DeepSeek时代的Large-scale LLM推理

2025年底DeepSeek V3发布炸场，几乎为业界之后的LLM优化方向定了调，尤其是大规模推理优化方面。去年快年底时对LLM的推理优化技术做过一个简单的总结：《LLM时代中的AI推理优化》，现在看来已有很多变化。在DeepSeek V3问世快一年之际，这里简单整理总结一下业界与之相关的推理优化技术。

根据官方技术报告《DeepSeek-V3 Technical Report》，DeepSeek V3在网络结构上仍然采用了Transformer架构。Transformer layer中的Attention与FFN部分，分别采用了Multi-Head Latent Attention（MLA）和DeepSeekMoE。简单来说，前者采用了lora技巧减少了KV cache，使MLA的计算在decode阶段也不会memory-bound（可参见《A Deep-Dive Into the New Flash MLA Kernel》），后者采用了fine-grained MoE使得模型可以在推理计算量可控的前提下更好地scale。这两种结构和之前的DeepSeek V2是基本一致的，可参见论文《DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model》和论文《DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models》。有个差别是在MoE中DeepSeek V3采用了称为auxiliary-loss-free的load balancing策略。另外DeepSeek V3还使用了Multi-Token Prediction（MTP）输出多个token。这个结构在推理中是可选的，如果要用的话可用于投机推理。之后发布的DeepSeek R1与DeepSeek V3在网络结构上一致。

在DeepSeek V3之后业界涌现出了很多新的网络，可以从中一窥业界的发展趋势。

Kimi-K2: 参见《Kimi K2: Open Agentic Intelligence》。网络结构与DeepSeek V3是一样的，区别主要是一些超参（如专家数提高到384，Attention head数降低到64等）的改变，其总参数量提高到了~1T。
Qwen3：参见《Qwen3 Technical Report》。Qwen3分为dense和MoE两类，后者带MoE结构。它的Attention部分采用了GQA，并做了些改动（加了QK-Norm）。和Qwen2.5（参见《Qwen2.5 Technical Report》），一样也采用了DeepSeekMoE中的fine-grained experts。与Qwen2.5不同，MoE中没有shared expert。
Ling-1T：其网络结构基于论文《Towards Greater Leverage: Scaling Laws for Efficient Mixture-of-Experts Language Models》中activation ratio，expert granularity, shared experts ratio等配置参数对于MoE模型有效性影响的研究。Attention模块采用GQA。MLP部分前4层采用Dense FFN，后面的MoE采用类似DeepSeek V3的256个experts，每个token激活1 shared expert + 8 experts。
LongCat-Flash：参见《LongCat-Flash Technical Report》。它采用了DeepSeek V3中的MLA，MTP与fine-graned expert的设计。区别在于每个layer包含了两个MLA和多个FFN。MoE中，一方面基于不同的token所需计算量不同，它采用了zero-computation experts使得模型根据contextual importance来动态调节计算量。另一方面，它采用Shortcut-connected MoE (ScMoE)用shotcut连接第一个MLA到MoE，另一条路是FFN->MLA->FFN。这样无需shared expert也可以使通信与计算能很好地做single-batch overlap。
Step-3：参见《Step-3 is Large yet Affordable: Model-system Co-design for Cost-effective Decoding》。Attention部分采用Multi-Matrix Factorization Attention（MFA），详细可参见《Multi-matrix Factorization Attention》。它与MLA类似，先将Q降维，经过归一化后再升维。不同的是对K和V不会做这个操作。Q的所有head共享K和V。FFN部分采用了与DeepSeekMoE类似的结构。
DeepSeek OCR：参见《DeepSeek-OCR: Contexts Optical Compression》。它是VLM架构。Encoder部分为包含SAM和CLIP的DeepEncoder，用于图像的特征提取。Decoder部分采用小规模的DeepSeek-3B-MoE。
DeepSeek V3.2-Exp：参见《DeepSeek-V3.2-Exp: Boosting Long-Context Efficiency with DeepSeek Sparse Attention》。它引入了DeepSeek Sparse Attention（DSA）结构。该结构包含Lightning Indexer和Top-k Token Selection，实现了细粒度稀疏注意力机制。Lightning indexer计算query token与前面token的index score，然后挑最大的K个token对应的KV与query进行attention计算。它主要解决传统的稠密attention在长序列下计算复杂度指数增长的问题。
MiniMax-M1/M2：参见《MiniMax-01: Scaling Foundation Models with Lightning Attention》与《MiniMax-M1: Scaling Test-Time Compute Efficiently with Lightning Attention》。Attention部分使用lightning attention（一种linear attention）与softmax attention（GQA）按7：1的比例堆叠。MoE部分采用32专家选2的策略。之后出的MiniMax-M2模型没有用MiniMax-M1中的lightning attention，而是用回了full attention（原因可参见官方文章《为什么MiniMax M2是一个Full Attention模型？》）。MoE部分更加稀疏（230B参数激活10B）。
Qwen3-Next：参见《Qwen3-Next: Towards Ultimate Training & Inference Efficiency》。Attention使用Hybrid Attention（混合注意力机制），它将Gated DeltaNet（线性注意力）与Gated Attention（标准Attention加了Gating机制等改进）以3比1的比例组合。线性注意力可以将标准Attention的平方复杂度降到线性。MoE部分高度稀疏（80B参数激活~3B）。
Kimi Linear：参见《Kimi Linear: An Expressive, Efficient Attention Architecture》。它的核心是Kimi Delta Attention（KDA），是一种线性注意力机制。它扩展了Gated DeltaNet，将其head-wise的遗忘门变成更细粒度的channel-wise。它对Gated DeltaNet的转移矩阵Diagonal-Plus-Low-Rank（DPLR）通过加限制得到其变体，使得可以用硬件高效的chunkwise并行算法进行计算。Kimi Linear架构将KDA与MLA以3:1的比例混合。

Attention由于其复杂度为序列长度的平方，因此对长上下文的处理是比较挑战的。这个问题上最近有两个比较热的方向：

Sparse Attention
如DeepSeek的NSA和DSA。早些年就有不少工作指出Attention中其实只需要KV中的部分就能得到不错的accuracy，如《H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models》和《Quest: Query-Aware Sparsity for Efficient Long-Context LLM Inference》等。它们以一定的标准，基于KV-cache的eviction或 selection的方法选取对精度影响大的KV部分参与计算。但是它们是作为推理阶段的近似方法提出的，对accuracy通常影响会较大。对accuracy影响更小的方式是在训练时就采用Sparse Attention。DeepSeek团队之前的论文《Native Sparse Attention: Hardware-Aligned and Natively Trainable Sparse Attention》提出过一种用于长上下文的Sparse Attention结构-NSA。该结构比较复杂，结合了三种方式：粗粒度的压缩信息，细粒度的token选择和局部上下文的滑动窗口，再由gate控制。相比之下，DeepSeek V3.2中的DSA结构会简单一些。
Linear Attention
如MiniMax-M1，Qwen3-Next和Kimi Linear。Attention中K和V可以看作是状态，Q可以看作每步的输入。它与K和V进行计算并更新K和V。理想情况是K和V作为状态增量更新，每步Q与这个状态相乘。但由于softmax的存在，我们没法用结合率将K与V先相乘。如果直接去掉softmax自然会使模型的表达能力降低，因为这样Attention就退化成一个纯线性函数。Linear Attention将softmax去掉，但是将Q与K通过一个非线性函数转到特征空间。然后在特征空间上相乘。这样便可以利用结合率将K和V相关部分先乘了。在前深度学习时代流行一时的kernel method似乎又以新的形式重回舞台。

回到DeepSeek V3的部署上来。在模型发布之后的DeepSeek 开源周里，各重要组件（FlashMLA，DeepEP，DeepGEMM，DualPipe, EPLB，3FS）以开源项目的形式陆续发布。尽管推理引擎（从文章《The Path to Open-Sourcing the DeepSeek Inference Engine》中可知是基于早期版本vllm）没有开源，但这些开源的组件已普遍被吸收到各主流推理引擎中。

DeepSeek在官方的技术报告《DeepSeek-V3 Technical Report》与技术文章《DeepSeek-V3 / R1 推理系统概览》中有关于部署方案的说明。但由于没有开源完整的推理解决方案。业界有很多相关实现和优化工作，如：

SGLang
- 《Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs》
- 《Deploying DeepSeek on GB200 NVL72 with PD and Large Scale EP (Part I): 2.7x Higher Decoding Throughput》
- 《Deploying DeepSeek on GB200 NVL72 with PD and Large Scale EP (Part II): 3.8x Prefill, 4.8x Decode Throughput》
- 《Together with SGLang: Best Practices for Serving DeepSeek-R1 on H20-96G》
Ascend
- 华为昇腾服务器 DeepSeek V3/R1 推理部署最佳实践
- 《Serving Large Language Models on Huawei CloudMatrix384》
- 《DeepServe: Serverless Large Language Model Serving at Scale》
- 《xDeepServe: Model-as-a-Service on Huawei CloudMatrix384》
TensorRT-LLM
- 《Optimizing DeepSeek R1 Throughput on NVIDIA Blackwell GPUs: A Deep Dive for Developers》
- 《Pushing Latency Boundaries: Optimizing DeepSeek-R1 Performance on NVIDIA B200 GPUs》
《RTP-LLM DeepSeek Reproduce Tech Report》
《腾讯太极团队实现DeepSeek模型业内H20最高性能15800+ tokens/s》

PD分离

现代LLM主流采用的auto-regressive的生成方式主要由两阶段组成：Prefill（或称context）和Decode（或称generation）。两者在计算模式上有很大的不同。前者计算密度高，KV cache需求相对小，一般是compute-bound；后者则相反，一般是memory-bound。

传统的做法是把两个阶段放在一个GPU或者一个节点上做。该做法的缺点是对资源的利用效率不高，会出现跑prefill请求时带宽资源用不满，跑decode请求时计算资源用不满的情况。另一方面，prefill与decode会相互干扰。LLM服务通常会有TPOT的SLO，而如果计算资源被prefill 请求占用，容易会使TPOT增大无法达到SLO要求，尤其是在长序列的情况下更为严重。论文《SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills》和《DeepSpeed-FastGen: High-throughput Text Generation for LLMs via MII and DeepSpeed-Inference》等工作中的chunked prefill将长的prompt切成多份，然后将它们与decode阶段的请求混合起来执行，可以一定程度上缓解该问题。但它会有一些缺点：1.实际当中很难选取合适的chunk size。大了不满足SLO，小了又打不满GPU。2. 它会带来前面chunk的KV cache重复读的开销。3. 当使用chunked prefill，可能会使得batch里的那些decode任务也无法使用CUDA graph。

由于两个阶段的任务放在一起做影响效率，因此一些论文中提出将prefill与decode分离（即PD分离，或PD disaggregation），放到不同GPU或不同节点上，以减少两个阶段的互相干扰。相关早期经典工作如《Splitwise: Efficient generative LLM inference using phase splitting》的SplitWise，《DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving》的DistServe和《Inference without interference: Disaggregate LLM inference for mixed downstream workloads》的TetriServe。在两年左右的时间里，PD分离已从论文中的POC到现在各大推理引擎中的事实标准。尤其是对于像DeepSeek V3/R1这样的大模型，几乎已成为标配。有了PD 分离后，为了便于区分，原来的模式一般称为Monolithic, co-located PD或PD aggregation模式。

PD分离是一种思路，不限于手段与形式。业界也有一些利用GPU底层机制来实现单卡PD分离的，这样的好处是避免了KV cache跨卡或跨机传输的开销。如：

《semi-PD: Towards Efficient LLM Serving via Phase-Wise Disaggregated Computation and Unified Storage》基于NVIDIA提供的MPS通过SM的切分来做同一GPU上的PD分离。
《Optimizing SLO-oriented LLM Serving with PD-Multiplexing》利用CUDA中的green context机制（在CUDA 12.4中引入）进行SM的切分做PD分离，并引入了调度机制可以自适应地调节P和D实例的计算资源。

除了减少两个阶段执行时的干扰，将两者分离还可以方便独立对其做优化。这些优化有多个方面：

并行策略：Prefill与decode阶段可能适合不同的并行策略。如《Dynamo Disaggregation: Separating Prefill and Decode for Enhanced Performance》中提到decode阶段采用大TP而prefill阶段采用小TP。《FlashComm2大模型推理中以存换传的通信优化技术》中提到prefill一般采用TP，减少卡均计算量。Decode阶段一般采用DP，减少通信次数。《DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving》中的实验得出prefill与decode阶段适合不同的TP与PP配置。
执行方式：在prefill与decode中对算子可能会采用不同的实现。如DeepSeek V3中，MLA在decode阶段会通过矩阵吸收将之转为MQA计算，而prefill阶段不会。Deep EP在prefill与decode阶段分别采用normal与low latency模式。另外，decode阶段一般会用CUDA graph（需要占用额外memory），而prefill因为动态长度不会用。Piecewise CUDA graph可用于prefill阶段使能CUDA graph，但Attention一般不会走CUDA graph。
资源分配：Prefill与decode计算资源可以按需求配比，甚至自动增加和缩减。在异构集群当中，我们还可以根据prefill和decode阶段的资源需求特点，将prefill分配给那些算力强的节点；而decode分配给memory多带宽高的节点。进一步地，像论文《SPAD: Specialized Prefill and Decode Hardware for Disaggregated LLM Inference》中提出为prefill和decode节点根据其特点分别设计相应的硬件。

PD分离架构下主要性能挑战就是KV cache的管理与传输。在典型的PD分离场景中，完整的推理过程包括prefill实例上做计算，KV cache从prefill传到decode实例，decode实例做计算。这带来了几个挑战，如prefil和decode实例的调度，KV cache的管理与传输优化等。

KV Cache管理与传输

KV的管理有中心式与分布式两种，或者两种的混合。另一方面，流行的LLM推理框架中都包含了利用层次化存储（HBM，DRAM，SSD, NVMe, Remote）对KV cache进行管理与传输的模块。工程上一般它们以后端的形式实现。如：

SGLang的HiCache（Hierarchical KV caching）的后端有：File, NIXL, Mooncake, AIBrix, 3FS, EIC。其中的3FS是DeepSeek自研的高吞吐的分布式文件系统。DeepSeek基于它做了共享存储分布式数据处理系统3FS-KV，实现了Context Caching on Disk技术。详细在论文《Fire-Flyer AI-HPC: A Cost-Effective Software-Hardware Co-Design for Deep Learning》中有介绍。
vLLM中的KV connector后端有Shared storage，p2p NCCL, LMCache, NIXL, Multi connector与Offloading。
TensorRT-LLM的KV传输模式有DRAM, GDS和POSIX。传输后端有MPI, UCX, NIXL等。
论文《Serving Large Language Models on Huawei CloudMatrix384》的CloudMatrix-Infer提出peer-to-peer serving architecture，将系统分为三个子系统。除了prefill与decode，还有用于context caching和model caching的caching subsystem。它的caching cluster构建于disaggregated memory pool上。Matrix384上的超高带宽连接使prefill与decode可以直接访问共享的disaggregated memory pool。这样就避免了调度需要考虑KV cache locality所带来的复杂性与开销，也有利于负载均衡。

将KV cache放到更低的存储层次上，自然可能会有性能的问题。为了减少相关开销，可以从几个方面优化：

论文《Splitwise: Efficient generative LLM inference using phase splitting》中的Splitwise中采用layer-wise的方式来传输KV cache，使计算与传输可以overlap起来。论文《Cost-Efficient Large Language Model Serving for Multi-turn Conversations with CachedAttention》提出CachedAttention，采用layer-wise pre-loading和async saving使KV cache的访问与GPU计算overlap。为了提升从disk加载的性能，它使用scheduler-aware KV cache fetching策略。该策略会prefetch那些更大概率将被访问的KV cache从disk到host memory。
《SGLang HiCache: Fast Hierarchical KV Caching with Your Favorite Storage Backends》中调整KV cache的layout，从Layer-first到Page-first，从而使要传输的内容尽可能相邻，提高传输效率。

调度

单纯的调度（如round-robin）可能会导致KV cache的重复计算和负载不均衡。PD分离架构下的调度既需要尽可能将请求放到shared prefix多的节点以避免重复计算，另一方面还要考虑到节点间的负载均衡。也就是说调度需要做到locality-aware和load-aware。当两者有矛盾时需要做trade-off。

大多数LLM推理框架都做了这方面的工作，如：

Dynamo中的Smart Router会根据KV cache的hit rate，workload balance和GPU capacity来派发请求。可参考《NVIDIA Dynamo, A Low-Latency Distributed Inference Framework for Scaling Reasoning AI Models》。
SGLang中的Cache-Aware Load Balancer在router中维护工作实例当中radix tree的近似版本，通过预测KV cache的hit rate并根据它来选择实例。可参考《SGLang v0.4: Zero-Overhead Batch Scheduler, Cache-Aware Load Balancer, Faster Structured Outputs》。
vLLM中的KV cache Aware Routing可将请求派发给KV cache hit rate最高的实例。如果没有足够长的prefix匹配到，会fallback到其它的routing方式（如load-based）。可参考《KV Cache Aware Routing》。
DeepServe中的Locality-aware scheduling实现了基于prompt tree的调度策略。它和SGLang的做法类似，也是通过维护global tree与local tree来实现。可参考论文《DEEPSERVE: Serverless Large Language Model Serving at Scale》。
Mooncake采用以KV cache为中心的分离式架构，可参考论文《Mooncake: Kimi's KVCache-centric Architecture for LLM Serving》。全局调度器（Conductor）选取尽可能reuse KV cache的prefill实例，然后以chunk/layer为单位以pipeline的方式进行prefill计算，并传给对应的decoding实例，最后在decoding实例中以continuous batching方式进行计算。同时它还要考虑到不同prefill节点的负载均衡，以及TTFT的SLO目标。为了减少传输和memory开销，它会对最热的block在多个节点复制，对最冷的cache换出。此外，为了更好地让计算与通信并行，对于prefill实例，KV cache的load与store以layer-by-layer的方式进行，并且与prefill计算并行。对于decoding实例，KV cache的load以异步的方式进行，与decode计算并行。
论文《TokenLake: A Unified Segment-level Prefix Cache Pool for Fine-grained Elastic Long-Context LLM Serving》中的KV cache-aware routing机制在每个实例上维护本地prefix tree。对于每个请求，router会基于shared prefix的hit rate与load balancing策略决定发往哪个实例。但可能出现问题：1) 高hit rate的实例内存带宽过度使用，低hit rate的实例用不满。2) 为了均衡实例间的计算负载，具有shared prefix的请求会在实例间复制，造成冗余。3) 所有的prefix需要放在相同实例，以组成prefix tree。不同实例的slot不能共同使用，导致碎片化。论文提出一个segment-level的prefix cache pool，用于long-context的LLM serving。并基于它提出了heavy-hitter-aware segment-level load balancing算法提升负载均衡和去重，以及基于bipartile matching的dispatching算法最小化query和prefix cache的通信量。
论文《MemServe: Flexible Mem Pool for Building Disaggregated LLM Serving with Caching》引入了MemPool，它是一个弹性内存池，用于管理分布式（包括CPU DRAM和GPU HBM）的KV cache。通过它提供的API可构建PD-colocated实例与PD分离实例。Global scheduler通过global prompt tree-based locality aware policy可以加强cache reuse。

除了以上因素外，PD分离架构中调度还需要考虑的是：

是否要用PD分离

PD分离并不一定能带来收益。通常PD分离在高负载长prompt，TPOT的SLO较为严苛的场景下会有较大的收益，而在低负载的情况下性能可能并不比传统的方式更好。这时候就需要根据输入来选择是否用PD分离。如DeepServe中的PD-aware Scheduling用算法进行选择。Dynamo Planner会根据传输KV cache的时间，GPU的queue等待时间和disaggregated与aggregated方式的估计处理时间来决策是否使用分离方案或者是否需要添加GPU，并保证在scale-down时不会丢掉请求。

本地做还是远端做

由于通信开销等因素的存在，有时候严格按照PD分离的流程做效率未必高。比如，如果prompt很短又或者decode实例中有很高的prefix cache命中，那在decode实例中做prefill任务可能效率更高。这时候decode实例会执行prefill和decode的混合任务，其实就变成了传统的co-colated PD模式。Dynamo中的worker既可以执行prefill也可以执行decode请求。当它收到请求时，会由router先根据prefill长度和prefill queue状态决定在本地还是远端做prefill。更进一步地，prefill和decode实例都可以做混合任务。如论文《Prefill-Decode Aggregation or Disaggregation? Unifying Both for Goodput-Optimized LLM Serving》中提出的TaiChi。在hybrid-mode inference中，P-heavy实例为prefill任务优化，具有更大的chunk size。D-heavy实例为decode任务优化，chunk size较小。两种实例都可以处理包含prefill与decode任务的混合batch，同时又允许同一请求的prefill与decode阶段在不同的实例上。

资源分配

PD分离架构中还有个很重要的参数就是prefill和decode实例的数量。DeepSeek V3官方报告中只给出prefill与decode实例的配置，但没有给出具体的数量或比例。网上对于prefill和decode实例的比例进行过讨论：《deepseek v3为什么pd比例达到了1比10?》。《SGLang v4.8.0 PD分离性能研究》中根据官方公布的服务总量与处理速度数据进行估算，得到decode与prefill节点比例约为1.4，P4D18的组配置比例为3.27:1。《DeepSeek V3/R1 推理效率分析（2）: DeepSeek 满血版逆向工程分析》中也有推算过，得出组比例约为24:7。

但是，这个比例与模型、硬件和请求的负载都有关。实际当中是需要动态调整的。论文《Beyond the Buzz: A Pragmatic Take on Inference Disaggregation》对PD分离架构的做了分析并提出一些建议，如PD分离对于prefill-heavy的场景和更大模型较为高效，更大的NVLink域对PD分离有好处，对DeepSeek R1模型NVLink域范围内建议用EP。DP面向高吞吐，TP面向低延迟等。关于prefill与decode实例的比例问题，它提到在PD分离场景下，需要rate matching策略来确定prefill和decode实例的比例。总的来说，需要prefill的总处理速率约等于且小于prefill的总处理速率。文中提出的rate matching算法考虑了SLO限制，以最小化GPU数量为目标，用整数规划得到prefill与decode阶段吞吐平衡下的最佳配置。

面对负载的波动，当计算资源不够时，需要考虑Auto-scaling。很多框架中也会有这样的机制。如:

Dynamo中的Planner会持续监控相关指标，并考虑SLO，做出是否要添加额外GPU的决策。
AIBrix支持可配置的autoscaling策略，利用Knative Pod Autoscaler和AIBrix Pod Autoscaler中的算法进行autoscaling。
DeepServe中的AutoScaler模块会根据负载和SLO相关指标决定是否需要scale，并做了一些优化提高新实例启动的效率。

Attention-FFN分离与微服务化

PD分离的每个rank上仍是完整的网络。进一步的模块化是将网络拆分。Transformer网络架构主要包含Attention和FFN/MoE两个模块。Attention与FFN或MoE模块有着不同计算特点和资源需求。Attention模块是需要维护状态（KV cache）的，意味着需要有大量的内存访问，容易成为memory-bound（也不绝对，比如FlashMLA在很多时候是compute-bound的）。它的复杂度与batch size和seq len相关。而MoE模块是无状态的，但是容易因为load imbalance问题无法打满硬件。它的复杂度只与batch size相关。这种差异可能会带来一些问题，比如MoE需要较大batch size才能让每个rank达到高的硬件利用率，而Attention需要大量的memory用于KV cache以及SLO等因素又会限制batch size。这会带来矛盾。一种思路是像论文《MOE-GEN: High-Throughput MoE Inference on a Single GPU with Module-Based Batching》中提到的，在Attention后做一个聚集，从而将更大的batch传给MoE。这种做法可用于单卡配置下。那在多卡或多机下，就可以将两者分离放到不同的卡或节点上。这样就可以独立进行scale使各个模块的负载平衡，还方便异构集群的部署。

Attention与FFN分离的思想是近两近开始热起来的。这方面比较经典的工作如：

论文《Efficient Heterogeneous Large Language Model Decoding with Model-Attention Disaggregation》中的Lamina将Attention与其它模块分离并部署到异构集群上。它将需要大量KV cache访问的Attention放到访存带宽性价比较高的的设备，而其余部分则放在算力较强的设备上。
论文《MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism》将这种思想扩展到了MoE。它将Attention与MoE模块分离，并把它们放到独立的GPU上。使它们可以独立scale，应用不同的并行策略，或异构布署。另外它使用M2N通信库减少不必要的GPU到CPU的数据拷贝和一些初始化及同步开销。
论文《Step-3 is Large yet Affordable: Model-system Co-design for Cost-effective Decoding》进一步将这种思想应用到更大规模的模型。它引入的关键优化之一是Attention-FFN Disaggregation（AFD）。它采用多段流水线hide通信开销，并开发和开源了AFD专用的通信库StepMesh。它基于GPUDirect RDMA，将通信操作放在CPU上，不竞争SM。

这一方面，主流的推理引擎如SGLang和vLLM都已开始考虑，可参见SGLang的相关链接与vLLM的相关链接。

如果将这种分离的思想更进一步，可以将计算过程中的组件独立出来，以微服务（microservice）存在，并以高速网络连接起来。这样使得部署和scale更加灵活，鲁棒性也更高。

论文《Serving Large Language Models on Huawei CloudMatrix384》展望了component-level disaggragation。它将LLM分解成fine-grained microservice（如Attention, FFN, KV cache management，MoE expert gating等）。这样，它可以让microservice放到最适合的硬件上，也可以让互补的microservice放在同节点上，还可以让microservice独立scale以应对实时的负载变化。
论文《xDeepServe: Model-as-a-Service on Huawei CloudMatrix384》中的disaggregated MoE-Attention方案将Attention，MoE分别放到独立的卡上，应用到DeepSeek-V3/R1的decode阶段。同时，还提出了如专用于该方案的通信原语A2E和E2A等优化。文中还展望了进一步的形态-Transformerless，即将基于transformer的LLM拆分成Attention, FFN和MoE各模块，在高速互联的独立卡上执行。并在这样的架构下做到避免全局同步，从而提高scale能力。
论文《Expert-as-a-Service: Towards Efficient, Scalable, and Robust Large-scale MoE Serving》指出现有的系统的布署单元scaling粒度过粗不够灵活，依赖的大规模collective通信实现在初始化时建立静态的进程组。文中提出将MoE模式解耦出来，成为独立的stateless的服务。这种从monolithic deployment到service-oriented architecture的变化使得scale能以单个GPU为粒度，单个GPU出问题无需重构全局通信组提升鲁棒性，以及更容易处理动态的负载。另外，文中指出现有通信库的局限。如NCCL缺少single-sided P2P操作，像NVSHMEM等基于RDMA的库依赖symmetric buffer，StepMesh等需要CPU控制，因此开发了基于low-level IBGA（InfiniBand GPUDirect Async）的非对称异步P2P通信库。

并行策略

在大模型的部署中，并行策略（Parallel Strategy）对性能的影响非常大。不同的并行策略会影响访存数据量和通信数据量。且不同的模型，不同的硬件等因素都会影响最优的并行策略选择。

Attn DP or TP

以DeepSeek V3为例，根据官方技术报告，DeepSeek V3部署在H800集群，采用PD分离架构。Prefill阶段的部署单位为4个节点32个GPU。Attention部分采用TP4+SP4+DP8。TP与SP组可以复用，因此4x8=32。MoE部分采用EP32让每个专家处理的batch size足够大。Dense MLP部分采用TP1。小TP是为了避免通信开销。Decode阶段的部署单位为40个节点320个GPU。Attention部分TP4+SP4+DP80。TP与SP组复用，因此4x80=320。MoE采用了EP320（一卡一专家，256个专家外加64个冗余专家）。采用这么大的EP是为了让加载专家参数的访存开销最小化。另外，官方文章《DeepSeek-V3 / R1 推理系统概览》中给出了一个规模稍小一些的部署方案：

Prefill：路由专家 EP32、MLA 和共享专家 DP32，一个部署单元是 4 节点，32 个冗余路由专家，每张卡 9 个路由专家和 1 个共享专家

Decode：路由专家 EP144、MLA 和共享专家 DP144，一个部署单元是 18 节点，32 个冗余路由专家，每张卡 2 个路由专家和 1 个共享专家

这里Attention使用了DP。对于大模型中的MHA，常见的做法是在head维度用TP。DeepSeek中的MLA为了减少KV cache，让所有的head共用KV cache。在这种情况下，如果用TP会导致KV cache的拷贝（复制数为TP size除以KV head number）。对于大模型来说，KV cache通常是仅次于模型本身的大头。很多时候，吞吐上不去就是因为用于KV cache的内存不够，导致batch size上不去。这种情况下用DP可以解决问题。因此，像用了MLA、MQA和GQA的模型部署时会用Attention DP。为处理这种KV cache duplicate的问题还有个思路就是KV partitioning（KVP），即将KV进行sharding。可参见论文《Helix Parallelism: Rethinking Sharding Strategies for Interactive Multi-Million-Token LLM Decoding》。

但是，Attention DP也会带来一些缺点：

带来模型权重的拷贝。好在对于DeepSeek V3来说，MLA的参数量只占总体的1~2%。
相对TP来说，latency会变长，影响SLO。
Load imbalance问题。更多的解决方案在后面DPLB一节再展开。

MoE EP or TP

另外就是EP的使用。DeepSeek V3使用了大规模EP。其规模在decode阶段甚至达到了一个卡放一个expert。文中提到这样可以最小化访存开销，防止decode阶段由于batch size较小而bottleneck在访存上。那在小规模部署上，MoE是用EP还是TP呢。可以从几个角度考虑：

通信量：在TopK中的K小于卡数时，EP的通信量比TP小。推导可见文章《MoE 训练到底是开 TP 还是 EP？》或论文《MegaScale-MoE: Large-Scale Communication-Efficient Training of Mixture-of-Experts Models in Production》。
计算友好性：TP下每个rank都包含所有专家（Fine-grained MoE中专家数量有上百个），但每个专家只有1/TP。这样会形成很多小的GEMM。而在EP下，每个rank只有少量专家（如EP320下只有一个），且本地只需要计算当前专家需要处理的token。这样会形成大的GEMM，对硬件更友好。
对DP的影响：EP与DP的组可以复用。其实EP本身也可以理解为token粒度的DP，每个rank处理不同数据。而TP与DP一个是rank间处理相同数据，一个是处理不同数据，不会共享组。举例来说，world size=n的情况下，EP为n，DP也可以为n。而如果TP为m，那DP就得为n/m。
EP会有workload imbalance问题，而TP不会。关于这个问题后面再展开。

论文《EPS-MoE: Expert Pipeline Scheduler for Cost-Efficient MoE Inference》中有定量分析过TP+TP，DP+EP和TP+EP三种并行策略的数据访问量与通信数据量。结论是对于MoE的数据访问量，有： W D P + E P = W T P + E P < W T P + T P W_{DP+EP} = W_{TP+EP} \lt W_{TP+TP} WDP+EP=WTP+EP<WTP+TP，对于通信数据量，有 V D P + E P < V T P + E P < V T P + T P V_{DP+EP} \lt V_{TP+EP} \lt V_{TP+TP} VDP+EP<VTP+EP<VTP+TP。也就是说DP+EP的方案在只考虑吞吐的情况下是最优的。因此，可以看到大多数DeepSeek V3的部署方案中，Attention DP + MoE EP是较为常见的配置。

但现实中由于其它因素的考量（如SLO），会考虑一些混合策略，如：

《Together with SGLang: Best Practices for Serving DeepSeek-R1 on H20-96G》中在H20双节点方案中的prefill阶段，为了满足SLO中的TTFT目标以及让资源管理更简单，使用了TP。
论文《Pangu Pro MoE: Mixture of Grouped Experts for Efficient Sparsity》中的Pangu Pro MoE采用hierarchical & hybrid parallel策略，其中Attention部分采用DP2+TP4减少跨CPU通信。Routed expert中采用TP与EP混合平衡expert imbalance与suboptimal shape的影响。Shared experts由于计算量是均衡的，使用了TP8。
CloudMatrix-Infer中采用了staged hybrid parallelism解决DP中sequence-length skew（不同rank上的请求长短相差很大）和insufficient concurrency（在进行中的请求数小于DP size）的问题。它将MLA分为三个阶段采用了不同的并行策略：第一阶段input处理和down_proj，以及第三阶段的o_proj，由于不依赖token位置，可以用SP。这样，可以将请求以token粒度均匀分布在rank上。而第二阶段中q_up_proj，kv_up_proj和FlashAttention，采用TP保证工作负载的均匀分布。在第一阶段与第二阶段间插入AllGather，第二阶段与第三阶段插入All-to-All。

其它

除了Attention与MoE两个大模块，其它部件的并行策略的选择上也需要考虑内存占用，通信等多种因素。如：

Dense FFN：《Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs》讨论了DeepSeek V3的前三层Dense FFN用TP还是DP的问题。它采用了DP，基于几个原因：1) 大TP下切分后的维度太小，容易不满足GPU的alignment要求。2) 大TP虽然减少权重占用，但会让activation的占用变多。3) 最小化通信开销（如果Attention采用DP，那从网络输入到第四层前不需要通信操作）。
LM head采用TP还是DP，可根据不同场景选择。采用DP搭配Attention DP的话可以简化通信，但embedding矩阵需要在rank间复制。考虑矩阵shape硬件友好性可以用TP，但会引入通信开销。对于MTP中的LM head，《Scaling Expert Parallelism in TensorRT LLM (Part 3: Pushing the Performance Boundary)》中指出其在batch size较小容易成为memory-bound，因此使用TP来减少权重加载可获得性能提升。

对于DeepSeek V3/R1的整体部署方案中的并行策略，不同的目标（如throughput还是latency优先），不同的硬件都会产生影响。各家的基于不同硬件的方案，可参考以下文档的相关章节：

TensorRT-LLM：《Pushing Latency Boundaries: Optimizing DeepSeek-R1 Performance on NVIDIA B200 GPUs》与《Optimizing DeepSeek R1 Throughput on NVIDIA Blackwell GPUs: A Deep Dive for Developers》
SGLang：《Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs》
Ascend：《华为昇腾服务器 DeepSeek V3/R1 推理部署最佳实践》

负载均衡

大规模部署中有两大load imbalance问题。一个是前面提到的Attention中DP所带来的DPLB。它会让Attention模块的负载不均衡；另一个是MoE中EP带来的EPLB，它让MoE模块的负载不均衡。如果是通信采用all-to-all模式，那前者的表现是dispatch很长，后者表现是combine很长。

DPLB

对于DPLB，一个普遍的思想是集中调度。即所有的请求先收集在主rank上，然后再按一定的规则分发给每个rank。至于派发的规则，大体有几类：

比较常见的是round-robin，即大家轮流。实现简单，但局限是因为请求本身有长短，不同rank资源也有差异，可能导致不均衡。
按负载分派。将请求优先分发给负载较小的rank，以使不同的rank负载尽可能均衡。这个负载信息可以是基于实时信息采集和反馈的。

各个流行的LLM推理框架中大多有相关的特性：

SGLang：Load balance方法可选三种方式：round_robin, shortest_queue和minimum_tokens。看名字基本就知道大致用的什么策略。
vLLM：系统中有单个AsyncLLM前端（只在主节点）多个engine cores后端（所有节点都有）。主节点的AsyncLLM分发给engine cores。此外，系统中有独立的DP coordinator用于负载均衡和保证engine cores的同步。它从engine cores收集信息，并将这些信息发给API server。API server基于这些信息做负载均衡，然后把分派信息通过ZMQ发给engine cores。
TensorRT-LLM：除了基本的round-robin分发策略外，还提出了ADP Balance Strategy。它采用了一种等待机制来同步不同rank上的prefill任务。即当prefill任务来时不马上调度，而是采用一定的策略（等待时间可由参数调节）让多个rank都有类似的工作量再一起做。这样避免了一个rank上做prefill，其它rank做decode，做完了等前者的情况。
xDeepServe中的DP Load Balancing：FlowServe采用合作式scheduler让所有DP rank共享请求。由DP0上的leader scheduler用all-gather收集请求。然后，在prefill阶段使用一个cost model来分派请求。在decode阶段先排除达到batch limit的DP，再在其余的rank中挑选KV cache使用最少的rank。

EPLB

在采用EP的MoE中，80/20法则告诉我们，总会有一些专家会非常的热门。尽管网络结构与训练上会用到一些技巧（如分组专家，负载均衡loss函数，bias项等）来缓解该问题，但仍不可完全避免。大家也从实验当中证实了这一点。它带来的坏处就是所有rank都要等那个负载最重的rank跑完。一方面那些放置冷门专家的卡由于计算密度不够打不满硬件，另一方面在collective communication点时会出现大量的等待，造成硬件资源的浪费。

DeepSeek V3提出的EPLB（Expert Parallel Load Balancer）方案通过动态调度专家的负载分配解决该问题。它一方面引入冗余专家，即为高负载专家创建副本分担压力。论文中还提到dynamic redundancy策略，即每个GPU放多个冗余专家，但每次只有部分会被激活。另一方面基于运行时专家计算负载的统计信息，通过算法确定每个专家的位置，使得负载尽可能均衡且跨节点通信尽可能少。开源项目EPLB是DeepSeek官方的解决方案。它根据负载统计信息给出冗余专家和专家placement的计划。它包含两种算法分别适用于不同场景：

Hierarchical Load Balancing：当节点数量整除专家组数量时，使用该策略可以充分利用到group-limited expert routing机制。先将专家组均匀分布到节点，以保证节点间均衡。然后在每个节点内复制专家，最后将这些专家放于GPU上保证不同GPU之间的均衡。该策略一般用于小EP的prefill阶段。
Global Load Balancing：其它场景下可用该策略。该策略不考虑专家组，而是在全局范围内复制与分配专家。适用于更大EP的deocding阶段。

具体到工程实现上有online和offline两种方式。Offline的方式先跑数据统计，生成专家的placement配置，然后根据该配置进行初始化。这种方式的好处是实现简单，但专家的负载模式是会随着输入的改变而改变的。显然这种方式无法适应变化。因此，理想情况下专家的位置需要动态调整。这种情况下，流程一般分为这几步：

收集token统计信息
EPLB算法选择冗余专家并确定它们的placement
系统更新专家到device的mapping
用更新的mapping和进行模型执行

DeepSeek V3论文中提到调整周期为10分钟，但没有给出更多细节。Online的方式可以细分成两种：一种是同步的方式，即执行专家动态调整时不做模型的推理。异步的方式是两者一起做，保证服务尽可能丝滑不卡顿。显然，后一种更为理想，但实现也会更复杂，对硬件要求也会更高。目前主流LLM推理框架中基本都支持了online异步的EPLB，如：

TensorRT-LLM中支offline与online两种形式，可以参见官方说明《Expert Parallelism Load Balancer (EPLB)》。Online形式中支持以layer-wise方式进行EPLB，使得专家调整对性能影响尽可能小。基本原理可见《Scaling Expert Parallelism in TensorRT LLM (Part 1: Design and Implementation of Large-scale EP)》。文章《Attempts at Online EPLB Implementation》中介绍了支持online EPLB中权重更新所用的一些技巧。
SGLang：Asynchronous Dynamic Load Adjustment机制使load balancing和inference解耦。它采用hierarchical transfer strategy，保证transfer时可以做inference。详细请见《Asynchronous Dynamic Load Adjustment》。
vLLM：官方版本支持EPLB，但似乎是同步的实现。其衍生版vLLM Ascend Plugin支持Zero-Overhead Movement可以不打断推理，异步进行expert redistribution。详细请见其官方说明《Expert Load Balance (EPLB)》。

DeepSeek最近又开源了LPLB（Linear-Programming-Based Load Balancer）。它扩展了EPLB，实现了实时的负载均衡。相对于EPLB是基于一段时间的统计信息做均衡，它是每个batch都会做调整。在EPLB的基础上，它将token的分配问题建模成线性规划问题，然后利用单SM的内点法求解器在亚毫秒级求解。最后用NVLINK和NVSHMEM进行token的高速传输。

业界有不少对于EPLB的优化，一类是对于placement算法的改进，如OmniPlacement。还有一类是利用expert affinity信息。如：

《Together with SGLang: Best Practices for Serving DeepSeek-R1 on H20-96G》中的Expert Affinity EPLB通过跟踪top-k expert co-activations构建expert affinity matrix。标准的EPLB平衡GPU内的负载但忽视了expert间的关联，常常会将一起激活的专家分散到不同节点上，导致跨节点间通信开销增大。在GPU内负载均衡后，调整placement使共同激活的expert在同一个节点内。
论文《Exploiting Inter-Layer Expert Affinity for Accelerating Mixture-of-Experts Model Inference》中的ExFlow利用inter-layer的expert affinity信息，通过建模成integer progrmming得到expert placement减少通信开销。
论文《MOETUNER: Optimized Mixture of Expert Serving with Balanced Expert Placement and Token Routing》主要解决EP的load imbalance和communication skew的问题（后者导致GPU间数据传输的不平衡）。该文提出用Integer Linear Programming (ILP)在考虑token load, 通信和计算开销的基础上优化expert placement。它利用了跨layer的token routing依赖。即在某一层被送到特定专家的token，在下一层大概率会被送到一个有限的专家集合中。MoETuner给出最小化GPU间token路由开销和设备间的token均衡。

对于expert placement的优化除了可以减少imbalance问题，还可以用于减少通信量，如论文《Speculative MoE: Communication Efficient Parallel MoE Inference with Speculative Token and Expert Pre-scheduling》中的Speculative MoE通过speculative token shuffling和speculative expert grouping两种方法减少EP的通信开销。它利用intra-layer token-expert affinity和inter-layer expert expert affinity对token的expert路由进行预测。将token与expert尽可能放在一起的优化问题建模为ILP问题，其解用于online的speculative token shuffling和offline的speculative expert grouping。前者用shuffled-reduce-scatter/shuffled-allgather代替all-reduce，它将token与对应expert放在一起。后者将token所用到的的expert放在一起。

通信优化

通信-计算Overlap

在一些情况下计算与通信用的不同的硬件，因此我们会想尽可能将它们overlap，这样便可以将通信的耗时给hide起来。在DeepSeek V3之前，大家的注意力主要在GEMM与AllReduce之间的overlap，AllReduce与Residual/RMS的融合优化这些。像早期的Flux，用于MoE的Comet，基于CodeGen的TileLink，基于NCCL的FlashOverlap，基本思路都是将计算进行切分，然后进行细粒度的overlap。在DeepSeek V3之后，大家开始关注MoE的all-to-all（dispatch与combine）与GEMM的overlap。

DeepSeek开源了项目DeepEP，用于large EP MoE的all-to-all通信。它提供了两种模式：Normal模式适合高吞吐场景的prefill阶段。Low latency模式适合decode阶段，兼容CUDA graph。缺点是占的内存会比较多。该库提供了SM数量控制和hook-based的特性，方便与其它算子进行overlap。

对于通信，一方面是对于DeepEP本身的优化，如MNNVL，PPLX，CANN EP, Mooncacke EP。另一方面就是通信（all-to-all）与计算的overlap。DeepSeek V3网络中从Attention到dispatch到MoE再到combine，从逻辑上是前后依赖的（除了shared expert）。为了创造更多overlap的机会，DeepSeek V3引入了Two-batch overlap（TBO）。为了破除数据依赖，它将batch一拆为二，变为两个micro-batch。这样当一个micro-batch在做计算时，便可以同时做另一个micro-batch的通信了。对于DeepSeek V3模型具体的策略可见官方的Profiling Data in DeepSeek Infra。TBO已经在SGLang，vLLM和LightLLM等推理框架中实现了。

TBO本质上是将两个micro-batch做编排。其策略与模型和硬件都是相关的。比如CloudMatrix-Infer根据硬件特点设计了DeepSeek V3的TBO编排。在prefill阶段，它将计算（Attention与MLP等）主要放在AIC上，low-intensity auxiliary computation（如token reordering and metadata generation）放在AIV上，数据传输放在SDMA上。通过这样异构的部署减少资源争抢。在decode阶段，它将AIC与AIV计算单元在两个stream上做了分配，然后将Attention与MoE分别放在两个stream上面做overlap。

论文《TokenWeave: Efficient Compute-Communication Overlap for Distributed LLM Inference》采用了类似的思想，并做了一些优化：1）提出Token-Splitting技术将batch切成大致相等的两个子batch（token粒度而非request粒度切分）并在切分时考虑避免wave quantization。这样，一个子batch的计算与另一个子batch的通信可以overlap。2）优化LayerNorm与通信的顺序。将AllReduce拆分成Reduce-Scatter与All-Gather，然后将LayerNorm放在中间减少计算量。为了弥补AllReduce拆分带来的overhead，将AllReduce与RMSNorm的kernel进行了融合。

虽然TBO在一些情况下能通过计算与通信的overlap带来性能收益，但它也有缺点。在decode阶段，它会让batch size减半降低计算密度，又或者因为CUDA graph和WGMMA的对齐要求引入冗余计算。但如果提高batch size又会让低算力卡无法达到SLO要求。那有没有可能在single-batch中做这部分的overlap呢？

《DeepSeek V3/R1 推理效率分析（3）：Decode 配置泛化讨论》中讨论过single-batch的compute-communication overlapping，并比较了多个场景中H800与H20上TBO与SBO的性能。
LangCat-Flash中引入了SBO（single-batch overlap），它是用于自身特殊的MoE与MLA并行的ScMoE网络结构。
《Together with SGLang: Best Practices for Serving DeepSeek-R1 on H20-96G》中提出了SBO方案，并在SGLang上做了实现。该方案一方面使shared expert与dispatch进行overlap，另一方面通过修改DeepEP和DeepGEMM使它们可以overlap起来。
论文《EPS-MoE: Expert Pipeline Scheduler for Cost-Efficient MoE Inference》中的expert pipeline scheduler将MoE中的专家进行切分然后和all-to-all进行overlap也是类似的思路。它将GroupGemm/DenseGemm与all-to-all通信并行起来。

通信还可以与除GEMM之外的部分overlap。如《FlashComm3大模型推理中的多流并行技术》中对于通信做了两种overlap：一方面将Gating计算及结果的通信，量化及量化后激活的通信，以及shared expert的计算放到多个stream中，从而将它们overlap起来。另一方面将通信和权重及KV cache的预取进行overlap。这应该也是论文《PRESERVE: Prefetching Model Weights and KV-Cache in Distributed LLM Serving》中提到的技术。

其它通信优化

减少通信开销，除了前面通过overlap的方式去hide外，还有几种思路：

减少通信量（通过量化或者等价变换）
- 论文《Serving Large Language Models on Huawei CloudMatrix384》中提到的early quantization，在dispatch前做INT8的量化，从而减少通信量。
- 《FlashComm大模型推理中的AllReduce通信优化技术》中将AllReduce拆成Reduce-Scatter和AllGather，将AddRMSNorm，Gating，QKV降维和量化操作移到两者中间。这样既可以减少中间那些算子的计算量（因为经过scatter），也可以减少通信的数据量（AllGather是低维，量化后数据）。《FlashComm2大模型推理中以存换传的通信优化技术》在FlashComm基础上进一步优化ReduceScatter。基于等价数学变换将升维矩阵乘和通信算子交换位置，从而减少通信量。具体来说，将Attention后的output projection（假设两者都用TP）与后面的ReduceScatter交换位置，然后将ReduceScatter换为all-to-all将output project从TP换成DP。这样，就可以在维度小的地方通信，且消除了卡间求和（ReduceScatter）。代价是内存占用变多。
- 论文《DeepSpeed-MoE: Advancing Mixture-of-Experts Inference and Training to Power Next-Generation AI Scale》中的parallelism coordinated communiation optimization考虑在TP接EP的场景中，由于TP各rank上的数据是一样的，因此all-to-all可以只在TP rank相同的卡上做。EP后接TP也是类似的。
- 论文《A Hybrid Tensor-Expert-Data Parallelism Approach to Optimize Mixture-of-Experts Training》中的Duplicate token dropping用于减少all-to-all通信中不必要的数据。由于TP的各卡的数据是重复的，需要在all-to-all前将冗余的token去掉。
拓扑优化（利用节点内和节点间通信速率的差异）
- 论文《DeepSpeed-MoE: Advancing Mixture-of-Experts Inference and Training to Power Next-Generation AI Scale》中的hierarchical all-to-all是一个两步的过程：第一步中先做data-layout transformation后接节点内all-to-all；第二步做data-layout transformation后接跨节点all-to-all。虽然通信量增加了，但由于前者可以并行，且节点内通信较快，所以能提高性能。
- 论文《Flash Communication: Reducing Tensor Parallelization Bottleneck for Fast Large Language Model Inference》中的two-step AllReduce同时利用了拓扑优化与量化。它分为三个阶段：1)量化后做all-to-all。2)单rank内做reduce得到局部结果。3)量化后用AllGather广播局部结果。收到后做反量化。这样使得传输数据量减少，且reduce次数减少。

MTP

MTP是投机推理的一种形式，它不需要额外的draft model，而是在模型尾部加一个transformer block来预测draft token。据称acceptance rate可达到80%~90%。由于verification是可并行的，因此它可以提高decode阶段的计算密度。

对MTP有优化有几个方面：

多层MTP
- DeepSeek V3官方公开了一层MTP的权重，但部署时可以通过堆叠该层来达到一次预测多个token的效果。这也是最常见的MTP相关优化之一。但是，越到后面的MTP，其acceptance rate自然也会越低。
提高acceptance rate
- Relaxed Acceptance：在non-thinking阶段仍采用传统方法。而在thinking阶段，主模型通过输出多个token candidate，去除那些概率过低的。只要有一个candidate与draft匹配上就接受，从而提高acceptance rate。可参考《MTP optimization - Relaxed Acceptance》。
- Tree-based speculation：相比传统的chained-based投机推理方案，Tree-based方案可以扩展候选组合，从而提高acceptance rate。
- MTP fine-tuning：论文《xDeepServe: Model-as-a-Service on Huawei CloudMatrix384》中提到通过训练第二个MTP提高其acceptance rate。论文《FastMTP: Accelerating LLM Inference with Enhanced Multi-Token Prediction》中也提到了通过训练MTP层显著提高，尤其是第二和第三层MTP的acceptance rate。
- 太极AngelHCF通过调节超参数及网络（如MTP的LM head加norm算子）进行优化。
减少计算量
- 论文《FR-Spec: Accelerating Large-Vocabulary Language Models via Frequency-Ranked Speculative Sampling》中提出LM head中vocabulary中其实有75%的token出现概率累加少于5%，因此可以在MTP中的LM head只考虑高频token部分。这样就减少了投机阶段的计算量。但在verify阶段仍使用完整vocabulary以保证结果的正确性。
与主模型融合
- 《昇腾高吞吐投机推理框架FusionSpec》中将MTP层作为模型的一部分，并利用主体模型的控制参数。这样，将输入的准备从两次减少到一次，同时省去了控制参数的构造开销。另外，它实现了与multi-step与async post-processing的兼容，以及MTP中MLA的算子优化，通过调整计算流程与tiling方式减少了Q和K矩阵的搬运量。
- TensorRT-LLM在《Combining Guided Decoding and Speculative Decoding: Making CPU and GPU Cooperate Seamlessly》中介绍了两种实现：one-model和two-model实现。其中one-model实现是将主体模型与draft model放到一个CUDA graph中。该方案中CPU-GPU的同步会带来一些挑战。
- LongCat-Flash中的TVD fusing策略将target forward, verification, draft forward融合进一个CUDA graph中。
- 太极AngelHCF将主模型和MTP模型整个前向使用同一个CUDA graph执行, 有效避免小算子空隙。

Simulator

DeepSeek V3模型很大，后面出现的模型中也不乏体积更大者。部署方案很多时候时候会涉及多卡多机集群。常见的问题是对于给定模型，找出其最优的配置（如batch size，并行策略等）。但各种排列组合很多，靠一个个试的话所耗硬件成本巨大，耗时也长。一种做法是用simulator来代替实跑。业界工作如：

项目Shallow Sim与DeepSeek Simulator是DeepSeek的simulator，可以基于各模块计算量与硬件参数对不同输入和并行策略下的性能指标进行估计。
论文《Beyond the Buzz: A Pragmatic Take on Inference Disaggregation》中提到它会使用GPU performance simulator。其输入为模型架构，traffic pattern和GPU配置，输出不同batch size和并行策略下的性能。这个simulator还可以用来确定co-located serving中不同ISL-OSL组合下prefill与decode的混合比例。
论文《BestServe: Serving Strategies with Optimal Goodput in Collocation and Disaggregation Architectures》中的BestServe通过Estimator，Simulator，Optimizer组成的框架确定serving strategy。Estimator用于预测operator级别的latency，simulator输出TTFT和TPOT等指标，optimizer寻找满足SLO的最大化goodput的serving strategy。