vllm-project/vllm

解决什么问题

Demo 跑通之后，瓶颈往往不在模型，而在服务层：一张 GPU 能扛多少并发、长 prompt 怎么切、KV cache 涨起来时延迟怎么稳住。直接用原生 PyTorch 循环写生成，硬件大部分时间是闲着的。vLLM 就是针对这个问题做的推理与 serving 引擎，核心是 PagedAttention 管理 KV 内存，加上对进来的请求做 continuous batching。

有什么不同

和 Hugging Face transformers 的 generate 相比，后者简单易用但不是一个 serving 系统；vLLM 面向并发设计：分页 KV cache、chunked prefill、prefix caching、CUDA/HIP graph，以及一整套量化 kernel。和闭源 serving 方案相比，它开放且与模型解耦——README 称支持 200+ Hugging Face 架构，覆盖 dense、MoE、Mamba 混合、多模态、embedding 和 reward 模型，并提供 OpenAI 兼容 API 以及 Anthropic Messages / gRPC 接口。代价是硬件面铺得很广（NVIDIA、AMD、Intel GPU、CPU，还有 TPU、Gaudi、Ascend 等插件），kernel 面也很宽；这正是它的价值，但也意味着实际表现高度依赖你的 GPU 型号和模型组合。

适合谁

自己托管 LLM、在意单位成本吞吐的团队：搭推理服务的平台/MLOps 工程师、做模型评测的研究者，以及跑 MoE 或多模态模型、在其他引擎上比较别扭的人。只调 API 不碰权重的人，或者想要一个有厂商兜底的成品设备而不是自己运维项目的团队，不适合。

上手成本

需要 Python 和匹配版本的 PyTorch/CUDA（或 ROCm）工具链，显存要按模型加 KV cache 预留；安装命令是 uv pip install vllm。依赖树不小，需要和驱动版本对齐；启动速度可以靠预编译 kernel（vllm download-kernels）改善。Apache-2.0 许可宽松，但项目迭代很快：小版本之间 API 和参数常变，HotRepo 窗口内的讨论热度更多反映发布节奏，而不是沉寂。

点评

vLLM 不是这个赛道的新玩家，而是定义了这条赛道的那批项目之一。2023-02 创建至今积累了约 95k star、24k fork，2026-08 关于 v0.28.0 的 Hacker News 讨论说明它仍在持续发布有分量的版本。单周 +1,363 star（周榜 #15）是健康的动能，但追踪期内它没上过日榜——这里的关注是工程驱动的稳定增长，不是病毒式冲高。这是一个成熟且绑定较深的选择：认真做自建推理就值得投入，但不适合当周末玩具。