如何跳出单一基准评估 Google TPU 推理经济性

Ironwood 的公开测试结果让外部团队有理由认真评估 Google TPU，但它并没有给出通用答案。InferenceX 在特定模型和运行点上报告了有竞争力的每美元性能，同时也显示某些高并发场景下首 token 延迟仍是取舍。正确的动作不是一次性迁移架构，而是设计可回退的对比试验。

先定义服务，再选择加速器

把真实请求写成测试合同：输入和输出长度、并发、首 token 与逐 token 延迟目标、精度、区域和错误预算。8k 输入加 1k 输出可以是有价值的样本，却不能代表需要反复读取上下文的代码代理、无法等待批处理的语音服务，或更看重吞吐的离线任务。模型稳定、流量大且形状可预测的工作负载适合先试 TPU；频繁换模型、需要特殊算子或延迟极严的服务则需要更多证据。

把成本曲线当作待验证假设

报告中的每美元优势不应被简化为“谁更便宜”。逐并发记录吞吐、首 token 时间、逐 token 延迟和尾延迟，并保持模型、精度、质量目标及路由策略一致。更大的批量可能改善 token 成本，却把用户体验推过可接受的边界。总拥有成本同样依赖利用率、电力、网络、承诺用量、容量和地区价格；Google 的内部经济性不等于客户能够获得的价格。把乐观与保守假设都保存下来。

把软件成熟度列为发布门槛

成熟的 CUDA 工具链、内核、诊断工具和运维经验有实际价值。TorchTPU 和 SGLang 让 PyTorch 团队更容易使用 TPU，但现有材料也指出推测解码、解耦式服务、缓存卸载和多轮代理仍可能存在差距。试验必须回答：目标模型能否无需专门内核项目而稳定运行？团队能否定位慢请求、回滚版本、恢复故障并复现性能回退？若节省的 token 成本被持续的专家介入抵消，它就不是可重复的成本优势。

让试点回答运营问题

公平比较需要匹配服务策略。若 GPU 使用解耦式预填充和生成，而 TPU 使用聚合式服务，结果说明的是部署成熟度，并不是中性芯片排名。记录缓存策略、失败重试、扩缩容与版本回退，并观察长尾延迟。对于每个候选模型，检查是否有受支持的精度和区域容量，也要让应用团队确认质量没有因量化或排队策略改变。还应保留同一批请求的原始指标、版本号和失败样本；否则下一次模型或编译器更新后，团队无法判断差异来自硬件、软件还是流量本身。

用共同指标做最终决策

试点不能只看平台团队的图表，也要让产品、财务和可靠性负责人共同确认指标。设定最低质量分数、最大可接受等待时间、每月预算以及故障时的降级行为。在小流量阶段观察一周以上，覆盖高峰和低峰、缓存冷热变化及模型版本切换。若某项条件未满足，应保留原平台而不是通过修改目标来宣布试验成功。把试验结论连同测量脚本和成本假设归档，才能在下一次容量谈判或架构评审中复用。

同时衡量容量和可移植性

检查区域、容量、可观测性、安全控制、模型更新速度和退出路径。TPU 专属优化可能降低成本，也可能增加对单一云和少数专家的依赖；CUDA 也有锁定效应，重点是选择适合业务的依赖。以一个模型、一个工作负载类别、固定流量比例和明确回滚来试点，衡量完成请求成本、质量、SLO 达成率、运维工时和恢复表现。TPU 8i 的路线图应作为未来情景，不应用来提高当前 Ironwood 试验的分数。

定期重测而非一次定论

模型、编译器、服务软件和地区容量都会变化。保留原始业务负载与成本假设，并在版本或容量变化后重跑同一套测试，才能避免把一次预览结果误当成永久结论。 这份记录也应覆盖高峰与低峰。 这样，采购讨论可以基于可复现的服务结果，而不是脱离业务条件的宣传数字。