如果你想把大模型塞进一台设备或现有软件，难处往往不只在模型本身。它还要带上一整套运行环境，像出门只住一晚，却得拖着整间厨房。一个社区项目试图减轻这件行李：用C++20从头重写vLLM的推理服务栈，编译成66 MiB的二进制文件，推理时不需要Python或PyTorch。
先把标题说准确：这不是vLLM官方“甩掉Python”，而是一个未获官方背书、名称也尚未确定的社区移植版。本文全部项目事实和测试数据，均来自作者本人发布的一篇Reddit帖子，尚无独立测试、官方确认、论文或代码仓库材料交叉印证。
它重写的不只是模型加载
vLLM是一套面向大模型在线服务的开源引擎。它不仅让模型开始计算，还要给请求排队、把多个请求合并处理、管理显存，并持续生成token——也就是模型输出文字时逐步选择的基本单位。
作者暂时把新项目称为vllm.cpp。它用C++20从头重写这套服务栈。C++20是C++语言的一代标准，程序通常能编译成原生二进制，更容易嵌入其他软件。作者称，自己原来的vLLM安装占用了9.1 GiB virtualenv——也就是一套隔离的Python运行环境；新实现的构建产物则是66 MiB。
不过，这两个数字不能直接当作严格的“缩小了多少倍”。66 MiB是单个二进制文件的大小，9.1 GiB是作者机器上整个virtualenv的占用，统计口径不同。真正值得关注的是部署形态改变了：推理进程不再依赖Python解释器和PyTorch运行时。
据作者介绍，vllm.cpp已经实现continuous batching（请求陆续到达时持续拼批处理）、block-paged KV（分块管理模型生成时保存的中间结果）、automatic prefix caching（自动复用相同开头的计算结果）、speculative decoding（先猜一段输出再集中验证），以及兼容OpenAI接口形式的服务器。换句话说，它想搬走的不是一台发动机，而是发动机连同排队、仓储和接待系统。
怎样确认“搬过去以后没变味”
重写服务栈最棘手的问题，是新程序看起来能跑，不等于行为真的与参照实现一致。作者采用逐token对齐：给vllm.cpp和一个固定版本的vLLM相同工作负载，再检查每一步产生的token ID是否完全相同。作者称，目前约25种模型架构通过了这种核对，并会在移植代码时同步移植上游测试模块。
这个验证门槛比只看最终句子更严格。两段文字即使表面相近，中间某一步选择不同，也会被发现。但逐token一致仍不能证明所有输入、模型、调度方式和边界情况都正确。它更像一项有用的逐项验货，而不是整座工厂已经获得认证。
性能至少没有明显掉队
作者还在DGX Spark的GB10芯片上，用Qwen3.6-27B NVFP4测试了吞吐量。每个请求输入1024个token、输出128个token，结果取3次交错运行的中位数。
并发为1时，vllm.cpp与vLLM的结果分别是86.05和82.32，前者约高4.5%。并发升至32时，两者分别是1095.01和1076.25，差距约1.7%。作者没有把六档结果包装成全面领先：其判断是并发1时vllm.cpp胜出，其余五档基本持平。测试的轮次波动约为0.5%，六档中有五档差距不超过1.7%。
这组结果的意义很克制：至少在这台机器、这个模型和这套配置下，从Python栈迁到C++实现，没有显示出明显的吞吐量代价。它还不足以说明其他模型、硬件或实际业务负载也会如此。
为什么值得继续看
这个项目瞄准的是一类具体需求：部署者在意安装体积、运行环境和系统集成，希望把推理直接嵌入其他软件。若核心服务能力确实能够在不依赖Python和PyTorch运行时的原生程序中复现，部署选择会多一种。
它也提供了一种值得观察的工程方法：以固定的vLLM版本作为“标准答案”，用逐token核对把重写过程约束住。作者同时坦言，项目大量使用了AI辅助开发。这让严格测试更加重要，因为代码生成得快，不代表兼容性和长期维护自然解决。
局限与未知
- 性能测试目前只覆盖DGX Spark、Thor和AGX Orin；帖子仅完整披露了单一模型与特定配置下的一组数字，且只有3次交错运行，缺少完整环境和独立复现。
- 功能完成度、约25种架构及逐token一致性都来自作者自述。帖子还在“Output is”处截断，可能遗漏输出质量、限制或后续说明。
- 从头重写意味着原有功能需要重新实现，并长期追赶参照版本。帖子没有披露兼容范围、维护成本、安全审计或项目成熟度，因此现在更适合把它看作有明确验证思路的社区工程，而非vLLM官方替代品。