一把 key 上按任务类型分流：分类、摘要与写代码各派给谁

为什么按名气选模型通常是错的

很多团队在聚合站上只挂一个「最强」模型，结果是：批量打标这种高频、低难度的任务付出了不必要的成本，而真正需要长上下文推理的任务又因为上下文被截断而表现不稳。

选后端应该看任务的三件事：单次调用的难度、调用量的大小、输出是否可校验。名气只说明它在某些公开评测上的位置，不说明它在你的任务上的性价比。

三个判断维度

• 难度：输入是否需要多步推理，还是模式识别即可。分类、打标、路由基本属于后者。
• 量级：一天几百次和一天几十万次，最优选择完全不同。高频任务对单价和延迟敏感。
• 可校验性：输出能被程序自动检查（如必须落在固定标签集内、必须有可通过的测试）时，可以放心用更便宜的后端，用校验兜底。

决策表：按任务性质挑后端

| 任务性质 | 典型场景 | 关注点 | 选型倾向 |
| --- | --- | --- | --- |
| 廉价分类 / 打标 | 内容分桶、意图识别、情感极性、是否相关 | 单次成本、吞吐、标签稳定性 | 廉价快速的中小模型；输出做标签集约束 |
| 抽取与结构化 | 从文档里抽字段、转 JSON | 指令遵循、格式稳定性 | 中等规模模型 + 严格 schema 校验 |
| 摘要 / 归纳 | 会议纪要、长文压缩、多文档合并 | 长上下文、信息不丢失 | 长上下文能力强的模型；必要时分段再合并 |
| 长文推理 / 分析 | 合同条款比对、多跳问答、复杂规划 | 推理深度、上下文窗口 | 推理能力更强的旗舰模型，量小但要求高 |
| 代码生成 / 改写 | 写函数、补测试、跨文件重构 | 代码语料覆盖、长文件理解 | 代码能力突出的模型；用编译或测试做验收 |
| 对话与客服 | 多轮问答、话术生成 | 延迟、语气一致性 | 延迟低的通用模型；用固定系统提示稳定风格 |

表里不给具体型号，因为模型迭代快，而任务性质相对稳定。判断方法比型号更耐用。

分类任务：优先压低单价，再用约束保质量

分类类任务的关键不是模型多聪明，而是输出可控。做法：

1. 把候选标签写进系统提示，明确「只能输出标签之一」。
2. 用结构化输出或简单解析做校验，不合格就重试一次或转人工。
3. 先用少量样本对比两三个廉价后端的准确率，取满足阈值里最便宜的那个。
4. 定期抽样复检，防止输入分布漂移后准确率悄悄下滑。

这类任务通常占调用量的大头，把它的单价降下来，整体成本结构才会改变。

摘要与长文推理：先解决上下文，再谈模型

摘要类任务最常见的失败不是模型不够强，而是内容被截断。上线前先确认：待处理文本的长度分布、目标模型的实际上下文窗口、以及超长时是分段还是换模型。

• 单文档摘要：一次调用通常够用，重点是提示里约束长度和保留项（人名、数字、结论）。
• 多文档合并：先分段摘要，再做一次二级归并，比硬塞进一次调用更稳。
• 长文推理：需要跨段建立关系时，才值得上旗舰模型；如果只是压缩信息，用长上下文的通用模型即可。

代码任务：以可执行结果为准

代码生成的选型不该靠主观感受，而该靠通过率。准备一组来自你自己仓库的题目（修 bug、加测试、补边界），跑一遍候选后端，记录一次通过率和平均重试次数。

• 单函数补全：中小模型往往够用。
• 跨文件重构、需要理解调用链：优先代码能力强的旗舰模型。
• 无论哪个后端，都要用编译、类型检查或测试作为验收门，把「模型可能写错」当成常态而非意外。

在聚合站上怎么落地这套分流

一把 key 调多个模型，好处是分流不需要维护多套账号和计费。实践上：

• 按任务建路由：在应用层写一个 task → model 的映射表，而不是在业务代码里散落模型名。
• 统一参数层：温度、最大输出长度、超时按任务设定，不随模型改。
• A/B 对比：新模型上线时，用同一批历史输入回放，比较质量与成本再切换。
• 回落链：主模型超时或返回格式不合格时，自动切到备选，并记录回落率。回落率高说明选型不对，而不是模型坏了。
• 按任务打标计量：在日志里带上任务类型，才能看清成本花在哪类请求上。

关于成本的正确预期

在这个聚合站上，用户侧按官方价 ×1.3 扣费，贡献 key 按官方价 ×1.1（优质 ×1.2）返 USDC。也就是说，聚合本身提供的是一把 key、多个模型、无 KYC、USDC 充值的便利，而不是把单价打到远低于官方价的折扣。

真正的成本优化来自分流本身：把高频低难度任务放到便宜的后端，把旗舰模型留给真正需要它的少数请求。这个比例调好了，账单结构的变化远大于换供应商。

一个可以直接照做的起步流程

1. 从日志里取一周真实请求，按任务类型打标。
2. 统计每类的调用量占比和平均输入/输出长度。
3. 对占比最高的两类任务，各挑两个候选后端做小样本对比。
4. 定下 task → model 映射和回落链，写进配置而非代码。
5. 每月复检一次：准确率、回落率、每类任务的单位成本。

按任务性质选模型，本质是把「选模型」从一次拍板变成一条可持续维护的路由策略。模型会换，方法不会。