本文是实用生成式人工智能应用系列文章的一部分。在这一系列文章里，我们呈现了来自顶尖生成式人工智能实践者的现实世界解决方案和实操经验。

当大多数人提及大语言模型，他们可能会想到 OpenAI 旗下的某款模型。这些模型不仅规模大，而且功能强大，托管在 OpenAI 的服务器上，并通过网络 API 进行调用。这些基于 API 的模型调用是快速尝试 LLM 的一种方式。

然而，企业也可以选择部署自己的模型。部署或自托管 LLM 是一项具有挑战性的任务，并不像调用 OpenAI 的 API 那样简单。你可能会好奇：既然自托管 LLM 如此复杂，为何还要费心这么做呢？通常，企业选择自托管 LLM 基于以下三大动机：

• 隐私与安全：在自己安全的环境中部署模型（无论是在虚拟私有云还是本地）。

• 提升性能：许多领域的新模型需要自托管，特别是在增强检索生成（RAG）方面。

• 降低大规模部署的成本：虽然基于 API 调用的模型最初看起来可能很便宜，但对于大规模部署，自托管可能更具成本效益。

A16Z 的一份报告揭示了一个趋势：82% 的企业计划自托管模型。面对这一趋势，随之而来的问题是：为什么自托管如此具有挑战性？以下是三个主要原因：

• 模型规模：大语言模型的参数规模大。你可能认为一个 70 亿参数的模型算小的了，但其实不是：它实际上需要消耗 14GB 的 RAM。

• 昂贵的 GPU：GPU 是一种稀缺且昂贵的资源，因此高效利用 GPU 成了一个关键问题。

• 快速变化的领域：这个领域的发展日新月异，要求部署策略必须具备前瞻性，以适应未来的技术演进。

面对这些挑战，以下是七个开发和部署自托管大语言模型应用程序的实用技巧和窍门。

我们发现，团队在将他们的 AI 驱动应用程序推向生产环境时面临重重困难，通常是因为他们直到最后一刻才开始考虑生产阶段的问题。我们建议客户在项目初期就要明确他们的需求，并在此基础上评估在给定约束条件下的最佳实施策略。

具体来说，我们建议客户评估这些事项：

• 延迟要求：需要实时处理还是可以接受批处理？

• 预期负载：服务 10 个还是 10000 个并发用户？

• 硬件可用性：是否有特定的硬件需求，尤其是对于需要本地部署的情况？

一旦这些需求得到明确，团队便能清晰地决定在这些约束条件下最合适的构建方案。

考虑到大多数企业都不具备无限的硬件资源，通常最佳的做法是使用量化版本的模型，而非它们的未量化版本。在 2022 年 12 月发表的论文 《4 位精度：k 位推理伸缩法则》 中，Tim Dettmers 提出了一个观点：在资源规模固定的情况下，通过将更大的模型量化到 4 位，而非使用其全精度版本，几乎总能获得更优的性能。

图 1. 从 125M 到 176B 参数的 OPT 模型在零样本性能方面的位伸缩法则。随着量化精度从 16 位降至 4 位，固定模型位的零样本性能逐渐增强。然而，当量化精度降至 3 位时，这种趋势逆转，表明 4 位精度是最优选择。来源：《4 位精度：k 位推理伸缩法则》。

图 2. 根据硬件资源选择模型

在明确了硬件需求（参见技巧 1）之后，你就可以反向评估哪个模型在量化到 4 位时最符合你的情况。想要找到主流大模型的 4 位量化版本，可以访问 TitanML 在 HuggingFace 的主页。

GPU 的成本较高，因此部署自托管模型似乎是一件成本高昂的事情。然而，通过优化推理过程，部署可以变得更加可行，GPU 的利用率可以显著提高，计算成本也可以大幅降低。有很多种方法可以优化推理，但这里我只提供两个示例，展示它们对 GPU 利用率可能产生的显著影响。

在部署生成式 AI 时，你可以采用各种批处理策略。

最直接但效率低下的方法是完全不使用批处理，这在推理框架中很常见，例如 ollama。这种方法往往会导致 GPU 利用率低下。如果你考虑使用批处理，可以尝试动态批处理：即在处理请求时等待，然后集中分批处理。这种方法会导致较大的 GPU 利用率波动，并不是一个理想的状态。

对于生成式模型来说，最有效的方法是采用持续批处理，它允许新到的请求打断正在进行中的请求，以维持高 GPU 利用率。这正是我们在推理栈（Titan Takeoff）中所采用的策略。通过采用不同的批处理策略，无需对模型本身做出任何改变，就能实现 GPU 利用率大约 5 倍的提升，并带来了更好的用户体验。

图 3. 批处理策略及其 GPU 利用率

另一个能够对推理产生显著性能影响的是多 GPU 部署。当一个模型的规模超出了单个 GPU 的承载能力，需要在多个 GPU 之间进行分摊，就会采用这种部署方式。

假设我们有一个 90GB 的模型，但只有 30GB 的 GPU。这个 GPU 无法单独撑起这个模型，但如果我们对其进行分摊，可以部署在 3 个不同的 GPU 上。我有两种分摊模型的方法。最直接的方式是按层分摊（在 HuggingFace Accelerate 库 中使用）。

然而，这种按层分摊的方法会导致 GPU 在推理过程中有相当长的时间处于空闲状态。分摊模型的一个更好的方法是使用 张量并行——这正是我们在 Titan Takeoff 中所采用的策略。张量并行确保了 GPU 在整个推理过程中都能保持活跃，没有空闲时间。

图 4. 并行策略及其 GPU 利用率

从我提供的两个示例可以看到，通过优化推理和提升 GPU 利用率就能实现非常显著的性能提升。因此，你可以选择自己花时间研究，或者使用已经在这方面投入了大量时间的推理栈。

与以往的数据科学不同，因为大模型的计算成本极高，所以需要集中和整合基础设施。

部署开源模型很难，其难度远超直接使用 OpenAI API。因此，这一任务应该由专门的团队使用专业的工具来完成，而不是让各个机器学习团队自行解决。专门团队可以为公司内部的其他部门提供一个类似于 OpenAI API 的接口，方便他们使用。这样做将带来以下这些好处：

• 由于 GPU 利用率更高，降低了推理成本；

• 开发更简单、更迅速；

• 更高的应用程序伸缩性。

因此，对于团队来说，使用他们信任的推理栈至关重要，这个推理栈不仅支持 LoRA 适配器，还能非常高效地利用 GPU 资源。

图 5. 在未整合与整合的基础设施上部署 LLM

这个建议不言而喻，但鉴于我们在人工智能领域，尤其是开源领域所见证的快速发展，我们应该在构建系统时预设一个前提：即我们今天所使用的模型与 12 个月后我们将要构建的模型相比可能会显得相对落后。

图 6. 2023 年发布的模型。来源：Everypixel

那么，这对你应该采取的构建策略意味着什么？这意味着你应该追求高度的抽象化，并且应该使用那些将大模型视为可以轻松互换的构建块的工具和框架来构建你的系统。

我们注意到客户对 GPU 的定价表示担忧。他们意识到按小时计费的 GPU 比 CPU 要贵得多。然而，考虑到 GPU 在性能和效率方面相较于 CPU 的显著优势，它们无疑是生成式 AI 工作负载的首选。

生成式 AI 模型需要巨大的算力来处理大量数据，并生成文本、图像或代码。GPU 专为处理这类复杂且数据密集型的任务而设计，因为它们拥有成千上万的核心，能够并行执行计算任务。

另一方面，CPU 更适合于那些需要顺序处理的任务。因此，尽管 GPU 价格更高，但每个 Token 的成本实际上比 CPU 要低得多。因此，如果你能够实现更高的 GPU 利用率，应该总是优先选择使用 GPU 来处理 AI 工作负载。

大型模型虽然令人印象深刻，但很多时候，小型模型已经足以满足许多场景，并且更易于部署。你可以考虑使用非生成式模型或更小的模型，例如 Llama3-8B。

部署大模型确实是一项挑战，但也值得我们去做。自托管在隐私保护、性能提升和成本效率方面提供了显著的优势，尽管存在一些障碍，但对于许多企业而言仍然是一个明智的选择。

从一开始就明确你的部署边界，使用量化模型，并专注于优化推理。这些策略有助于你实现更高的 GPU 利用率并降低成本。集中整合基础设施，并随着技术的演进更新模型，这将使你的部署既可扩展又具备强大的适应性。始终优先选择 GPU，并在适当时考虑使用小模型。

人工智能领域的发展日新月异，保持敏捷和信息灵通至关重要。我希望这些技巧能够帮助你保持领先地位，并充分利用自托管大模型。

通过遵循这些实践，你将能够构建出不仅高效、成本效益显著，而且可扩展、具备未来适应性的 AI 应用。这样，你的组织就能够充分利用大模型技术的强大潜力。