# 10.1 Token 计费原理与成本模型

在 AI 时代，Token 就是新的电力。 理解 Token 的计费逻辑，是每一位 AI 工程师的基本功。这直接决定了商业模式是否成立。

## 10.1.1 什么是 Token？

Token 并不等同于单词（Word）或字符（Character），它是模型处理文本的基本单元。

* **英文**：通常 1 token 约等于 0.75 个英文单词。
* **中文**：中文 Token 消耗往往高于直觉估计，应以官方 tokenizer 或 SDK 统计结果为准。

**实战建议**： 在做容量规划前，先用官方 tokenizer、SDK 统计接口或真实日志，测出你的业务样本平均 token 分布，不要凭经验拍脑袋。

## 10.1.2 计费公式

Anthropic 的常见计费可先按最基本的公式理解：

$$\text{Total Cost} = (\text{Input Tokens} \times P\_{in}) + (\text{Output Tokens} \times P\_{out})$$

其中：

* `Input Tokens` 是模型读取的内容；
* `Output Tokens` 是模型生成的内容；
* `P_in`、`P_out` 由模型家族、版本和 API 类型决定。

很多模型的输出单价会高于输入单价，因此：

* **读**大量上下文未必最贵；
* **写**长答案、长思考链、长代码往往更贵。

## 10.1.3 如何看待模型成本差异

具体价格会调整，书里不应把某一日期的报价表当成长期事实。更稳定的理解方式是按**模型家族分层**：

| 模型家族         | 常见定位    | 成本特征     | 适合任务           |
| ------------ | ------- | -------- | -------------- |
| **Haiku 类**  | 极速、轻量   | 单次成本最低   | 分类、提取、改写、简单问答  |
| **Sonnet 类** | 均衡主力    | 成本与质量较均衡 | 编程、分析、通用生产任务   |
| **Opus 类**   | 高质量、强推理 | 单次成本最高   | 复杂规划、难例处理、深度推理 |

如果你需要精确报价，应在实施当天查看官方 pricing 页面，而不是依赖书中的静态数字。

## 10.1.4 隐藏成本

在计算 ROI 时，除了基础 API 费用，还要考虑三类常被低估的成本：

1. **思考/推理开销**：开启 thinking 后，额外推理 Token 通常按输出侧成本理解。
2. **错误重试**：Agent 在工具调用、解析、权限或环境上失败后，往往会触发额外轮次。
3. **Context 膨胀**：多轮对话中历史记录持续增长，会推高每轮输入成本，但它通常是**线性累积或阶梯上升**，不应轻率写成“指数级增长”。

## 10.1.5 成本计算案例：客服机器人

假设一个客服机器人平均每天接待 1000 人，每人对话 10 轮。

* 平均每轮 Input（含历史）: 2000 tokens
* 平均每轮 Output: 200 tokens

如果某个模型的输入单价为 `P_in`，输出单价为 `P_out`，那么日成本为：

$$
1000 \times 10 \times (2000 \times P\_{in} + 200 \times P\_{out}) / 1,000,000
$$

这个公式比直接写死某一代模型价格更有用，因为你可以：

* 替换为当天真实价格；
* 直接评估 Haiku / Sonnet / Opus 三档差异；
* 把缓存命中率、重试率、thinking 开销继续叠加进去。

**策略启发**： 如果业务里大多数问题都很简单，应优先让低成本模型处理主流流量，再把复杂请求升级给更强模型。

## 10.1.6 批量处理

如果在做离线数据分析，例如每晚批量处理合同、历史工单或评测数据，实时响应通常不是必要条件。 这类场景更适合使用 **Message Batch API** 或等价的异步批处理能力。

* **计费优势**：官方通常会给批处理明显折扣；常见表述是“最高可达 50% 折扣”，但仍应以当天官方 pricing 页为准。
* **工作机制**：将大量请求打包异步处理，再统一拉取结果。
* **适用场景**：大规模文档抽取、翻译、历史数据清洗、Evals 批量评分。

***

由于 Input Token 往往占据成本大头（尤其是 RAG 场景），Anthropic 推出了一项非常实用的技术：**Prompt Caching**。

➡️ [Prompt Caching 提示缓存](/claude_guide/di-si-bu-fen-shi-zhan-pian/10_optimization/10.2_caching.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/claude_guide/di-si-bu-fen-shi-zhan-pian/10_optimization/10.1_pricing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.