LLM API 的备用路由：面向文本、图像、音频和视频的多模态代理路由

当每个请求都返回文本时，LLM API 的备用路由很直接。如果主路由超时，你重试一次，切换到备用模型，验证 schema，并记录原因。

但当同一个产品还要路由图像生成、音频转录、语音输出和视频生成时，这套逻辑就不成立了。对 JSON 抽取安全的备用方案，并不自动对品牌视觉素材安全。语音转文本的备用，与文本转语音的备用并不是一回事。视频备用可能会造成重复支出、队列混乱，或者生成一个仍然需要人工批准的输出。

本指南将 Fallback Routing for LLM APIs: Multimodal Agent Routing for Text, Image, Audio, and Video 转化为 AI 产品团队的实施手册。目标不是选择一个通用模型。目标是让你代理所接触的每一种模态，都有明确的路由选择、验证、备用机制和成本审查。

截至 2026 年 9 月 12 日，Flatkey 的公开页面将产品描述为围绕一个 key、一个 balance、一个 invoice、100+ 官方 AI 模型、1,000+ 工具、OpenAI 兼容设置、使用日志和自动故障切换。Flatkey 的公开模型和定价页面也展示了面向文本、图像、音频和视频的模型路由。在上线前，请将这些实时页面视为当前的商业检查点，因为模型可用性、价格和路由健康状况都可能变化。

快速回答：多模态备用路由有什么变化？

在仅文本系统中，备用机制通常只问一个问题："另一个路由能否生成等价答案？"

在多模态系统中，LLM API 的备用路由必须问四个问题：

1. 正在生成什么产物？ 文本、图像、音频和视频不共享同一套质量标准。
2. 如何验证该产物？ JSON 解析器、视觉审阅者、转录校验器和视频审批队列是不同的验证系统。
3. 真正可恢复的故障是什么？ 限流、超时、无效输入、安全拒绝和低质量输出需要不同的处理方式。
4. 备用方案能否保持合同不变？ 只有在保留模态、输出形态、延迟预算、成本上限和审查路径时，备用路由才是安全的。

实用规则很简单：除非人工或策略层明确批准迁移，否则备用机制应保持在同一工作流类别内。

为什么通用重试在文本、图像、音频和视频场景下会失效

通用重试会把每次失败请求都当作传输问题。这对于多模态代理路由来说过于浅薄。

路由器需要知道某个失败是可重试的服务事件、无效请求、安全或策略结果，还是质量未达标。这些类别会导向不同的操作。

从路由类别开始，而不是模型名称

LLM API 最安全的备用路由，应从路由类别开始。随着可用性和质量变化，模型可以进出某个类别；工作流策略应保持稳定。

这张路由类别映射表避免了一个常见错误：把“多模态模型”当作一个单一能力桶。一个能够接受图像进行分析的模型，并不一定能生成图像。一个能理解音频的模型，也并不自动就是可用于生产的语音模型。一个在演示中可以生成视频的模型，也并不自动适合面向客户的自动化场景。

在编写代码之前先使用备用决策矩阵

决策矩阵为产品、工程和运营提供一套共享策略。请从下面的矩阵开始，并用你自己的模型、提供商和审批规则替换示例。

这个矩阵是本文的核心价值资产。它把 LLM API 的备用路由从工程上的事后考虑，转变为一种可在生产流量转移之前进行审查的策略。

多模态代理路由的参考架构

生产级路由器不需要复杂，但它确实需要清晰的边界。

flowchart LR
    A[代理请求] --> B[分类工作流]
    B --> C[选择主路由]
    C --> D[调用提供商或网关]
    D --> E[验证产物]
    E -->|通过| F[返回并记录]
    E -->|可重试故障| G[备用策略]
    E -->|策略或无效输入| H[以可操作的错误停止]
    G --> I[批准的备用路由]
    I --> D
    G --> J[人工审核或人工队列]

关键部分包括：

• 工作流分类器： 在路由选择之前，将任务标记为文本、视觉、图像生成、音频输入、音频输出或视频生成。
• 能力注册表： 记录哪些路由支持每种模态、端点、输入格式、输出形态、最大上下文、流式行为和成本等级。
• 备用策略： 定义可重试错误、允许的备用项、绕过防护规则以及最大尝试次数。
• 验证层： 在将产物返回给用户或传递到下游之前对其进行检查。
• 账本与可观测性： 记录模型、路由、所有者、状态、备用原因、延迟、使用量、成本和审核结果。

当团队希望拥有一个 OpenAI 兼容路由器、一个共享余额，以及一个用于审查受支持模型路由的统一位置时，Flatkey 可以位于提供商或网关层。你的应用仍然负责策略：允许哪类模态进行备用、何时停止，以及何时应由人工决策。

将策略定义为数据

避免把路由策略分散在各个 if 语句中。一个小型数据对象更易于审查，也更安全地修改。

{
  "workflow": "support_ticket_with_screenshot",
  "route_class": "vision_understanding",
  "primary_model": "primary-vision-reasoning-route",
  "fallback_models": ["backup-vision-reasoning-route"],
  "fallback_on": ["timeout_before_output", "rate_limit", "upstream_5xx"],
  "do_not_fallback_on": ["safety_rejection", "invalid_input", "partial_stream_sent"],
  "verification": {
    "type": "structured_text",
    "required_fields": ["summary", "severity", "evidence"]
  },
  "max_attempts": 2,
  "max_incremental_cost_usd": 0.05,
  "log_fields": [
    "request_id",
    "workspace_id",
    "route_class",
    "model",
    "fallback_reason",
    "latency_ms",
    "cost_usd",
    "verification_status"
  ]
}

同样的结构也可以表示媒体工作流：

{
  "workflow": "product_video_preview",
  "route_class": "video_generation",
  "primary_model": "primary-video-route",
  "fallback_models": ["approved-video-preview-route"],
  "fallback_on": ["provider_5xx", "capacity_unavailable"],
  "do_not_fallback_on": ["client_timeout_without_task_state", "safety_rejection", "asset_created"],
  "verification": {
    "type": "human_review",
    "checks": ["duration", "motion", "brand_safety", "reference_consistency"]
  },
  "max_attempts": 1,
  "manual_queue_after_failure": true
}

请注意其中的差异：文本策略通常可以自动回退，因为结果可以由机器校验。视频策略则更为狭窄，因为第二次生成不仅仅是重试；它是另一份产物，也是另一笔成本事件。

按模态划分的回退规则

文本：保留响应契约

文本是最容易入手的地方，因为验证可以自动化。对于 LLM API 的备用路由，文本备份应当保留：

• endpoint 形态；
• 如果使用了流式传输，则保留 streaming event 形态；
• JSON 或结构化输出行为；
• tool-call 行为；
• 引用或检索要求；
• 延迟上限；
• 成本上限。

错误在于：从可预测的结构化输出路由回退到一个更具创造性的模型，虽然听起来更好，但会破坏下游解析。如果该路由服务于产品自动化，那么解析器稳定性比文风更重要。

视觉：将图像理解与图像生成分开

视觉任务通常会对图像输出文本。图像生成任务则会产出新的视觉工件。它们不应共享同一个回退桶。

OpenAI、Google Gemini 和 Anthropic 都记录了图像理解或图像相关的 API 能力，但这些文档描述的是不同的请求表面和模型行为。对于多模态代理路由，策略问题并不只是“这个路由能处理图像吗？”而是“这个路由能否以相同的输入约束和输出契约处理这项图像任务？”

例如，截图分流工作流可能需要一个具备视觉能力的推理路由，并返回结构化文本。品牌创意工作流则需要一个图像生成路由，返回文件并通过视觉审查。这些是不同的 route class。

图像生成：不要绕过创意审查

图像回退应当保护创意契约：

• 宽高比；
• 分辨率或尺寸等级；
• 编辑还是全新生成；
• prompt-template 兼容性；
• 品牌与合规审查；
• 存储与资产生命周期；
• 每个被接受资产的成本。

如果主图像路由因为输入无效而失败，那么回退就是错误做法。应当修正请求。如果它因为服务提供商在任何资产创建之前暂时不可用而失败，那么在备用路由已经通过视觉 QA 的情况下，回退可能是合理的。

音频：将转写、理解与语音分开

音频路由通常隐藏着三项不同的任务：

• 语音转文本：将音频转换为转录文本。
• 音频理解：对音频内容、说话人意图或会议上下文进行推理。
• 文本转语音：生成口语化输出。

这些任务有不同的失败模式。转录路由可以通过词错误率、领域词汇、说话人标签、时间戳和延迟来评估。语音路由则通过声音质量、发音、延迟、允许的声音策略以及播放体验来评估。

备用应当保持在特定的音频任务类型内部。不要把“支持音频”作为单一策略标签。

视频：将备用视为另一种生产事件

视频通常是自动备用中风险最高的模态，因为一次失败或缓慢的请求可能已经在提供方侧创建了一个任务。在创建另一个任务之前，你的系统应当知道：

• 原始任务是否存在；
• 它是排队中、处理中、已成功、已失败还是已过期；
• 是否已创建输出 URL；
• 是否记录了任何用量或成本；
• 是否已有审阅者看过该资产；
• 第二次生成是否会违反预算或审批流程。

对于视频生成，一个安全的默认做法是：仅在任务尚不存在之前重试传输；轮询现有任务直到终态；然后使用人工或严格批准的重新生成路径。

备用发生时记录什么

日志中不可见的备用将变得无法改进。至少，每个请求都应记录：

对于 AI 产品团队来说，最有用的指标通常不是原始可用性，而是备用后的已接受输出率。一个返回很快但产生被拒绝资产的备用路由，从产品角度看并不可靠。

Flatkey 的作用

Flatkey 与 LLM API 的备用路由相关，因为运营层面的痛点远不止一次 API 调用。多模态产品往往会积累特定提供方的密钥、直接计费账户、分散的模型 ID、不一致的错误处理，以及用于文本、图像、音频和视频实验的独立仪表板。

Flatkey 的公开文档和网站为团队提供了一个与 OpenAI 兼容的路由 URL，用于受支持的模型调用、模型目录、使用日志、统一余额和统一发票界面。该实时网站还将可靠性框定为自动故障转移以及公开的状态/SLA 界面。这并不意味着你不再需要自己的模态策略，而是让这项策略有一个统一的执行位置，而不是把路由选择分散在特性代码中。

在以下情况下使用 Flatkey：

• 在比较受支持的模型路由时，只需要一个路由端点；
• 只需要一个地方查看模型可用性和商业上下文；
• 只需要一个余额和一张发票，而不是分散的提供商账户；
• 需要模型、token、成本、延迟和所有者审查的使用日志；
• 随着更多代理和工作流采用 AI API，需要进行路由治理。

如果只有单一提供商是唯一需求、工作负载不需要备用路由，而且最简单的供应商路径比跨模型控制更重要，那么就直接使用提供商账户。

LLM API 备用路由的上线检查清单

在多模态产品中启用自动备用路由之前，请完成以下检查清单：

1. 盘点模态。 列出所有会生成文本、分析图像、生成图像、接收音频、进行语音输出或生成视频的工作流。
2. 分配路由类别。 不要让一个“多模态”标签覆盖不同的工件类型。
3. 定义验证。 在可以信任备用路由之前，每个路由类别都需要一种通过/失败的方法。
4. 将重试与备用路由分开。 重试会重复同一路由。备用路由会切换路由。重新生成会创建一个新的工件。
5. 编写防绕过规则。 安全拒绝、无效输入、副作用以及可见的部分输出不应静默切换到备用路由。
6. 设置成本上限。 即使备用路由挽救了请求，但如果突破预算，对产品而言仍然算失败。
7. 记录路由决策。 存储主路由、最终路由、失败原因、成本、延迟和验证结果。
8. 测试故障注入。 模拟超时、速率限制、5xx 错误、无效输入、解析器失败、被拒绝的图像、错误的转录和缓慢的视频任务。
9. 从一个低风险工作流开始。 不要一次性在整个产品中打开跨模态备用路由。
10. 每周审查可接受输出率。 优化可用结果，而不仅仅是成功的 HTTP 响应。

这就是 LLM API 的可靠备用路由与跨不兼容路由的盲目重试之间的区别。

常见问题

什么是 LLM API 的备用路由？

LLM API 的备用路由是一种策略，用来决定当某条模型路由失败、降级或不可用时，应该重试、切换到已批准的备份、以可操作的错误停止，还是转交人工审核。

为什么多模态代理路由比纯文本路由更难？

多模态代理路由更难，是因为文本、图像、音频和视频输出具有不同的验证方法、成本曲线、延迟预期和审核风险。一个通用的备用规则无法安全地覆盖这四种情况。

一个 API 网关能处理文本、图像、音频和视频吗？

是的，一个网关可以集中管理所有支持路由的访问和使用审查。应用程序仍然需要为每种模态和工作流分别设置路由类和备用策略。

何时应该自动回退？

当输出契约可以被机器检查、备用路由已经经过测试、没有任何部分输出到达用户、没有不确定的副作用，并且备用方案仍在延迟和成本限制内时，自动回退最安全。

何时应该保持手动回退？

当产物需要主观审查、请求可能已经产生副作用、重复工作的成本很高，或者发生了策略/安全拒绝时，回退应保持手动。视频生成和对品牌敏感的图像生成通常属于这一类。

重试和回退是一回事吗？

不是。重试是将同一个请求再次发送到同一条路由。回退则会切换路由。重新生成会创建一个新的产物。应将它们视为不同的策略动作，因为它们在成本和质量方面的影响不同。

团队应该如何衡量回退质量？

衡量成功率、回退率、延迟、增量成本、解析器失败率、审查者接受率、回退后的拒绝输出率，以及回退后的接受输出率。HTTP 200 只是衡量的起点。

在下一次模型变更之前构建路由策略

为 LLM API 形式化回退路由的最有力原因是：模型接入变化的速度快于应用架构。新的文本、图像、音频和视频路由会不断上线。有些会消失、变慢、改价，或者在负载下表现不同。

如果你的产品具有路由类、验证规则、成本上限和可观测的回退决策，那么添加或移除一个模型就只是一次受控的策略更新。如果你的路由逻辑隐藏在功能代码中，每一次模型变更都会变成迁移风险。

从一个封闭的工作流开始，定义其模态和验证类别，测试已批准的备用方案，然后逐步扩展。当你准备好在所有支持的路由之间集中管理访问和计费时，请使用 Flatkey API 快速入门，查看 统一 AI API 工作流，并在 Flatkey 模型目录 中比较当前模型可用性。