刚刚，SGLang团队开源了他们部署DeepSeek-V3/R1大模型的方案。该方案使用96张H100（12个节点，每个节点8块H100 GPU）部署，采用预填充-解码分离架构和大规模专家并行（EP）技术（结合了DeepSeek开源的DeepEP、 DeepGEMM、EPLB），在处理2000 token输入序列时，单节点吞吐达到每秒52.3k输入token和22.3k输出token。这是首个在开源实现中接近DeepSeek官方博客报告的大规模吞吐性能的方案。如果在本地部署该方案，成本为每百万输出token 0.2美元，约为DeepSeek官方Chat API成本的五分之一。
目前，SGLang团队还专门写了一篇文章深入解析该部署方案的并行化设计、优化方法与实测结果。
代码：https://github.com/sgl-project/sglang 博客：https://lmsys.org/blog/2025-05-05-large-scale-ep
高效并行化对处理DeepSeek架构的计算复杂度和内存需求至关重要。本节概述了我们对以下关键组件的优化方案：注意力层、稠密前馈网络(FFN)、稀疏FFN以及语言模型(LM)头。每个组件都采用定制化的并行策略，以提升可扩展性、内存效率和性能。
注意力层
DeepSeek采用多头潜在注意力机制(MLA)来有效建模输入序列中的复杂依赖关系。为优化该机制，我们实现了DP Attention数据并行策略，消除跨设备的KV缓存冗余，显著降低内存开销。该方案自SGLang v0.4引入，现已扩展支持混合数据与张量并行，可灵活高效处理小批量数据。
稠密FFN
尽管仅使用三个稠密FFN层，DeepSeek-V3的计算仍会显著增加峰值内存占用，若管理不当可能导致系统崩溃。为此，我们采用数据并行(DP)而非张量并行(TP)策略，其优势如下：
（1）扩展性增强：当中间维度达18,432时，高TP并行度（如TP32）会导致单元碎片化（如576单元），该数值无法被现代GPU（如H100）的通用对齐边界128整除。这种错位会损害计算效率和内存利用率。DP通过避免碎片化确保跨设备负载均衡，提供更优的扩展方案。
（2）内存效率优化：传统TP虽能随计算单元增加降低内存占用，但在DP注意力机制下优势减弱。纯TP架构中，单层Transformer模型的内存需求随DP规模呈以下比例增长：
此处，表示每个设备（DP rank）上的隐藏状态大小，代表模型参数量，是表示CUDA Graph复制额外内存开销的系数。假设时，该内存使用函数在条件下取得最小值。DeepSeek-V3的中间层维度为18,432。在预填充阶段，CUDA Graph通常禁用，因此。但每设备的token数极易超过2,048，此时最优TP并行度为3或更低。在解码阶段，典型配置为每设备128个token且设置，此时内存最优TP并行度为6。两个阶段中，较低的TP并行度都能最小化单设备内存占用。因此，相比单纯依赖TP，DP可提供更具内存效率的扩展方案。
（3）通信开销最小化：在纯TP架构中，每个FFN层需要进行两次all-reduce操作，产生显著通信开销。通过采用DP策略，我们将其优化为在前置注意力层后执行单次reduce-scatter，在后续层前执行all-gather，使通信成本降低50%。当注意力计算也采用纯DP时，设备间通信可完全消除，大幅提升整体效率。
下图（a）展示了DP稠密FFN与DP注意力的集成方案，用户可通过设置--moe-dense-tp-size=1启用该功能。
稀疏FFN
在DeepSeek-V3的混合专家(MoE)架构中，稀疏FFN需要存储大量专家权重，形成显著内存瓶颈。我们采用专家并行(EP)策略，将专家权重分布到多个设备上。该方案在保持高性能的同时有效扩展内存容量，但会带来非常规all-to-all通信和工作负载不均衡等挑战。上图（b）展示了基于DeepEP框架的EP实现方案，具体设计与优化详见后续章节。
LM头
LM头需要在大词汇表上计算输出概率，这一资源密集型操作传统上采用词汇表并行来聚合TP组的token逻辑值。为提升扩展性和效率，我们沿用稠密FFN的数据并行(DP)策略，既降低内存开销又简化设备间通信，提供更高效的解决方案。
预填充与解码分离大语言模型推理包含两个独立阶段：预填充阶段（计算密集型，处理完整输入序列）和解码阶段（内存密集型，管理KV缓存进行token生成）。传统方案采用统一引擎处理这两个阶段，导致预填充与解码批次混合调度效率低下。为此，我们在SGLang中引入了预填充-解码(PD)分离架构。
统一调度的问题
传统统一引擎会引发三个关键问题：
预填充中断：新到达的预填充批次频繁打断正在进行的解码批次，显著增加token生成延迟 DP注意力失衡：在DP注意力机制下，不同DP工作节点可能同时处理预填充和解码批次，导致解码延迟上升 与DeepEP不兼容：如后续章节所述，DeepEP对预填充和解码采用不同调度模式，无法兼容统一调度
PD分离架构通过阶段解耦，为每个阶段实施定制优化，有效解决上述问题。
实现细节
SGLang的PD分离架构如下图所示，通过预填充服务器与解码服务器交替执行实现：
接收到输入请求后，工作流程如下：
预填充服务器与解码服务器通过握手配对，分别建立本地发送端和接收端 解码服务器预分配KV缓存后，触发预填充服务器启动模型前向计算 计算完成的KV缓存数据转移至解码服务器执行迭代token生成
这种分离确保每个阶段在最佳条件下运行，最大化 GPU 资源利用率。为了进一步提高性能，我们的实现包括：
非阻塞传输：数据收发在后台线程运行，确保调度器事件循环不受干扰 RDMA加速：基于队列对(QP)和分散聚合元素(SGE)实现非连续内存块高效传输 灵活API：集成Mooncake/NIXL等RDMA库，提供可适配的数据传输接口
基于DeepEP的专家并行
DeepEP是DeepSeek团队开发的一款专为简化混合专家模型（MoE）中专家并行（EP）设计的通信库。它有效解决了跨多GPU高效路由令牌至特定专家的技术难题，通过优化通信内核显著降低延迟并提升吞吐量，特别适合大规模推理任务。DeepEP提供两种专用调度模式以应对不同计算需求：
常规调度模式：针对长输入序列（如预填充阶段）优化，优先保障最大计算吞吐量。但该模式生成的符号化张量形状与CUDA Graph不兼容，导致其在解码阶段因内核启动开销过大而效能受限。 低延迟调度模式：专为解码阶段的输出令牌生成设计，以最小化延迟确保实时性能。该模式支持CUDA Graph，但需预分配固定内存空间。若内存需求超出预分配容量，将触发运行时错误。
在SGLang中，DeepEP的自动模式能根据工作负载动态选择上述调度方式。但若未采用参数分散（PD）技术，自动模式存在局限：同一通信组内无法同时支持预填充阶段的常规调度和解码阶段的低延迟调度。这一限制影响了其与DP注意力（内存高效推理的关键技术）的兼容性。各模式兼容性如下表所示：
PD解耦技术通过分离预填充和解码阶段来解决这一问题，使得在DP注意力机制下，预填充阶段可采用常规调度模式，解码阶段则启用低延迟调度模式。这种集成方案通过精准匹配各阶段需求来优化资源利用率，从而全面提升系统性能。
DeepGEMM集成
DeepGEMM是DeepSeek团队开发的另一款高效计算库，专为优化MoE模型中的计算任务而设计。它提供两种针对推理不同阶段的MoE相关矩阵乘法（分组GEMM）专用函数：
分组GEMM（连续布局）：该内核支持动态输入形状，特别适合MoE推理的预填充阶段。它处理不同专家数据连续拼接的输入，可灵活应对可变输入尺寸。 分组GEMM（掩码布局）：该内核采用固定输入形状，通过掩码张量仅计算输入的有效部分。其兼容CUDA Graph以优化内核启动，非常适合需要降低开销的解码阶段。
DeepGEMM与DeepEP的调度模式深度协同：
连续布局内核需与预填充阶段的常规调度配合使用。由于常规调度输出符号化形状，需通过置换操作将输出转换为内核预期的连续格式。我们参考LightLLM项目，实现了定制Triton内核进行高效置换，确保常规调度的输出能正确重组并与连续GEMM内核无缝对接。 掩码布局内核与DeepEP低延迟调度天然契合，二者均针对解码阶段优化且支持CUDA Graph。
SGLang还在张量并行下集成了DeepGEMM的MoE计算能力。此外，DeepGEMM提供高性能通用GeMM内核，通过设置环境变量SGL_ENABLE_JIT_DEEPGEMM=1即可在SGLang中启用，为非MoE运算带来更强计算效能。
双批次重叠技术
在多节点环境中，有限的通信带宽会显著增加整体延迟。为应对这一挑战，我们基于深度求索的系统设计实现了双批次重叠技术（TBO）。该技术将单个批次拆分为两个微批次，实现计算与通信的重叠执行，同时通过有效批次大小减半来降低峰值内存占用。然而，实际部署TBO时需解决特定实现难题。
实现挑战
尽管DeepSeek已公开TBO的设计框架，但仍存在两个细微的实现难点：
代码复杂度：直接编写TBO逻辑会导致管理多个微批次的代码重复，增加代码库复杂性，使其更难维护且易出错，尤其在微批次数量或重叠场景增多时更为明显。 预填充阶段的同步问题：当DeepEP的常规调度阻塞CPU时，需特别设计才能实现计算与通信的有效重叠。这种阻塞行为可能导致流水线停滞，造成GPU闲置，从而削弱TBO的性能优势。
抽象化实现方案
为构建更易维护和复用的代码库，我们采用由操作节点和暂停点组成的抽象层。该方法允许开发者以单微批次模式编写代码，同时通过插入策略性暂停点让其他微批次执行，从而简化开发流程。该方案具有以下优势：
消除代码重复 减少变量后缀的冗余使用 高效处理部分执行在层级末尾完成而其他未完成的情况 支持灵活调整重叠区域选择（例如未来升级为三批次重叠）且仅需最小代码改动
以下为该方案的简要实现演示：
预填充阶段重叠执行优化
我们改进了预填充阶段的任务启动顺序，以避免DeepEP中调度操作造成的CPU阻塞（即使在使用异步模式时）。具体而言：
调度操作会阻塞CPU，直到GPU从其他计算节点接收元数据并完成正确尺寸的张量分配。 若实现不当，在此期间计算流将处于空闲状态，因为没有计算任务被提交到GPU。
为优化性能，我们优先向GPU提交计算任务，再启动会阻塞CPU的通信操作。这确保了GPU在通信期间仍能保持计算活跃状态。如下图所示，采用合理启动顺序（以加粗边框标示）的TBO技术，成功规避了常规调度等CPU阻塞操作导致的计算气泡。
专家并行负载均衡器
在MoE模型中，专家并行(EP)常导致GPU间工作负载分布不均。这种不平衡迫使系统等待最慢的GPU计算或通信，既浪费计算周期又因专家激活增加内存占用。随着GPU数量(EP规模)增加，不平衡问题会愈发严重。
为解决此问题，DeepSeek开发了专家并行负载均衡器(EPLB)。EPLB以专家分布统计数据为输入，计算最优的专家排布方案以最小化负载不均。用户可分配冗余专家(例如32个额外专家)，与原有256个专家共同构成288个专家的资源池。该资源池允许EPLB智能地放置或复制专家——例如多次复制最高频使用的专家，或将中等使用频率专家与极少使用专家组合部署在同一GPU上。
除平衡负载外，EPLB还提供了更灵活的并行设计。原始256个专家方案将并行规模限制为2的幂次方，而EPLB的288专家方案支持更丰富的配置(如12或72等并行规模)。
下图通过仿真展示了规模效应和EPLB算法对负载不均的影响。我们通过GPU间MoE层的平均计算时间与最大计算时间之比来衡量平衡性，并使用各GPU处理的token数量估算其计算时间。可见系统扩展时利用率随节点数增加而下降，而启用EPLB能显著提升利用率。
EPLB在实际服务中的优化应用
要使EPLB发挥最佳效果，输入分布必须与实际服务负载高度匹配。我们通过两种策略实现这一目标：
增大批次尺寸：扩大批次可减少专家使用频率的随机波动，从而改善负载均衡。这可通过扩展计算集群或采用多令牌预测（MTP）等技术实现。 周期性再平衡：基于时间局部性特征定期更新专家分布，但需要高效实现专家重载机制。该策略的核心在于最小化专家重载操作的开销。
即使采用EPLB，部分负载不均衡仍不可避免，这使得进一步优化成为有价值的未来研究方向。
再平衡实现方案
SGLang采用三阶段专家再平衡机制，在保证效率的同时最大限度降低服务中断：
系统加载阶段：权重可选从磁盘预加载至主内存（加速再平衡）或通过内存映射（mmap）驻留磁盘（降低内存占用） 再平衡准备阶段：所需权重通过空闲DMA硬件引擎异步传输至设备内存，全程不中断GPU正在执行的任务 再平衡执行阶段：通过设备间拷贝完成权重更新，未来可通过物理内存重绑定技术进一步优化
这种分阶段实施方案确保再平衡过程既高效又无感知，在更新过程中始终保持系统性能稳定。
性能评估端到端性能评估
实验配置
我们在12节点集群上基于DeepSeek-V3评估了SGLang不同配置的端到端性能，集群通过InfiniBand互联，每个节点配备8块H100 GPU。本次测试重点验证高级优化技术带来的吞吐量提升，对比了以下四种配置方案：
基础版SGLang（TP16×6）：每两个节点组成独立计算组，以张量并行规模16（TP16）和DP注意力机制运行DeepSeek-V3推理 支持PD解耦的SGLang：集成PD解耦技术与完整EP优化方案。EPLB采用与输入/输出数据匹配的分布（因实时服务统计不可得） PD解耦+模拟MTP的SGLang：为模拟多令牌预测（MTP）效果，我们首先将批次大小翻倍并减半KV缓存长度以保持分组GEMM计算与内存访问负载不变；其次在真实注意力计算后插入空转内核，确保注意力阶段耗时与DeepSeek性能分析数据一致，精确反映MTP注意力机制导致的减速。保守假设MTP接受率为60% DeepSeek官方性能数据：吞吐量预估基于DeepSeek官方性能分析报告（profile data）
预填充与解码阶段性能分析
为适应不同负载需求，我们分别评估了预填充（P）与解码（D）阶段性能（假设非测试阶段资源无限以隔离测试节点负载）。测试环境复现DeepSeek官方配置，结果如下：
预填充阶段：在4节点（4×8×H100，EP32）配置下，1K/2K/4K提示词长度对应的单节点吞吐量分别为57,674/54,543/50,302 tokens/秒。如柱状图所示，较TP16基线最高提升3.3倍，主要归功于优化的分组GEMM内核（DeepGEMM）和双批次重叠技术。理想负载均衡下，系统吞吐量达DeepSeek官方数据的94.4%。 解码阶段：在9节点（9×8×H100，EP72；规模为DeepSeek测试的一半）配置下，2K输入时单节点吞吐量22,282 tokens/秒，较TP16基线加速5.2倍。模拟MTP场景（人为降低注意力内核速度以匹配真实延迟）中，4K输入仍保持17,373 tokens/秒的单节点吞吐量，与DeepSeek官方数据仅相差6.6%。如右图显示，性能提升主要源于EP支持的4倍批次扩展，通过大幅降低单GPU模型权重内存占用实现高效扩展。
性能对比结果
本节将SGLang的性能与DeepSeek推理系统进行对比，实验设置尽可能贴近DeepSeek的生产环境。我们从整体吞吐量和详细内核拆解两个维度展开分析，并参照DeepSeek官方博客及公开性能数据进行基准测试。
整体吞吐量
在预填充阶段，我们测试了单设备处理16,384个token、输入长度为4,096的场景。由于不确定DeepSeek的专家分布策略，我们评估了两种情形：默认专家分布方案，以及模拟理想EPLB（遵循分组限路由语义的随机专家选择）作为性能上限。 测试结果如下所示：
DeepSeek的分析报告显示其吞吐量大约是其生产环境的两倍。使用默认专家负载均衡的SGLang比DeepSeek的结果慢20%，而模拟的完美EPLB情况将差距缩小到6%。在解码方面，结果如下：
仅使用DeepSeek一半节点时，采用模拟MTP的SGLang性能仅略低于DeepSeek的配置。在高批量设置下（256序列，2000输入长度），SGLang每节点每秒可处理22,282个token，展现出强劲的可扩展性。
详细分解
下图展示了预填充阶段的内核执行时间细分，包括作为理论上限的单元测试结果：
默认EPLB：与DeepSeek的结果相比，通信内核执行时间更长且波动更大，可能是由于专家负载不均衡加剧所致。这会延长计算流间隙，拖累整体性能。 模拟完美EPLB：该结果更接近DeepSeek的结果，但仍存在差异，表明存在潜在优化空间。 与单元测试对比：DeepSeek和SGLang的通信时间均慢于单元测试结果，而禁用TBO时可达到后者水平，这为通信瓶颈场景指明了优化方向。
SGLang的解码内核分解与DeepSeek高度吻合，如下图所示：
关键观察结果包括：
合并时间差异：由于注意力计算时间较短，SGLang的合并操作比DeepSeek慢2倍，导致通信内核处于忙等待状态。在模拟慢注意力实验中，合并时间与DeepSeek匹配，验证了这一假设。 MoE性能：SGLang的MoE内核比DeepSeek慢25%，可能因为DeepSeek使用18个节点（我们使用9个）更高效地分配专家，减少了GEMM操作的内存访问开销。 调度优化潜力：DeepSeek和SGLang的每层调度时间均为~0.17ms，但DeepEP的单元测试显示，理论上可优化至0.06ms（占用SMs时间）。目前，调度过程因等待数据消耗大量忙等待时间。若在发送/接收操作间插入慢速虚拟内核，调度时间可降至0.09ms；结合单元测试的飞行时长分析，仍有进一步优化空间。
尽管存在小幅改进空间（主要在"其他内核"的融合优化），SGLang的解码性能已基本与DeepSeek对齐，下一步将重点优化预填充阶段。
消融研究：双批次重叠
批处理大小与注意力时间的影响
本节探讨了在不同批处理大小和模拟多任务处理（MTP）场景下TBO的性能表现。
TBO在预填充阶段带来两大显著收益，吞吐量对比和内存优化结果证明了这一点：
支持更大批处理大小：在默认配置中，每台设备最多处理8,192个令牌，超过16,384个令牌时会因内存不足（OOM）报错。TBO通过优化输入令牌的内存使用，将每台设备的批处理能力提升至16,384个令牌，性能提升达40.5%（与优化后的其他配置相比）。 提升吞吐量：通过重叠计算（如注意力与MLP阶段）和通信（如DeepEP的组合与分发），TBO在相同令牌处理量下，吞吐量较默认配置提高27%至35%。
TBO在解码阶段的表现因场景而异，性能与批处理大小和注意力处理时间密切相关：
实际测试案例：实际场景中的加速效果取决于批处理大小是否超过64至128个令牌的阈值。低于该值时，TBO收益甚微甚至为负（如32个令牌/设备时下降27%），因小批次会降低内核效率。在256个令牌时，速度提升达25.5%，吞吐量为22,310令牌/秒。 模拟MTP场景：在模拟MTP场景中，TBO的加速效果最为显著，尤其是在每解码步骤处理128个请求生成256个令牌时。由于注意力处理时间延长，计算（如DP注意力层）与DeepEP通信开销（如组合与分发步骤）得以重叠，128序列/设备时吞吐量提升35%，达到17,552令牌/秒（无TBO时为12,929）。
详细分析
我们评估了三种预填充场景：TBO 16k令牌/批次、TBO 8k令牌/批次、无TBO 8k令牌/批次。关键发现如下：
TBO效率：对比8k场景，TBO通过重叠计算与通信提升了整体效率。 批处理大小影响：TBO下将批次从16k降至8k会略微降低速度，反映小批次的内核效率下降。 内核性能：无TBO的8k案例在内核速度上优于TBO 16k案例（尽管两者有效批次均为8k），可能源于TBO的流式多处理器（SM）减少、重叠时的邻居噪声干扰或计算/通信内核不兼容。这些发现为SGLang的未来优化提供了方向。
我们分析了三种配置：TBO 256批次、无TBO 256批次、无TBO 128批次。时间分解显示：
TBO vs. 无TBO（256批次）：无TBO时通信时间显著增加，但计算内核（如GEMM）因更大批次而更快。 TBO（256） vs. 无TBO（128）：相同内核批次下，无TBO仅因非重叠通信而变慢，计算时间保持一致。与预填充不同，解码通信内核要么完全占用SM（发送/接收时），要么空闲（传输等待时），避免了与计算内核的资源竞争。
消融研究：EPLB
本节通过整体吞吐量分析和详细案例研究评估EPLB对系统性能的影响。鉴于EPLB对生产环境中工作负载分布及分布变化的敏感性，我们重点关注定性且可泛化的结论，而非需生产数据支撑的实际性能表现。
整体结果
下图展示了大规模场景下EPLB对吞吐量的影响。EPLB在预填充和解码阶段分别实现1.49倍和2.54倍的加速，这得益于其缓解GPU间工作负载失衡的能力。随着计算规模扩大，失衡问题加剧，而EPLB在实验中有效解决了这一问题，从而显著提升吞吐量。
案例研究：工作负载失衡与整体吞吐量的关系
为探究工作负载失衡与吞吐量的关联，我们以解码阶段为例进行案例分析：输入1800个令牌，输出100个令牌，批次大小为256。通过绘制解码步骤中吞吐量与平衡度（专家间平均令牌数/最大令牌数）的关系曲线，发现二者存在强相关性，表明高平衡度对性能优化至关重要。
案例研究：专家分布统计
下图展示了预填充与解码样本数据的专家分布统计结果：
关键发现：
专家使用不均衡：多数专家使用频率极低，少数专家被频繁调用，凸显MoE模型固有的不均衡性。 预填充与解码差异：两阶段分布虽具相似性，但存在显著区别。这验证了PD解耦策略的价值——通过为不同阶段定制专家布局以优化性能。
这些结论揭示了EPLB在解决工作负载失衡中的作用，以及针对阶段需求定制专家分布的重要性。
工具集临时张量
PyTorch中的内存管理可能因持久化对象引用而变得复杂，尤其是在GPU密集型工作流中，CUDA内存属于稀缺资源。参考以下示例：
在这段代码中，del hidden_state的本意是在计算完intermediate_state后释放hidden_state占用的内存。然而由于hidden_state仍在函数外部被引用，del操作实际并未生效。这会导致峰值内存占用增加，可能引发性能下降或内存不足错误。
SGLang通过DisposableTensor类解决这一问题——作为torch.Tensor的子类，它新增了dispose()方法，能显式且立即释放张量内存，从而规避Python引用计数机制的限制。其工作原理如下：
通过将hidden_state封装为DisposableTensor并在不再需要时调用dispose()，CUDA内存可立即释放。这确保了张量在完成计算作用后内存即刻回收，有效降低峰值内存占用并提升整体效率。
专家工作负载提取与模拟
SGLang还包含一套工具集，用于分析和模拟MoE模型中专家工作负载的分布。该功能支持用户实现以下目标：
导出专家工作负载统计：提取累计统计数据或逐批次工作负载数据。累计统计支持EPLB管理器进行实时优化，而逐批次数据则为分析和模拟提供细粒度洞察。
模拟专家利用率：无需昂贵硬件或重复试验，即可建模不同配置下的专家负载均衡。例如，用户可以从中小规模配置（如2x8xH100或8xH200）收集工作负载数据，进而模拟22节点大规模部署的性能表现。
此模拟功能使用户能够评估再平衡频率、节点数量或批次大小等因素对系统性能的影响，为规模化部署前的配置调优提供高性价比方案。
局限性与未来工作尽管当前基于SGLang的DeepSeek-V3推理实现已显著提升吞吐量，仍存在以下待改进方向：
延迟优化：当前设计侧重吞吐量，首次令牌生成时间（TTFT）为2-5秒，令牌间延迟（ITL）约100毫秒，需进一步优化以满足实时场景需求。 序列长度限制：受限于96块GPU的资源配置，仅支持较短序列。扩展GPU资源将有助于支持更长的序列，这对特定应用至关重要。 多令牌预测（MTP）整合：SGLang虽支持MTP，但与数据并行注意力机制未完全兼容，导致混合并行配置效率降低。 EPLB数据分布：本文实验使用的专家并行负载均衡器（EPLB）数据属于同分布数据，可能无法反映真实场景的多样性。未来需研究分布偏移时的性能表现。 灵活张量并行（TP）规模：DeepSeek-V3的稠密前馈网络（FFN）在内存最优条件下的TP规模虽小但仍大于1。当前SGLang仅支持纯TP或数据并行（DP），导致内存使用未达最优，需增加灵活TP选项。 Blackwell架构支持：当前实现仅兼容英伟达Hopper架构，我们正积极扩展对下一代Blackwell架构的支持。
通过参数分解解耦（PD）、专家并行（EP）和精心设计的并行方案，我们在SGLang中复现了DeepSeek推理框架并实现卓越性能。开源成果显示：输入吞吐量达52.3k token/秒，输出吞吐量达22.3k token/秒，充分证明SGLang在大规模LLM推理中的强大能力。诚邀社区共同探索、复现并拓展此项工作，推动高效AI部署的边界。
