不可不知小技巧｜vLLM-Plugin-FL 如何用“统一框架+弹性算子”释放异构算力

随着大模型推理负载的快速增长vLLM 已成为业内广泛使用的推理框架之一。与此同时多芯片生态也在加速走向繁荣一个现实问题逐渐浮出水面同一份 vLLM 代码正在被切分成越来越多个“芯片版本”。不同厂商的加速卡往往需要各自维护独立的 vLLM 分支或插件上游模型更新一次适配工作就要在多条分支上反复重来当用户尝试异构推理部署时更是常常被迫同时维护多套运行环境整体成本显著上升。问题的核心并不在 vLLM 本身而在于vLLM 的硬件相关能力没有被真正“解耦”。FlagOS 提出的统一多芯片 vLLM PluginvLLM-plugin-FL带来了一种更工程化的方式让 vLLM 保持单一版本让硬件差异收敛到算子层。01设计原理“框架层统一算子层分发”的虚拟后端vLLM-plugin-FL 是 FlagOS 面向 vLLM 推理框架打造的跨芯片扩展插件依托 FlagOS 四大核心组件FlagGems 统一算子库、FlagTree 多硬件编译器、FlagCX 分布式通信库和统一调度抽象层构建框架层统一、算子层按需分发的双层架构彻底解决多芯片适配碎片化痛点。解决多芯片适配问题的传统思路是在 vLLM 框架内部为每款芯片添加 if-else 分支。这个方式通常伴随代码臃肿、难以维护等问题甚至 vLLM 上游版本迭代时所有下游厂商分支都要面临痛苦的冲突解决。而 vLLM-Plugin-FL 给出了一种截然不同且更优雅的思路以 Out-Of-Tree 的方式将 FlagOS 作为虚拟后端接入 vLLM。从整体架构来看其核心设计逻辑可概括为十个字框架层统一算子层分发。在该体系中vLLM 上层框架逻辑保持完全一致不感知任何底层硬件差异所有与硬件相关的能力则通过 FlagOS 在算子层进行统一调度。vLLM-plugin-FL 采用Out-of-Tree的方式将 FlagOS 作为虚拟后端接入 vLLM。其核心目标是不修改 upstream vLLM 不引入硬件相关逻辑到框架层通过 plugin 机制扩展 backend 能力。通过这种方式单一 vLLM 版本可以无缝运行在多种芯片上。同时该设计具备天然的异构推理能力可以在不同硬件之间灵活调度执行路径从而最大化各类芯片的计算能力。而从 vLLM 的发展来看其多后端支持经历了代码层硬件抽象 、EntryPoint plugin 机制 、Out-of-Tree plugin三个阶段。FlagOS 方案属于第三阶段其核心特点是将 FlagOS 作为统一虚拟后端、将硬件差异收敛到 plugin 层、保持 vLLM upstream 完整性。这一设计的本质是用统一插件体系替代多分支 fork 维护模式。基于这样的流程多芯片用户可以获得三个关键收益1. 单一 vLLM 版本无差别运行彻底告别“一芯片一分支”的维护噩梦大幅降低同步上游更新的成本。2. 最大化释放异构算力通过灵活的算子分发可以在同一套框架下让不同芯片都运行其最优的算子实现实现“博采众长”。3. 简化部署与维护用户只需安装对应的插件和 FlagOS 组件即可在任意支持的芯片上获得一致的推理体验。同时在算子层面通过 FlagOS Triton 机制还可以提供基础可运行路径保证不同芯片具备统一执行能力。上图展示了从 vLLM 模型代码到多芯片执行的完整链路框架层统一调度算子层通过 OpRegistry SelectionPolicy 在三类后端间自动分发最终落到具体芯片上执行。02核心架构“多芯片算子分发架构”深度剖析如果说“虚拟后端”是 vLLM-Plugin-FL 的设计理念那么多芯片算子分发架构就是承载这一理念的“中枢神经系统”。它由三大核心模块构成统一 Dispatch 机制标准化的算子接入“总线”为了让不同来源的算子能够被统一管理和调用vLLM-Plugin-FL 设计了一套精密的 Dispatch 机制。其核心组件包括OpManager分发管理器、 OpRegistry算子注册表、SelectionPolicy选择策略、BackendImplKind后端类型定义。整体执行流程包括1. 算子调用进入 dispatch 层2. OpRegistry 读取已注册实现3. SelectionPolicy 进行后端选择4. OpManager 执行最终绑定函数目前vLLM-Plugin-FL 支持三种标准的后端实现。当某个算子被调用时Dispatch 机制会按照优先级从高到低查找可用实现优先尝试 FlagGems 的 Triton 算子若不可用则回退到厂商原生算子最后再回退到 PyTorch 参考实现。这种分层兜底的设计既保证了跨芯片的通用性又给厂商留出了深度优化的空间。算子粒度自动调优跨越“最后一公里”的性能鸿沟仅仅能跑起来还不够vLLM-Plugin-FL 的目标是“跑得最优”。为此它构建了一个算子粒度自动调优引擎 AutoTune Engine。这个引擎的工作流程是首先自动遍历模型中的所有算子并基于 FlagGems、Vendor 和 Reference 三种后端为每个算子构建一个包含多种配置的搜索空间然后以模型的端到端吞吐Throughput作为衡量标准自动测试不同算子配置对整体性能的影响最后通过启发式搜索或贝叶斯优化等方法自动找到使端到端性能最优的算子与配置组合供后续推理直接查表使用。这套机制优化的不是单个算子的峰值性能而是端到端吞吐。一个算子单测再快如果它在整体推理链路里拖慢了关键路径也不该被选中。实战验证Qwen3-Next 推理性能优化这套机制的有效性在Qwen3-Next模型上得到了充分验证带来了实实在在的性能提升第一步定位耗时算子。 通过 timeline 分析模型算子情况FlagOS 团队发现FlagGems 通用算子库里的 moe_align_block_size 算子在端到端性能中耗时占比高达 21.7%而 CUDA 版本的 vllm::moe::moe_align_block_size_kernel 仅占 2.5%。这个算子成了明显的性能瓶颈。第二步自动调优选择最优实现。AutoTune Engine 在搜索后为 moe_align_block_size 算子选择了 CUDA 版本实现。仅这一项调整就实现了端到端性能提升 3%–4.6%验证了自动调优对端到端性能的明显收益。第三步框架算子联合优化。针对耗时占比大的 FlagGems 算子团队进一步做了针对性优化重写解码阶段的 GDN 算子并增加并行度加速计算在框架层面移除算子调用前不必要的 clone 操作对 FlagGems 算子做向量化读取数据优化并使用 TLE 的 shared memory 功能加速计算。第四步FlagCX-CA 通信算子优化。 在多卡场景下通信算子同样是关键路径。FlagCX 的 ncclAdator 支持基于 NCCL device API 的 customAllReduce支持 LSA/Multimem 原语小消息≤512KlocalAllReduceMultimemSum LSAStore对比 vLLM cross_device_1stageIPC-based packed_reduce性能持平中小消息512K, 8M]interleavedAllReduceMultimemSum MultimemStore对比 vLLM cross_device_2stageIPC-based reducescatter allgather性能小幅提升。经过上述一套组合拳我们实现了Qwen3、Qwen3-Next 在单卡/多卡基于 FlagOS 统一后端的端到端推理达到 100% Triton 算子替代。Qwen3-Next 模型吞吐在英伟达上最优可达到原生的 99.6%。这意味着在不牺牲性能的前提下换来了跨芯片的统一推理能力。03实战接入芯片企业如何快速接入 vLLM-Plugin-FL对于芯片厂商或开发者而言将自家硬件接入 vLLM-Plugin-FL 生态是一个标准化、低成本的过程。整个流程主要分为适配和使用两大步。厂商算子适配Vendor Backend Integration适配的核心是实现一个 Vendor Backend将自己优化的算子注册到分发系统中。整个流程清晰且模块化1. 创建 Backend 类在vllm_fl/dispatch/backends/vendor/vendor_name/vendor_name.py中创建厂商后端类继承自Backend实现可用性检查和各算子的调用入口from ...base import Backendclass VendorNameBackend(Backend):_available Nonepropertydef name(self) - str:return vendor_namepropertydef vendor(self) - str:return vendor_name # 必须与目录名一致def is_available(self) - bool:检查厂商库是否可用if VendorNameBackend._available is None:try:import vendor_library # 导入厂商库VendorNameBackend._available Trueexcept ImportError:VendorNameBackend._available Falsereturn VendorNameBackend._availabledef silu_and_mul(self, x):from .impl.activation import silu_and_mul_vendorreturn silu_and_mul_vendor(x)def rms_norm(self, x, residual, weight, epsilon):from .impl.normalization import rms_norm_vendorreturn rms_norm_vendor(x, residual, weight, epsilon)def rotary_embedding(self, query, key, cos, sin, position_ids, is_neox_style):from .impl.rotary import rotary_embedding_vendorreturn rotary_embedding_vendor(query, key, cos, sin, position_ids, is_neox_style)def attention_backend(self):from .impl.attention import VendorNameAttentionBackendreturn vendor_module.impl.attention:VendorNameAttentionBackend2. 实现具体算子在impl/子目录下用厂商原生算子实现各个算子的具体逻辑。例如activation.pyimport torchdef silu_and_mul_vendor(x: torch.Tensor) - torch.Tensor:实现 SiLU(x[:, :d]) * x[:, d:] 操作d x.shape[-1] // 2# 使用厂商原生算子实现# 例如华为torch_npu.npu_silu_and_mul(x)return vendor_native_op(x)normalization.py类似​​​​​​​def rms_norm_vendor(x, residual, weight, epsilon):RMS 归一化实现# 使用厂商原生算子# 例如华为torch_npu.npu_rms_norm(x, weight, epsilon)return vendor_native_rms_norm(x, weight, epsilon)3. 注册算子在vllm_fl/dispatch/backends/vendor/vendor_name/register_ops.py中把上述算子实现注册到 OpRegistry并绑定可用性检查​​​​​​​import functoolsfrom vllm_fl.dispatch.types import OpImpl, BackendImplKind, BackendPrioritydef _bind_is_available(fn, is_available_fn):绑定 is_available 检查函数functools.wraps(fn)def wrapper(*args, **kwargs):return fn(*args, **kwargs)wrapper._is_available is_available_fnreturn wrapperdef register_builtins(registry) - None:注册所有厂商算子实现from .vendor_name import VendorNameBackendbackend VendorNameBackend()is_avail backend.is_availableimpls [OpImpl(op_namesilu_and_mul,impl_idvendor.vendor_name,kindBackendImplKind.VENDOR,fn_bind_is_available(backend.silu_and_mul, is_avail),vendorvendor_name,priorityBackendPriority.VENDOR, # 100),OpImpl(op_namerms_norm,impl_idvendor.vendor_name,kindBackendImplKind.VENDOR,fn_bind_is_available(backend.rms_norm, is_avail),vendorvendor_name,priorityBackendPriority.VENDOR,),OpImpl(op_namerotary_embedding,impl_idvendor.vendor_name,kindBackendImplKind.VENDOR,fn_bind_is_available(backend.rotary_embedding, is_avail),vendorvendor_name,priorityBackendPriority.VENDOR,),# 可选attention_backendOpImpl(op_nameattention_backend,impl_idvendor.vendor_name,kindBackendImplKind.VENDOR,fn_bind_is_available(backend.attention_backend, is_avail),vendorvendor_name,priorityBackendPriority.VENDOR,),]registry.register_many(impls)完成这三步后厂商算子就会被自动纳入 Dispatch 系统。运行时SelectionPolicy 会根据优先级和可用性自动决定是否调用厂商实现。可以参考已 Merge 的华为适配 PRhttps://github.com/flagos-ai/vllm-plugin-FL/pull/18。使用流程与调试接入过程中调试是绕不开的环节。vLLM-plugin-FL 提供了四种调试手段1. 环境变量调试​​​​​​​# 启用调试日志export VLLM_FL_LOG_LEVELDEBUG# 启用分发调试模式打印分发决策export VLLM_FL_DISPATCH_DEBUG1# 强制使用特定平台配置export VLLM_FL_PLATFORMvendor_name# 强制使用特定后端export VLLM_FL_PREFERvendor# 关闭FlagGemsexport USE_FLAGGEMS0# 打开FlagGemsexport USE_FLAGGEMS1# 使用FlagCX通信库export FLAGCX_PATH$FLAGCX_PWD2. 单元测试验证​​​​​​​# tests/test_vendor_backend.pyfrom vllm_fl.dispatch import get_default_managerdef test_vendor_backend_registration():manager get_default_manager()manager.ensure_initialized()# 检查注册snap manager.registry.snapshot()for op_name, impls in snap.impls_by_op.items():for impl in impls:if impl.vendor vendor_name:print(f{op_name}: {impl.impl_id}, available{impl.is_available()})def test_vendor_silu_and_mul():import torchfrom vllm_fl.dispatch import call_opx torch.randn(2, 128, devicedevice)result call_op(silu_and_mul, x)assert result.shape (2, 64)3. 运行示例脚本​​​​​​​# 使用 examples/offline_inference.py 测试cd /root/vllm-plugin-FLpython examples/offline_inference.py4. 检查算子分发​​​​​​​from vllm_fl.dispatch import resolve_op# 查看实际使用的实现fn resolve_op(silu_and_mul)print(fUsing implementation: {fn})配置优先级与常用环境变量当存在多份配置时vLLM-plugin-FL 有一套明确的优先级从高到低依次为1. VLLM_FL_CONFIG 环境变量指向的用户自定义配置文件完全覆盖2. 环境变量覆盖平台配置的特定项3. 平台配置文件ascend.yaml/cuda.yaml自动检测4. 代码内置默认值常用环境变量如果需要对 FlagGems 算子做精细控制还有白名单/黑名单机制仅在使用 flagos 后端时生效# 白名单默认空export VLLM_FL_FLAGOS_WHITELISTsilu,rms_norm# 黑名单默认空export VLLM_FL_FLAGOS_BLACKLISTmulFlagGems 算子统计日志路径为/tmp/flaggems_enable_oplist.txt可用于排查哪些算子实际走了 FlagGems 实现。04结语回顾 vLLM-plugin-FL 的整套设计把硬件差异收敛到算子层把框架逻辑统一在插件层。框架层用 Out-Of-Tree 插件方式接入 vLLM保证单一 vLLM 版本多芯片通用算子层用三类后端 优先级的 Dispatch 机制兼顾通用性和厂商优化空间再加上 AutoTune Engine 做端到端最优选择以及标准化的厂商接入流程整套体系就把M 款模型 × N 款芯片的适配难题降维成了M 款模型 N 款芯片的叠加问题。从 Qwen3-Next 上 100% Triton 算子替代、吞吐达原生 99.6% 的实测结果来看这条统一 分发 自动调优的技术路线已经在性能上具备了和原生路径正面交锋的能力。而对芯片厂商来说三步接入 四种调试手段的标准化流程也把跨芯适配的门槛压到了足够低而这或许也是 FlagOS 能够在 Qwen3.5、MiniMax M2.7、MiniCPM5、混元 MT2 等模型上持续实现 Day-0 多芯发布的原因所在。从设计理念到实战接入vLLM-Plugin-FL 都展现出其作为面向多元 AI 芯片的开源智算软件系统的核心价值。我们欢迎更多芯片企业与开发者加入 FlagOS 社区共同推动一个真正开放、统一、高效的 AI 开放计算生态。项目地址与资源vLLM-Plugin-FL 仓库https://github.com/flagos-ai/vllm-plugin-FL关于众智FlagOS社区为解决不同 AI 芯片大规模落地应用北京智源研究院联合众多科研机构、芯片企业、系统厂商、算法和软件相关单位等国内外机构共同发起并创立了众智 FlagOS 社区。成员单位包括北京智源研究院、中科院计算所、中科加禾、安谋科技、北京大学、北京师范大学、百度飞桨、硅基流动、寒武纪、海光信息、华为、基流科技、摩尔线程、沐曦股份、澎峰科技、清微智能、天数智芯、先进编译实验室、移动研究院、中国矿业大学(北京)等多家在 FlagOS 软件栈研发中做出卓越贡献的单位。FlagOS 是一款专为异构 AI 芯片打造的开源、统一系统软件栈支持 AI 模型一次开发即可无缝移植至各类硬件平台大幅降低迁移与适配成本。它包括大型算子库、统一AI编译器、并行训推框架、统一通信库等核心开源项目致力于构建「模型-系统-芯片」三层贯通的开放技术生态通过“一次开发跨芯迁移”释放硬件计算潜力打破不同芯片软件栈之间生态隔离。官网https://flagos.ioGitHub 项目地址https://github.com/flagos-aiGitCode 项目地址https://gitcode.com/flagos-aiSkillHubhttps://skillhub.flagos.io​