Token经济学：搞懂AI的计费逻辑，把钱花在刀刃上

写给谁看： 如果你用AI工具时总觉得"怎么这么贵"，或者发现明明只问了一个小问题却消耗了大量额度；如果你想搞懂token到底是什么，以及怎么花最少的钱获得最大的效果——这篇文章就是为你写的。

一、Token是什么？

1.1 直观理解：token ≠ 字符 ≠ 单词

先看几个例子，建立直觉：

英文："I love AI"
→ 切分为 ["I", " love", " AI"] → 3个token

中文："我爱人工智能"
→ 切分为 ["我", "爱", "人工", "智能"] → 4个token

代码："const x = 1;"
→ 切分为 ["const", " x", " =", " 1", ";"] → 5个token

Token是LLM处理文本的最小单位。 模型不会直接读取"字符"或"单词"，而是先把文本切分成一个个token，再对token进行计算。

你可以把token理解为：介于"字符"和"单词"之间的一个切分单位。 英文里，一个常见的单词通常是1-2个token，较长的单词可能会被拆成3-4个token。中文里，一个汉字通常是1-2个token，常见的词语组合可能是2-4个token。

1.2 为什么按token收费而不是按次？

你可能会问：为什么不像短信那样按条收费，而是按token数量收费？

原因很简单：按次收费不公平，按token收费才反映真实的算力消耗。

你问一个字的问题，和你贴10万行代码让它分析，消耗的GPU算力天差地别
Token数量直接对应计算量——token越多，模型需要做的矩阵运算越多，消耗的算力越大
按token收费，本质上是按算力收费，这是最合理的计价方式

1.3 输入token vs 输出token：为什么输出更贵？

几乎所有厂商的定价都是输入和输出分开计价，而且输出token的价格通常是输入的2-5倍。

为什么？因为两者的计算方式不同：

输入（理解）：模型可以并行处理所有输入token，一次性完成计算，速度快
输出（生成）：模型必须一个token一个token地生成，每生成一个token都要跑一次完整的前向传播，速度慢、算力消耗大

类比： 读一篇文章很快（输入），但写一篇文章很慢（输出）。生成比理解更"费脑子"，所以更贵。

1.4 主流厂商价格对比

什么是Mtoken？ Mtoken = Million tokens = 百万token。当你看到"$3/M tokens"，意思是"每百万token 3美元"。M就是百万（Million）的缩写，这是行业通用的计价单位。

以下是主流厂商的API定价（以2025年中为基准，实际价格可能有变动）：

厂商	模型	输入价格 ($/M tokens)	输出价格 ($/M tokens)	定位
Anthropic	Claude Opus 4	$15	$75	顶级推理
Anthropic	Claude Sonnet 4	$3	$15	性价比之选
Anthropic	Claude Haiku 3.5	$0.80	$4	轻量快速
OpenAI	GPT-4o	$2.50	$10	多模态旗舰
OpenAI	o3	$10	$40	深度推理
DeepSeek	DeepSeek-V3	$0.27	$1.10	极致性价比
DeepSeek	DeepSeek-R1	$0.55	$2.19	推理能力强
Google	Gemini 2.5 Pro	$1.25	$10	长上下文

几个关键结论：

输出比输入贵很多 — 这是普遍规律，差2-5倍
模型越强越贵 — Opus是Haiku的近20倍
价格差距巨大 — DeepSeek-V3的输入价格只是Claude Opus的1/55
没有绝对的好坏 — 贵的模型不一定适合所有场景，便宜的模型在很多场景下够用

二、Token的消耗真相

2.1 LLM是无状态的——每次都要从头读

这是理解token消耗的关键认知：

LLM没有"记忆"。

所谓的"上下文"，不是存在模型里的，而是每次都完整发送的。每次你发一条消息，模型并不是"接着上次聊"，而是把之前所有的对话内容重新读一遍，然后生成回答。

类比： 就像一个记忆力为零的天才——每次对话，你都要把之前聊过的所有内容重新复述一遍给他听，他才能"想起来"。

2.2 滚雪球效应——上下文越大，token越多

因为无状态的特性，token消耗会像滚雪球一样增长：

第1轮：
  系统提示词(2000) + 用户问题(100) + AI回答(500)
  = 2,600 tokens

第2轮：
  系统提示词(2000) + 第1轮历史(2600) + 用户新问题(100) + AI回答(500)
  = 5,200 tokens

第3轮：
  系统提示词(2000) + 前2轮历史(5200) + 用户新问题(100) + AI回答(500)
  = 7,800 tokens

...

第10轮：
  系统提示词(2000) + 前9轮历史(23400) + 用户新问题(100) + AI回答(500)
  = 26,000 tokens

看到了吗？第10轮的单次消耗是第1轮的10倍。 而且别忘了，每一轮你都在为前面所有的对话内容重复付费。

更直观的对比：

轮次	单轮消耗	累计消耗
第1轮	2,600	2,600
第5轮	13,000	39,000
第10轮	26,000	143,000
第20轮	52,000	546,000

这就是为什么长对话会越来越贵。

2.3 中英文token换算

不同语言的token效率不同：

语言	大致换算	说明
英文	1个单词 ≈ 1.3个token	100个英文单词 ≈ 130个token
中文	1个汉字 ≈ 1.5-2.5个token	100个汉字 ≈ 150-250个token

大多数情况下，中文比英文更"费token"。 因为大多数LLM的训练数据以英文为主，英文的词汇表（tokenizer）更优化，而中文的编码效率相对较低。

但不是绝对的。 以下情况中文反而更省token：

高度重复的中文文本 — 比如"好好好好好"可能被优化为很少的token，而英文重复"good good good"则不会
与训练数据高度匹配的中文内容 — 如果某段中文恰好在训练集中高频出现，tokenizer对它的编码效率会更高
专业术语 — 一些中文专业术语（如"人工智能"）已经是固定词组，可能比对应的英文短语"artificial intelligence"消耗更少的token

所以准确的说法是：在绝大多数场景下，同等语义的中文比英文更费token，但具体差异取决于文本内容和tokenizer的实现。

2.4 直观感受：百万token等于多少内容？

1M tokens（百万token）到底是什么概念？

内容	大约token数
一条微博（140字中文）	~300 tokens
一篇公众号文章（2000字）	~4,000 tokens
一份技术文档（1万字）	~20,000 tokens
一本《小王子》（约4万字）	~80,000 tokens
一本《红楼梦》（约73万字）	~1,500,000 tokens
1M tokens	≈ 50万字中文 ≈ 75万词英文

换个角度： 用Claude Sonnet处理1M tokens的输入，需要花费$3。听起来不多，但如果你的上下文管理不好，每次对话都在重复发送大量内容，这个消耗会快速累积。

三、Prompt Caching：最大的省钱利器

3.1 什么是Prompt Caching？

一句话定义：Prompt Caching（提示词缓存）是一种机制，让你不用为重复的输入内容反复付费。

回到前面的"滚雪球"问题：每次对话都要发送完整的上下文，意味着系统提示词、项目文件、历史对话这些不变的内容被一次又一次地重复计算。

Prompt Caching的解决方案是：把这些不变的内容缓存起来，下次遇到相同的前缀内容时，直接复用缓存结果，不用重新计算。

3.2 工作原理：前缀匹配

缓存是按"前缀"匹配的：

请求1: [系统提示词 + CLAUDE.md + 项目文件] + 问题A
        └────── 这部分被缓存 ──────┘

请求2: [系统提示词 + CLAUDE.md + 项目文件] + 问题B
        └────── 命中缓存！不用重新计算 ──────┘

前提条件：前缀内容必须完全一致。 如果系统提示词变了，或者CLAUDE.md改了一个字，缓存就失效了。

3.3 计费规则

操作	计费倍数	说明
缓存写入（首次）	1.25x	首次请求，内容写入缓存，比正常贵25%
缓存命中（后续）	0.1x	命中缓存，只收正常价格的10%
未命中缓存	1x	正常计费

关键结论：缓存命中后，成本直降90%。 这是目前最大的省钱手段。

3.4 真实场景对比

假设你有10个文件需要审查，每个文件的用户问题约100 tokens，AI回答约500 tokens，系统提示词+CLAUDE.md共5000 tokens：

❌ 场景A：每轮都开新对话（无缓存）

第1轮: 5000 + 100 + 500 = 5,600 tokens（正常计费）
第2轮: 5000 + 100 + 500 = 5,600 tokens（正常计费）
...
第10轮: 5000 + 100 + 500 = 5,600 tokens（正常计费）

总计: 56,000 tokens（全部按1x计费）
实际计费: 56,000 tokens

✅ 场景B：在同一轮对话中处理（有缓存）

第1轮: 5000 + 100 + 500 = 5,600 tokens（缓存写入，1.25x）
第2轮: 5000(命中缓存) + 100 + 500 = 5,600 tokens（缓存部分0.1x）
...
第10轮: 5000(命中缓存) + 100 + 500 = 5,600 tokens（缓存部分0.1x）

实际计费: 5000×1.25 + (5000×0.1 + 600)×9 = 6,250 + 9,900 = 16,150 tokens

节省: 56,000 - 16,150 = 39,850 tokens，节省约71%。

这就是为什么善用缓存能大幅降低成本。

3.5 如何最大化利用缓存

保持前缀内容稳定 — 系统提示词、CLAUDE.md尽量不变，这样缓存命中率最高
在同一会话中处理多个相关任务 — 而不是每个任务开一个新会话
把不常变的内容放在前面 — 缓存是从前往后匹配的，前面的内容越稳定越好
避免频繁修改CLAUDE.md — 每次修改都会导致缓存失效

3.6 缓存过期：不是永久有效的

针对Claude Code来说，缓存是有时间限制的，不是写入后就永久存在。

缓存类型	过期时间	说明
标准缓存	5分钟（固定，不可自定义）	默认开启，缓存写入后5分钟内没有被再次访问就会过期
扩展缓存	1小时（固定，不可自定义）	需要手动启用，缓存有效期延长到1小时

注意： 目前Anthropic不支持自定义缓存时长。你不能设置成30分钟、2小时或任意时长，只能在"5分钟"和"1小时"两个固定选项中选择。这是服务端的限制，用户无法修改。

关键规则：缓存每次被命中时，TTL（存活时间）会重置。 也就是说：

时刻0: 缓存写入 → 开始5分钟倒计时
时刻2: 缓存命中 → 倒计时重置，重新开始5分钟
时刻5: 缓存命中 → 倒计时重置，重新开始5分钟
时刻8: 没有访问 → 倒计时继续
时刻13: 没有访问，距离上次命中已过5分钟 → 缓存过期

实际影响：

连续使用时 — 只要你持续在对话，缓存就不会过期，每轮对话都会命中
中途暂停时 — 如果你停下来思考超过5分钟，缓存就过期了，下次请求需要重新写入
扩展缓存的优势 — 对于需要长时间思考的复杂任务，1小时的缓存有效期可以避免反复写入

如何启用扩展缓存：

启用扩展缓存需要满足两个条件：

条件1：账户权限（后台配置）
  → 你的Anthropic账户计划需要支持扩展缓存功能
  → 在Anthropic控制台中确认是否已开通

条件2：请求开关（CLI配置）
  → 每次请求时需要显式告诉服务端"我要用扩展缓存"
  → 通过 --betas 参数传入

两个条件缺一不可。 有权限但不加参数，不会生效；加了参数但没权限，也不会生效。

Claude Code CLI启用方式：

# 方式一：启动时临时指定
claude --betas extended-cache-ttl

# 方式二：在settings中持久化配置（推荐）
# 编辑 ~/.claude/settings.json，添加：
{
  "betas": ["extended-cache-ttl"]
}

API直接调用方式：

在请求头中设置：anthropic-beta: extended-cache-ttl

提示： --betas 参数还可以传入多个beta特性，用空格分隔即可。

注意： 缓存过期时间等细节可能会随Anthropic的政策调整而变化，建议以官方文档为准。

3.7 国内大模型厂商的缓存机制对比

上面介绍的都是Anthropic（Claude）的缓存机制。如果你使用的是国内厂商的模型，缓存的工作方式有所不同。

核心差异：国内厂商大多采用"服务端自动缓存"，用户无需手动配置。

维度	Anthropic（Claude）	DeepSeek	智谱GLM / 字节豆包等
缓存触发方式	用户主动配置（`--betas`参数）	服务端自动，无需配置	服务端自动，无需配置
用户可控程度	高（可选标准/扩展缓存）	低（服务端自动管理）	低（服务端自动管理）
缓存时长	5分钟 / 1小时（可选）	服务端控制，不可配	服务端控制，不可配
命中折扣	0.1x（省90%）	约0.1x（省90%）	各家不同
配置复杂度	需要了解参数	零配置	零配置

各厂商具体说明：

DeepSeek：

采用"上下文缓存"（Context Caching）机制
完全自动：只要请求的前缀内容与之前某次请求匹配，自动命中缓存
用户不需要做任何配置，API调用方式不变
命中缓存后价格大约是正常价格的1/10
缓存TTL由服务端控制，用户无法调整

智谱GLM：

服务端自动做缓存优化，对用户透明
不像Anthropic那样有明确的"标准缓存/扩展缓存"两档选择
缓存带来的成本降低体现在最终计费中

字节豆包：

类似智谱，服务端自动处理
用户侧无需额外配置

对用户的实际影响：

使用Anthropic（Claude）：
  → 你需要了解缓存机制，合理配置才能最大化省钱
  → 控制权在你手里，但需要学习成本

使用国内厂商（DeepSeek/GLM/豆包）：
  → 缓存自动生效，你不需要关心
  → 零学习成本，但也少了主动优化的空间

建议：

如果你主要使用Claude Code，接入的是Anthropic的模型，则重点掌握Anthropic的缓存配置
如果你混合使用国内的多个厂商，了解各家的缓存差异可以帮助你做出更经济的选择
不管用哪家，保持前缀内容稳定都是提升缓存命中率的通用最佳实践

四、省钱实战

4.1 模型分级使用策略：不要用大炮打苍蝇

核心原则：简单任务用轻量模型，复杂任务用强模型。

Anthropic（Claude）模型分级

级别	模型	输入价格 ($/M tokens)	输出价格 ($/M tokens)	适合任务
轻量级	Claude Haiku 3.5	$0.80	$4	格式转换、文案润色、简单问答、翻译
中档	Claude Sonnet 4	$3	$15	代码编写、技术分析、方案设计、日常开发
顶级	Claude Opus 4	$15	$75	复杂推理、架构设计、难题攻关、关键决策

Anthropic分级决策思路：

这个任务需要"深度思考"吗？
├── 不需要（格式化、翻译、简单问答）→ Haiku，快且便宜
├── 一定程度需要（写代码、做方案）→ Sonnet，性价比最优
└── 非常需要（复杂推理、架构设计）→ Opus，顶级能力

大炮打苍蝇的代价： 用Opus回答"1+1等于几"，成本是Haiku的近20倍，结果完全一样。

智谱GLM模型分级（对照Anthropic）

级别	模型	对标Claude	适合任务
轻量级	GLM-4-Flash	≈ Haiku	简单问答、格式转换、日常对话
中档	GLM-4	≈ Sonnet	代码编写、技术分析、文档处理
顶级	GLM-4-Plus	≈ Opus	复杂推理、专业分析、高质量写作

智谱GLM的特点：

中文能力更强，处理中文文档和对话时效果更好
价格比Claude便宜很多（大约1/10到1/20）
适合对成本敏感、主要处理中文内容的场景

一个实际的选型建议：

你的任务是什么语言为主？
├── 英文为主 → 优先选Claude系列，英文能力更强
├── 中文为主 → 优先选智谱GLM或DeepSeek，中文能力好且便宜
└── 中英混合 → 按任务复杂度选，简单任务用国内模型，复杂任务用Claude

任务复杂度如何？
├── 简单（翻译、格式化）→ 国内模型够用，省90%的钱
├── 中等（写代码、做方案）→ Claude Sonnet 或 GLM-4
└── 复杂（架构设计、难题攻关）→ Claude Opus 或 GLM-4-Plus

在Claude Code中如何配置和切换模型

知道了要分级使用，但具体怎么操作？下面是在Claude Code中配置模型的完整指南。

方式一：启动时指定模型

# 使用Claude Sonnet（默认）
claude --model sonnet

# 使用Claude Opus
claude --model opus

# 使用Claude Haiku
claude --model haiku

# 使用具体的模型版本号
claude --model claude-opus-4-8
claude --model claude-sonnet-4-6

方式二：会话中动态切换（推荐）

在Claude Code交互界面中，使用 /model 命令随时切换：

> /model sonnet        # 切换到Sonnet，适合日常开发
> /model opus          # 切换到Opus，适合复杂推理
> /model haiku         # 切换到Haiku，适合简单任务

方式三：在settings中设置默认模型

编辑 ~/.claude/settings.json：

{
  "model": "sonnet"
}

这样每次启动Claude Code都会默认使用Sonnet。

一个实际的工作流示例：

1. 启动Claude Code，默认用Sonnet
   → claude

2. 先用Sonnet做日常开发任务
   > 帮我给这个函数添加错误处理

3. 遇到复杂的架构决策，切换到Opus
   > /model opus
   > 分析一下这个模块的架构，给出重构建议

4. 架构决策完成，切回Sonnet继续开发
   > /model sonnet
   > 按照建议重构这个模块

5. 需要批量格式化文件，切换到Haiku省钱
   > /model haiku
   > 帮我把这10个文件的注释格式统一

接入第三方模型（DeepSeek、智谱GLM、小米等）

如果你想在Claude Code中使用国内模型来节省成本，需要理解一个关键机制：Claude Code内部只认三个模型槽位（sonnet、opus、haiku），通过环境变量将它们映射到你实际使用的第三方模型。

模型映射机制：

Claude Code的三个槽位          你的环境变量映射              实际调用的模型
─────────────────          ─────────────────          ──────────────
sonnet                  →   ANTHROPIC_DEFAULT_SONNET_MODEL   →   你指定的模型
opus                    →   ANTHROPIC_DEFAULT_OPUS_MODEL     →   你指定的模型
haiku                   →   ANTHROPIC_DEFAULT_HAIKU_MODEL    →   你指定的模型

这意味着：

切换模型时，你输入的始终是 /model sonnet、/model opus、/model haiku
不需要输入第三方模型的名称
具体调用哪个模型，由环境变量决定

以小米模型为例：

假设你使用小米的mimo系列模型，配置如下：

{
  "ANTHROPIC_BASE_URL": "https://your-api-url/v1",
  "ANTHROPIC_API_KEY": "your-api-key",
  "ANTHROPIC_MODEL": "mimo-v2.5-pro",
  "ANTHROPIC_DEFAULT_HAIKU_MODEL": "mimo-v2-flash",
  "ANTHROPIC_DEFAULT_SONNET_MODEL": "mimo-v2.5-pro",
  "ANTHROPIC_DEFAULT_OPUS_MODEL": "mimo-v2.5-pro",
  "CLAUDE_CODE_SUBAGENT_MODEL": "mimo-v2-flash"
}

配置后的效果：

/model haiku   → 实际调用 mimo-v2-flash（轻量，适合简单任务）
/model sonnet  → 实际调用 mimo-v2.5-pro（中档，日常开发）
/model opus    → 实际调用 mimo-v2.5-pro（同上，目前小米没有更强的模型）

⚠️ 注意映射的合理性：

上面的例子中，sonnet和opus都映射到了同一个模型（mimo-v2.5-pro），这意味着模型分级没有真正生效——不管你怎么切换，sonnet和opus调用的都是同一个模型。

正确的分级思路：

haiku  → 映射到最便宜/最快的模型（如 mimo-v2-flash）
sonnet → 映射到主力模型（如 mimo-v2.5-pro）
opus   → 映射到最强模型（如果厂商有更强的型号）

如果厂商目前只有一个主力模型，那确实没法做分级。但随着各家模型矩阵的丰富，你可以通过调整映射来实现真正的分级使用。

其他厂商的映射示例：

// DeepSeek
{
  "ANTHROPIC_DEFAULT_HAIKU_MODEL": "deepseek-chat",
  "ANTHROPIC_DEFAULT_SONNET_MODEL": "deepseek-chat",
  "ANTHROPIC_DEFAULT_OPUS_MODEL": "deepseek-reasoner"
}

// 智谱GLM
{
  "ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-4-flash",
  "ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-4",
  "ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-4-plus"
}

完整配置步骤：

# 第一步：设置API端点和密钥
export ANTHROPIC_BASE_URL=https://your-provider-url/v1
export ANTHROPIC_API_KEY=your-api-key

# 第二步：设置模型映射
export ANTHROPIC_DEFAULT_HAIKU_MODEL=your-light-model
export ANTHROPIC_DEFAULT_SONNET_MODEL=your-main-model
export ANTHROPIC_DEFAULT_OPUS_MODEL=your-strong-model

# 第三步：启动Claude Code
claude

# 第四步：正常使用，用 /model 切换
> /model haiku      # 切换到轻量模型
> /model sonnet     # 切换到主力模型
> /model opus       # 切换到最强模型

注意： 第三方模型的接入方式可能因厂商不同而有所差异，具体请参考各厂商的API文档。部分功能（如工具调用、扩展缓存）在第三方模型上可能不完全支持。

知行合一的模型选择清单：

你要做的事	推荐模型	Claude Code操作
简单问答、格式转换	Haiku	`/model haiku`
写代码、改bug、做方案	Sonnet（默认）	直接用，不用切换
复杂架构设计、难题攻关	Opus	`/model opus`
批量简单任务（格式化、重命名）	Haiku	`/model haiku`
代码审查、安全分析	Opus	`/model opus`
日常开发的大部分工作	Sonnet	保持默认即可

4.2 Claude Code操作习惯

在使用Claude Code时，养成以下习惯可以大幅节省token：

`/clear` — 开始新任务时必用

作用：清除当前上下文，从零开始
什么时候用：完成一个任务，准备开始下一个不相关的任务时
为什么省token：避免携带上一个任务的无用上下文

错误示范： 一直在同一个会话里做不同的任务，上下文越来越长，token消耗越来越大。

正确示范： 每完成一个独立任务，用 /clear 清除上下文，再开始下一个任务。

`/compact` — 上下文快满时用

作用：将当前对话历史压缩为摘要，释放上下文空间
什么时候用：感觉到对话变慢，或者系统提示上下文即将溢出时
为什么省token：把冗长的历史对话压缩成精简的摘要

工作原理： /compact 会把之前的对话历史总结成一个精简版本，保留关键信息，丢弃冗余细节。之后的对话只发送压缩后的内容，token消耗大幅降低。

`/model` — 按需切换模型

作用：在当前会话中切换使用的模型
什么时候用：简单任务切换到轻量模型，复杂任务切换到强模型

灵活切换的示例：

用 Sonnet 读取和分析代码（中等任务）
切换到 Opus 做复杂的架构决策（重任务）
切换回 Haiku 做简单的格式化（轻任务）

4.3 CLAUDE.md精简策略

什么是CLAUDE.md？

CLAUDE.md是Claude Code的"宪法"——每次对话启动时，它都会被自动加载，作为Agent的行为准则和知识基础。

你可以把它理解为：你和Claude Code之间的"约定书"。 你在这里写下的内容，Claude Code会视为最高优先级的指令，在每次对话中遵守。

它不限于编程场景，可以包含：

你的工作习惯和偏好（"回复用中文""代码注释用英文"）
项目的规范和约束（"这个项目用React，不用Vue"）
常用的工作流程（"每次提交前先跑测试"）
需要Agent记住的关键信息（"这个项目的数据库是PostgreSQL"）

关于CLAUDE.md的详细用法，包括它的三级区域模式（用户级、项目级、目录级），我们会在后续的文章中专门介绍。 这里只关注和token节省相关的精简策略。

为什么要精简？

CLAUDE.md是Claude Code每次对话都会加载的配置文件，它的内容每轮对话都会消耗token。

常见错误： 把整个项目文档都塞进CLAUDE.md，动辄上万字，每次对话白白消耗几万token。

正确做法：

CLAUDE.md应该只包含：
✅ 项目核心技术栈和版本
✅ 代码规范和命名约定
✅ 关键目录结构说明
✅ 重要约束和注意事项

CLAUDE.md不应该包含：
❌ 完整的API文档（放在项目里按需读取）
❌ 详细的功能说明（放在docs目录里）
❌ 历史变更记录（放在CHANGELOG里）
❌ 长篇的架构说明（放在专门的文档文件里）

原则：CLAUDE.md是"每次必读的精简手册"，不是"项目百科全书"。 详细内容放在项目文件中，需要时让Agent自己去读取。

一个参考标准： CLAUDE.md控制在500-1500字以内为宜。超过2000字就需要考虑精简了。

4.4 Batch API：批量任务的省钱方案

如果你有大量独立的、不紧急的任务，可以使用Batch API。

什么是Batch API？

把多个请求打包成一个批次提交
厂商在系统空闲时处理这些请求
通常享受50%的折扣

适合场景：

批量翻译文档
批量生成内容
批量代码审查
数据分析和处理

不适合场景：

需要实时交互的任务
需要即时反馈的开发任务

各厂商的Batch API折扣：

厂商	Batch API折扣
Anthropic	50%折扣
OpenAI	50%折扣
DeepSeek	25%折扣

4.5 第三方模型接入建议

如果你使用Claude Code并想接入其他模型来节省成本，以下是一些推荐配置：

模型	特点	适合场景	价格优势
智谱 GLM-5.1	中文能力强，性价比高	中文文档处理、简单编码	比Claude便宜10-20倍
DeepSeek V4	代码能力强，价格极低	代码编写、技术问答	比Claude便宜50倍+
通义千问 Qwen	多语言支持好	通用任务	比Claude便宜10-15倍

接入方式

Claude Code支持通过API兼容层接入第三方模型。具体配置方式可参考官方文档，后续的文章也会具体介绍。

建议策略：

日常简单任务用国内第三方便宜模型
复杂任务切换回Claude原生模型
这样既能省钱，又能保证关键任务的质量

4.6 真实案例：一个中等任务的token消耗分析

任务： 为一个中等规模的Node.js项目（约50个文件）添加TypeScript类型定义

过程：

让Claude Code读取项目结构 → 消耗约8,000 tokens
逐个文件添加类型定义（10个核心文件）→ 每个文件约3,000-5,000 tokens
修复类型错误 → 消耗约5,000 tokens
运行TypeScript编译验证 → 消耗约3,000 tokens

总计： 约60,000 tokens

费用（以Claude Sonnet为例）：

输入: ~40,000 tokens × $3/M = $0.12
输出: ~20,000 tokens × $15/M = $0.30
总计: $0.42

如果用Opus： 输入 $0.60 + 输出 $1.50 = $2.10，贵了5倍

如果用DeepSeek V3： 输入 $0.011 + 输出 $0.022 = $0.033，便宜了12倍

结论：选择合适的模型，同样的任务成本可以相差几十倍。

结尾：Token是AI时代的"货币"

理解token，就像理解汽车的油耗——你不一定要成为工程师，但你需要知道：

什么操作费油 — 长对话、大上下文、强模型
怎么省油 — 缓存、分级模型、精简上下文、Batch API
什么时候该踩油门 — 关键任务用强模型，不要省这个钱

最后的建议：

不要为了省钱而省钱，该用强模型的时候就用
但也不要无意识地浪费，养成良好的token使用习惯
最贵的不是token，而是你的时间 — 如果用便宜模型导致返工，反而更贵
也不是越贵的模型效果越好，有的简单任务使用轻量级的模型可能会获得更好的效果、更好的执行效率以及能极大的节省token消耗

posted @ 2026-06-07 21:40 flycloudy 阅读(29) 评论(0) 收藏举报

刷新页面返回顶部

Continued

Token经济学：搞懂AI的计费逻辑，把钱花在刀刃上

一、Token是什么？

1.1 直观理解：token ≠ 字符 ≠ 单词

1.2 为什么按token收费而不是按次？

1.3 输入token vs 输出token：为什么输出更贵？

1.4 主流厂商价格对比

二、Token的消耗真相

2.1 LLM是无状态的——每次都要从头读

2.2 滚雪球效应——上下文越大，token越多

2.3 中英文token换算

2.4 直观感受：百万token等于多少内容？

三、Prompt Caching：最大的省钱利器

3.1 什么是Prompt Caching？

3.2 工作原理：前缀匹配

3.3 计费规则

3.4 真实场景对比

3.5 如何最大化利用缓存

3.6 缓存过期：不是永久有效的

3.7 国内大模型厂商的缓存机制对比

四、省钱实战

4.1 模型分级使用策略：不要用大炮打苍蝇

Anthropic（Claude）模型分级

智谱GLM模型分级（对照Anthropic）

在Claude Code中如何配置和切换模型

4.2 Claude Code操作习惯

`/clear` — 开始新任务时必用

`/compact` — 上下文快满时用

`/model` — 按需切换模型

4.3 CLAUDE.md精简策略

什么是CLAUDE.md？

为什么要精简？

4.4 Batch API：批量任务的省钱方案

4.5 第三方模型接入建议

推荐的第三方模型

接入方式

4.6 真实案例：一个中等任务的token消耗分析

结尾：Token是AI时代的"货币"

公告

Continued

Token经济学：搞懂AI的计费逻辑，把钱花在刀刃上

一、Token是什么？

1.1 直观理解：token ≠ 字符 ≠ 单词

1.2 为什么按token收费而不是按次？

1.3 输入token vs 输出token：为什么输出更贵？

1.4 主流厂商价格对比

二、Token的消耗真相

2.1 LLM是无状态的——每次都要从头读

2.2 滚雪球效应——上下文越大，token越多

2.3 中英文token换算

2.4 直观感受：百万token等于多少内容？

三、Prompt Caching：最大的省钱利器

3.1 什么是Prompt Caching？

3.2 工作原理：前缀匹配

3.3 计费规则

3.4 真实场景对比

3.5 如何最大化利用缓存

3.6 缓存过期：不是永久有效的

3.7 国内大模型厂商的缓存机制对比

四、省钱实战

4.1 模型分级使用策略：不要用大炮打苍蝇

Anthropic（Claude）模型分级

智谱GLM模型分级（对照Anthropic）

在Claude Code中如何配置和切换模型

4.2 Claude Code操作习惯

/clear — 开始新任务时必用

/compact — 上下文快满时用

/model — 按需切换模型

4.3 CLAUDE.md精简策略

什么是CLAUDE.md？

为什么要精简？

4.4 Batch API：批量任务的省钱方案

4.5 第三方模型接入建议

推荐的第三方模型

接入方式

4.6 真实案例：一个中等任务的token消耗分析

结尾：Token是AI时代的"货币"

公告

`/clear` — 开始新任务时必用

`/compact` — 上下文快满时用

`/model` — 按需切换模型