模型分层选型

Model Tiering

PE-M-01内容已写满G07模型差异与迁移第 7 层

模型迁移分层成本

一句话结论

分层选型的产出不是一张模型价目表，而是一张带评测基线与升级条件的档位表，它让成本与质量的分派可被度量、可被替换。

本页结构（可跳转）

机制图：请求按难度分派到不同档位、弱档失败再升档，以及「各档各自建基线 + 档位写成配置」两个前提。（本站自制）

01为什么需要它

同一套提示词在不同能力档与价位的模型上表现并不相同，而把所有请求都交给最强模型既不经济也不必要：分类、抽取与格式转换这类请求，在低价档上往往已经够用。

分层选型把请求按难度或价值分派到不同档位，让昂贵的能力只花在真正需要它的请求上，同时把成本、延迟与质量之间的关系从只能靠调提示词去挤，变成可以调节的参数。
分层的收益并非白来：跨档协作与失败升级都会推高 token 消耗，省没省必须按档记账之后再判断。

适用边界

分层选型处理的是分派问题，它不解决单次调用本身的正确性：同一档位内部仍然要靠提示词、结构化输出与校验回路来保证结果可用。另外，如果请求的难度在调用前无法判断，分派就只能靠猜，这时先积累评测集与失败样本，比急着切档更有价值。

02机制说明

分层选型包含三个决定：分层维度（按难度、按任务类型、按数据敏感度）、每层的模型选择，以及分派规则；分派规则可以是静态规则，也可以是轻量分类器，或者由强模型自己判断后再回填。

工程上有三条要点。
第一，每一层都要有各自的评测基线，档位差异必须被量出来，否则分派阈值只是猜测。
第二，必须保留升级路径：弱档处理失败或置信度不足时升级到强档，这比硬扛在弱档更可靠，但它并不自动更省——失败重试与跨档协作都会推高 token 消耗，省下的钱有没有被重试吃掉，要按档核算过才知道。
第三，模型代际更替很快，档位表应当写成配置而不是硬编码，换模型时只改配置并重跑该档的评测集。
监控侧要按层分别记录调用量、质量与成本，分派阈值才可能被持续校准；只记录总体成本，会看不见某一层悄悄退化。

03何时该用 / 何时不该用

按场景对照：先看条件，再看该怎么做。
类别	场景 / 条件（总结）	具体做法（细节）
该用	请求的成本敏感度或难度差异显著时	档位差异被量出之后，按档分派才可能比全程使用同一模型更划算，也更容易说清钱花在了哪里。
该用	存在数据敏感度分层需求时	把敏感请求限制在本地或私有部署的模型上，其余请求走托管档位。
不该用	未度量档位差异就分层	分派规则会引入新的不确定性，省下的成本可能被误分派吃掉。
不该用	把档位硬编码进业务代码	模型代际更替很快，替换模型应当只改配置并重跑该档评测。

04实验台

filemarkdown

查看代码

# 档位表：分层写成配置，而不是散落在业务代码里
tiers:
  cheap:
    model: 小模型
    use_for: [分类, 抽取, 格式转换]
    eval_set: evals/cheap.jsonl
    escalate_to: mid
  mid:
    model: 中档模型
    use_for: [摘要, 多步改写]
    eval_set: evals/mid.jsonl
    escalate_to: strong
  strong:
    model: 强模型
    use_for: [规划, 代码生成, 长链推理]
    eval_set: evals/strong.jsonl
    escalate_to: null

预期观察：换模型时只改 model 一处，并重跑该档评测集；任一档缺 eval_set 就说明该档还没有基线，分派阈值不可校准。

promptmarkdown

查看代码

你是请求分派器。读入一条用户请求，判断它属于哪一档，只输出一个 JSON 对象。
档位定义：
cheap：单步分类、字段抽取、格式转换、短文本改写
mid：摘要、多步改写、需要少量推理的问答
strong：规划、代码生成、长链推理、跨文档聚合
输出格式：{"tier": "cheap|mid|strong", "reason": "一句话依据", "confidence": 0.0 到 1.0}
同时符合多个档位时取更高的一档；无法判断时输出 strong，并写明无法判断、保守升级。

预期观察：输出能被解析成固定枚举，无法判断的请求落到保守档而不是猜档位；把分派结果与各档实际成本一并记录，才能看出阈值偏松还是偏紧。

05证据

主张官方用资深同事与初级同事的比喻区分两类模型，说明它们能承接的任务与所需的交代方式并不相同：分派应当先判断请求该落到哪一档，而不是让所有请求共用一套写法与一个模型。

分级official

来源S-0011 https://developers.openai.com/api/docs/guides/prompt-engineering

原文

展开原文关键句

A reasoning model is like a senior co-worker. ... A GPT model is like a junior coworker.

主张官方工程博客的实测显示，强模型带队、弱模型执行的分层组合在内部研究评测上比单一强模型高 90.2%（厂商自述内部评测）；同一页给出的代价是多 Agent 架构的 token 消耗约为普通对话的 15 倍，因此分层结构换来的是质量提升与显著上升的 token 消耗，两者必须一起记账（该实测对象是研究型多 Agent 系统，不是按请求分派的档位路由）。

分级official

来源S-0006 https://www.anthropic.com/engineering/multi-agent-research-system

原文

展开原文关键句

a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% ... multi-agent systems use about 15× more tokens than chats.

主张在推荐与排序类任务的可复现性研究中，高性能模型上更简单的提示常优于更复杂的提示且成本更低；该结论限于这一任务域，但它说明提示复杂度的最优值与档位相关，各档需要各自的提示写法与评测基线。

分级paper

来源S-0037 https://arxiv.org/abs/2507.13525

原文

展开原文关键句

For high-performance LLMs, simple prompts often outperform more complex ones while reducing cost.

06术语

术语模型分层选型　Model Tiering

界定按任务难度把请求分派给不同能力档与价位的模型，用路由在成本与质量之间取得平衡。

07失效模式

未度量就分层各档在目标任务上的差距没有被量出来，分派规则引入的不确定性可能抵消掉省下的成本。
只统计总体成本没有按层记录调用量、质量与成本，某一档悄悄退化时看不出来，往往等到用户投诉才被发现。
缺少升级路径与用量口径弱档失败后直接返回错误或降级结果，省下的成本被重试与人工兜底吃掉；跨档协作多花的 token 若不单独记账，分层会被误判为必然更省。
档位硬编码模型换代或价格调整后要改代码，替换周期变长，配置与评测基线逐渐脱节。

08在本站知识结构中的位置

所属分组: G07模型差异与迁移
依赖深度: 第 7 层（同层节点彼此无先后约束）

前置PE-C-01 架构在册→PE-M-01 本节点→后继PE-M-02

在交互全景图中定位本节点。