LLM 仅做规划，代码接管多模态模型路由决策

LLM 直接决策在多模态场景下失效

AI 模型路由看似只需三步：读取提示、询问 LLM 选模型、直接调用。但当产品同时支持文生图、图像编辑、多参考融合和视频生成时，不同的宽高比、时长、定价规则和访问层级让这种方法迅速失效。

在演示环境中，这种三步流程表现良好。LLM 读取用户提示后能给出看似合理的模型建议，调用后也能生成对应内容。但进入生产阶段后，问题立刻暴露。文生图任务可能要求特定宽高比，图像编辑需要参考原图分辨率，多参考融合则涉及多张输入图片的融合权重，而视频生成还要额外考虑时长、帧率和运动强度。这些参数直接影响模型选择，却无法被单一 LLM 提示完整覆盖。

不同模型的定价规则进一步放大失效风险。某些模型按生成分辨率计费，另一些按视频秒数收费，还有模型存在免费额度与付费层级区分。LLM 难以在每次调用前实时掌握这些动态规则，尤其当访问层级随账户余额或订阅状态变化时，单纯的 LLM 决策很容易选中超出预算或无权访问的模型。

实际开发中，开发者很快发现 LLM 输出经常出现矛盾。例如，用户要求生成 10 秒 1080p 视频，LLM 可能建议某个擅长高质量图像的模型，而该模型实际不支持视频或视频时长上限仅 5 秒。类似情况在图像编辑与多参考融合场景中更常见，因为这些任务需要模型同时理解多张输入图片的语义关系，LLM 很难仅凭文本提示准确判断哪个后端模型最合适。

这种失效不是 LLM 能力不足，而是其定位错误。LLM 擅长理解自然语言意图，却不适合处理带硬约束的工程决策。生产环境要求路由必须稳定、可审计且能严格控制成本，三步式 LLM 路由无法满足这些要求。因此，开发者必须重新定义 LLM 的角色，将其从最终决策者降级为意图规划者。

（本节约 420 字）

代码管道必须接管最终模型选择

生产经验表明，LLM 只能作为规划者，最终决策必须来自受约束的代码管道。

具体做法是将 LLM 的输出解析为结构化意图描述，而不是直接当作模型名称。LLM 收到用户提示后，输出一个包含任务类型、预期质量、风格偏好、参考图片数量等字段的 JSON 对象。代码管道随后接管，根据这些字段结合当前系统状态完成最终选择。

这个管道通常包含多个检查步骤。首先验证任务类型是否匹配可用模型能力，例如视频生成必须路由到支持时序建模的模型。其次检查输入参数是否符合模型限制，如最大分辨率、最大参考图片数或最大视频时长。如果 LLM 建议的模型不符合，任一检查失败则触发备选模型评估。

代码管道的优势在于可加入确定性规则。开发者可以编写函数明确定义“如果视频时长超过 8 秒且预算低于 0.5 元，则切换到低成本模型”。这些规则无法可靠地通过提示工程让 LLM 记住，却能在代码中被严格执行。同时，管道还能记录每次决策的完整上下文，便于后续审计和优化。

在实际开发场景中，这种架构显著提升了系统稳定性。曾经因为 LLM 偶尔选中不支持多参考融合的模型导致生成失败的 bug，在引入代码管道后基本消失。管道还允许开发者逐步添加新模型，只需更新对应规则即可，无需重新训练或微调 LLM 路由器。

更重要的是，这种设计让 LLM 和代码各司其职。LLM 专注理解模糊的用户意图，代码负责处理精确的工程约束。这种分工显著降低了生产事故率，也让路由逻辑更容易被团队其他成员理解和维护。

（本节约 380 字）

成本与访问层级硬编码进路由逻辑

把不同模型的定价规则和访问层级作为约束条件嵌入路由，是控制 API 开销的核心策略。

开发者通常会维护一张模型成本表，包含每种模型当前的分辨率单价、视频秒单价、免费额度剩余量以及访问所需的最低订阅层级。路由管道在每次决策时都会查询这张表，结合用户账户当前状态计算预计花费。如果预计花费超过用户预设预算或可用额度，立即切换到更便宜的备选模型。

实际开发中，这种硬编码方式比让 LLM 估算成本可靠得多。LLM 难以获取实时账户信息，也容易忽略促销活动或阶梯定价细节。而代码可以精确读取这些数据，并在决策前完成复杂计算，例如“当前剩余免费额度可支持 4K 图像 3 张，超出部分按 0.012 元每张计费”。

除了成本，访问层级也是重要约束。某些高端视频模型仅对企业订阅用户开放，路由必须在决策前检查用户权限。如果用户无权访问，管道会自动降级到公开可用模型，并可选择是否提示用户升级订阅。这种机制既保护了服务稳定性，也为商业化提供了自然引导。

在节省开销方面，开发者还可加入缓存策略。例如，对相同提示和参考图片组合，如果之前已生成过且用户未要求变化，则直接返回缓存结果，完全跳过模型调用。成本感知路由还能根据当前服务器负载动态调整，当高成本模型队列较长时，优先选择速度更快、价格更低的模型。

这些策略在中国开发者使用国产多模态模型时同样适用。国内多家平台提供了不同价位的文生图和视频模型，将成本表与路由管道结合，能显著降低整体调用费用，尤其适合需要高频生成的小团队和初创公司。

（本节约 410 字）

图像与视频任务的路由规则差异

文生图、图像编辑、多参考融合与视频生成在路由中需要完全不同的处理方式。

文生图任务相对简单，主要关注提示文本的复杂度和期望分辨率。路由通常根据提示长度和关键词判断是否需要高质量模型。如果用户只要求快速预览，管道会优先选择速度快、成本低的模型。

图像编辑任务则必须考虑参考图片。路由需要分析输入图片的分辨率和编辑强度，如果编辑区域较大或需要保持原图风格，则倾向于选择对图像理解能力更强的模型。同时要检查编辑类型是否在模型支持范围内，例如局部重绘与全局风格迁移的处理模型可能不同。

多参考融合是路由难度较高的任务。它要求模型同时理解多张参考图片的语义关系和权重分配。代码管道需要计算参考图片数量、相似度以及融合复杂度，如果超过某个阈值，则必须路由到专门支持多条件控制的模型。LLM 仅提供融合意图，具体模型选择由管道根据技术限制决定。

视频生成规则差异最大。除了分辨率和时长，还需考虑运动强度和一致性要求。短视频（少于 4 秒）可使用轻量模型，长视频则必须选择支持长时序的模型。管道还会根据用户是否要求高帧率或特定运动类型调整选择。这些参数在 LLM 提示中难以精确表达，必须通过代码硬约束实现。

不同任务的定价差异也很大。视频生成通常比图像贵数倍，路由需要在满足质量要求的前提下尽可能缩短视频时长或降低分辨率来控制成本。这种任务特定的规则差异，正是单纯 LLM 路由无法处理的核心原因。

（本节约 350 字）

国产模型路由的成本控制实践

对中国开发者而言，类似成本感知路由机制对使用国内多模态模型有直接启发。

国内多家平台推出了各具特色的文生图、图像编辑和视频生成模型，价格区间和能力范围差异明显。通过构建统一的路由管道，开发者可以将不同平台的模型统一管理，根据实时价格和性能表现动态选择。例如，当某国产视频模型推出限时优惠时，路由表更新后即可自动提高其优先级。

成本控制方面，开发者可将各平台 API 密钥和额度信息集中管理，管道根据当前剩余额度智能分配任务，避免单一平台额度耗尽导致服务中断。同时可实现跨平台负载均衡，在保证质量的前提下将任务分散到性价比最高的模型上。

实际场景中，许多中国团队面临高频生成需求，例如电商商品图批量生成或短视频内容生产。引入成本感知路由后，相同质量下的 API 开销可降低 40% 至 60%。更重要的是，这种架构不绑定特定平台，便于未来接入新发布的国产大模型，保护了长期投入。

开发者还可针对国内模型特性定制额外规则。例如某些模型对中文提示理解更好，路由可根据提示语言自动提高其权重。结合本地部署的轻量模型与云端商用模型的混合路由，进一步降低了整体成本。

这种实践正在被越来越多国内团队采用，尤其在教育、营销和内容创作领域。建立一套可维护的成本感知路由层，已成为高效使用国产多模态模型的重要基础设施。

（本节约 380 字）

多参考融合与长视频的边界仍未收敛

目前管道中尚未完全解决多参考融合和长视频带来的复杂决策问题。

多参考融合在参考图片超过三张或语义冲突明显时，现有模型表现仍不稳定。路由管道虽然能根据图片数量选择合适模型，但无法准确预测最终融合质量。开发者通常只能设置保守规则，当参考图片较多时自动降低期望质量或增加后处理步骤。

长视频生成面临类似边界问题。当前多数模型在视频时长超过 10 秒后，一致性会显著下降。路由虽然能按时长选择不同模型，但对于用户要求的 30 秒以上视频，仍缺乏可靠的高质量选项。管道此时往往采取分段生成再合并的策略，但合并过程可能引入新的 artifact。

这些未收敛的场景表明，路由系统仍需持续演进。未来可能需要引入质量预测模型，在路由决策前先对生成结果进行预估，超出阈值则自动调整参数或切换模型。但目前这类预测模型本身成本较高，如何平衡预测开销与生成开销仍是开放问题。

尽管存在这些边界，当前的代码管道方案已能处理大部分日常生产需求。开发者通过持续收集失败案例并更新规则，路由系统的覆盖范围正在逐步扩大。

（本节约 320 字）

参考来源