从单一昂贵模型迁移到任务路由 + LLM fallback 的经验

我是用一种很笨的方式学会这个道理的。

我的自动化架构画在图上很干净，上线之后却一团糟：

一个巨大的假设："最强"的模型在任何负载下都是最强的

大概有一周时间，感觉还挺聪明。

然后怪事就开始了。

一个规划步骤变慢了。一个提取步骤原本无聊又稳定，结果开始超时了。一个审核步骤在我需要它保守行事的时候，开始返回完美流畅但毫无意义的废话。

没有一样东西是完全坏掉的——这种状态反而更让人头疼。

真正的升级不是换一个更贵的模型。

更准确地说：按任务分配模型，外加只在真正有帮助时才触发降级。

错误：用一个大聪明处理所有工作

很多人第一步都这样做。

我们找到一个信任的模型——GPT-5.4、Claude Opus 4.6、Grok 4.20，随便哪个——然后把所有请求都发过去：

// 别这样做
const response = await openai.chat.completions.create({
  model: "gpt-5.4",
  messages: [{ role: "user", content: userInput }]
})

在"app"实际上是 5 个不同工作负载伪装成一个的时候，这看起来很优雅，直到你发现不对劲。

我是这样想的：

一个模型处理所有任务
  ↓ 拆分 ↓
每个任务用专用模型
  + 按需配置 fallback

一旦我按这种方式拆分了工作流，架构变丑了，结果却变好了。

这个交换完全值得。

什么会在生产环境先出问题

通常不是智能水平。

最先出问题的是：

这就是为什么路由基础设施比跑分截图更重要。

如果你的 n8n 流程在凌晨 2 点处理发票，它不会在乎谁在 X 上赢得了精心挑选的推理测试。

• 请求是否顺利发出
• 提供商是否在限流
• 降级后的模型是否还支持你的 schema
• 账单是否保持可预期

OpenRouter 让我重新思考故障切换

OpenRouter 已经做了提供商路由和跨提供商负载均衡，这比听起来更有用。

有趣的地方在于：你可以在保持 OpenAI 风格请求格式的同时，在其下方添加路由控制。

{
  "model": "openai/gpt-4o",
  "messages": [
    {"role": "user", "content": "Summarize this invoice"}
  ],
  "provider": {
    "order": ["openai", "anthropic"],
    "allow_fallbacks": true,
    "sort": "price"
  }
}

这是请求体的一个小改动。

从运维角度看，这却是一个大改动。

这就是无聊的基础设施。

当日复一日运行的 agents 时，无聊的基础设施恰恰是你想要的。

真正的诀窍：按任务定制的 fallback

我犯的错误是把 fallback 当成一个巨大的紧急开关。

// 别这样做
{
  "model": "gpt-5.4",
  "fallback": {
    "provider": "B",
    "trigger": "any_error"  // 太宽泛了
  }
}

更好的模式是按任务定制 fallback：

• 规划任务的 fallback 是一种方式
• 提取任务的 fallback 是另一种方式
• 审核任务可能根本不需要 fallback

这个设计合理得多。

规划任务的 fallback 应该切换到强兼容的模型

规划任务我最在意的是：

• 工具调用兼容性
• 不要出现创意性的奇怪行为

如果 GPT-5.4 是你的主要规划模型，Claude 作为备份可以工作。

但前提是你的工具 schema、输出期望和 token 限制都能对上。

否则 fallback 会在 agent 静默选错分支的那一刻"看起来工作正常"。

这是最糟糕的一种失败。

提取任务只在真正的提供商问题时才 fallback

这是 Portkey 真正实用的地方。

Portkey 允许你定义 fallback 链，并且只在特定状态码（如 429 或 503）时触发。

这比在任意错误时都重新路由好得多。

{
  "strategy": {
    "mode": "fallback",
    "on_status_codes": [429, 503]
  },
  "targets": [
    {"provider": "@openai-prod"},
    {"provider": "@azure-prod"}
  ]
}

保持主要提取路径稳定，只在提供商限流或不可用时才降级。这正是我在生产环境想要的行为。

审核任务要严格，不要花哨

审核任务容易产生昂贵的错误。

审核不需要最耀眼的模型。

你需要的是：

• 愿意说"不合格"
• 不热衷于重写答案

如果你的审核层变得太花哨，它就不再做判断，而是开始即兴发挥了。

钱到底花在哪里了

到这里，路由就不再是架构讨论，而是账单讨论了。

模型定价仍然相差数倍，而不是一点点百分比。

对于不紧急的工作，Google 的 Gemini 3.7 Flash Batch API 是最清晰的例子之一。批量定价比标准路径便宜 50%。

这使它非常适合：

• 重新处理旧任务
• 批量数据丰富
• 任何不需要即时延迟的工作

如果工作不需要即时延迟，它可能根本不应该跑在最贵的实时路径上。

我一直在用 luxury 模型的价格做流水线工作。

我希望一开始就有的架构

现在我会推荐这样的路由设置：

按任务路由
  ├── 规划 → GPT-5.4 + Claude Opus 4.6 fallback
  ├── 提取 → Gemini 3.7 Flash + GPT-5.4-mini fallback
  └── 审核 → Claude Opus 4.6（无 fallback）

主流工具到需求的映射是这样的：

• OpenRouter → 跨提供商路由 + 负载均衡
• Portkey → 状态码触发的 fallback 链
• Standard Compute → 扁平月费套餐
• Gemini Batch API → 非紧急工作的批量路径

最后一个类别比大家承认的重要得多。

很多团队最终确实搭建了更好的路由，然后迎面撞上下一个问题：

"酷，系统现在更可靠了。为什么账单还是一团乱？"

这就是固定费率计算变得有趣的地方。

如果你在 n8n、Make、Zapier、OpenClaw 或自定义 workers 中全天候运行 agents，按 token 定价会把每次路由改进都变成财务对话。

Standard Compute 有意思的地方在于：它保持了 OpenAI 兼容的接口，但消除了持续不断的 token 计算。对于 agent 密集型工作负载，这是真正的运维优势。

是的，更多路由可能制造调试噩梦

如果一个请求可能命中多个提供商和多个模型，调试就变得更难。

延迟变得更难分析。

开销变得更难分析。

输出漂移变得更难分析。

所以不要随意搭建 fallback。

我现在遵循的规则：

1. 只在工作流能容忍模型差异的地方添加 fallback
2. 根据特定条件触发 fallback，而不是模糊的"不满意"
3. 记录每个步骤的最终提供商和模型
4. 保持主路径和备份路径的 prompt 和 schema 兼容
5. 只对真正不紧急的工作使用批量路径

如果跳过这些规则，fallback 路由就会变成鬼屋。

请求成功了，但是：

• 延迟尖峰此起彼伏
• 成本模型变得奇怪
• 没人知道到底发生了什么

不是所有备份都是安全的备份

这是很多路由建议过于随意的地方。

备份模型在技术上可以成功，但仍然会破坏工作流。

可能差异大到影响结果的事情：

• JSON / schema 行为
• 保留或合规约束
• 系统提示词大小
• 工具调用格式

这就是为什么我怀疑有人声称找到了每个任务的通用替代品。

对于狭窄的路径，也许可以。

对于真正的 agent，有多个故障模式……你需要分别测试每个步骤。

一个实用的 Python 示意

如果你在构建自己的 worker，最简单的模式是在考虑花哨编排之前先按任务路由。

TASK_MODELS = {
    "planning": "gpt-5.4",
    "extraction": "gemini-3.7-flash",
    "review": "claude-opus-4.6"
}

TASK_FALLBACKS = {
    "planning": ["claude-opus-4.6"],
    "extraction": ["gpt-5.4-mini"],
    "review": []
}

def pick_model(task_name: str):
    return TASK_MODELS[task_name], TASK_FALLBACKS.get(task_name, [])

然后记录每个决策：

import time

def run_step(task_name, payload):
    primary, fallbacks = pick_model(task_name)
    started = time.time()

    try:
        result = call_llm(primary, payload)
        log_event(task=task_name, model=primary, fallback_used=False, latency_ms=int((time.time() - started) * 1000))
        return result
    except RateLimitError:
        for model in fallbacks:
            try:
                result = call_llm(model, payload)
                log_event(task=task_name, model=model, fallback_used=True, latency_ms=int((time.time() - started) * 1000))
                return result
            except Exception:
                continue
        raise

这不炫酷。

但这种代码比"把所有请求都发给最聪明的模型"更能经受住生产环境的考验。

如果你用 OpenAI 兼容的 SDK，保持集成简单

这是另一个教训。

你不需要重写整个应用才能获得更好的路由。

如果你的技术栈已经用 OpenAI API，你通常只需更换 base URL 就能继续。

pip install openai

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.standardcompute.com/v1"
)

resp = client.chat.completions.create(
    model="gpt-5.4",
    messages=[
        {"role": "user", "content": "Extract invoice number and total as JSON"}
    ]
)

print(resp.choices[0].message.content)

这对自动化团队很重要。

如果你已经在 n8n、Make、Zapier 或自定义 Python workers 中运行流程，最好的基础设施升级通常是不强制重写的那种。

我现在会推荐的实际设置

如果我现在重建一个 agent 架构，我会这样做：

1. 按任务选主要模型，不是按应用选

规划任务用最强的模型。

如果需要的话，审核任务用一个。

2. 只在失败代价高的地方加 fallback

如果规划失误可以毁掉整个运行，就给它一个强力的备份。

如果提取失败重试成本低，就保持简单。

3. 用路由基础设施，而不是重写应用

OpenRouter 和 Portkey 都允许你在 OpenAI 风格接口之下添加弹性。

这是通往可靠性最快的路径。

4. 把重复的异步工作推到批量定价

便宜的批量路径不激动人心，但对账单影响很大。

5. 可靠性之后再解决成本可预测性

一旦 agents 全天候运行，按 token 计费本身就变成了运维问题。

如果你想要一个即插即用的 OpenAI 兼容路径加固定月费定价，Standard Compute 值得关注。它正好适合这样的场景：团队厌倦了在自动化持续运行时盯着 token 消耗。

结论

我一开始以为自己需要一个最好的模型。

我真正需要的是一个能扛住以下问题的架构：

• 随机模型抽风
• 始终走高端路径导致的成本漂移

用一个大贵模型处理所有事情看起来很高级。

按任务路由看起来很无聊。

但无聊的架构才能在生产环境存活。