开放模型与闭源模型

docs.scrimba.com

从本质上说，一个模型就是一大堆训练出来的权重（也就是它在训练过程中学到的那些数字），用来预测下一个 token。这一章要讲的是这些权重到达你手中的两种方式——闭源模型是你通过 API 租用的，开放权重模型是你可以自己运行的——以及它们各自实际运行在哪里。大家默认被引导去用的是托管的闭源模型，而服务商也没有什么理由去主动介绍其他选择，所以了解完整的选项，以及每种选项在什么情况下真正有用，是很值得的。

开放权重与闭源权重

获取一个 AI 模型有两种方式，区别就在于模型到底存放在哪里。

第一种是闭源模型，有时也叫专有模型。你只能通过公司提供的 API 接触到它，API 就相当于一个在线的门：你发送文字进去，得到文字回来，整件事就是这样。模型的权重——那一大堆让它运转起来的训练数字——始终被锁在公司自己的服务器上。你是在租用访问权限，而不是拥有任何东西。

第二种是开放权重模型。在这种情况下，公司会公开这些权重，所以你可以下载自己的一份副本，在你能控制的硬件上运行它。可以把它想象成：租一间你永远看不到内部线路的公寓，和拥有一份这栋楼的完整图纸，是两种完全不同的关系。

大多数人一开始都会选择闭源 API，因为这是最容易上手的入门方式，这样开始完全没问题。开放模型这个选项是真实存在的，也值得了解，这样你才明白租用只是一种选择，而不是唯一的路。

Juno开放权重与闭源权重 闭源模型存放在公司的服务器上，你只能通过它们的 API 接触到它，所以你是在租用访问权限。开放权重模型会公开它的数字，所以你可以下载一份副本自己运行。一开始用闭源 API 完全没问题，但了解一下另一条路的存在会很有帮助。

整个区分归结为一个问题：权重掌握在谁手里？对于闭源或专有模型，权重永远不会离开服务商，你只能通过 API 与模型对话。对于**开放权重**模型，权重会以某种许可协议公开发布，你可以下载并在任何地方运行它。

这里要小心一点，因为"开放权重"不等于"开源"。几乎所有"开放"的 LLM 都只发布了训练好的权重，却保留了训练数据和训练代码，所以你无法从零完全复现这个模型。有些许可协议还带有使用限制，比如限制可以商用的公司规模上限，或者限制允许的使用场景。在决定使用之前先读一读许可协议；"开放"是一个程度问题，不是非黑即白的判断。

在能力上，前沿闭源模型（在任何特定时刻能力最强的模型）往往在公开榜单上领先。但优秀的开放权重模型在大量实际任务中已经足够接近了，而且这个差距还在不断缩小。实际的做法是不要想当然地认为自己一定需要最顶尖的模型。很多工作用开放模型就完全够用，判断的方法是拿你自己的任务去实测，而不是看排行榜。

Juno开放权重与闭源权重 闭源意味着只能通过 API 使用，权重留在服务商手里；开放权重意味着权重公开，你可以下载并运行。开放权重不等于开源，因为训练数据和代码通常仍是保密的，许可协议也可能限制用途，所以一定要读一读。前沿闭源模型在榜单上领先，但一个强劲的开放权重模型也能胜任大量实际工作，所以按任务来选。

"开放"真正带给你的是控制权，以及摆脱厂商锁定。你可以固定住确切的权重版本，让模型永远不会在你不知情的情况下悄悄变化，可以检视它的行为，也可以在任何你有硬件的地方运行它。当可复现性或数据驻留要求很重要时，这是一个实实在在的优势。

但它带给你的不是天上掉下来的馅饼。**开放权重**几乎总是意味着"权重加许可协议"，而不是开源：没有训练数据，许可条款往往还不简单。所以合规和许可审查会变成你实际要做的工作，一个听起来很宽松的模型，许可协议里仍可能限制商业使用或再分发，如果你跳过阅读，这些限制往往会在后期才暴露出来。

对于最难的任务，前沿能力上的差距也是真实存在的，即便它在不断缩小。所以要按眼前的任务来选择，而不是按标签来选择。对于大部分日常工作，开放权重模型完全够用；对于难度的极限，闭源前沿模型可能仍然更胜一筹。

我一直要提醒自己的一点是：把"开放"当作权重和许可协议共同构成的属性，两者都要读。"我能下载它"和"我能拿它做任何事"根本不是一句话的两种说法，这两者之间的差距，我以前就吃过亏。

Juno开放权重与闭源权重 开放权重给你的是控制权和摆脱厂商锁定：版本固定、行为可检视、随处可运行。它给你的不是开源，所以要为许可协议和合规审查留出预算，因为一份看起来友好的许可协议仍可能禁止商用。按任务选择，不要按标签选择，永远不要把"我能下载它"读成"我能拿它做任何事"。

模型运行在哪里

有一种流传甚广的说法认为，选择开放模型就意味着你必须自己搭建服务器、亲自运行这个模型。这个说法是错的，值得早点说清楚。

模型可以运行在两种地方之一。对于托管模型，某家公司在自己的机器上运行它，你通过 API 调用在网络上接触到它，API 调用就是你的代码发出的一个小请求，然后得到一个回应。你完全不用碰运行它的那台电脑。而在自建部署（self-hosting）中，你自己运行这个模型，在你自己的电脑或自己的服务器上。

这里是大家容易忽略的一点。开放模型并不会强迫你走自建部署这条路。你完全可以像使用闭源模型那样，通过某家托管公司来使用开放模型：你发送请求，得到回应，机器由别人负责运行维护。自建部署是一个你可以选择的选项，不是你必须遵守的规则。

Juno模型运行在哪里 模型要么运行在别人的机器上，你通过网络访问它；要么运行在你自己运行的机器上。开放模型两种方式都可以，所以选择开放模型并不意味着你突然就要去管理服务器。你完全可以让一家托管公司帮你运行开放模型，就像你使用闭源模型一样。

抛开"非此即彼"的思维方式会更有帮助，因为模型运行在哪里其实是一个连续的谱系。谱系的一端，是通过服务商的 API 调用的闭源模型。中间，是由第三方托管方帮你运行的开放权重模型。另一端，是你自己运行的开放权重模型，也就是**自建部署**：你提供机器，运行用来提供模型服务的程序。

沿着这个谱系移动的成本之所以很低，是因为一种被广泛采用的聊天消息 API 格式已经成了事实上的标准，许多开放模型托管方和自建服务端都暴露出同样的格式。所以更换服务商往往只需要改一下基础 URL 和模型名称，而不需要重写代码（参见从代码中调用模型）。你学到的关于调用模型的知识不会被锁死在某一家厂商上。

概括来说，自建部署意味着你要提供硬件（一块性能足够的 GPU，或者一台租用的 GPU 服务器），并在模型前面运行一个服务程序。要把这当作你真正要承担的工作。在这里我们只停留在决策层面，不深入讲搭建细节。

Juno模型运行在哪里 可以把它想象成一个谱系：通过服务商使用闭源模型，通过第三方托管方使用开放模型，或者自己自建部署开放模型。因为很多接口都共用同一种聊天消息 API 格式，在它们之间切换通常只是换一下 base_url 和模型名称，而不是重写代码。自建部署是谱系的最远端，由你自己承担硬件和服务，所以要有意识地选它，不要默认走这条路。

自建部署是基础设施建设，不是什么附加任务。一旦你自己运行模型，容量规划、负载扩展、正常运行时间、安全补丁和模型更新就都归你负责了。"能在我的笔记本上跑起来"只是一个演示，生产环境是另外一笔账。

大多数团队会跳过的中间路线，是托管式的开放模型服务。你能获得开放模型的好处（比前沿闭源模型更低的成本、固定特定模型版本的能力、数据存放位置的选择空间、不被单一厂商锁定），却不需要自己搭建 GPU 集群。事实上的标准聊天 API 格式就是你的保险：只要你的代码坚持这个接口，切换托管方，或者以后把模型拉回自己内部运行，都只是改配置，而不是迁移。

我见过一次"快速自建"吃掉整整一个季度的时间，所以我只在确实有具体压力时才会考虑真正的自建部署：数据驻留规定、对你有利的规模经济，或者一个你必须端到端全权掌控的模型。如果没有这些理由，答案就是托管式开放模型或闭源托管模型。

Juno模型运行在哪里 自己运行模型意味着容量、正常运行时间、补丁和更新都要你自己负责，所以别轻易走上这条路。团队容易忽略的路线是托管式的开放模型服务：拥有开放模型的经济性和控制力，却不用自己伺候 GPU。代码只对接标准聊天 API，换服务商就只是改配置，不是迁移。真正的自建部署要留给数据驻留、规模经济，或者硬性模型控制这类具体理由。

什么时候该用哪种

这里有一个简单的方式来把握整个选择。托管的闭源模型是租用：不需要搭建任何东西，你能拿到目前最好的质量，每次使用都付一点钱。你自己运行的开放模型更接近拥有：你获得更多的控制权和隐私，也没有需要付给服务商的按次账单，但你要承担让它保持运行的工作。

大多数人一开始通过 API 租用是正确的选择，而且大多数人永远都不需要更多。先租用是正常、合理的路径。

这一章的重点不是说你应该转去自己运行模型。它只是想告诉你，这个选择权在你手里，这样如果有一天你的需求变了，你能认出这个选项本来的样子。

选定了模型之后，接下来的问题是你要如何跟它对话。下一章提示词，讲的就是如何引导你选定的模型，让它给出你真正想要的结果。

Juno什么时候该用哪种 可以把它理解成租用和拥有的区别：托管的闭源模型是租用，你自己运行的开放模型更接近拥有。通过 API 租用是正确的起点，大多数人也乐于一直待在那里。你现在知道另一条路是存在的，这就是这一章的全部意义。接下来是"提示词"，我们会学习如何引导你选定的模型。

等你真正要做选择的时候，大致按下面这个顺序去权衡各个因素。第一，能力：托管的前沿模型在这个任务上真的物有所值吗，还是一个强劲的开放权重模型就已经足够好了？第二，数据敏感性：在服务商的条款下，这些数据能否离开你的边界，还是**数据驻留**要求（关于数据物理上必须存放在哪里、在哪里被处理的规定）根本就排除了这个选项？

第三，成本曲线。按 token 计费的 API 在起步阶段很便宜，低用量时也一直便宜，但在稳定的高用量情况下可能会变得很贵，这正是固定成本的自建部署能占优势的地方。第四，控制权：你是否需要在不同版本之间固定住确切的行为，或者避免被锁定在单一厂商上？

大多数情况下，做法都是一样的。先从托管 API 开始，因为这是让东西跑起来最快的路径。然后只有当具体的压力真正出现时才重新考虑：规模带来的成本压力、隐私或合规要求，或者真实存在的能力或控制需求。

要根据证据来决定，不要根据默认设置或某种执念。等模型确定下来之后，提示词讲的就是如何从它那里获得可靠的输出。

Juno什么时候该用哪种 按顺序权衡四件事：所需的能力、数据敏感性、成本曲线，以及控制权。先从托管 API 开始，因为它能最快让你跑起来，等具体的压力出现时——比如高用量下的成本，或者数据驻留规定——再重新考虑。根据证据来切换，不要凭直觉。然后转向"提示词"，让你选定的模型真正听话地表现出来。

说白了就是这样。对大多数团队来说，托管的闭源 API 是正确的默认选择，自建部署开放权重模型是一个成本和控制权的决策，不是什么彰显严肃程度的标志。它在超过某个规模之后，或者在合规、数据驻留约束之下才值得，在这之前基本不值得。

所以你要大致知道，对你的用量而言，成本曲线在哪个点交叉，因为这个交叉点就是整个财务论证的核心。要知道你的数据规定真正要求的是什么，而不是它们模糊感觉上要求什么，这就涉及到安全与限制，以及你到底该发送什么内容的问题。还要知道，开放权重也让你能够按自己的意愿自由微调，而不需要征求服务商的同意（参见微调）。避免**厂商锁定**——也就是被绑死在某一家服务商的价格、条款和模型生命周期上——也是同一套计算的一部分。

学习这一切的目的，不是让你去自建部署。我见过有人为了证明一个观点自己搭建了一整套栈，结果到了第二周的值班期就后悔了。真正的目的是：默认路径是托管的闭源模型，服务商也没有什么理由去主动指出其他选择，所以了解完整选项的工程师，能做出深思熟虑的选择，而不是被动接受别人给的默认项。

模型的问题在权衡利弊之后有了答案，接下来提示词才是日常工作中真正获得好输出的地方。

Juno什么时候该用哪种 对大多数团队来说，托管的闭源 API 是正确的默认选择，自建部署开放权重模型是一个在超过某个规模或受合规约束时才值得的成本和控制权决策，不是什么个性标签。要知道你的成本曲线在哪里交叉，要知道你的数据规定真正要求什么，还要记住开放权重能让你免费微调、摆脱厂商锁定。我见过为了证明一个观点而自建部署的例子，那种后悔是真实的。了解完整的选项，这样你才能有意识地做选择，然后继续前往"提示词"。