把采购指标从“峰值算力”转向“有效 token 产出”，本质上是从买设备的理论上限，转向买业务真正拿到的吞吐与成本。峰值 FLOPS、显存带宽仍然重要，但它们更像筛选硬件的参数，不再足以单独决定采购量和供应商排序。 首先，比较口径会从单卡峰值转向端到端的单位成本与服务能力。可按具体工作负载统计每秒生成的有效 token、每百万有效 token 的总成本，以及满足目标延迟时的持续吞吐。这里的“有效”需要先定义：是否只计最终交付的输出 token，提示词 token 是否单列；推测解码中被接受的 token 如何计量；重试、拒答、重复生成和质量不合格的 token 是否剔除。口径不统一，数字就无法横向比较，也容易被优化成好看的账面指标。 其次，采购更看重利用率和系统协同。实际产出受到模型大小、序列长度、批处理、并发、KV cache、显存容量与带宽、网络互联、编译器和调度策略共同影响。同一批加速卡，若负载经常等待显存或通信，峰值再高也可能产不出更多 token。因此评估应使用代表性的线上或回放负载，测量不同并发和上下文长度下的吞吐、首 token 延迟、逐 token 延迟及故障率；同时核算主机、网络、存储、机房电力、冷却和运维成本，而不是只看芯片报价。 这会改变采购组合：通用大模型推理可能优先考虑大显存、高带宽和互联；较短上下文、较简单模型的稳定批量任务，则可能更适合成本更低、能耗更优的配置。若工作负载可切分或有明确的延迟等级，也可以把昂贵资源留给低延迟、长上下文任务，把弹性批处理放到更便宜的资源上。因而不一定是统一追逐某一款“最高效”芯片，而是按任务类型配置集群，并为峰值需求和日常负载分别留出容量。 采购合同和验收也可能随之变化：除硬件规格外，约定特定模型、精度、上下文、并发和延迟条件下的持续有效吞吐、能耗及可用性，并以可复现的基准测试验收。还要注意，token 数并不等于业务价值：不同模型的一个 token 质量不同，量化或推测解码虽能提高吞吐，也可能影响准确率。因此更完整的指标应把质量门槛、延迟和成本一起纳入，例如在通过质量评测且满足 SLA 的前提下比较每单位成本的有效回答量。 简言之，算力采购将更像采购“满足质量与时延约束的服务能力”，而非单纯采购峰值芯片。有效 token 指标能让成本和利用率更透明，但只有定义清楚、覆盖端到端成本并配合质量评测，才不会变成新的单一数字游戏。