2026 年 4 月，知乎专栏里有篇文章叫《从0开始的原生Rust推理引擎》。标题看起来像要另起炉灶，开头的判断却很克制：vLLM、sglang 这类基于 Python 的推理框架已经占据大部分推理服务市场，也在逐步稳定。
这反而说明，Rust 要进入推理链路，最好的切口未必是推翻现有框架。
PegaInfer 的思路更像拆机器：模型前向计算、CUDA kernel、attention 算子这些成熟部分先不碰，重点处理 Python 链路里容易放大延迟的环节，比如 tokenizer、调度器和批处理逻辑。它用 Rust 从头实现这些组件，再去对接现有 CUDA kernel。
这个判断有现实背景。截至 2026 年 7 月，vLLM 的 GitHub star 已超过 45,000，sglang 也突破 12,000。两个框架已经覆盖了大量模型服务场景。真正让很多请求慢下来的，往往不是矩阵乘法本身，而是 Python 对象序列化、GIL 竞争、内存拷贝，以及请求在进入 GPU 前后的各种胶水代码。
PegaInfer 公开 benchmark 里，在 Llama 3.1 8B 模型、同等硬件条件下，端到端延迟比 vLLM 的 Python 调度路径降低 18% 到 23%。batch size 小于 8 时差距更明显，而这正是许多实时应用常见的负载形态。
Rust 更像是补上 Python 的短板
腾讯云开发者社区 2025 年初的一篇文章提到，Hugging Face 职位列表中，Rust 相关 AI Infra 岗位同比增长 340%。这个数字容易被解读成“Rust 要替代 Python”，但岗位需求本身更值得看：它们大多指向高性能服务层、数据管道、系统组件，而不是“用 Rust 重写 Transformer”。
Hugging Face 走得更早。它的 tokenizers 库采用 Rust 核心加 Python 绑定，把原本容易被忽略的分词环节单独做快。收益很直接：大文件分词速度提升 3 到 5 倍，内存占用下降 60%。到了 2026 年，text-generation-inference（TGI）里，请求路由、批处理调度、流式输出等底层逻辑也大量交给 Rust，外层仍然保留 Python API。
LinkedIn 上 AI 工程师 Geanderson Lenz 在 2026 年 3 月的文章里说得更直白：大玩家已经意识到，用 Rust 重写 Python 库的后端，是同时保留两边优势的办法。Python 继续负责原型、接口和业务表达，Rust 接管计算密集、数据敏感、延迟敏感的底层部分。
这比“语言替换”更接近真实工程。
先拆这三个地方
从 PegaInfer、Hugging Face TGI 以及一些开源实践看，Rust 在推理链路里的入口可以更小，也更有效。
第一是预处理和 tokenizer。 tokenizer 看起来不像大头，但高并发下，Python 字符串处理和内存分配会很快变成瓶颈。如果推理服务每天处理千万级请求，把 tokenizer 换成 Rust 实现，CPU 侧延迟可以砍掉 40% 以上。Hugging Face 的 tokenizers Rust 版已经验证过这条路，很多团队不需要自己再造一个。
第二是批处理组装和调度。 vLLM 的 continuous batching 很强，但调度层仍会涉及大量列表操作、对象生命周期管理和请求状态更新。当并发请求数超过 100，GIL 带来的影响会更明显。Rust 在这里的好处不只是快，而是延迟更可预测：没有 GC 暂停，没有 GIL 争抢，p99 和 p50 不容易被拉得太开。
第三是后处理和流式输出。 推理服务返回结果前，经常要做 logits 处理、停止词检测、格式转换、SSE 输出。很多实现会在 Python 里用 NumPy 补一段逻辑，但 CPU-GPU 数据搬运的成本容易被埋掉。Rust 可以把一部分后处理放在更靠近底层的位置，少绕一次 Python，也少一次回传。
这些环节有个共同点：它们不属于模型计算核心，却能吃掉端到端延迟的 30% 到 50%。
一套更现实的分层
假设 2026 年中要做一套企业内部推理服务：单卡 H100 跑 7B 到 70B 模型，P99 首 token 延迟要压在 200ms 以内，SSE 流式输出不能卡，工具调用和 JSON Schema 校验也要严格。
这时没必要先写一个 Rust 版 vLLM。更稳的拆法大概是这样：
接入层用 Rust 写 HTTP/gRPC 网关，处理鉴权、限流、连接复用和 SSE 流式输出。一个 8 核机器可以扛住上万并发长连接，单机内存占用比 Python 方案低一个数量级。
调度层用 Rust 写请求队列和 batching 调度器，按模型、长度、优先级把请求打包，再喂给后端。
推理后端继续交给 vLLM 或 sglang。模型加载、量化、PagedAttention、KV cache 这些复杂逻辑先不动。
后处理层用 Rust 做解码、JSON Schema 校验和工具调用解析，配合 tokenizers 这类 Rust crate，减少在 Python 和底层之间来回穿梭。
业务编排仍然留给 Python。prompt 工程、Agent 逻辑、工具注册、审计日志，这些变化快、依赖多的部分，Python 仍然更顺手。
这套结构的关键，是让 Rust 拿走“延迟敏感 + CPU bound”的部分，让 Python 留在“业务变化快 + 库足够多”的位置。对多数团队来说，这比重写一个完整推理引擎可控得多。
为什么别急着重写 vLLM
2026 年 1 月，Francesco Ciulla 在 YouTube 上和 Joshua Mo 讨论 Rust 框架 Rig 与 Python 框架 LangChain。测试里，Rig 在一些链式调用场景下更快，但 LangChain 的易用性和周边工具仍然难以替代。Joshua Mo 的说法很直接：Rust 很适合 AI Agent，前提是你真的需要极致性能和可预测延迟；大多数人并不需要。
放到推理引擎上，道理类似。
vLLM 和 sglang 已经支持大量模型、多种量化格式、分布式推理、KV cache 优化。这里的难点不只是语言。Attention、MoE 路由、量化反量化、KV cache 管理，很多都落在 CUDA、Triton、CUTLASS 这些层面。Rust 当然可以写算子，candle、burn、tch-rs 都在探索，但如果能直接复用 vLLM 和 sglang 已经打磨过的 kernel，工程账通常更划算。
还有一笔账常被低估：适配成本。Hugging Face 上的模型格式、GPTQ、AWQ、GGUF、FP8 等量化格式，多模态输入处理，背后是一整套 Python 工具链。Rust 端要追平这套能力，靠一两个工程师很难。
所以 PegaInfer 更值得看的地方，不是“Rust 能不能重写推理引擎”，而是它把边界划得比较清楚：Rust 写调度和批处理，复用现有 CUDA kernel；Rust 做 tokenizer，保留 Python 的模型加载和配置管理。这种拆解式改造风险低，收益也更容易量化。
真落地时，坑也不少
异步运行时上，tokio 仍是事实标准。但 Rust 侧和 vLLM 这类 Python 后端通信时，要认真处理背压。否则 Rust 网关收请求很快，后端吃不下，最后堆到 Python 侧 OOM。
FFI 边界也要收紧。如果一定要在 Rust 里调 Python，PyO3 或 rustpython 都能用，但最好把边界封在明确模块里。最糟糕的情况，是 Rust 和 Python 在整个调用链里互相穿插，排查问题时每一层都像黑箱。
可观测性同样要提前设计。Rust 侧的 trace、metrics、log，要和 Python 后端对齐时间戳和 request_id。OpenTelemetry 在两端 SDK 都已经成熟，但 schema 要先约定好，否则故障会断在语言边界处。
编译时间也别轻视。大型项目一旦引入 tch-rs、candle、burn 这类带 C/CUDA 依赖的 crate，CI 构建会明显变重。增量编译和缓存不提前做，迭代速度很容易被拖慢。
到 2026 年 7 月，Rust 在 AI 基建里的位置已经比两年前清楚很多。它最适合的起点，不是替掉 Python，而是接管 Python 链路里那些刚好不适合 Python 的部分：预处理、批处理、后处理、网关和调度。
写 Rust 推理引擎，可以从这些地方开始。别从一场语言战争开始。
