问题
推理存储加速项目应该怎么验收,才不会为没有兑现的性能买单?
结论
把验收拆成四道按周推进的门禁,每一道都有可以测量的通过条件,任何一道不达标就停在那里:G1 到货验收(第 2 周)、G2 单机基线(第 4 周)、G3 联测主门禁(第 7 周)、G4 稳定性与验收(第 10 周)。
为什么要分门禁
性能类项目最常见的纠纷是:设备到了、钱付了,上线后的数字和方案书对不上,而双方对「怎么算达标」各有说法。
门禁化的做法是把这个争议提前。合作开始之前就写清楚每个阶段测什么、测到多少算过;过了才进下一阶段,没过就止损。买方承担的风险被限制在当前这一道门禁以内。
四道门禁的通过条件
门禁上的数字从哪里来
买方应该额外要求什么
除了门禁本身,有三样东西值得写进合作条款。
- 签字版报告:每道门禁的结果落在纸面上,而不是停留在演示里。
- 复现材料:补丁、负载客户端、编排脚本和原始数据,让你自己的团队能重跑R8。
- 可重算的测算模型:投入产出的测算用源码交付,你可以换成自己的参数重新计算。
相关实测报告
- R1FX100 大模型推理与训练综合性能测试报告(AMD MI308X × 8)一份报告回答五个问题:LMCache 并行读补丁有多大作用、KV 分层在多卡下能否扩展、8 卡并发加载模型快多少、频繁切换模型时算力有效利用率如何变化、训练 Checkpoint 并发写能快多少。测试模型为 Qwen2.5-32B 与 7B。
AMD Instinct MI308X × 8 · ROCm 7.2 - R2FX100 KV Cache 性能测试报告(480B · TP8 长上下文)Qwen3-Coder-480B-FP8 以八卡单实例(TP=8)的标准生产形态部署,在长上下文冷恢复负载下做三方对照:FX100、本地 NVMe 单盘、无外存整段重算,并按并发 8 / 16 / 32 做梯度。本站引用最多的吞吐与 TTFT 数字出自这份报告。
AMD Instinct MI308X × 8 · ROCm 7.2 - R3FX100 KV Cache 性能测试汇总报告(480B · TP4×2 · 全指标)同一台 8 卡服务器改为四卡双实例(TP4×2)部署,九档负载记录全部指标:TTFT 的 p50 / p90 / p99、TPOT、吞吐与盘带宽。这份报告还验证了两件事:fs:// 共享池能让两个实例热共享同一份缓存;同一档位做两轮独立测量,偏差不超过 5%。
AMD Instinct MI308X × 8 · ROCm 7.2 - R8FX100 KV Cache 测试代码导出包与原始测试数据让第三方能自己重跑一遍的全部材料:LMCache 并行读补丁(git patch 与修改前后全文)、负载客户端、编排脚本、探针取证脚本,以及原始测试数据。
AMD Instinct MI308X · ROCm 7.2
外部参考资料
- 01
延伸阅读
厂商给的推理性能数据,怎么核实真假?
核实厂商推理性能数据的五个检查项:对照基线、测试平台与部署形态、重复测量偏差、第三方报告、复现材料。附常见的数字陷阱和提问清单。
出处R2R3R4R5R8R9
KV Cache 分层在什么场景下没用?
KV Cache 分层的收益来自缓存命中。短对话、低并发、上下文从不重复、瓶颈在输出阶段,这四类负载收益有限。本文说明原因和自查方法。
出处R2
KV Cache 被逐出后重算还是读回?480B 模型实测
480B 模型、并发 16 的长上下文冷恢复负载下,整段重算与从 FX100 读回 KV Cache 的首 token 延迟和吞吐对比,附测试条件、两个对照基线和复现方式。
出处R2R3R4R8