过去用 Ray Serve 在 GKE 上跑 LLM 推理，虽然 Python 原生 API 和灵活编排很香，但性能一直是硬伤。流量峰值下 Python runtime 容易饱和成为瓶颈，导致延迟飙升、吞吐上不去。现在 Google Cloud 和 Anyscale 联手，通过三个底层优化直接把问题干掉了——最高实现 5x 吞吐量提升和 8x 延迟降低，代价是零，开发者不用改一行代码。

核心就三招。第一，内置 HAProxy 做请求路由，把代理开销从 Python runtime 剥离出去，高并发不再卡死。第二，直接 token 流架构：推理返回的 token 不再经过 ingress router，直接从模型实例走代理回客户端，砍掉一次中转延迟。第三，为 vLLM 重新设计了 v2 Ray executor 后端，把 Ray 抽离数据平面，调度完全异步，性能打平原生 vLLM 的同时保留了 Ray 的弹性。实测用 Gemma 4 在 A4 VM（NVIDIA B200）上对比，新配置碾压旧版。

这套方案的启发是：推理性能优化的天花板不在于模型本身，而在于编排层的架构设计。Google 证明了用成熟的负载均衡器（HAProxy）和异步调度模式，可以纯靠系统层改造把性能拉升一个量级。对团队工程选型的启示很直接：别再死磕模型压缩了，先看看你的 serving 框架有没有犯这些低级架构错误——流式 token 走回源路由、Ray 参与数据平面，这些都是肉眼可见的坑。