Node.js多模型路由实战：成本直降60%的智能调度方案

过去半年，我一直在折腾一件事：在不牺牲响应质量和用户体验的前提下，把每月的模型账单压下来。最开始接入大模型那会儿，团队所有请求都打到一个最强模型上，业务方倒是开心了，可月底对账的时候，数字让我有点坐不住——翻译一句"你好"、抽几个关键词、给评论打个情感标签，这些轻量任务和复杂推理任务一样，按最高档价格走了一遍完整链路，成本高得离谱。

后来我把目光投向"多模型路由"：让 Node.js 服务在收到请求时，根据成本预算、延迟敏感度和任务类型，自动决定把这一次调用交给哪个模型。方案落地后，月度模型成本降了大约 60%，平均响应时间也稳住了。这篇文章不是泛泛讲概念，而是把我在生产环境里真正跑通的完整设计、核心代码和踩坑经验整理出来。如果你正在用 Node.js 接入多个大模型，或者被"贵模型太贵、便宜模型不靠谱"这种两难处境卡住，这篇应该能给你一个可落地的参考答案。

1. 一条消息应该花多少钱？多模型路由要解决的实际问题

1.1 单一模型架构的三大死穴

先说清楚我为什么非要做路由。早期我们系统里所有 LLM 请求都走同一个高端模型，一开始接入简单，但随着调用量涨上来，问题就暴露得很明显。

第一大死穴是成本失控。高端模型和入门模型的价格可能差 10 倍甚至 20 倍，但对简单任务来说，两者的输出质量可能根本没差别。每天几百万次调用，哪怕只有 20% 是"杀鸡用牛刀"，月底账单也是肉眼可见地膨胀。第二个死穴是延迟不可控。高端模型因为参数量大、推理负载高，首 token 延迟普遍比轻量模型高不少。用户只是想知道一句话是正面还是负面，结果等了两三秒才看到结果，体验伤害很大。第三是效果的不确定性：不是所有复杂模型都在所有任务上表现更好，代码生成、JSON 结构化输出、多轮对话、长文档总结，不同模型的强项差异很明显，单一模型等于把所有鸡蛋放在一个篮子里。

1.2 路由系统到底在路由什么

很多人以为多模型路由就是"做个 if-else 判断一下，简单任务走便宜模型，复杂任务走贵模型"。真要这么简单，我就不用写这篇文章了。

路由的本质，是对"一次请求"和"多个候选模型"做匹配。每次请求带着三个关键特征：这次任务属于什么类型、用户能接受多长的等待、这笔调用愿意花多少钱。每个模型也有三个属性：能力特长、平均响应速度、单位价格。路由系统要做的，就是在候选模型里找到"满足硬性约束 + 综合评分最优"的那一个。

这里面还有一层隐含需求：智能路由不能让业务方感知到"模型变了"。接口要统一，响应格式要统一，错误处理要统一。也就是说，路由层必须是一个透明的代理，上游业务不关心自己用的是哪个模型，只关心结果对不对、快不快、便宜不便宜。这个约束直接影响下面的系统设计。

2. 先把决策因子量化：成本、延迟、任务类型建模

2.1 成本模型：按 Token 计价的价格函数与预算感知

做路由之前，第一步是建成本模型。所有主流模型的 API 都是按 Token 计费的，而且输入 Token 和输出 Token 单价不同，所以一次调用的成本不能简单地用"模型单次价格"来算，要用价格函数：

code复制cost = inputTokenCount × inputPrice + estimatedOutputTokens × outputPrice

注意这里的输出 Token 数是"预估值"。请求发起前，你根本不知道模型会输出多长，所以必须根据历史数据或者业务场景来预估。比如代码生成类任务平均输出 800 token，短文本分类平均输出 50 token，这些统计值可以从日志里算出来。

我建议把价格表做成外部配置，而不是写死在代码里。模型供应商经常调价，而且不同账户的折扣可能不一样。实际项目中我用了一个简单的 JSON 配置：

json复制{
  "gpt-4o": {
    "inputPricePerMillion": 2.5,
    "outputPricePerMillion": 10,
    "avgOutputTokens": 600,
    "latencyWeight": 0.4,
    "capabilityTags": ["complex", "reasoning", "code", "multimodal"]
  },
  "gpt-4o-mini": {
    "inputPricePerMillion": 0.15,
    "outputPricePerMillion": 0.6,
    "avgOutputTokens": 400,
    "latencyWeight": 0.2,
    "capabilityTags": ["simple", "classification", "extraction"]
  },
  "claude-3-haiku": {
    "inputPricePerMillion": 0.25,
    "outputPricePerMillion": 1.25,
    "avgOutputTokens": 450,
    "latencyWeight": 0.15,
    "capabilityTags": ["simple", "classification", "chat"]
  }
}

价格单位我用"每百万 Token"来配，避免数字太小不好维护。有了价格配置，估算单次成本就是一次乘法，路由决策时可以实时算。

2.2 延迟模型：动态测速与滑动窗口预估

延迟是买不到准确数字的，因为模型服务的负载随时在变，上午通畅的模型到了下午高峰可能就慢如蜗牛。所以，不能只看配置表里写死的"这个模型快"，要看真实观测。

我的做法是维护一个"滑动窗口平均延迟"表。每个模型记录最近 N 次成功调用的首 token 延迟和完整延迟，路由时取最近一段时间的中位数，而不是把所有历史数据平均——因为一次网络抖动会把平均值拉得很高。

计算代码大致是这样：

javascript复制class LatencyTracker {
  constructor(options = {}) {
    this.windowSize = options.windowSize || 50;
    this.latencies = new Map(); // model -> number[]
  }

  record(model, latencyMs) {
    if (!this.latencies.has(model)) {
      this.latencies.set(model, []);
    }
    const list = this.latencies.get(model);
    list.push(latencyMs);
    if (list.length > this.windowSize) {
      list.shift();
    }
  }

  getMedianLatency(model) {
    const list = this.latencies.get(model) || [];
    if (list.length === 0) {
      return this.defaultLatency(model);
    }
    const sorted = [...list].sort((a, b) => a - b);
    const mid = Math.floor(sorted.length / 2);
    return sorted.length % 2 ? sorted[mid] : (sorted[mid - 1] + sorted[mid]) / 2;
  }

  defaultLatency(model) {
    // 冷启动时的兜底值，比如从配置里拿
    return 2000;
  }
}

还有一个小细节：滑动窗口内的样本要在时间上分散，避免某一次大批量测试把某个模型刷得很高。实际操作里，我会按"每 30 秒最多采一个样本"来做节流，保证数据反映的是日常表现，不是某一瞬间的突发情况。

2.3 任务类型：不是靠关键词匹配，而是靠能力画像

任务类型怎么判断？很多人第一反应是关键词匹配：看到"摘要"两个字就路由到总结模型。但真实请求五花八门，用户不会把"帮我润色这段文字"和"做摘要"区隔得那么分明，关键词匹配的泛化能力太弱。

更靠谱的做法是把任务类型建模成"能力标签"。我维护一个能力清单：reasoning（复杂推理）、planning（规划）、code（代码生成）、multimodal（图片/音频理解）、classification（分类/抽取）、generation（文本创作）、summary（摘要）等等。每个任务请求落到路由层时，通过一个轻量分类器打上这些标签。

分类器可以用一个小模型，也可以用一个本地规则引擎。生产环境里我建议先上规则 + 少量正则兜底，等积累了一定量的样本，再用标注数据训练一个几 KB 的文本分类器。原因很实际：如果分类这一步本身都调用了大模型，那成本优化就没有意义了；本地规则不是最优方案，但胜在零成本和零延迟，对大多数场景够用。

能力画像的另一面是"每个模型能做什么"。比如多模态输入只能走支持图片的模型；代码生成最好走代码能力强的模型，否则轻量模型可能输出格式混乱的代码。所以每个模型配置里的 capabilityTags 不是摆设，它决定了任务类型的硬性约束能不能被满足。

3. 核心实现：Node.js 多模型路由器的骨架与决策流程

3.1 模型供应商统一适配层

进入代码之前，先把架构思路说清楚。路由器的前面是业务侧 API，后面是多个模型供应商。为了不让路由层被某个供应商的 SDK 格式绑架，我抽象了一个统一的 ModelAdapter 接口：

javascript复制class ModelAdapter {
  constructor(config) {
    this.name = config.name;
    this.capabilities = new Set(config.capabilityTags);
    this.provider = config.provider;
  }

  async complete(payload) {
    // 由具体实现覆写
    // 统一的请求结构：{ messages, temperature, maxTokens, stream }
    // 统一的响应结构：{ text, usage: { inputTokens, outputTokens } }
    throw new Error('Not implemented');
  }

  supports(taskTags) {
    for (const tag of taskTags) {
      if (!this.capabilities.has(tag)) {
        return false;
      }
    }
    return true;
  }
}

实际的 OpenAI 适配器、Claude 适配器或本地部署模型的适配器都继承这个类，把各自的 SDK 请求和响应转换成统一格式。这一步很关键，它把"路由逻辑"和"供应商差异"彻底解耦。路由决策器不需要知道请求长什么样，只需要拿到"这个模型当前成本多少、延迟多少、是否支持当前任务"三个维度的数据。

3.2 路由决策器：加权评分与硬性约束

核心的路由决策我用的是"硬性约束过滤 + 加权评分排序"两步走。这样比单纯打分更安全——比如用户明确要求 800ms 内返回，那所有预估超过 800ms 的模型直接淘汰，不给"分数高但延迟超了"的模型机会。

完整决策代码：

javascript复制class Router {
  constructor({ adapters, latencyTracker, options = {} }) {
    this.adapters = adapters;
    this.latencyTracker = latencyTracker;
    this.options = {
      costWeight: 0.35,
      latencyWeight: 0.35,
      qualityWeight: 0.3,
      maxBudgetPerCall: Infinity,
      maxLatencyMs: Infinity,
      ...options
    };
  }

  async route(taskTags, context = {}) {
    // 1. 硬性筛选：能力、预算、延迟
    const candidates = [];
    for (const adapter of this.adapters) {
      if (!adapter.supports(taskTags)) continue;

      const latency = this.latencyTracker.getMedianLatency(adapter.name);
      const cost = this.estimateCost(adapter, context);
      const quality = this.getQualityScore(adapter, taskTags);

      if (cost > this.options.maxBudgetPerCall) continue;
      if (latency > this.options.maxLatencyMs) continue;

      candidates.push({ adapter, cost, latency, quality });
    }

    if (candidates.length === 0) {
      // 兜底策略：放宽约束，选成本最低的可用模型
      return this.fallbackRoute(taskTags);
    }

    // 2. 归一化评分
    const maxCost = Math.max(...candidates.map(c => c.cost));
    const maxLatency = Math.max(...candidates.map(c => c.latency));
    const maxQuality = Math.max(...candidates.map(c => c.quality));

    for (const candidate of candidates) {
      const normalizedCost = maxCost === 0 ? 0 : candidate.cost / maxCost;
      const normalizedLatency = maxLatency === 0 ? 0 : candidate.latency / maxLatency;
      // quality 越高越好，所以要用 1 - 归一化倒数
      const normalizedQuality = maxQuality === 0 ? 0 : 1 - candidate.quality / maxQuality;

      candidate.score =
        this.options.costWeight * normalizedCost +
        this.options.latencyWeight * normalizedLatency +
        this.options.qualityWeight * normalizedQuality;
    }

    candidates.sort((a, b) => a.score - b.score);
    return candidates[0].adapter;
  }

  estimateCost(adapter, context) {
    const inputTokens = context.inputTokens || 0;
    const outputTokens = adapter.config.avgOutputTokens || 200;
    const inputPrice = adapter.config.inputPricePerMillion || 0;
    const outputPrice = adapter.config.outputPricePerMillion || 0;
    return (inputTokens / 1_000_000) * inputPrice + (outputTokens / 1_000_000) * outputPrice;
  }

  getQualityScore(adapter, taskTags) {
    // 这里根据任务类型给模型能力打分
    // 比如 code 任务，代码能力强的模型给高分；classification 任务，轻量模型也有高分
    const qualityMap = {
      code: { 'gpt-4o': 10, 'gpt-4o-mini': 6, 'claude-3-haiku': 6 },
      reasoning: { 'gpt-4o': 10, 'gpt-4o-mini': 5, 'claude-3-haiku': 4 },
      classification: { 'gpt-4o': 8, 'gpt-4o-mini': 9, 'claude-3-haiku': 9 }
    };
    const scores = qualityMap[taskTags[0]] || {};
    return scores[adapter.name] || 5;
  }
}

这段代码的注释我要解释几点。第一，score 越低代表越优，因为在归一化时我统一把"成本越高分越高、延迟越高分越高、质量越高分越低"处理了，最后取分数最低的候选。第二，getQualityScore 看起来像硬编码，但在早期版本里这是一个可配置的 JSON 映射表，方便业务调整"哪个模型擅长什么"。第三，fallbackRoute 很关键——如果所有候选都因为延迟或预算被过滤掉了，不能直接报错，而是回到成本最低且可用的模型，把硬性约束放宽到只保留能力约束。

3.3 从请求到响应的完整链路

路由决策只占整个请求链路的一小部分，完整的调用流程是这样的：

javascript复制async function handleLLMRequest(req, res) {
  const taskTags = classifyTask(req.body.messages);
  const inputTokens = estimateInputTokens(req.body.messages);

  const router = getRouter();
  const adapter = await router.route(taskTags, { inputTokens });

  // 打日志，方便后面复盘路由决策
  logDecision({
    requestId: req.id,
    taskTags,
    selectedModel: adapter.name,
    timestamp: Date.now()
  });

  // 执行真实调用
  const response = await adapter.complete({
    messages: req.body.messages,
    temperature: req.body.temperature || 0.7,
    maxTokens: req.body.maxTokens,
    stream: false
  });

  // 把实际 token 用量回传给成本 tracker，用于校准预估
  trackUsage(adapter.name, response.usage);

  res.json({
    text: response.text,
    model: adapter.name,
    usage: response.usage
  });
}

这里有三个容易被忽略的点：第一是日志，路由决策必须留痕，否则你根本不知道线上到底用了哪个模型，成本归因就是一笔糊涂账；第二是 trackUsage，把真实的 token 消耗统计起来，用于修正 avgOutputTokens 的预估值，让成本估算越跑越准；第三是响应体里带上 model 字段，方便业务侧观察和排查。这一步是整个系统能否持续优化的数据基础。

4. 路由策略深水区：上下文感知、降级与成本熔断

4.1 上下文窗口与价格突变：单次请求的预估陷阱

第一版路由上线后我踩了一个大坑：所有请求都只按"新对话"来估算成本，没有考虑多轮对话的上下文累积。结果一个长对话的请求，输入 Token 从一千涨到几万，模型路由却还是按一千来估算，导致一堆长对话被路由到了轻量模型上，输出质量明显下降。

修法是在 estimateCost 里用真实的完整上下文 Token 数计算：

javascript复制function estimateInputTokens(messages) {
  // 这里可以用 tokenizer 精确计算，也可以按字符数粗略估算
  // 粗略估算：汉字约 1 字符 ≈ 0.6 ~ 1 token，英文约 4 字符 ≈ 1 token
  return messages.reduce((acc, msg) => {
    const content = msg.content || '';
    return acc + Math.ceil(content.length / 3); // 保守估算
  }, 0);
}

如果要更精确，建议用 tiktoken 之类的库，但它是 Python 库，Node.js 生态里可以用 gpt-tokenizer 或 @dqbd/tiktoken。对于生产系统，token 数直接决定成本和路由准确性，这个计算不能太草率。

还有一个"价格突变"的坑：模型供应商偶尔会调整价格，如果你的配置是硬编码的，价格一变，路由决策就会失真。所以我建议给配置加一个版本号和生效时间，价格调整时发布新配置，同时保留历史版本用于成本对账。

4.2 降级链与失败转移：便宜模型不是随时能顶上的

路由不是选出模型就结束了，真实调用总会出问题：限流（429）、超时、内部错误（5xx）、JSON 输出格式不对。如果只路由一次，失败就重试同一个模型，那路由的意义就少了一半。

我的做法是在路由阶段就为请求建立"降级链"：首选模型、备选模型、兜底模型。首选失败时，按优先级依次尝试备选，直到成功或全部失败。降级链的构建不是简单复制路由结果，而是把排在第二、第三的候选模型也保留下来：

javascript复制async function executeWithFallback(candidates, payload) {
  const errors = [];
  for (const candidate of candidates) {
    try {
      return await candidate.adapter.complete(payload);
    } catch (err) {
      errors.push({ model: candidate.adapter.name, error: err.message });
      // 记录降级事件
      logFallback(candidate.adapter.name, err);
    }
  }
  throw new AggregateError(errors, 'All models failed');
}

有一个细节：降级链不是每次都要尝试全部候选，而是根据错误类型跳过一些模型。比如 429 限流，说明模型本身没问题，只是当前负载高，可以继续试下一个；如果是 400 参数错误，那说明这个请求本身有问题，换成别的模型大概率也会失败，直接报错交给上层处理更合适。降级策略需要和错误分类结合，否则可能白白浪费很多次调用。

4.3 成本熔断与预算限额：防止失控账单

多模型路由一方面省了钱，另一方面也带来了新风险：如果路由配置出 bug，比如某个模型价格被配成 0，或者某个任务的分类器失灵，所有请求都涌向一个模型，账单照样可能爆炸。所以我在系统里加了一个成本熔断机制。

熔断分两层：单次预算限额和全局预算限额。单次限额就是在路由决策时检查 maxBudgetPerCall，超了直接排除候选；全局限额则是维护一个按时间窗口（比如每小时）累计的 token 消耗和费用，当消耗超过预算阈值时，所有请求自动降级到最低成本模型，直到窗口重置。

javascript复制class BudgetManager {
  constructor(options) {
    this.hourlyBudget = options.hourlyBudget || 10; // 每小时预算，美元
    this.hourlyUsage = 0;
    this.usageHistory = [];
  }

  recordCost(costUsd) {
    const currentHour = Math.floor(Date.now() / 3_600_000);
    if (this.usageHistory.length && this.usageHistory[0].hour === currentHour) {
      this.usageHistory[0].cost += costUsd;
    } else {
      this.usageHistory.unshift({ hour: currentHour, cost: costUsd });
      if (this.usageHistory.length > 24) this.usageHistory.pop();
    }
    this.hourlyUsage = this.usageHistory[0].cost;
  }

  canAfford(costUsd) {
    return this.hourlyUsage + costUsd <= this.hourlyBudget;
  }
}

这个幅度在 Webhook 或定时任务里处理很有用。比如我们有一个批量处理任务，每晚要处理几十万条数据，如果路由发现预算不够，会自动把模型从昂贵档切到便宜档，任务继续跑但成本可控。没有熔断之前，这类批量任务是最容易出现"一夜跑掉一个月预算"的。

5. 实测与调优：线上数据给我的教训

5.1 我的压测方法和指标体系

路由系统写完之后，需要通过压测验证效果。我的做法是搭建一个模拟线上请求的基准集：包含 10 类任务、每类 500 条真实脱敏请求，然后用脚本循环发给路由服务，同时对比三个版本的配置。

我关注的指标有四个：单次请求平均成本、P50/P95 延迟、质量不达标率（通过人工或裁判模型抽样评测）、路由决策耗时（这个必须极低，否则路由本身成了瓶颈）。路由决策本身必须控制在几毫秒内，如果决策耗时超过 20ms，说明路由逻辑里做了太重的计算，比如每次请求都去调分类器，这就要优化了——分类器应该做成异步的或者本地化的。

下面是我在实际压测中对比的一组代表性结果（模型名做了模糊处理）：

多模型路由的初期版本比全走旗舰模型成本下降了将近 70%，质量只掉了 3 个百分点。但调优后还能再进步，核心是把任务类型的分类器从正则匹配升级成了本地轻量模型，同时把延迟权重的斜率调得更陡，让"慢模型"更快被淘汰。

5.2 路由参数调优：权重怎么定、阈值怎么设

很多人拿到评分公式会问：成本、延迟、质量三个权重到底怎么配置？我的经验是不要凭空拍脑袋，而是用压测数据反推。

如果业务对延迟极度敏感（比如实时客服聊天），就把 latencyWeight 调高到 0.5 以上，同时把 maxLatencyMs 设置成硬性上限。这种情况下，即便某模型质量略高，一旦某段时间延迟不稳，也会被快速排除。如果业务对成本极度敏感（比如大批量离线处理），就调高 costWeight，甚至可以到 0.6。如果业务更看重答案质量（比如代码审查、复杂分析），把 qualityWeight 调高。

这里有一个反直觉的细节：权重不是越大越极端越好。延迟权重调高了，确实能让请求走向更快的模型，但如果高到 0.8，可能导致不同请求在模型之间频繁切换，缓存命中率下降，整体成本反而上升。我最后把三个权重定在 0.35 / 0.35 / 0.3，这是综合压测后最稳的一组值。

5.3 我踩过的坑：模型名称映射、流式响应与路由

第一个坑是模型名称不统一。OpenAI 的一个大版本可能同时存在 gpt-4-1106-preview、gpt-4-turbo、gpt-4o 几个称呼，Claude 那边也有时代版本。我的配置表里用的 gpt-4o，但某个历史请求日志里记录的却是 gpt-4-1106-preview，导致成本归因对不上账。解决方式是在配置表里加一个 aliases 数组，兼容历史模型名，统一映射到当前主版本。

第二个坑是流式响应。我们的部分业务为了用户体验用了 SSE 流式输出，但路由决策必须在流开始前完成，而且流式调用失败时，用户已经看到了部分输出，这时候走降级链重新请求同一个提示词，会造成输出重复。我的处理办法是：对启用流式的请求，首选模型一旦开始输出就记录下来，降级链只覆盖"连接建立前"的失败；如果流中途断开，不重试，直接抛错让前端显示重试按钮。严格来说这不是最优方案，但比盲目重试更安全。

第三个坑是并发限流。有些模型服务商的限流是按"每分钟请求数"和"每分钟 token 数"双维度计算的。我们的路由器只按请求数估算负载，没有评估 token 维度，结果每次批量任务一启动，就触发某些模型的 RPM 限制，导致大量 429 错误。后来我在每个适配器里加了一个简易的 token bucket 限流器，按照各家文档配置的 RPM 和 TPM 来模拟本地令牌消耗，在路由决策时就把"即将排队"的模型排除掉，429 率大幅下降。

6. 还能怎么继续演进：我的后续规划

多模型路由目前做到这个程度，已经能满足大多数团队的降本增效需求，但距离"自适应"还有很长一段路。我接下来打算在三方面继续迭代。

第一是反馈闭环。现在质量评分基本靠静态配置，后续想通过用户反馈、点赞点踩信号动态调整质量分。一个任务在某个模型上连续获得差评，应该自动降低该模型在这个任务类型上的质量分数，而不是等人工改配置。

第二是更细粒度的用户维度路由。不同用户对成本和延迟的容忍度完全不同：企业客户愿意等更久换更好答案，普通 C 端用户则希望越快越好。后续想在请求里带上用户等级或渠道属性，让路由规则因用户而异，而不是一刀切。

第三是引入缓存层。很多请求是重复的，或者近乎重复的，在没有缓存的情况下，每条请求都要真金白银地走一次模型。加一层语义缓存之后，完全一样的 prompt 可以直接命中历史答案，连轻量模型都不用调用，这可能是比多模型路由更省钱的一个优化点。

最后再分享一个小经验：不要在一开始就把路由规则设计得太复杂。先跑通"按任务类型选模型 + 成本估算"这条最基础的链路，用日志和压测数据看效果，再慢慢加入延迟预估、降级链、熔断这些进阶策略。路由系统的价值不是靠一次设计出来的，而是靠上线后不断根据真实流量打磨出来的。