来自 @inferact 的 @BugenZhao 在 PyTorch 新加坡会议上介绍了这项工作。
LLM 推理这块，GPU 算力一直在高速迭代，但有意思的事来了——硬件越强，Python 前端反而越不够用了。
原因很简单：当 KV 缓存基本全命中的时候，GPU 跑完一次推理快得出奇，但 Python 那头处理请求、解析参数、做 Token 预处理，反而成了整条链路最慢的地方。CPU 先跑满了，GPU 在等。
vLLM 的做法是用 Rust 重写前端。上周这个 PR 正式合并进了主分支。
GPU 越来越快，Python 有点撑不住了
原来的架构里，Python API 服务器（基于 FastAPI）负责接收请求、解析 OpenAI 格式参数、处理 Token、管理流式输出，挺全能的。
问题是高并发一上来，CPU 就先扛不住了。vLLM 团队测了下，传统 Python 服务器在高吞吐场景下，CPU 开销把整体性能压死了，GPU 反而没能跑满。
Rust 前端针对的就是这块。底层推理引擎没变，ZMQ 通信边界也没变，换起来很简单，加一个环境变量就行：
VLLM_USE_RUST_FRONTEND=1性能差了多少？单进程打 32 个 Python 进程
官方给的基准测试数据，测的是预处理密集型场景：
| 前端类型 | 吞吐量 |
|---|---|
| 原 Python 前端 | ~162 req/s |
| Rust 前端 | ~837 req/s |
| 提升幅度 | 约 5.16 倍 |
更早的 RFC 里有个更直观的说法：一个 Rust 进程，吞吐量和 P50 首 Token 延迟，都能打平甚至超过 32 个并发 Python 进程。
这不只是快，还意味着 CPU 占用降下来了，长尾延迟也收敛了。
架构设计
分层 Crate 架构：各模块边界清晰，功能拆得很开，后续社区想改、想扩展都方便。
流式优先的处理管道：整个架构围绕流式传输设计，非流式请求的处理几乎不带额外开销。
只用稳定版 Rust：没用实验性特性，上生产不用担心工具链的坑。
普通用户需要做什么？
基本上什么都不用做。
Rust 编译好的二进制文件会打包进 Python Wheel，pip install 或者拉 Docker 镜像都会自带，不需要本地装 Rust 环境。
目前已支持 Completions、Chat Completions 和主要的 Generate API，beam_search 和 n 这类参数还在补，不算主流用法，大多数场景可以直接用。
最后
一直以来大家吐槽的 vLLM Python 前端性能问题，这次算是正面回应了。推理成本高、高并发下延迟抖动的团队，可以测一下，就一个环境变量的事。
Rust 改写基础设施这条路，Hugging Face TGI 也在走，看来不只是 vLLM 一家的判断。
