北京
大模型推理的成本账，往往藏在芯片利用率的小数点后。谷歌最新放出的这份技术文档，记录了他们如何在4颗TPU v6e上，把260亿参数的Gemma 4 MoE模型压榨到468,736 token/秒的吞吐——这个数字意味着1024个用户同时提问时，首token延迟只有0.3秒。
这不是实验室理想环境下的跑分，而是一套经过反复崩溃、调参、再崩溃后沉淀的"生产级"配置。文档里毫不避讳地提到了两次关键的"Stabilization Fix"：最大序列长度从32K砍半到16K，并发请求数从更高值锁死在256。这两个保守数字背后，是JAX预编译对HBM显存容量的硬约束，以及约1.5GB显存的精确让渡。
真正让这套配置突破瓶颈的，是几个相互咬合的内存优化策略。KV缓存用fp8精度直接砍掉一半显存占用；前缀缓存（prefix caching）让多轮对话复用计算结果；而ngram投机采样则以当前上下文预测未来3个token，把首token延迟压进了300毫秒线。这些技术单独看都不算新，但组合在一起，恰好填满了v6e-4四芯片拓扑的通信带宽与算力配比。
环境变量的调参同样关键。VLLM_TPU_BUCKET_PADDING_GAP设为256，强制把请求长度对齐到256 token的整数倍——这个看似粗暴的截断， drastically减少了JAX需要编译的图数量。对于高负载部署场景，"编译抖动"的消除往往比单次推理优化更能决定稳定性。
这套配置现在被标记为Trillium v6e-4平台上Gemma 4 MoE的"verified standard"。值得注意的是，它服务的已经是完整版推理优化模型，而非早期轻量基线。从2048并发用户下仍维持45万token/秒的表现来看，MoE架构的稀疏激活特性，确实在特定硬件拓扑上找到了甜点区。
对于正在评估TPU集群方案的团队，这份文档的价值在于展示了"边界在哪里"——不是理论峰值，而是妥协后的可行解。当显存、编译开销、通信延迟形成不可能三角时，谷歌的选择是：保吞吐、保延迟、砍序列长度。这个优先级排序本身，就是生产环境最真实的约束条件。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
