GPUStack Day 0 支持 Kimi-K3：8×B300 上 vLLM 与 SGLang 推理实测

本文记录 Kimi-K3 在单机 8×NVIDIA B300 环境中的部署与压测过程，并对 vLLM、SGLang 两套推理引擎在 64K 与 200K 长上下文场景下的表现进行拆解。测试显示：64K 输入下 vLLM 更快，200K 输入下 SGLang + DCP 反超；真正拉开差距的不是 Prefill，而是长上下文 Decode 阶段的 KV 读取方式。

Kimi-K3 是一款面向复杂推理与长上下文任务的 MoE 模型。本次测试使用 单机 8×NVIDIA B300，通过 GPUStack 分别接入 vLLM 与 SGLang，并启用 Kimi-K3-DSpark 草稿模型进行投机解码。

先给出最值得关注的结论：

• 64K 输入、10 路并发：vLLM 端到端耗时 100.5 秒，SGLang 为 150.8 秒，vLLM 领先约 1.5×。
• 200K 输入、10 路并发：SGLang 端到端耗时 225.3 秒，vLLM 为 295.2 秒，SGLang 反超约 1.31×。
• vLLM 从 64K 增长到 200K 后，稳定解码吞吐下降 3.29×；SGLang 仅下降 1.25×。
• 性能交叉的主因是本轮 SGLang 开启了 --dcp-size=8，而 vLLM 的 decode_context_parallel_size=1。
• 两侧 Prefill 能力接近，主要差异来自 Decode 阶段。
• Random 数据集使 DSPARK 投机解码的接受率极低，因此本轮结果不能直接代表真实生产流量。

重要说明： 这不是严格对等的 A/B 测试。两套引擎在 DCP、显存分配、算子后端、接受判据等方面存在差异。本文更适合用来理解瓶颈与选型方向，不应被视为最终性能排名。

测试环境

本次测试环境如下：

项目	配置
服务器	单机
GPU	8×NVIDIA B300
单卡可见显存	267.69 GiB
模型	Kimi-K3（MXFP4）
草稿模型	Kimi-K3-DSpark
推理引擎	vLLM / SGLang
测试输入	64K、200K 及多种长度
输出长度	3K
并发	10
数据集	Random

准备模型权重

使用 ModelScope 下载 Kimi-K3 主模型与 DSpark 草稿模型。

下载 Kimi-K3 主模型（MXFP4）

modelscope download \
  --model moonshotai/Kimi-K3 \
  --local_dir ./Kimi-K3

下载 vLLM 使用的 DSpark 草稿模型

modelscope download \
  --model skyai/Kimi-K3-DSpark \
  --local_dir ./Kimi-K3-DSpark

下载 SGLang 使用的 DSpark 草稿模型

modelscope download \
  --model skyai/sglang-Kimi-K3-DSpark \
  --local_dir ./Kimi-K3-DSpark

拉取推理镜像

拉取 vLLM 镜像

docker pull vllm/vllm-openai:kimi-k3

拉取 SGLang 镜像

docker pull lmsysorg/sglang:kimi-k3

镜像准备完成后，在 GPUStack 的推理后端中分别为 vLLM 和 SGLang 添加自定义版本。

在 GPUStack 中部署 vLLM

在 GPUStack 中创建 vLLM 自定义后端，选择 Kimi-K3 模型、8 张 B300，并配置所需环境变量。

vLLM 自定义后端及模型配置如下：

vLLM 环境变量

VLLM_ENABLE_K3_LATENT_MOE_TAIL_FUSION=1
VLLM_ALLREDUCE_USE_FLASHINFER=1
VLLM_ENGINE_READY_TIMEOUT_S=3600
VLLM_USE_V2_MODEL_RUNNER=1
VLLM_USE_RUST_FRONTEND=1

vLLM 启动参数

--trust-remote-code
--load-format fastsafetensors
--moe-backend auto
--gpu-memory-utilization 0.95
--tensor-parallel-size 8
--max-model-len 1000000
--kv-cache-dtype fp8
--attention-config '{"mla_prefill_backend":"TRTLLM_RAGGED","use_prefill_query_quantization":true}'
--max-num-batched-tokens 32768
--enable-prefix-caching
--enable-auto-tool-choice
--tool-call-parser kimi_k3
--reasoning-parser kimi_k3
--max-num-seqs 32
--speculative-config '{"model":"Inferact/Kimi-K3-DSpark","num_speculative_tokens":7,"method":"dspark","attention_backend":"FLASHINFER_MLA","draft_sample_method":"probabilistic","rejection_sample_method":"block"}'

--gpu-memory-utilization 0.95 在本轮测试中导致 KV 池超额提交，并触发运行期 OOM 重试。后文会给出更稳妥的调整建议。

在 GPUStack 中部署 SGLang

同样创建 SGLang 自定义后端，选择 8 张 B300，并录入模型与启动参数。

SGLang 自定义后端及模型配置如下：

SGLang 启动参数

--trust-remote-code
--model-path <Kimi-K3 模型路径>
--tp-size 8
--dcp-size 8
--disable-custom-all-reduce
--enable-symm-mem
--mem-fraction-static 0.85
--reasoning-parser kimi_k3
--tool-call-parser kimi_k3
--mamba-full-memory-ratio 0.86
--host 0.0.0.0
--port 30000
--speculative-algorithm DSPARK
--speculative-draft-model-path <Kimi-K3-DSpark 模型路径>
--speculative-dspark-block-size 7
--enable-linear-replayssm-spec
--chunked-prefill-size 32768
--max-prefill-tokens 32768
--context-length 1000000
--kv-cache-dtype fp8_e4m3

服务启动后，可在 GPUStack 中查看实时日志、吞吐与 KV Cache 状态。

64K / 3K、10 路并发对比

首先使用 64K 输入、3K 输出、10 路并发进行测试。

vLLM 测试结果

SGLang 测试结果

测试期间的推理日志如下：

不同输入长度下的测试

除 64K 外，本轮还测试了多种输入长度，用于观察上下文增长对 TTFT、TPOT、ITL 与端到端耗时的影响。

vLLM

SGLang

核心结果：64K 与 200K 之间发生性能交叉

从客户端可信指标与引擎日志综合看，两套引擎在 64K 和 200K 之间发生了明显的性能交叉：

场景	vLLM	SGLang	结果
64K 端到端耗时	100.5 s	150.8 s	vLLM 领先约 1.5×
200K 端到端耗时	295.2 s	225.3 s	SGLang 领先约 1.31×
64K 稳定解码吞吐	约 501 tok/s	约 335 tok/s	vLLM 领先约 1.5×
200K 稳定解码吞吐	约 163 tok/s	约 268 tok/s	SGLang 领先约 1.64×
64K→200K 解码退化	3.29×	1.25×	SGLang 扩展性更好

一句话解释： vLLM 在较短上下文中没有 DCP 通信开销，因此更快；上下文增长后，SGLang 的 DCP=8 将每张卡需要读取的 KV 数据量大幅分摊，长上下文 Decode 反而更有优势。

但读完两边源码后，这个差异不是“vLLM 忘了开”那么简单：vLLM 在代码里明确禁止 DCP 与 DSPARK 投机解码共存，想要 DCP 就必须放弃投机；SGLang 允许二者共存，代价是投机退化为非自适应模式。也就是说，这是一道架构层的取舍题，而不是配置疏漏。

为什么会发生性能交叉

1. Decode 扩展性是决定性因素

取 10 路请求全部进入解码后的稳定段：

解码聚合吞吐：10 路并发稳定段均值，单位 tok/s；数据来源为引擎自报日志。

vLLM（DCP=1）

• 64K：稳定段约 439～537 tok/s，峰值 537 tok/s。
• 折算单请求约 53.7 tok/s，即约 18.6 ms/token。
• 200K：稳定段约 157.8～166.6 tok/s，均值约 163 tok/s。
• 折算单请求约 16.3 tok/s，即约 61.3 ms/token。
• 上下文增长约 3.1×，解码性能下降 3.29×，呈近似线性退化。

SGLang（DCP=8）

• 64K：稳定段约 313～418 tok/s，均值约 335 tok/s。
• 折算单请求约 33.5 tok/s，即约 29.9 ms/token。
• 200K：稳定段约 252～288 tok/s，均值约 268 tok/s。
• 折算单请求约 26.8 tok/s，即约 37.3 ms/token。
• 上下文增长约 3.1×，解码性能仅下降 1.25×。

在 64K 场景中，DCP 每一步增加的通信成本还没有被 KV 读取收益抵消，所以 vLLM 更快；到了 200K，KV 读带宽成为主要瓶颈，SGLang 的 DCP 优势开始显现。

2. Prefill 能力基本打平

两侧的 chunked-prefill / max-num-batched-tokens 都设置为 32768，稳定 Prefill 聚合吞吐约为 19K～23K tok/s。这说明在 8×B300 上，Kimi-K3 的 MoE + MLA 预填充能力已经比较接近，整体差距主要出现在 Decode 阶段。

需要注意的是，vLLM 的 64K Prefill 数据受到两类运行时事件干扰：

• 8 张卡共出现 32 次软 OOM 重试；
• 4 个算子在推理期发生 JIT 编译。

这些事件都集中在 64K 测试初期，因此 vLLM 该轮的 Prefill 聚合值和首批 TTFT 偏悲观。200K 测试中未复现，SGLang 日志中也没有对应的 OOM / JIT 记录。

3. SGLang 日志揭示了长上下文 Prefill 衰减

SGLang 会逐 chunk 输出 input throughput。在 200K 场景中，同一请求的 6 个 chunk 吞吐依次约为：

22265 → 21064 → 19628 → 18475 → 17243 → 16408 tok/s

切换到下一个请求后，吞吐又回到约 22K tok/s。这直接反映了随着已缓存上下文变长，注意力计算成本逐步上升。

vLLM 的 Avg prompt tput 是 10 秒窗口聚合值，粒度更粗，因此不会直接呈现这一结构。对比两侧日志时，需要注意可观测口径并不完全一致。

DSPARK 投机解码：本轮基本没有带来收益

本轮压测使用 Random 数据集。随机 token 序列本身几乎不可预测，因此草稿模型很难连续命中。

两套引擎都使用 Kimi-K3-DSpark，并设置 7 个投机 token；但在 200K 场景下，双方平均接受长度都接近 1：

• vLLM：约 1.05～1.17；
• SGLang：约 1.05～1.17。

这意味着系统为草稿模型付出了额外算力，却几乎没有获得投机解码收益。vLLM 200K 轮中，Drafted throughput 约 990 tok/s，而 Accepted throughput 仅约 21 tok/s，约 98% 的草稿计算被丢弃。

不同场景下的接受长度与接受率如下：

场景	引擎	接受长度	接受率 / 草稿命中率	解释
64K	vLLM	2.27～2.51	18%～21%	唯一还有实质收益的一档：每次前向多落地约 1.5 token
64K	SGLang	1.21～1.55	3%～8%	同样数据、同样草稿模型，却明显弱于 vLLM——值得单独查
200K	vLLM	1.05～1.17	1.1%～2.5%	完全崩塌；草稿算力 98% 浪费
200K	SGLang	1.05～1.17	1%～2%	同样崩塌

结论： 本轮测到的是“投机解码纯负担”场景，不能直接外推到真实生产流量。下一轮应改用 ShareGPT、真实业务请求或其他自然语言数据集。

两套引擎的接受判据也不同

两边草稿权重同源，但验证策略不同：

• vLLM 显式设置 draft_sample_method=probabilistic 和 rejection_sample_method=block，采用更宽松的概率式分块验证。
• SGLang 的 DSPARK 路径采用严格的 greedy 逐位匹配；块内第一个 token 不匹配，后续 token 会全部作废。

因此，在相同草稿模型下，两套引擎仍可能出现明显不同的平均接受长度。若要严格验证投机解码收益，需要统一数据集、采样参数、gamma 与接受判据。

客户端指标：先排除不可信的吞吐列

四组客户端测试的可信指标汇总如下：

指标	vLLM 64K	SGLang 64K	vLLM 200K	SGLang 200K
总耗时（s）	100.5	150.82	295.21	225.34
请求延迟均值（s）	84.42	141.53	284.58	217.83
TTFT 均值（ms）	34,838.8	41,670.6	125,210.8	59,002.0
TTFT P50（ms）	34,181.1	40,391.9	125,189.2	54,104.0
TTFT P90（ms）	36,987.9	53,525.0	126,667.0	103,336.0
TPOT 均值（ms）	12.28	47.18	45.21	72.6
ITL 均值（ms）	9.94	33.3	3.47	52.96
失败 / 未完成	0 / 0	0 / 0	0 / 0	0 / 0

截图中的部分吞吐字段无法与总 token 数、并发和耗时相互校验。例如：

• vLLM 200K 显示输出吞吐 1111.61 tok/s；
• 但按 10 × 3000 ÷ 295.21 计算，物理上限约为 101.6 tok/s；
• 64K 测试也存在接近 11× 的固定偏差。

因此，本文只采用 TTFT、TPOT、ITL、延迟与总耗时；吞吐统一以引擎日志为准。

TTFT 口径也需要统一

启用 --reasoning-parser kimi_k3 后，思维链输出位于 delta.reasoning，而不是 delta.content。如果压测工具只从 delta.content 计算首 token，两套引擎的 TTFT 都会被系统性抬高。

对于推理模型，更合理的口径是：

time-to-first-any-delta

即收到第一个 reasoning 或 content 增量时就停止 TTFT 计时。

此外，vLLM 该轮还出现长 Prefill 挤占 Decode 调度预算的现象：当 long_prefill_token_threshold=0 时，队首长请求可能一次吃满 32768 token 预算，导致其他已经进入运行态的请求拿不到一个 token 的 Decode 调度，从而形成较平的高 TTFT。

显存分配与 KV Cache 容量

每张 B300 可见显存为 267.69 GiB，两侧模型权重占用接近，但剩余显存分配策略差异很大。

vLLM

项目	数值
模型权重及 non-torch	197.72 GiB
峰值激活	12.82 GiB
CUDA Graph	5.13 GiB
KV Cache	43.76 GiB

KV 池容量为 2,687,776 token，1M 上下文下理论最大并发约为 2.69×。

但当前配置存在超额提交。vLLM 日志提示：若要真正落入 0.95 显存预算，KV Cache 应降至 38.48 GiB，而本轮实际分配了 43.76 GiB。这也是运行期 OOM 重试的主要来源。

可选择以下一种方式修正：

方案一：降低显存利用率

--gpu-memory-utilization 0.92

方案二：显式限制 KV Cache

--kv-cache-memory 41317885440

SGLang

项目	数值
模型权重	195.86 GiB
全注意力 KV Cache	11.80 GiB
草稿模型 KV（K-V）	8.74 GiB
Mamba / SSM 状态	10.93 GiB
剩余空间	17.08 GiB

全注意力池容量为 916,672 token，草稿池容量为 7,333,376 token。

当前配置声明 context-length=1000000，但全注意力池只有 916,672 token，比目标上下文少约 8.3%。也就是说，单条满 1M 请求无法完整放入 KV 池。

同时，max_running_requests 从 48 被压缩到 39，瓶颈来自 Mamba 状态缓存，而非普通 KV Cache。对于 1M 长上下文高并发场景，vLLM 当前的容量余量更大。

冷启动开销

两套引擎总冷启动时间都在 10 分钟左右，但耗时分布不同：

阶段	vLLM	SGLang	备注
容器创建完成	17:06:21	18:01:45	GPUStack 创建时间
权重加载	163.8 s	141.0 s	vLLM 12 shard / fastsafetensors；SGLang 96 shard / 多线程
权重体积（单卡）	194.54 GiB	195.86 GB	MXFP4 MoE + compressed-tensors
算子预热	CuTeDSL 25 单元 13.8～16.9 s + KDA Triton	KDA prefill / vision FA4 / RoPE 预编译	两侧都有 K3 专用 JIT 预热
CUDA Graph 捕获	85～88 s / 5.13 GiB / 51 档	约 5.5 min / 67 档	SGLang 档位更密，且含 DSpark 草稿图折叠
引擎初始化合计	409.61 s	约 370 s	vLLM 显式打印；SGLang 由时间戳推算
服务可用	约 17:16:57	18:11:59	SGLang：server is fired up
容器→可用总时长	约 10.6 min	约 10.2 min	同量级

• vLLM 的主要耗时来自 profile、KV 分配与 warmup，约 409.6 秒；
• SGLang 的主要耗时来自 CUDA Graph 捕获，约 5.5 分钟。

如果服务需要频繁扩缩容，应把冷启动时间纳入容量规划，并尽量通过常驻实例、预热或分批扩容降低影响。

配置并不完全对等

本轮两套技术栈的主要差异如下：

项目	vLLM	SGLang	可能影响
解码上下文并行	DCP=1（关闭）	DCP=8，comm=a2a，复制 Q 投影	主导：长上下文解码的全部差距
All-Reduce	FlashInfer + Custom + SymmMem，且与 RMSNorm 融合	显式 --disable-custom-all-reduce；多播不可用→回退普通 NCCL	高：小批解码通信占比大
MLA 预填充后端	TRTLLM_RAGGED + 查询量化	trtllm_mla	中
MLA 解码后端	FLASHINFER_MLA	cutedsl_mla（混合后端，官方标注 experimental）	中
线性注意力（KDA）	FlashKDA 预填充内核	Triton（decode / verify / extend 全 Triton）	中：Triton 相对手写 CUDA 通常有差距
MoE 后端	FLASHINFER_TRTLLM_MXFP4_MXFP8，autotune 被关	flashinfer_mxfp4（trtllm-gen SiTU cubin）	中：autotune 关闭意味着 GEMM tiling 未调
KV 页大小	block 32，为对齐 Mamba 抬到 attn block 1536	page_size 64	中：1536 对齐带来内部碎片
torch.compile	被 BREAKABLE_CUDAGRAPH 自动关闭（即 mode=none）	未启用	中：仅剩手写 custom_ops + 三个融合
前端	Rust frontend（VLLM_USE_RUST_FRONTEND=1）	Python / uvicorn	低～中：高并发下 tokenize / SSE 开销
显存占用系数	0.95	0.92	低～中：直接反映在 KV 池大小
并发上限	max_num_seqs=64	48→39（Mamba 状态缓存封顶）	中：本轮并发仅 10，未触发
Model Runner	V2 + 异步调度	标准调度 + overlap schedule	待评估

日志中值得处理的告警

两边共有：FP8 KV Cache 缺少 scaling factor

两侧日志均提示 FP8 KV Cache 未提供 scaling factor，并回退到 1.0。该配置可能影响精度，而本轮没有进行输出质量对齐。

在对性能数字下最终结论前，应先使用固定评测集验证精度，确认 FP8 KV Cache 没有造成不可接受的质量损失。

两边共有：slow tokenizer

两套引擎都出现 Using a slow tokenizer 告警。对于 64K / 200K 长输入，Tokenizer 耗时会直接进入 TTFT，应优先更换或启用 fast tokenizer。

SGLang：设备名识别异常

日志中一处将设备识别为 NVIDIA L20D，但其他位置又正确识别为 B300 / GB300、SM100 / SM103。DCP 通信后端会根据设备名查表选择，建议确认 a2a 是否由错误条目触发。

同时，日志提示：

DeepGemm is enabled but the scale_fmt of checkpoint is not ue8m0

这可能在 Blackwell 平台上带来精度问题，需要进一步验证。

vLLM：显存利用率设置过高

--gpu-memory-utilization 0.95 使 KV Cache 超额提交。运行期每张卡需要额外约 4.52 GB，但当时只剩约 2.67 GB，于是触发多轮分配器清缓存与重试。

建议将显存利用率降至 0.92，或使用日志给出的 --kv-cache-memory 值显式限制。

vLLM：部分“已启用”融合可能未实际生效

日志显示 norm_quant、act_quant 与 allreduce_rms 已启用，但这些属于 Inductor 编译期 pass；Kimi-K3 自动开启 VLLM_USE_BREAKABLE_CUDAGRAPH 后，编译模式可能被强制设为 NONE，因此对应融合未必真正应用。

此外，本轮还关闭了 FlashInfer autotune。vLLM 的结果可能低于其最佳状态，复测时应重新检查实际生效的编译与算子配置。

代码层根因：DCP 与投机解码在两个引擎中的取舍

这是整份分析里最硬的一条结论，而且它不是调参能绕开的。

前面 200K 场景的性能反转，表面看起来像是“vLLM 忘了开 DCP”。但源码显示并非如此：vLLM 结构性地不允许 DCP 和 DSPARK 同时开启。当 decode_context_parallel_size > 1 遇到 K3DSparkModel 时会直接抛出异常（config/speculative.py:978-986）。

因此，在 vLLM 上若要获得长上下文的 KV 分片收益，就必须整条放弃投机解码。

SGLang 可以同时开启 DCP 与 DSPARK，但同样需要付出代价：dcp_size > 1 会强制设置 SGLANG_RAGGED_VERIFY_MODE=static（overrides.py:356-362）。此时 DSPARK 的 SPS 成本表、STS 温度校准、置信度 planner 和块接受率估计器等自适应机制均不再激活，每个请求都会验证完整的 8-token 窗口，无法进行自适应裁剪。

这也解释了为什么 SGLang 能在 200K 场景中保住 DCP 的长上下文收益，但投机接受长度始终偏低。

能力组合	vLLM	SGLang	对选型的含义
DCP + 投机解码	不允许，启动即抛异常	允许，但投机降级为非自适应	长上下文场景两边都需要取舍，只是取舍点不同
长上下文 KV 分片	只能关闭投机后使用	可与投机共存	SGLang 在 200K 的优势具有结构性来源
自适应投机（SPS / STS / planner）	无此机制，依靠 block 验证提高接受率	有，但开启 DCP 后失效	两边都没有“长上下文 + 高接受率”的现成配置
接受判据可调性	两个显式参数，均可向更宽松方向调整	阈值在 kernel 内硬编码为 1.0	SGLang 侧没有现成旋钮可调

其余几个只有读代码才能发现的点

SGLang 的 KDA 融合验证内核大概率没有运行

启动参数解析得到 linear_attn_verify_backend=nv_cutedsl，但 dispatcher 在赋值时直接将 verify_kernel 指向 triton_kernel（kda_backend.py:97-98）。融合 CuTe 路径只会在运行期通过 _can_run_dspark_cutedsl_mtp() 的严格形状约束后尝试。

日志最终显示 verify=TritonKDAKernel，说明实际回退到了 Triton，验证侧仍有一部分性能潜力没有释放。

SGLang“第二个 KV 池”的身份

日志中的 7,333,376 = 916,672 × 8，正好是 dcp_size 的倍数。它并不是第二种架构池，而是草稿 worker 的 MHA KV 池按 DCP 虚拟 token 空间寻址的结果。

草稿模型使用 trtllm_mha 稠密注意力，因此 K/V 分开记账，各占约 4.37 GB。

vLLM 的 1536 attention block 是由 Mamba 对齐要求产生的

混合模型要求 attention 页的字节数不小于 Mamba 页，因此 block 从 32 被提高到 1536，再通过约 0.70% 的 Mamba 页 padding 使两类页的字节数对齐（platforms/interface.py:890-940）。

代价是约 0.7% 的字节浪费和更粗的前缀缓存粒度。这个 1536 边界又会反馈给 align 模式的分块切分，间接参与前文提到的 Decode 饿死问题。

vLLM 2.69× 并发上限的来源

限制并不是 KV 总量不足，而是 scheduler_reserve_full_isl=True 默认要求在请求准入时就按完整最大序列长度预留 KV。

如果将 --max-model-len 从 1M 调整为实际业务长度，并发能力会立即提高。

选型建议

输入不超过 64K，吞吐优先

优先选择 vLLM。

本轮 64K 场景中，vLLM 解码吞吐约领先 1.5～1.6×，端到端耗时领先约 1.5×。在较短上下文中，避免 DCP 通信开销更有利。

200K 及以上长文服务

优先考虑 SGLang + DCP。

本轮 200K 场景中，SGLang 解码约领先 1.64×，并且随上下文增长的性能退化明显更缓。不过上线前必须先将 KV 池提高到不低于目标 context-length。

它也是当前两侧中唯一可以同时保留 DCP 与投机解码的一方，但开启 DCP 后，DSPARK 会退化为非自适应验证模式。

长上下文 + 高并发

当前配置下更倾向 vLLM，但需要复测。

vLLM 在 1M 上下文下理论 KV 容量约为 2.69 路，而 SGLang 当前全注意力池不足 1M，且 Mamba 状态缓存将最大运行请求数压缩到 39。

如果 SGLang 调整 KV / Mamba 内存比例后，再与“关闭投机、开启 DCP”的 vLLM 进行对照，结论可能发生变化。

下一轮如何做严格复测

新版源码分析显示，vLLM 无法同时开启 DCP 与 DSPARK，因此不能简单地“给 vLLM 也开 DCP”来进行二方对齐。更合理的方式是增加 SGLang 关闭 DCP 的第三组，并同时优化两侧各自可修复的问题。

#	动作	对象	理由
1	设置 --long-prefill-token-threshold 4096	vLLM	单条 Prefill 分块独占 32768 预算，导致 Decode 饿死；这是本次 vLLM 长上下文吃亏的头号可修项
2	换掉 Random 数据集，改用 ShareGPT / 真实长文档	压测平台	当前投机解码接受率 1%～8%，测到的是“投机纯做负担”，与生产完全脱节
3	改用 time-to-first-any-delta 计算 TTFT	压测平台	思维链输出位于 delta.reasoning；从 delta.content 计算首 token 会同时抬高两侧 TTFT
4	修复压测平台的吞吐统计口径	压测平台	vLLM 输出吞吐被稳定虚高约 11×，且出现总吞吐小于输入吞吐的矛盾
5	将 gpu-memory-utilization 降到 0.92，或钉住 --kv-cache-memory=38.48GiB	vLLM	消除 8 卡×4 轮的运行期 OOM 重试；当前 KV 池存在超额提交
6	增加“SGLang 关闭 DCP”测试组，进行三方对照	SGLang	vLLM 无法同时开启 DCP + DSPARK，只能通过反向对齐验证 DCP 与 static 验证模式的代价
7	将 --max-model-len 降到真实业务长度	vLLM	并发受 scheduler_reserve_full_isl 满长预留支配，当前 1M 设置白白压低并发能力
8	扩展 warmup，覆盖 4 个现场 JIT 的算子形状	vLLM	首批请求的 TTFT 被 Triton 现场编译拉高
9	去掉 --no-enable-flashinfer-autotune	vLLM	MoE 运行在 FLASHINFER_TRTLLM_MXFP4_MXFP8 上，却只使用启发式 tactic
10	去掉 --disable-custom-all-reduce，排查多播不可用	SGLang	小批 Decode 的通信占比高；vLLM 侧已经使用 FlashInfer AR + RMSNorm 融合
11	确认 KDA 融合验证内核没有走 CuTe 路径的原因	SGLang	verify 实际回退到 Triton，验证侧仍有一部分性能潜力没有释放
12	提供 FP8 KV scaling factor，并进行精度回归	两侧	两边都在 scale=1.0 下运行 FP8 KV，性能结论缺少精度前提
13	抬高 --mamba-full-memory-ratio 或改用 bf16 SSM，并抬高 KV 池	SGLang	解除 39 路并发上限，并让 max_total_num_tokens ≥ 1M
14	补充 P99 与更高并发（≥64 路）档位	压测平台	当前并发 10 远未触及两侧调度器和并发上限的差异

总结

这次 8×B300 单机测试最有价值的地方，不是简单得出“谁更快”，而是清楚展示了上下文长度如何改变推理瓶颈：

• 64K 阶段，通信开销更敏感，vLLM 更有优势；
• 200K 阶段，KV 读带宽成为核心瓶颈，SGLang + DCP 反超；
• Prefill 不是主要差距来源，Decode 扩展性才是关键；
• 投机解码在 Random 数据集下几乎完全失效；
• 显存分配、TTFT 口径和客户端吞吐统计都会显著影响结论。

因此，生产选型不能只看单一 TPS。上下文长度、并发规模、KV 容量、DCP 配置、真实请求分布与输出质量，必须放在同一套评测体系中综合判断。

About GPUStack

GPUStack 是由 GPUStack.ai 所推出的开源项目。GPUStack.ai 成立于2022年，是 AI Infra 解决方案提供商，目前已完成5300万元种子轮融资。创始团队成员均来自业界应用广泛的 Kubernetes 管理平台 Rancher 的核心团队。其中，联合创始人及 CTO 梁胜博士是前 SUSE 全球工程及创新总裁，加入 SUSE 之前，梁胜博士于2014年9月创立全球著名的容器管理平台公司 Rancher Labs 并担任 CEO。

我们的愿景是赋能企业可以在任意环境使用人工智能以实现业务的卓越运营。GPUStack 是实现这一目标的重要一步。

使用 GPUStack 迅速搭建你的专属 MaaS 平台！开始在本地快速构建 GPU 集群，运行和使用各种 AI 模型，赋能您的 AI 应用。