AI token
约 1468 字大约 5 分钟
2026-01-17
介绍
token 可以理解成：模型读写文本时用的“计数单位”，介于字符和词之间。输入（prompt）会被切成 input tokens，模型生成的回复会被切成 output tokens，分别计费。
OpenAI 官方解释就是：token 是文本的“积木块”，可能是一个字、半个词、一个词，取决于语言和上下文。
一个很粗的经验（仅供估算）：
- 英文：1 token ≈ 3/4 个单词 或 ≈ 4 个字符（不同 tokenizer 会有差异）
- 中文：很多时候可以近似按 1 个汉字≈1 token 估，但也会浮动（标点、空格、数字都会影响）
claude-opus-4-5 模型 23 $ 100 万 tokens
100 万 tokens 其实非常非常多，日常一次对话往往也就几百到几千 tokens。
真正烧钱的场景通常是：
- 塞了很长的上下文（几万 tokens）
- 或者你让它输出超长内容（尤其输出单价高）
- 或者你频繁多轮、每轮都带一堆重复系统提示（这时候缓存能救命）
模型定位/成本结构不同：顶级旗舰（Opus）就是贵，尤其输出贵
能力差异：代码/推理/对齐/稳定性强的通常更贵（值不值看你业务）
Cache write / Cache read 是 Prompt Caching（提示词缓存）：把 prompt 里“很长但经常重复”的前缀（系统提示、工具定义、长背景资料等）缓存起来。
Cache write（写缓存）：第一次把那段前缀“存进去”，通常比普通输入更贵（因为要创建缓存）
Cache read（读缓存 / 命中）：后续请求如果前缀完全一样，就按更便宜的“命中价”计费
Cache write / Cache read 说的主要就是 prompt（更准确说是“prompt 里那段稳定的前缀”） 的计费方式。
关键区别：不是“每次对话都会自动走缓存”
- 你的每次请求确实都会带 prompt（系统提示 + 历史消息 + 本轮问题）
- 但只有其中“重复且被允许缓存”的那一段，才可能触发 cache
所以才会出现：
- 第一次：这段前缀要“写进去” → cache write
- 后面：同样前缀再次出现 → cache read（很便宜）
- 但如果你每轮 prompt 都在变（哪怕只改了几个字、时间戳、随机 id、不同排序），那就命不中，还是标准 input 计费
总结：Cache = 给“重复的 prompt 前缀”打折，不是给“全部历史对话”自动打折。
默认情况下，历史消息不算 cache，所以会话越长越贵，而且很多时候是“越聊越像滚雪球”。
历史越长，input tokens 只增不减
在大多数 API/中转站里（不做缓存/不做裁剪）每一轮请求都会带上：system + 历史 messages + 本轮问题
所以第 N 轮的 input tokens ≈ 前 N-1 轮全部内容 + 这一轮输入 于是成本会变成一种“累加效应”：
- 前面聊得越多 → 后面每一轮都要重复读一遍 → 每轮都付钱
- 如果你还让它输出很长 → 输出也继续付
这就是消耗“倍数上升”的原因。
但注意：它通常不是严格指数爆炸，更像“线性变贵”
如果你每轮都追加同样长度的内容：
- 第 1 轮读 1 份
- 第 2 轮读 2 份
- 第 3 轮读 3 份…
所以总成本更像 1+2+3+… 的那种增长（越到后面越贵，但不是指数）。
历史消息变便宜有三种路：
用 cache（但只对“稳定前缀”有效）
如果把“项目背景/规范/模板/工具说明”这种长而稳定的东西放在前面，并且平台/调用方式真的启用了缓存，那么那一大坨可以走 cache read，后面每轮就便宜很多。
但“聊天历史”这种每轮都在变的内容，往往命不中缓存（哪怕只差一个字符）。
做“对话压缩”
每聊几轮，就让模型把当前进展总结成一段短的“状态”，然后你把原始长历史丢掉，只保留：
- 一段总结（短）
- 关键事实/决策（短）
- 必要的代码片段（短）
这招对“写文档/做项目设计”特别管用，省钱立竿见影。
只带“相关片段”，别带全历史
尤其写代码时：不要把整个 repo、整个聊天都塞进去。只带：
- 当前要改的文件片段
- 相关接口定义
- 相关约束
其余用一句话摘要即可。
性价比最高、翻车率最低的一种 LLM 工作流
LLM 工程化使用方案（省钱 + 稳定）
核心思想：用最强模型做“思考与设计”，用便宜模型做“执行与填充”，用任务拆解对抗 token 爆炸与模型失控。
在真实开发中直接用顶级 LLM：
- 会话越长 → token 成本滚雪球
- 任务越大 → 模型越容易跑偏
- 输出越多 → 钱烧得越快
而直接用便宜模型：
- 大任务容易设计崩
- 长期一致性差
- 架构与约束容易自相矛盾
解决思路：把“高认知难度”与“低认知执行”拆开。
总体策略：
旗舰模型 = 架构师 / 设计师
中低价模型 = 工程执行者
顶级旗舰模型（如 Claude Sonnet / Opus）
适合：
- DESIGN.md
- TODO.md
- 架构图（文字）
- 模块边界定义
- 接口契约
- 非功能性约束（性能 / 安全 / 可维护性）
不适合：
- 长时间多轮写代码
- 填充大量样板代码
原因：输出 token 单价高，但抽象与一致性能力最强。
中低价模型（MiniMax / Claude Haiku / GPT-4o-mini）
适合：
- 写具体代码
- 填充 DTO / Service / Controller
- 按 TODO 实现功能
- 快速试错与重写
前提：
- 必须有清晰的 DESIGN + TODO
原因：执行能力强、便宜，但不擅长自主设计。