HappyHorse 1.1 video routing：阿里把有声视频变成网关决策

HappyHorse 1.1 video routing 在阿里云百炼更新视频模型选型说明后，变成了一个真实的 operator 决策。官方目录现在把 HappyHorse 1.1 推荐给文生视频、首帧图生视频和参考图像生视频，同时把 Wan 2.7 保留给自定义音频、首尾帧连续性、视频参考和更复杂的视频编辑。对把媒体生成当成异步基础设施的团队来说，HappyHorse 1.1 video routing 不是一次简单的模型名更新。它要求 AI gateway 在把任务发送到 DashScope 之前，先判断这是哪一种创意作业。

HappyHorse 1.1 video routing 发生了什么

阿里云官方的 Model Studio 视频生成与编辑指南 已经把 HappyHorse 1.1 放在几个常见视频路径的首选位置。文生视频推荐 happyhorse-1.1-t2v，支持有声视频、720P 或 1080P、3 到 15 秒片段。首帧图生视频推荐 happyhorse-1.1-i2v，分辨率和时长区间相同。参考图像生视频推荐 happyhorse-1.1-r2v，适合需要基于图片保持角色一致性的场景。

同一篇官方文档也保留了 Wan 2.7 的关键位置。需要传入自定义音频文件时，推荐 wan2.7-t2v-2026-04-25。需要首帧、首尾帧、视频续写时，推荐 wan2.7-i2v-2026-04-25。参考中包含图片和视频，或需要通过音频定义音色时，wan2.7-r2v 更合适。特效复刻、运镜复刻和指令编辑继续由 wan2.7-videoedit 承担，普通视频编辑则可以走 happyhorse-1.0-video-edit。

这也和阿里模型目录里的信号一致：Model Studio 已经把 happyhorse-1.1-t2v、happyhorse-1.1-i2v、happyhorse-1.1-r2v、happyhorse-1.0-video-edit 与 Wan、Qwen 图像模型一起列出。官方传递的信息很明确：DashScope 视频不再是一个笼统的“生成短片”入口，而是一组按工作负载划分的路线。

HappyHorse 1.1 video routing 为什么影响 AI engineering teams

视频生成对 routing layer 的压力和聊天、embedding 完全不同。视频任务更长，通常是异步的，重试成本更高，也更难只靠一个 provider 状态码判断成败。一次聊天请求失败后可以很快 fallback；一个 15 秒 1080P 视频任务失败时，可能已经消耗了排队时间、用户耐心和创意预算。HappyHorse 1.1 video routing 给 operator 一个很强的理由：在第一次 API call 之前就要拆分队列。

第一层拆分是意图。纯文本 prompt、首帧动画、参考图像保持一致性、自定义音频、首尾帧连续性、指令编辑，不应该共用同一个默认模型。第二层拆分是证据。请求里是否带音频文件、尾帧、参考视频、编辑指令，会决定模型能力映射。第三层拆分是产品承诺。如果界面承诺音画同步、角色一致性、1080P 输出或平滑串联片段，gateway 就应该根据这个承诺 routing，而不是简单选择最低成本默认路线。

地域也是 operator 影响的一部分。阿里文档在视频家族里区分中国内地、国际、全球和美国部署范围。生产 router 需要知道任务能否在用户选择的地域运行，静态数据驻留是否重要，以及 fallback 是否跨越了部署范围边界。因此，HappyHorse 1.1 video routing 应该进入策略层，而不是散落在各个应用 prompt 里。

HappyHorse 1.1 video routing 的 router/operator angle

一个实用的 AI gateway 应该把阿里的选型说明转换成媒体任务分类器。纯 prompt 短片、并且产品需要 3 到 15 秒有声视频时，把 happyhorse-1.1-t2v 作为默认路线。请求只有单张起始图片、没有自定义音频需求时，走 happyhorse-1.1-i2v。产品要求基于图像保持角色一致性时，走 happyhorse-1.1-r2v。一旦请求包含自定义音频、尾帧连续性、视频续写、视频参考或高级编辑语义，就切到 Wan 2.7。

Fallback 必须显式定义。除非用户或产品策略接受降级，否则不要把有声视频路线静默降到无声模型。不要把首尾帧连续性替换成只看首帧的动画，却不把结果标记为 degraded route。对媒体工作负载来说，fallback contract 至少应该包含分辨率、时长、音频、输入模态、地域，以及是否需要保留参考主体。

Observability 也要有媒体专用标签。建议记录 job_type、input_modalities、requested_duration、resolution、audio_required、reference_kind、region_scope、provider_model、排队时间、生成时间、重试次数和最终资产状态。这些标签能让财务按功能核算视频成本，也能让产品团队知道用户实际在请求文生视频、图生视频还是参考视频。

这正是 TheRouter 的 AI gateway 文档 模式可以延伸的地方。模型 routing 不只是选择便宜的文本模型。对于 multimodal 系统，router 会变成作业规划器：选择 provider lane，记录对用户做出的承诺，并阻止跨模态或跨地域的危险 fallback。

TheRouter 用户应该观察或尝试什么

正在使用 DashScope、或准备构建多 provider 媒体层的团队，应该先把 HappyHorse 1.1 video routing 写成一个小型策略表，再放进产品。可以从五条路线开始：文生视频、首帧图生视频、参考图像生视频、自定义音频或连续性视频、视频编辑。每条路线都定义 primary model、allowed fallback、blocked fallback、最大时长、允许分辨率、数据地域规则，以及用户可见的降级提示。

用代表性任务做一次 dry test：

• 纯 prompt 的 1080P 短片，route 到 happyhorse-1.1-t2v。
• 产品图片动画，route 到 happyhorse-1.1-i2v。
• 角色一致性请求，route 到 happyhorse-1.1-r2v。
• 带旁白的短片，因为需要自定义音频而 route 到 Wan 2.7。
• 串联场景，因为首尾帧连续性重要而 route 到 Wan 2.7。
• 编辑请求不要进入生成路线，而是进入 video-edit lane。

最后验证：即使 provider 改变，gateway 也要为每个任务记录同一组字段。结论很简单：HappyHorse 1.1 video routing 让 DashScope 媒体栈更容易采用，但前提是团队不要再把视频当成单一 endpoint。routing unit 是创意作业本身，策略必须保留模态、音频、地域和 fallback 意图。