ProsGrow 如何将 DeepSeek v4 Flash 首 token 延迟最高降低 32%

结果：等待时间缩短 30% 以上

对于处理文档或编程请求的助手而言，开始生成内容前的等待也是用户体验的一部分。在真实服务测试中，针对约 8,000 token 的提示词，ProsGrow 将这一等待从 0.564 秒缩短至 0.384 秒，即首 token 延迟（TTFT）降低 32.0%。

对比在同一台配备 8 × AMD MI325X 的主机上使用 DeepSeek V4.1 Flash，并与模型修订版本和运行时版本均相同的本地基线比较。无缓存请求均未命中前缀缓存。三种受测提示词长度都获得了改善。

对于最长的受测提示词，这意味着收到首段内容前的等待约缩短 5.66 秒。标题中的结果指首 token 延迟；完整请求吞吐量将在下文单独说明。

性能提升来自哪里

我们重点研究推理服务栈如何在 AMD 硬件上执行模型，尤其是开始生成前处理输入提示词所需的工作。通过性能分析和有针对性的运行时优化，我们释放了现有部署中的性能潜力。

这一结果建立在 DeepSeek 模型以及上游 vLLM 和 AMD AITER 运行时能力之上。我们保留了原始检查点精度，并在推测式生成中使用真实目标模型进行验证，没有引入额外的有损量化。

对于运营私有 AI 基础设施的团队，这表明在扩展硬件之前，先测量推理服务瓶颈可能带来收益。合适的优化方式取决于模型、提示词长度以及应用的响应时间要求。

吞吐量与质量检查

在一项独立的部署后检查中，使用重复且已缓存的提示词，三种提示词长度的完整请求输出吞吐量提升了 7.7–10.2%。这一指标包括等待首个 token 以及接收完整响应的时间。缓存请求的首 token 延迟略有上升，增幅为 2.4–3.2%，因此收益取决于工作负载更看重哪项指标。

在正式采用优化配置前，我们对相同的 128 道数学题，分别在短提示词和长提示词条件下进行对比。两种条件下，均未出现基线回答正确、优化后却回答错误的情况，且部署后的六项功能检查全部通过。这些有限范围的检查支持此次变更；更广泛的编程、多语言和客户任务质量仍需分别评估。

InferenceX 参考结果与 ProsGrow 对比

在一项独立的一小时 AgentX 基准测试中，我们优化后的部署达到了每用户 261.780 token/s 的交互性中位数，而保存的 InferenceX MI325X 参考结果为 239.808，即提升 9.16%。每张 GPU 的输出吞吐量从 15.83257 提升至 16.55379 token/s，即提升 4.56%。

这些运行使用基准测试的合成推测接受长度 3.51。这是性能测试设置，与我们在服务和质量测试中使用的真实验证相互独立。图中的提升也与无缓存首 token 延迟降低 32% 的结果分别测量。

交互性中位数是 token 间延迟中位数的倒数，并采用仪表板的舍入规则。吞吐量包含请求轨迹中的空闲时间。历史参考未完整标明检查点和运行时镜像，因此这是一次部分复现的参考对比。公开运行与优化运行分别完成了 244 和 252 个纳入性能分析的请求，因此已完成请求的组成不同。每个配置仅运行一次，未提供置信区间。此处展示的 ProsGrow 测量均为本地结果。

测量范围

测试于 2026 年 9 月 24 日进行，模型分布在全部八张 GPU 上。每个真实服务请求均生成恰好 1,024 个输出 token。TTFT 从请求开始计时，到流式响应中出现首个非空内容为止。对应的提示词和输出长度保持一致，并确认无缓存请求的前缀缓存命中次数为零。

每个无缓存配置在每种提示词长度下先进行一次预热，再测量四个请求。各次运行顺序执行，编译与缓存历史不同。这些是与我们复现的基线对比的本地测量；结果会随流量、并发量和提示词组合而变化。32% 是三种受测长度中观察到的最大降幅，不代表置信区间或生产环境 SLA 承诺。

私有 DeepSeek 托管与 AMD GPU 算力

对于评估私有 DeepSeek 托管或独享 AMD GPU 服务器的团队，这项基准测试将部署规划与模型精度、提示词长度和响应时间联系起来。首 token 延迟（TTFT）衡量答案何时开始输出；完整请求吞吐量则衡量体验的另一个方面。ProsGrow 可以针对您的私有推理工作负载评估这些权衡。