第一性原理视角下的MoE推理的经济学分析

随着DeepSeek R1、Kimi K2和DeepSeek V3.1混合专家（MoE）模型的相继发布，它们已成为智能前沿领域大语言模型（LLM）的领先架构。由于其庞大的规模（1万亿参数及以上）和稀疏计算模式（每个token仅激活部分参数而非整个模型），MoE式LLM对推理工作负载提出了重大挑战，显著改变了底层的推理经济学。随着消费者对AI模型的需求不断增长，以及AGI公司生成数万亿token合成数据的内部需求，"每token成本"成为决定利润率和内部强化学习（RL）训练部署所需资本支出成本的关键因素。

本分析从硬件限制和成本角度审视MoE架构。关键瓶颈——、内存带宽和节点间连接速度——直接影响端到端性能和用户扩展潜力。在此基础上，我们开发了大规模模型服务的理论成本模型，比较DeepSeek V3.1和Kimi K2，并展示硬件成本如何塑造LLM推理提供商的商业模式。

我们使用这一世界模型将token转化为美元——展示如何经济高效地大规模向消费者提供这些模型，以及如何低成本地用于合成数据生成。我们认为这是一个目前被忽视的市场机会，也是NeoClouds的潜在增长引擎。最后，我们直面房间里的大象——这些模型的消耗量惊人地低。尽管美元/性能比出色，但全球开源模型的消耗量仍小得惊人，表明推理提供商可能存在供过于求，且用户感受到的能力差距并未在基准测试中充分体现。

本文其余部分安排如下。我们首先详细研究DeepSeek的架构，涵盖多头部潜在注意力（MLA）、专家路由和专家并行（EP）。基于DeepSeek已发布的优化（其中许多在SGLang中实现），我们开发了适用于不同硬件规格的理论性能模型。然后，我们根据实际性能数据验证该模型，并利用它推导出不同部署配置的每token定价。

对于寻求推理经济学简明概述的读者，我们建议直接阅读“硬件考量与利润率”部分，必要时再返回查看DeepSeek V3.1的架构细节和理论模型公式作为参考材料。

“DeepSeek MoE架构”、“推理优化技术”和“吞吐量：理论与实践”部分基于作者在Aleph Alpha的工作。我们发布了内部用于估算硬件需求的数字和方法，以及通过在多节点设置上运行DeepSeek V3.1实验观察到的数字。该理论模型首次出现在Aleph Alpha博客上。

Introduction

2025年1月，DeepSeek发布其R1推理模型，在全球金融市场引发所谓的“DeepSeek冲击”——西方主要科技公司，尤其是NVIDIA（见图1），其市值遭受了巨大（尽管短暂）的损失。虽然无法确定具体是什么吓到了投资者，但人们普遍认为，根本原因是意识到训练原始DeepSeek V3的成本效率之高，论文中报告的数字仅为560万美元，比西方各实验室报告的数字低几个数量级。

比微不足道的训练预算更让行业内部人士瞩目的是DeepSeek API提供的巨大成本优势。以每百万输出token仅2.1美元的价格，它提供了超过27倍的成本优势（见图2），同时几乎匹配O1-preview的基准性能（当时领先的推理模型）。

DeepSeek团队在模型和训练细节方面前所未有地开放，与本分析最相关的是其推理基础设施细节。在开源周期间，他们发布了高效的多头部潜在注意力（MLA）内核、专家并行（EP）通信库，并公布了推理堆栈和设置的细节，解释了优化技术并发布了理论收入数据（见图3）。

要理解DeepSeek如何实现如此显著的成本优势，需要考察AI推理的底层商业模式。引用Semianalysis的话：

The modern factory is an AI token factory. Raw Silicon, electricity, and water comes into a Datacenter and what comes out is intelligence (in the form of tokens).

现代工厂是一个AI token工厂。原始硅、电力和水进入数据中心，产出的是智能（以token形式）。

“AI token工厂”的商业模式很简单。与任何工厂一样，业主希望将固定设备成本分摊到尽可能多的用户身上。在AI推理中，这一固定成本是运行GPU的每小时费用，提供商通过每小时生成尽可能多的token来最大化效率。生成的token越多，每token成本越低——从而实现更便宜的定价或更高的利润率。这创造了一种经典的经济模型，激励规模经济：必须分摊到尽可能多用户身上的大量固定成本（GPU服务器）。

在本文中，我们开发了一个全面的成本模型来回答一个基本问题：生成一个DeepSeek V3.1 token的实际成本是多少？哪些因素会影响这个数字？我们旨在建立一个理论成本模型，使我们能够根据硬件规格（、内存带宽和互连）和工作负载配置文件（批大小和输入/输出token数量）估算最终吞吐量。我们希望这将帮助您建立更准确的主题世界模型，并就硬件投资和部署策略做出明智决策。我们将使用该理论模型为不同特性的部署（延迟/速度/成本权衡）提出最佳硬件设置。

本文面向经验丰富的读者。我们强烈建议您首先阅读并理解《LLM推理经济学》的核心信息。

https://zhuanlan.zhihu.com/p/1914027039675126945

在开始阅读本文之前，您应熟悉以下主题：什么是，计算/内存受限的含义，什么是缓存以及如何计算其内存占用，以及预填充和解码阶段是什么。我们假设读者熟悉这些主题，并且我们坚信，如果没有这些背景知识，本文中的主题可能难以理解。

DeepSeek V3.1和Kimi K2是混合专家风格模型的两个突出例子。理解它们的成本优势需要考察MoE经济学与传统密集模型的区别。MoE推理的关键挑战在于，与Llama3等密集模型不同，每个处理的token仅激活部分参数，而非整个模型。正如我们在之前的文本中了解到的，解码（或逐token）阶段主要受内存限制，这意味着运行模型的大部分执行时间和成本都来自从全局内存加载模型参数的时间。密集模型的这一特性自然激励积累尽可能大的批，并在尽可能多的请求之间分摊加载模型参数的成本，即实现某种规模经济——多个用户共享固定成本。

对于MoE来说，这变得更加困难。在解码阶段，批中的每个token在每一层仅激活一小部分参数。这意味着每个请求需要加载模型的不同部分，如图4所示。随着批中请求数量的增加，需要从全局内存加载的模型部分越来越多。专家是半随机选择的，因此批中的某些token将被路由到同一个专家。随着批大小的逐步增加，越来越多的专家将被不同的请求共享。这意味着在较大的批大小时，我们将部分重现密集模型的情况——在多个用户之间分摊模型加载成本。不幸的是，这意味着我们需要显著更多的请求，即更多的用户，才能为MoE模型实现相同的“规模经济”。

为了说明这一挑战：虽然DeepSeek V3.1在单次前向传播中仅激活370亿参数，但随着不同查询激活不同专家，这一数字几乎随批大小线性增长。在大批次下，系统可能需要加载接近完整的6710亿参数模型，造成严重的内存带宽瓶颈。此外，对更大批次的需求需要大量资源来存储所有请求的缓存。这两个因素使得模型必须在单个节点之外运行。简而言之，单个节点上没有足够的内存带宽，也可能没有足够的内存空间来聚集足够的用户，使模型服务在经济上可行。

GPU节点是专为高性能计算设计的专用计算机系统。它本质上是一个包含多个GPU的服务器，以及CPU、内存或网络设备等硬件。一个流行的节点示例是NVIDIA的DGX系统，在单个机箱中包含八个高端GPU（如H100、H200或B200），以及GPU之间的高速互连（NVLink）。在节点内，GPU到GPU（节点内）通信的速度远高于节点之间的通信（节点间）。

为了有效托管大规模MoE风格模型，推理提供商需要多个GPU节点。理想情况下，我们希望拆分模型，使每个GPU处理一部分专家，并将所有相关查询路由到该GPU。这样每个GPU都保持忙碌，并且GPU不需要像张量并行（TP）设置那样通信中间结果。这种方法称为专家并行（EP）。请注意，专家选择发生在每一层，每个token。在解码阶段，随着模型生成一个又一个token，新生成的token会被路由到位于不同GPU上的不同专家。

引用DeepSeek自己的话：

由于DeepSeek-V3/R1中的专家数量众多——每层256个专家中只有8个被激活——模型的高稀疏性需要极大的整体批大小。这确保了每个专家有足够的批大小，从而实现更高的吞吐量和更低的延迟。大规模跨节点EP至关重要。

由于我们采用了预填充-解码分离架构，我们在预填充和解码阶段采用了不同程度的并行性：

预填充阶段 [路由专家EP32，MLA/共享专家DP32]：每个部署单元跨越4个节点，有32个冗余路由专家，每个GPU处理9个路由专家和1个共享专家。

解码阶段 [路由专家EP144，MLA/共享专家DP144]：每个部署单元跨越18个节点，有32个冗余路由专家，每个GPU管理2个路由专家和1个共享专家。

在单个设置中增加节点数量不仅对端到端性能有有益影响，对每个节点的性能也有影响。换句话说，我们在硬件（即GPU）的固定成本上获得了更高的投资回报率（ROI）。Perplexity的一篇博客文章清楚地展示了这一优势（见图5）。可以看到，随着涉及的节点数量增加（EP数量），每个节点的性能也随之提高。我们可以将其比作工厂——在自动化工具上投入更多资金会增加工厂现有工具的回报。随着设置中节点数量的增加，它具有复合效应，降低每token的价格，但这是有代价的——我们需要大量的使用来充分利用该设置。

虽然理论上在多节点设置中运行模型可以实现巨大的规模经济，使更大的批次运行得更高效，但大规模运行这样的操作是一项高度复杂的工作。它需要成熟的软件栈，以及开发该栈的人员对底层硬件的深入理解。当我们查看SGLang首次开源复现多节点DeepSeek设置所涉及的人员名单时（见图6），这一点就很明显。尽管存在开源复现，但截至2025年9月，它仍然很难操作，需要仔细协调不同软件库的版本和分支。我们知道有几家公共推理提供商由于上述原因，选择在单个H200或B200节点上提供DeepSeek服务。虽然这种设置远非最优，但维护和向客户提供服务要容易得多。

DeepSeek MoE 架构

由于“DeepSeek时刻”是我们撰写本文的动机，且截至2025年9月，DeepSeek V3.1仍是OpenRouter上最受欢迎的开源模型（见图7），我们将其用作计算中的参考架构。所有DeepSeek V3、DeepSeek R1和DeepSeek V3.1共享完全相同的架构细节；它们“仅”在权重值和推理行为上有所不同。

DeepSeek V3.1是一个混合模型，根据推理设置的不同，它会生成数千个所谓的推理token后才给出最终答案。无论设置如何，每token层的底层推理数学是相同的，但由于输入到输出token的分布可能差异很大，我们实现的推理数学将高度依赖于模型是用于推理模式还是非推理模式，这反映在DeepSeek的定价页面上。

DeepSeek架构在Hugging Face上的模型配置中进行了总结（见图8）。它由61层（num-hidden-layers）组成，其中3层是密集的（first-k-dense-replace），其余58层是MoE层。每个MoE层包含一个改进的自注意力机制（多头部潜在注意力，或MLA）、一个门控机制，以及257个专家——1个共享专家和256个路由专家——如n-shared-experts和n-routed-experts所定义。MoE层之后是传统的语言建模（LM）头。DeepSeek团队还提出了一个多token预测（MTP）头用于推测解码。然而，由于建模其实际性能复杂且对较大批次的相关性较低，我们在本分析中排除了它。

每层由多头部潜在注意力（MLA）和DeepSeekMoE组成，如图9所示。MLA是传统注意力的一种变体，它使用线性代数优化来压缩缓存。与其他模型（如Llama、Qwen等）不同，MLA不存储完整的键值对，而是仅存储大小为kv-lora-rank + qk-rope-head-dim的压缩潜在表示。这减少了逐token解码期间的内存带宽需求，因为生成每个token需要加载的缓存内存更少。

这些优化将缓存压缩到每个token 70KB——比其他模型减少了2-7倍（Qwen3 32B：163KB，Llama 405B：每个token 516KB）。这种压缩直接转化为更低的内存带宽需求和更低的推理成本。我们将在后面详细介绍MLA的计算机制；关键的见解是，这种架构选择从根本上改变了服务大型语言模型的经济学，尤其是在长上下文（如代理）用例中。

MLA之后是DeepSeekMoE组件（见图9）。路由机制使用一个从隐藏大小映射到n-routed-experts的线性层，根据每个token的语义内容对最相关的专家进行分类。每个token被单独路由到不同的专家集合。一个常见的误解是专家是在序列（或查询）级别选择的；我们要强调的是事实并非如此。DeepSeek为每个token选择前八个专家，路由分数在组合专家输出时作为权重。

每个专家包含一个带有SwiGLU激活的标准MLP结构：三个线性层（W1和W3：隐藏大小→moe-intermediate-size，W2：反向）。至关重要的是，moe-intermediate-size（2048）小于隐藏大小（7168）——这与Llama 3.3 70B等传统密集模型相反，后者的中间维度是3.5倍大（28672 vs 8192）。这种压缩降低了每个专家的计算成本，同时通过专家多样性保持模型容量。

除了八个路由专家外，每个token还会经过一个共享专家，该专家提供所有输入共有的基础知识。这种混合方法在专业化和计算效率之间取得了平衡。

这种架构在所有58个MoE层中重复，之后是LM头用于下一token预测。关键的架构创新——MLA的内存效率和稀疏专家激活——代表了从传统密集transformer向经济优化推理的根本转变。在以下章节中，我们将分析MLA和MoE组件的计算细节，确定决定服务成本和扩展限制的主要瓶颈。

如果您对架构细节和优化不感兴趣，只想阅读结论和元分析，请直接跳到“硬件考量与利润率”部分。

推理优化技术

DeepSeek团队在训练和推理其模型时面临严重的计算限制。这种硬件稀缺性在检查OpenRouter报告的DeepSeek V3.1平均吞吐量时很明显（见图10）。虽然Fireworks和Together等西方推理提供商以舒适的60-80 token/秒（tps）的速度提供服务，但DeepSeek仅能达到约25 tps。

对于推理模型来说，在生成最终答案之前生成数千个token，这会导致交互式用例的用户体验显著恶化。一个典型的需要3000个推理token的数学问题需要120秒（3000 token/25 tps）——迫使用户等待2分钟，这限制了其实际应用场景仅限于用户对延迟容忍度较高的情况。

面对硬件稀缺，DeepSeek采取了任何优秀工程师都会采取的措施：他们发挥了创造力。他们没有为永远无法拥有的完美条件设计，而是围绕实际约束进行了全面优化。DeepSeek最近一篇论文中详细介绍的推理优化——从专家路由到MLA-MoE计算重叠到网络拓扑——反映了这种受约束驱动的思维方式。我们将考察对我们的理论成本模型影响最大的几项优化。

专家并行

如后文所示，专家层包含约6610亿参数，占总参数的98.5%。这种分布需要仔细考虑并行化策略。为了最小化与权重相关的开销，参数分布而非复制是最佳方法。

在传统的张量并行配置中，密集FFN层的通信涉及每个token和层的隐藏大小值的分发和组合。MoE模型引入了复杂性，因为批token会被路由到不同的模型组件（不同的专家）。鉴于专家权重矩阵的紧凑维度（d-moe=2048），张量并行分片会将这些矩阵分割成过小的组件，导致次优的块矩阵乘法性能。专家并行分片保留了矩阵的完整性，使得在GEMM操作期间内存访问模式更高效。

然而，这种方法将总通信开销增加到

每个token和层，其中d是模型的隐藏大小。由于专家可能位于不同的设备上，专家并行分布更容易受到通信瓶颈的影响，从根本上改变了与密集模型相比的性能特征。

对于设备数量较少的部署，尤其是单节点或双节点配置，或节点间通信硬件非常差的部署，张量并行分片由于通信开销较低，可以实现更优的性能。

专家并行负载均衡

专家路由概率呈现非均匀分布（见图11），导致某些专家接收的请求量不成比例地高，而其他专家则未得到充分利用。在可用设备上简单均匀地分配专家会产生两个关键性能问题：（1）不均匀的通信模式，瓶颈会导致整个前向传播停滞；（2）设备间的计算负载不对称。此外，高利用率的设备必须处理更多的激活加载和内存写回操作，加剧了性能下降。

负载均衡策略可以通过在设备间智能分配专家来缓解这些问题，以实现更均匀的计算负载。此外，频繁访问的专家可以被复制以减少通信峰值，尽管这种方法需要权衡增加的权重加载和降低的每GPU 缓存容量。由于专家层的计算通常受内存限制，每个设备上拥有相同数量的专家是最优的。因此，每层额外专家的数量必须限制为专家并行大小的倍数。

一个有趣的用例是不均匀的节点配置，其中冗余专家可用于填充未充分利用的设备，以实现平衡的专家分布。例如，SGLang团队报告在解码操作中使用九个节点（72专家并行大小）和32个额外专家，在额外内存开销和减少通信峰值之间取得了良好的权衡。

重要的是，随着节点数量的增加，专家负载均衡变得越来越具有挑战性。这种退化是因为更少的节点将更多的专家集中在每个设备上，增加了实现系统范围平衡的概率。因此，对于节点数量极少的部署，专家平衡的改善并不值得相应的冗余专家。

位置感知专家选择

为了最小化有限的节点间通信，专家选择可以纳入位置惩罚，优先将token路由到其注意力计算所在的同一节点上的专家。这种方法减少了跨节点通信开销，这通常是分布式MoE推理的主要瓶颈。

在训练期间，DeepSeek V3实施了专家路由约束，确保每个token最多路由到M个节点。节点选择遵循每个节点上分布的专家的最高Kᵣ/M亲和度得分之和，其中Kᵣ表示路由专家的数量，M表示每个token的最大节点数。

这种方法可以适应推理场景，但需要仔细调整以平衡位置优势与响应质量。这种方法的一个显著后果是，token路由模式变得依赖于批中序列的位置，可能会产生位置相关的专家利用模式，从而影响模型响应。

数据并行注意力

注意力计算采用数据并行方法，将请求分布到可用设备上（见图12）。这种策略使缓存序列能够保留在单个设备上，消除了对潜在缓存的复制或设备间通信的需求，而在张量并行MLA计算中，由于投影矩阵的存在，这是必需的。

然而，这种数据并行方法需要在设备间复制所有MLA权重，DeepSeek V3.1约为10 GB，并且必须在每次前向传播时加载。这对大规模部署提出了可扩展性权衡。具体来说，在超过64个GPU的配置中，MLA权重参数消耗的内存资源可能超过专家层本身。这种复制减少了可用的缓存容量，并使MLA计算在大多数批大小下受内存限制。

双批重叠隐藏通信

如前所述，MoE模型中的专家并行产生的通信量大约是传统张量并行的九倍。为了减轻这种开销，可以实施双批重叠（TBO）策略，将通信时间隐藏在计算背后。这种方法将全局批大小划分为两个微批，允许同时执行，其中一个微批进行计算，另一个处理通信操作。

有效的重叠实现需要仔细协调计算和通信阶段。图13展示了解码操作的基本TBO配置。由于通信操作消耗的计算资源最少，TBO在某些情况下可以实现接近两倍的运行时改进。

预填充-解码分离

LLM推理包括两个具有根本不同计算特征的不同阶段。预填充操作同时处理整个输入序列，创建计算密集型工作负载，具有高利用率但最小的缓存需求。解码操作迭代生成token，导致受内存带宽限制的计算。此外，由于其重复性，解码对延迟更敏感。

正如SGLang博客文章中更详细解释的那样，传统的统一引擎将预填充和解码批一起处理，引入了三个关键低效：（1）传入的预填充批中断正在进行的解码操作，导致大量token生成延迟；（2）当工作节点同时处理不同类型的批时，会出现数据并行注意力不平衡，增加解码延迟；（3）与需要每个阶段不同调度模式的高级专家放置策略不兼容。

预填充-解码分离通过将工作负载分离到针对每个阶段需求优化的专用集群来解决这些问题，预填充通常由于更好的计算利用率而需要比解码更少的资源。

理论性能模型

理论性能模型创建了我们DeepSeek V3.1模型的虚拟克隆，能够分析不同的硬件配置，以确定最佳的MoE模型服务策略。此外，该框架允许识别各种部署场景下的系统瓶颈。虽然该模型是专为DeepSeek V3架构设计的，但扩展到Kimi-K2和其他MoE架构非常简单。

理论性能模型分别分析注意力（DeepSeek V3.1的情况下为MLA）和专家计算，因为这些组件可能在不同时间受不同资源限制。由于可以采用双批重叠技术来隐藏通信，模型的这两个部分可能在没有重叠的情况下运行，因此无法在组合计算中隐藏内存加载。此外，模型考虑了可能包含不同节点内和节点间通信硬件的异构网络中的通信。通信时间可以选择使用TBO重叠。最后，我们考虑专家分布不均匀的场景，导致通信不平衡、内存加载增加和GPU间计算不均，从而可能成为整个系统的瓶颈。

该模型基于以下假设：

• 没有来自DeepEP TBO通信库的计算和内存加载开销。实际上，这一假设不成立，因为该库会启动相当数量的CUDA内核。

• 所有计算和权重均以FP8执行和存储，但通信操作除外，其中调度以BF16进行。这一假设在很大程度上是准确的，因为超过98%的参数位于专家权重中，这些权重使用8位量化。

• 分析仅关注解码性能，不考虑预填充操作。将给出预填充性能的理论推导。

首先，我们根据执行的操作和加载的内存来查看Transformer块的MLA和专家MLP网络的执行时间。其次，我们考虑通信。作为参考，所有变量名称列于表1中。

内存加载

为了估计从内存加载的时间，我们查看每次前向传播期间加载的内容。首先看MLA，其次是专家网络。

MLA

MLA在推理期间的内存需求可分为三个主要组件：MLA权重（读取）、缓存（读取和写入）和激活（写入）。

其中d_c = 512表示压缩维度，d^h_R = 64表示解耦查询和键的每头维度，L = 61是层数。

专家网络

对于专家MLP网络，我们有两个内存传输源：模型权重，每次前向传播读取一次；激活，以FP8加载一次并以BF16写回一次。

嵌入层

计算

为了量化计算延迟，我们研究多头部潜在注意力（MLA）机制，遵循DeepSeek v2附录C中详细的架构规范。我们的分析结合了矩阵吸收优化，使某些线性变换能够在推理期间合并。我们根据DeepSeek V3的训练时间计算器验证了我们的计算框架，以确保一致性，尽管由于仅在推理期间可能的优化，我们需要进行一些更改。此外，解码操作的单token生成特性极大地简化了几个方程，相对于需要完整序列处理的训练上下文。我们用Prefill注释表示特定于预填充场景的计算，以区分预填充与解码执行路径的不同之处。

我们的计算分析有三个主要部分：基线的普通MLA实现、采用矩阵吸收技术的优化MLA，以及专家网络的计算延迟。

MLA

会增加内存传输量并减少可用的缓存容量。但有一种两全其美的方法。我们的方法与DeepSeek的提示不同，避免了结果复合矩阵的具体化。相反，我们通过动态计算实现效率：在计算q_t^C时，我们按需计算复合矩阵，而不是存储它。这种策略保持了相同的内存占用和加载模式，同时消除了由于解码阶段K和V张量的上投影而产生的计算密集型序列长度依赖性。

为了理解MLA的计算需求，我们首先分析简单的普通实现以建立基线计数，然后进展到优化变体并展示其性能改进。

普通MLA实现

普通实现遵循DeepSeek v2附录C中的MLA规范，包括三个阶段：潜在投影、自注意力和输出投影。

潜在上下投影 潜在投影包括两个连续的操作：下投影到潜在空间，然后上投影到注意力维度。为了简单起见，我们忽略RoPE和Softmax计算。

其中FLOPs_{k_RoPE_proj}每个k只需计算一次，因为它们被缓存。

注意力计算 注意力机制计算查询-键与缓存的键值对的交互，其计算复杂度随序列长度而变化。

现在，我们研究实现非具体化矩阵吸收方法时的计算修改。

矩阵吸收MLA实现

潜在上下投影 由于我们吸收了K和V张量的上投影矩阵，我们不再需要执行这些投影。

这消除了投影阶段的序列长度依赖性，这是一个显著的计算瓶颈。

如图所示，在不引入额外矩阵具体化的情况下，消除了FLOPs×W^(UK)和FLOPs×W^(UV)的序列长度依赖性。

输出线性变换 最终的线性变换再次将注意力输出投影到模型维度，将W^UV的吸收合并到W^O中。我们再次避免具体化吸收的矩阵以最小化内存开销。

专家网络

通信

通信基础模型

根据SGLang博客文章中的分析，唯一的GPU间通信源于专家并行分片。图16说明了单个层前向传播期间的这种通信模式。每层有两个不同的通信阶段：一个调度阶段，将token从数据并行MLA块路由到选定的专家；一个组合阶段，聚合专家计算结果，以便传播到下一层的数据并行MLA块。

前导因子2反映了计算-通信微批重叠，其中连续的批处理引入了顺序依赖。调度操作使用FP8精度，而组合阶段使用BF16精度。

改进1：非异构通信链路

标准系统通常在节点内和节点间通信有不同的互连速度。鉴于总通信量的1/n_nodes保留在单个节点内，在互连速度差异显著的异构网络配置中（例如，NVLink为450 GB/s，而InfiniBand为50 GB/s），这部分通信可以忽略不计。NVL72机架配置是一个显著的例外，它在机架内的所有节点间提供统一的NVLink连接。

对于具有异构互连的系统，总通信时间变为：

改进2：专家不平衡

虽然足够大的批大小和随机专家路由（以及适当的共享专家复制）理论上可以重新平衡这种负载，但生产系统的实证测量显示专家利用率存在固有差异，与这一假设相矛盾。

从托管专家的单个GPU的角度来看，通信量变为：

将专家负载不平衡因子（在下一节中引入）纳入公式后，得到：

对于异构网络配置，由此产生的通信时间变为：

常见互连列表

表2列出了常用互连技术的全对全通信模式的单向带宽规格，其中通信吞吐量受限于单个GPU的可用带宽（单向带宽）：

专家均衡性

专家在GPU上的分布对专家层的通信和执行时间有很大影响。作为一个说明性示例，我们可以考虑一个具有2x8 H100 GPU的系统，并均匀分布所有专家。在这种情况下，有一个GPU拥有共享专家加上大约16个路由专家。由于批中的所有项目都将访问共享专家，该GPU必须加载大约

比其他GPU更多的激活。此外，2.7倍的通信量将通过连接到该GPU的链路。

为了模拟这种不平衡，我们定义并向用户公开变量β_eb。与SGLang的定义类似，β_eb定义为GPU间平均专家负载与最大专家负载之比，因此：

因此，β_eb_gpu=1是平衡情况，β_eb=1/n_GPUs将是完全不平衡的。因此，平均负载增加了L_imbalanced = (1/β_ep) × L_balanced。

为了平衡专家，一些n_additional_experts被复制到多个GPU上。这可能导致EP内存加载时间增加。由于EP通常受内存限制，这可能导致EP执行时间增加。因此，平衡专家是加载更多权重与更均匀的通信和计算之间的权衡。最后，必须确保（n_routed_experts + n_additional_experts）模 ep_size = 0，否则会在内存加载和计算中引入设计上的不平衡。

SGLang博客文章中的图17显示了给定GPU数量和可能的主动负载平衡情况下的专家均衡示例。

从部分到整体

考虑到所有这些因素，我们实现了一个理论模型，根据硬件估算模型吞吐量。这应该更容易理解不同硬件提供商之间在延迟、吞吐量和成本之间的权衡。

该模型包含许多假设，例如：

• 所有权重均以FP8存储；MLA以BF16计算；专家层中的矩阵乘法以FP8执行。通信以FP8进行，但调度以BF16进行。

• 我们对计算、内存带宽和通信的开销做出了一些强有力的假设。我们假设不同硬件的低效水平相同，以保持公平。这些水平是任意的，可以说是我们计算中误差的主要来源之一。实际上，这些低效对于每个硬件来说也不相同，并且强烈依赖于实现。

• 为了简化计算，我们假设不执行MTP。我们成功使其与MTP一起运行；然而，我们认为性能提升不值得增加模型的复杂性，尤其是对于较大的批次。

• 我们仅查看解码性能，不考虑预填充。

• 我们假设没有来自DeepEP双批通信库的计算和内存加载开销。这不是真的，因为这些操作会启动大量CUDA内核，这可能对高度优化的内核（如GEMM）产生下游影响，因为它们将不再获得预期的线程数。

在较高层次上，性能模型包括三个主要执行组件：MLA计算、专家并行（EP）计算和通信开销。对于MLA和EP操作，我们确定内存带宽或计算吞吐量是限制因素。通信可以选择使用双批重叠（TBO）重叠，其中一次前向传播的总执行时间变为：

高层模型结构如下：

计算、内存和通信时间估计使用先前推导的公式，并根据实际实现的低效进行调整。实际系统很少达到理论峰值性能，因此需要在所有组件上设置低效因子。DeepEP通信库文档显示，从50 GB/s的理论峰值实现了40 GB/s的吞吐量，产生约25%的通信开销。FlashMLA实现了约66%的MFU。专家层计算性能基于DeepGEMM基准测试，显示从1980 TFLOPs的理论FP8密集峰值性能中获得1550 TFLOPs，导致EP计算开销因子约为30%。两种计算低效都额外增加了10%的惩罚，以考虑次优输入条件和内核之间的开销。

内存低效估计在没有分析的情况下更具挑战性。由于某些操作（如矩阵乘法）需要多次加载相同的值，并且大多数内核针对计算受限场景进行了优化，我们应用了一个保守的低效因子2.0来考虑这些开销。

token生成速率计算为总执行时间的倒数，全局吞吐量随并发批大小而扩展：

需要注意的是，该模型不考虑所提出的配置在现实世界内存限制下是否可行。例如，长上下文序列可能会因内存限制而大幅减少并发序列的最大数量，导致吞吐量远低于理论预测。

预测与实际比较

为了验证我们的理论模型，我们将其与使用三种截然不同的硬件设置的实际测量结果进行比较：

• 4x8 H100：这是我们认为大型企业合理维护的基本设置。这也是我们设法获得的设置，因此我们有所有合理批大小的测量结果。

• 9x8 H100：这是SGLang博客文章中的设置，包括他们调整后的性能测量结果。

• 12x4 B200：这涉及NVL72设置中72个GPU中的48个。我们用它来可视化新一代硬件的表现差异。这也是SGLang团队测试的设置。

图18和19表明，我们的理论模型与实证测量结果达成了合理的一致。第一个图展示了系统的总吞吐量和每个请求的token/秒（TPS），第二个图通过展示每GPU的TPS强调了效率。

正如预期的那样，我们的模型显著高估了实际性能，我们必须使用我们的低效因子来调整模型。这种差异源于两个主要因素：首先，各个组件内核未能达到峰值性能，如前所述；其次，这些单个组件的峰值性能在受限批大小下很少达到。此外，端到端优化通常次优，导致内核针对不同的操作场景进行优化。这些因素证明了我们纳入的低效假设是合理的。

小批大小的估计尤其具有挑战性，如图18所示。在批大小为32时，我们设置中的实际性能（蓝色显示）超过了理论预测（考虑我们的低效因子；它不超过硬件本身的上限）。在我们的模型中，我们假设专家激活概率均匀，这与实际情况不符。实际上，激活的专家较少，导致吞吐量高于预测。随着批大小的增加，吞吐量收敛到预测水平，表明激活了大多数或所有可用专家。

与我们的假设一致，该模型不评估给定批大小在给定系统内存限制下是否实际可行。在我们的系统配置中，序列驱逐在批大小超过1024后开始，导致每个请求的吞吐量急剧下降和总吞吐量饱和。增加节点数量会扩大可用于缓存的内存量，从而允许更大的批大小，如两个SGLang配置所示。

吞吐量：理论与实践

查看图19，我们观察到每GPU批大小的增加显著提高了系统效率。然而，实现这些最佳批大小需要大量内存分配来存储缓存。由于总权重大小基本保持不变（不包括数据并行MLA权重），将计算分布到更多GPU上会按比例减少每个GPU的权重负担。

大规模系统带来的一个日益严重的问题是通信开销，它随批大小线性增长。因此，具有大批次和短序列长度的配置可能会遇到通信瓶颈。这一现象在图19中表现为，4x8 H100配置在批大小为512时的每GPU吞吐量高于9x8 H100设置，因为后者受通信限制。然而，前者配置在实践中无法维持这些批大小，并将驱逐序列，实际上以较小的批大小运行。这也展示了NVL72超级节点在推理工作负载中的优势，有效缓解了潜在的通信限制。

Kimi-K2是第一个超过1T参数的开源LLM。该模型采用与DeepSeek V3.1基本相同的架构，只是每层有更多的路由专家。如图20所示，这种配置导致吞吐量降低，尤其是在MLA运行时间保持最小的内存受限条件下。然而，对于大批次，在相同硬件配置下实现等效批大小是不可行的，因为Kimi-K2需要更多的GPU内存来存储其权重。因此，尽管理论性能下降看似不大，但由于与DeepSeek V3.1部署相比有效批大小减少，实际性能差异可能更显著。

在服务长序列时，也出现了类似的缓存驱逐增加和有效批大小减少的挑战，因为它们的缓存需要大量内存空间。尽管序列长度对解码性能的影响相对较小，如图21所示（而在预填充期间，序列长度具有二次依赖性），但它限制了运行非常低的批大小，显著降低了系统效率。

例如，一个4×8 H100设置为每个GPU提供大约20 GB的GPU内存用于缓存。在上下文长度为32,768 token时，这转化为最大有效批大小为

在实践中，缓存的碎片化和其他低效因素进一步降低了这一数字。DeepSeek报告的平均上下文长度要短得多，为4989 token，这在可管理范围内。

生产服务环境通常在服务级别协议（SLA）要求下运行，这些要求规定了每个请求的最低TPS阈值。如图22所示，这些性能保证通常对可实现的批大小施加惊人的严格限制。提供商发现自己被迫使用较小的批次来满足每个请求的延迟要求，导致效率次优。这一限制对较小的部署配置影响更大，为大规模企业运营创造了自然优势，服务于数十万客户。

我们之前的分析对预填充阶段的关注有限。在预填充期间，系统计算所有输入token的完整缓存并生成第一个输出token。由于需要完整的注意力计算，该阶段的计算复杂度随序列长度呈二次增长。对于较短的序列，预填充持续时间仍远短于后续的解码阶段。然而，在长上下文场景中，预填充可能超过解码时间，造成重大系统瓶颈。

服务框架通常会中断解码操作以处理预填充批，导致整个推理管道停滞。此外，预填充操作通常受计算限制而非内存限制，需要与解码不同的优化策略。大规模部署通过实施预填充-解码分离来解决这一问题，将这些阶段物理分离到不同的实例中。预填充实例通常使用比解码实例更少的GPU，反映了预填充操作的较短持续时间和不同的资源需求。

交互式聊天应用和代理工作流经常涉及多轮序列，其中连续请求共享公共提示前缀。考虑到这些对话上下文的潜在长度，重复执行共享内容的预填充变得非常低效。复杂的缓存机制可以通过在请求之间重用计算的缓存来显著提高性能。有效的缓存架构不仅限于GPU内存，还可以使用CPU内存，甚至持久化到磁盘。对于足够长的序列，即使是磁盘到GPU的传输通常也比重新计算快。此外，磁盘缓存可以保存更长时间，可能长达数天。

这种缓存基础设施还可以作为分离的预填充和解码实例之间的缓冲层。LMCache和Mooncake等系统提供了这一问题的基础解决方案。然而，建立这样的缓存基础设施并非易事，我们将这一主题留待未来的博客文章讨论。在当前的分析中，我们注意到，尽管预填充会对整体系统性能产生重大影响，但设计良好的缓存策略可以提供实质性的缓解。DeepSeek的生产部署报告实现了约56.3%的缓存命中率，表明部署时预填充时间有显著减少。

虽然SGLang和vLLM等开源推理框架可能无法达到Fireworks或Together等专业商业推理提供商的绝对峰值性能，但我们认为性能差距仍然相对较小。生产部署的证据，如Tweet 23中引用的，表明开源解决方案接近主要企业实现的最先进效率水平。

我们的理论分析结合实证测量表明，专有推理提供商可能实现与优化良好的本地个人部署相当的计算效率。然而，这些商业提供商通过访问更优越的硬件和更有利的规模经济保持竞争优势。主要的差异化似乎源于基础设施优势和规模经济，而不是推理栈本身的根本算法或实现优势。

硬件考虑和利润率

在为DeepSeek V3.1或Kimi等大规模MoE推理设置选择硬件时，必须考虑几个关键因素。首先，由于稀疏计算模式及其对前向传播所需加载参数的影响，向设置中添加更多GPU具有显著的规模经济。换句话说，四个节点的组合应该比两个节点上的两对工作节点更具竞争力。SGLang团队创建的图表清楚地说明了这一点（见图24），其中72个GPU的设置在每GPU基础上远远超过16个GPU的设置，这一观察结果证实了我们之前从Perplexity的结果中看到的（见图2）。

其次，累积吞吐量和每个用户的体验高度依赖于部署运行的批大小。这在我们测试DeepSeek的基准测试中（见图18）以及SGLang团队提供的数字中（见图25）都得到了很好的体现。允许的批大小越大，累积吞吐量越大，但这是以每个用户的延迟增加为代价的，如Tab. 1所示——这是推理优化中的一个基本权衡。

硬件选择是下一个关键考虑因素。最佳选择高度取决于您特定用例的延迟/吞吐量要求。虽然NVL72中的B200将比H100提供更优的每GPU性能，但它们的价格要高得多——假设您能获得它们。根据推理提供商想要优先考虑的因素，无论是成本还是延迟，这将影响此处的最佳硬件类型。

对于您的具体应用，您运行多少输入和输出token，每个用户的利润有多大，每天并发用户数量的分布如何，用户的灵活性如何，以及在高峰使用时，tps可以降到多低？所有这些因素都应影响什么硬件最适合您。

在对不同硬件设置运行理论模型后，我们注意到一个有趣的现象：B200的慢速互连是一个多大的瓶颈。我们估计的通过InfiniBand连接的B200与通过NVLink连接的B200之间的性能差距似乎很大。这显然高度取决于模型以及我们在节点间通信的多少，但总体而言，我们认为对于DeepSeek这样规模的模型，在B200上运行可能实际上并不理想，因为通信开销几乎抵消了与H100相比更快的内存和更多带来的大部分收益（见图27）。

我们希望您从阅读本文中得到的另一个观察结果是，当前的推理提供商是多么“以聊天为中心”。如果您查看OpenRouter报告的各种提供商的DeepSeekV3吞吐量，大多数都提供非常舒适的50+ tps（见图28）。虽然这对于聊天等实时应用来说很好，但如果我们想使用该模型生成合成数据，这就不太理想了。正如我们在本文中多次看到的，在Perplexity的基准测试中（见图5），在我们的理论估计中，以及在我们的实际观察中（见图19），保持如此高的tps虽然对实时应用很好，但在我们想要生成尽可能多的token时是次优的。为此，操作批大小需要大幅增加。这将导致每个请求的tps性能显著下降，但总体吞吐量大幅提高。对于异步或非时间关键的工作负载，这种权衡非常有利，大大降低了每token的成本。

这种设置非常适合合成数据生成，其中单个延迟无关紧要，目标是最大化每美元硬件投资的总token产量（图29）。然而，我们认为当前的推理提供商未能充分服务于这一市场。虽然有些提供批量折扣——Fireworks对批量API提供40%的折扣，DeepSeek在中国提供50%的非高峰定价（见图32）——但这些有限的选择表明，对灵活、吞吐量优化的服务存在巨大的未满足需求。

这种基础设施缺口为专门从事短期、高吞吐量计算租赁的NeoCloud提供商提供了重大机会。如今，一些提供商，如Prime Intellect，已经提供了对多达64个H100的集群的按需访问（见图30）。这样的设置即使对于DeepSeek这样的大型模型，也能够每天生成数十亿个合成token。

此类数据运行的推理轨迹可用于类似OpenAI提供的产品中的强化学习微调（RLFT）。我们相信，使用RL来训练直接最大化业务特定奖励的模型具有显著的增长潜力。想象一个虚拟助手帮助人们做出购买决策，它以实际美元收入作为奖励，放大更能转化为销售的行动，或者一个虚拟伴侣促进深度参与的对话，让用户在应用中停留更长时间。企业无疑有巨大的经济动机来应用此类技术，以类似于YouTube或TikTok已经在推荐引擎中所做的方式最大化收入。

此外，为了提高推理经济性，此类RL模型可以使用LoRA适配器或类似技术进行训练，并与数千个其他模型一起服务，所有模型都针对特定用例。这种多租户服务方法为推理提供商提供了一个引人注目的商业机会。在提供商基础设施上托管其自定义LoRA适配器的客户在迁移到竞争对手时面临显著的转换成本，因为适配器针对特定的服务配置和客户工作流进行了优化。RLFT基于独特而细致的奖励，这些奖励非常特定于客户；与标准的监督微调（SFT）不同，仅通过上下文学习来复制它要困难得多，这使其成为推理提供商更具吸引力的案例。

我们预计推理市场将在提供的吞吐量、延迟和定价方面进一步专业化。像Groq和Cerebras这样的超快token提供商因其以几秒延迟交付的token而收取更高溢价是很自然的，而像NeoCloud这样的其他提供商则专注于高延迟、高吞吐量的推理场景，专注于合成数据生成。我们希望在未来的文本中详细阐述这一领域。

从代币到美元——代币经济学评估

现在，我们终于可以回答最初的问题：DeepSeek V3.1 token的公平价格是多少？正如您在阅读本文后所了解的，答案并不令人满意，取决于具体情况。

每token的价格取决于两个因素：我们的硬件成本，以及它每单位时间可以生成多少token。正如Perplexity的数字（图5）和SGLang的结果（图24）所示，部署更多GPU时，每GPU的性能有显著优势。将更多GPU投入服务大规模MoE模型将提高每GPU的性能，从而降低成本并提高利润。

此外，由于LLM推理严重受内存限制，我们服务模型的批大小显著影响所有请求的总吞吐量。我们使用的批大小越大，累计生成的token越多，但这是以每个用户的延迟增加为代价的，如Tab. 3所示。

此外，并非所有硬件都是平等的。虽然B200将比H100提供更优的计算GPU性能，但它们的成本要高得多（见表3），这使得在优化成本效率和在最小化成本的同时生成尽可能多的token时，它们可能不是最佳选择。

总之，虽然我们无法提供确切的数字，但我们希望这一分析能为影响token定价的因素提供有价值的见解。我们提供的理论性能模型虽然不完美，但应该对预期性能和不同硬件选项之间的权衡提供坚实的直觉。

丢失的tokens

最后，我们想解决一个显而易见的问题：全球市场中token缺失的问题。在撰写本文时，DeepSeek V3.1仍然是OpenRouter上最受欢迎的开源模型。虽然显示的每日消耗量徘徊在每天300亿token左右，但仔细检查后发现，其中大部分是输入token，而不是输出token。OpenRouter上DeepSeek V3.1输出token的全球日消耗量约为10亿token。快速查看表3中的数字显示，只需一个NVL72的一小部分，我们就可以满足这一需求20倍以上，同时保持合理的>30 token/秒/请求。

这是一个相当大的差距。全球最受欢迎的开源模型的消耗量如此之小，以至于一个NVL72的容量就可以满足需求，这怎么可能呢？考虑到这种低需求，这么多推理提供商如何维持业务？简而言之：谁在赚钱？

有人可能会说，我们只考虑了解码token，而大部分收入来自输入token。我们这样做是因为，由于缓存机制，很难准确估计输入token成本中有多大比例可以被推理提供商捕获。

引用DeepSeek的话：

在24小时统计期内...总输入token：6080亿，其中3420亿token（56.3%）命中了磁盘上的缓存。

缓存大大降低了预填充的成本，缩短了到第一个token的时间，并使推理提供商能够将节点从预填充转移到仅处理解码。例如，DeepSeek提供75%的折扣（见图32）。

假设DeepSeek的缓存数据在整个行业中都适用，那么通过OpenRouter实现的每日总利润将为：

分布在所有推理提供商中。一些提供商不提供缓存，一些提供比DeepSeek更便宜的定价，一些提供更贵的定价，因此估计每天的总支出并不容易，但我们预计不会有太大不同。这就引出了一个问题：DeepSeek的需求在哪里？

第一个自然的答案是，OpenRouter只捕获了DeepSeek模型全球需求的一小部分。问题是，有多小？即使只有1%，假设我们的估计准确，也可以轻松地由3到4个NVL72满足。这一计算的一个警告是，我们的数字（基于SGLang基准）假设输入长度为2000 token，这是我们在理论模型中试图考虑的。如果我们将上下文长度从2k增加到32k，缓存占用空间将增加16倍，严重限制我们可以运行的批大小，大大改变我们的潜在利润率。

总体而言，我们没有精确数据支持“缺失的token在哪里？”这个问题的答案；在DeepSeek透露的数字中，他们声称每天处理1680亿输出token（这些数字来自2025年2月，当前数字可能显著更高）。这比OpenRouter大几个数量级，这个差距让我们感到非常惊讶，但这在很大程度上可以回答这个问题。也许全球对DeepSeek token的需求绝大多数（>99.9%）是通过直接调用提供商而不是通过聚合多个提供商的服务来满足的。

我们唯一能找到的公开分享其数据的其他提供商是Chutes（见图33）。在大约2亿输出token和低得多的定价（每百万输出token仅80美分）的情况下，他们每天从DeepSeek V3.14的输出token中获得约160美元的收入。除此之外，他们似乎从输入token中获得了更多收入，但这似乎主要是由于缺乏缓存。随着LMCache和Mooncake等易于访问的缓存解决方案的出现，我们预计这一问题将在未来几个月内得到解决，由此产生的节省将传递给消费者。

在与行业内部人士交谈时，有人告诉我们，一些领先的推理提供商，那些已经筹集了九位数资金的公司，每天处理数万亿token，但截至2025年9月，没有公开证据支持这些说法。我们发现，谷歌、字节跳动或微软宣称他们每天处理数万亿token，而我们看到的开源提供商的数字却微不足道，这种差异令人困惑！

文章来自于微信公众号“human five”，作者是“Piotr、Eric”。