小模型和大模型怎么搭配？低成本AI系统的分层架构

资料核验日期：2026-08-05。涉及产品版本、地区、价格或政策时，发布前仍应再次检查官方页面。

核心结论

• 先用规则，再用模型。能由代码确定完成的任务，不必消耗生成模型。
• 小模型适合可验证任务。格式、字段和结果可以自动检查时，降本最稳。
• 大模型负责复杂性和高风险。不是所有请求都值得进入最强模型。
• 失败要可升级。低置信度、校验失败或用户不满意应进入更强层级。
• 成本必须包含返工。便宜模型造成的重试和人工修复可能超过单价差。

分层架构的核心不是模型大小，而是任务责任

小模型可以承担高频、低风险、可程序校验的任务；大模型负责复杂推理、模糊决策、跨资料整合和高价值输出。规则引擎则负责确定性判断。把所有请求都交给最大模型，往往成本高且不必要；把所有请求都交给小模型，又会放大返工和错误。

一个实用的四层架构

哪些任务优先交给小模型？

• 输出结构固定并可Schema校验；
• 错误可以被程序快速发现；
• 单次价值低、请求量大；
• 输入短、领域边界清楚；
• 失败后可以无损升级。

例如邮件分类、意图识别、标签生成、简单实体抽取和模板化改写，通常比法律条款解释、复杂研究或大仓库代码重构更适合小模型。

什么时候必须升级大模型？

• 用户问题存在多重含义，且澄清成本高；
• 需要跨文档推理、证据比较或多步骤规划；
• 输出会触发外部写操作或重要业务决定；
• 小模型校验失败、低置信度或多次重试；
• 任务价值高于额外模型成本。

不要把“低成本”只理解成API单价

真实成本还包括重试、人工返工、错误事故、延迟等待、上下文重复、工具调用和运维复杂度。FrugalGPT与RouteLLM说明了模型级联和路由可以优化成本质量边界，但生产系统必须使用自己的任务分布验证。^[1][2]

上线步骤

1. 统计30天真实任务，按频率、风险、可校验性分类。
2. 为每类任务指定最低合格模型，而不是先指定统一模型。
3. 建立自动校验和升级条件。
4. 保存大小模型的双跑样本，计算质量差与成本差。
5. 灰度将低风险流量迁移到小模型。
6. 每次模型更新后重新跑评测集。

一个内容生产系统的分层示例

选题分类、标题去重和关键词归类可以由规则或小模型完成；资料摘要和提纲生成交给通用模型；涉及最新事实的部分由联网研究模型处理；最终发布前再由强模型检查事实、逻辑和遗漏，并由人工审核。这样并不是为了让每一步都“用AI”，而是把不同难度放到最低合格层级。

评估时不要只比较模型单价。假设小模型一次只花强模型的十分之一，但20%的任务需要重试两次、5%的任务造成编辑返工，那么真实节省会明显缩水。应计算每完成一项合格任务的平均成本，而不是每次API请求的平均成本。

分层系统的验收指标

• 各层任务成功率与升级率；
• 严重错误是否被自动校验拦截；
• 升级后能否解决原问题；
• 平均每个合格结果的总成本；
• 高峰期P95延迟与队列长度；
• 人工返工时间是否真实下降。

分层架构最常见的失败方式

• 为了省钱，把所有任务都先交给小模型，导致大量隐藏错误；
• 升级条件只看回答长度或自报置信度，没有程序校验；
• 不同层使用不同提示词，难以判断质量差来自模型还是配置；
• 强模型失败后继续无限重试，没有人工接管；
• 只计算API费用，不计算人工复核和事故成本；
• 模型版本更新后没有重新测升级阈值。

较稳妥的做法是先让小模型只承担一两类明确任务，证明成功率和成本收益后再扩展。分层架构的复杂度也需要被证明有价值，否则“所有任务用一个合适的中档模型”可能更简单可靠。

如何确定升级阈值？

先用历史样本测出小模型在哪些条件下明显退化，例如输入超过某长度、需要三步以上推理、包含多个附件或出现高风险关键词。把这些条件作为初始升级规则，再用线上数据调整。阈值应同时限制误放和过度升级：前者伤质量，后者伤成本。

常见问题

文章局限

• 不同模型层级和价格变化很快，文章提供架构方法而非固定产品清单。
• 涉及高风险自动决策时，即使使用强模型也应保留人工确认。

参考来源

1. FrugalGPT：How to Use LLMs While Reducing Cost（核验于 2026-08-05）
2. RouteLLM（ICLR 2025）（核验于 2026-08-05）
3. OpenAI：Models（不同能力与成本层级）（核验于 2026-08-05）
4. AWS：智能提示路由（核验于 2026-08-05）

更新记录

• 2026-08-05：首次整理并核验官方或一手资料，建立可复用流程与检查清单。