15 个视频生成 provider：云 API、本地 GPU 与素材库三条路
看 OpenMontage 的视频生成能力，最容易走偏的读法是把 README 里那张 provider 表当成排行榜，从上往下找「哪个最好」。这张表不是排行榜，它是一张接入方式清单：同一件事（把提示词或图片变成一段视频）有三条性质完全不同的路，表里的 Type 那一列才是重点。
先把表放上来
这张表出自 README 的 Supported Providers 折叠块，标题写的是 15 providers，表格实际也是 15 行。Notes 一列是 README 自己的措辞，照抄如下：
| Provider | Type | README 的 Notes |
|---|---|---|
| Kling (fal.ai) | Cloud API | High quality, fast via fal.ai gateway |
| Kling Official | Cloud API | Official direct API with separate kling_official provider |
| Runway Gen-4 | Cloud API | Cinematic quality, Gen-3 Alpha Turbo / Gen-4 Turbo / Gen-4 Aleph |
| Google Veo 3 | Cloud API | Long-form, cinematic. Via fal.ai or HeyGen. |
| Grok Imagine Video | Cloud API | Strong reference-image video and xAI-native short-form generation |
| Higgsfield | Cloud API | Multi-model orchestrator with Soul ID for character consistency |
| MiniMax | Cloud API | Cost-effective |
| HeyGen | Cloud API | Multi-model gateway |
| WAN 2.1 | Local GPU | Free, 1.3B and 14B variants |
| Hunyuan | Local GPU | Free, high quality |
| CogVideo | Local GPU | Free, 2B and 5B variants |
| LTX-Video | Local GPU / Modal | Free locally, or self-hosted cloud |
| Pexels | Stock | Free stock footage |
| Pixabay | Stock | Free stock footage |
| Wikimedia Commons | Stock | Free/open stock footage and archival video |
读之前先立一条边界：Notes 里的 “High quality”、“Cinematic quality”、“Cost-effective” 全都是 README 的描述，不是我们的评价。我们没有调用过其中任何一个 API，没有生成过任何一段视频，也没有验证过任何一条 Notes。下面能写的，只有从这张表数出来的结构，以及它和仓库里其它文本能对上的地方。README 在这一节顶部还指向 docs/PROVIDERS.md，说那份文档里有完整配置指南、定价与免费额度——那份文档我们没有读过，本文不描述它的内容。
数出来的三类：8 / 4 / 3
按 Type 列分，15 个里 8 个是 Cloud API、4 个是 Local GPU（含 LTX-Video 那行的 Local GPU / Modal）、3 个是 Stock。
这个 8/4/3 比数字本身有用得多，因为三类的性质根本不一样：
- Cloud API：要密钥、要联网、按调用计费，出片能力取决于对面的服务。
- Local GPU：四行 Notes 里都出现了 Free（LTX-Video 那行写的是 “Free locally, or self-hosted cloud”），代价换成了你自己的机器和模型下载。
- Stock：Pexels、Pixabay、Wikimedia Commons 三个，压根不生成任何东西，是检索既有素材。
第三类特别容易被忽略。它跟前两类不是同一个动作，却被放进了同一张「视频生成」表里。对于内容本身要求真实影像的片子（档案画面、实拍空镜），这一类是唯一走得通的路；反过来，你要一个世界上不存在的镜头，素材库这条路直接出局。选型的第一刀应该切在这里，而不是切在「Kling 和 Runway 谁强」。
三条网关型路径，和出现了两次的 Kling
把表横着读，会发现有几个条目并不是模型，而是网关：
- fal.ai：Kling 那行 Notes 明写 “via fal.ai gateway”，Veo 3 那行写 “Via fal.ai or HeyGen”，MiniMax 也在 README 里被归到可经 fal.ai 的一路。
- HeyGen：README 直接把它描述为 “Multi-model gateway”，
.env注释里写的是 “VEO, Sora, Runway, Kling via single gateway”。 - Atlas Cloud：出现在
.env的注释里。
Higgsfield 那行的措辞是 “Multi-model orchestrator”，也属于「一个入口后面挂多个模型」的形态。
所以「配了几个 provider」和「能调到几个模型」不是一回事：一把网关密钥可能同时点亮好几行，而两行不同的条目也可能指向同一个底层模型。
最典型的就是 Kling 出现了两次：一次是 Kling (fal.ai)，走 fal.ai 网关；一次是 Kling Official，README 写明是官方直连，provider 名叫 kling_official。这不是重复条目——它和 .env 里 FAL_KEY 与 KLING_API_KEY 是两个独立密钥的事实对得上。也就是说，你手上有哪把密钥，决定你走的是同一个模型的哪条通道。密钥在文中一律以变量名出现，别把真实值贴进任何配置示例或截图里。
本地那四个，能落到配置里的具体取值
本地 GPU 这一类不只是表里四个名字，它在 README 的环境变量示例里有确切的取值。VIDEO_GEN_LOCAL_MODEL 这一行给出的可选值是：
VIDEO_GEN_LOCAL_MODEL=wan2.1-1.3b # or wan2.1-14b, hunyuan-1.5, ltx2-local, cogvideo-5b
五个取值，正好对应表里 WAN 2.1（1.3B 与 14B 两个变体）、Hunyuan、LTX-Video、CogVideo 四个 Local GPU 条目。表里 Notes 说 WAN 2.1 有 1.3B 和 14B 两个变体，配置项里就真有 wan2.1-1.3b 和 wan2.1-14b 两个值——文档和配置在这一处是咬合的。
需要说清楚的是，这是一个取值枚举，不是硬件建议。这些模型各需要多少显存、能不能在你的卡上跑起来、跑多久，README 与本文引用的仓库文本里都没有给出数据，我们也没有跑过，所以本文不写任何「几 G 显存够用」的话。CogVideo 那行 Notes 提到 2B 和 5B 两个变体，而 VIDEO_GEN_LOCAL_MODEL 的枚举里只出现了 cogvideo-5b——两处的粒度不同，这里只陈述差异，以仓库当前状态为准。
一个视频 provider 都不配，会发生什么
这张表还有一个「第零档」，藏在 README 的合成运行时那节里：当没有配置任何视频生成 provider 时，agent 生成静态图，由 Remotion 把它们变成完全动起来的视频。
这是 README 的原文口径，也是理解整个 provider 体系的关键——视频生成 provider 在这套系统里是可选增强，不是必选前置。Remotion 被 README 标注为 “Local (Node.js)“，做的是基于 React 的程序化视频；另一套运行时 HyperFrames 走 HTML/CSS/GSAP 路线。两套运行时怎么选、以及它们各自的版本要求，我们另有一篇专门讲，这里只需要记住一件事：表里 15 行全空着，这套系统仍有出片路径。
15 个 provider，不等于 13 个工具
README 架构图里 tools/video/ 那一行写的是 “13 video gen tools + compose, stitch, trim”，和这张 15 行的表数字对不上。
两者不是同一个计数口径：一个数的是 provider，一个数的是 tool。写文档、写工单、跟人对齐能力范围的时候，把口径说清楚比报数字重要——「我们接了 13 个」和「我们接了 15 个」在没有口径的情况下都是错的说法。这处差异如实指出到此为止，我们不推断哪个是准的，也不拿它评价这个项目。
所以别数这张表，去问 registry
AGENT_GUIDE.md 的 What Not To Do 里有一条与本篇直接相关的硬条款：不要硬编码 provider 名、API key 名或安装 URL，要从 registry 的 install_instructions 和 dependencies 字段读。另一条是：不要孤立地呈现单个不可用工具，永远展示完整能力图景，用 “X of Y providers configured for this capability.” 这种说法。
还有一条容易踩的：tts_cloud、tts_engine、video_gen 这三个是已删除的旧名称，文档明确要求不要再使用。你如果照着老教程或老 issue 里的写法去调，名字对不上是预期内的。
README 给的查法是不看文档看 registry，跑这两条命令：
python -c "from tools.tool_registry import registry; import json; registry.discover(); print(json.dumps(registry.support_envelope(), indent=2))"
python -c "from tools.tool_registry import registry; import json; registry.discover(); print(json.dumps(registry.provider_menu(), indent=2))"
从调用形式能读出 tools/tool_registry.py 里的 registry 对象提供了 discover()、support_envelope()、provider_menu() 三个方法。AGENT_GUIDE.md 的 Mandatory Preflight 一节里另外提到了两条能力查询命令，并各配了一行注释：一条标的是 # Full menu — grouped available/unavailable per capability.（按能力分组，列出可用与不可用），另一条标的是 # Raw envelope — every tool's full contract. Slow/firehose; use for debugging only.（每个工具的完整契约，原文明确警告慢、输出量大，只用于调试）。这两条注释各属于哪条命令，我们不做推断；上面的命令照抄自仓库文档，我们没有运行过，输出结构本文不描述，以你本地跑出来的为准。
顺带一句：README 的演示视频旁标了 $1.33、$0.02、$0.69、$0.15 这类金额，那些是项目方在 README 中自行标注的成本，不是我们验证过的报价，更不能用来推算你自己做一条要花多少钱——用哪条路、跑几次重试、走哪把密钥，变量全在你这边。
拿这张表做判断的顺序
把上面几节倒过来用，顺序大致是这样：先确定你要的画面是必须真实存在（走 Stock 那三行）、还是必须被生成（走另外两类）；再确定你能不能接受付费 API 与联网（能就看 Cloud API 那 8 行，不能就看 Local GPU 那 4 行，或者干脆一个不配、走静态图 + Remotion 那条路）；最后才是在选定的那一类里挑具体条目，而这一步该挑谁，README 只给了形容词，我们没有实测数据，本文不做推荐。
真正确定你手上有什么的，也不是这张表，是 preflight 时 registry 报出来的那份菜单。
本文依据 OpenMontage 官方仓库（github.com/calesthio/OpenMontage）的 README、
AGENT_GUIDE.md、config.yaml、pipeline_defs/ 与 lib/ 下的治理模块整理，核对日 2026-08-09。
本文内容为仓库源码与文档口径，我们没有安装或运行过该系统，也没有调用过其中任何一个 provider API，
文中出现的成本数字均为项目方在 README 中自行标注的金额，非我们的实测结果。
该项目以 AGPL-3.0 发布，部分流水线在 manifest 中自标 stability: beta，请以仓库最新内容为准。
安全相关做法请结合自身环境评估，本文不构成安全方案建议。