为每次调用使用一个模型可能会造成不必要的高昂成本，但路由并不一定自动带来改进。
一个团队可能会发现分类、提取、起草和复杂推理在质量和延迟方面有不同的要求。路由可以利用这些差异。但它也可能增加一个分类器调用、提供商故障模式、不一致的安全行为以及更多的评估工作。唯一站得住脚的节省成本主张，是根据你测得的 token 用量、当前提供商价格和质量门槛计算得出的。
这是多模型编排：在明确的质量、延迟、隐私和成本约束下，为特定的调用类型选择一个模型或专用服务。
本文将介绍相关模式、路由逻辑、权衡，以及逐步实施指南。
为什么单一模型并非最佳选择
提供商目录经常发生变化，但工作负载仍可以定义功能层级：
高能力推理层级： 适用于复杂规划或分析的候选模型。请在你自己的案例中评估准确性、工具行为、尾部延迟和生成的推理 token 总数。
通用层级： 适用于面向用户的起草和混合知识工作，其中质量重要但可能不需要扩展推理。
低延迟层级： 适用于有界分类、提取和重写任务。较小的模型并不保证足够的准确性或更低的端到端延迟。
本地或小模型层级： 当数据本地性、离线运行或边际服务成本重要时适用。在比较时应包括硬件、运维、能耗、并发性和量化影响等因素。
专用服务（嵌入、重排序、视觉、语音）：针对具体操作与通用模型进行比较；专用性并不能证明质量更高或总成本更低。
做决策时应查看当前的模型和定价页面：OpenAI 模型和定价、Anthropic 模型和定价，以及Google 模型和定价。不要在长期架构决策中固化可用性或价格。
典型AI应用会进行多种不同类型的大语言模型调用。每次调用都有自己的要求：
- 分类用户意图：使用标注数据集（包括模糊和超出范围的案例）评估低延迟候选模型。
- 提取结构化数据：衡量字段级准确性和模式有效性，而非模型大小。
- 生成面向用户的响应：衡量事实性、政策合规性和尾部延迟。
- 总结过往对话：测试是否遗漏了决策、名称、约束和否定内容。
- 背景批量处理：衡量吞吐量、重试成本和截止时间完成情况。
不要假设最便宜的候选模型就足够，或最昂贵的候选模型就是最佳。应使用相同的评估数据集对每条路径进行验证。
通过遥测数据计算节省成本
针对每种调用类型，收集以下信息：
- 每月调用次数；
- 输入、缓存输入和输出的 token 分布；
- 重试率和级联率；
- 工具、搜索、批量处理或托管费用；
- 延迟百分位数；以及
- 路由发布评估的通过率。
使用当前价格计算每条候选路由的成本：
monthly route cost = calls × (
input_tokens × input_price
+ cached_tokens × cached_price
+ output_tokens × output_price
) + tool_charges + hosting + expected_retry_cost
仅对通过相同质量和安全发布标准的候选路由与基线进行比较。在结果旁边报告所作的假设。一个节省了 token 成本但增加了人工修正、事故或延迟的路由，总体上可能成本更高。
如果遥测数据不可用，请先运行影子评估。不要从通用流量拆分中发布节省百分比。
基本编排模式
生产环境的多模型系统中反复出现以下几种模式：
模式1：按任务路由
不同类型的任务交给不同模型。这是最简单的模式。
# Resolve these aliases from reviewed configuration; provider IDs change.
def route_request(task_type):
if task_type == "classification":
return SMALL_TIER
elif task_type == "extraction":
return EXTRACTION_TIER
elif task_type == "summarization":
return SUMMARY_TIER
elif task_type == "user-facing-response":
return RESPONSE_TIER
elif task_type == "complex-reasoning":
return REASONING_TIER
任务由调用代码分类（代码知道自己要请求什么）。路由是确定性的，易于调试。
模式2：按复杂度路由
系统估算每个请求的复杂度，并据此路由。
def route_by_complexity(request):
complexity = estimate_complexity(request)
if complexity < 3:
return "small"
elif complexity < 7:
return "mid"
else:
return "flagship"
复杂度可以通过启发式方法（请求长度、关键词检测）估算，也可以通过模型（由低成本分类器为请求评分）估算。这种模式适合处理同一任务类型中难度不同的情况。
模式3：级联路由
先尝试低成本模型。如果输出良好，就直接使用；否则升级到更昂贵的模型。
def cascade(request):
cheap_response = call_model("small", request)
if is_acceptable(cheap_response):
return cheap_response
return call_model("flagship", request)
如果“可接受”能够通过置信分数、验证器或另一个质量检查模型来判断，这种模式就很有效。它的优势很明显：大多数简单请求由低成本模型回答，只有困难请求才会到达昂贵模型。
模式4：专用路由
让专用模型处理专用任务：
- 嵌入：使用专用嵌入模型（比使用聊天模型生成嵌入便宜得多）。
- 重排序：使用专用重排序模型。
- 视觉：使用视觉专用模型分析图像。
- 语音：使用语音模型进行转录/合成。
- 代码：使用代码专用模型处理代码任务。
专门化或规模较小的模型可能在特定任务上更快、更便宜或表现更好，但这些优势并不能仅从模型的标签中得出。请对具体模型、提供商、提示词、语言、延迟百分位数、价格表和评估集进行基准测试。
模式5：按提供商路由
使用多个提供商的模型，以获得冗余能力和定价议价空间。
providers = ["openai", "anthropic", "google"]
preferred = "anthropic" # primary
fallback = "openai" # fallback
def call_with_failover(request):
try:
return call(preferred, request)
except (RateLimit, ProviderError):
return call(fallback, request)
这样可以抵御单一提供商宕机和速率限制，还能利用定价变化——当某个提供商降价时，可以将更多流量转移过去。
真实示例：客户支持AI
下面通过客户支持AI具体说明多模型编排的用法。
系统对每张工单执行以下步骤：
步骤1：分类意图。 客户正在询问什么？
路由候选：一个能通过已标注意图集评估的低延迟模型。
**第2步：判断紧急程度和情绪。**客户是否感到不满？是否紧急？
路由候选：仅当紧急情况的假阴性符合单独定义的安全阈值时，使用同一模型；情绪并非紧急性的可靠替代指标。
第3步：检索相关知识。
路由候选：嵌入检索加重排序器，并在针对工单场景构建的检索集上进行评估。
第4步：判断AI能否回答，还是需要转交人工。
路由候选：专门针对转交召回率进行评估的模型。规则应强制将账户访问、安全、法律、财务或其他政策规定的情况转交人工。
第5步（如果AI能回答）：生成面向客户的响应。
路由候选：一个质量更高的通用模型。在事实性、政策、隐私和语气通过发布标准之前，仅保留为草稿。
第6步（如果AI无法回答）：为人工客服生成摘要。
路由候选：一个成本较低的模型，其摘要能够保留问题、证据、尝试的步骤、客户约束和不确定性。
**第7步：质量检查。**响应是否符合我们的标准？
路由候选：确定性检查加上经过校准的判断模型。判断模型并非独立的保证；应由人类对它的决策进行抽样验证。
对每一步进行测量，然后使用测得的 token 分布、当前价格、转交比例、重试比例和人工审核成本，填写上方的成本公式。此示例故意不提供通用的节省估算：工单构成和接受阈值决定了结果。
路由逻辑
实现路由有以下几种方法：
方法1：按任务类型硬编码
最简单的方式。你知道正在调用什么任务，然后选择模型。
def classify(text):
return openai_client.chat.completions.create(
model=SMALL_TIER, # your provider's current small model
messages=[{"role": "user", "content": f"Classify: {text}"}],
)
def respond(context, query):
return claude_client.messages.create(
model=RESPONSE_TIER, # reviewed config alias, not a frozen provider ID
max_tokens=1024,
messages=[{"role": "user", "content": f"Context: {context}\n\nQuery: {query}"}]
)
优点：透明、易于调试、易于修改。 缺点：无法适应同一任务类型内部的请求复杂度差异。
方法2：路由模型
使用小型模型对每个请求分类并进行路由。
ROUTER_PROMPT = """
Classify this request as: trivial, moderate, or complex.
Output one word.
Request: {request}
"""
def route(request):
classification = small_model_call(ROUTER_PROMPT.format(request=request))
return MODEL_BY_COMPLEXITY[classification]
优点：能适应同一类别内的复杂度变化。 缺点：增加延迟（路由模型调用）、增加一个故障点，并且需要调优。
方法3：基于嵌入的路由器
对于符合已知模式的请求，使用与过往示例的嵌入相似度。
def route(request):
embedding = embed(request)
closest = find_nearest_example(embedding)
return closest.suggested_model
优点：速度快（只需一次向量查找），而且会随着数据增加变得更智能。 缺点：需要构建带标签的示例集。
方法4：级联
先尝试低成本模型；必要时升级。
def cascade(request):
cheap = small_model_call(request)
if validates(cheap):
return cheap
return flagship_call(request)
优点：自适应、平均成本低。 缺点：需要升级时速度较慢（要调用两次），并且需要可靠的验证。
在实践中，许多生产系统采用混合方式：主要任务类型使用硬编码路由，对特定高波动子类型使用级联。
常见误区
应避免以下错误：
误区1：以降低质量为代价优化成本
把所有任务路由到小型模型，很容易看到成本下降；质量随之下降却更难察觉。路由变更必须始终搭配质量监控。
一种有用的实践：在样本覆盖重要的输入类别和失败模式之前，对更便宜的路由进行影子测试或A/B测试。固定测试一周本身并不能构成证据。在预声明的质量和安全标准得到满足之前，不要部署该更改。
误区2：路由器设计过度
一个具有许多任务类型和不透明逻辑的路由器可能比它所替代的路由更难维护。从你的测量结果所支持的最少路由数量开始。
仅当某条路由改变了运营决策，并且对可衡量约束的改进足以证明其维护责任、测试和回退路径值得投入时，才添加该路由。
误区3：忽视延迟
价格较低的模型不一定更快。应分别测量延迟和质量。级联（先尝试一个模型，再回退）在回退情况下至少会增加一次额外尝试，可能会显著增加面向用户的流程的尾部延迟。
对于面向用户且对延迟敏感的响应，应在通过率和尾部延迟两个方面，将直接路径与级联路径进行对比评估。级联路径通常在批量或异步工作中更容易被容忍，但正确的路径取决于具体的工作负载。
误区4：不处理提供商故障
依赖多个模型，也意味着拥有多种失败方式。旗舰模型可能宕机、触发速率限制或API密钥过期。路由逻辑需要回退机制。
为速率限制、超时和提供商错误定义明确的处理方式。只有在跨提供商回退的数据处理条款、区域路径、工具/模式约定和评估结果均可接受时，才应采用跨提供商回退。否则应以安全方式拒绝执行、排队或转交人工；返回明显更差的答案并不能算作可用。
误区5：不衡量每条路由的质量
你需要知道哪条路由表现良好、哪条表现不佳。这就需要评估，最好实现自动化。
一套实用设置是：记录每次生产调用使用的模型、请求、响应，并在可能时记录质量信号（用户反馈、下游指标、自动评估）。汇总每条路由的指标，在用户投诉前发现质量漂移。
重新验证当前依赖项
模型ID、退役日期、上下文限制、价格、速率限制、区域处理和结构化输出/工具语义可能独立发生变化。在更改别名之前，请重新查看提供商的当前文档并重新运行路由评估。与OpenAI兼容的API层并不保证模式、工具行为、token 计数、安全策略或数据处理方式等同。
入门清单
如果你要从头构建多模型系统，或者从单一模型迁移，可以遵循以下步骤：
-
**梳理任务。**你的应用会进行哪些类型的大语言模型调用？大致频率如何？大致成本如何？
-
**按复杂度分类。**将每种任务类型划分为简单、中等或复杂，并匹配相应的模型层级。
-
**构建路由器。**先采用硬编码的按任务路由，不要过度设计。
-
定义失败行为。 根据后果和数据策略，使用经过测试的回退方案、队列、安全拒绝响应或转交人工。
-
**衡量每条路由的质量。**设置日志和基本评估。你需要知道质量能否保持。
-
**迭代。**质量保持稳定时，将任务迁移到更便宜的模型；质量下降时，再迁回昂贵模型。持续调整。
-
**持续调优。**模型会变化，新模型会发布，价格会变动。2026年5月最优的路由设置，到2026年11月可能已经不再理想。
仅在有证据支持的情况下进行路由
当调用类型确实不同且每条路由均经过评估时，多模型编排可以降低成本或延迟。但它也可能增加运营成本并降低一致性。应发布测量的基线、路由结果、质量门限和采样周期，而不是做出普遍的节省声明。
路由条件可能较为简短；实际的生产工作包括配置控制、评估、可观测性、隐私审查、重试语义和备用方案。
梳理你的任务，对可行的候选方案进行基准测试，仅在有证据支持的情况下进行路由，并在发布后持续测量。
