企业官网建设流程全解析

1. 模型选型这件事，为什么每次价格调整都值得重新算一遍

做AI应用开发的同行应该都有体会，模型选型从来不是一锤子买卖。每次API价格调整，尤其是主力轻量模型出现大幅降价的时候，之前算好的成本模型基本就作废了。我这次重新做选型核算，起因就是Haiku 5.5这轮降价——幅度直接拉到90%，这个数字放在任何一家云服务的定价史上都算得上激进。

先把这个事情说清楚：Haiku 5.5是某AI平台旗下的轻量级模型，定位是"快、便宜、够用"，主要面向高并发、低延迟、成本敏感的调用场景。这次降价之后，它的输入输出Token单价降到了原来的十分之一左右。对于每天跑几十万甚至上百万次调用的业务来说，这不是"省点钱"的问题，而是直接决定了某些功能能不能从"赔本赚吆喝"变成"有毛利可算"。

我自己的项目是一个内容处理类的工具，核心链路里有两块调用：一块是长文本的摘要和结构化提取，另一块是短文本的分类和意图识别。之前这两块都混用同一个中档模型，因为轻量模型在结构化输出上偶尔会翻车，重试成本反而更高。但价格一变，整个账本就得重算——不是简单地"便宜了就换"，而是要算清楚：降价之后，轻量模型在哪些任务上已经"够用且划算"，哪些任务仍然必须用中档甚至高档模型兜底。

这篇文章就是把这轮重新选型和成本核算的完整过程拆开讲。适合谁看？如果你正在做AI应用的成本优化、正在纠结模型分层策略、或者单纯想知道"降价90%到底意味着什么"，下面的内容应该能直接拿去用。我会把核算表格、分层逻辑、实测踩坑都摆出来，不玩虚的。

2. 先把账算明白：Token成本核算的底层逻辑

2.1 Token计费的基本盘：输入、输出、缓存三块

很多人算成本只盯着"每百万Token多少钱"，但实际账单出来往往对不上。原因是Token计费至少有三个维度：输入Token、输出Token、以及缓存命中/写入的Token。这三块的单价完全不同，输出通常比输入贵好几倍，缓存命中则便宜到几乎可以忽略。

以这次降价的Haiku 5.5为例，降价后的价格结构大致是这样的（具体数字以官方页面为准，我这里用的是核算时的口径）：

这个表格里最关键的信息不是绝对数字，而是输入和输出之间的倍率关系。假设输出单价是输入的5倍，那么一个"输入长、输出短"的任务（比如分类）和一个"输入短、输出长"的任务（比如生成），成本结构完全不一样。降价90%对前者的影响远大于后者，因为前者主要成本在输入侧。

我踩过的第一个坑就在这里：早期做核算时只按"平均每次调用消耗多少Token"估算，结果实际账单比预估高了40%。后来拆开看才发现，输出Token的占比被严重低估了——模型在结构化输出时经常多吐一些解释性文字，这些全按输出计费。

2.2 单次调用成本的计算公式

把上面三块拼起来，单次调用的成本公式是：

单次成本 = 输入Token数 × 输入单价 + 输出Token数 × 输出单价 + 缓存相关费用

看起来简单，但实操中有几个变量必须实测才能确定：

• 输入Token数：不只是你的prompt长度，还包括系统提示词、few-shot示例、历史对话。系统提示词如果写得很长，每次调用都在重复计费。
• 输出Token数：模型的实际输出长度往往比预期长，尤其是没有严格约束格式的时候。
• 重试率：如果模型输出格式不对需要重试，重试的那次调用也是全额计费。轻量模型的重试率通常比中档模型高，这是隐性成本。

我建议的核算方法是：先跑一批真实样本（至少200条），统计出输入、输出的Token分布，取P50和P95两个值分别算。P50代表典型成本，P95代表最坏情况成本。只算平均值会误导决策，因为成本超支往往发生在长尾上。

2.3 降价90%对不同任务类型的实际影响

这里要泼一盆冷水：降价90%不等于你的总成本降90%。总成本降多少，取决于轻量模型能承接多少比例的任务。

举个具体的例子。假设你原来所有任务都用中档模型，单次成本是X。现在把其中60%的任务切给降价后的Haiku 5.5，这60%的成本变成0.1X，剩下40%仍是X。新的平均成本是：

新平均成本 = 0.6 × 0.1X + 0.4 × X = 0.06X + 0.4X = 0.46X

也就是说，即使降价90%，如果只能切换60%的任务，总成本也只降到原来的46%。要真正吃到降价红利，核心工作是提高轻量模型的可承接比例，而这靠的是任务拆分和输出约束，不是单纯换个模型名。

这个认知直接改变了我后面的选型策略：不是"选一个模型"，而是"设计一套分层路由"。

3. 分层选型策略：什么任务交给Haiku 5.5，什么任务必须升级

3.1 任务分层的第一原则：按"容错成本"而不是"任务难度"划分

很多人分层是按任务难度来的——简单的给轻量模型，复杂的给高档模型。但实际操作中，"难度"是个很模糊的概念。我后来改成按容错成本划分，清晰得多。

容错成本的意思是：如果这个任务模型输出错了，会造成多大损失？损失包括重试成本、人工复核成本、以及错误结果带来的业务影响。

按这个标准，任务可以分成三档：

• 低容错成本：输出错了重试一次就行，或者有自动校验能兜住。典型如意图分类、标签提取、简单摘要。这类任务大胆交给Haiku 5.5。
• 中容错成本：输出错了需要人工介入，但频率不高可以接受。典型如结构化数据提取、多轮对话中的信息抽取。这类任务可以交给Haiku 5.5，但必须加校验和重试机制。
• 高容错成本：输出错了直接影响业务结果，或者人工复核成本极高。典型如长文档的深度分析、需要多步推理的决策建议。这类任务保留中档或高档模型。

我实测下来，我自己的项目里低容错成本任务占了约70%，中容错成本占20%，高容错成本只占10%。这意味着理论上可以把90%的调用切到Haiku 5.5，但实际因为中容错成本任务需要重试，有效切换比例大概在75%到80%之间。

3.2 实测对比：Haiku 5.5在各类任务上的表现

光算成本不够，得看质量。我拿同一批测试集（300条真实样本）跑了Haiku 5.5和中档模型的对比，结果如下：

这张表是我这次核算里最有价值的东西。它清楚地告诉我：分类和意图识别这类任务，Haiku 5.5和中档模型的差距在2个百分点以内，完全可以切换；结构化提取差距9个点，需要加一层格式校验和重试；多步推理差距19个点，坚决不切。

注意：这个准确率是在我的特定测试集上跑出来的，你的任务分布不同，结论可能不一样。强烈建议自己跑一遍再决策，不要直接抄。

3.3 路由层的设计：怎么让请求自动落到合适的模型

分层策略定下来之后，落地靠的是路由层。我的做法是在调用入口加一个轻量级的规则引擎，根据任务类型和输入特征决定用哪个模型。

路由规则大致是这样的：

1. 请求进来先打标签，标签来自业务侧的显式声明（比如调用方指定task_type）。
2. 如果task_type属于"可切换"列表，走Haiku 5.5。
3. 如果task_type属于"需加校验"列表，走Haiku 5.5，但输出必须过校验器，校验失败则升级到中档模型重试。
4. 如果task_type属于"不切换"列表，直接走中档模型。

这个路由层本身不复杂，几十行代码就能实现。关键是要把task_type的声明做规范，不能让调用方随便传。我一开始没做约束，结果有些调用方把复杂任务标成简单任务，导致质量事故。后来改成白名单机制，task_type只能从预定义列表里选，问题就解决了。

路由层还有一个隐藏收益：它让成本变得可观测。每个task_type的调用量、Token消耗、重试率都能单独统计，哪块成本高、哪块可以继续优化，一目了然。

4. 实操落地：从核算到上线的完整流程

4.1 第一步：采集真实调用数据，建立成本基线

在动任何代码之前，先花两三天采集真实调用数据。需要采集的字段包括：task_type、输入Token数、输出Token数、使用的模型、是否重试、响应时间。

采集方式很简单，在现有的调用封装层加一段日志就行。关键是不要采样，全量记录。因为成本核算对长尾很敏感，采样容易漏掉高消耗的调用。

采集周期建议至少覆盖一个完整的业务周期（比如一周），这样能捕捉到工作日和周末的差异。我采集了7天，总共约12万次调用，数据量足够做决策了。

采集完之后，按task_type分组统计，算出每组的：日均调用量、平均输入Token、平均输出Token、P95输入Token、P95输出Token、重试率。这张统计表就是成本基线，后面所有优化都跟它对比。

4.2 第二步：用基线数据算清楚"切换收益"

有了基线数据，就可以算切换收益了。算法是：

原成本 = Σ(task_type调用量 × (平均输入Token × 中档输入单价 + 平均输出Token × 中档输出单价)) 新成本 = Σ(可切换task_type调用量 × (平均输入Token × Haiku输入单价 + 平均输出Token × Haiku输出单价)) + Σ(不可切换task_type调用量 × 原单价) + 重试成本

重试成本要单独算，因为Haiku 5.5在"需加校验"任务上的重试率比中档模型高。我实测下来，结构化提取任务的重试率从3%升到了12%，这部分额外成本必须计入。

算完之后我得到一个关键数字：切换后总成本降到原来的21%。这个数字比单纯"降价90%"听起来保守，但它是真实的、可复现的。原因就是前面说的，只有约75%的调用能真正切换，加上重试成本，最终降幅是79%而不是90%。

提示：如果你的业务里"可切换"任务占比更高，降幅会更接近90%。反之如果复杂任务多，降幅会小很多。所以核算一定要基于自己的数据。

4.3 第三步：灰度上线与质量监控

算清楚收益之后，不要一次性全量切换。我的做法是灰度：先切10%的流量到Haiku 5.5，观察一周；没问题再切到50%，再观察一周；最后全量。

灰度期间要盯的指标有三个：

• 质量指标：准确率、重试率、校验失败率。任何一个指标恶化超过阈值就回滚。
• 成本指标：实际账单 vs 预估账单。差异超过10%就要查原因。
• 延迟指标：Haiku 5.5的响应时间通常比中档模型快，但如果路由层引入额外开销，整体延迟可能反而上升。

我灰度期间遇到过一次质量波动：某个task_type的校验失败率突然从5%跳到18%。排查发现是那批输入里有一类特殊格式，Haiku 5.5处理不好。解决办法是在路由规则里加了一条前置判断，遇到这类格式直接走中档模型。这种问题只有灰度才能发现，全量切换就晚了。

4.4 第四步：建立持续的成本监控看板

切换完成不是终点。模型价格会变、业务量会变、任务分布也会变，成本核算必须持续做。

我搭了一个简单的监控看板，每天更新几个核心数字：总调用量、各模型调用占比、总成本、单次平均成本、重试率。看板不复杂，但能让我在成本异常时第一时间发现。

看板里我特别关注一个指标：单次平均成本的变化趋势。如果它突然上升，通常意味着任务分布变了（比如复杂任务占比增加），或者某个task_type的重试率上升了。这两个原因对应的处理方式完全不同，需要进一步下钻分析。

5. 常见问题与排查技巧实录

5.1 成本核算类问题

问题一：预估成本和实际账单对不上，差20%以上。

排查思路：先看是不是漏算了缓存费用。缓存写入和命中的单价虽然低，但量大时也会累积。再看是不是漏算了重试调用。最后检查Token计数口径——有些平台的Token计数和你的估算方式不一样，比如对特殊字符的处理。

我的经验是，预估和实际差异在10%以内算正常，超过15%一定要查。我遇到过一次差异25%，最后发现是系统提示词被重复计入了——每次调用都带上了完整的系统提示词，而我在估算时只算了用户输入部分。

问题二：降价后总成本没降多少。

这通常是因为可切换任务占比低。解决办法不是硬切，而是优化任务拆分。比如把一个复杂任务拆成"提取+推理"两步，提取部分交给Haiku 5.5，推理部分交给中档模型。这样能提高轻量模型的承接比例。

我试过把一个长文档分析任务拆成"分段摘要（Haiku）+ 汇总推理（中档）"，成本降了60%，质量几乎没损失。

5.2 质量类问题

问题三：Haiku 5.5在结构化输出上格式不稳定。

这是最常见的坑。解决办法有三层：第一层是在prompt里给严格的格式示例；第二层是加输出校验器，格式不对就重试；第三层是重试两次仍失败就升级到中档模型。

我实测下来，加了这三层之后，结构化提取的有效成功率从85%提升到了97%，接近中档模型的水平。代价是重试成本，但算总账仍然划算。

问题四：某些输入类型上Haiku 5.5表现明显差。

不同模型对输入类型的敏感度不一样。我遇到的是超长输入（超过8000 Token）时Haiku 5.5的质量下降明显。解决办法是在路由层加输入长度判断，超过阈值直接走中档模型。

这个阈值需要自己测。我的做法是拿一批不同长度的输入跑对比，找到质量开始明显下降的拐点，把阈值设在拐点之前。

5.3 速查表

这些坑我基本都踩过一遍。最深的体会是：模型选型不是选一个"最好的"，而是设计一套"最合适的组合"。降价只是给了你重新组合的机会，能不能吃到红利，取决于你的工程能力。

6. 几个容易被忽略的细节和我的实操心得

6.1 系统提示词的长度直接决定成本下限

这一点值得单独拎出来说。系统提示词每次调用都会重复计费，如果你的系统提示词有2000 Token，每天调用10万次，那就是2亿Token的输入消耗。降价之后这部分成本虽然低了，但绝对量仍然可观。

我的优化做法是：把系统提示词里"每次都一样"的部分和"随任务变化"的部分拆开。固定部分尽量精简，能删的删，能合并的合并。我把自己项目的系统提示词从1800 Token压到了600 Token，光这一项就省了三分之二的输入成本。

6.2 输出长度约束是最有效的省钱手段

输出Token通常比输入贵，所以控制输出长度是省钱的关键。方法是在prompt里明确要求"只输出结果，不要解释"，并且给出字数上限。

我实测过，加了输出约束之后，平均输出Token从320降到了180，降幅44%。而且质量没有下降，因为那些被砍掉的都是冗余的解释性文字。

6.3 缓存策略要跟着模型切换一起调整

不同模型的缓存行为可能不一样。切换模型之后，原来的缓存命中率可能下降。我切换后第一周就发现缓存命中率从35%掉到了22%，原因是Haiku 5.5对某些输入的归一化处理和原模型不同。

解决办法是重新设计缓存键，把模型标识也纳入缓存键的一部分，避免不同模型的缓存互相污染。同时针对Haiku 5.5的输入特征重新调优缓存策略，命中率慢慢回到了30%以上。

6.4 不要忽略"小模型+多次调用"的组合

有时候一次中档模型调用能完成的任务，用两次Haiku 5.5调用也能完成，而且总成本更低。比如一个需要"提取+判断"的任务，可以拆成两次调用：第一次提取，第二次判断。两次Haiku调用的成本可能只有一次中档调用的三分之一。

但这种做法会增加延迟和工程复杂度，适合对延迟不敏感、对成本敏感的场景。我自己的项目里，批处理类的任务用了这个策略，实时类的任务还是单次调用。

6.5 价格会再变，核算框架要能复用

最后说一个心态层面的东西。这次Haiku 5.5降价90%，下次可能别的模型降价，或者涨价。重要的不是记住这次的具体数字，而是建立一套能复用的核算框架。

我的框架就是前面说的四步：采集基线、算切换收益、灰度上线、持续监控。这套框架跟具体模型无关，跟具体价格无关，换任何模型都能用。下次价格再变，我把新价格填进去，半天就能算出新的选型方案。

这套框架我用了大半年，中间经历过两次价格调整，每次都能快速响应。比起每次重新拍脑袋，效率高太多了。如果你也在做类似的成本优化，建议先把框架搭起来，再谈具体选型。