多模型 AI 视频路由是怎么工作的

"把所有模型装到一个按钮后面"听着简单，其实不是——每个模型 API 不同、价格不同、支持的场景不同，而且全都是异步运行的。下面是我给 HyperFrames 搭的架构，让一个 prompt 框能干净地路由到 Kling、Google Veo 或 Wan，并且永远不会把一笔积分扣两次。

1. 模型的单一事实源

一切从一张注册表开始，它为每个模型定义：支持哪些场景（文生视频、图生视频）、合法的时长和画幅、积分价格、由哪个上游供应商/端点服务。

我坚守的铁律：永远不存在第二张手工维护的价格表。 用户被扣的积分是在加载时从模型定义派生出来的。这个教训我在更早的项目上吃过亏——一张重复的价格表漂移失同步，一个 premium 模型被按真实成本的零头计费，每次成功生成都在亏钱，直到我们发现。一张注册表、一次派生、零漂移。

2. 场景感知的端点解析

一个模型不等于一个端点。有些供应商为同一个逻辑模型的文生视频和图生视频卖不同端点；有些用一个端点、靠你是否传图来切换行为。所以注册表在提交时解析 (模型, 场景) → 端点，而不是假设一个模型对应一个 URL。这里搞错，图生视频请求就会悄悄打到文生视频端点。

3. 带毛利不变量的积分经济

每个模型的积分价格都服从一条不变量：

模型积分 × 成本地板 ≥ 供应商美元成本

其中成本地板是最便宜积分包的单价。只要对每个模型都成立，无论路由选中哪个供应商，都不可能亏本卖出一次生成。前端估算器和服务端用同一个解析器，所以你点生成前看到的积分数字，就是实际会被扣的数。

4. 带 webhook 的异步生成

视频模型要跑几秒到几分钟，HTTP 请求不可能挂那么久，所以生成完全异步：

1. 派发——按注册表校验请求、占用积分、建任务，带一个签名回调 URL 把任务打给供应商。
2. 回调——供应商完成后 POST 到我们的 webhook。我们验 HMAC token（防止有人伪造"成功"）、下载结果、转存到自己的对象存储、标记任务完成。
3. 对账——webhook 偶尔会丢。一个后台流程轮询任何"处理中"太久的任务，从供应商状态把它收尾，所以没有任务会永远卡住。

5. 幂等扣费 —— 保护你积分的那部分

积分产品里最吓人的失败模式是一次生成扣两次费。慢渲染加一次没耐心的双击、一个重试的脚本、一次抖动的网络——任何一个都可能把同一请求发两次。

所以每次生成都带一个幂等 key。第一个请求赢得唯一性约束、只建一个任务；任何同 key 的重复请求都会输掉竞争，返回已存在的任务，而不是再派一个作业。我直接测过：同时打五个一模一样的请求，得到的是恰好一个任务、一次扣分、一次供应商调用。而如果占用积分后派发失败，积分会自动退还——你永远不会为没发生的生成付费。

这对你意味着什么

你看到的是一个 prompt 框和一个模型下拉。底下是一张让价格诚实的注册表、让正确端点总被命中的场景感知路由、带对账兜底让作业可靠完成的异步 webhook，以及让你余额每个视频只被扣一次的幂等扣费。正是这些无聊的基础设施，让"每个模型、一套积分"真的成立。