大部分关于「贵不贵、值不值」的争论，最后都卡在同一件事上：不清楚自己在为什么付钱。这一篇只讲最基础的三件事——一次请求里到底发生了什么、token 是怎么算的、账单由哪几项组成。
一次请求里，模型只做一件事：预测下一段文字
你把一段文字（提示词 / prompt）发过去，模型按顺序吐出下一段文字（回复）。它没有记忆、不保存你的对话——所谓「多轮对话」，是客户端每一轮把历史记录重新拼进提示词再发一遍。这一点决定了后面两件事：上下文越长越贵，重复内容越多越贵（所以才需要缓存）。
拿到模型能力的三种方式
同一句「调用大模型」，在工程上是三条不同的路，成本结构和风险完全不同：
| 方式 | 你付给谁 | 优点 | 主要代价 |
|---|---|---|---|
| 官方 API | 模型厂商 | 身份确定、价格透明、功能最全（缓存、批量、结构化输出） | 单价最高、多数要外币卡、部分区域受限 |
| 中转 / 聚合站 | 中间商 | 支付方便、单价低、一个 Key 调多个厂 | 渠道来源不透明、可能掉包或缓存不生效、有跑路风险 |
| 自建 / 开源权重 | GPU 平台或机房 | 数据不出内网、长跑成本可控 | 前期投入大、要自己运维、效果通常弱于一线闭源模型 |
Token：模型眼里的最小单位
模型不认识「字」，它看到的是 token。粗略换算：英文约 4 个字符 1 个 token；中文常见 1 个汉字 1～2 个 token（不同模型的分词器不一样）。所以「1000 字的文章」在不同模型上不是同一个价钱。
- 输入 token
- 你发过去的内容：提示词 + 历史对话 + 上传的文档 / 图片转成的 token
- 输出 token
- 模型生成的内容，通常单价是输入的 3～5 倍
- 缓存写入
- 把一段重复前缀（系统提示词、长文档）存进缓存，单价约为输入的 1.25 倍
- 缓存读取
- 下一轮直接复用缓存，单价约为输入的 0.1 倍
上下文窗口：能一次性装下多少 token
上下文窗口（context window）是「单次请求里，输入 + 输出加起来」的上限：128K 表示大约能装 128,000 个 token。宣传值和实际可用值往往有差：系统提示词、工具定义、图片都会占额度，留给回答的空间比想象中小。
- 超出上限通常直接报 400（context length exceeded），而不是自动截断；
- 很多站点的「1M 上下文」是按官方规格写的，实际上游链路会先截断，表现为回答变差而不是报错；
- 长上下文≠长记忆：把 200K 塞进去，模型对中段内容的回忆准确率会明显下降。
账单由什么决定
把一次任务的花费拆开，只有四项：
- ① 输入量
- 和你的提示词长度、历史轮数成正比
- ② 输出量
- 和模型啰嗦程度、任务复杂度成正比
- ③ 缓存是否生效
- 生效时重复部分打约 1 折；不生效就全价重算
- ④ 站方倍率
- 中转站按分组给不同倍率，同一次调用在不同站可能差数倍
先记住这 5 句话
- 按 token 计价，不按次数；报价必须换算成「每百万 token」才可比；
- 输出比输入贵 3～5 倍，让模型少说废话比省提示词更省钱；
- 历史对话每轮重发，长对话的成本是平方级增长的；
- 缓存是省钱的开关，能不能用、命中多少，是评判站点质量的关键指标；
- 「便宜的站」如果缓存不生效，最后往往比官方还贵。
常见问题
没有信用卡能用官方 API 吗？
多数厂商支持先充值后使用，但通常需要外币卡或虚拟卡；部分平台提供免费额度。如果完全没有支付手段，中转站或聚合平台是更现实的选择，但要接受渠道不透明带来的风险。
1 个汉字等于几个 token？
取决于分词器：多数中文模型约 1 个汉字 1 个 token，部分模型 1.5～2 个。英文约 4 个字符 1 个 token。要精确计算，用厂商的 tokenizer 或本站的 Token 单价换算工具按实际文本跑一遍。
上下文窗口越大越好吗？
不是。窗口大意味着可以塞更多内容，但成本随长度线性上升，且模型对超长上下文中段的回忆能力会下降。能靠检索解决的，不要整篇塞进去。