推理路由就是架构：把每个请求交给「够用且最便宜」的模型

如果要给 2026 年的企业 AI 成本下一句结论，HPCwire 在 8 月的这篇分析给了很好的措辞：成本问题不是训练预算，也不是哪个前沿模型在最新榜单上排第一，而是推理——更具体地说，是路由。也就是「把每个请求匹配给能处理它的最便宜模型」，并调好「什么时候该多花钱」的那个阈值。同一篇文章里还有一句值得贴到墙上：一个 AI 系统的成本由其架构决定，而不是由发票上的模型决定。这一点在 2026 年的价格表上尤其明显——不同档位模型的价格横跨两个数量级。把路由当作一等基础设施来建、像衡量其它东西一样去衡量它，账单就会从一个谜团变成一项设计决策。

一、账单其实是一串路由决策的结果

同一个问题，交给便宜模型可能只花几分钱，交给前沿模型可能要花上几十倍。如果所有请求都走同一个最贵的模型，那么「省钱」这件事就完全没有发生——因为从未有人问过「这个请求真的需要那个模型吗」。HPCwire 的框架把路由放在核心：匹配请求与模型能力，然后调优阈值，决定何时升级。CloudZero 与 Wavect 的分析同样指出，真正的成本驱动因素往往更细——上下文长度、缓存命中、重试、输出长度——而这些恰恰是路由层能够影响的东西。结论很朴素：想控成本，先让每个请求都走它「配得上」的模型。

// Route to the cheapest model that can actually do the job, then escalate
// only when a cheap attempt fails a check you trust.
type Tier = { model: string; usdPerMTokIn: number; usdPerMTokOut: number };

const TIERS: Tier[] = [
  { model: "budget-flash-lite", usdPerMTokIn: 0.10, usdPerMTokOut: 0.40 },
  { model: "mid-sonnet",       usdPerMTokIn: 2.00, usdPerMTokOut: 10.00 },
  { model: "frontier-fable",   usdPerMTokIn: 10.00, usdPerMTokOut: 50.00 },
];

export async function answer(prompt: string) {
  for (const tier of TIERS) {
    const out = await call(tier.model, prompt);
    const verdict = await check(out);
    metrics.record(tier.model, verdict, out);
    if (verdict.passed) return { text: out, tier: tier.model };
  }
  throw new Error("no tier passed checks");
}

成本不是模型决定的，是架构决定的

二、两张表解释了一切：价格与质量

第一张是价格表。2026 年的公开定价里，廉价档位的输入价格可以低到每百万 token 几毛钱，而前沿档位是每百万 token 十美元级别——输入价格横跨约两个数量级，输出价格差距同样巨大。第二张是质量表。便宜模型在某些任务上确实够用，而另一些任务上会失败。路由要做的，就是把这两张表对起来：对多数请求走廉价档，对需要它的少数请求升级。这里最容易犯的错是只看价格不看质量——一个便宜但总失败的请求，最终会因为重试而变得更贵。路由的目标不是最低单价，而是最低「每次成功」的成本。

// Cost per request, not cost per month. If you cannot attribute spend to a
// request, you cannot route it - you can only hope.
function charge(
  req: { id: string },
  usage: { input: number; output: number },
  tier: Tier,
) {
  const usd = (usage.input / 1e6) * tier.usdPerMTokIn
            + (usage.output / 1e6) * tier.usdPerMTokOut;
  db.requests.update(req.id, { $set: { model: tier.model, usd } });
  return usd;
}

三、级联与阈值：把「够用」变成可判定

级联（cascade）是路由最常见的形式：先用最便宜的模型试，若输出通过了你信任的检查，就采用；不通过则升级到下一档。这套机制的成败全在「检查」上——如果你的检查太松，错误会漏过去；太严，则几乎所有请求都会升级，便宜档位形同虚设。因此检查项应该是与任务强相关的硬约束：结构是否符合 schema、是否泄漏了 PII、是否引用了给定的上下文、长度是否在范围内。还有一个常被忽略的前提：换模型版本时要重跑评测集，因为针对某个模型失败模式调的阈值，未必能迁移到另一个模型。

// The cheapest token is the one you never send. Cache exact and fuzzy hits.
const key = hash(normalize(prompt));
const hit = await cache.get(key);
if (hit) return { text: hit, tier: "cache" };

// Normalize before hashing: whitespace and casing are formatting, not intent.
function normalize(s: string) {
  return s.trim().replace(/\s+/g, " ").toLowerCase();
}

每一行一个档位：量、花费、通过率

四、先量化，再路由：三个必须测量的量

没有测量就没有路由。至少要能回答三个问题：第一，每个请求花了多少钱——按请求记账，而不是按月汇总。第二，每个档位的通过率是多少——便宜档通过率太低，说明阈值或提示词有问题。第三，缓存与去重的命中率——最便宜的 token 永远是你从未发出的那个。把这三件事做起来，路由就不再是感觉，而是数据。顺带一提，把「上下文长度」也纳入观察：很长的上下文往往意味着更贵，而很多长上下文其实是历史对话的重复累积，压缩它比换模型更省钱。

// A router is only as good as its checks. Score every cheap attempt, and
// re-run the eval set whenever a model version changes underneath you.
const CHECKS = [schemaValid, noPii, groundedInContext, withinLength];

function passesAll(out: string) {
  return CHECKS.every((c) => c(out));
}
// A threshold tuned for one model's failure modes will not transfer to
// another model's. Treat routing like a model swap with a regression suite.

五、落地代码：从级联到报表

第一段是级联路由器：按档位从便宜到贵依次尝试，任何一档通过检查就返回，全部失败才报错。第二段按请求记账，把 token 与单价折算成美元记到请求上。第三段是缓存与归一化：命中缓存直接返回，归一化后再哈希，因为空白与大小写是格式而非意图。第四段是质量门禁，把检查项固定成一组函数，并在模型版本变化时重跑评测。第五段导出按档位聚合的报表：每个档位的请求量、花费与通过率——然后拿去对照阈值调优。

// Export spend and quality by tier on a schedule. Routing is an experiment,
// so log the outcome instead of trusting the intuition that started it.
const rows = await db.requests.aggregate([
  { $group: {
      _id: "$model",
      usd: { $sum: "$usd" },
      n: { $sum: 1 },
      passRate: { $avg: "$passed" },
  } },
]);

await exportCsv("routing-report.csv", rows);

最便宜的 token，是你从未发出的那个

六、清单：把路由当成产品能力来经营

五个检查项。第一，你能不能算出单个请求的花费？第二，你知道每个档位的通过率吗？第三，缓存与去重的命中率是多少？第四，换模型版本时会不会重跑评测集？第五，你有没有按固定节奏导出「按档位」的花费与质量报表？这五项里，第二项最容易被忽略，却最致命——一个廉价档位如果通过率只有一半，它非但不省钱，还会因为升级与重试把钱花在两次调用上。路由的真正目标从来不是「用最便宜的模型」，而是「用最少的钱拿到可信的结果」。