vLLM v0.26.0 将 AMD GitHub 故事推向跨厂商推理竞赛
vLLM 发布了 0.26.0 版本，包含 411 次提交，使 amd github 生态系统成为日益扩大的推理竞赛的核心。此次更新致谢了 212 位贡献者，其中包括 61 位首次贡献者。最具影响力的改动聚焦于 DeepSeek-V4、ROCm、推测解码和硬件专用内核。
这并不只是又一份冗长的模型与错误修复清单。vLLM 正在成为一个共享优化层，Nvidia、AMD、Intel、模型开发者和基础设施团队都在通过代码展开竞争。该框架正愈发决定新架构能以多快速度在其创建者偏好的硬件栈之外变得实用。
v0.26.0 release 支持这一判断。它将完整的 Inkling 实现与覆盖 CUDA、ROCm 和 XPU 的 DeepSeek-V4 优化结合起来，同时还提升了准确性、缓存分层、注意力选择和 Rust 前端。
核心矛盾如今已很清晰。硬件厂商依然能从专有库和架构专属功能中获益。然而，用户正越来越期待一个服务框架能在多种加速器上提供有竞争力的性能。
这种期待给每家厂商都带来了压力。Nvidia 必须维持 CUDA 与较新 Hopper 功能的优势。AMD 必须将 ROCm 兼容性转化为可重复的生产性能。Intel 则必须证明 XPU 支持不止于基本执行。
vLLM v0.26.0 并未终结这场竞赛。它让战场变得更可见、更可衡量，也更易于贡献者参与。
vLLM v0.26.0 实际带来了哪些变化
该版本将多项新兴模型功能纳入更广泛的服务栈，同时增加了超越 Nvidia 硬件范围的优化。
Inkling 获得了最完整的模型级引入。该版本新增基础建模、分段 CUDA 图支持，以及针对 Hopper GPU 优化的相对注意力。它还包括 MTP=1 推测解码、LoRA 支持和标准的 ModelOpt NVFP4 量化。
CUDA 图会记录 GPU 操作以便高效重放，从而减少重复启动开销。分段捕获将这种方法应用于工作负载中兼容的部分，而非要求使用一张固定的整体图。
MTP 指多 token 预测，即模型在生成过程中一次提出不止一个未来 token。推测解码会并行检查这些候选 token，并保留主模型接受的部分。该技术旨在降低生成延迟，同时不改变最终模型的接受规则。
LoRA，即低秩适配，会向基础模型加入紧凑的可训练权重。其支持之所以重要，是因为生产团队常常通过共享基础设施服务多个定制变体。若只支持模型而没有适配器路径，这种部署模式便不完整。
因此，Inkling 工作覆盖的不只是权重加载，还涉及图执行、注意力、推测生成、定制化和量化部署。这种广度比兼容性列表中出现一个模型名称更具信号意义。
DeepSeek-V4 获得的是另一类关注。vLLM 报告称，一个专用路由内核带来了每个输出 token 端到端耗时 2.94% 的改善。每输出 token 耗时通常称为 TPOT，用于衡量完成初始处理后生成 token 的速度。
该版本还报告，fused_topk_bias 内核的运行速度提升至原来的 1.5 至两倍。该操作有助于在混合专家模型中选择专家。另一项改动移除了冗余的重复与复制操作，据报告带来 1.8% 的端到端 TPOT 提升。
这些数字是项目方针对特定 pull request 报告的结果，不应被解读为适用于所有配置的普遍改进。批量大小、序列长度、加速器、并行策略和模型设置都可能实质性改变结果。
准确性也与吞吐量一同受到关注。新的 head_dtype 选项允许生成模型以 fp32 运行 lm_head。语言模型头会将内部表示转换为 token 分数，因此这一最终阶段的数值行为至关重要。
项目将这条 fp32 路径扩展至 LoRA，并增加了 ROCm torch.mm 快速路径。因此，团队可以保护输出头精度，而无需在 AMD 硬件上接受完全通用的实现。
现在可以为每个键值缓存组选择注意力后端。键值缓存会存储此前的注意力状态，从而让生成过程无需重新计算完整序列。按缓存组选择后端，有助于支持层之间注意力要求并不相同的混合模型。
滑动窗口注意力也成为一项明确的后端能力。这项改动让引擎能够更清晰地判断，某个后端是否支持仅关注有限近期上下文的模型。
该版本移除了 TeleChat、Persimmon 和 Fuyu 支持。这提醒我们，服务框架无法在不承担维护成本的前提下无限扩展。新集成不断加入，而维护不足或相关性较低的路径最终会退出。
该版本的规模固然重要，但其构成更重要。模型集成、底层性能、正确性、存储与前端工作同步到来。这种组合构成了本次更新核心的跨厂商压力。
为什么 AMD GitHub 工作的重要性超越兼容性
AMD 支持正从清单项目走向模型专属优化，尽管生产级对等性仍需独立测试。
amd github 这一侧面体现在多项与 DeepSeek 相关的改动中。vLLM 为分层上下文注意力预填充新增了 ROCm 两阶段压缩器。预填充会在逐 token 生成开始前处理输入提示词。
分层上下文注意力会将长上下文计算拆分到多个设备和通信阶段。两阶段压缩器能够降低为这一路径准备数据的成本。其实际价值取决于具体的集群拓扑和工作负载。
该版本还列出了针对 DeepSeek-V4 的稀疏解码与预填充优化。稀疏计算会避免处理不参与当前步骤的元素或路径。当模型架构暴露出可用稀疏性时，这可以减少不必要的内存流量和算术计算。
另一项贡献将面向 DeepSeek-V4 的 DSpark 推测解码带到 AMD。DSpark 是一种草稿模型方法，用于提出 token 供目标模型验证。它出现在 AMD 上，意味着推测执行不再仅被视为 CUDA 功能。
相应的 AMD DSpark work 直接服务于这场核心竞赛。当团队能够通过同一服务接口，在另一类加速器上运行现代模型功能时，该功能就更具实用价值。
ROCm 还获得了 fp32 生成头的快速路径。与推测解码相比，这一细节看似较小，却处理了一个实际权衡：运营者希望获得准确性优势，而不必让每项操作都走低效的回退路径。
额外的 ROCm 工作覆盖了 MiniMax-M3 的稀疏分页注意力和推测解码。分页注意力以块为单位管理缓存内存，在请求长度不同时减少碎片化。稀疏分页注意力则在这一内存系统中应用模型专属的稀疏性。
该版本还包含 HybridW4A16 线性内核。W4A16 表示四位权重与 16 位激活值。这在计算期间保持较高激活精度的同时，减少模型权重内存占用。
MiniMax-M2 通过 AITER 获得了融合 QK 归一化和 all-reduce 实现。融合会合并操作，以降低中间内存流量和启动开销。all-reduce 会在分布式推理期间聚合参与设备之间的数值。
这些改进并非可以互相替代。每项都针对不同瓶颈，例如内存容量、通信、缓存处理、token 验证或内核启动。它们共同表明，AMD 贡献者正在服务栈的各层开展工作。
这种广度比名义上的模型支持更有意义。一个模型或许能成功加载，却可能因为某项未经优化的操作主导延迟而在经济性上缺乏吸引力。生产支持要求逐一移除这些瓶颈。
发行说明还将 AMD 关联贡献者列为项目的首次参与者。贡献者所属机构本身并不能证明性能对等，但它显示厂商专属的专业能力正在进入共享仓库。
对于基础设施采购方而言，这改变了评估流程。他们可以通过相似的 API 和更一致的软件层比较硬件。仍需进行具有代表性的基准测试，但由完全不同服务系统造成的差异会更少。
这种影响也延伸至工程工作流。团队可以查看实现细节，并通过 pull request 跟踪优化。engineering knowledge base 可帮助组织将这些变化与内部基准结果和部署决策关联起来。
AMD 的机会很明确。更强的 vLLM 支持能够降低曾经保护 CUDA 部署的软件切换成本。运营者可以保留熟悉的模型服务概念，同时测试另一种加速器。
余下的挑战同样明确。AMD 必须证明其在真实工作负载中具备稳定性能，而不仅是单个内核的表现。安装、集体通信、可观测性、模型覆盖范围和回归控制，都会影响生产环境的采用。
vLLM v0.26.0 缩小了部分实现差距。它并未消除硬件可用性、网络、库成熟度或运维经验方面的差异。从该版本得出的任何采购结论，都应以这种区别为指引。
DeepSeek-V4 让跨厂商内核成为主赛场
DeepSeek-V4 使该框架成为竞争性硬件路径的交汇点，因为其架构暴露出多个高要求的推理瓶颈。
混合专家模型会为每个 token 激活选定的专家网络，而不是使用全部参数。这种设计能够在不对每一个生成步骤应用完整网络的情况下提升模型容量，但也带来了棘手的路由和通信问题。
专用 DeepSeek-V4 路由内核正是为解决其中一个问题而设计。vLLM 将其与 2.94% 的端到端 TPOT 改善相关联。重要的是“端到端”这一表述，因为孤立的内核加速未必会影响用户可见的延迟。
fused_topk_bias 的结果说明了这种区别。项目报告其内核性能提升至原来的 1.5 至两倍。在操作层面，这一提升很显著，但完整应用的收益取决于该操作占据多少运行时间。
移除重复的张量复制操作，据报告带来 1.8% 的端到端 TPOT 改善。复制并不会增加模型智能，却会消耗带宽和时间。它们被移除说明，成熟的推理优化往往看起来像系统层面的日常整理。
这些收益会在不同工作负载中以不同方式累积。高流量服务可能重视小幅 TPOT 降低，因为它影响大量请求。低流量应用则可能更关心启动时间、首 token 延迟或内存容量。
该版本将 DeepSeek 相关工作扩展到 Nvidia、AMD 和 Intel 路径。Nvidia 获得了专用内核改进和面向 Hopper 的能力。AMD 获得了 ROCm 压缩、稀疏执行和推测解码。Intel 的 XPU 路径则获得了 DSpark 推测解码。
XPU DSpark 变更之所以重要，是因为它将一项关键特性镜像到了另一种后端。XPU 是 Intel 面向加速器的软件抽象层，涵盖受支持的 GPU 环境。
这并不意味着这些实现可提供完全相同的性能。它意味着该框架能够在不止一种后端上表达相同的服务策略。这使对比测试更容易，也减少了应用层面的架构锁定。
Nvidia 依然拥有显著的软件优势。Inkling 栈包含 Hopper FA4 相对注意力和 ModelOpt NVFP4 量化。Hopper 是 Nvidia 的 GPU 架构，应用于 H100 一代等产品。
FA4 指本次发布工作中采用的专用注意力实现。NVFP4 是与 Nvidia 优化栈相关的四位浮点格式和部署路径。这些特性表明，新硬件能力能够迅速进入 vLLM。
与此同时，vLLM 正在构建避免由单一后端定义所有层级的抽象。按缓存组选择注意力实现，让模型能够组合兼容的实现方式。显式能力声明则让调度器更容易处理后端差异。
因此，真正的对手并不是 AMD 与 Nvidia 两家公司之间的竞争，而是作为服务策略的可移植优化与厂商专属优势之争。
可移植优化承诺在不断变化的加速器环境中提供统一的运维界面。厂商专属优势则承诺通过紧密对齐的库和内核，最大化利用硬件特性。vLLM v0.26.0 试图同时兼容这两种路径。
这种平衡并不容易。抽象可能过于通用，从而留下未被利用的性能空间。实现也可能过于专用，进而在模型、设备和软件版本之间带来维护负担。
该项目的贡献者模式提供了一种答案。硬件专家可以加入针对性的实现，而引擎则保留共享的调度、API、缓存和模型行为。本次发布的 212 位贡献者表明，这种协作的范围已相当广泛。
不过，贡献者数量并不能衡量架构一致性。更多路径意味着需要测试更多组合。新模型、缓存策略、量化格式和推测解码器可能以孤立测试难以发现的方式相互作用。
DeepSeek-V4 加剧了这一挑战，因为它结合了专家路由、稀疏操作、长上下文机制和推测选项。对于任何有关跨厂商服务成熟度的说法而言，它都是一项有效的压力测试。
在这一背景下，amd github 的工作更具意义。它并非 vLLM 边缘的独立兼容性项目，而是与 CUDA 和 XPU 实现共同参与同一场面向特定模型的性能竞赛。
该版本扩展能力的速度快于确定性
vLLM v0.26.0 提供了更多部署组合，但其发布说明不能替代针对具体工作负载的验证。
第一个不确定性涉及基准测试的可迁移性。2.94% 的端到端 TPOT 改进描述的是经过测试的情境，而非有保证的结果。硬件类型、张量并行度、提示词长度、输出长度、并发量和内存压力都可能改变结果。
内核级结果需要更加谨慎地解读。一项操作快 1.5 至 2 倍听起来很有决定性，但若该内核仅占总运行时间的一小部分，服务层面的增益可能依然有限。
运营团队应使用贴近生产形态的流量复现测量。这包括真实的到达模式、上下文长度、适配器、量化设置和故障行为。峰值吞吐量很少能够完整反映用户体验。
第二个不确定性来自交互复杂度。vLLM 现在支持更多注意力后端、缓存层级、推测配置和特定模型路径。每个选项都能增加价值，但组合会扩大验证范围。
KV 卸载说明了这种取舍。该版本改进了指标、事件处理、对象存储二级层以及对数据并行副本的感知。卸载会将缓存数据从稀缺的加速器内存移至另一存储层级。
这可以扩展有效容量并提升复用率，也可能引入查询延迟、网络依赖、序列化工作和一致性问题。新增的读写仪表应有助于运营团队区分这些成本。
采用工作负载身份的对象存储改善了面向云的安全和访问管理，但也将外部服务行为引入推理路径。团队必须理解延迟尖峰或暂时不可用将如何影响请求。
混合模型的部分前缀缓存命中提供了另一项有用的优化。当前缀缓存中请求共享初始 token 时，它会复用计算。即使缓存提示词仅有部分匹配，部分命中仍可保留价值。
不过，缓存命中率高度依赖应用。具有重复系统提示词的服务可能显著受益。以无关提示词为主的工作负载可能复用有限，却仍需承担缓存管理开销。
新的 fp32 lm_head 选项呈现了不同的取舍。根据该项目的说法，更高精度可提升生成头的准确性。与较低精度路径相比，它也可能影响内存移动或计算。
ROCm 快速路径旨在降低 AMD 硬件上的这类成本。团队仍需进行任务级评估，因为数值变化可能对不同模型和解码设置产生不同影响。准确性应针对相关提示词进行测量，而不应仅根据数据类型推断。
安全性改进也是审视完整发布内容的另一原因。vLLM 替换了 diskcache，以消除 pickle 反序列化。Python pickle 可以在反序列化期间执行代码，因此不受信任或被篡改的数据会带来风险。
该版本还解决了与此前漏洞修复相关的并发稀疏不变量竞争问题。其他变更包括限制完成提示词列表、清理验证错误中的文件路径，以及限制正则表达式编译时间。
这些修复体现了推理服务器所承担的运维负担。它会解析请求、加载模型、管理文件、编译语法，并协调并行工作进程。因此，性能特性是在一个重要的安全边界内交付的。
依赖项更新带来了更多变量。该版本升级至 Transformers 5.13.0、FlashInfer 0.6.14 和 NIXL 1.3.1，也更新了加速器专属组件，并为 ABI 稳定性固定了某些注意力构建版本。
ABI，即应用程序二进制接口，定义了编译组件之间的交互方式。当原生扩展和核心库独立演进时，稳定接口能够减少破坏性变更。即使采取了这些预防措施，依赖项变更仍值得进行预发布测试。
模型移除进一步凸显了维护问题。TeleChat、Persimmon 和 Fuyu 不再受支持。使用较少见模型的团队必须将框架升级视为兼容性事件，而非例行的软件包刷新。
因此，对该版本最稳妥的解读应是有条件的。vLLM 扩大了优化覆盖范围，并改进了多项运行控制能力，但并未独立验证所有宣传中的增益能否适用于全部受支持系统。
该项目透明的拉取请求记录很有帮助。团队可以检查代码、基准测试说明和评审讨论。路由内核工作为评估者提供了比笼统性能说法更精确的起点。
不过，开放实现并不能消除部署风险。运营团队仍需负责回归测试、容量规划、安全审查和回滚准备。
AMD GitHub 生态系统接下来应证明什么
接下来三个信号是可重复的端到端基准测试、跨厂商特性在生产环境中的采用，以及在模型快速变化期间的持续维护。
第一个信号是在 Nvidia、AMD 和 Intel 加速器上进行独立的 DeepSeek-V4 测试。测试应公布提示词分布、输出长度、并发量、精度、并行度、软件版本和功耗条件。
这之所以重要，是因为 vLLM 报告的改进来自多个不同层面。内核加速、复制移除、推测解码和稀疏执行应一起测量。否则，用户无法判断哪些增益能在完整服务中保留下来。
最有用的比较将包括首 token 时间、TPOT、吞吐量、尾延迟和内存消耗。首 token 时间衡量生成开始前的延迟。尾延迟则反映平均值可能掩盖的较慢请求。
如果 AMD 在这些指标上持续保持竞争力，可移植优化的论点将更有说服力。这将表明 ROCm 贡献能够带来不止于功能对等的成果。较弱或不一致的结果则会维持厂商专属调优的理由。
第二个信号是推测解码和分层缓存存储在真实生产环境中的采用。这些特性承诺降低延迟或提升有效容量，但也增加了更多运行环节。
对于推测解码，运营团队应报告接受率和端到端节省。只有当建议 token 被足够频繁地接受，以抵消额外计算时，草稿模型才有帮助。
对于分层存储，运营团队应报告缓存命中率、传输延迟、故障行为以及维护二级数据的成本。v0.26.0 中的新指标为这些观察提供了基础。
可见的采用将强化 vLLM 不只是实现集合的定位。这将表明其抽象能够在持续流量和运维约束下发挥作用。有限的采用则可能暴露发布说明未能呈现的复杂性。
第三个信号是在下一波模型和依赖项变化中的维护质量。v0.26.0 全面加入 Inkling，同时将多个模型迁移至 Transformers 后端。
该迁移可以减少重复的建模代码，并使支持与广泛使用的库保持一致。但它也可能让 vLLM 对上游行为和发布时间更加敏感。兼容性测试必须跟上两个项目的节奏。
因此，Transformers 迁移值得获得超出版本号本身的关注。用户应关注回归问题、后端专属异常，以及支持下一个主要模型系列所需的时间。
模型移除提供了另一项有用的衡量标准。健康的项目有时必须淘汰不再支持的代码，同时也应足够早地传达这些决定，以便运营团队规划迁移。
未来一到三个月，后续修复的质量将与新的头条特性同等重要。快速的纠正性发布可能体现积极维护，但高频率也可能暴露集成压力。
amd github 生态系统还应证明持续的贡献者深度。单一厂商主导的优化可以迅速合入，但要在新的 PyTorch、ROCm、模型和 vLLM 版本中维护它，则需要更长期的所有权。
对开发者而言，实际行动很直接：使用具有代表性的流量和固定硬件，将 v0.26.0 与当前运行的版本进行基准测试。将模型质量检查与系统性能检查分开。
对于企业采购方而言，此次发布支持更广泛的硬件评估，但本身不足以成为采购决策的依据。应要求提供可复现的结果，其中包括安装投入、监控、故障恢复和升级表现。
对于 AI 产品团队而言，这些变化可能在不修改应用接口的情况下影响响应速度和容量。这让基础设施试验更加容易，但也使隐藏的后端差异变得更加重要。
请记录模型版本、运行时设置、基准测试提示词和加速器软件。缺少这些背景信息，后续比较就会失去可靠性。同样的严谨性也能帮助团队解释：为什么较新的内核确实改善了服务表现，或为什么没有改善。
vLLM v0.26.0 最终会推动推理市场走向更开放的竞争。Nvidia 仍保有深度的硬件与软件整合优势。AMD 正在通用框架内获得日益具体的 ROCm 路径。Intel 则持续扩展 XPU 覆盖范围。
结果不会由兼容性徽章决定，而将取决于稳定的延迟、可预测的准确性、运维简便性，以及在真实工作负载下持续维护的能力。
这正是 amd github 故事重要的原因。该代码库正成为硬件声明与可审查实现相遇的场所。下一步，是证明这些实现能够经受住生产环境的考验。
你的团队应优先测试哪一项信号：DeepSeek-V4 吞吐量、推测解码接受率，还是分层缓存行为？选择当前已限制服务的瓶颈，然后将 v0.26.0 与受控基线进行比较。
