Helios：一个跳过所有捷径的实时长视频生成模型

我脑子里一直有一张清单，列着我认为视频生成模型必须具备的东西：用于加速的 KV 缓存、用于节省内存的稀疏注意力、用于防止画面漂移的关键帧采样。来自北京大学元组的 Helios 把这些全都抛弃了——却依然在单张 H100 上跑出了 19.5 FPS。正是这个矛盾让我停下来认真看了看。

我是 Dora。过去几天我仔细阅读了 Helios 论文和代码仓库，在本地跑了一些测试，试图弄清楚为什么这个方案能在常识认为不该奏效的情况下奏效。这不是一篇跑分评测，更像是一个被”革命性”声称烫伤过太多次、每次都要索要凭证的人留下的一组笔记。

Helios 究竟是什么

Helios 是一个自回归视频生成模型，每个块生成 33 帧，通过将块串联起来生成分钟级别的视频——最高可达 1,452 帧、24 FPS，折合约 60 秒连续画面。

这本身并不令人惊讶。真正不寻常的是它没用到的那些东西：

• 无 KV 缓存
• 无因果掩码
• 无稀疏或线性注意力
• 无 TinyVAE
• 无渐进式噪声调度
• 无量化
• 无 self-forcing、error-banks 或关键帧采样（标准防漂移工具箱）

看到这张清单，感觉就像有人在描述一辆没有发动机还能跑的车。这些技术的存在，都是因为视频生成开销大、内存饥渴，而且在长序列上容易出现质量退化。Helios 绕开了所有这些，却仍然实现了实时推理。问题不在于它是否有效——演示视频就摆在那里——而在于为什么有效。

三阶段训练流程

Helios 提供三个模型变体，分别对应三个训练阶段。理解这些阶段有助于解释其设计逻辑。

第一阶段：Helios-Base

基础模型。核心架构创新就在这里落地：

• 统一历史注入（Unified History Injection）——模型在不产生通常误差累积惩罚的情况下对先前块进行条件约束
• 简易防漂移（Easy Anti-Drifting）——一种训练时策略，取代了大多数自回归视频模型所依赖的推理时 hack（self-forcing、error-banks）
• 多期记忆块化（Multi-Term Memory Patchification）——一种处理长时间上下文的内存高效方案

Helios-Base 使用带有标准无分类器引导（CFG）的 v-prediction。它在三个变体中原始质量最高，但推理时也最重——每块需要 50 个扩散步骤。

第二阶段：Helios-Mid

引入了**金字塔统一预测校正器（Pyramid Unified Predictor Corrector）**进行 token 压缩的中间检查点。模型在这里开始用边际质量换取显著的速度提升。它使用 CFG-Zero*，消除了推理期间无条件模型评估的需求。

如果你用过扩散模型，就知道 CFG 通常会让计算量翻倍——每一步要跑两次模型，一次带提示词，一次不带。去掉这个需求是相当可观的效率提升。

第三阶段：Helios-Distilled

最终变体使用**对抗性分层蒸馏（Adversarial Hierarchical Distillation）**将 50 个扩散步骤压缩到 3 个。它从 v-prediction 切换到带自定义调度器（HeliosDMDScheduler）的 x0-prediction，并完全取消了 CFG 的需求。

这正是跑出 19.5 FPS 的变体。三步，无 CFG，无加速 trick——只是一个被训练成一次就能做对的模型。

“无捷径”方案为何重要

视频生成领域的大多数加速工作都是叠加式的。你先建好模型，发现太慢，于是加上 KV 缓存。内存还是不够，于是加上稀疏注意力。长序列上质量漂移，于是加上关键帧采样。每个修补都引入了自己的故障模式和复杂性。

Helios 走的是反向路径：让基础模型本身足够高效，从而不需要那些外挂。训练流程承担了推理时 trick 通常负责的繁重工作。

这里有一个实际影响很容易被忽视。活动部件越少，能出问题的地方就越少。 如果你曾经调试过 KV 缓存损坏问题，或者看着稀疏注意力在特定帧边界产生瑕疵，你就知道这些系统要收的代价。Helios 不用交这个代价。

内存方面的数据同样令人印象深刻。论文声称在训练期间，使用图像扩散规模的批大小，可以在 80 GB 显存内装下四个 140 亿参数的模型。这是对通常庞大资源占用的一次激进压缩。

它能做什么

Helios 在三个变体上都支持四种生成模式：

• 文本生成视频——输入提示词，输出视频
• 图像生成视频——首帧加提示词
• 视频生成视频——风格迁移、重定时、修改
• 交互模式——迭代精修

帧数规则很具体：以每块 33 帧的倍数为单位工作。想要大约 30 秒？那就是 22 块 = 726 帧。完整一分钟？44 块 = 1,452 帧。块边界是自回归交接发生的地方，从我看到的演示来看，接缝出奇地干净。

最后这一点值得强调。自回归视频模型通常在块边界处表现最差——运动卡顿、颜色偏移、物体漂移。“简易防漂移”训练策略似乎真正解决了这个问题，尽管在宣告问题已解决之前，我还想看到更多样化的测试用例。

集成与生态

Helios 已经支持多种推理后端：

• Hugging Face Diffusers——ModularPipeline 集成
• vLLM-Omni——基于阶段图架构的分离式服务
• SGLang-Diffusion——带优化内核的统一流水线
• Ascend NPU——Day-0 硬件支持（在昇腾上约 10 FPS）

Diffusers 集成最易上手。vLLM-Omni 路径对于希望在不同硬件上分离预填充和解码阶段的生产部署很有意思。SGLang-Diffusion 感觉是面向未来的选项——它专为批量流水线式服务设计，这类服务能让实时应用成为可能。

对昇腾 NPU 的支持是一个战略信号。对非 NVIDIA 硬件的 Day-0 支持说明这不是事后才想到的。在昇腾上约 10 FPS，虽然比 H100 慢，但对许多应用来说仍然可用。

HeliosBench

团队构建了他们自己的基准测试——HeliosBench——专门为评估实时长视频生成而设计。这值得一提，因为现有大多数视频基准聚焦于短片段（4–16 秒），无法捕捉在分钟级别长度下才会出现的失败模式：时间漂移、运动退化、物体持久性失败。

有专门构建的基准测试并不保证客观性，但至少意味着他们在测量正确的事情。我希望看到使用 HeliosBench 的独立评估来验证其方法论。

我仍在思考的问题

极端情况下的质量。 33 帧块的设计很优雅，但 44 个连续自回归步骤有很多累积误差的机会。演示视频看起来很干净，但演示永远看起来干净。我想看对抗性提示词——复杂的摄像机运动、多个相互作用的物体、整整一分钟内戏剧性的光线变化。

蒸馏的权衡。 从 50 步压缩到 3 步相当激进。蒸馏模型通常以牺牲多样性和精细细节来换取速度。Helios-Base 变体的存在自有其原因——当质量比速度更重要时，你要付出 17 倍的计算代价。两个工作点之间的差距相当悬殊。

生态系统成熟度。 该模型是开源的（Apache 2.0），这很好。但开源视频模型需要社区工具才能变得实用——ComfyUI 节点、微调训练脚本、LoRA 支持。这个生态系统需要时间发展，而 Helios 现在还是全新的。

硬件要求。 在 H100 上实时运行令人印象深刻。但大多数人的桌面上并没有闲置的 H100。对许多用户来说更相关的问题是：在 4090 上体验如何？在 A100 上呢？论文对 H100 和昇腾的性能说得很清楚，对硬件长尾则不太明确。

为何脱颖而出

过去一年我看过很多视频生成发布公告。大多数都是渐进式的：更好的 FID 分数、稍长一点的片段、稍快一点的推理。Helios 感觉不同，因为它挑战了一个我没意识到自己已经内化的假设——实时长视频生成需要一叠推理优化叠在彼此之上。

Helios 给出的答案是：如果你只是把模型训练得更好呢？ 把复杂性推进训练流程，而不是推理栈。让模型本身高效，而不是事后往上贴效率补丁。

这种方法是否能够扩展、泛化，并在生产工作负载的冲击下存活，还是一个开放的问题。但这个方向令人信服。更少的活动部件，更清晰的架构，以及不言自明的性能数字。

代码和权重在 GitHub 上。Apache 2.0。如果你有一张 H100 和一个下午，值得一看。