Skip to content
This page has been auto-translated and may contain errors.View in English

开放式模型和闭源式模型

docs.scrimba.com

从本质上讲,模型是一大堆经过训练的权重(它在训练期间学到的数字),用来预测下一个token。本章讨论的是这些权重到达你手中的两种方式,一种是你通过API租赁的闭源模型,另一种是你可以自己运行的开放权重模型,以及它们实际运行的位置。默认的选择是大多数人被引导选择的托管闭源模型,而提供商几乎没有理由突出其他选择,因此了解完整的选项以及每个选项何时重要是有价值的。

开放权重、闭源权重

获取AI模型有两种方式,区别在于模型实际存在的位置。

第一种是闭源模型,有时也称为专有模型。你只能通过公司的API(一种在线通道)访问它:你发送文本,获取文本返回,就是这样。模型的权重,即那一大堆使其运作的经过训练的数字,被锁定在公司的服务器上。你是在租赁访问权,而不是拥有任何东西。

第二种是开放权重模型。这里公司会发布这些权重,所以你可以下载自己的副本,并在你控制的硬件上运行它。把它想象成租一套公寓,但你永远不被允许看到它的布线,而不是拥有建筑平面图的副本。

大多数人开始使用闭源API,因为这是最容易进入的大门,这是一个好的开始方式。开放选项是真实存在的,值得了解,这样你就能明白租赁是一种选择,而不是唯一的道路。

Juno开放权重、闭源权重 闭源模型存在于公司的服务器上,你通过他们的API访问它,因此你是在租赁访问权。开放权重模型将其数字公布出来,所以你可以下载副本并自行运行。从闭源API开始是完全可以的,但了解另一扇门的存在会有所帮助。

整个区别归结为一个问题:谁持有权重?对于闭源或专有模型,权重永远不会离开提供商,你只能通过API与模型通信。对于**开放权重**模型,权重在许可证下发布,你可以下载并在任何地方运行。

要小心,因为"开放权重"不等同于"开源"。几乎每个"开放"大语言模型都发布了训练权重,但保留了训练数据和训练代码,因此你无法从头开始完全重现该模型。一些许可证还附带使用限制,例如对使用它商业化的公司规模的上限,或对允许用途的限制。在做出承诺前阅读许可证;"开放"是一个谱系,而不是二进制的。

在性能方面,最前沿的闭源模型(任何给定时间最具能力的模型)通常领先公共基准。但强大的开放权重模型对于许多实际任务来说已经足够接近了,而且差距随着时间的推移在不断缩小。实际的做法是不要假设你需要绝对最顶级的模型。许多工作由开放权重模型就可以很好地处理,你可以通过针对自己的任务进行测试来了解,而不是查看排行榜。

Juno开放权重、闭源权重 闭源意味着仅API接口且权重保留在提供商;开放权重意味着已发布的权重可供你下载并运行。开放权重不是开源软件,因为训练数据和代码通常保持私密,许可证可能限制使用,所以要阅读它。最前沿的闭源模型领先基准,但强大的开放权重模型处理大量实际工作,因此根据具体任务来选择。

"开放"实际上给你带来的是控制权和摆脱锁定的自由。你可以固定确切的权重,使模型永远不会在你身下悄悄改变,检查其行为,并在任何有硬件的地方运行它。当可重复性或数据驻留很重要时,这是一个真正的优势。

它不会给你的是免费午餐。**开放权重**几乎总是意味着权重加许可证而不是开源:没有训练数据,通常有非平凡的许可证条款。因此合规和许可证审查成为你需要做的实际工作,一个听起来宽松的模型仍然可能限制商业使用或重新分发方式,如果你跳过阅读,这些问题可能会在后期浮出水面。

最前沿的能力差距对于最困难的任务也是真实存在的,即使差距在缩小。因此根据你面前的任务来选择,而不是基于标签。对于大部分常规工作,开放权重模型已经足够了;对于困难的边界情况,闭源最前沿可能仍然会赢。

我不得不一直提醒自己:将"开放"视为权重和许可证的共同属性,并同时阅读两者。"我可以下载它"与"我可以用它做任何事"不是同一句话,而这两者之间的差距曾经坑过我。

Juno开放权重、闭源权重 开放权重给你控制权和逃脱锁定的自由:固定版本、可检查的行为、随处运行。它们不会给你开源,因此要为许可证和合规审查预留资源,因为一个看起来友好的许可证仍然可能禁止商业使用。根据任务来选择,而不是标签,永远不要将"我可以下载它"理解为"我可以用它做任何事"。

模型运行的位置

有一种说法说选择开放模型意味着你必须设置自己的服务器并自己运行它。这是不对的,值得早点澄清。

模型可以在两个地方运行。对于托管模型,某个公司在他们的机器上运行它,你通过网络API调用与它交互,这是一个小请求你的代码发送出去并从中获得答案。你永远不会接触到运行它的计算机。对于自托管,你自己在你的计算机或你自己的服务器上运行模型。

这是人们忽视的部分。开放模型不会强制你进行自托管。你可以通过托管公司以同样舒适的方式使用开放模型,就像使用闭源模型一样:你发送请求,获取答案,由别人保持机器运行。自托管是你可以采取的选项,而不是你必须遵循的规则。

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是正确的默认设置,自托管开放权重模型是成本和控制决策,在一定规模之后或在合规约束下得到回报,而不是人格特征。了解你的成本曲线在哪里交叉,了解你的数据规则真正要求什么,并记住开放权重给你免费微调和逃脱供应商锁定的权利。我见过证明观点的自托管,后悔是真实的。学习完整菜单以便有目的地选择,然后继续到提示工程。