实际 LLM 应用中很多团队会遇到一个共同问题所有请求都调用同一个最强模型效果虽然稳定成本却随着调用量上升迅速失控。AI model router 就是用来解决这类问题的一种中间层它根据请求类型、模型能力、价格和当前负载把请求分发到合适的 LLM用较低成本满足大部分需求。这篇文章以一次成本优化项目为背景完整梳理模型路由器的设计思路、最小实现、成本验证和生产落地要点。需要先说明一点标题里的 94% 成本下降来自特定业务场景不一定能在所有系统上复现。文章给出的代码和配置是用于讲解实现思路落地时要以实际模型 API、定价策略和业务数据为准。1. 先理解 AI 模型路由器的价值边界1.1 模型路由要解决什么问题模型路由器的核心问题只有一个当前这个请求真的需要最强的模型吗在自然语言处理项目中并不是所有请求都要求高推理能力。用户问“今天天气怎么样”“这个接口返回的字段是什么意思”和用户提交一份包含数学推理、代码调试、多步规划的复杂问题对模型能力的需求完全不同。如果统一调用大参数、高价格模型简单请求会支付超额成本如果统一调用小模型复杂请求会频繁失败或质量下降。AI model router 就是在用户请求和底层 LLM 之间增加一层决策逻辑。它把请求分类估算需要的输出长度读取每个模型的能力和价格然后决定把请求交给哪个模型。本质上是在“效果、延迟、成本”三者之间做权衡。1.2 为什么路由会带来成本下降LLM 的成本结构通常由输入 token 数、输出 token 数和不同模型单价决定。大部分业务场景里高频请求其实是短文本问答、摘要、格式转换、意图识别这类任务它们不需要顶级模型的全部能力。一个典型例子1000 次请求全部走大模型每次输入约 500 token输出约 200 token成本按大模型单价计算。其中 800 次请求实际是小模型就能完成的只有 200 次真正需要大模型。如果路由逻辑能把 800 次简单请求切到小模型成本变化会非常明显。这不是通过压缩模型参数量实现的而是通过减少高单价模型调用次数实现的。94% 这个数字虽然来自特定案例但背后的逻辑是一致的大部分成本浪费来自“模型能力和请求需求不匹配”。1.3 路由器与 API 网关的差异有人会把模型路由器当成 API 网关两者职责并不一样。API 网关关心的是路由转发、鉴权、限流、协议转换、负载均衡它不关心模型能力是否匹配。模型路由器关心的是业务语义和模型能力任务属于哪个类别、输出质量要求多高、延迟预算多少、当前模型能不能处理。实际项目中两者可以配合API 网关负责把外部请求接入系统模型路由器位于网关之后在内部完成模型选择。不要把模型路由逻辑直接写进网关否则后续调整模型策略会受制于网关发布和团队职责边界。2. 从案例出发确定路由目标和判断维度2.1 一次成本优化项目的背景以一次成本优化项目为例。团队运营一个企业内部知识库助手主要包含三类请求文档内容问答用户针对某段文档提问问题通常短、答案可以从上下文里提取。代码与命令生成用户要求生成脚本、调试命令对步骤准确性要求高。综合总结与规划用户提交多段材料要求生成结构化报告或方案。项目启动前所有请求都调用同一个高价模型。监控显示每月 token 消耗中约 20% 的请求属于代码和复杂规划类剩下 80% 是文档问答和短文本处理。把 80% 的简单请求拆到低成本模型是成本优化的主要切入点。目标并不是让所有请求都用最便宜的模型而是保证每个请求都使用“够用且不浪费”的模型。还需要约束延迟和错误率否则成本降下来但用户体验变差优化没有意义。2.2 决策维度一览模型路由决策不是一个单一的 if else而是多维度打分的组合。常用维度如下维度说明影响任务类型问答、摘要、代码、数学、推理、生成等决定是否需要强模型输入长度段落长度、上下文大小影响输入成本和延迟预期输出长度回复长度估算影响输出成本和模型输出上限质量要求是否存在标准答案、是否会被人工审查低质量场景可接受较小模型延迟预算用户能接受的等待时间大模型延迟高小模型延迟低成本上限单次请求允许的最大成本超预算请求必须切模型或拒绝在最小实现里任务类型往往是最强信号。代码、数学、复杂推理优先分给强模型文档问答、简单摘要、意图识别分给小模型。但要避免只按任务类型判断因为同一个任务类型内部复杂度也可能差别很大。2.3 示例价格模型为了演示成本计算需要先定义模型和价格。以下价格不是任何平台的实时报价仅作为示例模型标识输入价格美元/1K token输出价格美元/1K token能力倾向llm-large0.0150.075高推理、代码、长文生成llm-small0.00150.006短问答、摘要、格式转换llm-medium0.0030.015中等复杂度解释、分类把这组价格写进配置路由服务才能按实际 token 用量计算成本。注意采购或接入新模型时价格要单独确认并测试 tokenizer 的切分规则不同模型对同一段文本的 token 计费可能不同。3. 最小可运行的模型路由服务3.1 项目结构与数据模型下面用一个最小示例说明模型路由器的实现思路。项目结构如下llm-router/ ├── config/ │ └── routing.yaml ├── core/ │ ├── scheme.py │ ├── estimator.py │ ├── router.py │ └── client.py ├── logs/ │ └── router.log └── main.py首先定义模型配置。用ModelConfig保存模型名称、价格、上下文窗口和是否支持复杂推理# core/scheme.py from dataclasses import dataclass from typing import Optional dataclass class ModelConfig: name: str input_price: float output_price: float context_window: int 8192 max_output_tokens: int 4096 supports_reasoning: bool False dataclass class RouteRequest: task_type: str prompt: str expected_output_tokens: int 512 max_cost_usd: Optional[float] None max_latency_seconds: Optional[float] NoneRouteRequest是路由器的统一入参。在线服务中它通常由上游服务组装从请求体里读取用户输入用分类模型或规则识别任务类型再传给路由器。3.2 统一请求响应结构路由器返回时不能只告诉上层“选择了哪个模型”还要返回内容、token 用量和成本。这样才能在后面做成本统计和质量回归。dataclass class RouteResponse: model: str content: str input_tokens: int output_tokens: int cost_usd: float统一响应结构有两个作用上层业务代码不关心底层模型差异只需要处理一个响应对象。成本统计模块可以从响应对象中提取 token 和费用不需要额外去查调用链。3.3 基于规则的路由实现先实现一个 token 估算器。真实项目应该使用各模型对应的 tokenizer但最小示例可以用字符数近似# core/estimator.py def estimate_tokens(text: str, bytes_per_token: float 4.0) - int: if not text: return 0 return max(1, int(len(text.encode(utf-8)) / bytes_per_token))这个函数的价值是在真正调用模型前先得到输入 token 数量用于成本估算和模型选择。生产环境里建议在每个 provider adapter 中调用官方 tokenizer避免估算偏差影响路由判断。接下来实现规则路由器# core/router.py from core.scheme import ModelConfig, RouteRequest from core.estimator import estimate_tokens class RuleRouter: def __init__(self, models: dict[str, ModelConfig]): self.models models def route(self, req: RouteRequest) - str: input_tokens estimate_tokens(req.prompt) if input_tokens self.models[llm-large].context_window * 0.8: return llm-large if req.task_type in {code, math, reasoning, multi-step-plan}: return llm-large if req.task_type in {qa-extractive, summarize-short, intent}: return llm-small return llm-medium这个路由规则包含三层判断超长输入优先走大模型因为小模型上下文窗口不足。高推理任务直接走大模型避免小模型反复生成错误内容。简单任务走小模型其余走中等模型。这里要强调规则路由器适合快速验证思路但不适合长期维护。规则会随着任务类型增加而膨胀最终出现“优先级冲突”和“难以解释”的问题。更可靠的方式是引入打分函数。3.4 本地验证与预期输出在main.py里模拟一次调用from core.scheme import ModelConfig, RouteRequest from core.router import RuleRouter models { llm-large: ModelConfig( namellm-large, input_price0.015, output_price0.075, context_window128000, supports_reasoningTrue, ), llm-medium: ModelConfig( namellm-medium, input_price0.003, output_price0.015, context_window32000, ), llm-small: ModelConfig( namellm-small, input_price0.0015, output_price0.006, context_window16000, ), } router RuleRouter(models) req RouteRequest(task_typeqa-extractive, prompt后端返回的 error_code 是什么意思) print(router.route(req))预期输出是llm-small。用同样的方法构造一个task_typecode的请求预期输出是llm-large。这就是最小闭环输入请求输出模型选择结果。之后再把模型选择结果接入真实客户端替换返回的content字段。4. 让路由决策更可靠4.1 从规则路由升级为打分路由规则路由的缺点是“一刀切”。同样是代码任务修改一行配置和编写一个完整微服务复杂度完全不同。打分路由的思路是为每个候选模型计算综合分数选择分数最高的模型。打分函数可以包含三个子分数成本分、延迟分、质量分。def score_model( model: ModelConfig, input_tokens: int, expected_output_tokens: int, task_quality_need: float, latency_budget: float, ) - float: cost input_tokens / 1000 * model.input_price expected_output_tokens / 1000 * model.output_price cost_score 1.0 / (1.0 cost * 100) quality_score model.supports_reasoning * task_quality_need (1.0 - model.supports_reasoning) * (1.0 - task_quality_need) latency_score max(0.0, 1.0 - latency_budget / 10.0) return cost_score * 0.5 quality_score * 0.4 latency_score * 0.1这里的参数不能直接复制到生产环境。它只是说明打分路由的构造方式每一项都应该是可量化的并且权重需要根据业务反馈调整。真实项目中成本分应该使用真实单价质量分应该来自离线评测或线上效果指标而不是简单用supports_reasoning代替。4.2 回退机制设计路由器需要处理小模型失败的情况。常见失败包括内容被过滤、输出格式不符合要求、捕获到异常、质量分过低。回退机制可以这样实现def route_with_fallback(req: RouteRequest, client, router) - str: selected router.route(req) response client.complete(modelselected, promptreq.prompt) if not response.is_valid: return client.complete(modelllm-large, promptreq.prompt) return response回退机制的关键是不要无限制重试。第一跳失败后切到更大模型最多重试两次如果仍然失败直接进入错误处理流程。否则成本没有降下来延迟反而翻倍。4.3 动态调节路由策略路由器的配置不应该写死在代码里。推荐把模型价格、任务类型映射、权重参数放到配置中心或独立配置文件运行时可以动态更新。# config/routing.yaml default_model: llm-medium rules: - task_type: qa-extractive model: llm-small - task_type: code model: llm-large - task_type: reasoning model: llm-large fallback: enabled: true max_retry: 2 fallback_model: llm-large更新配置后要记录版本号和生效时间。模型价格调整或新模型接入时先在小流量环境验证再全量发布。不要直接修改生产配置后不做任何验证否则可能出现“所有请求都路由到同一个模型”的问题。5. 成本统计与收益验证5.1 按模型聚合成本成本优化是否有效不能只看总账单。要建立按模型、按任务类型、按天聚合的成本视图。可以写一个简单的统计函数def aggregate_cost(responses: list[RouteResponse]) - dict[str, float]: result {} for resp in responses: key resp.model result[key] result.get(key, 0.0) resp.cost_usd return result更完整的方案是把每次调用的RouteResponse写入日志表字段包括请求 ID、模型、输入 token、输出 token、任务类型、耗时、成本。后续做分析时只需要按模型聚合就能看到成本分布。5.2 验证收益时要排除缓存干扰很多 LLM 产品提供 prompt 缓存。如果缓存命中token 成本可能大幅下降。但这部分收益来自缓存不是完全来自模型路由。验证路由器收益时建议先关闭缓存或者分别统计“缓存命中”和“未命中缓存”的两组数据。否则两种优化混在一起无法判断路由策略是否真的合适。另一个容易忽略的问题是 token 估算误差。假如estimate_tokens低估了实际 token 数成本统计就会偏乐观。生产环境里成本统计必须以实际扣费回执为准不要用估算值做对账。5.3 在测试环境做质量回归路由优化不能只看钱还要看效果。建议建立一个小规模测试集里面包含三类请求小模型应该能处理的简单请求。必须由大模型处理的高难度请求。边界请求比如超长输入、低质量 prompt、多语言混合内容。每次调整路由策略后跑一遍测试集记录模型选择结果和质量评分。如果小模型在简单请求上出现明显下降需要调整路由规则或质量评分权重。6. 常见问题与排查路径6.1 路由结果不稳定现象同一个请求在不同时间被路由到不同模型。排查路径确认请求参数是否一致特别是task_type是否由上游传递。检查输入长度是否接近阈值estimate_tokens可能因为字符集不同产生偏差。检查配置是否被动态更新规则表是否被中途修改。解决方案是把路由决策结果连同输入摘要写入日志。出现问题时可以回放当时的请求和配置版本。6.2 成本没有下降反而上升现象接入路由器后总成本更高。常见原因小模型需要多次重试才能达到效果重试导致 token 消耗增加。回退机制过于宽松大量请求第一次失败后都走了大模型。上游请求经过路由后输出长度估算不准大模型输出了更多 token。缓存策略变化原本命中的缓存失效。排查时先看“模型调用次数”和“平均输出 token 数”两个指标。如果小模型调用次数高但失败后重试次数也高说明小模型选择边界可能太激进。6.3 小模型抢占高价值请求现象代码生成或复杂推理请求被路由到小模型用户反馈答案质量差。原因通常是任务类型识别不准。比如用户用“帮我看看这个命令有没有问题”表达代码调试需求但上游把这句话分类成了普通问答。解决方式提升任务分类准确率。在路由规则中设置关键词扩展。引入质量反馈机制用户“不满意”或“重新生成”的请求下次直接走大模型。6.4 日志和监控维度缺失现象优化上线后只能看到总账单无法定位是哪类请求贡献了大部分成本。这是最需要提前预防的问题。从第一天起就记录路由决策、token 用量、模型名称、任务类型、耗时和错误状态。没有这些数据任何成本异常都无法快速定位。7. 生产环境落地的关键点7.1 配置外置与动态更新模型路由的配置变化非常频繁。新模型发布、价格调整、业务任务类型变化都会影响路由策略。配置应该放在独立配置中心而不是编译进代码。生产环境至少需要配置版本管理。灰度发布能力。配置变更后自动加载。变更审计日志。7.2 超时、重试与熔断每个模型调用的超时时间不同。小模型响应快大模型在长上下文下可能很慢。路由器需要为不同模型设置不同的超时时间不能共用同一个值。重试需要考虑两个层面网络或服务端错误例如 429、5xx可以重试。模型输出质量不合格只能走回退逻辑。如果某个模型连续失败比如连续 5 次超时或 5 次返回空内容应该触发熔断暂时把请求切到其他模型并发送告警。7.3 安全、权限与合规模型路由器会暴露模型调用能力需要严格控制访问权限。内部服务通过 API Key 或服务账号访问路由器。外部用户请求不能直接指定模型名称。需要记录输入内容区分哪些字段可以进入模型、哪些字段必须脱敏。对于涉及个人信息的请求路由日志不能完整保存原文。模型路由虽然能降低成本但不应成为数据合规的例外点。日志中保存最小必要字段并在保存前进行敏感信息过滤。7.4 生产部署前检查清单上线前可以按下面这个清单逐项确认检查项确认内容模型可用性候选模型 API 是否可用是否有配额限制单价确认输入输出单价是否与合同或控制台一致Tokenizer 验证估算 token 与实际 tokenizer 的误差是否在可接受范围超时配置每个模型是否设置了独立超时时间回退策略回退重试次数是否限制是否会触发告警日志字段是否记录了请求 ID、模型、token、成本、错误信息质量测试集简单请求和高难度请求是否都覆盖灰度计划能否先切 10% 流量观察后再放量回滚方案配置是否可以快速一键回滚成本监控是否按模型和任务类型设置成本告警这张清单同样适用于学习环境之外的所有阶段。不要在没有质量测试集和日志指标的情况下直接全量发布。8. 从路由器到更细粒度的成本治理模型路由器不是成本优化的终点。它是一套机制的入口请求分类、能力评估、成本计算、质量反馈、灰度实验、指标监控这些能力组合起来才构成完整的成本治理体系。对新手来说最有价值的练习不是直接搭一个生产级路由器而是先用最小规则路由跑通流程记录 1000 条真实请求统计其中高频任务类型和成本分布。有了真实数据再逐步把规则改成打分路由把小模型的选择边界调整到合理范围。这篇文章主要聚焦在模型选择层。后续可以继续深入三个方向一是基于 embedding 的语义路由把请求向量化和历史效果做匹配二是基于强化学习的路由策略让模型选择随质量反馈自动优化三是把路由器接入 MCP 或 Agent 工具链在多个工具和模型之间统一调度。每个方向都需要稳定的日志和评估体系支撑否则再复杂的路由算法也缺少判断依据。