Token 计费这件事我在项目里被账单教育了整整三次才真正把“Prompt 越写越贵”背后的机制看清。很多人以为模型计价是按“字数”或者“条数”来的真不是。你输入的那段精心打磨、层层叠叠的 Prompt每一帧都在按 Token 数以更贵的价格被吞掉而你对 Token 的想象和 API 实际的切分方式差距大到足以解释为什么别人 0.5 元能跑完的任务你花了两块五。这篇内容不讲虚的直接带你把计费公式掰开揉碎Token 到底怎么切、输出为什么比输入贵、你的 Prompt 里哪些“无用但昂贵”的词在悄悄吃掉预算以及怎么把成本压下来。适合所有在调 API、写 Agent、搭 Chatbot 的朋友特别是那种“感觉没干嘛但预扣余额总在跳”的人。看完你就能自己算出每一轮请求的真实价格并且知道从哪一刀切下去最疼。1. 计费的第一性原理Token 根本不是按字算的1.1 为什么 1000 个汉字能变成 2000 个 Token模型在做推理之前会先把你塞进来的文本“切碎”成最小语义单元这个单元就叫 Token。不同模型有自己独立的词表切分算法也不一样但绝大多数商用模型的词表里英文单词和常见标点通常一个词根切 1 到 2 个 Token而汉字呢单个汉字在很多主流词表里也被切成一个 Token但别高兴太早——空格、换行、前后缀、特殊符号、重复的语气词全部单独计。举个例子中文里“你好世界”四个字加一个逗号如果按“你好”合起来切也许 3 个 Token但如果你把这句改成“你好呀世界”加语气词、加波浪号、加空格可能直接变成 6 到 8 个 Token。而英文更狠一个长单词如 internationalization 会被切成好几个 Token因为词表里没有完整单词。于是同样一个语义量字节更长的写法 Token 更多账单更贵。这里最关键的一层你发出去的中文表面看是“几个字”实际计费是“切完的碎片数量”。碎片越多越贵。Prompt 里凡是冗余的修饰词、铺垫性的客套、不必要的换行缩进、重复列举的格式符号不产生推理价值但全部计入当前请求的输入 Token。1.2 输入和输出从来不是一个价很多第一次接 API 的人只看到单价一个很小的数字根本没注意价格表里有两列输入列和输出列。输出列通常是输入列的 2 到 5 倍。因为生成一个 Token模型要做一次“自回归采样”是真正的算力消耗而读输入只是把已有 Token 做前向编码成本低很多。那这和“Prompt 越写越贵”有什么关系关系太大了。你 Prompt 写了很多输入费是涨了一点但更伤的是Prompt 如果诱导模型输出长篇内容、重复输出你已经写进 Prompt 的限定条件、或者用“请详细说明”这种话逼模型把每一点都扩写输出 Token 数会暴增而输出 Token 每个都按高价计。我的一个模拟项目 X 里有个客服机器人最初版本把“要有礼貌”“请帮用户详细解答”反复写进系统提示词。结果模型发现用户态度不好时就开始长篇道歉一个原本 50 Token 能答完的问题输出干到 300 多 Token。账单一翻输出计费直接占掉总成本八成。你说这是 Prompt 的问题还是计费规则的问题两者都有但根子在于你没理解“输出才是吞金兽”。1.3 成本估算必须先算 Token 总量要快速判断一次请求花多少钱有个非常实用的估算公式单次成本 输入Token数 × 输入单价 输出Token数 × 输出单价。单价在哪看你用的那家平台的定价页注意区分“每千 Token 价格”还是“每百万 Token 价格”我第一次看的时候把单位看错算出来的预算打了个八折心理预期真到账单下来直接裂开。你可以做个简单的对照1 个汉字大约等于 1 到 1.5 个 Token1 个英文单词大约等于 1.3 到 2 个 Token。如果你写的 Prompt 是中文 500 字别按 500 Token 估按 700 到 800 Token 更稳妥。输出端同理如果模型输出 1000 字中文按 1300 到 1500 Token 估。理解了 Token 切分和输入输出差价才能往下聊“到底谁在让 Prompt 越来越贵”。最终你会发现贵不是因为你用了大模型而是因为你的 Prompt 生产方式天然制造了冗余并且你毫无感知。2. Prompt 膨胀的五个真实路径你的钱被谁吃掉了2.1 系统提示词越叠越厚的复利效应这是最隐蔽的吃钱大项。开发一个应用时你需要系统提示词来设定角色和规则。今天加一句“你是一个严谨的助手”明天加一句“回答要分步骤”后天再加“请结合用户历史上下文”。每条单独看都不长但累积起来很容易超过 800 Token甚至我看到有些项目里系统提示词写到 2000 Token。关键问题在于系统提示词不是你只在开场发一次而是每一次请求都会被完整发送到模型。用户跟你对话 10 轮这 2000 Token 就被计费 10 次。用户聊得多热闹你的系统提示词就扣得多频繁。如果再加上多轮对话里每轮都要拼接历史那 Token 就是以“轮次 × 系统 历史 当前”这么个乘法关系在跑。所以你会发现一个诡异现象业务没多少用户其实也没聊多少句但成本高得出奇。几乎可以断定是系统提示词在复利累积。那种“一轮对话就完成任务”的简单调用还好只要涉及多轮系统提示词的膨胀直接决定你的成本天花板。2.2 few-shot 示例被当模板无限复制few-shot 是调 Prompt 的常用手段给模型一两个示例它就能学会你要的格式。问题是很多人舍不得删示例甚至把“示例”写得和正式指令一样长。每次都带三个示例每个示例输入输出都 150 Token那光 few-shot 部分就是 450 Token 起步再叠加系统提示词和历史消息压力直接拉满。更坑的是有些示例内容本身包含重复话术。比如给客服模型示范“如果用户生气请先道歉然后解释原因”这个示例模型根本不需要你直接指令写清楚就行。示例的用途是让模型模仿“格式和语气”不是让它背业务逻辑。能用一条模板说明白的事写成示例就是在为冗余付费。我见过一个项目把 few-shot 减到零完全用指令模板代替输入 Token 少了 40%效果没降。所以告别“示例越多越好”的迷信用指令把边界限定清楚比给一堆例子省得多还更好维护。2.3 思维链提示词被滥用成“付费作文”思维链CoT提示词比如“请一步一步思考”本身确实能提升复杂推理任务的准确性。但它的问题也很明显模型会以为你真的要求它把所有内部推理都写出来于是一顿“首先、然后、接着、再者”的输出光解释思路就写五百字。这些文字全部按输出高价计费。正确做法是区分任务。数学、逻辑、代码调试这类推理任务可以适当引导模型“仅输出最终结果不输出推理过程”或者把推理范围限制在内部。你真要检查它的推理质量就只保留关键步骤明确告诉它“简要给出依据最多三行”。实测下来输出 Token 直接少一半效果几乎不变。很多人不知道你写“请详细思考”模型的理解就是“写长一点”。而“写长一点”和“思考得更好”之间没有必然关系。计费只认 Token不认深度。你得多精贵它就得按高价给多少。想省钱就要明确压制输出长度。2.4 格式化牺牲品JSON、Markdown 与标签噪音做应用开发时为了结构化返回你让模型输出 JSON、Markdown 表格或者带 XML 标签的内容。这些格式本身会占用大量 Token。比如一个 JSON 字段名status_code拆成 Token 可能是好几个再叠加引号、冒号、大括号、缩进一个本来 30 Token 能表达的对象格式化后 60 Token 起步。输出端格式化成本翻倍还不算最气人的。最气人的是你把格式化要求写进 Prompt然后模型输出得稍微不合规你又得“重新生成一次”重试一次就再计一次费。一个 JSON 解析失败重试三遍等于一单变三单独成本直接三倍。优化思路是能少要求格式就少要求。如果一定要 JSON明确只返回必需字段不必返回完整接口文档、不必带多余描述。也可以考虑在系统提示词里固定一个极简的 JSON 模板让模型只填空填错概率低输出短钱花得值。2.5 对话历史的“滚雪球”效应多轮对话应用中每轮要带历史消息。如果你不做截断10 轮之后每次请求可能带进来 3000 甚至 5000 Token 的历史其中大部分是重复的客套话、无意义的确认语句。用户在第 15 轮问的问题其实只依赖最近两轮信息但你把前 13 轮全塞给模型它们也全部计费。更坑的是模型生成的历史消息里还包含长回复。你让模型上一轮答了 800 Token 的详细报告下一轮用户简单说“嗯”你这 800 Token 又被完整计费一次因为它是上下文。合理方案是按 Token 窗口做滑动截断至少做一个“最近 N 轮 系统提示词 当前问题”的拼接策略而不是无脑全传。对话历史膨胀是所有聊天型应用成本失控的第一大原因。在动手优化 Prompt 之前先把上下文管理做起来预算立刻会好看很多。这部分我后面第三节再给具体策略。3. 上下文管理成本失控的第一现场3.1 不使用滑动窗口的代价我曾经维护过一个带记忆的问答 Bot一开始图省事把所有聊天记录直接塞进上下文。用户聊了半小时后每发一句话我要往模型传最近几千个 Token 的完整历史。用户只问了一句“那上次说的地址是啥”结果这一句带着前面十条长回复一起计费单次请求成本从 0.01 元涨到 0.08 元翻了八倍。这个场景很典型你以为模型有记忆其实是你在替模型背书“存储费”。模型的上下文要你主动把内容传过去才能“记得”。所有你传的内容都是钱所以你要像管硬盘空间一样管理上下文窗口越短越好。我后来采用的做法是只保留最近三轮对话加当前问题。命中率几乎没下降因为绝大多数用户问题只依赖最近语境而真正需要长期记忆的东西应该走向量检索把命中的相关片段拼进来而不是傻乎乎地把所有历史都带着。成本下降 60% 以上响应速度还更快。3.2 把“长期记忆”交给向量库而非上下文如果你做了一个长期记忆功能比如记录用户的偏好、历史订单别把它们全都做成历史对话往里塞。更合理的做法是把关键实体和结论离散化存储每次根据当前问题检索最相关的 2 到 3 条记忆注入提示词。这样 Token 占用是稳定的不会随着时间线性增长。向量库那套东西听起来高级本质就是“检索相关片段”。你可以用一个简单的关键词匹配先顶上。重点是“只填需要的内容”而不是“把仓库全搬进来”。很多项目的记忆功能膨胀到不可控就是因为偷懒不分相关性全量拼接。3.3 带外信息与常规请求分流上下文中还有一种很常见但容易被忽略的膨胀来源把大量固定的带外信息比如业务 SOP、产品百科、客服话术全部写死在 Prompt 里。这些内容往往几千 Token但实际每次请求只会命中其中一小部分。我的建议是这些固定知识库内容别当 Prompt 写做成检索片段。在代码里先判断用户问题匹配哪个片段再把它拼接进 Prompt。输送给模型的知识少而精准模型准确率反而更高Prompt 总长也大幅下降。上下文管理的核心原则只有一句每一次计费都是拿你传进去的所有 Token 算的少传那些用不上的内容成本自然会降。4. 模型选型与参数配置看不见的加价项4.1 大模型不是贵在聪明是贵在“每 Token 都更贵”这是很反直觉的一点不同模型的差价不在“输出质量”而在“单价”。同系列模型里轻量版和旗舰版的价格差距可以达到几十倍。很多任务根本不需要旗舰版的推理能力但开发者习惯默认用最强的成本自然压不住。教程里说“选择合适模型”像废话但真实场景里我见过太多项目只是做个简单的意图识别和固定话术回复也调用超大模型。这种任务用一个轻量模型完全够单价却省了 70%。成本优化首先看模型选型其次才轮到 Prompt。选型时要考虑任务复杂度、需要推理的深度、可接受的延迟、对输出格式的稳定性要求。不是“越聪明越好”而是“刚好能完成就好”。你可以做一个分层策略简单任务用轻量模型只有复杂推理才让旗舰模型上场整体成本立刻降下一大截。4.2 最大 Token 上限的隐藏门道很多开发者只设置了 max_tokens 作为输出上限却没意识到这个参数和计费的直接关系。max_tokens 设得过大模型就可能把回答写得又臭又长尤其在没有后续约束时模型默认倾向“把话说完”。这不只是体验问题每一个多生成的 Token 都是钱。最合理的做法是先估任务输出规模。比如“一句话回答”max_tokens 设 50写代码按需设置 500总结长文设置 800。别一刀切给一个超大值。如果模型经常达到上限被截断再针对性调大也不迟。另外还有 temperature 这类采样参数虽然不会直接改变单价但过高的随机性会导致模型胡言乱语语义漂移严重时你会想重试而重试本质就是重复计费。规范做法是固定一个适中的采样参数保证输出稳定少做重试动作。4.3 重试与多次调用隐性计费翻倍调试阶段代码报错然后重试同一请求这个太常见了。但每一次重试都是完整计费的。有人写代码时忘了处理网络超时结果同一请求被自动重试三次三倍金额就这么白白扣了。在 API 调用逻辑里要注意幂等设计和错误分类。是网络波动导致调用失败重试才有意义是参数错误重试多少次都一样烧钱。你需要在业务层面做好容错比如超时后先查询上下文状态而不是无脑重新发请求。同时很多项目为了提取结构化数据先让模型生成完整回答再让另一个模型总结关键词一次任务调用两次 API。这属于架构层面的重复计费。能在一个 Prompt 里完成的事不要拆成两段确实要拆也要确认前一个输出没有浪费。5. 实操账单拆解一个典型客服 Bot 的成本优化全过程5.1 优化前的真实账单结构我做一个模拟项目 X客服 Bot日均请求 5000 次每次请求带系统提示词 1200 Token、带历史上下文平均 1500 Token、用户输入平均 200 Token、模型输出平均 600 Token。用某主流 API 的中间价位估算输入每百万 Token 约 15 元、输出每百万 Token 约 60 元。单次请求输入 1200 1500 200 2900 Token单次请求输出 600 Token。按价格算输入成本 2900/1000000 × 15 ≈ 0.0435 元输出成本 600/1000000 × 60 ≈ 0.036 元。单次成本约 0.08 元。日均 5000 次一天成本 400 元一个月 30 天就是 1.2 万元。这个数字看着不夸张但当你发现这 1.2 万里有一半是因为“系统提示词写太长 历史全量携带 输出缺乏约束”你说你心痛不心痛。5.2 按成本结构逐项优化第一步把系统提示词从 1200 Token 压到 400 Token。去掉所有客套话、重复的格式说明、大段的角色扮演背景只保留角色定义、输出规则和边界条件。这块能省多少每次请求输入直接省 800 Token单次成本减少 0.012 元日均省 60 元月省 1800 元。第二步历史上下文从全量携带改成最近 3 轮裁剪从 1500 Token 压到 500 Token。日均再省约 0.015 元每次月省 2250 元。第三步输出约束加指令“简要回答不超过 3 句”同时 max_tokens 从 1024 调到 200。平均输出从 600 Token 压到 180 Token输出成本降七成单次节省约 0.025 元月省 3750 元。三步加起来单次成本从 0.08 元降到约 0.025 元月成本从 1.2 万降到 3750 元。省了接近 70%而且是在产品质量不降的前提下。这个案例说明Prompt 优化不是玄学是能一笔一笔算出来的账。5.3 优化后还要盯的两个指标成本优化做完不代表一劳永逸。要持续盯“每次请求平均 Token 数”和“日均调用次数”。前者可以通过日志统计如果发现 Token 数悄悄回升大概率是提示词又被人加了新内容或历史窗口逻辑出了问题。后者关注业务量的自然增长增长本身没问题但单次成本要保持在低位才健康。我给你的建议是每次改动 Prompt顺手记录改前改后的“输入 Token 平均值”和“输出 Token 平均值”数字会告诉你所有的真相。感觉这个东西在成本控制里最不靠谱只有数字不会说谎。我之前给系统提示词做“瘦身”的时候很多开发者担心效果下降。实际上约束越清晰模型越容易输出符合要求的内容。模糊的长篇大论才是诱导模型自由发挥然后输出失控的根源。6. 避坑清单与经验速查6.1 六条立刻可以落地的省 Token 技巧系统提示词只写必要角色与规则总长控制在 500 Token 内。多轮对话只传最近 3 轮超过 3 轮的历史不保留。输出要明确给出长度限制别只写“请简洁”。能用指令说清的事不要配示例示例最多 1 到 2 条。避免让模型先长篇输出再二次提取信息一次完成最省钱。所有格式化输出尽量压缩字段去掉不必要的信息。这六条每一条都能单独见效合在一起效果是乘法级的。不用改代码架构不用换模型只是调整你组织文本的方式钱就下来了。6.2 Token 计数工具和调参建议开发过程中一定要用 Token 计数工具来估量 Prompt 长度。平台一般有在线 Tokenizer你可以在本地写脚本调用。习惯了“写完 Prompt 先数一数”之后你对成本会非常敏感这种敏感会在设计阶段就帮你避开冗余。另外如果你用官方 SDK注意是否开启了自动重试或自动补全功能。有些默认配置会在请求失败时自动重试 3 次这在你测试阶段会让你莫名其妙消耗大量 token。调试阶段建议关掉自动重试在业务代码里自己控制。调参方面temperature 我建议固定在一个较低值比如 0.3 以下保证输出稳定减少重试top_p 不要和 temperature 同时乱动保持一个默认值max_tokens 按任务类型分别设置不要全局一个值。6.3 预算告警和用量监控最后也是最重要的一件事开通用量告警。大多数平台支持预算阈值和调用量监控你要把告警阈值设在预期成本的 80%不要等到余额空了才发现失控。如果平台没有这个功能自己写脚本拉取账单每天凌晨检查一次“日均 Token 消耗”和“单次请求平均 Token”。成本控制的本质是“观测”。能观测才有优化看不到数字你连哪里在漏钱都不知道。很多项目成本爆炸不是因为用了最贵的模型而是因为完全没看账单等回过神来已经烧了一笔冤枉钱。别让这个过程发生在你身上。我在实际项目里踩过最痛的一次就是一个看似不起眼的日志打印函数把所有请求和响应全文打到了日志文件里结果日志系统因为存储成本先爆了。Token 计费只是显性成本由文本膨胀带来的隐性运维成本同样要命。所以最后再分享一个个人习惯每次写 Prompt我都会先把文本粘到计数工具里看一遍 Token 数就 10 秒钟的事但一年下来省下的费用相当可观。