模型路由怎样按延迟与成本选择后端

我第一次把多个模型后端接进同一个接口时，最容易犯的错是把“最快”和“最便宜”当成同一张排序表。实际请求里，首 token 延迟、完整响应延迟、输入输出成本、上下文上限和当前错误率往往互相牵制。更稳妥的模型路由做法是：先排除不满足硬约束的后端，再在剩余候选中按业务权重排序，最后把超时和回退写成明确的请求边界。

官方地址：https://huggingface.co/docs/inference-providers/

路由器不负责猜哪个模型“最好”，它负责在当前任务约束下选择“够用、可达、能解释”的后端。延迟和成本是排序信号，能力与健康状态是筛选条件。

先把“快”和“省”拆成可比较的约束

延迟至少分成首 token 延迟和完整响应延迟；成本也不要只记录一个模糊的“每次调用价格”，而应按输入 token、输出 token 或供应商账单口径保存。对一个需要流式回复的问答接口，我通常把首 token p95 当硬约束，把完整响应 p95 当软偏好；对批处理任务则反过来。这样不会因为一个后端首字很快，就把长输出的总耗时和成本全部隐藏起来。

模型能力同样要先筛选。例如需要工具调用、视觉输入或较长上下文时，缺少能力的后端不应该因为价格低而进入排序。Hugging Face Inference Providers 的文档把它描述为位于应用和多个 provider 之间的统一代理层，客户端可以显式指定 provider，也可以使用 auto；这个思路适合拿来设计自己的路由接口，但具体能力仍要以实际 provider 文档为准。

用路由表先筛选，再按权重排序

路由表是我认为最值得保留的中间层。它把“后端叫什么”与“为什么选它”分开，后续更换供应商时不用把业务代码改成一串 if/else。下面的 TypeScript 片段只展示选择逻辑，p95Ms、inputCost 和 outputCost 应来自你自己的观测或账单数据。

type Backend = {
  id: string;
  p95Ms: number;
  inputCost: number;
  outputCost: number;
  capabilities: Set;
  healthy: boolean;
};

type RouteRequest = {
  required: Set;
  maxP95Ms: number;
  maxCost: number;
};

function chooseBackend(backends: Backend[], request: RouteRequest): Backend | undefined {
  // 先过滤能力、健康状态和硬阈值，避免低价但不可用的后端参与排序。
  const candidates = backends.filter((backend) => {
    const hasCapabilities = [...request.required].every((item) => backend.capabilities.has(item));
    const estimatedCost = backend.inputCost + backend.outputCost;
    return backend.healthy && hasCapabilities && backend.p95Ms  {
    const leftScore = left.p95Ms * 0.6 + (left.inputCost + left.outputCost) * 0.4;
    const rightScore = right.p95Ms * 0.6 + (right.inputCost + right.outputCost) * 0.4;
    return leftScore - rightScore;
  })[0];
}

这里的成本示例故意保持简单：真实系统应统一币种、token 估算口径和计费周期，并把输入输出比例纳入预算模型。另一个容易忽略的点是健康状态不能只靠一次探活更新，至少应结合最近窗口内的超时、限流和供应商错误。

超时与回退必须写成独立边界

排序只解决“首选谁”，不解决“首选失败后怎么办”。我会把回退分成几类：单次请求超时可以换到备用后端；连续的限流或服务不可用可以短暂熔断；不支持某项能力时不能盲目重试；预算达到上限时则应降级到更小的模型或返回明确的业务提示。

回退函数还要保留尝试记录，避免把同一个后端重复调用。下面的示例只允许每个候选尝试一次，并把失败原因交给上层记录；它没有把所有错误都当成可回退错误。

type Attempt = { backend: string; reason: string };

async function callWithFallback(
  candidates: Backend[],
  invoke: (backend: Backend) => Promise,
): Promise {
  const attempts: Attempt[] = [];

  for (const backend of candidates) {
    try {
      // 每个候选只调用一次；超时应由 invoke 内部使用请求级取消控制。
      const answer = await invoke(backend);
      return { answer, attempts };
    } catch (error) {
      const reason = error instanceof Error ? error.message : "unknown-error";
      // 记录真实原因，只有允许回退的错误才继续尝试下一个后端。
      attempts.push({ backend: backend.id, reason });
      if (!reason.includes("timeout") && !reason.includes("rate-limit") && !reason.includes("unavailable")) {
        throw error;
      }
    }
  }

  throw new Error(`all-backends-failed:${attempts.map((item) => item.backend).join(",")}`);
}

这个边界很重要：模型拒答、参数不合法、权限失败和能力不匹配，通常不是换后端就能解决的问题。如果把它们全部归到“失败后重试”，路由器会放大成本，也会让真正的配置错误变得难以定位。

把选择理由和实际结果一起留下来

如果只记录最终使用了哪个模型，下一次调参时很难知道路由器为什么作出这个决定。每次请求至少保留请求类型、所需能力、候选快照、首选后端、实际后端、回退原因、首 token 延迟、总耗时和成本估算。不要在日志里保存完整提示词或敏感业务数据；保留可关联的请求标识和必要的聚合字段就够了。

我的经验是先用一段时间的真实请求记录校准阈值，再决定是否引入更复杂的动态策略。没有足够观测数据时，静态路由表加有限回退往往比“实时预测每个模型质量”更容易解释，也更容易在故障时止损。

哪些场景适合使用这套路由边界

如果应用同时面对交互问答、批量摘要和结构化抽取，按任务类型维护不同的延迟、成本和能力约束很有价值。若所有请求都要求同一模型、同一地区和同一 SLA，直接固定后端通常更简单。路由层真正值得维护的前提，是候选之间确实存在可度量的取舍。

模型路由只按价格排序可以吗？

不建议。价格只能作为排序信号，能力、健康状态和延迟硬阈值应先过滤，否则低价后端可能因为不支持输入类型或持续超时而产生更高的总成本。

回退后要不要重新走完整路由？

同一次请求通常只在预先排好的候选列表中向后尝试，避免回退时再次把已经失败的后端选回来。下一次请求再根据新的健康窗口重新生成候选列表。

总结一下：先用能力和健康状态做硬筛选，再用延迟与成本排序；给超时、限流、不可用和不可回退错误分别定义边界；最后把选择理由、实际后端和回退结果记录下来。这样模型路由才是可调整的工程组件，而不是一段难以解释的供应商名单。