SGLang开源首个对标官方性能的DeepSeek-V3/R1 H100部署方案

SGLang开源DeepSeek-V3/R1的H100部署方案，性能匹敌官方，成本更低！

先说一个核心判断：大模型部署这件事，又往前迈了一大步。

刚刚，SGLang团队正式开源了他们部署DeepSeek-V3/R1大模型的方案。这个方案用96张H100（12个节点，每个节点8块GPU）跑起来，在预填充-解码分离架构和大规模专家并行（EP）技术的加持下，处理2000 token的输入序列时，单节点吞吐量达到了惊人的每秒52.3k输入token和22.3k输出token。请注意，这是目前第一个在开源实现中，性能如此接近DeepSeek官方博客报告的方案。更关键的是，在本地部署这条方案，每百万输出token的成本仅为0.2美元——这个数字，大约是官方Chat API成本的五分之一。

目前，SGLang团队还专门写了一篇文章，深入解析了这套部署方案背后的并行化设计、优化细节和实测数据。需要访问代码和博客地址的，可以看看文末的链接。接下来，我们就把这套方案的硬核内容拆开来看。

并行化设计

要让DeepSeek这种规模的大模型跑得高效，并行化是绕不开的坎。本节从上到下拆开来看：注意力层、稠密前馈网络（FFN）、稀疏FFN，以及语言模型（LM）头，每一层都用了量身定制的并行策略。

注意力层

DeepSeek用的多头潜在注意力机制（MLA），核心优势在于建模长序列依赖。为了把这个优势发挥出来，SGLang引入了DP Attention数据并行策略，说白了就是让不同设备之间不再冗余存储KV缓存，这能大幅压低内存开销。DP Attention从SGLang v0.4开始就在用了，现在进一步支持了混合数据并行和张量并行，小批量场景下更灵活。

稠密FFN

DeepSeek-V3虽然只用了三层稠密FFN，但这一点计算量却可能成为内存上的“隐形冲击波”。SGLang在这里选的是数据并行（DP），而不是传统的张量并行（TP）。

为什么这么选？三点考量：

（1）扩展性更好。 中间维度高达18,432时，要是硬上TP32这种高并行度，会出现“单元碎片化”——算下来576个单元，但这个数不能被H100这种现代GPU的128对齐边界整除，计算效率和内存利用率都会受损。DP就没有这个烦恼。

（2）内存效率更高。 TP随着计算单元增加会降低内存占用，但在DP注意力机制下这个优势不厉害了。数学推导告诉我们，在DeepSeek-V3这种中间维度下，预填充阶段的最佳TP并行度其实只有3甚至更低。解码阶段，128个token的典型配置下，最优TP也只是6。所以，靠DP而不是TP扩展，显然是更省内存的路径。

（3）通信开销更小。 纯TP方案里，每个FFN层都要做两次all-reduce，通信负担不小。换成DP后，只需要在前置注意力层后面做一次reduce-scatter，再到后续层前做一次all-gather，通信成本直接打对折。而且如果注意力层也用纯DP，设备间通信甚至可以完全消除。

下图（a）展示了DP稠密FFN与DP注意力的集成方案，设置--moe-dense-tp-size=1即可启用。

稀疏FFN

混合专家（MoE）架构里，稀疏FFN要存大量专家权重，内存上是个大问题。SGLang采用专家并行（EP）策略，把专家权重分散到多个设备上，既保持了高性能，又扩容了内存。当然，代价就是复杂的all-to-all通信和负载不均衡。上图（b）展示了基于DeepEP框架的EP实现版本，具体细节后面还会展开。

LM头

LM头要在大词汇表上算输出概率，传统做法是“词汇表并行”来聚合TP组的token逻辑值。这里SGLang延续了稠密FFN的思路，继续用数据并行（DP），既降内存开销，又简化通信。

预填充与解码分离

大模型推理天然分成两个阶段：预填充阶段（计算密集型，处理完整输入序列）和解码阶段（内存密集型，管理KV缓存逐token生成）。传统做法用一个引擎包揽，结果就是两个阶段混在一起调度，效率极低。SGLang的做法是彻底分开——预填充-解码（PD）分离架构。

统一调度的问题

• 预填充频繁中断：新来的预填充批次动不动打断正在解码的批次，延迟一下就上去了。
• DP注意力失衡：不同DP节点可能同时处理预填充和解码任务，解码延迟跟着涨。
• 与DeepEP不兼容：DeepEP对预填充和解码采用不同的调度模式，统一调度跟它根本玩不到一起。

PD分离现学现卖，通过阶段解耦，每个阶段都能享受量身定制的优化。

实现细节

SGLang的PD分离架构如何运作？预填充服务器与解码服务器交替执行，过程很直观：

1. 预填充服务器和解码服务器先“握手”配对，分别建立本地的发送端和接收端。
2. 解码服务器预分配好KV缓存后，通知预填充服务器启动模型计算。
3. 算好的KV缓存数据转移到解码服务器，开始逐token生成。

这套机制还支持：非阻塞传输（数据收发在后台跑，调度器完全不受影响）、RDMA加速（基于队列对和分散聚合元素实现高效传输）、灵活API（集成Mooncake/NIXL等RDMA库，适配不同数据接口）。

大规模专家并行

基于DeepEP的专家并行

DeepEP是DeepSeek团队专为MoE模型中的专家并行（EP）设计的通信库，核心是解决“如何高效地把token路由到正确专家”这个技术难题。它提供两种专用调度模式：

• 常规调度模式：针对长输入序列（预填充阶段）优化，优先保吞吐量。问题是生成的张量形状不固定，跟CUDA Graph不兼容，所以在解码阶段因内核启动开销太大而效率低下。
• 低延迟调度模式：专为解码阶段设计，目标是最小化延迟。它支持CUDA Graph，但需要预先分配固定内存，一旦超出就会触发运行时错误。

在SGLang中，DeepEP的自动模式可以根据负载自动切换调度方式。但如果不用PD技术，同一个通信组内不能同时支持两种模式，这就影响了它与DP注意力的兼容性。各模式兼容性如下表所示：

PD解耦技术正是为了解决这个矛盾：预填充阶段用常规调度，解码阶段切到低延迟调度，两者互不干扰，资源利用率拉满。

DeepGEMM集成

DeepGEMM是DeepSeek的另一块拼图，专为MoE计算优化。它提供两种分组GEMM专用函数：

• 分组GEMM（连续布局）：支持动态输入形状，很适合预填充阶段。连续拼接的专家数据输入，灵活性高。
• 分组GEMM（掩码布局）：固定输入形状，通过掩码只算有效部分，兼容CUDA Graph，解码阶段省开销。

两者与DeepEP的调度模式深度绑定：连续布局需跟常规调度配合，常规调度输出的符号化形状需要先通过置换操作（参考LightLLM项目里的定制Triton内核）变成连续格式，才能对接GEMM；掩码布局则跟低延迟调度天生一对，都优化解码阶段，都支持CUDA Graph。

另外，SGLang在张量并行下也集成了DeepGEMM。更进一步，DeepGEMM还提供了通用GeMM内核，通过设置SGL_ENABLE_JIT_DEEPGEMM=1即可启用，非MoE运算也能受益。

双批次重叠技术

多节点环境下，有限网络带宽是主要瓶颈。为此，SGLang在DeepSeek系统设计基础上实现了双批次重叠技术（TBO）。核心思路：把一个批次拆成两个微批次，计算和通信重叠执行，顺便因为有效批次变小还能降峰值内存。但落地上有两处难题。

实现挑战

1. 代码复杂性：直接写TBO逻辑会导致代码重复，后期维护调试都麻烦。
2. 预填充阶段的同步问题：DeepEP的常规调度会阻塞CPU，导致流水线停滞、GPU空闲，TBO的优势大打折扣。

抽象化实现方案

为了可维护性和复用性，SGLang引入了一套基于操作节点和暂停点的抽象层。开发者按单微批次的思路写代码，再通过策略性插入暂停点让其他微批次执行，代码不重复，还灵活支持未来升级（比如三批次重叠）。

预填充阶段重叠执行优化

关键优化点：先把计算任务提交到GPU，再启动阻塞CPU的调度操作。这样，就算调度操作因为等待其他节点的元数据而阻塞，GPU也能在通信期间保持计算活跃。下图里，采用合理启动顺序（加粗边框标示）的TBO成功规避了CPU阻塞导致的计算气泡。

专家并行负载均衡器

MoE模型里，专家并行经常导致GPU间工作负载不均。系统只能等最慢的GPU，既浪费计算周期，又因专家激活增加内存开销。而且GPU越多（EP规模越大），不均衡越严重。

DeepSeek的解决方案是专家并行负载均衡器（EPLB）。它基于专家分布统计数据，算出最优专家排布方案。用户可以分配冗余专家（比如在原256个基础上再加32个，共288个），然后让EPLB智能复制或组合专家——最常用的专家多复制几份，不常用的跟中等频率的专家叠放在同一GPU上。

EPLB还打破了原方案对并行规模（2的幂次方）的限制，现在支持12、72等更多样的配置。

下图展示了规模效应和EPLB算法对负载不均衡的影响。平衡性定义为GPU间MoE层的平均计算时间与最大计算时间的比值。可以看到，节点数增加时利用率会下降，但启用EPLB后提升很明显。

EPLB在实际服务中的优化应用

要让EPLB真正有效，输入分布必须跟实际服务负载高度匹配。SGLang靠两条路来实现：

• 增大批次尺寸：批次越大，专家使用频率的随机波动越小，负载自然越均衡。这可以通过扩展计算集群或采用多令牌预测（MTP）技术来实现。
• 周期性再平衡：利用时间局部性特征，定期更新专家分布，但需要高效实现专家重载，核心就是最小化重载带来的开销。

当然，就算有EPLB，负载不均衡也不可能完全消失，更多优化空间值得探索。

再平衡实现方案

SGLang的三阶段专家再平衡机制，效率很高且对服务影响很小：

1. 系统加载阶段：权重可以事先从磁盘加载到主内存（再平衡更快），或者用内存映射驻留磁盘（省内存）。
2. 再平衡准备阶段：需要的权重用空闲DMA引擎异步传输到设备内存，GPU当前任务完全不受影响。
3. 再平衡执行阶段：通过设备间拷贝完成权重更新，未来还可以靠物理内存重绑定进一步优化。

性能评估

端到端性能评估

实验配置

测试在12节点集群上，每个节点8块H100，通过InfiniBand互联。重点验证不同配置下的吞吐量提升。

• 基础版SGLang（TP16×6）：每两个节点一组，TP16 + DP注意力。
• PD解耦版：集成PD和完整的EP优化。
• PD解耦+模拟MTP版：通过翻倍批次、减半KV缓存长度模拟多令牌预测，假设接受率60%。
• DeepSeek官方数据：直接引用官方性能分析报告。

预填充与解码阶段性能分析

• 预填充阶段（4节点，EP32）：1K/2K/4K提示词对应的单节点吞吐量分别为57,674/54,543/50,302 tokens/秒。相比TP16基线，最高提升3.3倍，DeepGEMM和双批次重叠是主要功臣。理想情况下，吞吐量达官方数据的94.4%。
• 解码阶段（9节点，EP72）：2K输入时单节点吞吐量22,282 tokens/秒，相比TP16基线加速5.2倍。模拟MTP场景下（4K输入），仍保持17,373 tokens/秒，只比官方数据差6.6%。性能提升主要靠EP支持的4倍批次扩展，大幅降低了单GPU模型权重的内存占用。

性能对比结果

SGLang与DeepSeek推理系统的对比，尽可能贴近生产环境。以下是整体吞吐量和内核拆解两个维度的分析。

整体吞吐量

预填充阶段，单设备处理16,384个token、输入长度4,096。由于不确定DeepSeek的专家分布策略，这里评估了两种场景：默认分布和模拟理想EPLB（按分组限路由语义随机选专家）。

DeepSeek的分析报告显示其吞吐量大约是实际生产环境的两倍。SGLang在默认专家分布下比DeepSeek的结果慢20%，模拟完美EPLB后差距缩小到6%。

解码阶段的结果如下：

仅用DeepSeek一半节点时，模拟MTP的SGLang性能只比DeepSeek的配置略低。高批量下（256序列，2000输入长度），每节点每秒可处理22,282个token，扩展性很强。

详细分解

• 默认EPLB：时通信内核执行时间更长、波动更大，说明负载不均衡在拖后腿。
• 模拟完美EPLB：更接近DeepSeek结果，但还留有余地。
• 与单元测试对比：两者通信时间都比单元测试慢，而禁用TBO时可达到单元测试水平，提示下一步优化方向。

解码内核分解与DeepSeek高度吻合：

• 合并时间差异：注意力计算时间短，导致SGLang的合并操作比DeepSeek慢2倍，通信内核只能忙等待。模拟慢注意力后差距消失。
• MoE性能：SGLang比DeepSeek慢25%，很可能是DeepSeek用18个节点（我们只用9个）更高效地分配专家，减少了GEMM的内存访问开销。
• 调度优化潜力：两者调度时间都约0.17ms，但DeepEP单元测试显示理论上可优化至0.06ms。目前在发送/接收操作间插入慢速虚拟内核可降到0.09ms，还有进一步优化空间。

整体来看，解码性能已基本对齐，下一步重心是预填充阶段的优化。

消融研究：双批次重叠

批处理大小与注意力时间的影响

TBO在预填充阶段的收益是双重的：

• 支持更大批处理大小：默认每设备8,192个令牌上限，超过就OOM。TBO将上限提升到16,384个，性能提升40.5%。
• 提升吞吐量：通过重叠计算和通信，在相同令牌处理量下较默认配置提升27%~35%。

解码阶段的效果取决于批次和注意力时间：

• 实际场景：批次超过64~128令牌时才有显著加速。256令牌时速度提升25.5%，吞吐量22,310令牌/秒。
• 模拟MTP场景：128序列/设备时吞吐量提升35%（17,552 vs. 12,929令牌/秒），得益于注意力时间延长让计算和通信更好地重叠。

详细分析

三种预填充场景（TBO 16k、TBO 8k、无TBO 8k）的对比显示：

• TBO明显提升了效率。
• 从16k降到8k批次，内核效率略有下降。
• 无TBO的8k案例在内核速度上优于TBO 16k，可能是因为TBO的流式多处理器减少或重叠时的邻居干扰。

解码阶段（TBO 256、无TBO 256、无TBO 128）的时间分解揭示：

• 无TBO时通信时间增加，但GEMM因批次更大而更快。
• 与预填充不同，解码通信内核要么完全占用SM，要么空闲，避免了资源竞争。

消融研究：EPLB

EPLB对系统性能的影响，重点看定性结论。

整体结果

EPLB在预填充和解码阶段分别实现1.49倍和2.54倍的加速，充分展示了在缓解负载不均衡方面的价值。

案例研究：工作负载失衡与整体吞吐量的关系

解码阶段（输入1800 token，输出100 token，批次256）的案例显示，吞吐量与平衡度（专家间平均令牌数/最大令牌数）存在强相关性。

案例研究：专家分布统计

1. 专家使用不均衡：多数专家使用频率极低，少数专家被频繁调用。
2. 预填充与解码差异：两阶段分布虽相似，但区别显著，印证了PD解耦策略的必要性。

工具集

临时张量

PyTorch的内存管理容易因为持久化对象引用而复杂化，特别是CUDA内存这种稀缺资源。比如下面这段代码：

del hidden_state原本想释放内存，但因为hidden_state还在外部被引用，实际上根本不会释放，峰值内存反而上涨，甚至导致OOM。

SGLang的DisposableTensor类作为torch.Tensor的子类，新增了dispose()方法，能显式立即释放张量内存，绕开Python引用计数机制。

通过将hidden_state封装为DisposableTensor并在不再需要时调用dispose()，CUDA内存可立即回收，峰值内存占用自然下降。

专家工作负载提取与模拟

SGLang提供了一套工具，用于分析和模拟MoE模型中的专家工作负载分布。用途有两个：

• 导出专家工作负载统计：累计统计支持EPLB实时优化，逐批次数据提供细粒度洞察。
• 模拟专家利用率：无需昂贵硬件或重复试验，就能建模不同配置下的负载均衡。比如从中小规模配置采集数据，再模拟22节点大规模部署的性能。

局限性与未来工作

当前实现虽然已显著提升吞吐量，但还有不少可改进的地方：

• 延迟优化：首次令牌生成时间（TTFT）2-5秒，令牌间延迟（ITL）约100毫秒，对实时场景来说还不够快。
• 序列长度限制：96块GPU限制了序列长度，扩展GPU资源有助于支持更长序列。
• MTP整合：SGLang虽支持，但与DP注意力未完全兼容，混合并行配置效率受影响。
• EPLB数据分布：实验用的同分布数据未必反映真实场景的多样性。
• 灵活TP规模：DeepSeek-V3的稠密FFN在内存最优下TP规模极小但仍大于1。当前SGLang只支持纯TP或DP，需增加灵活选项。
• Blackwell架构支持：目前仅兼容Hopper，下一代的Blackwell支持已在路上。

结论

通过PD分离、专家并行和精心设计的并行方案，SGLang在开源实现中复现了DeepSeek推理框架的核心能力。输入吞吐量52.3k token/秒，输出吞吐量22.3k token/秒——这些数字充分证明了SGLang在大规模LLM推理中的潜力。当然，这只是开始，我们期待社区一起来探索、复现和拓展，共同推动高效AI部署的边界。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：SGLang开源首个对标官方性能的DeepSeek-V3/R1 H100部署方案要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题