把视频生成模型跑起来，只是第一步。换一张加速卡再跑通，往往意味着设备初始化、算子接口、通信后端乃至数值精度都要重新适配和验证。当国产 AI 芯片型号持续增加，模型越来越通用，推理框架却可能被切分成一个个“芯片版本”，这是视频生成走向规模化部署时绕不开的现实问题。

视频生成推理框架 LightX2V 给出的答案，不是另起炉灶，而是一个插件。日前，轻量级图像与视频生成推理框架 LightX2V 正式推出基于 FlagOS 的跨芯片插件 lightx2v-plugin-FL。它以独立 Python 包的方式，为视频生成推理框架 LightX2V 注册一个统一的“元平台”入口。不改主链路，不重写引擎，上层模型流程保持不变，变化只发生在硬件适配层。

一、挑战：视频生成的跨芯适配，难在哪？

与高并发的 LLM 推理不同，视频生成以 DiT 为代表，呈现“长序列、小批次”的负载特征。一次扩散推理需要多轮去噪，注意力、线性层、归一化和旋转位置编码等核心算子的单次开销，会在完整采样过程中不断累积，对算子的稳定性和效率要求极高。同时，视频 Token 数量随分辨率和时长急剧增长，单卡部署常需配合权重卸载、量化或稀疏注意力，跨芯运行必须同步验证数据布局、数值精度、峰值显存和调度开销。

此外，LightX2V 针对视频生成提供了序列并行、CFG 并行及混合并行策略，底层集合通信（如 All-to-All、All-Reduce）一旦变化，直接影响链路的可用性和端到端效率。一个完整的跨芯平台后端，既要识别设备、适配关键算子，也要在优化算子缺失时保证基本可运行，并为多卡选择合适的通信后端。这需要的不是一次性移植，而是可持续的架构设计。

二、解法：三方分工，各司其职

LightX2V 为此次跨芯接入提供了成熟的视频生成推理底座。作为轻量级图像、视频生成推理框架，LightX2V 覆盖多种生成任务，并将少步蒸馏、高性能算子、量化、缓存、参数卸载和多卡并行等技术整合到统一框架中，从计算效率、显存占用和部署方式等多个层面优化生成体验。与此同时，LightX2V 原有的 lightx2v_platform 已将模型流程、设备管理与算子实现分层解耦：上层负责模型加载、采样调度、并行策略和显存管理，下层提供面向不同硬件的设备与算子实现。这套完整的推理能力与清晰的平台抽象，为新的硬件能力接入奠定了基础。

lightx2v-plugin-FL 是连接 LightX2V 与 FlagOS 的轻量适配层。它通过平台注册、设备识别、算子路由和通信连接，为 LightX2V 增加统一的 flagos"元平台"入口。在这条路径下，LightX2V 继续负责上层视频生成流程，插件则将其中的关键计算与多卡通信请求连接到 FlagOS。对使用者而言，只需设置 PLATFORM=flagos 并选择相应配置，即可继续沿用 LightX2V 原有的模型与推理流程。

图：LightX2V 负责上层视频生成流程，插件将关键计算与多卡通信连接到 FlagOS

FlagOS 为这条插件路径提供跨芯片的算子与通信基础设施。FlagOS 社区是面向 AI Agent 时代的开源跨芯片异构 AI 系统软件栈。在 FlagOS 2.1 中，FlagGems 已覆盖 560 多个算子、支持来自 14 家厂商的 23 款芯片型号；FlagCX 以 PyTorch ProcessGroup 方式提供跨芯片集合通信能力，KernelGen 和 FlagScale Agent 则进一步探索算子自动生成与模型迁移。对于本次接入，FlagGems 为视频生成中的注意力、矩阵乘法、归一化和旋转位置编码等计算提供可复用的跨芯能力，FlagCX 则为多卡执行提供统一的集合通信入口。

三方由此形成清晰的协作关系：LightX2V 发挥在生成模型、推理流程和系统优化方面的优势，lightx2v-plugin-FL 负责平台接入、接口适配与能力衔接，FlagOS 提供跨芯算子、集合通信和多元硬件生态支撑。

三、设计：把“元平台”嵌入 LightX2V 的三个关键问题

将 FlagOS 作为一个“元平台”嵌入 LightX2V，而不是绑定某一款具体芯片的后端，需要解决三个关键问题。

1、注册时序

LightX2V 的平台注册分为暂存的 PLATFORM_* 表和模型最终查询的注意力（ATTN）、矩阵乘法（MM）、归一化（RMS/LN）与 RoPE 运行时注册表。框架导入时执行的 merge() 是一次快照复制，而非实时视图；如果插件在合并后才写入平台算子表，模型仍看不到新条目。

lightx2v-plugin-FL 采用了一个有意设计的“分开注册”策略：

• 设备注册到 PLATFORM_DEVICE_REGISTER，供 set_ai_device() 初始化平台时查找；

• 算子直接注册到 LightX2V 的最终运行时注册表，绕开晚注册可能遇到的快照问题。

插件把全部注册逻辑收敛到一个幂等的 register() 函数。无论入口被调用一次还是多次，都不会重复注册。

在打包层面，项目已经声明标准 Python 入口点（Entry Point）：

[project.entry-points."lightx2v.platform_plugins"]
flagos = "lightx2v_fl:register"  

当 LightX2V 上游完成对该 Entry Point 组的扫描后，安装插件即可被框架发现。对于尚未包含扫描钩子的 LightX2V 版本，当前可用的兼容方式是在导入 LightX2V 之前显式导入插件：​​​​​​​

import lightx2v_fl  # 自动调用 register()
import lightx2v

这一导入顺序由框架注册表的快照语义决定。插件通过“算子直达最终注册表 + 设备提前注册”的方式，同时保证算子可见性和平台初始化时序。

2、算子接入

当前插件优先覆盖 Wan 风格视频 DiT 的主干路径。算子选择继续沿用 LightX2V 的配置体系，无需在模型代码中增加 if flagos 分支。下表列出插件提供的注册键；实际运行会由所选 JSON 配置决定启用哪些实现。

（1）Attention：先解决布局，再谈跨芯调用

LightX2V 的 Wan 路径通常使用 [S, H, D]，或带批次维的 [B, S, H, D] 布局。插件把 Q、K、V 转换为 FlagGems 所需布局，调用后再恢复为 LightX2V 期望的形状。变长场景依据 cu_seqlens_q 和 cu_seqlens_kv 分段执行并拼接；FlagGems 不可用或执行异常时，回退到 PyTorch SDPA。当前逐序列路径首先保证完整性，原生变长内核仍是后续优化方向。

（2）MatMul：区分“跨芯可运行”与“低比特加速”

非量化路径通过 F.linear 执行，全局 FlagGems 接管开启后，相关 ATen 调用可进一步由 FlagGems 承接。FP8 和 INT8 路径复用 LightX2V 的按通道对称量化权重加载器，当前会先将量化权重反量化为 FP16，再执行线性层。它提供的是低比特权重存储能力，不等同于融合式 FP8/INT8 GEMM 加速；低比特融合内核及其端到端收益仍需逐芯片验证。

（3）Norm与 RoPE：小算子同样决定端到端完整性

RMSNorm、LayerNorm 和 RoPE 虽然计算规模较小，却高频出现，也容易暴露接口、布局和广播差异。RoPE 适配会统一拆分 cos/sin Cache，在 LightX2V 的 [S, H, D] 与 FlagGems 的 [B, H, S, D] 之间转换；出现异常时，原始布局仍可安全进入 PyTorch 回退实现。

（4）两级接管：显式注册为主，全局接管为辅

插件以 JSON 中可见的显式算子注册为主，也可开启 FlagGems 全局 ATen 接管，让未经过模板层的 Softmax、逐元素计算和归约等长尾操作交给 FlagGems：

export LIGHTX2V_FL_GLOBAL_GEMS=1

如果某些 ATen 算子在特定模型或芯片上不适合被接管，可通过环境变量排除：

export LIGHTX2V_FL_GEMS_UNUSED=softmax,gelu

全局接管会改变整个进程的 PyTorch 算子行为，因此默认关闭。建议先验证显式注册的 DiT 主路径，再按模型和芯片评测全局接管效果。

3、多卡通信

面对长序列注意力，LightX2V 的序列并行需要跨设备重排数据，CFG 并行则让条件与无条件分支并行计算。通信后端必须同时匹配实际设备、PyTorch ProcessGroup 和框架并行策略。lightx2v-plugin-FL插件在初始化分布式环境时优先导入 FlagCX，并采用异构 ProcessGroup 形式：

cpu:gloo,<device>:flagcx

这样，CPU 侧集合通信保留在 Gloo，设备侧通信交给 FlagCX。若 FlagCX 未安装，或用户主动设置：

export LIGHTX2V_FL_DISABLE_FLAGCX=1

插件会根据设备类型回退到对应的设备通信后端：

这套设计同时提供统一入口和兼容路径，并为后续围绕不同卡数、硬件拓扑与并行配置持续开展端到端优化奠定基础。

四、验证：平头哥双卡跑通完整链路

插件是否可用，最终要由真实模型和任务来检验。团队选择 DreamZero-DROID 进行验证，这是一个图像到视频与动作（Image-to-Video-and-Action，I2VA）任务，模型接收多相机视觉输入，同时预测未来视频并输出机器人动作，覆盖视频生成、动作生成、双卡执行和关键算子分发，是比单算子测试更严格的系统验证。

本次实验在两张平头哥 PPU-ZW810E（单卡 97,920 MiB）上运行 LightX2V + FlagOS 路径，任务指令为“向前移动平底锅，并使用盘子中间的刷子刷洗锅内侧”，输入来自 DROID 数据集的三相机观测。视频/动作推理步数均为 16 步，并行方式为 CFG 并行规模 2，分辨率为 640×352。为聚焦计算路径验证，本次关闭 FlagCX，使用厂商 NCCL 完成双卡通信。

运行结果（预热一次后三次测量）显示：DiT 时间为 85.34 ± 0.39 秒，端到端 Pipeline 时间为 88.35 ± 0.36 秒。实测过程中，系统通过 flagos 平台完成执行，注意力算子由 FlagGems 承接，运行记录中未触发 PyTorch 回退路径。

插件最终生成 141 帧、640×352、5 FPS 的视频，并输出数值有效的 384×8 动作数组。这次验证跑通的不只是一段视频，而是从多视角视觉输入、未来画面预测到机器人动作输出的完整链路——真实模型、双卡执行、关键算子分发、数值有效输出，每一个环节都在验证插件架构的可行性。

五、价值与展望：从一次接入到持续共建

LightX2V 与 FlagOS 的这次连接，价值沿着三个层次向外延伸，也为后续的生态共建奠定了基础。

对 LightX2V 用户而言，多了一条熟悉而开放的部署路径。模型、任务、提示词和大部分配置仍沿用 LightX2V 原有方式，开发者无需学习另一套视频生成框架，就能尝试 FlagOS 提供的跨芯片能力。对 LightX2V 框架本身而言，进一步拓宽了多平台生态。FlagOS 插件与已有硬件支持相互补充，让框架既能深耕模型推理与性能优化，也能连接更广泛的跨芯片开源基础设施。对 FlagOS 与芯片厂商而言，插件生态延伸到视频生成和具身智能领域——视频生成和具身智能任务能够持续检验算子覆盖、精度、多卡通信和系统协同，真实负载为底层能力迭代提供实际驱动力；芯片厂商也有了更清晰的协作接口，围绕一套配置和测试方法即可参与共建。

目前，lightx2v-plugin-FL 已完成元平台注册、核心 DiT 算子接入、FlagCX 通信选择、PyTorch 与设备通信兼容路径，以及 Wan T2V 配置和 DreamZero 双卡实测。项目已提供平头哥 PPU-ZW810E 的示例 Docker 镜像，开发者可通过源码或镜像快速体验。但当前成果仍以插件框架与端到端链路验证为主，更多芯片、模型、精度与并行组合需要逐项完成数值对齐和性能验证。

后续，双方还将继续推进三个方向的深入工作。在算子层面，变长注意力的原生内核支持、FP8/INT8 融合 GEMM 的逐芯片验证与性能优化，以及 FlagGems 全局接管的稳定性提升。在通信层面，FlagCX 在 LightX2V 序列并行和 CFG 并行负载下的端到端验证与拓扑适配。在生态层面，更多芯片的接入与数值对齐、自动化测试基线的建立，以及与更多视频生成模型的兼容性验证。

这正是开源插件的意义所在：LightX2V 继续推进视频生成推理，FlagOS 社区和芯片厂商围绕清晰的设备与算子边界补齐硬件能力，开发者则用同一套配置和测试方法复现并贡献优化。“PLATFORM=flagos”只是入口；真正重要的，是 LightX2V 由此获得了一条连接多元算力、持续共同演进的新路径。

项目与技术资料

• LightX2V：https://github.com/ModelTC/LightX2V

• LightX2V x FlagOS 插件：https://github.com/ModelTC/lightx2v-plugin-FL

• FlagOS 官网：https://flagos.io

• FlagOS GitHub：https://github.com/flagos-ai