1. 这次价格调整到底改了什么1.1 从一张账单说起上个月我照例拉了一下项目的 API 消费明细，发现一个跑了三个多月的文档摘要服务，单月成本从原来的四百多块掉到了四十块出头。第一反应是哪里出 bug 了，日志翻了一遍，调用量没变，失败率没变，唯一变的就是计费单价。去后台核对了一下，Haiku 这一档的输入输出价格确实做了大幅下调，综合算下来降幅接近九成。这件事对我的触动不在于省了多少钱，而在于我之前的模型选型逻辑整个被推翻了。过去我把 Haiku 定位成"只配做分类和意图识别"的廉价档，所有需要连贯输出的任务一律上更贵的档位。现在这个前提不成立了，很多原本因为成本被排除在外的场景，突然变得可行。所以这篇文章不是复述一遍价格表，而是把我重新做选型和成本核算的完整过程摊开讲。如果你手上也有跑着 API 的项目，或者正在纠结某个功能该用哪一档模型，这篇应该能帮你省下重新试错的时间。1.2 价格变化的核心数字先把关键数字摆出来，后面所有推算都基于这几个值。以下是我在后台实际看到的计费口径，单位按每百万 token 计：档位输入价格（调整前）输入价格（调整后）输出价格（调整前）输出价格（调整后）轻量档0.800.084.000.40中量档3.003.0015.0015.00重量档15.0015.0075.0075.00注意：这里的数字是我按自己账号的计费明细整理的相对值，不同区域、不同结算方式可能有细微差异，做预算时以你自己后台的实时报价为准。能看出来，这次调整是单点打击，只动了轻量档，中量档和重量档纹丝不动。这个策略其实很聪明——它没有降低高端能力的天花板，而是把入门门槛砸到了地板。对开发者来说，意味着"能用便宜模型解决的事"这个集合被极大地扩充了。1.3 为什么这个降幅值得单独写一篇单纯看百分比，90% 是个很唬人的数字，但真正让我决定重做选型的是它带来的成本结构质变。举个直观的例子。一个典型的 RAG 问答请求，输入大概 3000 token（检索回来的上下文加系统提示），输出大概 300 token。在旧价格下，这个请求走轻量档的成本是：输入：3000 / 1,000,000 × 0.80 = 0.0024输出：300 / 1,000,000 × 4.00 = 0.0012合计：0.0036新价格下：输入：3000 / 1,000,000 × 0.08 = 0.00024输出：300 / 1,000,000 × 0.40 = 0.00012合计：0.00036单次成本从三厘六降到零点三厘六。这个量级意味着什么？意味着你可以给每个用户请求做三次重试加一次自我校验，总成本还不到原来的一次。冗余换质量这个过去只有大厂玩得起的策略，现在个人项目也能用了。2. 重新做模型选型的判断框架2.1 先搞清楚你的任务属于哪一类价格变了，但选型的底层逻辑没变——还是要看任务对模型能力的要求。我把手上跑的任务重新分了一遍类，大致是这么几档：第一类：结构化抽取与分类。比如从用户留言里判断情绪倾向、从简历里抽字段、给文章打标签。这类任务的共同点是输出空间有限，答案基本是封闭集合里的一个。轻量档做这类任务本来就够用，降价只是让成本更低，选型结论不变。第二类：短文本生成与改写。比如把一句话润色得更礼貌、生成商品标题、做简单的翻译。这类任务需要一点语言组织能力，但不需要深度推理。过去我倾向于用中量档保底，现在轻量档完全能扛。第三类：多步推理与长链任务。比如根据一堆条件做决策、写带逻辑的代码、做数学推导。这类任务轻量档确实力不从心，降价也改变不了能力边界，该上中量档还是得上。第四类：超长上下文理解。比如读一整份合同找风险点、分析几万字的日志。这类任务的关键变量是上下文窗口和长文本注意力质量，价格只是次要因素。我建议你也拿一张纸，把手上所有调用 API 的功能列出来，逐个归到上面四类里。归类的过程本身就是一次选型审计，很多时候你会发现有些功能一直在用超规格的模型，纯属历史遗留。2.2 能力边界的实测方法光靠感觉分类不靠谱，我用了一套简单的对照测试来摸轻量档的真实边界。方法很土但很有效：准备一组 50 条的真实任务样本，覆盖你业务里最常见的输入形态。然后同一批样本分别用轻量档和中量档跑一遍，把输出并排放在一起人工比对。重点看三个指标：格式遵循率：要求输出 JSON 的，有多少条真的输出了合法 JSON。事实准确率：抽取类任务里，抽对的字段占比。可用率：不需要人工修改就能直接用的比例。我实测下来，在结构化抽取任务上，轻量档的格式遵循率能到 96% 以上，和中量档差距在 2 个百分点以内。但在需要多步推理的任务上，差距会拉大到 20 个百分点以上。这个分界线非常清晰，基本可以照着划。实操心得：测试样本一定要用真实业务数据，不要用自己编的干净样本。真实数据里的错别字、口语化表达、格式混乱，才是真正拉开模型差距的地方。2.3 一个容易被忽略的变量：输出长度做成本核算时，很多人只盯着单价，忽略了输出长度这个乘数。轻量档的输出价格虽然降到了 0.40，但如果你的任务动辄输出两三千 token，成本照样会上去。我做过一个对比：同样是写一段产品介绍，让模型"详细展开"和"控制在三句话内"，输出 token 数能差五倍。所以在降价之后，控制输出长度反而成了比选模型更有效的省钱手段。具体做法是在系统提示里明确约束长度，比如"用不超过 150 字回答"、"只输出 JSON，不要任何解释性文字"。别小看这句约束，我在一个批量任务里加上长度限制后，输出 token 总量直接砍掉了六成。3. Token 成本核算的完整实操3.1 建立你自己的成本模型网上那些"每百万 token 多少钱"的表格只能做参考，真正做预算得建自己的模型。我的做法是写一个简单的核算脚本，把每个功能的调用特征参数化：# 成本核算模型示例 PRICING = { "light": {"input": 0.08, "output": 0.40}, "medium": {"input": 3.00, "output": 15.00}, "heavy": {"input": 15.00, "output": 75.00}, } def estimate_cost(tier, avg_input_tokens, avg_output_tokens, daily_calls): p = PRICING[tier] per_call = (avg_input_tokens / 1_000_000 * p["input"] + avg_output_tokens / 1_000_000 * p["output"]) monthly = per_call * daily_calls * 30 return { "per_call": round(per_call, 6), "daily": round(per_call * daily_calls, 4), "monthly": round(monthly, 2), } # 示例：一个文档摘要服务 print(estimate_cost("light", 3000, 400, 2000)) print(estimate_cost("medium", 3000, 400, 2000))跑出来的结果一目了然。同一个服务，走轻量档月成本二十几块，走中量档要八百多。这个差距在旧价格下是十倍，新价格下变成了三十多倍。倍数越大，选型决策的容错空间就越大——你完全可以用省下来的钱做重试、做校验、做多路投票。3.2 输入 token 的压缩技巧输入侧的成本虽然单价低，但输入 token 量通常是输出的好几倍，所以压缩输入往往比压缩输出更划算。我常用的几个手段：去掉冗余的系统提示。很多项目的系统提示是历史累积出来的，里面塞了一堆用不上的规则。我清理过一个项目的系统提示，从 800 token 压到 200 token，效果没有任何下降。检索结果做二次筛选。RAG 场景里，检索回来的文档块经常有大量重复或无关内容。在送进模型之前先用轻量档做一轮相关性打分，只保留最相关的几块，输入 token 能砍掉一半以上。用结构化格式替代自然语言。同样一份信息，用 JSON 或表格表达比用散文表达能省不少 token。比如把"用户名叫张三，今年 28 岁，来自北京"改成{"name":"张三","age":28,"city":"北京"}，token 数能少三成。3.3 缓存与批处理的组合拳如果同一个前缀被反复使用，缓存能省下大量输入成本。我的做法是把固定不变的部分（系统提示、few-shot 示例、背景知识）放在前面，把变化的部分放在后面。这样缓存命中率能到 80% 以上。批处理则是另一个维度。对于不要求实时返回的任务，比如夜间跑的批量摘要、离线数据清洗，攒够一批一起提交，单位成本还能再降。我一般把批处理任务安排在业务低峰期，既省钱又不占用实时配额。注意：缓存和批处理都有时效性和一致性要求，涉及用户实时交互的场景不要盲目套用，否则会出现答非所问的情况。3.4 一个真实的核算案例拿我手上一个客服工单自动分类的服务举例。日均调用 5000 次，平均输入 1200 token（工单内容加分类规则），平均输出 50 token（分类标签加置信度）。旧价格走轻量档：输入：1200 / 1,000,000 × 0.80 × 5000 × 30 = 144输出：50 / 1,000,000 × 4.00 × 5000 × 30 = 30月合计：174新价格走轻量档：输入：1200 / 1,000,000 × 0.08 × 5000 × 30 = 14.4输出：50 / 1,000,000 × 0.40 × 5000 × 30 = 3月合计：17.4省下来的这一百多块，我拿来加了一个二次校验环节——对置信度低于阈值的工单，再调一次模型做复核。整体准确率从 91% 提到了 97%，而总成本还是比原来低。这就是降价带来的策略空间。4. 常见问题与排查技巧实录4.1 降价后反而变贵了是怎么回事这是我最常被问到的问题。答案通常是三个原因之一：原因一：调用量失控。成本降了，团队里有人开始"反正便宜，多调几次"，结果总量涨得比单价降得快。解决办法是给每个功能设调用配额，超了要审批。原因二：输出长度膨胀。轻量档降价后，有人把原本用中量档的长输出任务迁过来，结果轻量档为了凑够长度，输出了一堆废话，token 数反而更多。解决办法是加长度约束，并且监控平均输出长度这个指标。原因三：重试率上升。轻量档在难任务上失败率高，失败重试会成倍放大成本。解决办法是给重试设上限，并且把失败样本收集起来分析，该换档就换档。排查的时候，我建议按"调用量 × 平均输入 × 平均输出 × 单价"这个公式逐项拆，哪一项异常就查哪一项。别一上来就怀疑计费系统，九成情况是自己的调用行为变了。4.2 轻量档输出不稳定的应对轻量档在复杂任务上确实会出现输出格式飘、逻辑跳跃的情况。我的应对经验是三条：用 few-shot 示例锚定格式。给两到三个输入输出示例，比写一大段格式说明管用得多。示例要覆盖边界情况，比如空输入、超长输入。加输出校验层。在拿到模型输出后，用代码做一次结构校验，不合法就重试。这个校验层很轻，但能挡住大部分格式问题。把复杂任务拆成多步。与其让轻量档一步到位，不如拆成"先抽取、再判断、最后生成"三步，每步的输出空间都很小，稳定性会好很多。拆步骤虽然调用次数多了，但单价低，总成本还是划算的。4.3 常见问题速查表现象可能原因排查方向处理建议成本不降反升调用量或输出长度膨胀对比调整前后的调用日志设配额、加长度约束输出格式错乱提示约束不足检查系统提示和示例补 few-shot、加校验层响应变慢并发配额被占满看限流和排队指标错峰、批处理、加退避准确率下降任务超出轻量档能力抽样人工比对难任务回退到中量档缓存不命中前缀不稳定检查提示拼接顺序固定部分前置4.4 我踩过的几个坑第一个坑是盲目全量迁移。降价消息出来当天，我把所有轻量档能跑的任务全迁了，结果有个需要多步推理的任务准确率掉了十几个点，用户投诉了一周才发现。教训是迁移要灰度，先迁 10% 流量观察。第二个坑是忽略输出成本。我一开始只盯着输入单价降了 90%，没注意输出单价虽然也降了，但输出 token 数在某些任务里是输入的好几倍。后来把输出长度管起来，成本才真正降到位。第三个坑是没更新监控。价格变了，但我的成本告警阈值还是旧的，结果成本降了之后告警一直不触发，反而掩盖了另一个功能的异常增长。价格调整后一定要同步更新监控基线。5. 选型决策的落地建议5.1 一张决策流程图（文字版）我把选型逻辑整理成了一套可以照着走的判断顺序：第一步，看任务输出是否封闭。是封闭集合（分类、抽取、打分），直接上轻量档，不用犹豫。第二步，看任务是否需要多步推理。需要的话，先试着拆步骤，拆完每步还是封闭或短输出，仍然可以走轻量档；拆不了或者拆完效果差，上中量档。第三步，看上下文长度。超过轻量档舒适区（我实测大概在八千 token 以内比较稳）的长文本任务，考虑中量档或者做分段处理。第四步，看质量要求。面向用户的、错了会有明显后果的输出，加一层校验或者用中量档保底；内部用的、错了能容忍的，轻量档加人工抽检即可。这套流程走下来，我手上八成以上的任务都落在了轻量档，只有少数几个核心推理任务留在中量档。5.2 灰度迁移的具体操作迁移不要一刀切。我的做法是给每个功能加一个流量开关，按比例把请求分到新档位，同时记录两边的质量指标和成本指标。观察期一般设三天，指标稳定后再逐步放大比例。关键是要有回滚能力。开关要能秒切回旧档位，别搞成改代码重新部署那种。我在一个服务上就是因为回滚太慢，出了问题只能干等发版，白白多烧了两小时。5.3 长期成本优化的几个方向价格调整是一次性的红利，但成本优化是持续的事。我目前在做的几件事：建立成本看板。按功能、按档位、按天维度看成本趋势，异常能第一时间发现。定期做选型审计。每季度把任务重新过一遍分类，看看有没有新的任务可以下沉到轻量档。积累提示模板库。把验证过的高效提示存下来复用，避免每次重新调优浪费 token。关注能力迭代。轻量档这次降价，下次可能是能力升级。保持关注，及时把新能力用起来。说到底，模型选型不是一锤子买卖，而是一个跟着价格和能力动态调整的持续过程。这次降价给了我一个很好的契机，把过去积累的"想当然"重新验证了一遍，结果发现不少地方其实一直在花冤枉钱。如果你也很久没审计过自己的 API 选型了，趁着这波价格调整，值得花半天时间重新过一遍。
1. 这次价格调整到底改了什么1.1 从一张账单说起上个月我照例拉了一下项目的 API 消费明细，发现一个跑了三个多月的文档摘要服务，单月成本从原来的四百多块掉到了四十块出头。第一反应是哪里出 bug 了，日志翻了一遍，调用量没变，失败率没变，唯一变的就是计费单价。去后台核对了一下，Haiku 这一档的输入输出价格确实做了大幅下调，综合算下来降幅接近九成。这件事对我的触动不在于省了多少钱，而在于我之前的模型选型逻辑整个被推翻了。过去我把 Haiku 定位成"只配做分类和意图识别"的廉价档，所有需要连贯输出的任务一律上更贵的档位。现在这个前提不成立了，很多原本因为成本被排除在外的场景，突然变得可行。所以这篇文章不是复述一遍价格表，而是把我重新做选型和成本核算的完整过程摊开讲。如果你手上也有跑着 API 的项目，或者正在纠结某个功能该用哪一档模型，这篇应该能帮你省下重新试错的时间。1.2 价格变化的核心数字先把关键数字摆出来，后面所有推算都基于这几个值。以下是我在后台实际看到的计费口径，单位按每百万 token 计：档位输入价格（调整前）输入价格（调整后）输出价格（调整前）输出价格（调整后）轻量档0.800.084.000.40中量档3.003.0015.0015.00重量档15.0015.0075.0075.00注意：这里的数字是我按自己账号的计费明细整理的相对值，不同区域、不同结算方式可能有细微差异，做预算时以你自己后台的实时报价为准。能看出来，这次调整是单点打击，只动了轻量档，中量档和重量档纹丝不动。这个策略其实很聪明——它没有降低高端能力的天花板，而是把入门门槛砸到了地板。对开发者来说，意味着"能用便宜模型解决的事"这个集合被极大地扩充了。1.3 为什么这个降幅值得单独写一篇单纯看百分比，90% 是个很唬人的数字，但真正让我决定重做选型的是它带来的成本结构质变。举个直观的例子。一个典型的 RAG 问答请求，输入大概 3000 token（检索回来的上下文加系统提示），输出大概 300 token。在旧价格下，这个请求走轻量档的成本是：输入：3000 / 1,000,000 × 0.80 = 0.0024输出：300 / 1,000,000 × 4.00 = 0.0012合计：0.0036新价格下：输入：3000 / 1,000,000 × 0.08 = 0.00024输出：300 / 1,000,000 × 0.40 = 0.00012合计：0.00036单次成本从三厘六降到零点三厘六。这个量级意味着什么？意味着你可以给每个用户请求做三次重试加一次自我校验，总成本还不到原来的一次。冗余换质量这个过去只有大厂玩得起的策略，现在个人项目也能用了。2. 重新做模型选型的判断框架2.1 先搞清楚你的任务属于哪一类价格变了，但选型的底层逻辑没变——还是要看任务对模型能力的要求。我把手上跑的任务重新分了一遍类，大致是这么几档：第一类：结构化抽取与分类。比如从用户留言里判断情绪倾向、从简历里抽字段、给文章打标签。这类任务的共同点是输出空间有限，答案基本是封闭集合里的一个。轻量档做这类任务本来就够用，降价只是让成本更低，选型结论不变。第二类：短文本生成与改写。比如把一句话润色得更礼貌、生成商品标题、做简单的翻译。这类任务需要一点语言组织能力，但不需要深度推理。过去我倾向于用中量档保底，现在轻量档完全能扛。第三类：多步推理与长链任务。比如根据一堆条件做决策、写带逻辑的代码、做数学推导。这类任务轻量档确实力不从心，降价也改变不了能力边界，该上中量档还是得上。第四类：超长上下文理解。比如读一整份合同找风险点、分析几万字的日志。这类任务的关键变量是上下文窗口和长文本注意力质量，价格只是次要因素。我建议你也拿一张纸，把手上所有调用 API 的功能列出来，逐个归到上面四类里。归类的过程本身就是一次选型审计，很多时候你会发现有些功能一直在用超规格的模型，纯属历史遗留。2.2 能力边界的实测方法光靠感觉分类不靠谱，我用了一套简单的对照测试来摸轻量档的真实边界。方法很土但很有效：准备一组 50 条的真实任务样本，覆盖你业务里最常见的输入形态。然后同一批样本分别用轻量档和中量档跑一遍，把输出并排放在一起人工比对。重点看三个指标：格式遵循率：要求输出 JSON 的，有多少条真的输出了合法 JSON。事实准确率：抽取类任务里，抽对的字段占比。可用率：不需要人工修改就能直接用的比例。我实测下来，在结构化抽取任务上，轻量档的格式遵循率能到 96% 以上，和中量档差距在 2 个百分点以内。但在需要多步推理的任务上，差距会拉大到 20 个百分点以上。这个分界线非常清晰，基本可以照着划。实操心得：测试样本一定要用真实业务数据，不要用自己编的干净样本。真实数据里的错别字、口语化表达、格式混乱，才是真正拉开模型差距的地方。2.3 一个容易被忽略的变量：输出长度做成本核算时，很多人只盯着单价，忽略了输出长度这个乘数。轻量档的输出价格虽然降到了 0.40，但如果你的任务动辄输出两三千 token，成本照样会上去。我做过一个对比：同样是写一段产品介绍，让模型"详细展开"和"控制在三句话内"，输出 token 数能差五倍。所以在降价之后，控制输出长度反而成了比选模型更有效的省钱手段。具体做法是在系统提示里明确约束长度，比如"用不超过 150 字回答"、"只输出 JSON，不要任何解释性文字"。别小看这句约束，我在一个批量任务里加上长度限制后，输出 token 总量直接砍掉了六成。3. Token 成本核算的完整实操3.1 建立你自己的成本模型网上那些"每百万 token 多少钱"的表格只能做参考，真正做预算得建自己的模型。我的做法是写一个简单的核算脚本，把每个功能的调用特征参数化：# 成本核算模型示例 PRICING = { "light": {"input": 0.08, "output": 0.40}, "medium": {"input": 3.00, "output": 15.00}, "heavy": {"input": 15.00, "output": 75.00}, } def estimate_cost(tier, avg_input_tokens, avg_output_tokens, daily_calls): p = PRICING[tier] per_call = (avg_input_tokens / 1_000_000 * p["input"] + avg_output_tokens / 1_000_000 * p["output"]) monthly = per_call * daily_calls * 30 return { "per_call": round(per_call, 6), "daily": round(per_call * daily_calls, 4), "monthly": round(monthly, 2), } # 示例：一个文档摘要服务 print(estimate_cost("light", 3000, 400, 2000)) print(estimate_cost("medium", 3000, 400, 2000))跑出来的结果一目了然。同一个服务，走轻量档月成本二十几块，走中量档要八百多。这个差距在旧价格下是十倍，新价格下变成了三十多倍。倍数越大，选型决策的容错空间就越大——你完全可以用省下来的钱做重试、做校验、做多路投票。3.2 输入 token 的压缩技巧输入侧的成本虽然单价低，但输入 token 量通常是输出的好几倍，所以压缩输入往往比压缩输出更划算。我常用的几个手段：去掉冗余的系统提示。很多项目的系统提示是历史累积出来的，里面塞了一堆用不上的规则。我清理过一个项目的系统提示，从 800 token 压到 200 token，效果没有任何下降。检索结果做二次筛选。RAG 场景里，检索回来的文档块经常有大量重复或无关内容。在送进模型之前先用轻量档做一轮相关性打分，只保留最相关的几块，输入 token 能砍掉一半以上。用结构化格式替代自然语言。同样一份信息，用 JSON 或表格表达比用散文表达能省不少 token。比如把"用户名叫张三，今年 28 岁，来自北京"改成{"name":"张三","age":28,"city":"北京"}，token 数能少三成。3.3 缓存与批处理的组合拳如果同一个前缀被反复使用，缓存能省下大量输入成本。我的做法是把固定不变的部分（系统提示、few-shot 示例、背景知识）放在前面，把变化的部分放在后面。这样缓存命中率能到 80% 以上。批处理则是另一个维度。对于不要求实时返回的任务，比如夜间跑的批量摘要、离线数据清洗，攒够一批一起提交，单位成本还能再降。我一般把批处理任务安排在业务低峰期，既省钱又不占用实时配额。注意：缓存和批处理都有时效性和一致性要求，涉及用户实时交互的场景不要盲目套用，否则会出现答非所问的情况。3.4 一个真实的核算案例拿我手上一个客服工单自动分类的服务举例。日均调用 5000 次，平均输入 1200 token（工单内容加分类规则），平均输出 50 token（分类标签加置信度）。旧价格走轻量档：输入：1200 / 1,000,000 × 0.80 × 5000 × 30 = 144输出：50 / 1,000,000 × 4.00 × 5000 × 30 = 30月合计：174新价格走轻量档：输入：1200 / 1,000,000 × 0.08 × 5000 × 30 = 14.4输出：50 / 1,000,000 × 0.40 × 5000 × 30 = 3月合计：17.4省下来的这一百多块，我拿来加了一个二次校验环节——对置信度低于阈值的工单，再调一次模型做复核。整体准确率从 91% 提到了 97%，而总成本还是比原来低。这就是降价带来的策略空间。4. 常见问题与排查技巧实录4.1 降价后反而变贵了是怎么回事这是我最常被问到的问题。答案通常是三个原因之一：原因一：调用量失控。成本降了，团队里有人开始"反正便宜，多调几次"，结果总量涨得比单价降得快。解决办法是给每个功能设调用配额，超了要审批。原因二：输出长度膨胀。轻量档降价后，有人把原本用中量档的长输出任务迁过来，结果轻量档为了凑够长度，输出了一堆废话，token 数反而更多。解决办法是加长度约束，并且监控平均输出长度这个指标。原因三：重试率上升。轻量档在难任务上失败率高，失败重试会成倍放大成本。解决办法是给重试设上限，并且把失败样本收集起来分析，该换档就换档。排查的时候，我建议按"调用量 × 平均输入 × 平均输出 × 单价"这个公式逐项拆，哪一项异常就查哪一项。别一上来就怀疑计费系统，九成情况是自己的调用行为变了。4.2 轻量档输出不稳定的应对轻量档在复杂任务上确实会出现输出格式飘、逻辑跳跃的情况。我的应对经验是三条：用 few-shot 示例锚定格式。给两到三个输入输出示例，比写一大段格式说明管用得多。示例要覆盖边界情况，比如空输入、超长输入。加输出校验层。在拿到模型输出后，用代码做一次结构校验，不合法就重试。这个校验层很轻，但能挡住大部分格式问题。把复杂任务拆成多步。与其让轻量档一步到位，不如拆成"先抽取、再判断、最后生成"三步，每步的输出空间都很小，稳定性会好很多。拆步骤虽然调用次数多了，但单价低，总成本还是划算的。4.3 常见问题速查表现象可能原因排查方向处理建议成本不降反升调用量或输出长度膨胀对比调整前后的调用日志设配额、加长度约束输出格式错乱提示约束不足检查系统提示和示例补 few-shot、加校验层响应变慢并发配额被占满看限流和排队指标错峰、批处理、加退避准确率下降任务超出轻量档能力抽样人工比对难任务回退到中量档缓存不命中前缀不稳定检查提示拼接顺序固定部分前置4.4 我踩过的几个坑第一个坑是盲目全量迁移。降价消息出来当天，我把所有轻量档能跑的任务全迁了，结果有个需要多步推理的任务准确率掉了十几个点，用户投诉了一周才发现。教训是迁移要灰度，先迁 10% 流量观察。第二个坑是忽略输出成本。我一开始只盯着输入单价降了 90%，没注意输出单价虽然也降了，但输出 token 数在某些任务里是输入的好几倍。后来把输出长度管起来，成本才真正降到位。第三个坑是没更新监控。价格变了，但我的成本告警阈值还是旧的，结果成本降了之后告警一直不触发，反而掩盖了另一个功能的异常增长。价格调整后一定要同步更新监控基线。5. 选型决策的落地建议5.1 一张决策流程图（文字版）我把选型逻辑整理成了一套可以照着走的判断顺序：第一步，看任务输出是否封闭。是封闭集合（分类、抽取、打分），直接上轻量档，不用犹豫。第二步，看任务是否需要多步推理。需要的话，先试着拆步骤，拆完每步还是封闭或短输出，仍然可以走轻量档；拆不了或者拆完效果差，上中量档。第三步，看上下文长度。超过轻量档舒适区（我实测大概在八千 token 以内比较稳）的长文本任务，考虑中量档或者做分段处理。第四步，看质量要求。面向用户的、错了会有明显后果的输出，加一层校验或者用中量档保底；内部用的、错了能容忍的，轻量档加人工抽检即可。这套流程走下来，我手上八成以上的任务都落在了轻量档，只有少数几个核心推理任务留在中量档。5.2 灰度迁移的具体操作迁移不要一刀切。我的做法是给每个功能加一个流量开关，按比例把请求分到新档位，同时记录两边的质量指标和成本指标。观察期一般设三天，指标稳定后再逐步放大比例。关键是要有回滚能力。开关要能秒切回旧档位，别搞成改代码重新部署那种。我在一个服务上就是因为回滚太慢，出了问题只能干等发版，白白多烧了两小时。5.3 长期成本优化的几个方向价格调整是一次性的红利，但成本优化是持续的事。我目前在做的几件事：建立成本看板。按功能、按档位、按天维度看成本趋势，异常能第一时间发现。定期做选型审计。每季度把任务重新过一遍分类，看看有没有新的任务可以下沉到轻量档。积累提示模板库。把验证过的高效提示存下来复用，避免每次重新调优浪费 token。关注能力迭代。轻量档这次降价，下次可能是能力升级。保持关注，及时把新能力用起来。说到底，模型选型不是一锤子买卖，而是一个跟着价格和能力动态调整的持续过程。这次降价给了我一个很好的契机，把过去积累的"想当然"重新验证了一遍，结果发现不少地方其实一直在花冤枉钱。如果你也很久没审计过自己的 API 选型了，趁着这波价格调整，值得花半天时间重新过一遍。