核心要点

  • 模型选型不是选最强的,是选最合适的:2026 年前沿模型能力差距在缩小(AA Index 60-70 区间密集),但价格差距仍达 3-5 倍。选型的核心是在预算约束下找到能力-成本-上下文的最优组合,而非盲目追求最高分。

  • 三轴决策框架:能力轴(AA Intelligence Index / Arena Elo)、成本轴($/百万 input/output token)、上下文轴(窗口长度 × 实际可用率)。三轴必须同时看:单看能力会超预算,单看成本会选到能力不足的模型,单看上下文会忽略「标称 1M 实际 128K 可用」的陷阱。

  • 真实对照案例:Grok 4.6(AA Index 61,$2/$6)vs Claude Sonnet 5(AA Index ~65,$2/$10 永久化,news-7693)——能力差距 4 分,成本差距 40%(output 端),选型取决于任务对 output 质量的敏感度。Agent 高频调用场景选 Grok 4.6 更经济,高质量写作/推理场景选 Sonnet 5 更划算。

  • 分层路由策略:不是「选一个模型」,而是「按任务分层路由」——简单任务用便宜模型(Index 40-50,$0.5/$1.5),中等任务用中档模型(Index 55-65,$2/$6),复杂任务用旗舰模型(Index 70+,$5/$15)。OpenRouter 等聚合平台支持动态路由,可把成本降低 50-70%。

  • 成本可见性与持续优化:选型不是一次性决策,而是持续优化过程。建立三层监控(实时 token 消耗、每日成本趋势、每月 UWP 每美元有用工作量),当 UWP < 1 时重新评估选型,当 UWP > 10 时增加投入。

简要回答

模型选型的核心是建立「能力(AA Index)× 成本($/token)× 上下文(窗口)」三轴决策框架。先按任务分层(简单/中等/复杂),再在每层内找能力-成本最优组合。真实案例:Grok 4.6(Index 61,$2/$6)vs Claude Sonnet 5(Index ~65,$2/$10 永久化)——能力差距 4 分,成本差距 40%,选型取决于任务对 output 质量的敏感度。选型不是一次性决策,需建立三层监控(实时/每日/每月)与 UWP(每美元有用工作量)持续优化。

标准回答

一、为什么模型选型是工程决策而非技术决策

2026 年前沿模型的能力差距在缩小:AA Intelligence Index 60-70 区间密集分布了 Grok 4.6(61)、Claude Sonnet 5(~65)、GPT-5.6-Cyber(~68)等多个模型,但价格差距仍达 3-5 倍。这意味着「选最强的」不再是理性决策——超预算的模型即使能力高 10%,也会因为调用量受限而实际产出更少。

选型的本质是在预算约束下最大化有用工作量,而非最大化能力分数。

二、三轴决策框架

选型必须同时看三个轴:

能力轴:AA Intelligence Index(第三方跨模型综合基准,0-100 可比指数)或 LMSYS Arena Elo(人类偏好投票)。两者互补:AA Index 侧重可复现任务表现,Arena 侧重主观偏好。选型时两者都看,避免「讨喜但不准」或「准但不讨喜」。

成本轴:$/百万 input/output token。注意 input 和 output 价格差距可达 3-5 倍(如 Claude Sonnet 5 $2/$10),选型时必须按任务的实际 input/output 比例计算加权成本,而非只看 input 价格。

上下文轴:标称窗口长度 × 实际可用率。很多模型标称 1M token 上下文,但实际在 128K 后性能显著下降(「lost in the middle」问题)。选型时必须实测任务场景下的实际可用窗口,而非相信标称值。

三轴的权重按任务类型调整:Agent 高频调用场景成本权重最高(调用量决定总成本),写作/推理场景能力权重最高(质量决定产出价值),长文档处理场景上下文权重最高(窗口不足直接失败)。

三、真实对照案例:Grok 4.6 vs Claude Sonnet 5

Grok 4.6:AA Index 61,$2/$6(input/output 百万 token),128K 上下文。
Claude Sonnet 5:AA Index ~65,$2/$10(input/output 百万 token),200K 上下文,news-7693 报道其介绍价永久化(原定 9 月涨至 $3/$15,8 月 10 日宣布取消)。

能力差距 4 分(~6%),成本差距:input 相同,output 差 40%。选型取决于任务对 output 质量的敏感度:

  • Agent 高频调用场景(如客服 Agent 每天 10 万次调用):选 Grok 4.6,output 成本节省 40%,能力差距 6% 在客服场景可接受
  • 高质量写作/推理场景(如技术文档、代码审查):选 Sonnet 5,output 质量提升 6% 值得 40% 成本溢价
  • 长文档处理场景(如 100K+ PDF 分析):选 Sonnet 5,200K 上下文 vs 128K 上下文,实际可用窗口差距更大

四、分层路由策略

选型不是「选一个模型」,而是「按任务分层路由」:

  • 简单任务(文本分类、格式转换、简单问答):用便宜模型(AA Index 40-50,$0.5/$1.5),如 GPT-4.1-nano、Claude Haiku
  • 中等任务(摘要、代码生成、数据分析):用中档模型(AA Index 55-65,$2/$6),如 Grok 4.6、Claude Sonnet 5
  • 复杂任务(多步推理、长文档理解、高质量写作):用旗舰模型(AA Index 70+,$5/$15),如 Claude Opus 4.8、GPT-5.6

OpenRouter 等聚合平台支持动态路由,可按任务类型自动分发,可把成本降低 50-70%。

五、成本可见性与持续优化

选型不是一次性决策,而是持续优化过程。建立三层监控:

  • 实时:token 消耗速率、单任务成本
  • 每日:日成本、UWP(每美元有用工作量 = 业务价值 / AI 支出)
  • 每月:成本趋势、预算执行、选型复盘

UWP 是核心指标:UWP > 10 增加投入,UWP 1-10 优化成本,UWP < 1 重新评估选型。当模型降价或新模型发布时,重新跑三轴框架,更新路由策略。

常见误区

⚠️ 常见踩坑

误区一:只看 input 价格不看 output 价格。很多任务 output token 是 input 的 2-3 倍(如长文本生成),output 价格差距 40% 意味着总成本差距 60%+。必须按任务的实际 input/output 比例计算加权成本。

误区二:相信标称上下文长度。很多模型标称 1M token 上下文,但实际在 128K 后性能显著下降(「lost in the middle」)。选型时必须实测任务场景下的实际可用窗口,而非相信标称值。

误区三:选一个模型打天下。不同任务对能力、成本、上下文的需求差异巨大,用旗舰模型做简单任务是浪费,用便宜模型做复杂任务是失败。必须按任务分层路由。

误区四:选型是一次性决策。模型价格和能力在快速变化(如 Claude Sonnet 5 介绍价永久化,news-7693),必须建立持续监控与复盘机制,当 UWP < 1 时立即重新评估。

追问

追问 1如何实测模型在实际任务场景下的表现,而非依赖第三方榜单?

建立内部评测集是核心:从生产任务中抽取 100-200 个代表性样本(按任务类型分层,确保覆盖简单/中等/复杂三档),用相同 prompt 在候选模型上跑,人工评分或自动评分(如 ROUGE、BERTScore、任务特定指标),计算加权平均分。与第三方 AA Index 对比,偏差 > 10% 时以内部评测为准。关键是评测集必须覆盖生产分布——不能只挑简单样本自欺欺人。建议每月更新评测集,跟踪模型版本迭代对实际任务表现的影响。

追问 2如何设计分层路由策略,让简单任务自动分发到便宜模型、复杂任务自动分发到旗舰模型?

规则引擎或轻量分类器做任务分级:输入长度 < 1K token + 无复杂推理 = 简单任务(便宜模型),输入 1K-10K + 单步推理 = 中等任务(中档模型),输入 > 10K + 多步推理 = 复杂任务(旗舰模型)。OpenRouter 支持按 task_type 参数自动路由,也可自建路由层。更精细的方案是用小模型做前置分类器,判断任务复杂度后路由。关键约束:路由层必须能处理分级错误——当简单任务被误分到旗舰模型时,成本超支但质量无损;当复杂任务被误分到便宜模型时,必须能检测质量下降并自动升级到旗舰模型重跑。

追问 3UWP < 1 时如何快速定位是模型选错了还是任务定义错了?

UWP = 业务价值 / AI 支出。UWP < 1 时先检查三层问题:任务层——该任务是否适合 LLM(确定性任务不该用模型,用正则/规则更快更准);模型层——是否过强(简单任务用了旗舰模型,杀鸡用牛刀);prompt 层——是否低效(冗余上下文、重复调用、格式错误导致重试)。逐层排除后才是选型本身的问题。常见陷阱:业务价值量化不准确(如客服 Agent 节省的人工成本被低估),或 AI 支出计算遗漏了隐藏成本(如 token 缓存失效导致的重复计费)。

追问 4如何处理模型降价或新模型发布对选型的影响?

建立月度复盘机制:每月 1 号跑一次三轴框架(能力/成本/上下文),对比上月数据。当新模型发布或现有模型降价 > 20% 时,触发临时复盘。用 A/B 测试验证新模型在实际任务上的表现,而非直接切换——新模型的能力分可能高但实际任务表现未必更好(评测集偏差、分布漂移等)。切换时保留回滚路径:新旧模型并行运行 1-2 周,监控质量指标与成本指标,确认无退化后再完全切换。关键约束:不要因为「新模型分数高」就急于切换,生产环境的稳定性优先于榜单排名。

追问 5多模型路由中如何处理一致性问题(不同模型输出格式不同、行为不同)?

统一输出 schema 是基础:所有模型必须返回相同 JSON 结构(用 JSON Schema 约束),格式不符时自动重试或降级到备用模型。行为一致性通过 system prompt 控制:所有模型使用相同的 system prompt 模板,仅调整 task-specific 部分。关键约束:路由层必须能检测格式错误并自动降级,否则一致性承诺就是空话。更深层的一致性问题是「语义一致性」——不同模型对同一指令的理解可能有细微差异(如「总结」的长度、风格),需要在评测集中覆盖这类边界情况,并在 system prompt 中明确约束。

🔗 相似问题

同一考点的不同问法,换着练更稳

延伸学习

按主题分类的相关资源,便于系统复习