AI价格战重塑软件架构：按任务难度分配模型层级

大家关注 AI 价格战的原因都错了。标题党们在说 token 变得多么便宜。真正值得关注的，是便宜的 token 会对当下的软件架构方式产生什么影响。

变化已经发生，而这比价格下调本身更重要。

模型不再是单一形态，而是分出了层级

主流实验室已经悄悄将产品线分成了不同层级。简单任务用廉价快速的模型，复杂问题用昂贵的高推理能力模型。这不是定价噱头，而是架构信号。如果你的应用无论难度如何都把每个请求发给同一个模型，那你不是在简单任务上多花钱，就是在复杂任务上能力不足。

值得采用的模式：按任务路由，而不是按应用路由。

function routeModel(task) {
  if (task.type === 'classification' || task.type === 'extraction') {
    return 'cheap-tier-model';
  }
  if (task.type === 'reasoning' || task.type === 'multi-step-planning') {
    return 'frontier-tier-model';
  }
  return 'mid-tier-model';
}

思路简单。但实际上几乎没有任何人的代码库真正实现了这个。一年前，当各层级之间的价格差距还很小时，应用全部硬编码使用同一个模型还算合理。现在差距已经不小了。

长上下文窗口正在淘汰简单 RAG

多个前沿模型现在已经配备了百万 token 级别的上下文窗口。一年前，检索增强生成（RAG）之所以存在，主要是因为没有别的选择——你没法在窗口里塞下足够的上下文，所以只能分块、嵌入、检索。这个约束正在快速消失，适用于很多使用场景。

这不意味着 RAG 消亡了。它意味着"何时真正需要 RAG"这个决策现在需要更加审慎。如果你的数据集能放进上下文窗口，那么向量数据库可能正在解决一个你已经不再拥有的问题。

没有人把监管因素纳入预算

当价格战吸引所有目光的同时，欧盟 AI 法案的高风险条款本月开始正式生效。透明度规则要求聊天机器人必须声明自己是 AI，合成媒体需要附带标签。如果你要向欧盟市场推送任何 AI 相关产品，这不再是可选项——我敢打赌，大多数个人项目和相当一部分生产应用都还没合规。

一年前，有趣的 AI 工程问题是"选哪个模型"。现在的问题是"哪个模型、用于哪个任务、花多少成本、在什么规则下"。这和大多数教程仍在教的东西相比，是截然不同的架构问题。

有没有人实际上在生产环境中做了分层模型路由，还是说大家仍然在每个应用里硬编码一个模型？好奇大家实际上在这方面是领先还是落后于同行。