token 到底是什么

token 是模型读写文本的最小单位，既不是字也不是词。模型内部先用分词器把文本切成一串 token，再逐个处理， API 计费也是按这串 token 的数量算钱——输入多少个、输出多少个，分别乘以各自的单价。 所以「这段话多少钱」这个问题，本质上是「这段话切成多少个 token」。

分词器是各家自己训的，切法不一样。同一段中文，A 家可能切出 100 个 token，B 家切出 130 个。 这也是为什么跨厂商比价时，只看单价会失真：单价低但分词更碎的模型，实际账单未必更便宜。 真要较真，就拿同一段代表性文本，分别调一次两家的 API，读各自返回的 usage 字段对比。

怎么用这个页面

把你真实要发给模型的内容整段粘进去——包括 system prompt、示例、检索到的文档片段， 而不是只粘用户那一句话。这是最容易低估成本的地方：很多项目的 system prompt 比用户输入长十倍， 而且每轮对话都要重发一次。粘完看 token 数的量级，再去 API 月成本估算器把日调用量乘进去，就得到一个能拿去排预算的数。

输出侧没法粘（还没生成），但可以用经验值兜底：问答类回答通常几百 token， 写代码、写长文的场景轻松上千。保守做法是按你设的 max_tokens 上限算一遍，得到成本天花板。

三个省钱的着力点

第一是把重复的输入变成缓存。如果每次请求的前半截都一样（固定的 system prompt、 固定的工具定义、固定的知识片段），多数厂商都提供提示缓存，命中后这部分输入按很低的折扣价计费。 这对长 system prompt 的项目效果最明显。

第二是别用旗舰模型干粗活。分类、抽取、格式化这类任务，轻量档模型的效果往往够用， 单价却可能只有旗舰的几分之一。常见做法是先用小模型跑一遍，只在它拿不准时才升级到大模型。

第三是控制上下文长度。把整份文档塞进上下文，比检索出相关的几段再塞进去贵得多， 而且长上下文还容易触发更高的分档价。具体怎么权衡，可以看 上下文长度计算器那一页。

不要指望它替代官方计数

本页用的是通用近似规则，不加载各家的真实分词器，误差在正负一两成是正常的。 它的定位是「上线前快速判断量级」，不是对账工具。真正需要精确数字的场合只有一个可靠来源： 调用返回里的 usage 字段，或厂商官方提供的 tokenizer 工具。