超越 InferenceX MI325X 参考成绩：DeepSeek 吞吐量提升 60%

对于构建私有 AI 服务的团队，有效容量是一个业务问题：部署能够处理多少工作量？流量增加时，用户需要等待多久才能收到响应？

在 10 月的 DeepSeek V4.1 Flash 研究中，更新后的推理服务配置在相同的双 GPU 配额、32 个并发基准会话下，每 GPU 输出吞吐量比 9 月 22 日的 InferenceX MI325X 参考成绩高出 60.1%。与同一台机器上我们自己的基线相比，提升幅度为 60.8%。

硬件配额没有变化。机会来自推理服务软件使用硬件的方式。

结果：相同 GPU 配额，更多输出

DeepSeek V4.1 Flash；1 个模型实例使用 2 张 GPU；32 个并发轨迹会话。公开参考成绩日期为 2026 年 9 月 22 日；ProsGrow 的本地测量日期为 10 月 20 日。

本地对照测试还显示，响应开始前的等待时间明显缩短。平均首 token 延迟从 4.70 降至 1.09 秒，降低 76.8%。在 1 小时的基准测试中，优化后的测试完成了 2,785 个性能分析请求，基线测试则完成了 1,896 个。

这些指标反映了不同的收益：更多输出容量、更短的生成前等待时间，以及更多已处理请求。这里的完成请求是基准测试请求，并非已完成客户任务的数量。

这对私有 AI 容量意味着什么

助手可能在多个轮次中重复访问相同的文档、指令和对话历史。如果推理服务栈反复处理本可以复用的工作，可用 GPU 容量就无法为应用完成更多有效工作。

我们的结果提示，在扩展推理部署之前，可以先做一项切实的评估：用有代表性的流量测量现有系统，检查其推理服务配置。对于具有类似复用模式的工作负载，软件调整可能在相同 GPU 配额内释放更多容量。

这是一项值得调查的容量空间。要将其换算成每请求成本，还需要实际托管价格、利用率、CPU 与内存资源，以及应用质量目标。本研究没有测量客户的成本节省。

我们如何找到改进空间

ProsGrow 将更新的开源推理服务栈与智能体轮次之间更有效的可复用上下文利用方式结合起来。我们建立了本地基线，评估候选配置，并比较完整基准测试的结果。

这项工作基于 DeepSeek 和 vLLM ROCm 生态。我们的贡献是识别部署中的改进机会、集成配置，并测量其在 MI325X 上的表现。60.8% 的本地提升反映了软件与配置更新的综合效果。

这延续了我们在早期 DeepSeek 延迟研究中以工作负载为中心的方法。该研究与这些 10 月测量属于不同实验，其提升百分比不应相加。

测量说明

这些是 ProsGrow 采用归档 InferenceX AgentX 协议得到的本地工程结果：录制的智能体轨迹、计划时长为 1 小时的测试，以及模拟的推测接受行为。模拟用于控制性能测试条件；生产响应需要真实验证和单独的验证工作。吞吐量按观测到的请求窗口内生成的输出计算，包含轨迹中的停顿。

标题将我们的测量结果与一次带日期的公开参考测试进行比较，该参考保存在我们 10 月 19 日快照的第 442868 行。这不是对更新后 InferenceX 排名的声明。本地前后对照测试提供了同一机器上的比较。这里报告的每个本地配置均只有 1 次正式测试，未提供置信区间。

另一次小规模质量检查使用了不同的 GPU 配额和并发数，不能据此确定本次双 GPU、32 会话配置的质量。客户任务质量与真实服务响应时间，仍属于生产适用性验证的必要内容。

发现现有部署中的容量空间

ProsGrow 可以根据您的请求组合、流量、响应时间目标和基础设施预算，帮助评估私有 DeepSeek 托管。先建立经过测量的基线，再测试合适的推理服务配置能够释放多少容量。

与 ProsGrow 讨论私有推理试点。