企业官网建设流程全解析

1. 这次价格调整到底改了什么

1.1 从一张账单说起

上个月我照例拉了一下项目的 API 消费明细，发现一个跑了三个多月的文档摘要服务，单月成本从原来的四百多块掉到了四十块出头。第一反应是哪里出 bug 了，日志翻了一遍，调用量没变，失败率没变，唯一变的就是计费单价。去后台核对了一下，Haiku 这一档的输入输出价格确实做了大幅下调，综合算下来降幅接近九成。

这件事对我的触动不在于省了多少钱，而在于我之前的模型选型逻辑整个被推翻了。过去我把 Haiku 定位成"只配做分类和意图识别"的廉价档，所有需要连贯输出的任务一律上更贵的档位。现在这个前提不成立了，很多原本因为成本被排除在外的场景，突然变得可行。

所以这篇文章不是复述一遍价格表，而是把我重新做选型和成本核算的完整过程摊开讲。如果你手上也有跑着 API 的项目，或者正在纠结某个功能该用哪一档模型，这篇应该能帮你省下重新试错的时间。

1.2 价格变化的核心数字

先把关键数字摆出来，后面所有推算都基于这几个值。以下是我在后台实际看到的计费口径，单位按每百万 token 计：

注意：这里的数字是我按自己账号的计费明细整理的相对值，不同区域、不同结算方式可能有细微差异，做预算时以你自己后台的实时报价为准。

能看出来，这次调整是单点打击，只动了轻量档，中量档和重量档纹丝不动。这个策略其实很聪明——它没有降低高端能力的天花板，而是把入门门槛砸到了地板。对开发者来说，意味着"能用便宜模型解决的事"这个集合被极大地扩充了。

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 常见问题速查表

4.4 我踩过的几个坑

第一个坑是盲目全量迁移。降价消息出来当天，我把所有轻量档能跑的任务全迁了，结果有个需要多步推理的任务准确率掉了十几个点，用户投诉了一周才发现。教训是迁移要灰度，先迁 10% 流量观察。

第二个坑是忽略输出成本。我一开始只盯着输入单价降了 90%，没注意输出单价虽然也降了，但输出 token 数在某些任务里是输入的好几倍。后来把输出长度管起来，成本才真正降到位。

第三个坑是没更新监控。价格变了，但我的成本告警阈值还是旧的，结果成本降了之后告警一直不触发，反而掩盖了另一个功能的异常增长。价格调整后一定要同步更新监控基线。

5. 选型决策的落地建议

5.1 一张决策流程图（文字版）

我把选型逻辑整理成了一套可以照着走的判断顺序：

第一步，看任务输出是否封闭。是封闭集合（分类、抽取、打分），直接上轻量档，不用犹豫。

第二步，看任务是否需要多步推理。需要的话，先试着拆步骤，拆完每步还是封闭或短输出，仍然可以走轻量档；拆不了或者拆完效果差，上中量档。

第三步，看上下文长度。超过轻量档舒适区（我实测大概在八千 token 以内比较稳）的长文本任务，考虑中量档或者做分段处理。

第四步，看质量要求。面向用户的、错了会有明显后果的输出，加一层校验或者用中量档保底；内部用的、错了能容忍的，轻量档加人工抽检即可。

这套流程走下来，我手上八成以上的任务都落在了轻量档，只有少数几个核心推理任务留在中量档。

5.2 灰度迁移的具体操作

迁移不要一刀切。我的做法是给每个功能加一个流量开关，按比例把请求分到新档位，同时记录两边的质量指标和成本指标。观察期一般设三天，指标稳定后再逐步放大比例。

关键是要有回滚能力。开关要能秒切回旧档位，别搞成改代码重新部署那种。我在一个服务上就是因为回滚太慢，出了问题只能干等发版，白白多烧了两小时。

5.3 长期成本优化的几个方向

价格调整是一次性的红利，但成本优化是持续的事。我目前在做的几件事：

建立成本看板。按功能、按档位、按天维度看成本趋势，异常能第一时间发现。

定期做选型审计。每季度把任务重新过一遍分类，看看有没有新的任务可以下沉到轻量档。

积累提示模板库。把验证过的高效提示存下来复用，避免每次重新调优浪费 token。

关注能力迭代。轻量档这次降价，下次可能是能力升级。保持关注，及时把新能力用起来。

说到底，模型选型不是一锤子买卖，而是一个跟着价格和能力动态调整的持续过程。这次降价给了我一个很好的契机，把过去积累的"想当然"重新验证了一遍，结果发现不少地方其实一直在花冤枉钱。如果你也很久没审计过自己的 API 选型了，趁着这波价格调整，值得花半天时间重新过一遍。