X

重点摘要

仅对逾时与 429 回应等暂时性失败重试同一路由。

切换到符合相同能力与输出合约要求的模型。

为整个请求设置最高成本与延迟预算，而不是为每次尝试各自设置。

为每个请求记录供应商、模型、错误类型、重试次数与最终路由。

将 retry 与 fallback 分开

retry 会将请求再次送往同一路由，因为失败可能只是暂时性的。fallback 则会更换供应商或模型，因为原始路由不可用或不适合。

把两者当成单一的通用重试循环，会让事件更难诊断，也可能在不提升成功率的情况下成倍增加成本。

retry: 超时、连接重置、429 或暂时性的 5xx 响应。
fallback: 供应商反复失败、模型容量问题或政策限制。
停止: 无效请求、不支持的参数或输出验证失败。

创建能力兼容的路由表

fallback 模型应依能力而非品牌分组。视觉请求不能 fallback 到仅支持文字的模型，而严格的 JSON 工作流程也不应路由到经常违反 schema 的模型。

必要的输入与输出模态。
最小上下文与输出长度。
工具调用与结构化输出支持。
可接受的最高价格与延迟。

套用单一请求层级预算

请求预算应涵盖所有 retry 与 fallback 尝试。在开始下一次尝试之前，先检查剩余的延迟与成本预算是否足以支持。

const routePolicy = {
  maxAttempts: 3,
  maxLatencyMs: 18_000,
  maxEstimatedCost: 0.12,
  retryOn: [408, 429, 500, 502, 503, 504],
  fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};

衡量 fallback 质量，而不只是可用性

即使请求成功回传，也可能代表产品失败。请在 fallback 事件后追踪输出验证、用户修正率与任务完成情况。

建议仪表板：路由成功率、fallback 率、p95 延迟、预估成本、验证通过率，以及依模型区分的质量分数。

常见问题

每个失败的 AI 请求都应使用 fallback 模型吗？

不应该。无效参数、不支持的输入与失败的安全检查应立即停止。只有在另一条兼容路由有现实可能完成相同任务时，fallback 才合适。

一个 AI 请求应允许多少次 fallback 尝试？

多数互动式工作流程应将总尝试次数控制在两到三次。正确上限取决于剩余延迟预算、任务价值与预估成本。