上下文窗口与 Token 计费
理解大语言模型一次能”看见”多少东西，以及为什么对话越长反而单次越便宜。
一、Token 是什么（先澄清一个常见误解）
Token 不是字节，跟文件大小（KB / MB）无关，它是模型处理文本的最小单位。
| 内容 | 粗略 token 换算 |
|---|---|
| 1 个英文单词 | ≈ 1.3 token |
| 1 个中文字 | ≈ 1 ~ 2 token |
| 1M token | ≈ 40~50 万汉字 ≈ 一本中等厚度的书 |
所以”Opus 4.7 支持 1 兆上下文”说的是 1M tokens（100 万 token），不是 1 MB 文件。
二、上下文窗口里装了什么
一次推理，模型能”看见”的所有东西全部累加计入窗口：
- 系统提示（含
CLAUDE.md、memory、工具定义） - 所有历史轮次的 用户消息 + 助手回复
- 本轮新消息
- 工具调用的参数 + 工具返回的结果（常被低估，读一个长文件就能吞掉几千 token）
三、“1M 窗口”限制的是累计，不是单次
每次发送消息，客户端会把本次会话从第一条开始的所有内容全部重新打包发给模型。模型本身无状态——它没有记忆，所谓”记得前面”完全是客户端每次把历史重新塞进去营造的幻觉。
所以：
每聊一轮 → 打包发送的"包"就变大一点 → 直到撞上 1M token 的墙
单次问答几乎不可能撑爆（除非一次粘贴 30 万字文档）；真正会爆窗口的是长期累计 + 大量长文档。
四、超限了会怎样？不是”忘了”，是”塞不进”
模型本身没有”遗忘机制”，一次请求要么装得下、要么根本传不出去。不同产品层的处理方式：
| 产品 | 机制 |
|---|---|
| 裸 API 调用 | 直接返回 400 错误，请求失败 |
| Claude Code / 桌面版 | 接近 ~85% 时自动压缩，把早期对话摘要化后替换原文 |
| 某些聊天产品 | 滑动窗口，直接丢弃最早几轮 |
体验上像”忘了前面”，本质是被压缩或丢弃了。
五、图片与视频如何计 Token
图片：按像素面积算，不是文件字节
Anthropic 近似公式：
tokens ≈ (width × height) / 750
| 图片尺寸 | 约 token |
|---|---|
| 200 × 200 | ~53 |
| 500 × 500 | ~333 |
| 1024 × 1024 | ~1400 |
| 1568 × 1568（Claude 自动压到的上限） | ~3276 |
一张 3 MB 的 PNG 如果分辨率 1200×800，也就 ~1280 token，离 1M 差 3 个数量级。图片大小几乎不会撑爆窗口。
视频：Claude 不原生支持
需先抽帧成图片序列喂入。决定 token 量的是 帧率 × 时长 × 分辨率，不是文件大小。
- 1 分钟视频按 1 帧/秒抽 ≈ 9 万 token
- 10 分钟按 2 帧/秒抽 ≈ 180 万 token（超 1M 窗口）
所以视频确实容易撑爆，核心变量是帧数。
六、不同文档格式对 LLM 的友好度
从高到低：
| 排名 | 格式 | 原因 |
|---|---|---|
| 🥇 | Markdown | 纯文本零噪音，结构语义直接可读，Token 效率最高 |
| 🥈 | 纯 txt | 无噪音但缺结构，适合短文 |
| 🥉 | XML | 语义标签最清晰，适合”分段喂上下文”（外包一层），不适合整篇正文 |
| 4 | HTML | 语义标签可读，但 class / style / <script> 污染严重 |
| 5 | Word (.docx) | OOXML 冗余 + 样式污染，通常要先转文本才能读 |
实战建议：笔记正文用 Markdown；给模型喂”上下文 + 指令 + 示例”的复杂提示词时用 XML 分段，XML 内容里嵌套 Markdown。
七、Prompt Caching（提示词缓存）—— 理解计费的关键
为什么需要缓存
模型每次”读”输入都要做注意力计算，长对话若每次重算历史就是浪费。Anthropic 的缓存机制把**第一次计算的中间结果（KV state）**存起来，后续请求前缀一致时直接复用。
核心规则：命中缓存要求前缀一字不差完全相同；任一字符变动，从那里开始往后全部重算、重新缓存。默认缓存 5 分钟 过期。
四类 Token 与价格（关键！）
Claude Opus 4.7 官方价格（每 1M token，美元）：
| 类别 | 含义 | 价格 | 相对 input 的倍率 |
|---|---|---|---|
| Input（提示） | 新输入，未缓存 | $15 | 1.0x |
| Output（补全） | 模型生成的内容 | $75 | 5x（贵） |
| Cache read（缓存读） | 命中历史缓存 | $1.50 | 0.1x（便宜 10 倍） |
| Cache creation（缓存写） | 首次写入缓存 | $18.75 | 1.25x（略贵） |
价格从便宜到贵：缓存读 << 提示 < 缓存写 <<< 补全
用”健忘的抄写员”记住这套规则
你请了一位抄写员（=模型）帮你处理文稿，他记忆力为零，每次见你都像初次见面。
- 读新内容：1 块/页（input）
- 写回答：5 块/页（output，要动脑创作，贵 5 倍）
店家推出档案柜服务（=Prompt Caching）：
- 建档：第一次存档，1.25 块/页（cache creation，比普通读贵 25%）
- 调档：之后每次取用，0.1 块/页（cache read，打 1 折）
- 保鲜期 5 分钟，过期自动清理
这就是为什么对话越长反而越便宜：历史内容绝大部分从”档案柜”1 折调出，只有新增那一点按原价处理。
账单实例（2026-04-18 实测）
一次长对话的请求拆解：
| 类别 | token 数 | 单价 | 小计 |
|---|---|---|---|
| 提示（新问的话） | 100 | $5/M × 2.5 | $0.0005 |
| 缓存读（历史命中） | 101,355 | $0.50/M × 2.5 | $0.0507 |
| 缓存创建（本轮新增） | 2,771 | $6.25/M × 2.5 | $0.0173 |
| 补全（模型输出） | 248 | $25/M × 2.5 | $0.0062 |
| 总计 | $0.0747 |
注：这里是某第三方中转的账单，模型倍率 2.5x 是中转站加价。价格比例关系（1:5:0.1:1.25）与 Anthropic 官方一致。
关键洞察：若没有缓存，这次请求 104,226 个输入 token 全按原价要 $0.52，缓存帮省了 86%。
八、费用优化实战原则
费用从高到低的 token 类型：
补全 (5x) >>> 缓存写 (1.25x) > 提示 (1x) >> 缓存读 (0.1x)
所以省钱思路顺序：
1. 让模型回答精简 → 砍补全（最大头）
2. 保持历史稳定不修改 → 最大化缓存命中
3. 5 分钟内保持活跃 → 避免缓存过期重建
4. 不切换模型/账号 → 缓存不跨模型、跨账号
什么会失去缓存优势
- ❌ 超过 5 分钟没请求 → 缓存过期，要重建
- ❌ 修改了历史对话 / 系统提示 → 从修改点开始全作废
- ❌ 切换模型 / 账号 / 中转站 → 缓存不通用
- ❌ 前缀太短（<1024 token）→ 达不到最小缓存块，无法缓存
九、一句话总结
上下文限制的是 token 数（语言单位），不是文件字节；每轮对话整包重发（模型无状态），但重复历史靠 Prompt Caching 打 1 折，所以”聊得久反而便宜”；真正决定单次成本的始终是”这一轮模型写了多少字”。
相关笔记
- Transformer —— 注意力机制是上下文窗口的底层基础
- 注意力机制 —— KV cache 正是缓存机制能实现的技术前提
- 大模型如何”理解”文本 —— 上下文窗口边界为什么会限制”主题分析”质量(Lost in the Middle)
- LLM-API 选型方法论 —— Token 计费在 API 选型 5 维度框架中的位置
- LLM 接口规范实战 —— Chat Completion 响应里的
usage字段、reasoning_tokens等计费细节
探索日期：2026-04-18 · 整理自与 Claude 的多轮问答