“成本敏感型开发”这个词这几年在 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.030.060.03092 分9 万2模型 Y标准0.0150.030.01588 分4.5 万1模型 Z轻量0.0050.0150.005575 分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 项目上的利润空间往往就是从这里抠出来的。