导读：Google在Cloud Next 2026发布TPU 8i与TPU 8t双路线：8t面向训练，8i专为推理和大规模Agent设计。官方称8i单Pod可连接1152颗TPU，片上SRAM提升，并强调更好的每美元性能。企业真正关心的是多步骤Agent在峰值并发下能否稳定，而不是芯片单项规格。
Agent负载为何不同
普通聊天通常一次请求结束，Agent会反复推理、调用工具、等待结果并继续，单个用户可能产生数十次模型调用。上下文长度、输出长度和缓存命中差异很大，瞬时负载也受工具完成时间影响。
容量估算按一次成功任务的请求数、Token和持续时间，而不是只按日活。区分交互任务、后台任务和批处理，前者优先低延迟，后者可排队。
需要观察哪些指标
记录首Token、输出速度、P95与P99延迟、队列、加速器利用率、KV缓存命中和失败重试。平均值会掩盖用户最明显的尾部等待。
将基础设施指标关联到模型、租户和任务ID，判断慢是推理、网络还是外部工具。GPU或TPU空闲不一定代表容量富余，可能在等数据。
缓存与调度策略
稳定系统提示和工具定义使用可复用前缀，长上下文按权限检索。短请求与超长请求分队列，防止大任务阻塞。后台Agent设置截止时间和优先级。
跨区域路由要考虑数据驻留和网络时延。容量不足时先降级低风险模型或暂停后台任务，高风险任务不静默换到未验证模型。
采购与压测
使用自己的模型与Agent轨迹压测，不只接受供应商峰值数据。模拟早高峰、工具同时返回、单节点故障和缓存冷启动。
计算芯片、网络、存储、运维和冗余的总成本，并与云API比较。利用率不稳定的小团队不必过早自建。
执行清单
- 按成功任务计算模型调用与Token。
- 同时监控尾延迟、队列和缓存。
- 交互、后台与批处理分队列。
- 用真实Agent轨迹做故障和冷启动压测。
- 以总拥有成本和业务成功率选型。
总结
TPU 8i体现推理基础设施正为Agent循环优化。容量规划要围绕任务链、尾延迟、缓存和故障恢复，芯片规格只有在完整系统中才能转化为用户体验。
