我用Rust重写推理引擎，不仅仅是为了性能

现如今，vLLM、sglang 等基于 Python 的推理框架已经占据了大部分推理服务的市场，逐步走向稳定和成熟。

那么，为什么还要用 Rust 从头开始写一个推理引擎呢？为什么不直接用现成的 vLLM 或 sglang？

原因主要来自两个方面。

首先，是关于语言本身的限制。从去年到现在，我也有幸为上述两个框架贡献过一些代码，参与过一些模块的设计，并积累了一些运维经验。在这个过程中，我深切地感受到 Python 极大地限制了我去追求更高性能和更复杂逻辑的实现。“我们要控制对 CPU 的使用”、“Python 处理不了这么多”，这些话反复被提及，其根源大都绕不开 GIL。因 GIL 带来的各种长尾问题也让我不禁思考：大家都说 GPU 是千亿级别的生意，这难道就是千亿级基础设施应有的样子吗？另一方面，Python 的灵活性有时也是一把双刃剑。未处理的错误、状态不完全匹配、内存泄漏等本应由编译器解决的逻辑问题，却耗费了我大量宝贵的时间去调试。

其次，是出于我个人对系统理解的渴望。由于我的工作主要围绕 KV缓存 和路由展开，过去一年也更专注于引擎的 KV cache 相关模块。有时，我发现自己听不懂做框架或算子优化的同事讨论的内容，这为我自己的 KV cache 系统演化带来了一些阻碍。我意识到，理解整个推理框架的优化思路和行为逻辑至关重要，未来也需要进行协同设计，而不是只做一个独立的单机推理引擎。怎么才能真正理解一件事物呢？我想起了费曼的那句话：“What I cannot create, I do not understand.”

基于以上两个原因，我早在去年还在北京时就尝试过用 C++ (stdexec) 写一个推理引擎，但不知为何，总觉得有些别扭。那时 LLM 的能力和我驾驭 LLM 的能力都比较有限，这个尝试便不了了之。后来，在我用 vibe 的方式完成了第一个稍微成熟的 开源 Rust LLM KV cache 项目后，我意识到，Rust 仿佛成了我的编程母语。就像此刻我用中文写博客一样自然，写 Rust 代码时我感到流畅许多。在深入思考了 “vibe coding” 与我自身的关系后，我突然找到了正确的协作方式（关于我如何与 LLM 协作工作和学习，之后会单独写一篇）。我觉得是时候把这个想法重新捡起来了。

于是，便有了 pegainfer。它依旧 100% 的代码由 Opus 4.6 high 生成，我没有手写，除了算子我没有全部仔细检查外，框架层面的代码我都扫了一遍。

Pegainfer 的现状是：用 Rust 写框架，用 CUDA 写算子，同一时刻只支持处理一个请求。它没有前缀缓存，没有 Sampler，也没有调度器，还不支持 CUDA Graph，算子也没有进行细致的优化。在我的 RTX 5070 Ti 上，运行 Qwen3 4B 模型大概能稳定在 70 token/s 的吞吐量，精度与 Hugging Face 对齐（这个对齐过程是 Opus 自己完成的，还蛮有意思）。

所以，现阶段 pegainfer 的状况，高情商的说法是“百废待兴”，低情商的说法是“要啥啥没有”。这种刻意的留白是我有意为之。原本我计划把所有“没有”的功能都实现完再写博客介绍，显得正式一些。但我发现，我和 LLM 一起学习、探索、支持新功能的过程反而更有价值，也更有意思。全部写完了再介绍，无非又是一个推理引擎，讲的还是那些老掉牙的优化技术。

那么，用 Rust 写推理引擎的体验到底怎么样？说实话，比预期中好很多，不知道是不是因为 Opus 4.6 的进化。代码编写、测试、压测的体验都非常棒。cargo run -r 即可编译启动，cargo test -r 即可快速运行测试，也包括一些端到端（e2e）测试。同时，Rust 的生态体验非常好，以下是 pegainfer 依赖的一些重要的库：

• cudarc — Rust 的 CUDA 绑定，提供对 CUDA runtime 和 cuBLAS 的安全封装，是整个 GPU 计算的基础。
• axum + tokio — 异步 HTTP 框架，提供 OpenAI 兼容的 API 服务，几行代码就能启动一个高性能服务器。
• safetensors — HuggingFace 的模型权重格式，零拷贝加载，比 pickle 安全得多。
• tokenizers — HuggingFace 的分词器，Rust 原生实现，速度极快。
• fastrace — 分布式追踪库，输出 Chrome Trace JSON 格式，可以直接在 Perfetto UI 里查看每个算子的耗时（这个比较有意思，是 pegainfer 的独家功能，之后会介绍）。
• logforth — 结构化日志库，支持过滤、着色、多输出。
• half — BF16/FP16 类型支持，配合 cudarc 完成半精度存储。
• anyhow — 错误处理，非常省心。

最重要的是，我不用再担心 GIL，也不用担心生命周期和错误未被处理的问题。日志、指标、追踪，几乎都是开箱即用。这个从零开始搭建的过程，让我对 人工智能 推理系统的内部运作有了更深的理解，也验证了 Rust 语言在高性能基础设施领域的独特优势。如果你也对类似的技术探索感兴趣，欢迎到云栈社区 的 Rust 和架构板块交流讨论。