自建 LLM 还是用云端：成本与控制权的权衡

自建 LLM 还是用云端：成本与控制权的权衡 | 前端进阶之旅

Full translation

完整中文译文

Andrew Marble
marble.onl
andrew@willows.ai
2023 年 8 月 13 日

在《终结者》系列电影中，良好的关系战胜了技术优势。Kyle Reese 和 Sarah Connor 凭借智慧击败了先进的 T-800，而后者又帮助 Sarah 和 John 战胜了更为先进的 T-1000。OpenAI 的 GPT-4 是目前最先进的公开可用语言模型。还有一些分析表明，总体而言，使用 GPT-4 的成本低于自行托管性能相当的模型。尽管 OpenAI 的模型具备种种优势，我仍想说明，自行托管依然值得考虑，尤其是在你准备构建产品或内部能力时。

如果你要在定制应用中使用语言模型，可以调用 OpenAI、Anthropic 等公司的 API：提交 prompt、获得响应，然后按使用量付费。你也可以配置自己的模型，将其托管在本地或云端。目前有许多模型可供自行托管。近期的一些分析从成本和性能角度论证了使用 OpenAI API 的合理性¹˒²。虽然可以进行非常细致的成本计算，但按使用量计费的 API 有一个显而易见的成本优势：只有实际使用硬件时，你才需要为它付费。大多数自行托管的应用都很难充分利用专用 GPU，因此会为大量闲置时间买单。

衡量性能是一件非常微妙的事——我个人认为，各类 benchmark 和“排行榜”³上的排名，与模型在特定商业任务中的表现并不存在一一对应的关系。不过，在广泛的能力范围内，GPT-4 毫无疑问优于其他模型；而在公开可用的模型中，也只有最优秀的那些才能与 Claude（Anthropic 的模型）和 GPT-3.5 竞争。

尽管如此，使用公开可用的模型依然有着令人信服的理由。（注意，我说的不是“开源”：其中许多模型还受到其他限制，因此并不符合开源的定义⁴。不过这里不展开讨论。）在我看来，归根结底，这是一个“关系”问题。使用 API，意味着 OpenAI 等公司提供什么，你就只能接受什么。模型功能、定制能力、价值取向（包括审查制度和世界观）等，全都由这些公司决定。你能构建的只有一个前端。这也意味着你无法访问模型的内部状态，因此会受到诸多限制，例如无法在模型之上应用高级的问责技术或 guardrail。这一切也可能是好事，因为你不必为这些问题操心。但它同样意味着，无论你构建了什么，都会完全依赖一家初创公司。

从“基于关系”的开发角度看，使用自行托管的模型有充分的理由。掌控模型架构和权重，可以消除未来变更带来的不确定性，也意味着你不必被动接受 OpenAI 决定提供给你的东西。现在已经形成了一个由不同模型组成的丰富生态，你可以在其中进行实验，也可以自由定制模型——例如按照自己的条件进行 fine-tuning。这种模式最终能让你与自己的 AI 模型建立长期关系，并围绕它调整产品。你可以明确知道，自己构建的东西将继续与所选择的模型配合工作，同时还能自主决定是否以及何时做出改变。这样构建出来的，就不只是套在别人语言模型外面的一层前端，而是一个与模型深度集成的系统。

此外，对于许多应用来说，真正创造价值的并不是 GPT 类模型那种全面而均衡的优势。运行一个 GPT-4 规模的模型，每月成本可能高达数万美元。但 7B 和 13B 模型（分别拥有 70 亿和 130 亿个参数，是 LLaMA 及其他公开模型的常见规模）已经可以在笔记本电脑上运行。这些模型足以胜任许多任务，而且作为本地系统的一部分，也可能具备很高的成本效益。

“负责任地”使用 AI 可以有很多种含义。科技公司往往把重点放在政治正确和一些流于表面的偏见观念上，主要是为了避免 chat-GPT 这类通用型公开模型引发争议。但对许多应用而言，尤其是专业知识工作⁵，这些顾虑大多无关紧要，真正需要解决的是事实准确性、完整性，或者仅仅是确保模型不要偏离主题。许多让“模型循规蹈矩”的技术，都需要访问模型的内部状态、梯度和中间输出⁶。使用基于 API 的模型，会限制你能够进行的实验和增强。

缓存模型内部状态、对模型进行 fine-tuning 等各种优化也是如此。API 确实提供了一些选项，但与自行托管时可用的能力相比，依然十分有限。这项技术仍在飞速演进，每天都有新的模型和技术出现。如果要将 LLM 作为产品或工具中紧密集成的一部分使用，那么要想保有随技术共同演进的灵活性，唯一的办法就是拥有一个自行托管的模型。

语言模型当前变化速度极快，这还带来了另一个问题：使用这项技术所需的技能与知识也在迅速演变。与自行托管的模型打交道，可以帮助组织和个人积累应对这一变化中技术格局的经验，而 API 无法做到这一点。无论是为了员工的职业发展，还是为了提升适应变化的能力，对许多公司而言，在更深的技术层面保有“AI”能力都非常重要，尤其是那些正在构建应用的公司。这项技术尚未成熟，而我们这些从业者所拥有的部分“护城河”，其实只是知道正在发生什么。

我甚至愿意更进一步：任何以非轻量方式使用 AI 的组织，都应该在内部拥有，或通过顾问获得一些对这项技术的深层理解，而不能只会查阅 API reference。只有这样，才能理解它从根本上最擅长什么。随着 AI 日益商品化并被过度炒作，它真正能够做到的事情，与人们实际使用它或者提议用它完成的事情之间，往往会出现巨大的脱节。

我预计几年之后，整个格局会变得截然不同——届时，人们将对模型必须具备的关键能力形成共识，而 API 也会支持这些能力。但对于一项仍处于实验阶段、快速演进的新技术，真正参与其中，需要深入访问模型和代码。这并不意味着所有公司或产品都需要这样的访问权限——有很多有价值的东西完全可以构建在 API 之上，如果非要自行托管，可能只是在浪费时间。但这些本质上属于不同类型的产品。

回到《终结者》的例子，Reese 和 T-800 都建立了牢固的关系，并因此成功完成了各自的任务。那些受 Skynet 指派的终结者，只知道四处炫耀自己更胜一筹的技术实力，最终却不足以赢得胜利。建立关系的一部分，就在于能否获得访问权限。我知道这个类比有些傻，但我相信同样的道理也适用于这些模型：关键在于能否深入理解工具的优势，并构建一个与它紧密集成的系统，而仅靠 API 是做不到这一点的。

《你并不需要托管 LLM，对吧？》↩︎
《你并不需要托管 LLM，对吧？》↩︎
《LLaMA inference》↩︎
《LLaMA inference》↩︎
LMSYS Chatbot Arena Leaderboard↩︎
LMSYS Chatbot Arena Leaderboard↩︎
《伪装成开源的软件许可证》↩︎
《伪装成开源的软件许可证》↩︎
《LLM 应用的新兴架构》↩︎
《LLM 应用的新兴架构》↩︎

关于模型问责，已经存在大量文献和研究。一个范围较窄的例子是《LLM 的内部状态知道自己何时在说谎》，此外还可参阅另一篇相关研究。↩︎