为什么DeepSeek在规模化部署时成本低廉，但在本地运行时却成本高昂？

图0：为什么DeepSeek在规模化部署时成本低廉，但在本地运行时却成本高昂？

为什么DeepSeek-V3在规模化部署时被认为速度快且成本低廉，但在本地运行时却速度过慢且成本高昂？为什么有些AI模型在初始响应时速度较慢，但一旦运行起来却速度较快？

AI推理服务提供商常提及吞吐量与延迟之间的根本权衡：对于任何给定模型，您只能在高吞吐量高延迟或低吞吐量低延迟之间做出选择。事实上，某些模型天生对GPU效率极低，因此在实际应用中必须以高延迟方式运行才能实现可用的吞吐量（例如DeepSeek-V3）。

这种权衡来自推理提供商为模型选择的批处理大小：不是在单个请求中批处理推理1，而是对数十或数百个并发用户请求进行批处理推理。基于转换器的大语言模型（LLMs）的一个独特特征是，同时计算一批完成几乎与计算一个完成一样快。为什么呢？

什么是批处理推理？

元素周期表 GPU擅长执行大规模矩阵乘法（GEMM，即“通用矩阵乘法”）。假设你有一个单一令牌需要通过模型处理（即与所有权重矩阵相乘——其他架构细节无关）。你将其表示为与模型维度（或隐藏层大小）匹配的向量（即1乘以模型权重矩阵的宽度），并进行乘法运算。这相当于1次GEMM。但如果你想批量处理10个令牌，这仍然只相当于1次GEMM，因为你可以将令牌堆叠成一个矩阵（10倍于模型维度）。这比执行10次稍小的GEMM要快得多。因此，推理服务器实现可能类似于以下结构：

一个请求带着提示词进来
该提示词经过预填充（通过注意力机制处理——我们稍后会看到如何批量处理2），形成一个键值缓存和一个令牌大小的矩阵（1 × 模型大小），最终将成为预测的令牌3
该令牌大小的矩阵进入一个队列
GPU服务器从队列中提取批次（例如128个），将其堆叠成一个128×模型大小的矩阵，并通过前馈模型权重进行乘法运算
最终结果被分割为128个独立的令牌
其中对应原始请求的令牌被流式传输回用户
假设该令牌不是序列结束令牌，则返回步骤 2 继续生成响应中的下一个令牌

需注意，服务器会决定批次大小。这是吞吐量与延迟之间的权衡。如果不进行批处理而逐个处理令牌，用户无需在队列中等待（如上文步骤3所示），因此延迟较低（假设拥有足够的GPU）。然而，如果进行大量批处理，延迟会升高，因为用户需等待批处理大小填满，但吞吐量会显著提升，因为GPU被更高效地利用。

为什么GPU在一次乘法大矩阵比多次乘法小矩阵更快？有两个原因。首先，向GPU发出每个命令涉及一些开销，而一次大乘法可以使用单个命令启动。其次，每个新的GPU命令涉及从内存中获取权重，对于大型权重来说这可能很昂贵。如果运行大量小型GEMM操作，可能会导致大部分时间都用于在内存中传输权重，而非实际计算。

为什么有些模型针对高批量大小进行优化？

通常，推理服务器会设置一个“收集窗口”，用户请求在此期间进入并排队。聊天服务器通常目标是5-10毫秒，但高批量后端可能扩展至200毫秒。如果新请求在窗口开始时到达，它可能需要等待整个窗口时长才能被处理⁴。当窗口关闭时，所有队列中的请求会被批量处理（即所有1×模型尺寸的矩阵被拼接成一个128×模型尺寸的矩阵），然后该批次被发送至管道。这种批量处理有时被称为“ tick”。

如上所述，您可以使用任何批次大小运行任何模型。批处理过程本身并不会排除某些类型的模型。然而，有可能构建一个如此不适合GPU的模型，以至于它实际上需要批处理才能实用。

为什么专家混合模型需要更大的批量大小

例如，考虑一个专家混合模型（如DeepSeek-V3或据称的原始GPT-4）。你可以通过训练它拥有数百个“专家”来获得一个强大的模型：这些专家是独立的前馈权重块，其中一个路由层会从中选择一个子集用于每个令牌。但这种模型在GPU上效率极低。原因显而易见：GPU倾向于执行少量大型矩阵乘法，但若专家数量过多，就会被迫进行大量小型乘法运算。除非采用批量推理，否则这将导致吞吐量低下。

让我们分析一下“收集窗口”为5ms和200ms时，大型混合专家模型会如何表现。假设你在5ms窗口内收集了十个用户请求。如果专家数量众多，部分专家可能仅对一两个令牌进行处理（即每个专家的批量大小远低于窗口内收集的总请求数）。然而，如果你等待200毫秒并收集4000个用户请求，你更有可能让所有专家达到饱和状态。虽然会增加一些延迟，但你确保了GEMMs足够大，且GPU始终以最大容量运行。

为什么大型管道需要高批量大小以避免管道气泡

对于大型模型而言，保持GPU持续活跃本身就是一项挑战。大型模型通常包含大量Transformer层，即构成前馈网络的数百个权重矩阵。在此场景下实现快速推理的唯一方法是通过管道化处理这些层：让一个GPU处理前十层，另一个GPU处理接下来的十层，依此类推。否则，您将无法将所有权重放入单个 GPU 的内存中，因此将花费大量时间在内存中交换权重，最终导致速度非常慢。在推理过程中，每个令牌（通常以“微批量”的形式，每个批次包含几十个令牌）会依次通过这些 GPU 组成的管道。

管道的效率取决于层数和集合窗口的大小。在处理窗口中的令牌时，每个“时钟周期”的开始阶段会出现部分闲置GPU（因为后续层的GPU尚未有任务可处理），结束阶段也会出现更多闲置GPU（当队列中无令牌时，早期层的GPU需等待下一个“时钟周期”）。这些空闲期有时被称为“预热”和“排空”。如果您使用多个小窗口，那么在预热和排空阶段消耗的GPU时间将比使用较少的大窗口更多。因此，通过选择窗口大小，您实际上是在吞吐量和延迟之间进行权衡。

如果你有大量层且收集窗口非常短，有时可能会出现待处理令牌数量少于层数的情况。这被称为“管道气泡”——实际上“排水”阶段比平时更早开始。你无法消除预热和排水（由于下面讨论的原因，推理必须在顺序“时钟周期”中运行），但你可以通过将收集窗口设置得足够长来消除管道气泡。管道气泡对模型吞吐量的影响极为严重，因此推理提供商总是将窗口设置得足够宽以避免它们。这会为具有大量层的模型带来明显的延迟。

难道不能让队列一直保持满载状态吗？

为什么推理提供商不能通过保持GPU队列中始终充满令牌来完全消除预热和清空过程？换句话说，难道不能完全取消计时器，只需让令牌微批次持续流动吗？当然，每个用户的推理必须是顺序进行的（因为在当前令牌处理完成前无法开始生成下一个令牌），但大型推理提供商应有足够的并发流量来保持队列中始终充满独立的用户请求。

我得承认，我很难理解为什么这在理论上不可能实现。就我所知，实际障碍在于注意力步骤的批处理方式：如果你想批处理注意力GEMMs，它们必须具有相同的形状（即序列中具有相同数量的先前令牌）。因此，你必须同时运行具有相同形状的组，而不是仅仅维护一个队列。在这方面至少有一些公开的研究，但我不会惊讶于还有更多我未见过的巧妙方法来实现这一点。

另一个想法：如果你需要时钟信号来执行注意力步骤，为什么不直接使用基于时钟的注意力推理系统，同时为全连接层（FFN）使用更高效的连续系统呢？据我所知，原因在于内存开销：

由于注意力输出需要用于FFN，你需要在内存中为其预留空间，等待其在FFN队列中获得插槽，这很快就会变得过于昂贵。
现代推理堆栈能够将注意力与FFN步骤合并为单个“操作”中的几个大型GEMM操作。如果你在不同GPU上执行这些操作，就需要运行不同操作并频繁在内存中传输权重。

总结

- GPU 在处理大型 GEMM 操作时效率最高，因此将大量令牌堆叠到单个矩阵乘法中，其令牌吞吐量远高于逐个处理令牌
- 在解码过程中，注意力只能对同一步的令牌进行批处理，迫使调度器以短暂的“时钟周期”运行。您在单个“时钟周期”中打包的令牌数量（即等待收集令牌的时间长度）即为批处理大小
  - 这些令牌来自不同用户。你不能批量处理同一用户的令牌，因为生成下一个令牌需要前一个令牌，因此批量处理需要来自不同用户的较高流量
- 更大的批量会增加延迟，因为用户令牌可能需要等待长达200毫秒才能填满批量并运行，但它们通过允许在前向传播步骤中使用更大（因此更高效）的GEMM来提升吞吐量
- 具有多层结构的模型（如长管道模型）需要更大的批次大小以避免管道气泡（通过确保每个时钟周期包含的批次数量多于管道步骤数量）
- 混合专家模型需要以高延迟方式提供服务才能高效运行：每个专家仅处理分配给它的令牌，因此需要更大的全局批次大小以确保每个专家保持忙碌。
- 推理提供商选择一个批次大小/窗口，以消除管道气泡并使专家饱和。较大的批次大小可以提高吞吐量，但会增加延迟，因为令牌需要等待填满一个时钟周期
- 某些模型（如DeepSeek的模型）作为具有多层的混合专家模型，因此需要较大的批次大小和高延迟，否则吞吐量会急剧下降。这就是为什么人们常说无法轻松在个人设备上运行DeepSeek：因为单个用户每次只运行一个推理任务时，其效率/吞吐量会非常低。
- OpenAI和Anthropic的模型响应迅速，这可能意味着：
  - 它们的模型具有更高效的架构（非MoE，层数更少），或
  - OpenAI/Anthropic在提供推理服务时采用了非常巧妙的技巧，或
  - 它们为GPU支付了远超实际需求的巨额费用
编辑：这篇文章引发了大量评论。我有点后悔没有给这篇文章起一个不同的标题——它其实不是关于在自己的电脑上运行模型。而是关于为个人使用运行模型，假设你拥有所有GPU（即批处理/吞吐量权衡）。
1 变压器模型的一个常见优势是，它们可以在单个用户请求内进行批量预填充。当你向它们传递一个长提示时，它们可以一次性处理整个提示，这是因为注意力机制的工作方式。之前的循环模型必须逐个令牌处理，这要慢得多（因为涉及更多的GEMM操作）。这与我在本文中讨论的批处理类型无关。我讨论的是如何在预填充完成后，高效地在多个不同用户请求之间批量进行推理。2 这也可以进行批处理，只要你批处理的注意力操作具有相同数量的令牌序列（即每个预测第四个令牌的序列都可以批处理在一起）。否则，KV缓存矩阵的大小不同，因此无法轻松将它们合并到一个批次中。稍后会详细讨论这一点。3 严格来说，生成的并非令牌本身，而是“logits”（即所有可能令牌的概率分布）。为了简化表述，本文及后续内容中将统一使用“令牌”一词。4 需要注意的是，在实际应用中，现代推理堆栈会使用“连续批处理”，即批次一满就会立即发送，而非等待固定时间窗口的整个长度。然而，推理仍以批次形式进行，因此吞吐量与延迟之间的核心权衡关系保持不变。

本文文字及图片出自 Why DeepSeek is cheap at scale but expensive to run locally

阅读余下内容

DeepSeek 人工智能| 2025-06-02