周三下午，一位开发者在调试vLLM时发现了一个容易被忽略的细节——框架默认使用标准精度，而非内存优化的Brain Float格式。这个发现让他重新跑了一遍完整的基准测试，对比两种数据类型的实际表现。

测试对象是谷歌刚发布的Gemma 4（26B-A4B-it），跑在Cloud TPU v6e-4（Trillium架构）集群上。结果验证了这套硬件处理超长上下文的能力，也暴露了一个硬性限制。

打开网易新闻 查看精彩图片

先看核心数据。在256并发用户、64K上下文长度下，系统达到了峰值预填充吞吐：498,253 token/秒。即使把并发拉到1024人，总批量约6700万token，吞吐仍能维持在479,760 token/秒。Trillium架构的预填充效率确实突出。

但延迟曲线很说明问题。64K上下文的首次token时间（TTFT），256用户时是20秒，1024用户时飙到74秒。前者还能支撑深度推理或重RAG场景，后者只适合非交互式的批处理任务。

真正卡住脖子的是模型本身。vLLM引擎配置了128K上下文窗口，但Gemma 4这个变体明确拒绝超过65,536 token的请求，返回400错误。64K是当前物理上限，不是配置问题。

对比32K和64K两种上下文长度，单用户TTFT分别是1.3秒和2秒；64用户时是4秒和7.4秒。并发越高，长上下文的延迟惩罚越明显。

目前系统仍在线运行，开放64K窗口。完整测试数据已导出CSV和JSON格式。对于需要处理超长文档的开发者来说，256并发是个甜蜜点——吞吐接近峰值，延迟还在可用范围。