1. 模型选型这件事为什么越来越像配电脑而不是选手机这两年做应用落地我最大的感受是模型选型已经从“谁家榜单分高用谁”彻底变成了“按任务配模型”的活儿。榜单分数当然还看但真正决定项目能不能跑起来的往往是三件事——每百万 token 的单价、上下文窗口够不够塞、以及这个任务到底吃不吃推理深度。标题里提到的两个模型一个主打轻快低成本一个主打长上下文与综合能力正好代表了当下两条典型路线。这篇就按我实际做项目时的思路把价格、上下文、任务适配这三块掰开揉碎讲清楚顺带把选型时容易踩的坑一并交代。先说清楚这篇适合谁看如果你正在做 AI 应用的技术选型、成本核算或者手上有具体任务不知道往哪个模型上放那这篇基本能当一份对照手册用。如果你只是想了解大模型大概怎么回事也能看懂我会尽量用生活化的类比把参数讲明白。需要提前说明的是文中涉及的具体价格、上下文长度等数值是基于 2026 年 10 月这个时间点公开信息整理的参考量级各家调价和版本迭代都很快实际下单前务必以官方最新页面为准这点我在后面还会反复强调。我见过太多团队在选型上翻车的案例翻车方式高度雷同要么是拿最贵的模型跑所有任务账单出来吓一跳要么是图便宜把长文档任务塞进小窗口模型结果截断得七零八落返工成本远超省下的那点钱。所以这篇不打算给你一个“标准答案”而是给你一套判断框架——看完你自己就能算出该用哪个。2. 先把两个模型的定位摆正别一上来就比分数2.1 轻量路线与综合路线本质是两种成本结构标题里这两个模型从命名和定位上就能看出分野。轻量款Haiku 这一档的核心卖点是单位成本低、响应快适合高频、短平快、对延迟敏感的任务综合款Luna 这一档的核心卖点是上下文长、复杂任务处理能力强适合长文档、多步骤推理、需要“想清楚再答”的场景。这个分野不是随便分的背后是模型规模、训练成本、推理算力的差异。打个比方轻量模型像一辆省油的小排量代步车市区通勤又快又便宜综合模型像一辆能拉货能跑长途的皮卡油耗高但能干重活。你非要用代步车拉建材或者用皮卡天天买菜都不是不行就是浪费。我在实际项目里最常见的误区就是用一个模型打天下。要么全上综合款求稳要么全上轻量款省钱结果两头不讨好。正确的做法是按任务分层把不同复杂度的请求路由到不同模型上这套“模型路由”的思路后面会专门讲。2.2 价格对比不能只看单价要算“有效成本”很多人比价格就盯着每百万 token 的输入输出单价这其实只对了一半。真正该算的是有效成本——完成同一个任务总共花了多少钱。这里头有几个容易被忽略的变量重试成本轻量模型在复杂任务上答不对你得重试或者换模型兜底这部分开销要算进去。上下文浪费长上下文模型如果只用来处理短请求等于用大窗口装小内容单价再低也是浪费。输出长度差异同样的问题有的模型啰嗦有的精炼输出 token 数差一倍很常见输出单价通常比输入贵好几倍这个差异会被放大。我一般会用一个简单的公式估算单任务成本单任务成本 ≈ (输入token数 × 输入单价 输出token数 × 输出单价) × 平均重试次数这个公式看着简单但把“重试次数”这一项加进去很多选型的结论就变了。轻量模型单价可能只有综合款的三分之一甚至更低但如果它在你的任务上重试率高达 40%实际成本优势就没那么夸张了。2.3 上下文窗口不是越大越好而是“够用且不浪费”上下文窗口这块我的经验是按任务的最长输入来定留 30% 余量就够。综合款动辄几十万 token 的窗口确实能一口气吞下整本书但你要问自己我真的需要一次性塞这么多吗长上下文有两个隐性成本。第一是注意力稀释——输入越长模型对关键信息的抓取精度越容易下降尤其是关键信息埋在中间位置时业内常说的“中间遗忘”现象。第二是计费放大——长输入按 token 计费塞得越多花得越多而且很多场景其实用检索增强就能解决没必要全量喂进去。我的做法是短任务几千 token 以内用轻量款完全够中等长度几万 token看任务复杂度决定超长文档十万 token 以上才考虑综合款的长窗口而且优先配合分段处理或检索而不是无脑全塞。3. 价格与上下文对照一张表看清差异在哪3.1 关键参数横向对照下面这张表是我按 2026 年 10 月公开信息整理的参考对照数值是量级示意具体以官方为准对比维度轻量款Haiku 档综合款Luna 档选型含义输入单价每百万 token低约为综合款的 1/5 至 1/3较高高频短请求优先轻量款输出单价每百万 token低约为综合款的 1/4 至 1/3较高输出长的任务要重点算账上下文窗口中等通常十几万 token 量级长通常几十万 token 量级超长文档才需要综合款响应延迟快相对慢实时交互场景轻量款占优复杂推理能力中等适合结构化任务强适合多步推理难题别硬塞给轻量款典型适用场景分类、抽取、改写、客服问答长文档分析、复杂规划、代码重构按任务分层路由这张表最该记住的不是具体数字而是每一行的“选型含义”那一列。数字会变判断逻辑不会变。3.2 一个真实的成本测算示例假设你有个文档问答产品每天处理 1 万次请求平均每次输入 3000 token、输出 500 token。我按量级做个粗算单位百万 token轻量款输入 30 百万 token × 低价 输出 5 百万 token × 低价假设输入单价 0.3、输出单价 1.2示意值日成本约 9 6 15 个单位。综合款同样用量假设输入单价 1.5、输出单价 6示意值日成本约 45 30 75 个单位。差距是 5 倍。但如果你的任务里有一半是复杂问题轻量款答不好需要重试两次那轻量款的实际成本就变成 15 × 1.5 22.5 个单位差距缩小到 3 倍多。这时候更优的方案不是二选一而是简单问题走轻量款、复杂问题走综合款混合下来可能只花 30 个单位左右比全用综合款省一半多。提示上面所有单价都是示意值目的是演示测算方法。真实报价请查官方定价页而且要注意输入输出分开计价、缓存命中可能有折扣这些细节。3.3 上下文窗口的“够用线”怎么定我一般会先统计任务输入的 token 分布看 P9595% 的请求落在哪个区间。如果 P95 在 8000 token 以内轻量款的中等窗口绰绰有余如果 P95 到了 5 万 token就得看综合款了。剩下那 5% 的超长请求单独走异步批处理或者分段方案不要为了极少数请求把整体架构拖重。这个思路说白了就是按主流需求配资源长尾单独处理跟数据库分库分表、缓存分层是一个道理。4. 任务选型把任务分成四类答案自然浮现4.1 第一类高频短平快任务闭眼选轻量款这类任务的特征是输入短、输出短、逻辑简单、量大。典型代表文本分类、情感判断、关键词抽取、格式转换、简单客服问答、内容审核初筛。为什么这类任务轻量款完胜因为它们的“推理深度需求”很低模型不需要想很多步就能答对轻量款的能力完全覆盖。而量大意味着单价差异会被放大成真金白银。我做过一个内容审核的项目每天几十万条短文本过一遍换成轻量款之后成本直接降了一个数量级准确率只掉了不到两个百分点完全在可接受范围内。这里有个实操心得这类任务一定要做批量处理把多条短请求合并成一次调用如果模型支持批处理接口能进一步摊薄开销。另外输出格式尽量用结构化约束比如要求返回 JSON减少模型啰嗦带来的输出 token 浪费。4.2 第二类长文档理解任务综合款的长窗口是刚需合同审阅、研报分析、长代码库理解、会议纪要提炼——这类任务的输入动辄几万到几十万 token轻量款要么塞不下要么塞下了精度崩掉。这时候综合款的长上下文就是硬需求省不得。但即便是这类任务我也不建议无脑全量塞。我的常规做法是先分段摘要、再汇总把长文档切成若干段每段用轻量款做摘要或信息抽取最后把摘要汇总给综合款做整体分析。这样既用上了综合款的深度推理又把它的输入量压下来了成本能省一大截。当然如果任务强依赖全文的跨段落关联比如找合同里前后矛盾的条款那就老老实实全量喂给综合款别为了省钱牺牲效果。4.3 第三类多步推理任务别在轻量款上硬扛数学题、逻辑推理、复杂规划、多轮工具调用——这类任务的特点是“一步错步步错”对模型的推理链条完整性要求高。轻量款在这类任务上不是不能答而是稳定性差同样的 prompt 多跑几次结果可能不一样重试成本很高。我的判断标准很简单如果一个任务需要模型“想三步以上”或者需要它自己拆解子问题就直接上综合款。省那点单价换来的是反复调试和兜底逻辑的开发成本不划算。我踩过这个坑——早期为了控成本把一个多步数据清洗的任务放在轻量款上结果错误率居高不下最后加了一堆校验和重试逻辑开发时间翻倍还不如一开始就用综合款。4.4 第四类混合任务用路由层做分流真实项目里纯一类任务的情况很少大多是混合的。这时候最划算的做法是加一个轻量路由层先用一个极简的判断可以是规则也可以是一次轻量款调用把请求分成“简单”和“复杂”两堆简单的走轻量款复杂的走综合款。路由判断本身要足够便宜否则就本末倒置了。我常用的几种路由信号输入长度超过阈值直接走综合款。关键词/意图命中“分析”“规划”“对比”这类意图走综合款。置信度轻量款先答附带一个自评置信度低的转综合款兜底。这套架构的收益在量大的时候非常明显我经手的一个项目混合路由后整体成本比全用综合款降了六成多效果几乎无损。5. 实操落地从选型到上线的完整流程5.1 第一步把任务清单和 token 分布摸清楚动手选型之前先做功课。把你要跑的所有任务列出来每个任务标注平均输入 token、P95 输入 token、平均输出 token、对延迟的敏感度、对准确率的容忍度。这份清单是后面所有决策的依据别跳过。我一般会拿一批真实样本跑一遍 token 统计别拍脑袋估。很多人估的 token 数和实际差两三倍导致成本测算完全失真。统计工具各家都有或者用通用的分词库粗算也行量级对了就够用。5.2 第二步小样本 A/B用数据说话选型最忌讳纸上谈兵。拿每个任务的 50 到 100 条真实样本同时跑轻量款和综合款记录三个指标准确率、平均输出 token 数、平均延迟。然后套进第 2.2 节的成本公式算有效成本。这里有个细节评估准确率时一定要用你业务真正在意的标准别用通用榜单那套。比如做信息抽取就看字段抽全了没有、抽对了没有而不是看回答读起来顺不顺。我见过团队用“感觉回答质量”来评估最后选出来的模型在业务指标上反而更差。5.3 第三步设计降级与兜底链路上线前一定要想清楚轻量款答不好怎么办我的标准配置是两级兜底——轻量款先答触发低置信度或格式校验失败时自动转综合款重答综合款再失败走人工或返回兜底话术。这套链路要提前压测确保转发的延迟和成本都在预算内。注意兜底链路一定要设熔断阈值比如综合款调用占比超过 30% 就告警。否则一旦轻量款出问题兜底流量暴涨账单会给你惊喜。5.4 第四步上线后持续监控单位经济模型选型不是一锤子买卖。上线后要盯几个指标各模型的调用占比、平均 token 消耗、兜底触发率、单请求成本。这些指标每周看一次发现兜底率上升或者成本异常及时排查是 prompt 退化还是任务分布变了。我个人的习惯是给每个模型调用打上任务标签这样月底一拉报表哪个任务在烧钱一目了然。没有这层埋点成本优化就是盲人摸象。6. 常见问题与排查实录6.1 高频问题速查表现象可能原因排查与解决账单远超预算输出 token 失控或兜底率过高查输出长度分布加输出格式约束查兜底触发率长文档任务效果差关键信息被截断或注意力稀释确认输入未超窗口尝试分段摘要再汇总轻量款结果不稳定任务复杂度超出其能力抽样对比综合款评估是否需路由分流延迟忽高忽低请求量波动或长输入拖慢拆分长请求错峰批处理成本降了但效果崩了路由阈值设得太激进回调阈值扩大综合款覆盖比例6.2 几个只有踩过才知道的坑第一个坑是缓存没利用好。很多场景下系统提示词、固定知识库内容是重复的如果平台支持上下文缓存命中缓存的部分通常有折扣能省不少。我见过团队每次请求都把一大段固定说明重新发一遍白白多花钱。第二个坑是输出格式没约束。让模型自由发挥它可能给你写一大段解释再给答案输出 token 翻倍。用结构化输出或者明确要求“只返回结果”能显著压低输出成本尤其对输出单价高的综合款效果明显。第三个坑是拿开发环境的样本估生产用量。开发时测的都是精心挑选的样本生产环境的输入分布往往更杂更长。上线前一定要用真实流量回放或者灰度观察别拿测试集的数据做成本承诺。6.3 一个容易被忽略的维度版本迭代风险模型版本更新很快价格和能力都可能变。我的建议是不要把架构绑死在某个具体版本上抽象一层模型调用接口换模型时只改配置不改业务代码。这样哪家调价、哪个版本能力提升你都能快速响应而不是被锁死。7. 我个人的选型心法做了这么多项目我总结下来就一句话先算账再分层最后留后路。算账是把有效成本算清楚别被单价迷惑分层是按任务复杂度把请求路由到合适的模型留后路是兜底链路和抽象接口都要有应对模型答不好和版本变化。具体到这两个模型我的默认配置是八成以上的常规请求走轻量款复杂和长文档任务走综合款中间用路由层衔接。这个比例不是拍脑袋是多个项目跑下来比较稳的起点你可以根据自己的任务分布微调。真要给个建议就是别急着一步到位先小流量灰度用真实数据把比例调准了再全量。最后分享一个我常用的自检问题如果明天这个模型涨价一倍我的架构扛不扛得住扛得住说明你的分层和抽象做到位了扛不住那就还有优化空间。这个问题比任何榜单都更能检验选型是否扎实。 
长河君 · 2026/11/3 5:12:13 · 阅读 1.2k 大模型选型实战：价格、上下文与任务适配的权衡指南
1. 模型选型这件事为什么越来越像配电脑而不是选手机这两年做应用落地我最大的感受是模型选型已经从“谁家榜单分高用谁”彻底变成了“按任务配模型”的活儿。榜单分数当然还看但真正决定项目能不能跑起来的往往是三件事——每百万 token 的单价、上下文窗口够不够塞、以及这个任务到底吃不吃推理深度。标题里提到的两个模型一个主打轻快低成本一个主打长上下文与综合能力正好代表了当下两条典型路线。这篇就按我实际做项目时的思路把价格、上下文、任务适配这三块掰开揉碎讲清楚顺带把选型时容易踩的坑一并交代。先说清楚这篇适合谁看如果你正在做 AI 应用的技术选型、成本核算或者手上有具体任务不知道往哪个模型上放那这篇基本能当一份对照手册用。如果你只是想了解大模型大概怎么回事也能看懂我会尽量用生活化的类比把参数讲明白。需要提前说明的是文中涉及的具体价格、上下文长度等数值是基于 2026 年 10 月这个时间点公开信息整理的参考量级各家调价和版本迭代都很快实际下单前务必以官方最新页面为准这点我在后面还会反复强调。我见过太多团队在选型上翻车的案例翻车方式高度雷同要么是拿最贵的模型跑所有任务账单出来吓一跳要么是图便宜把长文档任务塞进小窗口模型结果截断得七零八落返工成本远超省下的那点钱。所以这篇不打算给你一个“标准答案”而是给你一套判断框架——看完你自己就能算出该用哪个。2. 先把两个模型的定位摆正别一上来就比分数2.1 轻量路线与综合路线本质是两种成本结构标题里这两个模型从命名和定位上就能看出分野。轻量款Haiku 这一档的核心卖点是单位成本低、响应快适合高频、短平快、对延迟敏感的任务综合款Luna 这一档的核心卖点是上下文长、复杂任务处理能力强适合长文档、多步骤推理、需要“想清楚再答”的场景。这个分野不是随便分的背后是模型规模、训练成本、推理算力的差异。打个比方轻量模型像一辆省油的小排量代步车市区通勤又快又便宜综合模型像一辆能拉货能跑长途的皮卡油耗高但能干重活。你非要用代步车拉建材或者用皮卡天天买菜都不是不行就是浪费。我在实际项目里最常见的误区就是用一个模型打天下。要么全上综合款求稳要么全上轻量款省钱结果两头不讨好。正确的做法是按任务分层把不同复杂度的请求路由到不同模型上这套“模型路由”的思路后面会专门讲。2.2 价格对比不能只看单价要算“有效成本”很多人比价格就盯着每百万 token 的输入输出单价这其实只对了一半。真正该算的是有效成本——完成同一个任务总共花了多少钱。这里头有几个容易被忽略的变量重试成本轻量模型在复杂任务上答不对你得重试或者换模型兜底这部分开销要算进去。上下文浪费长上下文模型如果只用来处理短请求等于用大窗口装小内容单价再低也是浪费。输出长度差异同样的问题有的模型啰嗦有的精炼输出 token 数差一倍很常见输出单价通常比输入贵好几倍这个差异会被放大。我一般会用一个简单的公式估算单任务成本单任务成本 ≈ (输入token数 × 输入单价 输出token数 × 输出单价) × 平均重试次数这个公式看着简单但把“重试次数”这一项加进去很多选型的结论就变了。轻量模型单价可能只有综合款的三分之一甚至更低但如果它在你的任务上重试率高达 40%实际成本优势就没那么夸张了。2.3 上下文窗口不是越大越好而是“够用且不浪费”上下文窗口这块我的经验是按任务的最长输入来定留 30% 余量就够。综合款动辄几十万 token 的窗口确实能一口气吞下整本书但你要问自己我真的需要一次性塞这么多吗长上下文有两个隐性成本。第一是注意力稀释——输入越长模型对关键信息的抓取精度越容易下降尤其是关键信息埋在中间位置时业内常说的“中间遗忘”现象。第二是计费放大——长输入按 token 计费塞得越多花得越多而且很多场景其实用检索增强就能解决没必要全量喂进去。我的做法是短任务几千 token 以内用轻量款完全够中等长度几万 token看任务复杂度决定超长文档十万 token 以上才考虑综合款的长窗口而且优先配合分段处理或检索而不是无脑全塞。3. 价格与上下文对照一张表看清差异在哪3.1 关键参数横向对照下面这张表是我按 2026 年 10 月公开信息整理的参考对照数值是量级示意具体以官方为准对比维度轻量款Haiku 档综合款Luna 档选型含义输入单价每百万 token低约为综合款的 1/5 至 1/3较高高频短请求优先轻量款输出单价每百万 token低约为综合款的 1/4 至 1/3较高输出长的任务要重点算账上下文窗口中等通常十几万 token 量级长通常几十万 token 量级超长文档才需要综合款响应延迟快相对慢实时交互场景轻量款占优复杂推理能力中等适合结构化任务强适合多步推理难题别硬塞给轻量款典型适用场景分类、抽取、改写、客服问答长文档分析、复杂规划、代码重构按任务分层路由这张表最该记住的不是具体数字而是每一行的“选型含义”那一列。数字会变判断逻辑不会变。3.2 一个真实的成本测算示例假设你有个文档问答产品每天处理 1 万次请求平均每次输入 3000 token、输出 500 token。我按量级做个粗算单位百万 token轻量款输入 30 百万 token × 低价 输出 5 百万 token × 低价假设输入单价 0.3、输出单价 1.2示意值日成本约 9 6 15 个单位。综合款同样用量假设输入单价 1.5、输出单价 6示意值日成本约 45 30 75 个单位。差距是 5 倍。但如果你的任务里有一半是复杂问题轻量款答不好需要重试两次那轻量款的实际成本就变成 15 × 1.5 22.5 个单位差距缩小到 3 倍多。这时候更优的方案不是二选一而是简单问题走轻量款、复杂问题走综合款混合下来可能只花 30 个单位左右比全用综合款省一半多。提示上面所有单价都是示意值目的是演示测算方法。真实报价请查官方定价页而且要注意输入输出分开计价、缓存命中可能有折扣这些细节。3.3 上下文窗口的“够用线”怎么定我一般会先统计任务输入的 token 分布看 P9595% 的请求落在哪个区间。如果 P95 在 8000 token 以内轻量款的中等窗口绰绰有余如果 P95 到了 5 万 token就得看综合款了。剩下那 5% 的超长请求单独走异步批处理或者分段方案不要为了极少数请求把整体架构拖重。这个思路说白了就是按主流需求配资源长尾单独处理跟数据库分库分表、缓存分层是一个道理。4. 任务选型把任务分成四类答案自然浮现4.1 第一类高频短平快任务闭眼选轻量款这类任务的特征是输入短、输出短、逻辑简单、量大。典型代表文本分类、情感判断、关键词抽取、格式转换、简单客服问答、内容审核初筛。为什么这类任务轻量款完胜因为它们的“推理深度需求”很低模型不需要想很多步就能答对轻量款的能力完全覆盖。而量大意味着单价差异会被放大成真金白银。我做过一个内容审核的项目每天几十万条短文本过一遍换成轻量款之后成本直接降了一个数量级准确率只掉了不到两个百分点完全在可接受范围内。这里有个实操心得这类任务一定要做批量处理把多条短请求合并成一次调用如果模型支持批处理接口能进一步摊薄开销。另外输出格式尽量用结构化约束比如要求返回 JSON减少模型啰嗦带来的输出 token 浪费。4.2 第二类长文档理解任务综合款的长窗口是刚需合同审阅、研报分析、长代码库理解、会议纪要提炼——这类任务的输入动辄几万到几十万 token轻量款要么塞不下要么塞下了精度崩掉。这时候综合款的长上下文就是硬需求省不得。但即便是这类任务我也不建议无脑全量塞。我的常规做法是先分段摘要、再汇总把长文档切成若干段每段用轻量款做摘要或信息抽取最后把摘要汇总给综合款做整体分析。这样既用上了综合款的深度推理又把它的输入量压下来了成本能省一大截。当然如果任务强依赖全文的跨段落关联比如找合同里前后矛盾的条款那就老老实实全量喂给综合款别为了省钱牺牲效果。4.3 第三类多步推理任务别在轻量款上硬扛数学题、逻辑推理、复杂规划、多轮工具调用——这类任务的特点是“一步错步步错”对模型的推理链条完整性要求高。轻量款在这类任务上不是不能答而是稳定性差同样的 prompt 多跑几次结果可能不一样重试成本很高。我的判断标准很简单如果一个任务需要模型“想三步以上”或者需要它自己拆解子问题就直接上综合款。省那点单价换来的是反复调试和兜底逻辑的开发成本不划算。我踩过这个坑——早期为了控成本把一个多步数据清洗的任务放在轻量款上结果错误率居高不下最后加了一堆校验和重试逻辑开发时间翻倍还不如一开始就用综合款。4.4 第四类混合任务用路由层做分流真实项目里纯一类任务的情况很少大多是混合的。这时候最划算的做法是加一个轻量路由层先用一个极简的判断可以是规则也可以是一次轻量款调用把请求分成“简单”和“复杂”两堆简单的走轻量款复杂的走综合款。路由判断本身要足够便宜否则就本末倒置了。我常用的几种路由信号输入长度超过阈值直接走综合款。关键词/意图命中“分析”“规划”“对比”这类意图走综合款。置信度轻量款先答附带一个自评置信度低的转综合款兜底。这套架构的收益在量大的时候非常明显我经手的一个项目混合路由后整体成本比全用综合款降了六成多效果几乎无损。5. 实操落地从选型到上线的完整流程5.1 第一步把任务清单和 token 分布摸清楚动手选型之前先做功课。把你要跑的所有任务列出来每个任务标注平均输入 token、P95 输入 token、平均输出 token、对延迟的敏感度、对准确率的容忍度。这份清单是后面所有决策的依据别跳过。我一般会拿一批真实样本跑一遍 token 统计别拍脑袋估。很多人估的 token 数和实际差两三倍导致成本测算完全失真。统计工具各家都有或者用通用的分词库粗算也行量级对了就够用。5.2 第二步小样本 A/B用数据说话选型最忌讳纸上谈兵。拿每个任务的 50 到 100 条真实样本同时跑轻量款和综合款记录三个指标准确率、平均输出 token 数、平均延迟。然后套进第 2.2 节的成本公式算有效成本。这里有个细节评估准确率时一定要用你业务真正在意的标准别用通用榜单那套。比如做信息抽取就看字段抽全了没有、抽对了没有而不是看回答读起来顺不顺。我见过团队用“感觉回答质量”来评估最后选出来的模型在业务指标上反而更差。5.3 第三步设计降级与兜底链路上线前一定要想清楚轻量款答不好怎么办我的标准配置是两级兜底——轻量款先答触发低置信度或格式校验失败时自动转综合款重答综合款再失败走人工或返回兜底话术。这套链路要提前压测确保转发的延迟和成本都在预算内。注意兜底链路一定要设熔断阈值比如综合款调用占比超过 30% 就告警。否则一旦轻量款出问题兜底流量暴涨账单会给你惊喜。5.4 第四步上线后持续监控单位经济模型选型不是一锤子买卖。上线后要盯几个指标各模型的调用占比、平均 token 消耗、兜底触发率、单请求成本。这些指标每周看一次发现兜底率上升或者成本异常及时排查是 prompt 退化还是任务分布变了。我个人的习惯是给每个模型调用打上任务标签这样月底一拉报表哪个任务在烧钱一目了然。没有这层埋点成本优化就是盲人摸象。6. 常见问题与排查实录6.1 高频问题速查表现象可能原因排查与解决账单远超预算输出 token 失控或兜底率过高查输出长度分布加输出格式约束查兜底触发率长文档任务效果差关键信息被截断或注意力稀释确认输入未超窗口尝试分段摘要再汇总轻量款结果不稳定任务复杂度超出其能力抽样对比综合款评估是否需路由分流延迟忽高忽低请求量波动或长输入拖慢拆分长请求错峰批处理成本降了但效果崩了路由阈值设得太激进回调阈值扩大综合款覆盖比例6.2 几个只有踩过才知道的坑第一个坑是缓存没利用好。很多场景下系统提示词、固定知识库内容是重复的如果平台支持上下文缓存命中缓存的部分通常有折扣能省不少。我见过团队每次请求都把一大段固定说明重新发一遍白白多花钱。第二个坑是输出格式没约束。让模型自由发挥它可能给你写一大段解释再给答案输出 token 翻倍。用结构化输出或者明确要求“只返回结果”能显著压低输出成本尤其对输出单价高的综合款效果明显。第三个坑是拿开发环境的样本估生产用量。开发时测的都是精心挑选的样本生产环境的输入分布往往更杂更长。上线前一定要用真实流量回放或者灰度观察别拿测试集的数据做成本承诺。6.3 一个容易被忽略的维度版本迭代风险模型版本更新很快价格和能力都可能变。我的建议是不要把架构绑死在某个具体版本上抽象一层模型调用接口换模型时只改配置不改业务代码。这样哪家调价、哪个版本能力提升你都能快速响应而不是被锁死。7. 我个人的选型心法做了这么多项目我总结下来就一句话先算账再分层最后留后路。算账是把有效成本算清楚别被单价迷惑分层是按任务复杂度把请求路由到合适的模型留后路是兜底链路和抽象接口都要有应对模型答不好和版本变化。具体到这两个模型我的默认配置是八成以上的常规请求走轻量款复杂和长文档任务走综合款中间用路由层衔接。这个比例不是拍脑袋是多个项目跑下来比较稳的起点你可以根据自己的任务分布微调。真要给个建议就是别急着一步到位先小流量灰度用真实数据把比例调准了再全量。最后分享一个我常用的自检问题如果明天这个模型涨价一倍我的架构扛不扛得住扛得住说明你的分层和抽象做到位了扛不住那就还有优化空间。这个问题比任何榜单都更能检验选型是否扎实。