如何用更小的开源模型击败专有 LLM

围绕开源模型构建您的 AI 应用程序可以使它们变得更好、更便宜、更快。

译自 How to Beat Proprietary LLMs With Smaller Open Source Models，作者 Aidan Cooper。

在设计使用文本生成模型的系统时，许多人首先会转向专有服务，例如 OpenAI 的 GPT-4 或 Google 的 Gemini。毕竟，这些是目前最大、最好的模型，那么为什么还要使用其他模型呢？最终，应用程序会达到这些 API 不支持的规模，或者它们变得成本高昂，或者响应时间太慢。开源模型可以解决所有这些问题，但如果你尝试以使用专有 LLM 的方式使用它们，你将无法获得足够的性能。

在本文中，我们将探讨开源 LLM 的独特优势，以及如何利用它们来开发不仅比专有 LLM 更便宜、更快速，而且更好的 AI 应用程序。

表 1 比较了专有 LLM 和开源 LLM 的主要特征。开源 LLM 被认为在用户管理的基础设施上运行，无论是在本地还是在云中。总之：专有 LLM 是托管服务，提供功能最强大、闭源模型和最大的上下文窗口，但开源 LLM 在其他所有重要方面都更胜一筹。

下面是中文版的表格(markdown格式):

	专有大型语言模型	开源大型语言模型
示例	GPT-4 (OpenAI)、Gemini (Google)、Claude (Anthropic)	Gemma 2B (Google)、Mistral 7B (Mistral AI)、Llama 3 70B (Meta)
软件可访问性	闭源	开源
参数数量	万亿级	典型规模: 2B、7B、70B
上下文窗口	更长,100k-1M+tokens	更短,典型8k-32k tokens
能力	在所有排行榜和基准测试中表现最佳	历史上落后于专有大型语言模型
基础设施	平台即服务 (PaaS), 由提供商管理。不可配置。API 速率限制。	通常在云基础设施 (IaaS) 上自我管理。完全可配置。
推理成本	更高	更低
速度	在相同价格点更慢。无法调整。	取决于基础设施、技术和优化,但更快。高度可配置。
吞吐量	通常受 API 速率限制。	不受限制:随您的基础设施而扩展。
延迟	较高。多轮对话可能会累积显著的网络延迟。	如果在本地运行模型,则无网络延迟。
功能	通常通过其 API 暴露有限的功能集。	直接访问模型可以解锁许多强大的技术。
缓存	无法访问服务器端	可配置服务器端策略,提高吞吐量并降低成本。
微调	有限的微调服务(如 OpenAI)	完全控制微调。
Prompt/Flow 工程	通常由于成本高昂或由于速率限制或延迟而无法实现	不受限制,精心设计控制流程的负面影响很小。

表 1. 专有 LLM 和开源 LLM 特性的比较

本文的重点是，通过利用开源模型的优势，可以构建任务性能优于专有 LLM 的 AI 应用程序，同时还可以实现更好的吞吐量和成本概况。

我们将重点关注开源模型的策略，这些策略对于专有 LLM 来说是不可能的或效果较差。这意味着我们不会讨论对两者都有益的技术，例如少样本提示或检索增强生成 (RAG)。

在考虑如何围绕 LLM 设计有效系统时，有一些重要的原则需要牢记。

任务性能、吞吐量和成本之间存在直接权衡：很容易改进其中任何一个，但通常是以牺牲其他两个为代价。除非你的预算无限，否则系统必须在这三个方面都达到最低标准才能生存。对于专有 LLM，通常会卡在三角形的顶点，无法以可接受的成本达到足够的吞吐量。

在探讨可以帮助解决每个问题的策略之前，我们将简要介绍每个这些非功能性需求的特征。

许多 LLM 系统难以实现足够的吞吐量，仅仅是因为 LLM 的速度很慢。

在使用 LLM 时，系统整体吞吐量几乎完全由生成文本输出所需时间决定。

除非你的数据处理特别繁重，否则文本生成之外的因素相对不重要。LLM 可以比生成文本快得多地“读取”文本——这是因为输入 token 是并行计算的，而输出 token 是顺序生成的。

我们需要在不牺牲质量或产生过高成本的情况下最大化文本生成速度。

这给了我们两个杠杆，当目标是增加吞吐量时可以拉动：

• 减少需要生成的 token 数量
• 提高生成每个单独 token 的速度

以下许多策略都旨在改进其中一个或两个方面。

对于专有 LLM，你将按输入和输出 token 计费。每个 token 的价格将与你使用的模型的质量（即大小）相关。这为你降低成本提供了有限的选择：你需要减少输入/输出 token 的数量，或使用更便宜的模型（可供选择的不会太多）。

对于自托管 LLM，你的成本由你的基础设施决定。如果你使用云服务进行托管，你将按“租用”虚拟机的每个时间单位计费。

更大的模型需要更大、更昂贵的虚拟机。在不改变硬件的情况下提高吞吐量可以降低成本，因为处理固定量的数据所需计算小时数更少。同样，可以通过垂直或水平扩展硬件来提高吞吐量，但这会增加成本。

最小化成本的策略重点是让更小的模型能够用于该任务，因为这些模型具有最高的吞吐量和最便宜的运行成本。

任务性能是三个要求中最模糊的，但也是优化和改进范围最广的要求。实现足够任务性能的主要挑战之一是衡量它：很难正确获得 LLM 输出的可靠、定量评估。

由于我们专注于独特地有利于开源 LLM 的技术，因此我们的策略强调用更少的资源做更多的事情，并利用只有在直接访问模型时才可能的方法。

以下所有策略在孤立的情况下都是有效的，但它们也是互补的。它们可以应用于不同程度，以在系统的非功能性要求之间取得适当的平衡，并最大化整体性能。

• 提升任务性能
• 降低吞吐量
• 增加每个输入的成本

虽然可以使用广泛的多轮对话策略与专有 LLM 一起使用，但这些策略通常不可行，因为它们：

• 按令牌计费时成本可能很高
• 可能耗尽 API 速率限制，因为它们每个输入需要多个 API 调用
• 如果来回交换涉及生成许多令牌或累积大量网络延迟，则可能太慢

随着专有 LLM 变得更快、更具可扩展性和更实惠，这种情况可能会随着时间的推移而得到改善。但就目前而言，专有 LLM 通常仅限于单一的、单一的提示策略，以大规模应用于实际用例。这与专有 LLM 提供的更大的上下文窗口是一致的：首选策略通常只是将大量信息和指令塞进一个提示中（顺便说一下，这会产生负面的成本和速度影响）。

对于自托管模型，多轮对话的这些缺点不太令人担忧：每个令牌的成本不太相关；没有 API 速率限制；并且可以最大限度地减少网络延迟。开源模型较小的上下文窗口和较弱的推理能力也应该阻止你使用单一提示。这将我们引向了击败专有 LLM 的核心策略：

攻克专有 LLM 的关键，是用较小的开源模型在一系列更细粒度的子任务中完成更多工作。

精心制定多轮提示策略对于本地模型是可行的。诸如思维链 (CoT)、思维树 (ToT) 和 ReAct 等技术可以使能力较弱的模型执行与更大模型相当的性能。

另一个复杂层次是使用控制流和分支来动态地引导模型沿着正确的推理路径，并将一些处理任务卸载到外部函数。这些还可以用作保留上下文窗口令牌预算的机制，方法是在主提示流之外的分支中分叉子任务，然后重新加入这些分叉的汇总结果。

与其让一个小型开源模型承担过于复杂的任务，不如将问题分解为一个可行的子任务的逻辑流。

• 提高吞吐量
• 降低成本
• 提高任务性能

对于涉及生成结构化输出（例如 JSON 对象）的应用程序，受限解码 是一种强大的技术，可以：

• 保证符合所需结构的输出
• 通过加速令牌生成并减少需要生成的令牌数量来大幅提高吞吐量
• 通过指导模型来提高任务性能

我写了一篇单独的文章详细解释了这个主题： 使用受限解码进行结构化生成的指南生成语言模型输出的方式、原因、能力和缺陷

至关重要的是，约束解码仅适用于文本生成模型，该模型提供对完整下一个标记概率分布的直接访问，在撰写本文时，任何主要的专有 LLM 提供商都无法做到这一点。

OpenAI 确实提供 JSON 模式，但这种严格约束解码不能确保 JSON 输出的结构或吞吐量优势。

约束解码与控制流策略齐头并进，因为它使你能够通过将大型语言模型的响应约束为不同的分支选项，从而可靠地将其引向预先指定的路径。让一个模型对一系列冗长的多轮对话问题做出简短受限的回答，速度非常快且成本很低（记住：吞吐速度由生成的令牌数量决定）。

约束解码没有任何值得注意的缺点，因此，如果你的任务需要结构化的输出，你应该使用它。

• 提高吞吐量
• 降低成本
• 不影响任务性能

缓存是一种通过存储计算的输入：输出对来加速数据检索操作的技术，如果再次遇到相同的输入，则重用结果。

在非 LLM 系统中，缓存通常应用于与先前看到的请求完全匹配的请求。一些 LLM 系统也可能受益于这种严格形式的缓存，但通常在使用 LLM 构建时，我们不希望经常遇到完全相同的输入。

幸运的是，有专门针对 LLM 的复杂键值缓存技术，它们灵活得多。对于与先前看到的输入部分匹配但不是完全匹配的请求，这些技术可以极大地加速文本生成。这通过减少需要生成的令牌量（或至少加速它们，具体取决于特定的缓存技术和场景）来提高系统吞吐量。

对于专有 LLM，你无法控制如何对你请求执行或不执行缓存。但对于开源 LLM，有各种用于 LLM 服务的后端框架，可以显着提高推理吞吐量，可以根据你系统的定制要求进行配置。

除了缓存之外，还有其他 LLM 优化也可以用于提高推理吞吐量，例如模型量化。通过降低用于模型权重的精度，可以在不显着损害其输出质量的情况下缩小模型大小（因此也缩小了其内存需求）。流行的模型通常会有大量量化变体在 Hugging Face 上可用，由开源社区贡献，这让你不必自己执行量化过程。

SGLang 惊人吞吐量声明（参见 SGLang 发布博客文章）

vLLM 可能是最成熟的服务框架，拥有各种缓存机制、并行化、内核优化和模型量化方法。SGLang 是一个较新的参与者，具有与 vLLM 相似的功能，以及一种创新的 RadixAttention 缓存方法，声称具有特别令人印象深刻的性能。

如果你自托管模型，那么使用这些框架和优化技术非常值得，因为你可以合理地期望将吞吐量提高至少一个数量级。

• 提高任务执行效率
• 不影响推理成本
• 不影响吞吐量

微调包含各种技术，用于调整现有模型以在特定任务上表现得更好。我建议查看 Sebastian Raschka 的关于微调方法的博客文章作为该主题的入门读物。知识蒸馏是一个相关概念，其中一个较小的“学生”模型被训练来模拟一个较大的“教师”模型在感兴趣的任务上的输出。

包括 OpenAI 在内的一些专有 LLM 提供商提供最小的微调功能。但只有开源模型才能完全控制微调过程，并访问全面的微调技术。

微调模型可以显着提高任务性能，而不会影响推理成本或吞吐量。但微调确实需要时间、技能和良好的数据来实现，并且训练过程涉及成本。参数高效微调（PEFT）技术（例如 LoRA）特别有吸引力，因为它们相对于所需的资源量提供了最高的性能回报。

微调和知识蒸馏是最大化模型性能的最强大技术之一。只要正确实施，它们就没有缺点，除了执行它们所需的初始前期投资。但是，你应小心确保微调以与系统的其他方面一致的方式进行，例如提示流和受限解码输出结构。如果这些技术之间存在差异，则可能导致意外行为。

小模型：

• 提升吞吐量
• 降低成本
• 降低任务执行性能

这同样可以表述为“更大模型”，优缺点相反。关键点是：

尽可能将你的模型缩小，但仍要保持理解和可靠完成任务的足够容量。

大多数专有 LLM 提供商提供了一些模型大小/能力层级。而当涉及到开源时，所有你想要的大小中都有令人眼花缭乱的模型选项，最高可达 100B+ 参数。

如多轮对话部分所述，我们可以通过将复杂任务分解为一系列更易于管理的子任务来简化任务。但总会有一个问题无法进一步分解，或者这样做会损害需要更全面解决的任务方面。这在很大程度上取决于用例，但任务粒度和复杂度将有一个最佳点，它决定了模型的正确大小，如以最小的模型大小实现足够的任务性能所示。

对于某些任务，这意味着使用你能找到的最大、最有能力的模型；对于其他任务，你可能可以使用非常小的模型（甚至是非 LLM）。

在任何情况下，选择在任何给定参数大小下使用同类最佳模型。可以通过参考公开基准和排行榜来识别这一点，并且会根据该领域的快速发展速度定期更改。一些基准比其他基准更适用于你的用例，因此值得找出最适用的基准。

但不要以为你可以简单地替换 新的最佳模型 并实现立即的性能提升。不同的模型有不同的故障模式和特性，因此针对一个模型优化的系统不一定适用于另一个模型——即使它应该更好。

如前所述，所有这些策略都是互补的，当它们结合在一起时，它们会复合以产生健壮、全面的系统。但这些技术之间也存在依赖关系，重要的是确保它们保持一致以防止功能障碍。

下图是一个依赖关系图，展示了实施这些技术的逻辑顺序。这假设用例需要生成结构化输出。

这些阶段可以理解如下：

1. 目标数据模型是你想要创建的最终输出。这是由你的用例和生成文本处理之外的整个系统的更广泛要求决定的。
2. 受限解码输出结构可能与你的目标数据模型相同，或者可能针对受限解码期间的最佳性能进行了轻微修改。请参阅我的受限解码文章 以了解为什么会出现这种情况。如果不同，则需要一个后处理阶段将其转换为最终目标数据模型。
3. 你应该对你的用例的正确提示策略进行初步的最佳猜测。如果问题很简单，或者无法直观地分解，请选择单一提示策略。如果问题非常复杂，有许多细粒度子组件，请选择多提示策略。
4. 你的初始模型选择主要是一个优化大小的问题，并确保模型特性满足问题的功能要求。上面讨论了最佳模型大小。模型特性（例如所需的上下文窗口长度）可以根据预期的输出结构 ((1) 和 (2)) 和提示策略 (3) 计算。
5. 用于模型微调的训练数据必须与输出结构 (2) 保持一致。如果使用逐步构建输出的多提示策略，则训练数据还必须反映此过程的每个阶段。
6. 模型微调/蒸馏自然取决于你的模型选择、训练数据整理和提示流。
7. 精细调整模型的量化是可选的。您的量化选项将取决于您选择的基本模型。
8. LLM 推理服务器仅支持特定模型架构和量化方法，因此请确保您之前的选择与您所需的后台配置兼容。
9. 一旦您建立了端到端系统，您就可以建立一个反馈循环以持续改进。您应该定期调整提示和少样本示例（如果您正在使用这些示例）以解决系统未能产生可接受输出的示例。一旦您积累了合理的失败案例样本，您还应该考虑使用这些示例执行进一步的模型微调。

实际上，开发过程永远不会完全是线性的，并且根据用例，您可能需要优先优化其中一些组件而不是其他组件。但这是一个合理的基础，可以根据您的特定要求设计路线图。

开源模型可以比专有 LLM 更快、更便宜、更好。实现这一目标的方法是设计更复杂的系统，发挥开源模型的独特优势，并在吞吐量、成本和任务性能之间做出适当的权衡。

这种设计选择以系统复杂性换取整体性能。一个有效的替代方案是拥有一个由专有 LLM 提供支持的更简单、同样强大的系统，但成本更高且吞吐量更低。正确的决定取决于您的应用程序、您的预算和您的工程资源可用性。

但不要过快地放弃开源模型，而不调整您的技术策略以适应它们——您可能会对它们的功能感到惊讶。