1. 从 Coding Plan 说起为什么费用问题突然变得尖锐1.1 一个让很多团队措手不及的转折点如果你在过去一年里深度使用过各类 AI 编程辅助工具大概率经历过这样一个阶段平台方推出所谓的 Coding Plan按月订阅、额度管够、随便调用价格低到让人觉得“这玩意儿简直不要钱”。那段时间很多团队把 AI 编程助手当成了日常开发的标配代码补全、单元测试生成、代码审查、重构建议全都交给大模型来处理。但到了 2025 年下半年情况开始变了。多家平台陆续调整了 Coding Plan 的规则有的把“无限调用”改成了阶梯计费有的把高参数模型的调用从套餐里剥离出来单独收费还有的直接取消了包月制全面转向按 Token 计费。我身边好几个做 AI 应用开发的朋友都在吐槽“以前一个月几十块随便用现在同样的调用量账单直接翻了五六倍。”这就是所谓的“后 Coding Plan 时代”——补贴期结束大模型调用回归真实成本。对于个人开发者来说可能只是每月多花几十块钱的事但对于日均调用量在百万 Token 级别的团队来说费用对比和优化就成了一个必须认真对待的工程问题。1.2 这篇文章能帮你解决什么问题我写这篇东西的目的很直接把当前主流大模型的费用结构拆开揉碎结合实际调用场景算清楚一笔账让你知道在什么情况下该选哪个模型、怎么组合使用能把成本压到最低。具体来说我会覆盖以下几个方面的内容主流大模型 API 的计费逻辑和价格对比包括输入输出分别计价、缓存命中折扣、批量调用优惠等细节不同调用场景下的真实成本测算比如代码补全、长文本分析、多轮对话、Agent 工作流混合调用策略的设计思路怎么用便宜模型处理简单任务、贵模型处理复杂任务本地部署方案的成本对比什么规模下自建推理比调 API 更划算实操中踩过的坑和省钱的野路子这篇文章适合谁看如果你是大模型应用开发者、AI 产品的技术负责人、或者单纯是对大模型调用成本敏感的个人开发者这里的内容应该都能直接用上。如果你刚开始接触大模型还没到关心费用的阶段也可以先收藏着迟早用得上。1.3 一个重要的前提说明在展开之前我需要先说清楚一件事大模型的价格变动非常频繁。我写这篇文章时参考的是各平台公开的定价页面和实际账单数据但具体数字可能在你看到的时候已经变了。所以我的重点不是给你一个固定的价格表而是教你一套分析框架和计算方法让你在任何价格体系下都能自己算出最优方案。另外文中涉及的具体平台和模型我会尽量用通用描述避免变成某一家的软文。毕竟工具选型这件事适合自己的才是最好的。2. 大模型费用到底怎么算拆解计费逻辑2.1 Token 计费的基本单位所有按量计费的大模型 API核心计价单位都是 Token。你可以把 Token 理解成模型处理文本的“最小颗粒度”——一个中文字大概对应 1.5 到 2 个 Token一个英文单词大概对应 1 到 1.5 个 Token。代码的情况比较特殊因为符号多、缩进多同样字符数下 Token 数量会比自然语言高不少。这里有个很多人忽略的细节输入和输出的价格是不一样的。几乎所有平台都是输出 Token 比输入 Token 贵贵多少呢通常是 2 到 4 倍。这个差异背后的逻辑是输入 Token 可以并行处理计算效率高输出 Token 是自回归生成的必须一个一个蹦出来计算资源占用时间长。举个例子某个模型的定价是输入 1 元/百万 Token、输出 3 元/百万 Token。如果你一次调用传入了 2000 Token 的代码上下文模型返回了 500 Token 的补全结果那么这次调用的费用是输入费用2000 / 1,000,000 × 1 0.002 元输出费用500 / 1,000,000 × 3 0.0015 元合计0.0035 元单次看起来很少但如果你每天调用 10 万次一天就是 350 元一个月就是一万多。这就是为什么费用优化在大规模场景下如此重要。2.2 缓存命中被低估的省钱利器很多平台现在都支持上下文缓存Context Caching。什么意思呢如果你多次调用同一个模型且每次请求的前面部分比如系统提示词、固定的代码库上下文是相同的平台可以把这部分缓存起来下次调用时直接复用不重复计费。缓存命中的价格通常是正常输入价格的 10% 到 25%。也就是说如果你能把 80% 的输入 Token 都做成缓存命中输入成本直接降到原来的两成左右。这个机制对代码补全场景特别有用。因为代码补全的系统提示词和项目上下文往往很长且固定每次变化的只是当前编辑位置附近的一小段代码。把固定部分缓存起来费用能省一大截。但缓存有个限制大多数平台要求缓存内容至少有一定长度比如 1024 Token 或 2048 Token才能生效而且缓存有有效期通常是几分钟到几小时不等。如果你的调用频率很低缓存可能还没命中就过期了。2.3 批量调用折扣用时间换金钱另一个省钱的路子是批量 APIBatch API。你把一批请求打包提交平台在非高峰时段慢慢处理通常几小时内返回结果。作为补偿价格一般能打五折甚至更低。批量调用适合什么场景比如你要对一批代码文件做静态分析、生成文档、跑测试用例这些任务不要求实时返回完全可以攒一批一起提交。但如果你做的是交互式代码补全用户敲一个字符就要出结果那批量 API 就用不上。2.4 不同参数规模的模型价格差多少同一家平台通常会提供多个参数规模的模型比如 7B、13B、70B、几百B 等。价格差距非常大有时候小模型和大模型的价格能差 10 倍以上。这里有个常见的误区很多人觉得大模型一定比小模型好所以无脑选最大的。但实际上对于很多任务来说小模型的表现已经足够了。比如代码格式化、简单的变量重命名、基础的语法检查7B 级别的模型完全能胜任没必要用几百B的模型去烧钱。我的一般原则是先用小模型跑一遍如果效果不达标再升级到大模型。这个“渐进式升级”的策略在实际项目中能省下大量费用。3. 主流大模型费用横向对比3.1 国际主流模型的价格区间先看国际上的几个主要玩家。以下价格是我根据各平台公开定价整理的单位统一换算成人民币每百万 Token方便对比。模型系列输入价格元/百万Token输出价格元/百万Token缓存命中输入价格特点GPT-4o 级别35-70105-21017-35综合能力强价格高GPT-4o mini 级别1-34-120.5-1.5性价比高适合简单任务Claude Sonnet 级别20-4060-1202-8长文本处理好代码能力强Claude Haiku 级别2-58-200.2-0.5速度快适合高频调用Gemini Pro 级别10-2530-752.5-6多模态能力强Gemini Flash 级别0.5-22-80.1-0.5极低成本适合大批量处理这张表里的价格区间比较大是因为不同平台、不同地区的定价有差异而且经常调整。但整体格局是清晰的旗舰模型贵、轻量模型便宜差距在 10 到 50 倍之间。3.2 国内主流模型的价格区间国内的大模型平台在价格上普遍更有竞争力尤其是一些新兴平台为了抢市场价格压得很低。模型系列输入价格元/百万Token输出价格元/百万Token特点某旗舰大模型20-4060-120综合能力对标国际一线某中杯模型4-1012-30日常任务够用价格适中某轻量模型0.5-22-6高频调用首选某开源模型托管1-33-9基于开源模型价格透明某免费额度00有调用频率限制国内平台的一个显著优势是很多都提供免费额度。有的是每月赠送一定量的 Token有的是新用户一次性赠送还有的是对特定模型完全免费但限制并发。对于个人开发者和小团队来说把这些免费额度用好基本能覆盖日常开发需求。3.3 价格之外的隐性成本光看单价是不够的还有几个隐性成本必须考虑进去。延迟成本。便宜模型往往推理速度慢或者排队时间长。如果你的应用对响应速度有要求用便宜模型导致用户体验下降这个损失可能比省下的钱更大。重试成本。便宜模型的理解能力弱可能需要多次重试才能得到满意结果。每次重试都是一次完整调用算下来可能比直接用贵模型一次成功还贵。工程成本。如果你为了省钱搞了一套复杂的多模型路由系统维护这套系统本身的人力成本也要算进去。有时候简单直接地用贵模型总体成本反而更低。数据安全成本。调用外部 API 意味着数据要出你的服务器。如果处理的是敏感代码或用户数据可能需要额外的脱敏处理或者选择私有部署方案这些都是成本。4. 不同场景下的费用测算与选型策略4.1 代码补全场景高频低延迟代码补全是典型的高频调用场景。一个开发者一天可能触发几千次补全请求每次请求的输入输出都不大但架不住次数多。假设一个 10 人的开发团队每人每天触发 2000 次补全每次平均输入 1500 Token、输出 200 Token。一天的总调用量是输入10 × 2000 × 1500 30,000,000 Token 30 百万 Token输出10 × 2000 × 200 4,000,000 Token 4 百万 Token如果用某轻量模型输入 1 元/百万、输出 3 元/百万一天费用是 30 × 1 4 × 3 42 元。一个月按 22 个工作日算大约 924 元。如果用旗舰模型输入 30 元/百万、输出 90 元/百万一天费用是 30 × 30 4 × 90 1260 元一个月接近 2.8 万。差距接近 30 倍。所以代码补全场景的选型策略很明确优先用轻量模型配合缓存命中进一步降低成本。只有在补全质量明显不达标时才考虑对特定类型的请求升级到更大的模型。4.2 代码审查与重构建议低频高质量代码审查和重构建议的调用频率低得多可能一个 PR 才触发一次但每次的输入输出都很大而且对质量要求高。假设一个团队每天审查 20 个 PR每个 PR 的 diff 加上下文平均 8000 Token模型输出 2000 Token 的建议。一天的总量是输入20 × 8000 160,000 Token 0.16 百万 Token输出20 × 2000 40,000 Token 0.04 百万 Token这个量级下即使直接用旗舰模型一天的费用也就是 0.16 × 30 0.04 × 90 8.4 元。一个月不到 200 块。为了省这点钱去折腾小模型完全不值得。这个场景的选型策略是直接用最好的模型把精力放在提示词优化上提高审查质量。4.3 多轮对话与 Agent 工作流上下文膨胀是最大成本多轮对话和 Agent 工作流是费用最容易失控的场景。因为每一轮对话都要把之前的全部历史带上Token 数量会随着轮次增加而线性增长。假设一个 Agent 工作流平均执行 10 步每步的输入包括系统提示词2000 Token、历史步骤记录每步 500 Token、当前任务描述1000 Token。到第 10 步时输入 Token 数量是2000 10 × 500 1000 8000 Token如果每天执行 500 次这样的工作流平均每次输入 5000 Token、输出 500 Token输入500 × 5000 2,500,000 Token 2.5 百万 Token输出500 × 500 250,000 Token 0.25 百万 Token用中杯模型输入 5 元/百万、输出 15 元/百万一天费用是 2.5 × 5 0.25 × 15 16.25 元。看起来不多但如果工作流步骤增加到 20 步输入 Token 直接翻倍费用也跟着翻倍。这个场景的优化重点是压缩上下文。具体手段包括只保留最近几轮的历史、对历史记录做摘要、把固定信息做成缓存、用更简洁的提示词。这些优化能把 Token 数量压下来 50% 以上。4.4 长文本分析与文档处理输入为主长文本分析的特点是输入极大、输出较小。比如你要让模型读一份 5 万字的文档然后回答几个问题。假设每天处理 100 份文档每份 5 万 Token输出 1000 Token输入100 × 50,000 5,000,000 Token 5 百万 Token输出100 × 1000 100,000 Token 0.1 百万 Token这个场景下输入成本占绝对主导。所以选型时要特别关注输入价格以及是否支持缓存。如果多份文档有重叠部分比如同一项目的多个文件缓存能省不少钱。另外长文本场景要特别注意模型的上下文窗口限制。有些便宜模型的上下文窗口只有 8K 或 16K根本放不下长文档。这种情况下要么用支持长上下文的贵模型要么先把文档切块再做分析。5. 混合调用策略把每一分钱花在刀刃上5.1 模型路由的基本思路混合调用的核心思想是不同难度的任务用不同档次的模型。简单任务用便宜模型复杂任务用贵模型通过一个路由层来分发请求。路由的判断依据可以有很多种按任务类型代码补全走轻量模型代码审查走旗舰模型按输入长度短请求走轻量模型长请求走旗舰模型按用户等级免费用户走轻量模型付费用户走旗舰模型按置信度先用轻量模型试置信度低再升级到旗舰模型我实际用过效果比较好的是“按任务类型 按置信度”的组合。具体做法是所有请求先走轻量模型如果轻量模型返回的结果通过了某种质量检查比如代码能编译通过、输出格式符合预期就直接采用否则自动升级到旗舰模型重试。5.2 一个可落地的路由实现方案下面是一个简化的路由逻辑示例用 Python 伪代码展示class ModelRouter: def __init__(self): self.light_model LightModelClient() self.heavy_model HeavyModelClient() self.quality_checker QualityChecker() def route(self, request): # 第一步用轻量模型处理 light_result self.light_model.generate(request) # 第二步质量检查 if self.quality_checker.passes(light_result, request): return light_result # 第三步质量不达标升级到旗舰模型 heavy_result self.heavy_model.generate(request) return heavy_result这个方案的关键在于质量检查器的设计。对于代码补全可以检查生成的代码是否能通过语法解析对于文本生成可以检查是否包含必要的关键词或格式对于翻译可以用回译的方式检查一致性。质量检查器不需要完美只要能过滤掉明显不合格的结果就行。根据我的经验在代码补全场景下轻量模型的结果有 70% 到 80% 能直接通过检查只有 20% 到 30% 需要升级。这样综合成本大约是全部用旗舰模型的 30% 到 40%。5.3 缓存策略的精细化运营缓存用得好能省下大量输入成本。但缓存也不是万能的需要根据场景精细设计。对于代码补全可以把项目级的上下文比如整个文件的骨架、相关的类型定义做成缓存每次请求只传变化的部分。这样缓存命中率能到 90% 以上。对于多轮对话可以把系统提示词和固定的知识库内容做成缓存。但对话历史本身是变化的没法缓存只能通过摘要压缩来控制长度。对于批量文档处理如果多份文档有公共部分比如同一套模板生成的报告可以把公共部分缓存起来。需要注意的是缓存有存储成本。有些平台对缓存存储单独收费虽然价格不高但如果缓存内容很大且长期不用也会产生费用。所以要定期清理不再使用的缓存。5.4 批量调用的调度技巧批量调用能打五折但代价是延迟。所以关键是把“能等”的任务识别出来攒一批一起提交。适合批量调用的任务包括夜间跑的代码静态分析、定期生成的文档、离线数据处理、模型微调的数据准备。这些任务不要求实时返回完全可以攒到一定量再提交。我的做法是建一个任务队列所有非实时任务先入队当队列长度达到阈值比如 1000 条或者到了预设的提交时间比如每小时一次就打包提交批量 API。这样既能享受折扣又不会让任务积压太久。需要注意的是批量 API 通常有单次提交的数量上限和总 Token 上限提交前要检查一下。另外批量任务失败后的重试机制也要设计好避免因为个别请求失败导致整批任务卡住。6. 本地部署 vs API 调用什么规模下自建更划算6.1 本地部署的成本构成本地部署大模型听起来很美好——没有 API 调用费用数据不出本地想怎么用就怎么用。但实际上本地部署有一整套成本需要算清楚。硬件成本。这是最大的一块。要跑一个 70B 级别的模型至少需要两张 24G 显存的显卡加上配套的服务器一次性投入大概在 3 到 5 万。如果要跑更大的模型或者要求更高的并发硬件成本会成倍增加。电费。一张高端显卡满载功耗在 300W 到 450W 之间两张就是 600W 到 900W。加上 CPU、内存、散热整机功耗大概在 1kW 左右。按每天运行 10 小时、电费 0.6 元/度算一天电费 6 元一个月 180 元。运维成本。本地部署需要有人维护装驱动、配环境、更新模型、处理故障。这些工作虽然不直接产生费用但占用的人力时间是有成本的。折旧成本。硬件是有寿命的显卡一般用 3 到 5 年就该换了。把硬件成本按使用年限摊下来每年的折旧费也是一笔不小的开支。6.2 什么规模下自建更划算算一笔简单的账。假设你每个月的 API 调用费用是 X 元本地部署的月均成本硬件折旧 电费 运维是 Y 元。当 X 大于 Y 时自建更划算。以 70B 模型为例本地部署的月均成本大概是硬件折旧40000 / 48 个月 ≈ 833 元/月电费180 元/月运维按每月 2 小时算约 200 元/月合计约 1200 元/月也就是说如果你的 API 月费用超过 1200 元且调用量稳定自建就开始划算了。但要注意本地部署的模型能力通常不如同级别的 API 模型因为 API 模型往往有更多的优化和更大的参数量。6.3 混合部署本地兜底 API 弹性扩展实际生产环境中纯本地或纯 API 都不一定是最优解。更常见的做法是混合部署本地跑一个轻量模型处理日常请求遇到复杂任务或者流量高峰时自动切换到 API。这样既能保证基础服务的稳定性和数据安全又能在需要时获得 API 的强大能力。而且本地模型可以作为 API 的降级方案——当 API 服务不可用或者费用超预算时自动切回本地模型保证服务不中断。我见过一个团队的做法是本地部署一个 7B 模型处理 80% 的简单请求剩下 20% 的复杂请求走 API。这样每月的 API 费用控制在几百块同时保证了服务质量。硬件投入也不大一张消费级显卡就够了。7. 实操避坑指南那些账单教我的事7.1 常见问题速查表问题现象可能原因排查方法解决方案账单远超预期上下文膨胀检查每次请求的输入 Token 数压缩历史记录启用缓存缓存命中率低缓存内容太短或变化太频繁查看缓存命中统计增加固定前缀长度减少变化部分批量任务超时单批提交量过大检查批量 API 限制拆分批次控制单批 Token 总量模型响应质量差模型选型不当对比不同模型输出升级模型或优化提示词并发请求被限流超出平台 QPS 限制查看平台限流规则加队列缓冲或申请提额费用突然翻倍平台调价或计费规则变更对比历史账单和公告重新评估选型切换平台7.2 几个容易踩的坑坑一忽略输出 Token 的成本。很多人只关注输入价格觉得输入量大所以输入成本高。但实际上输出价格是输入的 2 到 4 倍如果模型输出很长输出成本可能超过输入。控制输出长度比如设置 max_tokens是省钱的重要手段。坑二缓存没配对。缓存要求请求的前缀完全一致才能命中。如果你在系统提示词里加了时间戳或者随机 ID缓存永远命中不了。检查一下你的提示词模板确保固定部分真的固定。坑三重试没有退避。调用失败后立即重试如果失败原因是限流立即重试只会继续被限流白白浪费调用次数。正确的做法是指数退避重试每次重试间隔翻倍。坑四没有设置预算告警。很多平台支持设置费用告警超过阈值就发通知。这个功能一定要开不然等到月底看账单才发现超支就晚了。坑五用旗舰模型做格式转换。有些任务其实不需要模型的理解能力比如 JSON 转 YAML、代码格式化这些用规则引擎或者小模型就能做用旗舰模型纯属浪费。7.3 我的省钱心得最后分享几个我在实际项目中总结的省钱技巧。第一先测再选。不要凭感觉选模型拿真实数据跑一遍对比测试。同样的任务不同模型的效果和费用可能差很多测过才知道哪个最划算。第二监控要细。按模型、按任务类型、按用户维度分别统计调用量和费用。这样才能发现哪些地方在烧钱有针对性地优化。第三留好退路。不要把所有请求都绑死在一个平台上。至少准备一个备选方案当主平台涨价或者出故障时能快速切换。第四定期复盘。每个月花半小时看看账单分析一下费用构成。很多时候优化机会就藏在那些不起眼的调用里。第五该花就花。省钱是为了更好地做事不是为了省钱而省钱。如果为了省几块钱导致开发效率下降或者产品质量受损那就本末倒置了。在关键任务上该用最好的模型就用把精力放在创造价值上。