大模型工作负载的真相：为什么“一刀切”的API定价正在伤害你的业务

我们常常认为，有些任务生来就比其他任务更复杂、要求更高。但在大语言模型（LLM）的应用世界里，这个简单的道理却常常被忽视。如今，大多数公司通过统一的API来获取AI能力，这些API用“按Token付费”这种看似平坦的定价，将不同工作负载背后迥异的成本和工程权衡彻底隐藏了起来。

然而，真相总会浮出水面。模型API称霸的时代正在终结。这要归功于像DeepSeek和阿里通义千问这样的优秀开源模型，它们正在侵蚀OpenAI等闭源模型API的优势；也要归功于如vLLM和SGLang等出色的开源推理引擎，它们正在瓦解那些由闭源推理引擎驱动的开放模型API的护城河。

想要抓住这次技术变革机遇的工程师们，必须更深入地理解自己的工作负载，才能正确地设计和优化他们的系统。

工作负载的三国演义：离线、在线与半在线

在更成熟的数据库领域，事务处理（OLTP，例如购物车）和分析处理（OLAP，例如年度报告）之间有着著名的分野。在这两者之间，则是兼具两者特性的混合工作负载。

类似的三分法帮助我们梳理了LLM的工作负载版图：

1. 「离线（或分析型）工作负载」：以批处理模式运行，异步地将结果写入数据存储。它「首要追求的是吞吐量」。
2. 「在线（或交互型）工作负载」：以流模式运行，与人类进行同步交互。它「对低延迟有着苛刻的要求」。
3. 「半在线（或突发型）工作负载」：在批量流上运行，与其他实时计算机系统通信。它「要求基础设施具备极高的灵活性」。

我们的核心建议如下：

• 「对于离线工作负载」，我们建议使用vLLM，通过异步RPC调用按需自动伸缩的计算资源。
• 「对于在线工作负载」，我们建议使用SGLang，配合充足的张量并行以及基于EAGLE-3推测解码技术，并通过低开销、前缀感知的HTTP代理访问部署在边缘的Hopper/Blackwell架构GPU。
• 「对于半在线工作负载」，我们建议根据情况选用上述任一引擎，并配合能够快速自动伸缩、且每个副本都能处理可变负载的按需计算资源。

接下来，我们将结合在我们平台上运行的真实应用案例和示例代码，深入解读并证明这些建议的合理性。

离线工作负载：吞吐量至上

想象一下这些场景：

• 一个数据增强服务，需要将LLM应用于数据集的每一行，以更新和扩充整个数据集。
• 一家领先的视频转录服务，需要为海量的录音通话生成LLM摘要，以便后续搜索和检索。

这些系统都是「离线」的：它们产生的信息是为了长期存储到其他计算机系统（如文件系统或数据库）中。任务以包含大量LLM请求的批量“作业”形式提交。出于成本考虑，整个作业应尽快完成，但其中任何一个单独的请求都不需要立即响应。作业的规模揭示了巨大的并行性潜力，从而实现规模经济。

离线系统通常更容易架构——计算机系统最初就是作为离线批处理机器而诞生的，这并非偶然。但它们依然面临挑战。

核心挑战：如何最大化每美元的吞吐量？

离线批处理工作负载的核心挑战在于，通过利用批处理内的任务并行性，在控制成本的同时最大化吞吐量。

这本质上是个好消息。因为运行LLM推理最流行、最易得的硬件——GPU，正是为「最大化吞吐量」而设计的。从每个时钟周期的上下文切换、大型矩阵乘法单元，到其任务并行的编程模型，都使得编写能够充分利用计算资源的推理内核相对容易。而且，开源且免费的内核已经足够出色。此外，LLM和其他神经网络的训练本身就是一种离线、批处理的工作负载，历史上，训练工作负载一直得到最多、最快的关注（例如当新硬件上市时）。

但内核并不是利用离线工作负载并行性所需的唯一代码。一个显著的例子是，批次必须由活跃和等待中的任务构建。单个LLM推理任务可以分为两个阶段：「预填充」和「解码」。预填充工作还可以进一步分块。通过精心设计，所有这些不同类型的工作都可以为批次中不同的任务进行协同调度。

通过混合批处理，计算强度较低的解码工作（细线）可以“搭便车”于计算强度更高的预填充工作（粗线）之上。不同颜色代表不同任务。

目前，vLLM推理引擎对这些调度优化有更好的支持。因此，我们当前推荐将其用于对吞吐量敏感的离线工作负载。

离线工作负载的实现要点

为了在离线应用中优化（每美元的）吞吐量，我们做出以下选择：

• 「推理引擎」：在vLLM上运行，启用异步调度和分块预填充。
• 「请求方式」：在每个请求中发送大批量数据，向引擎暴露最大的并行性。使用离线接口（如vLLM Python SDK中的LLM抽象）比面向在线服务的HTTP服务器接口更容易实现这一点。
• 「资源利用」：将每个副本的GPU数量限制在足以运行大型批次、以饱和GPU计算资源的最小值。多余的GPU容量应用于运行更多副本，而非增加单个副本的规模。

常见问题（FAQ）

「Q：既然是离线任务，慢一点也没关系，为什么还要如此关注吞吐量和成本？」
A：因为时间和资源就是金钱。一个需要处理100万条记录的任务，如果系统吞吐量高一倍，所需的GPU小时数就减少一半，直接降低成本。在规模化运营中，这种效率差异会转化为巨大的运营开支差距。

「Q：我直接用开源的vLLM本地部署不就行了吗？」
A：可以，但这要求你自行管理GPU集群、处理任务队列、监控和容错。云平台提供的价值在于将这些工程复杂度抽象掉，提供弹性的、按需使用的资源，并且通过多租户聚合平滑成本，让你真正只为计算量付费。

未来展望

随着模型可靠性的提高和使用日益普及，我们预计越来越多的批处理工作负载将在许多企业的后台安静运行。就像数据分析工作一样，最初是像人口普查那样罕见而庞大的工程，如今已成为常规且必备的能力。

我们观察到一个有趣的GPU定价模式：每美元的浮点运算次数大致恒定。这意味着，对于更关心「每美元吞吐量」而非「每秒吞吐量」的作业来说，那些更容易获得（本地部署）或供应量更大（云平台）的旧款GPU，可能更具性价比。

在线工作负载：延迟是头号敌人

思考这些场景：

• 一个语音助手需要参与人类用户的电话通话，实时提供支持。
• 一款智能代码编辑器需要在程序员思考下一步代码的短暂间隙里，提供“智能”自动补全。

这些系统是「在线」的：人类用户正在与系统交互，他们期望的响应速度必须匹配人类反应时间，通常在几百毫秒以内。用户通过多次交互，形成了多轮对话上下文。

构建在线系统极具挑战。它们对性能极度敏感，而性能问题会消融抽象层，耦合本应解耦的模块。但只要你解决了随之而来的挑战，它们是可以被构建出来的。

挑战一：规避主机开销

在线工作负载的首要挑战是系统只有几百毫秒的时间来响应。这意味着，使用Python这类解释型语言带来的性能损耗开始变得至关重要。主流的LLM推理引擎大多用Python编写（以便快速开发），因此需要精心架构和实现，以避免CPU上的工作阻塞GPU上的工作——即产生“主机开销”。根据我们的经验，SGLang推理引擎在这方面表现更优，其主机开销通常更低。

挑战二：降低通信开销

再说一遍：系统只有几百毫秒的时间来响应。对于LLM推理服务（而非本地应用），客户端与系统之间的通信在这个时间尺度上会引入显著的延迟。网络虽以光速传播，但对于地球上的客户端访问单一地理位置的系统来说，仍然意味着数十甚至上百毫秒的延迟。

解决方案是将路由代理和加速器资源部署到“边缘”，即靠近客户端的数据中心。除了技术问题，市场条件也可能带来挑战，因为并非所有云提供商在所有区域都提供所有类型的GPU。解决之道在于跨云聚合资源，支持区域化服务部署。

挑战三：处理多轮对话

在线工作负载的交互性不仅体现在延迟要求上，也体现在请求模式上。用户会对系统的响应做出回应，系统必须再次响应。

与HTTP这种（名义上）无状态的协议不同，高效的多轮LLM推理是有状态的。客户端通常在请求中提供完整的对话历史，但基于Transformer架构的现代模型，其计算需求随对话长度呈平方级增长。为了将其降至线性增长，需要存储线性数量的模型激活值，即“键值缓存”。

解决方案是根据用于填充缓存的信息（即请求的前缀）来路由请求到LLM推理副本。这种“前缀感知”路由可以简单到基于会话的粘性连接，也可以涉及对请求和缓存内容的深度检查。

挑战四：应对内存墙瓶颈

在带有KV缓存的LLM推理中，瓶颈操作的「算术强度」很低，这意味着推理受限于「内存带宽」。

直观理解是，每个请求每次前向传播只能生成一个或几个token，但你必须将所有模型权重（通常是数十亿）加载到寄存器中。对于每个用户，这些权重大约只进行了一次加法和一次乘法运算，这与GPU成百上千的“算术带宽”极不匹配，大量算力被浪费。此外，即使在线服务的延迟要求和请求负载允许跨请求批处理，但由于每个请求的前缀通常不同，因此必须为每个请求加载KV缓存的不同部分。缓存内容起初相对于模型权重可忽略不计，但会随序列长度增长。

以上讨论侧重于吞吐量。而在以延迟为首要关切的在线工作负载中，情况更糟。因为在单个加速器上运行一次前向传播需要加载数十亿的模型权重，而内存带宽是以每秒万亿字节来衡量的，这必然导致前向传播需要数毫秒。单个用户无法获得比这更低的单token延迟。自回归（即顺序）生成会叠加这些延迟，迅速吞噬有限的延迟预算——这是阿姆达尔定律又一个令人心碎的实例。

「解决方案A：增加内存带宽」

• 「硬件层面」：使用H100、B200等最新GPU，它们的内存带宽相比前代有显著提升。
• 「软件层面」：使用多个GPU增加总带宽，并通过「张量并行」等技术，利用矩阵乘法固有的并行性，将计算拆分到不同的GPU上协同工作。这通常需要在GPU后端通过NVLink等高带宽、低延迟的内部网络完成。

「解决方案B：减少内存需求（通常以模型质量为代价）」

• 「量化」：降低模型权重的精度，例如使用Hopper GPU原生支持的8位（FP8）或Blackwell GPU支持的4位（FP4）浮点数。对于约700亿参数以上的模型，4位量化效果很好。对于小至10亿参数的模型，8位量化通常能在保持质量的同时获得性能收益。
• 「模型架构选择」：现代架构中前馈层的「混合专家」结构，其目的正是为了减少内存带宽需求。比较模型时，应关注「活跃参数」而不仅仅是总参数。

挑战五：“欺骗”光速

最终，内存墙无法逃避，延迟无法进一步降低。系统达到了硬件的“光速”极限。

光速无法突破，但可以“欺骗”。

关键技巧是「推测解码」。它利用了朴素、单token自回归推理中闲置的「算术带宽」。

具体来说，我们使用一个更简单的语言建模系统（推测器）来生成多个连续的输出token，然后让更大的目标系统并行地判断这些token。因为推理受限于内存带宽，所以有额外的算力来运行推测器。由于大模型已经会输出其输入中每个token的概率，引擎可以确保输出保持不变。

这个想法在LLM推理领域已不新鲜，但直到最近，使用更复杂的推测模型还因操作困难而受限。「EAGLE-3推测器训练方法」改变了这一点。它不仅产生了在开源引擎中支持良好的简单推测器，而且达到了非常高的质量（以接受长度为衡量标准）。我们发现，仅通过开源推理引擎添加EAGLE-3，就足以匹配使用专有推理堆栈的模型供应商所达到的性能。目前，SGLang对推测解码的支持更好，这是我们推荐其用于低延迟应用的另一个原因。

在线工作负载的实现要点

为了在在线应用中优化低延迟，我们做出以下选择：

• 「推理引擎」：在SGLang上运行，以减少主机开销并充分利用推测解码。
• 「量化」：在H100/H200 GPU上使用FP8量化，以获得更小的内存占用和更快的预填充/解码内核。
• 「并行」：应用超出内存容量所需的额外张量并行，以降低内存读取延迟。
• 「推测解码」：使用现成的或自定义训练的EAGLE-3推测器模型。
• 「部署」：创建区域化的、超低开销的Web服务器，并启用基于会话的路由。

未来展望

由于对聊天机器人的巨额投资和热情，这类工作负载已经获得了大量的工程投入，其未来也相对清晰。

首先，我们预计在不久的将来，会有更多“欺骗光速”的方法变得重要，特别是那些牺牲少量性能换取大量速度的「有损优化」。例如：近似的KV缓存、层跳过、剪枝、KV缓存的有损压缩、有损推测等。这些技术中的许多在扩散模型领域已经相当成熟。

对于某些工作负载，像推测解码这样的完全无损性能改进可能不足以达到目标延迟。正确的有损性能改进方案因工作负载而异。

其次，我们预计这些工作负载将越来越多地转移到更专业的硬件上。Nvidia正在大力投资紧密互联的系统，谷歌也在构建具有类似架构的大型TPU系统。要取得更大突破，需要在硅层面进行更深入的创新，比如为特定模型架构设计专用集成电路。

然而，我们预计在线/聊天工作负载的「相对重要性」会随着时间推移而下降。当前的兴趣是由LLM的第一个“杀手级应用”——OpenAI的ChatGPT驱动的。但随着技术的发展，另一个“杀手级应用”正在浮现——「长时运行的背景智能体」，它们拥有机器的耐心，而非人类的急躁。这些应用将产生截然不同的工作负载，也就是我们接下来要讨论的。

半在线工作负载：灵活性是生命线

想象这些情景：

• 一个文档处理平台的用户，有时上传单份表格即时查阅，有时则丢进整个公司的文档库进行批量处理。
• 一家AI新闻分析机构，需要在突发新闻出现时，几分钟内迅速扩展其新闻分析智能体，爬取多种来源并生成综合报告；同时也需要在更长周期（如每天）生成一份“日报”。

这些系统是「半在线」的：有时它们需要将结果返回给等待中的人类；有时则将结果传递给流水线中的另一个计算机系统（可能是另一个智能体）。即使直接服务人类用户，其交互也不那么紧密。它们的工作负载具有「突发性」——有时负载会在几分钟或十几分钟内飙升至基准值的数百倍。

核心挑战：驯服高峰与均值之比

这种高“峰值-均值比”给服务此类工作负载的系统带来了成本困境。简而言之，成本通常由满足「峰值」需求的能力驱动，而收入则由服务「平均」需求产生。如果按照峰值需求静态配置资源，在负载低谷时资源将被大量闲置，导致成本效益极低。

系统成本与为峰值需求分配的资源成正比（阴影区域）。收入与已实现的资源需求成正比（曲线下方面积）。当峰值需求远高于平均值时，缺乏灵活资源分配的系统会变得不经济。

解决方案是「聚合与多租户」。即在共享硬件上服务多种不同的工作负载，这些负载不相关的峰值会聚合成为对该硬件平滑的时间线需求。“峰值-均值比”从而被降低。

在多租户系统中，峰值需求被降低，从而削减了成本。在最坏情况下，一组单租户系统的总成本可能接近整个多租户系统的成本。

关键优化：将冷启动从分钟级降至秒级

多租户计算机系统有其缺点，包括增加了「冷启动延迟」。即使从资源缓冲池中分配了服务资源，将这些资源配置好以开始处理请求也需要时间：容器或虚拟机必须启动，然后推理引擎必须初始化。

• 「容器启动慢」：对于大型容器镜像，启动时间可能长达数分钟。优化方法包括混合使用预先获取可能用到的文件和懒加载不太可能用到的文件。
• 「引擎初始化慢」：例如，Torch JIT编译器虽然能为推理过程带来巨大加速，但其编译过程可能需要几分钟，在此期间推理服务器副本无法处理请求。

我们的解决方案是「GPU内存快照」。在推理服务器副本准备好处理请求之前，我们将程序状态转储到文件系统。当启动新副本时，直接从这个快照文件加载，跳过了Torch JIT编译等计算过程，并将大量小文件I/O合并为一次大I/O，更适配存储系统。

内存快照可以将推理服务器启动时间缩短一个数量级，只需从快照存储中“恢复”服务器。快速的扩容能力改善了在突发负载下的响应时间。

半在线工作负载的实现要点

为了在半在线应用中优化灵活伸缩性，我们做出以下选择：

• 「资源策略」：使用能够快速启动、自动伸缩的GPU资源，以经济的方式应对可变负载。
• 「硬件选择」：在按需和抢占式B200 GPU相对稀缺的情况下，优先考虑H100或H200，这进一步指向使用FP8量化模型。
• 「部署与伸缩」：使用Web服务器部署模式，并设置自动伸缩策略以吸收小的负载突发（例如，通过设置max_inputs高于target_inputs）。
• 「引擎选择」：在vLLM和SGLang之间选择，取决于模型可用性等其他因素。
• 「性能加速」：使用GPU内存快照来加速服务器启动，特别是当你的引擎需要缓慢的JIT编译步骤时。

常见问题（FAQ）

「Q：我的应用流量时高时低，应该按峰值配置资源还是按平均值？」
A：都不应该静态配置。你应该使用具备快速自动伸缩能力的云原生服务。它会在负载上升时自动增加副本，在负载下降时减少副本，确保你始终接近“按实际使用量付费”的理想状态。

「Q：冷启动对我的用户体验影响大吗？」
A：对于突发流量，如果新副本启动需要几分钟，那么在扩容期间，用户可能会遭遇明显的延迟上升或服务不可用。这就是为什么将冷启动从分钟级优化到秒级至关重要，它直接关系到服务的响应能力和用户体验。

未来展望

我们预计，随着该领域的成熟，会出现更多此类半在线应用——离线和在线是显而易见的两种模式，但还有大量兼具两者特征的中间任务。

特别是，随着由「长时运行智能体」完成的工作越来越多（它们拥有计算机系统的耐心，而非人类的急躁），这类工作负载的重要性将日益凸显。人类用户愿意为减少短暂等待支付高额溢价，但对于被设计来完成长时任务的智能体或智能体系统，工程师们通常会倾向于相反的权衡。我们期待随着开发者和工程师们不断发现和扩展这些场景，为更多此类工作负载提供支持。

接下来该做什么？

尽管大语言模型时代已开始数年，但由于闭源模型公司和闭源推理引擎在能力上取得的先发优势，我们仍处于「LLM工程时代」的早期。

但正如在其他领域一样，底层技术正在足够地普及，以至于逐渐成为商品。随之而来的定制化和控制权优势，使得自建LLM推理服务的天平越来越向其倾斜。

这需要额外的工程努力，以及社区共同努力来传播知识、提升技能、生产开源模型和开源软件。如果你对大规模部署自己的推理服务感兴趣，现在正是深入理解你的工作负载，并开始规划符合自身需求架构的最佳时机。从区分你的任务是离线、在线还是半在线开始，选择合适的工具和策略，一步步构建起高效、经济且可控的AI能力。