先从一起账单异常说起。有一个功能上线两周日活用户几乎没有波动可费用账单莫名其妙翻了快一倍。我最初的直觉是哪里出现了调用泄露或者有人扫了接口地址在做批量请求结果查了一圈日志发现调用量只涨了百分之十几。真正的问题出在我自己写的 Prompt 上——前一天下午我把系统提示词从原来的三百多个字“优化”成了满满两页的结构化模板还随手加了十几条 few-shot 例子。然后整晚没合眼反复盯着计费后台确认了一个让所有 AI 应用开发者都需要警惕的事实Prompt 越长越要按每次调用重复付费这个钱比你想象中烧得快得多。这篇文章不聊宏大的技术趋势只聊和账单直接相关的 Token 计费机制、隐形开销和优化手段。适合正在做大模型 API 集成、做聊天机器人、做内容生成工具或者单纯想把 API 成本压下来的人。看完之后你至少能回答三个问题为什么 Prompt 会越写越贵贵的部分到底贵在哪里以及改怎么把不必要的“字数成本”降到最低。1. 从一次让账单翻倍的排查开始1.1 一次 API 调用到底按什么收费所有主流大模型 API 都不是按“字数”计费而是按Token收费。你可以把 Token 粗略理解为模型处理文本时的最小颗粒度它可能是半个词、一个词也可能是一小段标点。每次请求的账单由三部分组成单次调用费用 输入 Token 数 × 输入单价 输出 Token 数 × 输出单价输入单价和输出单价不一样通常是输出比输入贵两到三倍。比如某模型定价是输入 $1/百万 Token、输出 $2/百万 Token那么一次请求输出了 5000 Token光输出部分就要花一美分左右——听起来不多但如果每秒有几十次调用一天就是几十上百美元的量级。我在排查那次账单翻倍时算了一笔账系统提示词从 350 字扩到 2200 字对应的 Token 增量大约是 3500 到 4000 个。平台每分钟平均有大约 2000 次调用每天近 300 万次。多出来的 4000 Token × 300万次 额外计费 120亿 Token。哪怕按输入单价很低算也足以让月度费用直接翻倍。很多团队的误区是只看 Prompt 的“最终效果”把 Prompt 当作文档来维护却忘了它每一次都会被完整计费。1.2 一个中文字符不等于一个 Token字数错觉带来的成本误判绝大多数人在预估 Prompt 长度时都是拿“字数”去衡量的这在英文场景里还凑合在中文场景里特别容易踩坑。主流平台的 Tokenizer 对英文文本大致是 4 个字符对应 1 个 Token中文则往往是一个汉字对应 1 到 2 个 Token具体取决于分词器实现和上下文窗口类型。这意味着同样长度的一段中英文混合文本实际 Token 数差别很大。我做过一个小实验同一句话分别用中英文表达统计出来的 Token 数常常差一倍以上内容大致文本长度大概 Token 数英文“Please write a Python function to sort a list”约 46 字符约 10中文“请写一个Python函数来给列表排序”约 18 个字符约 14结构化模板中文为主约 800 字约 1200结构化模板中英混合、含代码块约 800 字约 1600注意上面只是示意数据不同模型的实际切分结果会有差异但规律是明确的不要用“字数”去估 Prompt 成本要用 Tokenizer 跑一遍真实 Token 数。平台的控制台或者本地 SDK 基本都提供了可视化 Token 统计接口展示一次请求消耗了多少输入 Token 和输出 Token排查费用问题时第一件事就是把这些数值拉出来看而不是对着 Prompt 文本猜。实操提醒给团队定一个规矩任何 Promot 改动上线前都必须记录修改前后的 Token 总量并用一天高峰期调用量做一次费用预估。这个习惯至少能避免一半以上的“Prompt 优化导致成本激增”事故。2. 每次调用都在重复付费的“固定开销”系统提示词、few-shot 与历史消息很多人以为 Prompt 只是用户输入的那句话但真正烧钱的往往是你看不见的那部分。2.1 静态 Prompt 部分如何被反复计费一个典型的 API 聊天请求传进去的是一个消息数组大致长这样{ model: chat-model, messages: [ {role: system, content: 你是一个专业的写作助手……此处省略大量字数}, {role: system, content: 使用以下格式输出标题/正文/摘要}, {role: user, content: 今天想写一篇关于AI计费的文章}, {role: assistant, content: 好的我来帮你写} ] }问题的关键在于system里的所有内容每当用户发起一次新请求都会原封不动地发送给模型并完整计费。它不会因为你上一次已经告诉过模型就被“记住”API 本身是无状态的。除非你主动把这份静态内容放进缓存、或者用平台提供的前缀缓存机制命中折扣否则这个代价是刚性支出。我见过不少团队把企业文化、产品说明、安全规范、语气风格指南、行业知识库摘要、甚至几十条实体抽取规则全部塞进 system 提示词里一条 Prompt 轻松超过 10000 Token。这类 Prompt 在单次调用时看着不贵但一旦业务进入稳定期每天几万次调用Prompt 固定开销 静态 Token 数 × 调用次数就是一个不断放大的乘法公式。要注意同一份静态 Prompt 并不会因为内容完全相同而自动打折。不少平台推出的“提示词缓存”也需要符合条件的完整前缀匹配并不只是“内容没变就行”。2.2 多轮对话历史成本像滚雪球一样增长多轮对话是成本增长的第二大来源。每次新请求都会把之前的对话历史重新拼在 messages 数组里发出去。对话持续轮次越多携带的历史越长。假设每轮用户消息加助手回复平均 500 Token第 20 次请求时仅历史部分就有大约 9500 Token这还没算新的用户输入和系统提示词。模型在理解上下文时也确实需要看到之前的对话但这个机制有一个很隐蔽的成本递增规律每一次请求的输入 Token 数量都是当前全部历史的累计值。从第 1 轮到第 N 轮输入侧总费用近似与对话轮数的平方相关。也就是说如果一个用户跟你聊了 30 轮他在后面几轮里每一句话所牵动的“背景开销”都远大于前面几轮。这还没完Assistant 在历史里生成的内容通常偏长二次或多次生成后累计历史会迅速膨胀。实测经验是10 轮以内对话还算可控一旦超过 20 轮输入部分的 Token 会增长到让人肉疼的程度——尤其是这些历史还经常包含大量重复说明性的内容。2.3 函数定义、工具描述和 few-shot 也占输入 Token除了系统提示词和对话历史凡是走 Function Calling 或 Tool Use 方案的函数声明也会完整出现在每次请求的输入里。函数签名、参数描述、字段类型说明一个都没法省。有些接口一次同时传 20 个工具定义输入 Token 瞬间多个几千。few-shot 示例同理。你给每条示例都可能被完整换算成输入 Token。有些做法是把一整套“高质量输出范例”全量塞进 Prompt美其名曰让模型参考实际上一句话的信息增量只有几十 Token却让整个 Prompt 多出 3000 Token。这类“示范型”静态内容是 Prompt 变贵最常见的隐性原因。3. 同一个任务两种 Prompt 写法费用差多少一次实测对比只看理论够不着痛处下面我用实际可复现的对比来说话。3.1 详细版 Prompt 与精简版 Prompt 的差异假设任务很简单从用户评论里抽取情感倾向并输出 JSON。我分别写了两个版本。详细版约 1200 字纯中文系统 你是一个具备深度情感分析能力的专业客服舆情分析助手你的任务是分析用户评论的情感倾向。 请严格遵循以下要求 1. 首先仔细阅读用户评论内容 2. 判断该评论的情感极性可选值是positive、negative、neutral 3. 如果评论属于正面输出positive 4. 如果评论属于负面输出negative 5. 如果无法判断输出neutral 6. 不要输出任何多余内容 7. 以下是几个例子 用户评论这个app太好用了强烈推荐 情感倾向positive 用户评论垃圾产品再也不用了 情感倾向negative 此处省略更多示例 现在请分析以下评论精简版约 60 字系统 你是情感分析器。仅输出JSON{sentiment:positive|negative|neutral} 用户 这个app太好用了强烈推荐Token 数估算如下版本用户输入 Token 数输出 Token 数详细版约 300约 25精简版约 45约 25单次调用差不了几厘钱但乘上调用量就完全不一样了。3.2 放大到真实业务量费用差距有多大假设输入单价 $1/百万 Token输出单价 $2/百万 Token每天调用 100 万次版本单次输入费用单次输出费用每天费用详细版300 × 1 ÷ 1000000 $0.000325 × 2 ÷ 1000000 $0.00005约 $350精简版45 × 1 ÷ 1000000 $0.00004525 × 2 ÷ 1000000 $0.00005约 $95同样一个任务只是把 Prompt 写短写干净每天能省约 70% 的输入成本。再叠加多轮对话历史差距还会拉大因为详细版经过几轮之后历史中的“静态废话”会不断增加每一次后续请求的 Token 数。3.3 详细版容易诱导模型输出更多内容这才是账单爆炸的真正推手上面对比里输出端暂时一致但现实中详细版 Prompt 往往会导致输出更长。比如详细版里写了“请逐步分析”“先思考再回答”这类引导词模型输出时就会按照思维链的形式生成大段推理内容。如果最终产品只要求一个 JSON 字段这部分“思考过程”就完全是额外费用。有一次我在调试一个分类功能输入 Prompt 加了一句“让我们一步一步来分析”某模型的输出 Token 直接从 80 涨到 1200效果还没有任何提升。后来把推理过程关掉、改成要求只输出结构化 JSON输出端成本立刻降到原来的十分之一。把 Prompt 写长并不等于把效果写好它经常只是把“公共场合说话”时的解释性内容无限放大同时给额外扣费。4. 把 Prompt 做“薄”的五种实操手段聊完问题根源下面是我实际落地过的优化方法按收益从高到低排列。4.1 善用平台自带的前缀缓存把静态内容放前面现在不少模型服务商提供自动或手动的 Prompt 前缀缓存命中后输入价格会大幅降低某些平台的缓存命中价格只有原价的十分之一左右。关键在于缓存的匹配通常是基于前缀完全一致的所以必须把稳定不变的内容放在 messages 数组最前面。我现在的做法是系统提示词固定放在第一段最少量的静态示例紧随其后然后把动态变化的用户消息、工具结果放在末尾。这样每次请求的公网前缀都能命中缓存长期下来静态那一大段花的钱就几乎可以忽略。注意如果系统提示词每次都在变比如塞了当前时间、随机数字、每次都会变化的动态指令缓存就会频繁失效费用立刻飙升。不建议为了凑缓存故意把 Prompt 顺序调得很别扭。先保证逻辑顺序再考虑缓存。4.2 精简系统提示词只留“必须做什么”删掉“解释为什么”我复盘之前那版膨胀的系统提示词时发现大量内容属于“解释性文字”“本工具旨在提升客服团队的响应效率因此你要……”“考虑到不同用户的表达习惯存在差异……”“你的回答应当体现专业、耐心的服务态度……”模型不需要知道业务背景它只需要明确的指令。那些说明背景的句子占用的是你每次调用的输入 Token。把它直接删掉用更短的祈使句替代通常不会降低效果。一个通用的精简公式是角色 任务 输出格式约束 边界条件而不是大段背景介绍 角色设定 开放式要求 冗余例子 补充说明4.3 控制 few-shot 数量从二十条压到两三条few-shot 是消耗输入 Token 的大户。每加一条示例输入 Token 就固定增加几百效果收益却往往边际递减。我的经验是90% 的任务里3 条以内高质量、覆盖边界的示例效果等同于 20 条示例。真正需要模型参考的往往不是“通用例子”而是“边界情况”。比如做情感分类与其贴“这个很好”和“这个很坏”不如贴一个“这个产品价格便宜但质量一般有一点失望”这种模糊案例。把一个有信息量的边界示例放进去比十个明晃晃的正例有用得多。多出来的边界描述也只用一条示例就够了。4.4 给历史消息做摘要压缩而不是无限堆积多轮对话场景里最有效的手段不是每条历史都全量带回而是把早期历史以摘要形式存储并在合适的时机替换掉原文。我在实际项目中常用两层策略最近 5 轮对话保留全文保证模型对近期用户意图的精确理解更早的对话由另一个轻量模型定期生成一段 50 到 100 Token 的摘要或者直接用规则抽取关键信息然后替换掉完整原文。这样做的好处是用户聊到 50 轮时输入 Token 不会从 5 轮时的 2500 Token 线性涨到 20000 Token而是基本稳定在 5000 Token 左右。如果产品形态允许也可以直接限制单次会话的最长轮数比如 20 轮后提示用户开启新会话。虽然体验上有点“硬”但对成本控制特别有效。4.5 用结构化输出与参数卡住输出长度每次调用时设置合理的max_tokens上限并尽量要求模型以 JSON 或其他结构化格式输出可以从源头压低输出端费用。比如做信息抽取输出格式{summary: 不超过50字, keywords: [最多3个]}再配合 API 参数里的温度调低、开启 JSON 模式模型就不太会在回答里加无关的“好的我来处理”之类的客套话和解释。输出 Token 少了费用自然就降。写一个小工具做日常审计可以预判改动后的成本def estimate_cost(prompt_token, output_token, input_price, output_price, daily_calls): daily_input_cost prompt_token * daily_calls * input_price daily_output_cost output_token * daily_calls * output_price return daily_input_cost daily_output_cost # 修改 Prompt 后运行一次即可看到费用预估 print(estimate_cost(300, 25, 1/1_000_000, 2/1_000_000, 1_000_000))5. 计费文档不会主动提醒你的三个细节结合我个人的排查经验和读过的计费文档还有几个容易忽略的细节需要单独列出来。5.1 报错与中断也可能照样扣费请求如果已经进入模型推理阶段即使网络中断、客户端主动取消、或者模型在中途触发了某个审核规则已生成并计费的部分可能仍然会出现在账单里。不同平台的结算规则不一样但不少是按“已处理 Token”计费的而不是按“最终正常返回”计费。我在某个项目里做过一次对比对同一个请求重试 5 次其中有 3 次中断最终账单里多扣的正是中断那一刻已生成的 Token。解决办法是非关键路径上尽可能使用超时重试策略不要无限重试对实时性要求不高的任务尽量走异步接口或批量接口通常这类接口在失败时更容易拿到明确不计费的保障。5.2 缓存命中和未命中的价格差“必须完全一致”的前缀规则前面提过缓存这里补充一个关键细节不同平台的缓存粒度差异很大。有的平台只要前 1024 个 Token 完全一致就能命中有的平台要求整个输入完全相同才能命中。最实用的判断方法是查看计费日志里的缓存命中标记如果没有这个标记就手动对照线上实际每轮请求的清单一查便知。需要特别小心的是开场白或模板里的动态变量比如“今天是 2026 年 5 月 12 日”这种如果放在系统提示词的固定前缀中每次都会破坏缓存命中。把这类动态内容挪到消息末尾或者干脆不放比让模型知道“今天是哪天”更重要——除非这个日期对输出有实质影响。5.3 max_tokens 不是省钱开关理解生成停止条件把 max_tokens 从 4096 改到 128确实能限制输出长度但它的副作用是如果任务本身的正确输出就超过这个长度模型会在截断处停止返回一个不完整的结果甚至产生格式损坏、JSON 截断等问题反而增加下一次纠错请求的成本。所以正确用法是先摸清每个任务的实际输出 Token 分布再设置一个“略高于正常值”的 max_tokens而不是为了省钱而压得太狠。我一般取正常输出 Token 分布的 95 分位再乘以 1.2 作为上限。5.4 贵模型做难事便宜模型做杂事如果项目里同时依赖不同档位的模型建议按任务拆分配置而不是让所有请求都走向最贵的大模型。我接触过的一个内容审核系统原来统一用最贵模型跑全文审核流量一到高峰期账单直线上升。后来改成先用便宜的小模型做粗筛把明显安全的评论直接通过只有置信度较低的评论才送进贵模型做二次判断总费用降了接近一半准确率甚至还有小幅提升。这套思路同样适用于 Prompt让“长任务”走需要深度推理的模型让“短任务、强约束、格式固定”的请求走便宜模型。很多平台不同档位间的价格差能到几倍甚至十倍选型带来的成本差异远超 Prompt 微调。6. 每次改完 Prompt 之后我还会做的一道审计这节其实是我自己的一个习惯也算给本文一个自然的落点。在每次修改 Prompt、上线新功能、或者调整模型参数之前我会打开一个简单的清单用 Tokenizer 统计当前完整 messages 的输入 Token 数统计其中静态系统提示词 静态 few-shot 的 Token 占比再统计历史消息的平均 Token 数和最大对话轮数按昨日有效调用量估算一次单日成本检查动态变量是否破坏前缀缓存确认 max_tokens 是否合理、是否允许结构化输出。这套动作花不了五分钟但已经帮我拦住过三次差点上线的成本事故。尤其是第一和第二条只要静态部分在整体输入里的占比超过 30%我就会重新考虑拆分任务、缩精提示词或者换更便宜模型。实际上最深刻的体会是Prompt 越写越贵通常不是因为它真的需要我们付费那么多而是因为我们把“告诉模型一句有用的话”和“把一本书塞进模型脑子里”混为一谈。大模型 API 的计费本质是按计算资源消耗来收取只要模型还在处理那堆不会产生增量应该的冗余文字账单就会继续增长。与其纠结一个词一个词的措辞不如定期回到 Token 数和调用量这两项基础指标上做体检。希望这次的解构对你手上的项目也有帮助。如果你也在为 API 账单上的陡增曲线头疼可以试着从静态 Prompt 开始减重多数情况下效果会来得比想象中更快。