AI调用也要做‘调度优化’：模型路由如何重塑成本与性能

llm infrastructure optimization agents cost-efficiency

AI调用也要做“调度优化”：模型路由如何重塑成本与性能

在过去一年里，大模型应用的成本问题逐渐从“隐性预算项”变成了工程团队绕不开的核心约束。当一个团队从原型走向生产系统，最先爆炸的往往不是算力，而是 API 账单。于是，一个看似“二级基础设施”的方向开始变得显眼：模型路由（Model Routing）——让系统在不同任务之间自动选择合适的 LLM。

最近 Hacker News 上一个关于“智能模型路由接入 Claude / Codex / Cursor”的项目讨论热度很高[1]，背后其实折射出一个更大的变化：AI 应用正在从“单一模型调用”走向“多模型调度系统”。

从“一个大模型解决一切”到“多模型协同”

为什么单模型架构开始失效

早期 LLM 应用很简单：选一个最强模型，把所有请求都丢进去。但现实很快给出了反馈：

  • 简单任务（摘要、格式转换）用旗舰模型过于昂贵
  • 复杂任务（架构推理、调试）小模型容易失败
  • agent 系统中调用次数指数增长

尤其是在 coding agent 场景中，一个请求往往会拆成：

  • 规划（Planning）
  • 检索代码上下文（Retrieval）
  • 执行修改（Execution）
  • 代码审查（Review）

每一步对模型能力要求完全不同。如果全用同一个模型，本质上是在用“最贵配置跑全流程”。

这也是为什么该项目作者提到，他们在使用 Opus 4.7 后由于 tokenizer 变化导致成本飙升，最终选择构建路由系统来“按需分配模型能力”[1]。

模型路由系统在做什么？

核心思想：给 LLM 调度加一层“控制器”

该 Hacker News 项目实现了一个类似“AI API 代理层”的系统，它会：

  • 接收所有模型请求
  • 判断任务复杂度
  • 选择合适模型（便宜 / 快 / 强）
  • 转换请求格式并转发

例如：

  • 简单代码生成 → DeepSeek / GLM 这类低成本模型
  • 复杂规划任务 → Claude Opus 或 GPT 前沿模型
  • 子 agent 探索代码 → 快速模型
  • 最终执行 patch → 中等能力模型

更关键的是，他们不是简单规则判断，而是用了基于 agent traces 的强化学习（RL）模型来学习路由策略[1]。

RL 路由的本质：学习“任务→模型”的映射

训练数据来自大量 agent 行为轨迹：

  • 输入：任务 + 上下文
  • 输出：选择哪个模型 + 是否成功完成任务

奖励函数很直接：

选对模型并完成任务 → 正奖励
失败或成本过高 → 负奖励

从系统设计角度看，这相当于把“模型选择”变成一个可学习的决策问题，而不是工程师手写规则。

为什么这个话题在社区爆火？

1. 成本焦虑已经成为开发者共识

评论区中最典型的反馈之一是：

“API rate cost has really become an issue”[1]

这句话几乎代表了当前 AI 工程的普遍状态——不是“有没有能力”，而是“是否付得起”。

模型路由的吸引力就在于它直接回应了一个非常现实的问题：
如何在不牺牲能力的情况下，把成本降低 20%～60%？

2. Agent 架构让“调用次数”失控增长

在 agent 系统里，一个用户请求可能触发几十甚至上百次 LLM 调用。

于是问题从：

“选哪个模型最好？”

变成：

“每一步是否都值得用同一个模型？”

评论中有人指出，现代 coding agent 已经“自己会分层选择模型”[1]：

  • exploration → 小模型
  • planning → 大模型
  • implementation → 中等模型

这实际上意味着：模型路由能力已经内生于 agent，但仍未标准化。

3. 一个关键争议：外置路由 vs 内置智能

讨论中有一个非常核心的分歧：

外部路由（proxy model）

优点：

  • 统一控制成本
  • 易部署
  • 可观测

缺点：

  • 破坏缓存机制（cache miss）
  • 破坏 agent 的反馈闭环
  • 缺少运行时上下文（例如刚刚失败的调用）

内部路由（agent 自主决策）

优点：

  • 拥有完整上下文
  • 可动态调整策略
  • 更贴近任务语义

缺点：

  • 成本不可控
  • 难以全局优化

评论中有人直接指出：

“Changing mid-flight is costly”[1]

这句话其实点出了一个系统性矛盾：
路由发生在“系统层”还是“模型层”？

被忽视但关键的问题：缓存与状态

prompt cache 是模型路由的隐形约束

在很多生产系统中，prompt caching 是降低成本的核心手段。但路由系统可能破坏这一机制：

  • 不同模型 → cache 不共享
  • 路由切换 → cache miss 增加
  • agent 重建上下文 → token 成本上升

有评论明确指出这一点：

“proxy model blows that up”[1]

换句话说：

路由节省的成本，可能被 cache 损失抵消。

这是当前很多模型路由系统尚未完全解决的问题。

更深一层：模型路由其实是在做“计算资源编排”

如果从基础设施视角看，模型路由并不只是 LLM 优化，而是：

把“智能计算”变成可调度资源

类似于：

  • CPU scheduler（进程调度）
  • Kubernetes（容器调度）
  • CDN（请求分发）

不同之处在于：

  • 调度对象不再是“算力”
  • 而是“不同能力层级的智能模型”

对开发者意味着什么？

1. 应用架构会变成“多模型系统设计”

未来的 AI 应用可能默认包含：

  • routing layer（模型选择）
  • caching layer（上下文复用）
  • fallback layer（失败恢复）
  • evaluation layer（质量监控）

开发者不再只是“调用 API”，而是在设计一个模型协作系统。

2. “选模型”会变成基础能力

就像现在没人手动选择 CPU core 一样：

  • 开发者不会直接选模型
  • 系统会自动分配模型能力

这也意味着一个趋势：

LLM API 将从“函数调用”变成“智能调度接口”

3. 评估体系会成为核心竞争力

评论中有人建议：

用 terminalbench / deepswe bench 来验证成本与性能收益[1]

这其实指向一个关键点：

没有统一 eval，路由优化无法验证价值。

未来可能出现：

  • routing benchmark
  • cost-performance curve
  • per-task routing accuracy

总结：从“模型时代”走向“调度时代”

模型路由的意义不只是省钱，而是一个更底层的变化：

LLM 应用正在从“单模型智能”进入“多模型系统工程”。

Hacker News 上的讨论之所以激烈，并不是因为这个项目本身多新，而是它击中了一个正在发生的结构性转变：

  • 模型越来越多
  • 能力差异越来越大
  • 成本差距越来越显著
  • agent 调用越来越频繁

当这些条件同时成立，“如何选模型”就不再是优化问题，而是架构问题。

未来真正重要的能力，可能不再是“用好某一个模型”，而是：

如何让一群模型协同工作，并且在成本与性能之间持续找到最优点。

参考

[1] Hacker News: Show HN – Smart model routing directly in Claude, Codex and Cursor
https://news.ycombinator.com/item?id=48688700
https://github.com/workweave/router