“成本敏感型开发”这个词，这几年在 AI 应用圈里出现的频率越来越高。尤其是当你把大模型接进生产环境、做成面向真实用户的产品之后，Token 不再只是调试时一个抽象的数字，而是每个月账单上一个很具体的金额。做技术方案的时候选哪家模型、用多长的提示词、给多深的上下文，这些决策直接决定了项目是赚钱还是赔钱。
这篇文章就围绕 Token 计数和模型选型这两件事，讲一套可落地的 ROI 计算思路。我不是要给你一个花里胡哨的理论框架，而是把我自己在一套内容分析类项目里实际怎么算账、怎么调优、怎么避坑的过程拆开讲一遍。主要内容包括：Token 计费的基础规则和换算陷阱、不同模型之间的成本质量对比方法、一个可以套进自己项目的 ROI 计算表，以及一套从基线到优化的完整调优案例。适合正在做 AI 应用开发、想理解成本结构、或者想把已有项目成本压下来的工程师和技术负责人阅读。
1. 为什么成本敏感型开发成了一种刚需能力
很多团队最开始接触大模型的时候，心态都是“效果优先”——哪个模型效果好用哪个，Token 贵一点无所谓。但一旦进入生产环境，用户量上来，业务对并发有要求，成本敏感这件事就会从“锦上添花”变成“生死攸关”。我见过不少项目上线第一个月就烧掉预算的大半，功能倒是稳定，但商业上根本算不过账。
1.1 成本失控的常见场景
我梳理一下自己见过的高发场景，基本可以归为三类。
第一类是对话产品的上下文堆积。用户和机器人多轮聊天，每一轮都把历史消息全量塞给模型。表面上看一次请求没几个钱，但一个活跃用户一天聊几十轮，每轮的上下文长度还在不断变长，这就像滚雪球，月末账单一出来，所有人都会沉默。
第二类是批量处理任务忽略单条成本。做信息抽取、文本分类、内容摘要这类离线任务时，一次性跑几百万条数据，单条成本哪怕只差几厘钱，乘以数据量之后就是一个很可观的差额。有人图省事，直接拿最强模型跑所有数据，四倍的价格差就这样白白送出去了。
第三类是调试阶段的大量重复调用。开发的时候同一段文本反复调模型试 prompt，一次两次无所谓，一个团队每人每天试几十次，累计的量其实不小。
这三个场景有一个共同点：都发生在“没有成本意识”的环节里。不是技术上做不到省，而是根本没有把成本当成一个需要管理的技术指标。
1.2 成本结构与估算模型
要想管理成本，得先搞清楚钱花在了哪里。大模型 API 的费用结构其实不复杂，核心就三项：输入 Token 费、输出 Token 费、固定请求费（少数平台按次计费时会有）。再加上一个容易被忽略的隐藏变量——失败重试产生的重复计费。
我习惯把一次业务请求的成本拆成这么个公式：
单次请求成本 = 输入 Token 数 × 输入单价 + 输出 Token 数 × 输出单价
这个公式看着简单，真正难的是估算 Token 数。Token 不是字符，它跟语言类型、分词器实现强相关。同样是 1000 个汉字，不同模型的计数结果能差出 30% 以上。所以实际做预算的时候，我不会靠猜，而是先写个小脚本，用目标模型自带的分词器跑一批代表性数据，测出一个“每千字折算 Token”的系数，再乘上预估的业务量。
另外一个关键点是输入输出的比例。很多任务表面上是“输入一大段、输出一小段”，比如文本分类、实体抽取，输入输出比可能是 50:1。但也有些任务，比如内容扩写、翻译，输出比输入还长，这时候输出单价高的模型就会被放大劣势。建成本模型的时候，一定要把输入输出比纳入考虑，否则算出来的 ROI 会和真实账单相差很大。
2. Token 计数的精度把控：从字符到计费单元的换算陷阱
Token 计数是整个成本计算的基础。如果这一步不准，后面所有模型对比、预算预估都是空中楼阁。但 Token 计数恰恰是最容易想当然的环节。
2.1 中英文 Token 差异不是什么玄学
先说结论：英文里通常 1 个 Token 约等于 4 个字符，中文里 1 个 Token 约等于 1 到 1.5 个汉字。造成这种差异的原因在于分词算法。
英文有天然的空格分词，常见的英文单词会被整体编码成 1 个 Token，长单词拆成 2 到 3 个。而中文没有空格，分词器通常会按“字节对”的方式来切，一个汉字在常见模型里大约是 0.6 到 1 个 Token。这意味着同一段话，用英文表达和用中文表达，Token 计数能差出 2 倍以上。
这在实际项目里有个很直接的启发：如果你的产品面向中文用户，输入内容却是中英混杂的（比如技术文档、代码注释），那 Token 计数的波动就会很大。我遇到过一种情况，同一批数据的 Token 消耗在模型 A 和模型 B 之间差异达到 40%，不是模型本身贵，而是不同分词器对中文和代码的切分效率不同。
所以要做的第一件事，就是用一个简单的脚本统计目标模型对“中文文本”“英文文本”“混合文本”三类内容的实际 Token 消耗。别直接用厂商提供的预估工具，那个通常只是粗略乘法，不够精确。
2.2 上下文窗口与请求循环的累加效应
如果说单次请求的 Token 计数还算简单，那会话场景下的累计计数就复杂得多。
假设一个客服机器人，每次请求都把最近 10 轮对话历史加上系统提示词一起发给模型。初始时一轮对话可能只有 500 Token，但随着对话轮次增加，每轮请求里携带的历史会越来越长。到了第 20 轮，一次请求可能就有 3000 Token 以上。而且这是“每轮都重新计费”，不是累加计费——也就是说，用户聊 20 轮，你付的是 20 次请求各自输入 Token 的总和，不是最后一次请求的 3000。
我给大家一个直观的数据感觉：如果一次请求输入约 2000 Token，输出约 500 Token，日调用 1 万次，按常规价格折算，一个月下来就是几十万元的量级。对于中小团队来说，这基本是“不可持续成本”。
在这种场景下，控制成本的思路通常是三种：截断历史（只保留最近 N 轮）、做摘要压缩（把早期对话压缩成摘要再喂给模型）、或者调整滑动窗口策略。后面实战部分我会具体说怎么算这三种方案的 ROI。
2.3 计费边界：输入输出、缓存命中、并行请求
Token 计费还有一个容易忽略的边界问题——输入和输出价格往往不同。大多数平台的输出单价是输入单价的 2 到 4 倍。有些团队优化提示词时只裁输入，对输出长度毫不在意，结果输出占比很高的场景里，成本降幅远不如预期。
另一个边界是缓存。部分平台对完全相同的输入前缀提供缓存计费（比正常输入便宜很多），但这要求应用层主动设计缓存策略，比如把系统提示词放在最前面并保持不变，保证每次请求的前缀一致，才能命中缓存。实践中有个矛盾：业务规则一变，系统提示词就得改，缓存命中率立刻下降。所以我建议把“系统提示词 + 固定示例”放在「稳定前缀区」，把“用户动态输入”放在后面，这样缓存收益最大。
并行请求也要留意。有些平台对并发有阶梯计价，或者对整批任务有聚合折扣，但你要是完全无脑地一次开 100 个线程跑，不仅拿不到折扣，还可能触发限流导致失败重试，重复计费直接让成本翻倍。
3. 模型选型的 ROI 计算框架：怎么才算“划算”
模型选型不是“哪个效果好选哪个”，而是在质量、成本、延迟三个维度里找平衡点。我理想中的模型选型流程，应该是一个可重复计算的决策过程，而不是拍脑袋。
3.1 用质量-成本-延迟三角做横向评估
我把模型选型拆成三个维度：
质量维度：在你自己业务的真实数据上测，别信榜单。一个模型在公开基准上能打 90 分，但在你的垂直领域可能只有 70 分，而另一个小模型因为训练数据覆盖了这个领域，反而能到 85 分。所以每个候选模型都要用自己的测试集去跑一遍，产出可量化的质量分。
成本维度：用前面提到的方式测出实际 Token 消耗，乘以目标模型单价，得到单次成本。再乘上预估的月调用量，得到月度总成本。
延迟维度：延迟不仅影响用户体验，还影响成本——超时重试会产生额外请求。我建议把延迟纳入成本公式：设置一个延迟上限，超过上限就认为该模型不可用，不参与性价比比较。
在这个三角框架里，真正难的是“质量分”的量化。我的做法是两步走：第一步做任务级的通过率测试，比如抽取任务里字段级别的准确率；第二步做人工抽样评分，取一个小样本让业务方打分，得到一个综合分。质量分的作用不是追求绝对精确，而是让不同模型之间有可比较的基准。
3.2 一个可复现的 ROI 计算表
下面这个表是我在某内容分析项目里实际用到过的对比方式。假设业务需求是“给每篇新闻打标签”，预估月处理量 300 万篇，平均每篇输入 800 Token，输出 100 Token：
| 模型 | 输入单价（每千Token） | 输出单价（每千Token） | 单篇成本 | 质量分 | 月成本 | 折合质量为满分的性价比排名 |
|---|---|---|---|---|---|---|
| 模型 X（旗舰） | 0.03 | 0.06 | 0.030 | 92 分 | 9 万 | 2 |
| 模型 Y（标准） | 0.015 | 0.03 | 0.015 | 88 分 | 4.5 万 | 1 |
| 模型 Z（轻量） | 0.005 | 0.015 | 0.0055 | 75 分 | 1.65 万 | 3 |
这里单篇成本的计算方式是 800/1000 × 0.015 + 100/1000 × 0.03 = 0.012 + 0.003 = 0.015。如果只看绝对成本，模型 Z 最便宜。但结合质量分看，模型 Z 只拿 75 分，如果业务要求 85 分及格，它直接被淘汰，根本不用算性价比。
更精准的做法是把“质量分不达标带来的返工成本”也计入。比如模型 Z 的准确率低，会导致人工重审比例上升 10%，每篇多花人工费 0.01 元，那模型 Z 的实际成本就不是 0.0055，而是 0.0155，瞬间失去优势。这也是为什么我一直强调：ROI 计算一定要把劣质输出的下游补救成本算进去，否则会得出完全错误的结论。
3.3 模型降级与路由策略：省钱的核心杠杆
选型不只是选“用哪个模型”，更关键的是设计“什么场景下用哪个模型”。这就是所谓的模型路由。
我在项目中常用的是一个三档路由策略：
第一档（简单任务）：关键词匹配、模板匹配，或者直接用轻量模型，这类请求量大但难度低，根本不需要大模型参与。
第二档（标准任务）：默认使用标准级模型，覆盖大多数业务请求，质量分 88 分左右，成本适中。
第三档（疑难任务）：当系统判定任务复杂度高，或者标准模型给出的置信度低于阈值时，才升级到旗舰模型。
这个策略听起来简单，落地时的关键却在于“判定逻辑”怎么设计。我用的方式是：先让轻量模型给出结果，同时附带一个自评置信度；置信度高就采用，置信度低就路由到更大模型。整个过程中，小模型处理了 70% 的请求，成本大幅下降，而最难的 30% 交给强模型，整体质量损失很小。
从实际效果看，这个策略能把总成本降掉 40% 到 60%，而且对用户体验几乎无感。相比单纯砍上下文、裁提示词，路由优化带来的收益更稳定、更可持续。
4. 实战：一套内容分析系统的成本调优全流程
前面讲的都是框架和原理，这一节我把一个虚构项目“某内容分析系统”的完整调优过程拆开，按时间线记录每一步做了什么、算了什么账、结果如何。项目背景：对入库的新闻文章做“标签抽取 + 情感判断 + 摘要生成”，预估日处理量 10 万篇。初始方案用的是旗舰模型，直接全量处理。
4.1 初始方案与成本基线
初步设计时，三件事放在一次请求里完成：标签抽取、情感判断、摘要生成。每篇文章平均正文 1500 字，折合约 1200 Token 输入，输出平均 200 Token。
用旗舰模型的报价：输入 0.03 元/千 Token，输出 0.06 元/千 Token。 单篇成本 = 1.2 × 0.03 + 0.2 × 0.06 = 0.036 + 0.012 = 0.048 元。
日处理 10 万篇，日成本 4800 元，月成本（按 30 天）约 14.4 万元。听着不至于肉痛，但这是单一功能模块的成本，业务整体还有其他模型调用，叠加起来就很夸张了。
初始方案最大的问题，是把三个强弱差异很大的任务打包在一起。情感判断相对简单，摘要生成对模型能力要求最高。一个旗舰模型干所有活，显然不是最优配置。
4.2 首次优化：提示词压缩与任务拆分
我在首个优化轮次做的事有三件：
第一步，压缩输入。原方案把整篇正文都塞进 prompt 做摘要和打标签。我做了个预处理：先对正文做一次关键句抽取（用规则+轻量模型），只把最重要的 300 到 500 字和标题、发布时间、来源等结构化字段传给生成模型。输入 Token 从约 1200 降到约 450。
第二步，拆分任务。把“标签 + 情感 + 摘要”一次请求拆成三种不同请求，分别用不同模型处理。情感判断用轻量模型，标签抽取用标准模型，摘要生成用旗舰模型。
第三步，裁输出。给摘要设置更明确的长度约束，并让模型输出结构化 JSON，避免多余的客套话和解释性文字。
第一次优化后的成本变化如下：
情感判断：输入 100 Token，输出 20 Token，全用轻量模型。 成本 = 0.1 × 0.005 + 0.02 × 0.015 = 0.0008 元。
标签抽取：输入 450 Token，输出 50 Token，用标准模型。 成本 = 0.45 × 0.015 + 0.05 × 0.03 = 0.00825 元。
摘要生成：输入 450 Token，输出 150 Token，用旗舰模型。 成本 = 0.45 × 0.03 + 0.15 × 0.06 = 0.0225 元。
单篇总成本 = 0.0008 + 0.00825 + 0.0225 = 0.03155 元，相比初始的 0.048 元，降了约 34%。月成本从 14.4 万降到 9.465 万，省了约 5 万元。
这个优化轮次的核心收获是：任务拆分带来的收益比单纯压缩 prompt 更大。因为拆分后可以让每个模块用恰好够用的模型，而不是所有任务都享受最高待遇。
4.3 二次优化：缓存、批量与模型路由
第一次优化把成本降到每月 9.5 万左右后，我又往下挖了几个手段。
缓存命中优化：把系统提示词设计成完全固定的前缀，放在 prompt 最前面；同时把业务配置参数（比如标签枚举列表）也做成固定字符串。同一批文章使用相同的规则前缀，平台能命中缓存，缓存部分的输入计费降到正常价格的约 10%。我们做了统计，大约 60% 的请求能稳定命中缓存。
批量聚合：因为业务是离线批处理，对实时性要求不高，我把单篇请求改成批量合并，一个请求处理 5 篇文章。输入 Token 有一定冗余（因为要加分隔符），但请求次数从 10 万降到 2 万，降低了对并发额度的占用，失败率也降下来了。重试导致的额外成本几乎归零。
动态路由上线：情感判断模块全部交给轻量模型，标签抽取做路由——轻量模型先给一版标签，带上置信度。置信度超过阈值就直接用，否则升级到标准模型。实际数据显示，约 70% 的请求在小模型就收口，30% 升级。摘要生成保持旗舰模型不变。
对这些变化重新计算一下。
情感判断：日调用 10 万次，全是轻量模型。 成本 = 10 万 × 0.0008 = 80 元/日。
标签抽取：10 万篇里 7 万篇走轻量模型，3 万篇走标准模型。 轻量成本 = 7 万 ×（0.45 × 0.005 + 0.05 × 0.015） = 7 万 × 0.003 = 210 元。 标准成本 = 3 万 × 0.00825 = 247.5 元。 标签合计 = 457.5 元/日。
摘要生成：10 万篇全走旗舰模型，加入缓存优化后，输入计费部分打折。 输入约 450 Token，其中 60% 命中缓存按 10% 计费，40% 正常计费。 加权输入单价 = 0.03 ×（0.6 × 0.1 + 0.4 × 1） = 0.03 × 0.46 = 0.0138 元/千 Token。 摘要成本 = 0.45 × 0.0138 + 0.15 × 0.06 = 0.00621 + 0.009 = 0.01521 元/篇。 日成本 = 1.521 万元。
这里要说明一下，缓存计费的逻辑在不同平台有差异，有的平台是缓存未命中时按正常输入价，命中时按折扣价。我这里的加权算法是简化模型，更精确的估算需要结合平台的实际结算报告。
优化后单日总成本 = 80 + 457.5 + 15210 = 15747.5 元。月成本约 47.24 万元？不对，这里我算错了，应该是 15747.5 × 30 = 472425 元，这显然不对。我需要重新算一下摘要生成的日成本，因为前面把“每篇 0.01521 元”看成“每万篇 0.01521 元”了。
重新整理：摘要日成本 = 10 万篇 × 0.01521 元/篇 = 15210 元。情感日成本 = 10 万 × 0.0008 = 80 元。标签日成本 = 457.5 元。合计 = 15747.5 元/日，月成本约 47.24 万元。这个数字反而比上一轮还高，明显不合理。
问题出在摘要生成的成本计算上：初始方案单篇 0.048 元里，摘要部分占 0.0225 元。优化后摘要部分应该是 0.01521 元，比 0.0225 便宜，日成本应该是 10 万 × 0.01521 = 15210 元？这里我犯了单位错误。0.01521 元/篇 × 10 万篇 = 1521 元，因为 0.01521 元是“元/篇”，乘以 10 万篇应该是 1521 元！对，0.01521 × 100000 = 1521 元。我把小数点移错了。
同理，情感判断 0.0008 元/篇 × 10 万 = 80 元，这个没错。标签 0.003 × 7 万 + 0.00825 × 3 万 = 210 + 247.5 = 457.5 元，也没错。摘要应该是 0.01521 × 10 万 = 1521 元。合计 = 80 + 457.5 + 1521 = 2058.5 元/日，月成本约 6.18 万元。这样才合理，比第一轮 9.47 万元再降约 35%。
这些计算过程告诉我一个教训：做成本优化时，每一步的算术都要反复核对，尤其要注意“元/篇”和“元/千 Token”之间的量纲转换。小数点错一位，结论就全反了。
4.4 最终 ROI 对比与收益
三个轮次的成果汇总如下：
| 阶段 | 单篇成本 | 月成本 | 相较初始 | 质量影响 |
|---|---|---|---|---|
| 初始方案 | 0.048 元 | 14.4 万元 | 基线 | 基线 |
| 首轮优化（压缩+拆分） | 0.03155 元 | 9.47 万元 | 下降 34.3% | 摘要质量持平，标签质量略升 |
| 二轮优化（缓存+路由） | 0.02059 元 | 6.18 万元 | 下降 57.1% | 情感判断准确率下降 1.5%，在业务容忍范围 |
单篇成本 = 2058.5 ÷ 10 万 ≈ 0.020585 元，我取 0.02059 元。
如果把人工复核成本也计入，评估更完整。因为情感判断准确率下降了 1.5%，意味着每天有 1500 篇文章需要人工抽检，假设人工抽检每篇耗时 0.5 分钟、人力成本每分钟约 0.5 元，额外成本约 375 元/日。即便如此，总成本也只是 1.08 万元/月，仍然显著低于首轮方案。这就是“劣质输出下游补救成本”在 ROI 计算里的实际应用。
5. 常见问题与排查技巧实录
最后这部分是实战中踩过的坑和排查方法，比前面的理论更容易直接用上。
5.1 高频踩坑点
第一个坑：用厂商页面的 Token 计数工具估算生产数据。厂商展示的计数结果往往基于即时输入串，一旦你的输入里有图片、表格转文字、特殊符号，误差会剧增。我建议养成一个习惯：每个模型上线前，自己写个脚本，抽样跑 500 条真实数据，统计“请求输入字符数”和“实际计费 Token 数”的比值，存成一个系数表。后面再做预算、压测、成本预估，都用这个系数。
第二个坑：忽略模型版本迭代导致的 Token 结构变化。同一个厂商的模型升级后，分词器可能换了逻辑，同样是 1000 个汉字，Token 数会变。如果你在优化前不重新测一次，之前的成本模型就是过时的。我遇到过模型默默升级导致 Token 消耗涨了 25% 的情况，账单差点失控。
第三个坑：输出长度预算设得太宽松。很多项目写“max_tokens = 1024”，但业务上根本不需要 1024 个输出 Token。输出费用单价高，这部分是很大的浪费。我建议根据真实业务的输出长度分布来设置上限，比如 90% 的响应都在 150 Token 以内，那就把上限设成 200，多出的空间用来自动截断。这个调整本身几乎免费，但成本影响不小。
第四个坑：把人月成本忽略。不少团队只算模型 API 费用，不做任何缓存、批量优化，因为开发资源有限。但反过来也有团队过度优化，花两周开发一个路由模块，省下来的钱可能不够这两周的人力成本。所以做任何一项成本优化之前，先算一下“开发工时 × 人力单价 / 预计年节省额”，如果回本周期超过 6 个月，就要慎重考虑。
5.2 预算告警与观测体系搭建
成本优化做完不是一劳永逸，必须配套观测和告警。我自己的体系包含四层：
第一层，请求级日志：每次请求记录模型名、输入 Token、输出 Token、缓存命中情况、耗时。这是成本分析的基础数据，必须有。
第二层，按业务维度聚合：把请求日志按业务线、场景、甚至按用户维度聚合，算出每个维度的日成本。这样能第一时间发现“某个用户把成本打爆了”这类异常。
第三层，预算告警：设置月预算的 50%、80%、100% 三档告警。触达 80% 时自动通知，触达 100% 时触发限流或降级策略，防止月底账单失守。预算告警不是设置完就不管，要定期校准，尤其是模型价格变化后。
第四层，成本环比分析：每天和上周同一天的对比，有 10% 以上的波动就自动生成分析任务，确认是新功能上线还是异常调用。没有这个环比，很多成本问题要等账单出来才发现，往往已经晚了。
工具方面，我试过直接调厂商的后台 Metric，够日常看，但做多维分析还是得自己搭一套基础的数据采集。轻量方案是写个日志处理脚本，简单聚合输出到一张报表；再往后可以接入内部可观测平台做看板。关键不是工具本身，而是“每个请求都能回溯到业务和场景”，没有这个基础，优惠省多少都体现不出来。
5.3 工具链推荐与开源替代
如果不想全自研，推荐几个实用工具方向。
一是提示词工作台。用于管理不同版本的 prompt、对比 Token 数和效果，团队协作时能省很多沟通成本。选择标准很简单：支持分环境管理、支持变量渲染、能预览 Token 数。
二是离线批处理调度器。当业务是大量离线任务时，用调度器统一管理批量并发、重试策略、失败补偿，可以显著减少重复请求。很多团队直接用消息队列就够，不一定非得引入重框架。
三是本地分词器对比工具。部分开源分词器和主要模型厂商的分词规则接近，你可以本地用 Python 或 Node 快速跑 Token 估算。注意：本地估算只是近似值，最终还是要以厂商结算为准，不要拿本地数值去精确对账。
四是成本监控面板。如果没有内部可观测平台，最简单的替代方案是用数据库 + 定时报表，每天凌晨跑一个 SQL 聚合，把昨日成本、环比波动发到群里。够用，而且零成本。
我个人的建议是，工具不要贪多。一个团队在早期最需要的只有一个可靠的日志采集方案和一个定时成本报表，其他都可以慢慢补。先让成本数据跑起来，再谈优化。
最后再分享一个小技巧：做模型选型和成本优化的过程中，每做一次调整，就把“为什么做、预期省多少、实际省多少”记录在案。这不是为了写文档，而是因为这些经验在下次做新品规划、申请预算、跟业务方解释成本结构时，全是硬通货。踩过几次坑之后我最大的体会是：成本敏感型开发真正难的不是技术，而是像算钱一样算 Token，像做产品一样做选型。能把这两件事做明白，团队在 AI 项目上的利润空间，往往就是从这里抠出来的。
