vLLM的演进：红帽如何驱动AI推理引擎的创新与多模态扩展

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的应用边界。如今，vLLM作为一个推理引擎与服务器，其支持的范围十分广泛：它不仅能运行文本生成模型，还支持多模态理解与生成、嵌入模型（用于RAG与向量数据库）、智能体编程（驱动Claude Code等工具），甚至在企业级层面，可应用于文档理解、OCR、推荐系统、客服、编程辅助乃至缺陷检测等判别式任务。此外，在强化学习等训练流程中，最终部署的推理模型、思维模型或工具调用模型，同样可以构建在或内置于vLLM之上。

“vLLM的核心角色，是一个高效的推理引擎与服务器，”Michael总结道，“这类似于Web服务器托管各种网页应用（如HTML或JavaScript页面）的逻辑。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如何守住“推理服务标准”的地位，我们拭目以待。