摘要：“某种程度上是这样。”因为提到 LLM，大多数人只会想到 OpenAI，调用 API 确实简单。她为什么要谈这些内容？调用 API 谁不会？但实际上，访问 LLM 的方式不止一种。可用托管的API如 OpenAI、Cohere、Anthropic 和 AI21

今天我会首先解释为什么 LLM 的部署很难，因为许多人可能并不理解其中的复杂性。接着，我会分享七个提高 LLM 部署效果的技巧和方法。

“最近在忙啥？”

“我一直在让 LLM 服务变得更简单。”

“LLM 部署难吗？不是直接调用 OpenAI API 就行？”

“某种程度上是这样。”因为提到 LLM，大多数人只会想到 OpenAI，调用 API 确实简单。她为什么要谈这些内容？调用 API 谁不会？但实际上，访问 LLM 的方式不止一种。可用托管的API如 OpenAI、Cohere、Anthropic 和 AI21 Labs 等。他们已为你完成托管和部署，你只需调它们。虽然这确实减少你的工作量，但仍存在复杂性，如减少幻觉输出。不过，他们已经完成很多繁重任务。很多场景，你可能更倾向自托管，如调用 Mistral或托管 Llama 或其他模型。这意味着你在自己的环境中托管它，无论VPC还是PC。

很多原因：

如果这几点不重要，就用 API 够了。

包括控制权、定制化和成本。最重要的是控制权。拥有 AI 独立性至关重要，如当 OpenAI 再次解雇 CEO，你仍可访问自己的模型，尤其是当你构建重要的业务应用时。如果你正在考虑自托管，你绝对不是孤军奋战，大多数企业都在努力建立自托管能力。

对冲基金的一员说：“隐私对我的用例很重要，因此自托管是有意义的。”然后他可能会问：“自托管真的有那么难吗？”我经常听到类似的话，这让我非常恼火。答案是：确实更难。你不能忽视那些你看不到的复杂性。当你调用基于 API 的模型时，你受益于他们的工程师在构建推理和服务基础设施方面所做的所有努力。实际上，像 OpenAI 这样的公司有 50 到 100 人的团队在管理这些基础设施。包括模型压缩、Kubernetes、批处理服务器、函数调用、JSON 生成、运行时引擎等。当你使用 API 模型时，这些你都不需要操心，但当你自托管时，这些问题突然变成了你的责任。

他可能会说：“但我经常部署机器学习模型，比如 XGBoost 或线性回归模型。部署这些 LLM 会有多难？”我们的回答是：“你知道 L 代表什么吗？”部署这些模型要困难得多。为什么呢？LLM 中的第一个 L 代表“大”（Large）。我记得我们刚成立公司时，认为一个拥有 1 亿参数的 BERT 模型已经算大了。现在，一个拥有 70 亿参数的模型被认为是小型模型，但它仍然有 14GB 的大小，这绝对不小。

第二个原因是 GPU。与 CPU 相比，GPU 更难处理，它们也更昂贵，因此高效利用 GPU 十分重要。如果你对 CPU 的利用率不高，可能问题不大，因为它们成本低得多。但对于 GPU，成本、延迟和性能之间的权衡非常明显，这是以前可能没有遇到过的。

第三个原因是，这个领域发展非常快。我们现在用于部署、优化和服务模型的技术，有一半在一年前还不存在。还有一个值得一提的问题是编排问题。通常，对于这些大语言模型应用，你需要协调多个不同的模型。例如，RAG（检索增强生成）就是一个典型的例子。你需要协调一个嵌入模型和一个生成模型。如果是最先进的 RAG，你可能还需要多个解析模型，比如图像模型和表格模型，此外还需要一个重排序模型。最终，你可能会用到五六个不同的模型。这会让人感到非常困惑。此外，部署应用还有其他常见难点，比如扩展性和可观察性。

构建应用程序时，应解你的部署边界。通常，人们在构建出一个自认为可行的应用程序后，才开始考虑部署边界。我认为，你应该先花时间思考你的需求，这会让后续一切变得更简单。如考虑你的：

所有这些问题都要提前规划。你可能无法知道精确需求，所以最好列出范围。如：“只要延迟低于 1 秒就可以接受。”或“只要高于某个值也行。”。还有一些问题如：我是否需要保证输出是 JSON 格式？是否需要保证输出符合特定的正则表达式规则？这些都值得提前思考。

提前规划好这些需求，那后续所有决策都容易得多。始终对模型进行量化。量化本质是一种模型压缩技术，它将LLM的权重精度降低到你想要的任何形式。4-bit 是我最喜欢的量化，从 FP32（32位浮点数）开始。因为它在准确性和压缩比之间达到极佳平衡。你可以看到这张图表，我们有一个准确性与模型位数的关系图，也就是模型的大小。

假设原始模型是 FP16（16位浮点数），其实它通常是 32 位的。红线表示它的准确性。当我们压缩模型时，比如从 FP16 降低到 4-bit，固定资源下，使用量化模型的性能实际上要好于未量化的模型。通过这张图表我们可以得出结论，对于固定资源，量化模型通常能够在准确性和资源利用率之间取得更好的平衡。

我们从基础设施开始，倒推需求。假设我们可用 L40S GPU，它有 48GB 显存。因为我们知道可用的资源，可以根据现有的模型倒推需求。如是 Llama 13B（130亿参数）模型，它需要 26GB 显存，没问题，可运行。但如是当前最先进 Mixtral 模型，它无法直接运行。然而，一个经 4-bit 量化的 Mixtral 模型可运行，这就很棒了。通过这种方式，就知道哪些模型可用来实验。

那个关于 Tim Dettmers 的图表也告诉我们，4-bit 量化模型在性能上可能更优。假设 Llama 模型和 Mixtral 模型体积一样，4-bit 模型通常会保留原来模型的高精度，同时大大减小了模型体积。我们通过基础设施倒推，找到能适配资源的量化模型，这很可能是当前性能最优的解决方案。

建议只花一点时间是因为，部署这些模型时，你最初想到的策略往往是完全错误的。虽然你不需要花大量时间思考这个问题，但稍微投入一些时间，可以使 GPU 利用率提升几个数量级。

举个例子，关于批处理策略。批处理是指多个请求同时处理。部署这些模型时，GPU 利用率是最宝贵的资源。因为 GPU 很昂贵，所以最大化其利用率非常重要。

如果我不使用批处理，那么 GPU 的利用率大概是这样的，非常糟糕。一个常见的错误做法是使用动态批处理，这种方法适用于非生成式 AI 应用，比如你之前可能用过的系统。动态批处理的原理是等待一小段时间，收集在这段时间内到达的请求，然后一起处理。在生成式模型中，这种方法会导致 GPU 利用率下降。开始时利用率很高，但随后会下降，因为用户会因较长的生成时间被卡在队列中。

动态批处理虽然是常见做法，但通常效果不好。如果你花点时间思考这个问题，可以采用持续批处理（Continuous Batching）。这是我们使用的一种方法，也是当前生成式模型的最先进批处理技术。它允许新到的请求中断正在处理的请求，以保持 GPU 利用率始终处于高水平。这样不仅减少了排队时间，还大幅提升了资源利用效率。这张 GPU 利用率图表是我们几周前的状态。相比动态批处理，持续批处理在 GPU 成本上可以带来一个数量级的提升。这完全不影响模型准确性，但大大提高了利用率。

对于非常大的模型，单个 GPU 无法满足推理需求。例如，Llama 70B、Mixtral 或 Jamba 等模型非常庞大。通常需要将它们分布在多个 GPU 上进行推理。这要求你能够设计一种多 GPU 推理的方法。最常见的方法（例如 Hugging Face 的 Accelerate 推理库所使用的方式）是按层级划分模型。如果模型占用 90GB，可以分配 30GB 给每个 GPU，共使用三个 GPU。然而，这种方法的缺点是每次只有一个 GPU 处于活跃状态，导致资源浪费，因为后续 GPU 需要等待前一个 GPU 完成任务。

这种方式存在局限性，例如在 Hugging Face Accelerate 库中。我们认为更优的方法是 Tensor Parallel。这种方式将模型按“长度”分割，使每个 GPU 能同时运行每一层，从而大幅提升推理速度，并支持任意大小的模型。所有 GPU 同时运行，因此避免了资源浪费。例如，在一个模型中，可以实现 GPU 利用率提升 3 倍，再加上其他优化，可以显著提升资源效率。

目前为止，我的建议包括：考虑部署需求、量化、推理优化。第四个建议是整合基础设施。生成式 AI 的计算成本非常高，因此集中的基础设施管理能带来很大优势。传统企业的机器学习团队往往以孤岛形式存在，导致基础设施整合效率低下。通过集中的 MLOps 团队（如 Ian 所领导的团队），可实现一次性部署并由单一团队进行维护，这让应用开发团队专注于构建应用。

举个例子，一个中央计算基础设施可以提供访问模型（如 Llama 70、Mixtral 和 Gemma 7B）的权限，并由中央团队定期更新模型（例如从 Llama 2 升级到 Llama 7）。各个应用开发团队可以个性化模型，例如添加 LoRA（轻量化适配器）或 RAG（结合专有数据的检索增强生成）。中央团队负责维护基础设施，而分散的开发团队仅需调用这些模型构建应用。这种方法不仅提高了 GPU 的利用率，还为组织提供类似 OpenAI 的体验，但使用的是私有模型。

关键点包括：确保推理服务器具备可扩展性、支持 LoRA 适配器以实现微调。如果做好这些工作，可以显著提升 GPU 利用率。GPU 的利用率非常重要，甚至可以说是仅次于家人和朋友的存在。

案例研究：RNL

一个美国企业 RNL 拥有四个不同的生成式 AI 应用，每个应用使用独立 GPU。这种方式导致了 GPU 利用率低下，因为不是所有应用始终满负荷运行。我们帮助他们将所有应用资源整合到一个推理服务器中，使各团队通过共享资源构建应用。这种方式将所需 GPU 数量减少了一半，同时也能更高效地管理生成式和非生成式任务。

建议的第五点是，假设在 12 个月内需要替换模型。随着 LLM 的快速发展，仅通过切换模型即可获得性能提升。例如，一个客户去年使用 Llama 1 开发了首个应用程序，在一年内更换了四次模型。

每周他们都会说，这个新模型出来了。你们支持吗？我会说，是的，但为什么这是第六次更改了？让我们回想一下一年前最先进的技术是什么。一年前，也许那时Llama已经发布了，但如果在那之前，可能是T5系列。T5模型是当时最好的开源模型。我们所见证的是开源大语言模型生态系统的惊人爆发。这一切都始于Llama，然后是Llama 2，接着许多企业在此基础上构建。

例如，Mistral 70B实际上是用与Llama相同的架构构建的。我们有来自阿联酋的Falcon。我们有Mistral的Mixtral。你们有很多，而且它们还在不断涌现。实际上，如果你查看Hugging Face，这是所有这些模型存储的地方，如果你查看他们的开源模型排行榜，顶级模型几乎每周都在变化。最新和最伟大的模型不断出现。这些模型将会不断变得更好。这是所有模型的性能，无论是开源还是非开源，你可以看到许可证，专有的或非专有的。开源模型正在慢慢地占据排行榜。我们开始接近开源和非开源之间的平等。现在，开源模型大约在GPT-3.5左右。那是我们所有人都为之惊叹的原始ChatGPT。

我的预期是，我们将在未来一年内达到GPT-4的质量。这意味着你真的不应该将自己与单一模型或单一供应商绑定。回到我之前向你们展示的a16z报告，大多数企业都在使用多个模型供应商。他们正在以一种可互操作的方式构建他们的推理栈，如果OpenAI出现故障，我可以轻松地将其替换为Llama模型。或者，如果现在Claude比GPT-4更好，我可以很容易地替换它们。以这种可互操作性为念进行构建真的很重要。我认为OpenAI给我们的最伟大的事情不一定是他们的模型，尽管它们真的很棒，但他们实际上违反直觉地民主化了AI领域，不是因为他们开源了他们的模型，因为他们真的没有，而是因为他们为行业提供了API的统一性。如果你以OpenAI API为念进行构建，那么你就可以捕捉到很多价值，并且能够轻松地替换模型。

这对构建方式意味着什么？以API和容器为先的开发使生活变得更轻松。这是相当标准的事情。抽象真的很好，所以不要花时间为你的特定模型构建自定义基础设施。你很可能在12个月内不会使用它。如果你要构建，尝试构建更通用的基础设施。我们总是说，在当前阶段，我们仍在许多组织中证明AI的价值，工程师应该花时间构建出色的应用体验，而不是纠结于基础设施。因为现在，对于大多数企业来说，我们很幸运有足够的预算去尝试这些生成式AI的东西。

我们需要快速证明价值。我们倾向于说，不要使用只支持Llama的框架，因为这只会给你带来更多麻烦。无论你选择什么架构或基础设施，确保当Llama 3、4、5、Mixtral、Mistral出现时，它们将帮助你采用它。我可以回到我之前谈到的案例研究。我们以这种方式构建，显然，用Mixtral替换Llama 3非常容易，当Llama 3出现时。例如，如果出现了更好的Embedder，就像几周前出现的非常好的Embedder，我们也可以很容易地替换它。

GPU看起来真的很贵。无论如何都要使用它们。GPU是如此惊人。它们非常适合生成式AI和生成式AI工作负载。生成式AI涉及大量并行计算，这恰好是GPU非常擅长的事情。你可能会看价格标签，觉得它比CPU贵100倍。是的，确实如此，但如果你正确使用它并从中获得你需要的利用率，那么最终处理的订单数量将会多得多，而且每个请求的成本将会便宜得多。

当你可以的时候，使用小型模型。GPT-4是王者，但你不会让王者洗碗。洗碗是什么：GPT-4是了不起的。它是一项真正卓越的技术，但使它如此出色的是它在能力上非常广泛。我可以使用GPT-4模型写情书，你可以用它成为一个更好的程序员，我们使用的是完全相同的模型。这很疯狂。那个模型有很多能力，因此它真的非常大。它是一个巨大的模型，而且推理起来非常昂贵。我们发现，你最好使用GPT-4来处理那些开源模型还无法处理的真正困难的事情，然后使用较小的模型来处理那些更容易的事情。通过这样做，你可以大幅降低成本和延迟。当我们谈到你之前拥有的延迟预算或资源预算时，如果你只在真正需要的时候使用GPT-4，你可以最大限度地利用资源预算。

三个常见的例子是RAG Fusion。这是当你的查询被大型语言模型编辑后，然后所有查询都进行搜索，然后结果进行排名以提高搜索质量。例如，你可以通过不使用GPT-4而获得很好的结果，只在必要时使用GPT-4。例如，使用RAG，你可以只使用一个生成模型来重新排名，所以只是在最后检查Embedder说相关的东西是否真的相关。小型模型，特别是针对函数调用的微调模型非常好。函数调用的一个非常常见的用例是，如果需要我的模型输出类似JSON或regex的东西，我基本上有两种方法可以做到这一点。要么我可以微调一个更小的模型，要么我可以给我的小模型添加控制器。控制器真的很酷。控制器本质上是，如果我自托管模型，我可以禁止我的模型说出任何会破坏JSON模式或我不想要的regex模式的标记。像这样的事情，实际上大多数企业用例，你不一定需要使用那些基于API的模型，你可以立即获得成本和延迟的好处。

确定你的部署边界，然后反向工作。因为你知道你的部署边界，你知道你应该选择的模型，当你将其量化下来时，就是那个大小。花时间思考优化推理，这可以真正地产生多个数量级的差异。生成式AI受益于基础设施的整合，所以尽量避免让每个团队负责他们的部署，因为很可能会出错。假设你将在12个月内替换你的模型进行构建。GPU看起来很贵，但它们是你最好的选择。当你可以的时候，你会使用小型模型。然后我们对Russell说这些，然后他说，“这太有帮助了。我非常兴奋地使用你的提示部署我的关键任务LLM应用。”然后我们说，“没问题，如果你有任何问题，请让我们知道”。

Q：你说过要为灵活性而构建。频繁更换模型的用例是什么？我们在自定义微调和自定义数据上花费的时间和精力将不得不重复？在频繁更换模型的情况下，你有什么建议吗？

A：你什么时候想要频繁更换模型？一直都是。随LLM改进速度，几乎总是可以仅通过更换模型就获得更好性能。你可能需要对提示进行一些调整，但通常，一对一的切换是可行的。例如，如果我的应用构建在GPT-3.5上，我将其替换为GPT-4，即使我使用相同的提示，我的模型性能可能会提高，这是一件非常低努力的事情。这与更换所需的工程努力如何协调？如果这是一个月的长过程，如果没有显著改进，那么你就不应该进行那个切换。我建议尝试以一种方式构建，使其不是一个月的长过程，实际上可以在几天内完成，因为那样几乎总是值得的。

这与微调如何协调？我有一个辛辣而热门的观点，即对于大多数用例，你不需要微调。微调在几年前的深度学习中非常流行。随模型越来越好，它们也更擅长遵循你的指示。你通常不需要为许多用例进行微调，可用RAG、提示工程和函数调用等方法。这就是我倾向于说的。如果你正在寻找你的第一个LLM用例，谈论更换模型，一个非常好的第一个LLM用例就是尝试替换你的NLP管道。许多企业都有现成的NLP管道。如果你可以将它们替换为LLMs，通常，你会获得多个点的准确性提升。

Q：你认为企业级硬件和消费者最大硬件在本地硬件上的区别是什么，因为我选择了消费者最大硬件，因为你的内存可以高达6000兆传输，PCI通道更快。

A：因为像他这样的人已经拿走了所有的A100s，当我们进行内部开发时，我们实际上使用的是4090s，这是消费者硬件。它们更容易获得，也比获得数据中心硬件便宜得多。这就是我们用于开发的东西。我们实际上没有使用消费者级硬件进行大规模推理，尽管没有理由它不会工作。

如果它适合你的工作负载。我们也使用它。我们认为它们非常好。它们也便宜得多，因为它们作为消费者级而不是数据中心级出售。

Q：你说GPU是一个整体，也是最重要的。我有点惊讶，但也许我的问题会解释。我用只有CPU的小虚拟机做了一些概念验证，我每秒几次请求就得到了相当好的结果。我没有问自己关于可扩展性的问题。我在想我们应该在多少请求时切换到GPU？

A：实际上，也许我在GPU方面有点过于强烈，因为我们也在CPU上部署过。如果延迟足够好，这通常是人们首先抱怨的问题，是延迟，那么CPU可能没问题。只是当你在寻找规模经济并且当你在寻找扩展时，它们几乎总是每个请求更贵。如果你的请求数量合理地低，延迟也足够好，那么你可以继续使用它。我认为我们的第一个推理服务器的概念验证是在CPU上完成的。你也会知道的另一件事是，你将限制你可以使用的模型的大小。例如，如果你正在做一个70亿量化的，你可能也可以继续使用CPU。我认为如果你从一张白纸开始，GPU更好。如果你的起点是你已经有一个充满CPU的大型数据中心，而且你否则不会使用它们，那么仍然值得尝试是否可以利用它们。

Q：我有一个关于通常使用的API的问题，当然，OpenAI的API通常也被应用程序使用。我也知道很多人真的不喜欢OpenAI的API。你看到其他API了吗？因为很多人只是在模仿它们，或者他们只是使用它，但没有人真的喜欢它。

A：当你说他们不喜欢它时，是他们不喜欢API结构，还是不喜欢模型？

Q：这是关于API结构的。这是关于文档的。这是关于状态的，关于你无法完全理解的很多事情。

A：我们也真的不喜欢它，所以我们编写了自己的API，称为我们的推理服务器，然后我们有一个与OpenAI兼容的层，因为大多数人使用那种结构。你可以查看我们的文档，看看你是否更喜欢它。我认为，因为它是第一个真正爆发的，它是整个行业在API结构上汇聚的地方。

来源：JavaEdge