本文记录 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-size8而 vLLM 的decode_context_parallel_size1。两侧 Prefill 能力接近主要差异来自 Decode 阶段。Random 数据集使 DSPARK 投机解码的接受率极低因此本轮结果不能直接代表真实生产流量。重要说明这不是严格对等的 A/B 测试。两套引擎在 DCP、显存分配、算子后端、接受判据等方面存在差异。本文更适合用来理解瓶颈与选型方向不应被视为最终性能排名。测试环境本次测试环境如下项目配置服务器单机GPU8×NVIDIA B300单卡可见显存267.69 GiB模型Kimi-K3MXFP4草稿模型Kimi-K3-DSpark推理引擎vLLM / SGLang测试输入64K、200K 及多种长度输出长度3K并发10数据集Random准备模型权重使用 ModelScope 下载 Kimi-K3 主模型与 DSpark 草稿模型。下载 Kimi-K3 主模型MXFP4modelscope download\--modelmoonshotai/Kimi-K3\--local_dir./Kimi-K3下载 vLLM 使用的 DSpark 草稿模型modelscope download\--modelskyai/Kimi-K3-DSpark\--local_dir./Kimi-K3-DSpark下载 SGLang 使用的 DSpark 草稿模型modelscope download\--modelskyai/sglang-Kimi-K3-DSpark\--local_dir./Kimi-K3-DSpark拉取推理镜像拉取 vLLM 镜像dockerpull vllm/vllm-openai:kimi-k3拉取 SGLang 镜像dockerpull lmsysorg/sglang:kimi-k3镜像准备完成后在 GPUStack 的推理后端中分别为 vLLM 和 SGLang 添加自定义版本。在 GPUStack 中部署 vLLM在 GPUStack 中创建 vLLM 自定义后端选择 Kimi-K3 模型、8 张 B300并配置所需环境变量。vLLM 自定义后端及模型配置如下vLLM 环境变量VLLM_ENABLE_K3_LATENT_MOE_TAIL_FUSION1VLLM_ALLREDUCE_USE_FLASHINFER1VLLM_ENGINE_READY_TIMEOUT_S3600VLLM_USE_V2_MODEL_RUNNER1VLLM_USE_RUST_FRONTEND1vLLM 启动参数--trust-remote-code --load-format fastsafetensors --moe-backend auto --gpu-memory-utilization0.95--tensor-parallel-size8--max-model-len1000000--kv-cache-dtype fp8 --attention-config{mla_prefill_backend:TRTLLM_RAGGED,use_prefill_query_quantization:true}--max-num-batched-tokens32768--enable-prefix-caching --enable-auto-tool-choice --tool-call-parser kimi_k3 --reasoning-parser kimi_k3 --max-num-seqs32--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-pathKimi-K3 模型路径--tp-size8--dcp-size8--disable-custom-all-reduce --enable-symm-mem --mem-fraction-static0.85--reasoning-parser kimi_k3 --tool-call-parser kimi_k3 --mamba-full-memory-ratio0.86--host0.0.0.0--port30000--speculative-algorithm DSPARK --speculative-draft-model-pathKimi-K3-DSpark 模型路径--speculative-dspark-block-size7--enable-linear-replayssm-spec --chunked-prefill-size32768--max-prefill-tokens32768--context-length1000000--kv-cache-dtype fp8_e4m3服务启动后可在 GPUStack 中查看实时日志、吞吐与 KV Cache 状态。64K / 3K、10 路并发对比首先使用 64K 输入、3K 输出、10 路并发进行测试。vLLM 测试结果SGLang 测试结果测试期间的推理日志如下不同输入长度下的测试除 64K 外本轮还测试了多种输入长度用于观察上下文增长对 TTFT、TPOT、ITL 与端到端耗时的影响。vLLMSGLang核心结果64K 与 200K 之间发生性能交叉从客户端可信指标与引擎日志综合看两套引擎在 64K 和 200K 之间发生了明显的性能交叉场景vLLMSGLang结果64K 端到端耗时100.5 s150.8 svLLM 领先约 1.5×200K 端到端耗时295.2 s225.3 sSGLang 领先约 1.31×64K 稳定解码吞吐约 501 tok/s约 335 tok/svLLM 领先约 1.5×200K 稳定解码吞吐约 163 tok/s约 268 tok/sSGLang 领先约 1.64×64K→200K 解码退化3.29×1.25×SGLang 扩展性更好一句话解释vLLM 在较短上下文中没有 DCP 通信开销因此更快上下文增长后SGLang 的 DCP8 将每张卡需要读取的 KV 数据量大幅分摊长上下文 Decode 反而更有优势。但读完两边源码后这个差异不是“vLLM 忘了开”那么简单vLLM 在代码里明确禁止 DCP 与 DSPARK 投机解码共存想要 DCP 就必须放弃投机SGLang 允许二者共存代价是投机退化为非自适应模式。也就是说这是一道架构层的取舍题而不是配置疏漏。为什么会发生性能交叉1. Decode 扩展性是决定性因素取 10 路请求全部进入解码后的稳定段解码聚合吞吐10 路并发稳定段均值单位 tok/s数据来源为引擎自报日志。vLLMDCP164K稳定段约 439537 tok/s峰值 537 tok/s。折算单请求约 53.7 tok/s即约 18.6 ms/token。200K稳定段约 157.8166.6 tok/s均值约 163 tok/s。折算单请求约 16.3 tok/s即约 61.3 ms/token。上下文增长约 3.1×解码性能下降 3.29×呈近似线性退化。SGLangDCP864K稳定段约 313418 tok/s均值约 335 tok/s。折算单请求约 33.5 tok/s即约 29.9 ms/token。200K稳定段约 252288 tok/s均值约 268 tok/s。折算单请求约 26.8 tok/s即约 37.3 ms/token。上下文增长约 3.1×解码性能仅下降 1.25×。在 64K 场景中DCP 每一步增加的通信成本还没有被 KV 读取收益抵消所以 vLLM 更快到了 200KKV 读带宽成为主要瓶颈SGLang 的 DCP 优势开始显现。2. Prefill 能力基本打平两侧的chunked-prefill/max-num-batched-tokens都设置为 32768稳定 Prefill 聚合吞吐约为19K23K 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 场景下双方平均接受长度都接近 1vLLM约 1.051.17SGLang约 1.051.17。这意味着系统为草稿模型付出了额外算力却几乎没有获得投机解码收益。vLLM 200K 轮中Drafted throughput 约 990 tok/s而 Accepted throughput 仅约 21 tok/s约98% 的草稿计算被丢弃。不同场景下的接受长度与接受率如下场景引擎接受长度接受率 / 草稿命中率解释64KvLLM2.272.5118%21%唯一还有实质收益的一档每次前向多落地约 1.5 token64KSGLang1.211.553%8%同样数据、同样草稿模型却明显弱于 vLLM——值得单独查200KvLLM1.051.171.1%2.5%完全崩塌草稿算力 98% 浪费200KSGLang1.051.171%2%同样崩塌结论本轮测到的是“投机解码纯负担”场景不能直接外推到真实生产流量。下一轮应改用 ShareGPT、真实业务请求或其他自然语言数据集。两套引擎的接受判据也不同两边草稿权重同源但验证策略不同vLLM 显式设置draft_sample_methodprobabilistic和rejection_sample_methodblock采用更宽松的概率式分块验证。SGLang 的 DSPARK 路径采用严格的 greedy 逐位匹配块内第一个 token 不匹配后续 token 会全部作废。因此在相同草稿模型下两套引擎仍可能出现明显不同的平均接受长度。若要严格验证投机解码收益需要统一数据集、采样参数、gamma 与接受判据。客户端指标先排除不可信的吞吐列四组客户端测试的可信指标汇总如下指标vLLM 64KSGLang 64KvLLM 200KSGLang 200K总耗时s100.5150.82295.21225.34请求延迟均值s84.42141.53284.58217.83TTFT 均值ms34,838.841,670.6125,210.859,002.0TTFT P50ms34,181.140,391.9125,189.254,104.0TTFT P90ms36,987.953,525.0126,667.0103,336.0TPOT 均值ms12.2847.1845.2172.6ITL 均值ms9.9433.33.4752.96失败 / 未完成0 / 00 / 00 / 00 / 0截图中的部分吞吐字段无法与总 token 数、并发和耗时相互校验。例如vLLM 200K 显示输出吞吐 1111.61 tok/s但按10 × 3000 ÷ 295.21计算物理上限约为 101.6 tok/s64K 测试也存在接近 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_threshold0时队首长请求可能一次吃满 32768 token 预算导致其他已经进入运行态的请求拿不到一个 token 的 Decode 调度从而形成较平的高 TTFT。显存分配与 KV Cache 容量每张 B300 可见显存为 267.69 GiB两侧模型权重占用接近但剩余显存分配策略差异很大。vLLM项目数值模型权重及 non-torch197.72 GiB峰值激活12.82 GiBCUDA Graph5.13 GiBKV Cache43.76 GiBKV 池容量为 2,687,776 token1M 上下文下理论最大并发约为 2.69×。但当前配置存在超额提交。vLLM 日志提示若要真正落入 0.95 显存预算KV Cache 应降至38.48 GiB而本轮实际分配了 43.76 GiB。这也是运行期 OOM 重试的主要来源。可选择以下一种方式修正方案一降低显存利用率--gpu-memory-utilization0.92方案二显式限制 KV Cache--kv-cache-memory41317885440SGLang项目数值模型权重195.86 GiB全注意力 KV Cache11.80 GiB草稿模型 KVK-V8.74 GiBMamba / SSM 状态10.93 GiB剩余空间17.08 GiB全注意力池容量为 916,672 token草稿池容量为 7,333,376 token。当前配置声明context-length1000000但全注意力池只有 916,672 token比目标上下文少约 8.3%。也就是说单条满 1M 请求无法完整放入 KV 池。同时max_running_requests从 48 被压缩到 39瓶颈来自 Mamba 状态缓存而非普通 KV Cache。对于 1M 长上下文高并发场景vLLM 当前的容量余量更大。冷启动开销两套引擎总冷启动时间都在 10 分钟左右但耗时分布不同阶段vLLMSGLang备注容器创建完成17:06:2118:01:45GPUStack 创建时间权重加载163.8 s141.0 svLLM 12 shard / fastsafetensorsSGLang 96 shard / 多线程权重体积单卡194.54 GiB195.86 GBMXFP4 MoE compressed-tensors算子预热CuTeDSL 25 单元 13.816.9 s KDA TritonKDA prefill / vision FA4 / RoPE 预编译两侧都有 K3 专用 JIT 预热CUDA Graph 捕获8588 s / 5.13 GiB / 51 档约 5.5 min / 67 档SGLang 档位更密且含 DSpark 草稿图折叠引擎初始化合计409.61 s约 370 svLLM 显式打印SGLang 由时间戳推算服务可用约 17:16:5718:11:59SGLangserver is fired up容器→可用总时长约 10.6 min约 10.2 min同量级vLLM 的主要耗时来自 profile、KV 分配与 warmup约 409.6 秒SGLang 的主要耗时来自 CUDA Graph 捕获约 5.5 分钟。如果服务需要频繁扩缩容应把冷启动时间纳入容量规划并尽量通过常驻实例、预热或分批扩容降低影响。配置并不完全对等本轮两套技术栈的主要差异如下项目vLLMSGLang可能影响解码上下文并行DCP1关闭DCP8comma2a复制 Q 投影主导长上下文解码的全部差距All-ReduceFlashInfer Custom SymmMem且与 RMSNorm 融合显式--disable-custom-all-reduce多播不可用→回退普通 NCCL高小批解码通信占比大MLA 预填充后端TRTLLM_RAGGED 查询量化trtllm_mla中MLA 解码后端FLASHINFER_MLAcutedsl_mla混合后端官方标注 experimental中线性注意力KDAFlashKDA 预填充内核Tritondecode / verify / extend 全 Triton中Triton 相对手写 CUDA 通常有差距MoE 后端FLASHINFER_TRTLLM_MXFP4_MXFP8autotune 被关flashinfer_mxfp4trtllm-gen SiTU cubin中autotune 关闭意味着 GEMM tiling 未调KV 页大小block 32为对齐 Mamba 抬到 attn block 1536page_size 64中1536 对齐带来内部碎片torch.compile被 BREAKABLE_CUDAGRAPH 自动关闭即 modenone未启用中仅剩手写 custom_ops 三个融合前端Rust frontendVLLM_USE_RUST_FRONTEND1Python / uvicorn低中高并发下 tokenize / SSE 开销显存占用系数0.950.92低中直接反映在 KV 池大小并发上限max_num_seqs6448→39Mamba 状态缓存封顶中本轮并发仅 10未触发Model RunnerV2 异步调度标准调度 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 编译期 passKimi-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_MODEstaticoverrides.py:356-362。此时 DSPARK 的 SPS 成本表、STS 温度校准、置信度 planner 和块接受率估计器等自适应机制均不再激活每个请求都会验证完整的 8-token 窗口无法进行自适应裁剪。这也解释了为什么 SGLang 能在 200K 场景中保住 DCP 的长上下文收益但投机接受长度始终偏低。能力组合vLLMSGLang对选型的含义DCP 投机解码不允许启动即抛异常允许但投机降级为非自适应长上下文场景两边都需要取舍只是取舍点不同长上下文 KV 分片只能关闭投机后使用可与投机共存SGLang 在 200K 的优势具有结构性来源自适应投机SPS / STS / planner无此机制依靠 block 验证提高接受率有但开启 DCP 后失效两边都没有“长上下文 高接受率”的现成配置接受判据可调性两个显式参数均可向更宽松方向调整阈值在 kernel 内硬编码为 1.0SGLang 侧没有现成旋钮可调其余几个只有读代码才能发现的点SGLang 的 KDA 融合验证内核大概率没有运行启动参数解析得到linear_attn_verify_backendnv_cutedsl但 dispatcher 在赋值时直接将verify_kernel指向triton_kernelkda_backend.py:97-98。融合 CuTe 路径只会在运行期通过_can_run_dspark_cutedsl_mtp()的严格形状约束后尝试。日志最终显示verifyTritonKDAKernel说明实际回退到了 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_islTrue默认要求在请求准入时就按完整最大序列长度预留 KV。如果将--max-model-len从 1M 调整为实际业务长度并发能力会立即提高。选型建议输入不超过 64K吞吐优先优先选择 vLLM。本轮 64K 场景中vLLM 解码吞吐约领先 1.51.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 4096vLLM单条 Prefill 分块独占 32768 预算导致 Decode 饿死这是本次 vLLM 长上下文吃亏的头号可修项2换掉 Random 数据集改用 ShareGPT / 真实长文档压测平台当前投机解码接受率 1%8%测到的是“投机纯做负担”与生产完全脱节3改用 time-to-first-any-delta 计算 TTFT压测平台思维链输出位于delta.reasoning从delta.content计算首 token 会同时抬高两侧 TTFT4修复压测平台的吞吐统计口径压测平台vLLM 输出吞吐被稳定虚高约 11×且出现总吞吐小于输入吞吐的矛盾5将gpu-memory-utilization降到 0.92或钉住--kv-cache-memory38.48GiBvLLM消除 8 卡×4 轮的运行期 OOM 重试当前 KV 池存在超额提交6增加“SGLang 关闭 DCP”测试组进行三方对照SGLangvLLM 无法同时开启 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-autotunevLLMMoE 运行在 FLASHINFER_TRTLLM_MXFP4_MXFP8 上却只使用启发式 tactic10去掉--disable-custom-all-reduce排查多播不可用SGLang小批 Decode 的通信占比高vLLM 侧已经使用 FlashInfer AR RMSNorm 融合11确认 KDA 融合验证内核没有走 CuTe 路径的原因SGLangverify 实际回退到 Triton验证侧仍有一部分性能潜力没有释放12提供 FP8 KV scaling factor并进行精度回归两侧两边都在 scale1.0 下运行 FP8 KV性能结论缺少精度前提13抬高--mamba-full-memory-ratio或改用 bf16 SSM并抬高 KV 池SGLang解除 39 路并发上限并让max_total_num_tokens ≥ 1M14补充 P99 与更高并发≥64 路档位压测平台当前并发 10 远未触及两侧调度器和并发上限的差异总结这次 8×B300 单机测试最有价值的地方不是简单得出“谁更快”而是清楚展示了上下文长度如何改变推理瓶颈64K 阶段通信开销更敏感vLLM 更有优势200K 阶段KV 读带宽成为核心瓶颈SGLang DCP 反超Prefill 不是主要差距来源Decode 扩展性才是关键投机解码在 Random 数据集下几乎完全失效显存分配、TTFT 口径和客户端吞吐统计都会显著影响结论。因此生产选型不能只看单一 TPS。上下文长度、并发规模、KV 容量、DCP 配置、真实请求分布与输出质量必须放在同一套评测体系中综合判断。About GPUStackGPUStack 是由 GPUStack.ai 所推出的开源项目。GPUStack.ai 成立于2022年是 AI Infra 解决方案提供商目前已完成5300万元种子轮融资。创始团队成员均来自业界应用广泛的 Kubernetes 管理平台 Rancher 的核心团队。其中联合创始人及 CTO 梁胜博士是前 SUSE 全球工程及创新总裁加入 SUSE 之前梁胜博士于2014年9月创立全球著名的容器管理平台公司 Rancher Labs 并担任 CEO。我们的愿景是赋能企业可以在任意环境使用人工智能以实现业务的卓越运营。GPUStack 是实现这一目标的重要一步。使用 GPUStack 迅速搭建你的专属 MaaS 平台开始在本地快速构建 GPU 集群运行和使用各种 AI 模型赋能您的 AI 应用。