周三下午，一个工程师盯着屏幕上的绿色指示灯松了口气——vLLM服务终于跑起来了。这次的主角是谷歌刚放出的Gemma 4 26B，跑在TPU v6e集群上，开了KV FP8量化、推测解码，用的是bfloat16精度。地址挂出来：34.95.135.58:8000，谁都能测。

先说最刺激的。1024个人同时往里塞1.6万字的上下文，系统没崩，prefill吞吐顶到了475,552 token每秒。这是之前v3版本根本跑不到的数字——那时候同档位测试直接超时。但代价也有：单用户低负载时反而慢了，1人/1024上下文，首token延迟0.489秒，比历史最优的0.116秒慢了3倍多。工程师猜是模型刚启动，KV缓存和JAX编译缓存都还没热起来。

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

TTFT（首token时间）的曲线很规矩。单用户1.6万上下文约1.1秒，1024用户同档位平均19.2秒，线性爬升，没出幺蛾子。但32768 token的测试全挂了，HTTP 400。原因是vLLM服务器的max_model_len硬设成32768，而测试要的是32768 prompt + 1生成token = 32769，超了1个就死给你看。

对比历史数据，128用户/1.6万上下文档位，这次prefill 37.9万token/s，比v3峰值44.6万低了15%，但算在TPU v6e-8的正常波动区间。真正的新纪录只有1024用户那一档——之前没人跑到过。

所以这张图怎么读？高并发稳定性是实打实的进步，低延迟冷启动是待填的坑，而那个32768的硬 ceiling，是配置层的限制，不是模型或硬件的锅。下次有人吹"支持32K上下文"，记得问清楚包不包括生成的那1个token。