Deploying DeepSeek on GB300 NVL72: Big Wins in Long-Context Inference

发表时间: 2026-02 · Blog post by Nvidia & SGLang Team (lmsys.org)

原文: https://lmsys.org/blog/2026-02-19-gb300-longctx

作者/机构：Nvidia & SGLang Team
发布时间：February 19, 2026

速读

一句话结论 结合 SGLang 的多项调度与并行优化，本文在 GB300 NVL72 平台上实现了 DeepSeek R1-NVFP4 模型 128K 超长上下文的高效推理，在同等条件下相比上一代 GB200 平台将吞吐量提升了 1.53 倍。

要解决什么问题 在超长上下文（如 128K 输入）的大语言模型推理中，系统面临两个核心卡点。首先是预填充（Prefill）阶段的计算瓶颈，当缺乏前缀匹配时，首 token 延迟（TTFT）极高，主要受限于注意力机制的庞大计算量。其次是解码（Decode）阶段的显存与带宽瓶颈，长上下文解码会迅速演变为受限于 KV 缓存容量和显存带宽的访存密集型任务。由于每个新生成的 token 都需要反复读取完整的历史 KV 数据，单张显卡的显存容量直接限制了系统能同时维持的并发请求数。当并发数超过显存上限时，系统被迫驱逐并重新计算 KV 缓存（即发生 Retraction），导致推理效率断崖式下跌。此外，在引入多 token 预测（MTP）等投机解码技术时，CPU 调度逻辑与 GPU 计算之间的频繁同步开销会成为新的阻塞点，限制了并发度的进一步提升。

怎么做的 核心思路是通过软硬件结合的方式，在预填充端切分计算流水线，在解码端横向扩展显存池，并利用异步调度掩盖 CPU 开销。该方案由四个关键部件构成：第一，基于 NVIDIA Dynamo 实现预填充与解码分离（PD）的集群级调度，通过轻量级的 KV 缓存感知路由和动态工作节点发现，让调度层引入近乎零的延迟。第二，在预填充路径上，采用分块流水线并行（Chunked PP）结合动态分块技术，将长提示词的计算打散以消除流水线气泡；同时全面启用 FP8 注意力机制和原生 FP8 KV 缓存，在固定显存下将 KV 容量翻倍。第三，在解码路径上，采用宽专家并行（Wide-EP）策略，将混合专家（MoE）权重和 KV 缓存分散到最多 32 张 GPU 上，从而大幅降低单卡显存压力。系统根据以下公式计算单 token 的 KV 显存占用：

$$KV\_footprint = (kv\_lora\_rank + qk\_rope\_head\_dim) \times num\_layers \times num\_kv\_head \times fp8\_size$$

结合 GB300 提升至 288GB 的 HBM3e 显存，系统能维持更大的解码批次大小而不触发重计算。第四，针对多 token 预测（MTP），设计了 Spec-V2 异步重叠调度器。它采用双流设计，前向流负责 GPU 计算，调度流负责 CPU 操作。通过创建未来张量映射（Future Tensor Map），调度流仅保留元数据张量的引用，直到最后一个批次才进行实例化，从而彻底解耦 CPU 调度与 GPU 验证步骤的同步屏障。此外，底层算子利用了 GB300 升级的特殊功能单元（SFU），使注意力机制中关键的 Softmax 指令吞吐量翻倍。

效果如何 实验在 GB300 NVL72 和 GB200 NVL72 硬件平台上展开，模型采用 FP4 量化的 DeepSeek-R1-NVFP4，测试数据设定为 128K 输入和 8K 输出的超长上下文负载。对比基线为相同 SGLang 优化栈下的 GB200 平台，分别测试了关闭和开启多 token 预测（MTP）两条路线。在最大吞吐量测试中，关闭 MTP 时，GB300 实现了 226.2 TPS/GPU，是 GB200（147.9 TPS/GPU）的 1.53 倍；开启 MTP 后，GB300 在维持 224.2 TPS/GPU 峰值吞吐的同时，将单用户吞吐量（TPS/User）从 23 提升至 43，实现了 1.87 倍的响应速度飞跃。在延迟与吞吐量平衡的严苛场景下，GB300 依然稳定保持 1.4 倍至 1.58 倍的性能优势。得益于显存优势，在 EP16 并行策略下，GB300 的实际最大解码并发数达到 36 请求每卡，远超 GB200 的 20 请求每卡。在预填充延迟方面，采用 8 卡分离部署架构，GB300 结合 32K 动态分块策略，将 128K 上下文的 TTFT 降至 8.6 秒。底层算子测试表明，GB300 的 FMHA 注意力算子延迟为 205 毫秒，比 GB200 快 1.35 倍。在 LongBench-v2 准确率测试中，系统得分为 56.9%，与官方基准完全对齐，证明极致优化未带来精度损失。作者也坦言，当前系统在上下文并行、通信算子与对称内存的结合，以及宽专家并行的重叠度上仍有优化空间，且 MTP 的草稿 token 数量目前还无法根据负载动态调整。

A1 主要贡献

作为Blackwell家族的最新成员，GB300 NVL72是目前用于长上下文（Long-context）大语言模型（LLM）推理的最强大平台。本文主要解决了在长上下文服务中（输入序列长度ISL为128K，输出序列长度OSL为8K）部署DeepSeek R1-NVFP4模型的效率与性能瓶颈问题。

研究团队通过引入一系列创新技术组合来实现极致优化，其核心创新点包括：

  1. Prefill-Decode分离（PD）：将预填充（Prefill）与解码（Decode）阶段解耦。
  2. 分块流水线并行（Chunked PP）：专门针对Prefill阶段优化。
  3. 宽专家并行（Wide-EP）：专门针对Decode阶段优化。
  4. 多Token预测（MTP）与重叠调度（Overlap Scheduling）。
  5. 更快的注意力内核（Attention Kernels）：得益于GB300中特殊功能单元（SFU）在注意力Softmax关键指令上实现了2倍的吞吐量提升。

核心成果亮点：

  • 长上下文（128K/8K）峰值吞吐量：SGLang在GB300 NVL72上实现了高达226.2 TPS/GPU的吞吐量，相比GB200具有1.53倍的优势。在几乎相同的GPU吞吐量下，MTP技术的引入使得单用户吞吐量（TPS/User）进一步提升了1.87倍。
  • 同等延迟条件下的对比：在匹配的负载和延迟条件下，GB300在各类代表性场景中持续提供相比GB200高出1.38倍至1.58倍的TPS/GPU。
  • EP解码扩展性：GB300拥有比GB200大1.5倍的HBM内存（288 GB vs 192 GB），这使得有效解码批处理大小提高了1.6倍（40 vs 24 req/GPU）。在DEP8配置下，能够扩展至288个并发请求且保持极低的回退率（Retraction）。
  • PP Prefill与优化的注意力内核：通过动态分块（Dynamic Chunking）技术，128K预填充的首字延迟（TTFT）降低至8.6秒（比GB200低1.07倍至1.23倍）。这一提升主要归功于FMHA内核实现了1.35倍的速度提升，其底层驱动力是SFU在Softmax关键指令上的吞吐量翻倍。

（复现指令可通过开源社区获取：[issue:18703, SGLang GitHub Repository, 2026]）

A2 方法细节

本章节详细阐述了使GB300在长上下文场景中获得巨大性能增益的主要技术方法。

1. 基于NVIDIA Dynamo的部署与集成

使用NVIDIA Dynamo进行集群级编排。在本文的实践中，DeepSeek-R1在GB300 NVL72上的部署是完全通过NVIDIA Dynamo进行编排的。NVIDIA Dynamo是一个专为集群规模下的Prefill-Decode（PD）分离推理设计的高性能控制平面。Dynamo能够处理协调异构的Prefill和Decode工作池所带来的复杂性，具体提供感知KV缓存的路由（KV-cache-aware routing）、工作节点协调、生命周期管理，以及一个经过优化的预处理和后处理栈，从而在集群规模下维持超高的吞吐量。

低开销的编排机制实现近零延迟。Dynamo的主要性能优势在于其轻量级的感知KV缓存请求引导（Request steering）和高效的元数据管理机制。在PD协调极为频繁的长上下文场景中，Dynamo确保了调度层引入的延迟几乎为零。这种设计直接使得SGLang的优化内核能够完全饱和GB300的HBM3e内存带宽，而不会因为编排逻辑的开销而产生性能瓶颈。

生产级别的扩展性与稳定性保障。Dynamo为多节点的PD部署提供了极其稳健的协调功能。这些功能涵盖了动态工作节点发现（Dynamic worker discovery）、健康状态追踪（Health tracking）以及跨异构Prefill和Decode池的生命周期管理。因此，当系统实例进行横向扩展（Scale up）、滚动更新（Roll）或重启（Restart）时，整个部署架构依然能够保持高度稳定。
Dynamo架构图

生产环境部署的Kubernetes支持。对于希望在生产环境中部署这些优化方案的用户，Dynamo Kubernetes技术栈提供了对GB200/GB300的全面支持。该技术栈内置了感知推理的自动扩缩容（Inference-aware autoscaling）功能，以及针对分离式部署的感知集群拓扑调度（Cluster topology-aware scheduling）能力。

2. Prefill路径：PP Prefill、长上下文TTFT与更快的内核

解决长上下文TTFT瓶颈的分块流水线并行设计。对于长上下文推理（例如128K tokens），首字延迟（TTFT）是一个主要的性能约束，特别是当提示词（Prompt）几乎没有或完全没有前缀匹配时，改善TTFT变得至关重要。为了应对这一挑战，研究团队在Prefill路径中采用了分块流水线并行（Chunked Pipeline Parallelism, PP），并将其与动态分块（Dynamic Chunking）技术相结合。这种组合技术有效地分布了提示词的计算负载，并显著改善了流水线不同阶段之间的计算重叠（Overlap）。
Chunked PP图解

全面启用FP8注意力与原生FP8 KV缓存。在之前针对GB200系列优化的基础之上，研究团队在GB300上全面启用了FP8 Attention，并为Prefill和Decode阶段引入了原生的FP8 KV-cache支持。这一设计的关键优势体现在两个方面：

  • 减少内存流量（Reduced Memory Traffic）：与BF16相比，FP8最大限度地减少了内存带宽瓶颈，从而提升了系统的吞吐量和稳定性。
  • KV容量翻倍（Doubled KV Capacity）：在固定的内存占用下，FP8使得KV缓存的容量翻倍，这直接支持了更大的批处理大小（Batch sizes）或更长的序列长度。

利用GB300硬件加速的Softmax优化注意力内核。研究团队还针对注意力内核（Attention kernel）利用了GB300特有的硬件加速Softmax功能。Blackwell Ultra GPU配备了升级版的特殊功能单元（SFU），为关键的Softmax操作提供了2倍的加速吞吐量，这对于注意力层来说是极其关键的。对于像长上下文Prefill这样属于计算密集型（Attention-heavy）的工作负载，这一硬件升级直接减少了计算瓶颈。

FMHA内核的显著加速效果。基准测试结果明确显示，得益于上述硬件升级，GB300上的FMHA内核相比于GB200实现了1.35倍的加速，这直接导致了整体TTFT的显著降低。

3. Decode路径：长上下文推理中的内存瓶颈

Decode阶段的KV主导与内存受限特性。长上下文的Decode阶段会迅速演变为由KV主导并受限于内存带宽的过程：每一个新生成的Token都需要重复读取完整的KV历史记录。因此，KV容量（即有多少序列可以驻留在内存中）和HBM内存带宽成为了最主要的性能瓶颈。

SGLang的专用运行时栈与架构策略。为了打破这一瓶颈，SGLang采用了一套专用的运行时栈和架构策略，具体包含以下三个核心组件：

  • 宽专家并行扩展（Wide-EP Scaling）：将专家并行（EP）与数据并行（DP）注意力相结合，将MoE权重和KV缓存分布到更多的GPU上（在本文的工作中最多扩展到32个GPU）。这种设计大幅降低了单张GPU的内存压力，允许使用更大的Decode批处理大小，且不会触发请求的"回退"（Retraction，即重新计算）。
  • CuTe DSL nvfp4内核：这是专门为Decode阶段的高性能nvfp4 MoE操作量身定制的底层内核。
  • DeepEP通信库：这是一个经过高度优化的分发（Dispatch）和组合（Combine）内核集合，用于实现高效的All-to-All通信。

GB300高HBM容量对Decode并发能力的理论与实际提升。GB300（Blackwell Ultra）每张GPU配备了288 GB的HBM3e内存，这是GB200 192 GB容量的1.5倍。为了量化GB300的288 GB HBM3e如何转化为有效的KV容量，研究团队以DEP16为例评估了最大Decode并发度。为了保证对比的公平性，两个平台上的mem_fraction_static均固定为0.75（尽管GB300更大的绝对内存实际上允许设置更高的比例）。最大Decode批处理大小由单Token的KV内存占用（35,136 Bytes/token）和128K+8K的工作负载（每个请求约136K个缓存Token）计算得出。在SGLang中，mem_fraction_static定义了分配给模型权重和KV缓存的GPU内存比例，剩余部分则保留给激活值和运行时缓冲区。单Token KV占用的计算公式为：
$(kv_lora_rank + qk_rope_head_dim) \times num_layers \times num_kv_head \times fp8_size = (512 + 64) \times 61 \times 1 \times 1 = 35,136$ Bytes per token。

项目 假设 / 指标 GB300 (@ mfs=0.75) GB200 (@ mfs=0.75)
单卡HBM 总HBM3e容量 288 GB 192 GB
静态预算 HBM × mem_fraction_static ≈ 216 GB ≈ 144 GB
单卡模型权重 FP4量化的DeepSeek-R1, EP16/TP16 ≈ 40 GB ≈ 40 GB
KV池预算 静态预算 – 模型权重 ≈ 176 GB ≈ 104 GB
工作负载 每个请求缓存的Token数 136K (128K+8K) 136K (128K+8K)
KV空间占用 cell_size_per_token 35,136 B 35,136 B
单卡单请求KV 136K × cell_size ≈ 4.45 GiB ≈ 4.45 GiB
理论上限 KV池 / 单请求KV ≈ 40 req/GPU ≈ 24 req/GPU
实际目标 约85%的上限以减少回退 ≈ 36 req/GPU ≈ 20 req/GPU
EP16映射 req/GPU × 16 GPUs ≈ 576 并发请求 ≈ 320 并发请求

内存优势直接转化为并发度优势。如上表所示，GB300更大的HBM几乎直接转化为了更高的Decode并发度——理论上限为40 vs 24 req/GPU。在实际运行中，系统通常在约85%的上限处运行，以避免请求完全占满KV缓存从而触发请求回退。这使得GB300上最大可达到36 req/GPU，而GB200为20 req/GPU（即在DEP16下，并发请求数为576 vs 320）。

4. 由重叠调度器驱动的多Token预测（MTP）

MTP与重叠调度的背景。自v0.4版本以来，重叠调度器（Overlap scheduler）已成为SGLang默认的批处理调度策略，它能够通过将CPU调度与GPU计算相重叠，实现零CPU开销。同时，多Token预测（Multi-token Prediction, MTP）是目前最流行的投机解码（Speculative decoding）方法之一，已被包括DeepSeek R1在内的主流模型广泛采用。
MTP与Overlap调度器图1
MTP与Overlap调度器图2

Spec-V2缓解MTP批次间的同步开销。为了无缝结合MTP和重叠调度器，SGLang提出了Spec-V2。该方案通过精心设计的消息传递和重叠策略，有效缓解了MTP批次之间的同步问题。

双流设计实现CPU与GPU操作的异步重叠。具体而言，Spec-V2采用了一种双流（Two-stream）设计：一个前向流（Forward stream）用于所有的GPU计算，另一个调度流（Schedule stream，此处使用“流”一词旨在强调其异步性）用于处理CPU操作，包括结果处理、内存释放、下一批次的准备工作等。

通过未来张量映射消除设备到主机的同步屏障。为了避免因将元数据张量从设备（Device）传输到主机（Host）而引起的同步屏障，Spec-V2创建了一个未来张量映射（Future tensor map）。调度流首先创建元数据张量的引用，并且只在最后一个批次将其具体化（Materializes）之后才去读取它们。通过这种方式，CPU操作可以与最后一个MTP批次的目标验证（Target verify）或草稿扩展（Draft extend）过程完美重叠。

对MTP与重叠调度结合的进一步支持增强。此外，研究团队在以下几个方面进一步增强了对MTP与重叠调度器结合的支持：

  • 实现了与PD分离架构和WideEP的兼容性，从而在更高并发下解锁了性能潜力。
  • 为MTP前向过程的所有阶段（包括草稿解码 Draft decode、目标验证 Target verify、草稿扩展 Draft extend）捕获CUDA图（CUDA graphs），进一步降低了CPU开销。
  • 在MTP层对MoE权重进行了FP8量化，使其能够与DeepGemm和DeepEP更顺畅地协同工作。

A3 实验环境

虽然原文未单独设立实验环境章节，但基于全文提取的实验配置信息总结如下：

  • 工作负载与数据集：长上下文推理任务，输入序列长度（ISL）为128K，输出序列长度（OSL）为8K。准确性测试使用LongBench-v2数据集。
  • 模型参数：DeepSeek R1-NVFP4（采用FP4量化，MTP层采用FP8量化MoE权重）。
  • 硬件配置：NVIDIA GB300 NVL72（单卡288 GB HBM3e，搭载SM103a芯片，SFU吞吐量翻倍）；对比基线为NVIDIA GB200 NVL72（单卡192 GB HBM，搭载SM100f芯片）。网络拓扑支持高达32张GPU的Wide-EP，以及用于Prefill测试的1P/1D（1个Prefill节点/1个Decode节点）8 GPU分离式架构。
  • 软件配置：部署于SGLang（v0.4及以上版本），使用NVIDIA Dynamo进行集群编排，底层依赖CuTe DSL nvfp4内核、DeepEP（用于All-to-all通信）以及DeepGemm。

A4 实验结果

1. 最大吞吐量分析

实验内容：在长上下文工作负载（ISL = 128K, OSL = 8K）下测量DeepSeek-R1的最大可达TPS（每秒Token数）。
实验结果与分析：

  • 在未开启MTP的情况下，GB300达到了226.2 TPS/GPU，是GB200（147.9 TPS/GPU）的1.53倍。结论指出，在长上下文场景下，峰值吞吐量主要受限于Decode端的KV缓存容量和内存带宽，而非计算能力；GB300更大的HBM容量允许更大的Decode批处理大小，使更多请求保持活跃而不触发回退。
  • 在开启MTP的情况下，GB300维持了224.2 TPS/GPU，而GB200为169.1 TPS/GPU（提升1.33倍）。最显著的结论是，MTP的主要收益体现在单用户吞吐量（TPS/User）上：GB300的TPS/User从23几乎翻倍至43（提升87%），同时保持了系统级的峰值TPS/GPU。这意味着每个用户都能获得明显更快的响应，且不牺牲系统整体吞吐量。
    最大吞吐量分析

2. 峰值容量与延迟约束分析

实验内容：在实际推理使用场景下对比GB300和GB200的性能。评估分为两个代表性场景：

  • 面向高吞吐量的场景（非MTP下TPS/User = 30–40，MTP下40–50）：系统经过调优以最大化聚合吞吐量，放宽延迟约束。

  • 延迟-吞吐量平衡场景（非MTP下TPS/User = 50–60，MTP下60–70）：反映了对单用户吞吐量和系统响应速度有更严格要求的场景。
    实验结果与分析：

  • 在高吞吐量场景下，未开启MTP时，GB300达到204.7 TPS/GPU，相比GB200的147.9提升了38.4%。开启MTP后，加速比更高，达到224.2 vs 169.1 TPS/GPU（提升44.9%）。

  • 在延迟-吞吐量平衡场景下，未开启MTP时，GB300保持了1.58倍的优势（167.9 vs 106.5 TPS/GPU）；开启MTP时，获得1.40倍的增益（196.4 vs 140.0 TPS/GPU）。
  • 结论：GB300在不同负载下始终比GB200高出1.4X–1.5X，且在对延迟敏感的条件下相对增益最大，这表明GB300在面对高单用户吞吐量要求时，具有更强的抵抗吞吐量衰减的韧性。
    吞吐量与延迟约束分析

3. Prefill延迟：Chunking策略与TTFT优化

实验内容：在长上下文负载（ISL = 128K, OSL = 8K）下，使用1P/1D分离架构（8 GPUs）评估不同分块策略和硬件对平均TTFT的影响。对比了三个分块维度：无分块（并发度=1）、静态分块、动态分块，以及三种初始分块大小（16K, 32K, 64K）。
实验结果与分析：

  • GB300在所有配置下的TTFT均比GB200低1.07X–1.23X。差距最大的是无分块基线（15.2s vs 18.6s），这主要归功于GB300优化的注意力内核。
  • 分块（Chunking）和动态分块对长上下文TTFT非常有帮助。无分块时，两平台的TTFT均超过15s。启用带PP重叠的分块Prefill后，TTFT降低了30–45%，其中较小的分块（16K, 32K）由于流水线利用率更高，始终优于64K。
  • 动态分块在静态分块的基础上进一步降低了8–17%的TTFT，因为它消除了固定调度引起的流水线气泡。在GB300上使用32K初始分块大小结合动态分块，实现了8.6秒的最佳TTFT。
    Prefill延迟与Chunking策略

4. Kernel级别对比

实验内容：在代表性的长上下文Prefill场景下进行内核级基准测试。配置为：长上下文序列Prefill，PP4并行，并发度8，Prefill大小128k，无分块。
实验结果与分析：

  • 搭载SM103a的GB300在Softmax吞吐量上实现了2倍提升，这使得FMHA内核相比GB200（搭载SM100f）获得了1.35倍的速度提升。GB300的延迟为205ms，而GB200为277ms。
    FMHA Kernel性能对比1
    FMHA Kernel性能对比2

5. 准确性验证

实验内容：在LongBench-v2数据集上评估系统的准确性，以确保模型完整性。
实验结果与分析：

  • 非MTP设置得分为57.2%。
  • 启用MTP后（accept length=2.37@MTP3），得分为56.9%，这与DeepSeek-R1-0528官方基准测试报告的56.7%完美吻合。

A5 结论

尽管上述各项技术已经充分证明了GB300在长上下文推理中的卓越性能，研究团队指出仍有多个优化方向可以进一步挖掘硬件潜力以获得更好的性能：

  1. 上下文并行（Context Parallelism）：与分块流水线并行相比，上下文并行同样是一个极具潜力且无气泡（Bubble-free）的选项，可用于进一步降低TTFT。
  2. 内核优化（Kernel Optimizations）：可以利用对称内存（Symmetric memory）来优化通信内核。此外，针对MTP的小型元数据准备内核也可以进行融合（Fused），以进一步降低CPU开销。
  3. DP负载均衡器（DP Load Balancer）：通过引入更优秀的DP负载均衡器，可以减少不同DP Rank之间的等待时间。
  4. Wide-EP中的更深层重叠（More Overlap in Wide-EP）：MoE计算与DeepEP通信可以进行更细粒度的调度和组织，从而实现更深层的计算重叠和更高的加速比。
  5. 针对长上下文与负载的感知投机调度（Spec-aware Scheduling for Long Context & Workload）：草稿Token（Draft tokens）的数量可以根据当前的工作负载进行动态调整。

A6 补充细节

致谢名单与社区贡献。本文的工作得益于多个团队与合作者的共同努力。研究团队特别感谢了NVIDIA团队的成员（包括Yangmin Li, Hao Lu, Ishan Dhanani, Weiliang Liu, Trevor Morris, Po-Han Huang, Kaixi Hou, Shu Wang, Lee Nau, Alex Yang, Mathew Wicks, Pen Chung Li），以及SGLang核心团队和社区贡献者（Baizhou Zhang, Jingyi Chen, Liangsheng Yin, Shangming Cai, Rain Jiang, Cheng Wan, Qiaolin Yu, Lianmin Zheng）。

方法细节中引用的参考文献说明：

  • 【1，NVIDIA Dynamo GitHub Repository，URL: https://github.com/ai-dynamo/dynamo】：在“基 于NVIDIA Dynamo的部署与集成”段落中被引用，原文描述其为一个用于集群规模下Prefill-Decode分离推理的高性能控制平面。
  • 【2，Dynamic Chunking，URL: https://lmsys.org/blog/2026-01-15-chunked-pipeline/】：在“Prefill路径”段落中被引用，原文描述其与分块流水线并行结合，用于分布提示词计算并改善流水线阶段间的重叠，从而降低长上下文TTFT 。
  • 【3，GB200 Series Optimizations，URL: https://lmsys.org/blog/2025-09-25-gb200-part-2/】：在“Prefill路径”段落中被引用，原文说明GB300上 的FP8 Attention和原生FP8 KV-cache支持是建立在之前GB200系列优化的基础之上的。
  • 【4，SGLang v0.4 Release Notes，URL: https://lmsys.org/blog/2024-12-04-sglang-v0-4/】：在“由重叠调度器驱动的多Token预测（MTP）”段落中被引用，原文说明自v0.4起，重叠调度器已成为SGLang的默认批处理调度策略 。
  • 【5，MTP Implementation in SGLang，URL: https://lmsys.org/blog/2025-07-17-mtp/】：在“由重叠调度器驱动的多Token预测（MTP）”段落中被引用，原文指出该博客包含SGLang中MTP实现的更多细节 。