AMD在10月8日发布技术文章，解释MI455X与MI355X的部分推理比较数据，展示吞吐量与交互响应之间的关系，并说明测试设置。这类材料有助于理解厂商数字，但它依然是特定条件下的结果，不能直接当作所有业务的固定提升比例。
随着AI推理场景增加，同一硬件可能在不同模型、输入长度和并发下呈现不同表现。以下从评估方法出发，讨论读性能图时需要保留哪些信息。
先确认比较的是哪一种工作
短问答、长文档处理和批量离线任务，对系统的要求并不相同。有的应用更看重首次响应，有的应用重视连续输出，还有的应用只要求在规定时间内处理完整批数据。
如果一张图只给出总吞吐量，却没有说明交互条件，使用者就难以判断它是否适合自己的业务。较完整的比较，应同时明确响应要求和总完成量，而不是只选择数值最高的一项。
模型精度与实现方式会影响结果
量化方式、算子实现和推理框架，都会改变资源需求。两个测试如果使用不同格式，即使模型名称相似，也需要确认输出质量和计算条件是否可比。
这并不意味着优化后的实现没有价值。恰恰相反，软硬件协同往往是产品能力的一部分，但报告中应把实现方式写清，让读者知道结果如何获得，以及迁移到自己环境需要哪些条件。
批量和并发会改变响应体验
把更多请求放在一起处理，可能提高设备使用效率，但请求也可能等待更久。业务是否接受这种等待，决定了高吞吐量数字是否有实际意义。
因此，评估可以设置一个响应上限，再比较系统在上限内持续完成的工作量。不同服务等级对应不同结论，不宜用离线批处理的最佳成绩描述交互应用的日常体验。
单个计算内核与完整模型要分开
某个矩阵运算的表现，可以帮助理解计算能力，却不能覆盖数据读取、模型调度和请求管理。完整推理流程还包含很多环节，其中任何一个成为瓶颈，都会影响最终速度。
工程团队可以把内核测试作为定位工具，把端到端任务作为验收对象。这样既能知道硬件潜力，也能判断软件是否把潜力转化成了实际收益。
复现记录比单个结论更有价值
测试报告应保存硬件配置、软件版本、输入数据特征和运行参数。后续升级时，才能对照确认哪些变化带来了提升，哪些引入了退化。
AMD此次对推理数据的解释，为比较新旧平台提供了更细的观察材料。对用户而言，值得借鉴的是这种追问条件的方式：先确定自己的任务，再选择相同或接近的测试，而不是从最大的倍数开始倒推采购结论。