使用 AI 助手时，响应的输出节奏很重要。更快的流式输出，有助于用户跟上解释、检查生成的代码，或决定接下来要问什么。
在 10 月的 DeepSeek V4.1 Flash 研究中，ProsGrow 在 4 张 MI325X GPU 上测得的解码交互速度中位数为 492.6 tokens/s/user。InferenceX 发布的同为 4 张 GPU、单会话的 H200 参考成绩为 332.2。我们的结果高出 48.3%。
这是一项仍在评估中的基准结果：该配置的本地质量评估尚未完成。它为交互式 DeepSeek 工作负载评估 AMD 提供了依据，但生产环境的适用性验证仍需完成。
标题背后的数据
| 指标 | 已发布的 H200 参考成绩 | ProsGrow 的 MI325X 结果 | 差异 |
|---|---|---|---|
| 解码交互速度中位数，tokens/s/user | 332.2 | 492.6 | +48.3% |
| 输出吞吐量，tokens/s/GPU | 37.45 | 42.83 | +14.4% |
DeepSeek V4.1 Flash；模型分配使用 4 张 GPU；1 个并发会话。H200 参考成绩：2026 年 9 月 21 日。ProsGrow 测量日期：2026 年 10 月 20 日。
解码交互速度衡量响应开始后的 token 生成速度。输出吞吐量衡量整个基准请求窗口内交付的输出，其中包含轮次之间的停顿。因此，标题中的 48.3% 指流式输出交互速度，并不表示完整响应或业务任务的完成速度提高了 48.3%。
相对于选定的参考成绩，这两项指标均有提升，但提升幅度不同。
值得测试的 AMD 部署选择
对于规划私有编码助手、文档工具或对话应用的团队，这些结果拓宽了值得评估的基础设施选择。模型、工作负载与推理服务软件，都可能显著影响 GPU 部署实际能够提供的性能。
商业机会在于根据应用所需的体验来选择基础设施。面向少量、对延迟敏感会话优化的服务，可能会采用与处理大量并发请求的服务不同的方案。
单会话结果不应外推至其他并发水平。我们测试的 8 会话配置仍低于对应的已发布 H200 参考成绩。这一结果支持针对特定需求做部署决策，不能据此声称某种 GPU 在所有工作负载上都更快。
ProsGrow 做了哪些改进
我们集成并评估了公开 vLLM ROCm 推理服务栈中能够降低生成阶段开销的改进。ProsGrow 的工作重点是选择合适的配置，与本地对照配置进行检查，并通过录制的智能体工作负载测量其表现。
底层实现来自上游 vLLM 社区。要将这项能力转化为可供选择的部署方案，需要明确它在哪些场景中有效、哪些硬件能够支持，以及还需要完成哪些验证。
这就是标题背后的工作：将软件能力与具体工作负载相结合，再测量实际结果。
测量说明
H200 数据来自一次已发布的 InferenceX 测试，保存在我们 10 月 19 日快照的第 442749 行。这是与不同主机、不同软件配置上的历史参考结果进行比较，并非同时开展的纯硬件对照测试，也不是更新后的排行榜成绩。
本地结果采用计划时长为 1 小时的 AgentX 测试，并模拟推测生成的接受行为。解码交互速度中位数遵循归档基准中对 token 间延迟取倒数的定义，不能替代首 token 延迟或端到端任务延迟。该配置仅进行过 1 次正式性能测试，未提供置信区间。
尚未完成的本地质量评估，是生产适用性验证之前必须完成的下一步。还需要测试应用特定的正确性、真实验证下的性能，以及目标并发水平。
评估适合您业务的 AMD DeepSeek 部署
ProsGrow 帮助团队探索私有推理与专用 AMD GPU 部署。我们可以从您的应用真正关注的提示词和响应时间目标出发，评估配置能否满足这些要求。