作者 | 褚杏娟 、Tina

vLLM 的故事始于加州大学伯克利分校 Sky Computing Lab 里一群充满热情的学生与研究员。2023 年，他们开源了核心的 PagedAttention 技术，vLLM 在短短一年多内 GitHub Star 数突破 4 万，并迅速增长至如今的 6.5 万，如今已成为全球科技公司首选的推理引擎。

在这一成功背后，Neural Magic 扮演了关键角色。这家由 MIT 研究员创立的企业，在巨头林立的 AI 优化领域中，以独特的“免费平台 + 开源工具”策略脱颖而出。通过深入贡献 vLLM，Neural Magic 不仅构建了成熟的企业级推理堆栈，还持续推动模型优化研究，维护着可直接与 vLLM 集成的预优化模型库。

正是其在 vLLM 开源社区的深厚积累与工程实力，吸引了红帽的注意。2024 年 11 月，红帽正式收购 Neural Magic，并将包括 vLLM 核心维护者 Michael Goin 在内的核心团队纳入旗下。Michael 在优化推理性能、最大化 CPU/GPU 效能方面拥有超过十年的经验。在 vLLM 社区，他专注于内核调优、模型压缩及系统优化等工作。

红帽成为重要参与者之后，AI 大模型领域发生了非常多变化。期间，vLLM 如何应对各种变化和挑战？红帽又如何帮助 vLLM 保持竞争优势？我们采访了红帽首席工程师、vLLM 核心贡献者 Michael Goin 和红帽亚太 CTO 办公室首席架构师兼大中华区 CTO 张家驹，他们详细介绍了 vLLM 的发展近况以及这期间的一些思考。

红帽首席工程师、vLLM 核心贡献者 Michael Goin

从 Llama 转向 DeepSeek

Michael 团队作为 vLLM 项目的“内核团队”，始终专注于集成与开发高性能推理内核，支撑着整个项目在快速迭代中保持领先。

随着各类模型竞相发布，vLLM 的开发节奏也持续加快。尤其是 DeepSeek R1 的发布，推动团队从聚焦 Llama 系列模型效率优化，转向全力投入 DeepSeek 模型相关特性的优化中。

为迅速响应 DeepSeek 的新特性，整个 0.7.2 版本的开发周期都很紧凑，此外还高效支持了 Qwen 2.5 VL 并引入了 Transformers backend，使用户能够直接运行任意 Hugging Face 模型。随后的 0.7.3 版本则成为一次规模更大的更新，短时间内有众多贡献者参与，开发过程高效且紧张。

该版不仅为 DeepSeek 启用了多 Token 预测（MTP）、MLA 注意力等优化，还扩展了对 AMD 硬件的支持与调优。此外，专家并行在 DeepSeek 之前并不常见，团队也因此推动了 vLLM 从支持张量并行、流水线并行到支持专家并行的演进。Michael 还将 DeepSeek 开源的一系列高性能工具，如 DeepGEMM、DeepEP、专家并行负载均衡等，系统化地融入 vLLM 生态。

面向推理场景，团队不断扩充高性能内核库，涵盖定制版 Triton、CUTLASS、CUDA 内核、HIP 内核等，还包括各种量化支持、众多定制内核实现等。

DeepSeek 的复杂性反而为团队带来了优化与泛化的契机。Michael 指出，团队将原本主要用于 DeepSeek 私有环境的技术，转化为可持续、通用化的实现，使其能服务更多基于 MoE 架构的模型。他强调，vLLM 的某些演进正是受 DeepSeek 所推动，并非因为 DeepSeek 模型本身运行更快，而是其开源的一系列先进技术为整个生态带来了提升。

这个过程中，DeepSeek 揭示了大模型高效部署的可行路径，而 vLLM 团队则将这些经验复现并通用化，构建出更强大的推理框架。“我们与 DeepSeek 合作，将优秀算法与底层框架的实现相结合，构建出更高效的推理框架，真正实现了强强联合。”Michael 总结道。

除了主导 DeepSeek V3 的整合，Michael 还带领团队完成了 GPT-OSS、Qwen、Kimi 等多个模型的适配与优化。

一个框架如何支持各家硬件

vLLM 团队的另一个核心使命，是构建开放、高效的硬件推理生态。他们不仅广泛支持各类主流芯片，更深度参与到新硬件的架构设计与性能优化中，推动整个社区向多硬件兼容的方向演进。

过去几个月，Michael 一直在与 NVIDIA 共同推进 Blackwell 芯片的支持工作，优化 B200 相关性能。团队成员还与 AMD 团队保持紧密协作，确保 AMD 在 vLLM 中的性能表现。Michael 还与 Google TPU 团队紧密合作一年多，完成了多次版本发布。最近，Michael 还作为最高决策者，参与设计了整体沐曦的支持架构。

以与沐曦的合作为例，可以看到红帽团队的参与程度之深：在项目非常早期阶段，Michael 便与沐曦团队共同讨论支持框架的设计方向。他主导高层架构，而团队中的社区贡献者则深入细节，甚至专程赴上海进行面对面技术对接。双方还专门在 Slack 上创建了频道，组建起一个跨公司的“线上联合工作组”，确保支持工作持续高效推进。

整个流程体现了团队对生态建设的严谨投入：他们先为硬件伙伴指明实现方向；待沐曦完成相应工作后，再共同进行代码审查与迭代优化。例如，协助沐曦将最初的支持方案，通过插件机制重构得更为优雅和可维护。在 GitHub 上，大量的修订建议（RC）经过团队的仔细审核。现在，Michael 手中持有一份很长的待审核列表。

这种深度协作，最终让双方共赢。正如张家驹所言：“对沐曦而言，他们找到了让社区支持其硬件的优雅方式，这意味着未来的维护工作量将比以往更少。对社区而言，我们也推动了一个支持不同硬件的生态系统的发展。”

PyTorch 之重

在异构计算时代，vLLM 之所以能广泛支持从 NVIDIA、AMD 到 Google TPU 乃至国内众多芯片，其核心战略在于：深度拥抱 PyTorch，将其作为连接上层框架与底层硬件的“最大公约数”。

从技术栈来看，硬件之上是 PyTorch，PyTorch 之上才是 vLLM。这意味着，只要硬件厂商提供了对 PyTorch 的良好支持，那么适配 vLLM 的工作就已完成大半。vLLM 中的模型定义几乎完全基于 PyTorch 编写，仅对注意力机制等少数关键模块保留了可替换的定制化空间。

PyTorch 自身已提供 SDPA 注意力实现，而 vLLM 在此基础上还支持十余种其他硬件 backend 的注意力实现，比如 NVIDIA 的 FlashAttention 与 FlashInfer、AMD 的 ROCm Attention 与 Triton Attention、Google TPU 的 Pathways Attention，以及昇腾 NPU 的 Attention 等。

正是通过这种统一的 PyTorch 抽象层，vLLM 得以集成各家硬件的加速实现。只要硬件供应商提供适用于 PyTorch 的集成或分发版本，绝大部分（约 90%）工作就已自然完成。而剩余约 10% 主要涉及对 PyTorch 中效率较低的部分进行定制优化，例如融合 MoE、矩阵乘法量化以及特定的注意力实现。

Michael 解释称，vLLM 之所以深度依赖 PyTorch，是因为几乎所有硬件供应商都有充分理由基于 PyTorch 进行开发：它不仅用于训练，也用于推理，并且与绝大多数开源软件深度集成。

他进一步表示，PyTorch 的主要竞争者是 Google 的 JAX，但 JAX 的开源程度相对较低，比如其 XLA 编译器 backend 并未开放，实际生态普及度远不及 PyTorch。正因为 PyTorch 被视为从机器学习到硬件层的最佳抽象框架，vLLM 才紧密依托其基础架构，并围绕高效大语言模型推理进行功能扩展，这也部分解释了 vLLM 选择加入 PyTorch 基金会的原因。

张家驹也指出，PyTorch 的应用如此广泛，以至于任何硬件厂商均主动适配 PyTorch 生态。像国内各类芯片厂商也正是通过 PyTorch 这一路径进行集成与适配的。

简言之，vLLM 不直接面对纷繁复杂的硬件技术栈，而是依托 PyTorch 这一成熟、开放的中间层，与硬件厂商及社区协同共建。这既降低了多硬件支持的复杂度，也让整个生态能在统一的基础上持续演进与优化。

NVIDIA 所谓护城河还很坚固？

那我们自然需要面对一个更深层的问题：如果说 CUDA 是 GPU 加速的“引擎”，PyTorch 就是调用它的“框架”，那么新兴硬件厂商究竟该如何追赶，才能达到与 NVIDIA CUDA 同等的高效与易用水平？

在 Michael 看来，这是一个充满挑战的命题。核心难点在于，即便最终能在 PyTorch 层实现功能兼容，其效率往往难以匹敌 NVIDIA 经过十数年深度打磨的 CUDA 生态。“CUDA 对其他硬件而言并非一种可直接迁移的语言，”他指出，这本质上是硬件抽象与软件生态的长期累积差距。

不过，路径依然存在。

Michael 指出，在硬件抽象层，采用类似 Triton 这样的领域特定语言是一种解决方案：只需用 Triton 编写一次算法，便可在多种硬件平台上运行。但该模式也存在局限：即使软件最终能够支持所有硬件 backend，内核开发人员仍需投入大量手动调试与内核开发工作，针对具体硬件进行深度调优才能实现高效率。

而张家驹分析称，实现与 CUDA 同等能力，有多种技术路径。例如沐曦选择完全兼容 CUDA API 的路线，此外也可借助领域特定语言通过不同的 backend 编译实现跨硬件运行，如 Triton 就是一种编写 GPU 算子的新兴语言。但这本质上仍是一种需要大量人工优化与适配的模式。

但转折点也正在出现。Michael 敏锐地指出，新型注意力算法正在不断涌现，对于这些崭新技术，其他硬件供应商有可能实现超越。

“它们非常新颖，供应商或许能提供比 CUDA 更快速、更原生的支持。例如 Kimi 提出的 KDA 算法，便率先通过 Triton 获得支持。在新算法领域，其他厂商有时反而能更敏捷地响应。”Michael 说道。

随着模型供应商不断探索比标准 Transformer 更高效的新架构，硬件厂商也获得了更大的灵活性与快速响应空间。就像 Michael 的那个比喻：这就像体育竞赛，一切又回到了同一条起跑线。

多模态支持

在软件与硬件生态持续融合的背景下，vLLM 并未止步于优化单一模态的推理。当多模态 AI 浪潮席卷而来时，团队将 vLLM 从一个纯文本推理引擎，全面升级为一个支持全模态生成与理解的统一服务平台。可以说，多模态模型架构如今改变了 vLLM 的架构。

“无论是文生图、文档理解，还是其他生成任务，其底层均依赖于大模型推理，因此都可以通过 vLLM 进行处理。”Michael 指出。

为此，团队对 vLLM v1 版本进行了彻底重构，其中一项关键创新是多模态前缀缓存（multimodal prefix caching）。传统上，vLLM 通过 Page Attention 复用文本 token 的键值缓存；如今，这一机制已扩展至图像、音频等任意模态输入。现在团队维护的是多模态缓存，重复请求的处理效率因此大幅提升。

为进一步支撑大规模推理部署，团队实现了编码器解耦技术，将视觉、音频编码器与语言模型 backbone 解耦。这既符合多模态模型的结构特点，也为超大规模推理场景提供了极致的弹性与资源利用率。

今年 12 月，这项演进迎来了一个里程碑：vLLM-Omni 作为其首个“全模态”推理框架正式发布，它将文本、图像、音频、视频的统一生成从概念变为可落地的生产级代码。Omni 并非在原有框架上简单封装，而是引入了一套完全解耦的流水线架构，让不同阶段按需分配资源，并通过统一调度衔接。一个 omni-modality 推理请求大致会经过模态编码器、LLM 核心与模态生成器三类组件，通过管线调度在不同 GPU/ 节点间协同工作。

“vLLM 的核心角色，是一个高效的推理引擎与服务器，”Michael 总结道，“这类似于 Web 服务器托管各种网页应用（如 HTML 或 Java 页面）的逻辑。vLLM 需要承载各种各样的模型与应用，并致力于在各种使用场景下，无论是应对一千名还是十万名用户的访问，都能提供优异的性能。”

从统一硬件抽象层到定义全模态推理架构，vLLM 正稳步推进其愿景：成为 AI 时代最通用、最高效的推理基础架构。

如何保持竞争优势

随着 vLLM 在过去两年半中逐渐发展成熟，一个趋势越来越明显：无论是去年还是今年，许多公司都开始将更多修改回馈至上游。

“这是因为 vLLM 本身已经有了大量的改进，这些改进对他们私下开发的版本来说也是有增益性的，所以他们希望能更频繁地与上游同步。他们开始愿意把自己定制的改动 upstream 到项目中，并且更倾向于直接使用 upstream vLLM，而不是开发一个非常不同的私有版本。我们已经在多个案例中看到了这种情况的发生。”Michael 解释道。

这一良性循环的核心驱动力，在于“速度”。

“我们的上游版本有一个独特优势：就是和众多领先的模型实验室和公司合作，快速收集他们的反馈，有 bug 就去修，修完之后也会放回社区，让更多人看到。”张家驹补充道。vLLM 的合作名单涵盖了从 DeepSeek、Qwen、字节、腾讯，到 LinkedIn、亚马逊、Mistral、Azure 和 Snowflake 等。

“了解他们可能如何使用 vLLM，以及未来模型架构可能对 vLLM 提出哪些改进需求，通过开发这些功能，来确保 vLLM 始终保持竞争力，紧跟行业发展。”张家驹说道。

用户越多，反馈就越快，迭代也越迅猛。当社区版本的迭代速度远超私有分支时，即使后者曾开发某些独有功能，也会很快发现社区版本的功能更多，可能有些功能与其类似。为了保留自己的少量修改而放弃社区的更多功能，显然得不偿失。张家驹指出。

据张家驹观察，去年很多人可能还用自己的版本做一些小开发，但今年在发现社区版本比他们“跑”得快很多后，大家都更倾向于使用社区版本。这种“速度优势”正推动 vLLM 加速成为大模型推理领域的事实标准。

one more thing：回应开发者问题

作为一个每月下载量超 20 万次的热门推理框架，vLLM 的广泛采用也使其必须直面生产环境中的真实挑战。近期，不少开发者集中反馈了启动速度偏慢的问题。

对此，Michael 回应道，团队大约从几个月前已经开始明确着手解决。团队不仅在 GitHub 上建立了专项跟踪与“启动体验优化”项目，还在 Slack 开设了专门频道，以持续收集并响应用户的实际痛点。

Michael 解释，导致启动时间较长的因素有几个，其一是 CUDA graph capture time：为了获得最佳性能，开发者希望能捕获尽可能多的 CUDA graph，但每多捕获一个 graph，启动时间也会增加，因此这需要做好权衡。另一个因素是 torch.compile，它本身也会需要一定的时间。开发团队已推动 torch.compile 团队重视启动时间问题，也取得了一些显著改进。

另外，vLLM 团队还打造了一些工具和指南，指导用户如何处理冷启动与热启动的差异，即模型是否首次运行与部署。团队设置了缓存目录，用于存储 torch.compile 的输出结果、Triton 的输出结果以及其他编译或初始化的内容。若开发者正在部署单个模型，并计划扩展至多个副本，团队建议在部署中复制该缓存目录以实现热启动，这比冷启动快得多。

结束语

在 vLLM 这一由社区驱动的项目中，红帽以其深厚的开源基因扮演着重要的角色。正如张家驹所说：“红帽全球约有两万名员工，其中可能有一两千名工程师完全在社区中做贡献。他们贡献的工作并不针对红帽的商业方面，做的事情非常中立。”

Michael 进一步指出，vLLM 的治理结构本身高度分散，共有 15 到 20 个不同组织的成员担任提交者或维护者。红帽正是在这样的多元生态中，以其工程实力与对开源原则的坚持发挥影响力。

红帽如此投入 vLLM，源于一个战略判断：推理是 AI 应用成本的核心环节。例如，若 DeepSeek 以其公开的成本效率托管模型，企业也必然期望在本地部署中达到同等水平。实现这种性能，需要 vLLM 集成最前沿的模型优化，而红帽正致力于此。

最具代表性的贡献是红帽主导推动了 vLLM v1 版本的架构重构。这次升级不仅为未来系统设计奠定了基础，更实质性地推动了社区标准化进程。例如，与 PyTorch torch.compile 团队长达一年半的合作，优化了上游框架以更好支持 vLLM 的高阶场景。“这些工作让支持新硬件、新模型变得更容易，”张家驹解释道，“红帽力图把这个标准化的层做得越来越厚、越来越稳定。”

面向更加多变的未来，红帽和 vLLM 如何守住“推理服务标准”的地位，我们拭目以待。