大模型时代必修课：懂 Token 的人，用 1 块钱跑出别人 100 块钱的效果。

大模型时代必修课：懂 Token 的人，用 1 块钱跑出别人 100 块钱的效果。

大模型时代的"成本意识"和"选型能力"

开篇：为什么你必须懂 Token？

你有没有遇到过这样的场景：同一个问题，在某个模型上调用一次只花了 5 分钱，换了另一个模型却花了 5 块钱？差距整整 100 倍。

这不是玄学，而是 Token 在起作用。

Token 是大语言模型处理文本的最小单位，也是 API 计费的基本依据。你发出去的每一个字、模型回复的每一句话，都会被换算成 Token，然后乘以单价，变成你账单上的真金白银。

不懂 Token，你可能会：

• 把一个 2000 字的系统提示词每次都完整发送，月账单翻 10 倍
• 用旗舰模型做分类、摘要这种轻量任务，多花 20 倍的钱
• 不知道缓存机制的存在，反复为同一段内容付费
• 选模型时只看"谁更聪明"，不看"谁更划算"

2026 年的大模型市场，价格差异已经达到 200 倍以上 。最贵的模型输入 $10/百万Token，最便宜的只要10/百万\; Token，最便宜的只要$ 10/百万Token，最便宜的只要0.30/百万 Token。选对模型、用对技巧，同样的效果可以省下 70%-90% 的成本。

本文将带你彻底搞懂五件事：

1. Token 到底是什么------从原理到换算，一次讲透
2. 怎么省 Token------8 个实战技巧，附真实成本对比
3. 主流模型怎么选------国内国际 30+ 模型横向对比
4. 选型决策框架------按场景、预算精准匹配
5. 进阶使用技巧------Prompt 工程、参数调优、避坑指南

读完这篇，你将具备大模型时代的"成本意识"和"选型能力"。

---

第一部分：彻底理解 Token 🔑

1.1 Token 是什么：模型的"乐高积木"

如果把语言比作乐高模型，那么 Token 就是乐高积木块。

一句话不是被模型当作一个整体来理解的，而是被拆成一个个 Token，逐个输入、逐个预测。模型看到的不是"你好世界"，而是 [你好] [世界] 这样的 Token 序列。

OpenAI 官方给出的定义非常精准：

"Tokens can be thought of as pieces of words."（Token 可以被看作是单词的片段。）

注意，是"单词的片段"，不是"单词"本身。一个 Token 可能是：

• 一个完整的单词：hello
• 单词的一部分：un + happiness = unhappiness
• 一个标点符号：，、。
• 一个或几个汉字：你好 可能是 1 个 Token，也可能是 2 个
• 一个特殊符号：代码中的 {、}、=>

为什么不直接用单词？因为单词的数量是无限的------每年都有新词产生，专业术语、人名、品牌名层出不穷。如果词表只包含固定单词，遇到生词就会"失语"。而 Token 采用"子词（subword）"策略，既能覆盖常见词汇，又能通过组合处理任意文本。

1.2 Token 与字符/单词的换算关系

这是最实用的部分。不同语言的 Token 密度差异很大。

英文换算（OpenAI 官方数据）：

换算关系	数值
1 Token ≈ 多少字符	约 4 个字符
1 Token ≈ 多少单词	约 0.75 个单词
1 个单词 ≈ 多少 Token	约 1.3 个 Token
1000 个单词 ≈ 多少 Token	约 1300 个 Token

中文换算：

换算关系	数值
1 个汉字 ≈ 多少 Token	约 1-2 个 Token（常见词 1 个，生僻字 2 个）
1000 个汉字 ≈ 多少 Token	约 1200-1800 个 Token
经验估算	中文字数 × 1.5 ≈ Token 数

中文的情况比较特殊。早期的 GPT-3.5/GPT-4 使用 cl100k_base 编码器，对中文支持不佳，一个汉字经常被拆成 2-3 个 Token。而 GPT-5 系列升级到 o200k_base 编码器（约 20 万词表），对非英语语言的处理大幅优化，中文 Token 效率显著提升。国内模型（DeepSeek、Qwen、GLM 等）的 tokenizer 更是针对中文做了专门优化，常见中文词汇通常 1 个 Token 就能表示。

代码换算：

代码的 Token 密度与自然语言不同。特殊符号（{}、()、=>、->）、缩进、关键字都会被单独计为 Token。一般来说，同样字符数的代码比英文文本消耗更多 Token，大约是英文的 1.2-1.5 倍。

实际示例：

文本内容	字符数	估算 Token 数
"Hello, world!"	13	~4
"你好，世界！"	7 个汉字+标点	~5-8
一段 500 字的中文段落	500	~750
一段 500 词的英文段落	~2500 字符	~650
一个 100 行的 Java 类	~3000 字符	~900-1200

1.3 Tokenizer 工作原理：BPE 算法

所有大模型都有一个"分词器（Tokenizer）"，负责把文本转换成 Token 序列。目前主流方案是 BPE（Byte Pair Encoding，字节对编码）。

BPE 最初是一种数据压缩算法，1994 年由 Philip Gage 提出，后来被 OpenAI 在 GPT-2 中引入并推广为 LLM 分词的标准方案。

BPE 的工作流程分两个阶段：

阶段一：训练（构建词表，只做一次）

1. 从最基础的单位开始------所有单个字节（UTF-8 编码后的 256 个可能值）
2. 扫描整个训练语料，统计相邻字符对出现的频率
3. 把出现频率最高的字符对合并成一个新 Token
4. 重复步骤 2-3，直到词表达到预设大小（如 GPT-2 是 50,257，GPT-5 是约 200,000）

举个极简的例子。假设语料中有很多 "aaabdaaabac"：

• 初始：a a a b d a a a b a c（11 个字符）
• 最高频对是 aa，合并后：aa a b d aa a b a c（9 个 Token）
• 下一个高频对是 aa + b = aab，合并后：aab d aab a c（5 个 Token）

只用了 2 次合并，就把 11 个字符压缩到了 5 个 Token。这就是 BPE 的魔力------高频出现的组合会被"粘"在一起，成为一个更高效的单位。

阶段二：编码（每次请求时执行）

推理时词表已经固定。对新文本进行编码时：

1. 先用正则表达式做"预分词"------按空格和标点切分，确保合并不会跨越单词边界（这就是为什么英文 Token 前面经常带一个空格）
2. 在每个词块内部，按训练时学到的合并规则顺序，贪心应用合并
3. 直到没有更多规则可应用，得到最终的 Token ID 序列

不同模型的 Tokenizer 差异：

模型系列	Tokenizer	词表大小	特点
GPT-3.5/4	tiktoken (cl100k_base)	~100K	中文效率较低
GPT-5/6	tiktoken (o200k_base)	~200K	多语言优化，中文效率提升
Claude	自研 Tokenizer	~200K	对长文本优化
Llama	SentencePiece	~128K	开源，多语言
Qwen/DeepSeek/GLM	自研 BPE	~150K+	中文优化，常见词 1 Token

这就解释了一个常见现象：同一段 prompt，在不同模型里 Token 数可能差 20%-50%。尤其是中文文本，国内模型的 tokenizer 通常比 GPT 系列更高效。

1.4 输入 Token vs 输出 Token vs 缓存 Token

API 计费不是"一口价"，而是分三类 Token 分别计价：

① 输入 Token（Input Tokens）

你发给模型的所有内容，包括：

• 系统提示词（System Prompt）
• 用户消息（User Message）
• 历史对话记录
• 工具/函数的返回结果
• 附加的文档、代码等上下文

输入 Token 是成本的大头。在 RAG（检索增强生成）、长文档分析、多轮对话等场景中，输入 Token 往往占总消耗的 70%-90%。

② 输出 Token（Output Tokens）

模型生成的回复内容。输出 Token 通常比输入贵 2-5 倍，原因是：

• 输出是"自回归生成"，每个 Token 都要等前一个生成完才能开始，计算无法并行
• 输入可以批量并行处理（KV Cache 优化），而输出必须逐个解码
• 输出质量直接影响用户体验，厂商在定价上倾向于"输出溢价"

以 GPT-5.6 Terra 为例：输入 $2.50/百万，输出2.50/百万，输出$ 2.50/百万，输出15/百万，输出是输入的 6 倍。Claude Opus 5：输入 $5/百万，输出5/百万，输出$ 5/百万，输出25/百万，输出是输入的 5 倍。

③ 缓存 Token（Cached Tokens）

这是 2025-2026 年最重要的成本优化机制。当你反复发送相同的内容（比如固定的系统提示词、长文档），厂商会把这部分内容缓存起来，后续请求直接从缓存读取，价格大幅降低。

各厂商缓存折扣对比：

厂商	缓存读取价格	相当于正常输入的	缓存写入价格	缓存有效期
Anthropic Claude	基价 × 0.10	10%（9折优惠）	基价 × 1.25（5分钟）/ × 2.0（1小时）	5分钟（默认）/ 1小时（需指定）
OpenAI GPT-5.6/6	基价 × 0.10	10%	基价 × 1.25	自动管理，至少 30 分钟
OpenAI GPT-4 系列	基价 × 0.50	50%	无额外费用	自动管理
DeepSeek	¥0.02-0.025/百万	约 0.8%-1%	无额外费用	自动管理
Qwen	基价 × 0.125	约 12.5%	无额外费用	自动管理
GLM	基价 × 0.25	25%	无额外费用	自动管理

可以看到，Anthropic 和新一代 OpenAI 模型的缓存折扣最狠------只收正常价格的 10% 。Claude Fable 5.1 更是做到了 $0.25/百万（仅为0.25/百万（仅为$ 0.25/百万（仅为10 基价的 2.5%），在长上下文反复读取的场景中，实际成本可以比 GPT-6 Astra 低 4 倍。

关键认知：比较模型价格时，不能只看输入输出的"标价"，必须把缓存命中率纳入考量。一个系统提示词 2000 Token 的应用，如果缓存命中率 90%，实际输入成本可能只有标价的 20%。

1.5 上下文窗口与 Token 的关系

上下文窗口（Context Window） = 单次请求中，输入 Token + 输出 Token 的最大总和。

它决定了模型一次能"看到"多少内容。如果你的 prompt 加上预期回复超过了窗口限制，API 会直接报错或截断。

主流模型上下文窗口对比：

上下文大小	代表模型	能装下什么
128K	GPT-4o、Gemini 3.1 Pro、Mistral 系列	约 9 万字中文 / 一本中篇小说
200K	Claude Haiku 4.5	约 15 万字中文
256K	Doubao-Seed-2.1、Step-3.7	约 19 万字中文
1M（100万）	GPT-5.6/6、Claude 5 全系列、Kimi K3、DeepSeek-V4、Qwen3.8-Max、MiniMax M3	约 75 万字中文 / 一整套代码库 / 一本长篇小说
1.05M	GPT-5.6/6 系列	约 79 万字
10M	Llama 4 Scout	约 750 万字中文 / 整个 GitHub 仓库 / 一套百科全书

2026 年，1M 上下文已经成为旗舰模型的标配。Llama 4 Scout 更是以 10M 开源最长窗口打破纪录，可以一次性装入整个代码库或多本书籍。

上下文越大越贵吗？ 不一定。但需要注意"长上下文溢价"：

• Gemini 3.1 Pro ：≤200K 输入 $2/百万，>200K输入2/百万，>200K\; 输入$ 2/百万，>200K输入4/百万（翻倍）
• GPT-6 Astra：>272K 输入溢价 2 倍，缓存输入溢价 1.5 倍
• MiniMax M3：≤512K 输入 ¥4.2/百万，512K-1M 输入 ¥8.4/百万（翻倍）

所以，如果你只需要处理 50K 的内容，选一个 1M 窗口的模型并不会多花钱；但如果你真的要用到 500K+ 的超长上下文，就要仔细算一下溢价成本。

1.6 如何计算/估算 Token 数量

方法一：官方在线工具

• OpenAI Tokenizer ：platform.openai.com/tokenizer --- 输入文本，实时显示 Token 拆分和数量
• Anthropic Token Counter ：platform.claude.com/docs/en/bui... --- 支持 Claude 系列模型的 Token 计数

方法二：代码估算（tiktoken）

import tiktoken

# GPT-5/6 系列使用 o200k_base 编码器
enc = tiktoken.encoding_for_model("gpt-5.6-terra")

text = "你好，世界！Hello, world!"
tokens = enc.encode(text)
print(f"Token 数量: {len(tokens)}")
print(f"Token 列表: {tokens}")
# 解码验证
print(f"解码后: {enc.decode(tokens)}")

对于其他模型，可以使用对应的 tokenizer 库：

• Claude：anthropic SDK 内置计数，或使用 transformers 的 AutoTokenizer
• 中文模型：HuggingFace transformers 加载对应模型的 tokenizer

方法三：经验法则（快速估算）

文本类型	估算公式
中文	字符数 × 1.5 ≈ Token 数
英文	单词数 × 1.3 ≈ Token 数
英文	字符数 ÷ 4 ≈ Token 数
代码	字符数 ÷ 3 ≈ Token 数

各平台计费规则说明：

• 几乎所有平台都按 实际 Token 数 × 单价 计费，不足 1 百万 Token 按比例计算
• 输入和输出分别计价，账单中会分开显示
• 缓存命中的 Token 按缓存价计费，未命中的按正常输入价计费
• 部分平台有"最低计费"规则（如 Anthropic 缓存最小 1024 Token 起算）
• API 返回的 usage 字段中会包含 prompt_tokens、completion_tokens、cached_tokens 等详细信息

---

第二部分：节省 Token 的实用技巧 💰

理解了 Token 的原理，接下来是最实战的部分------怎么省钱。以下 8 个技巧，从简单到进阶，覆盖从 Prompt 优化到架构设计的全链路。

2.1 Prompt 精简技巧

去除冗余客套话

很多人写 prompt 喜欢加"请你帮我..."、"我希望你能够..."、"非常感谢你的帮助"这类客套话。模型不吃这一套，这些话只会白白消耗 Token。

❌ 优化前（~50 Token）：
"你好！我是一名Java开发工程师，我想请你帮我写一个单例模式的实现，
要求是线程安全的，使用双重检查锁定方式，非常感谢你的帮助！"

✅ 优化后（~25 Token）：
"用Java实现线程安全单例模式，双重检查锁定。"

Token 直接省一半，效果完全一样。

结构化指令代替大段描述

用 Markdown 列表、表格代替冗长的段落描述，信息密度更高，Token 更省。

❌ 优化前：
"我需要你分析这段代码的性能问题。首先看时间复杂度，然后看空间复杂度，
接着找出可能的内存泄漏点，最后给出优化建议。注意要关注并发安全问题。"

✅ 优化后：
"分析以下代码：
1. 时间复杂度
2. 空间复杂度
3. 内存泄漏风险
4. 并发安全问题
5. 优化建议"

少用 Few-shot 示例

Few-shot（给几个示例让模型学习格式）确实能提升效果，但示例非常耗 Token。从 5 个示例减到 2 个，Token 立省 60%，效果通常只下降 5%-10%。

经验：如果任务格式简单（如分类、提取），1-2 个示例足够；如果任务复杂（如特定格式的报告生成），保留 2-3 个关键示例。

2.2 系统提示词优化

系统提示词（System Prompt）是每次请求都会发送的内容，也是缓存命中率最高的部分 。优化它的原则是：精简 + 固定 + 放最前面。

固定模板复用

把不变的系统提示词放在请求的最前面，且保持内容完全不变（连空格、标点都不要改），这样缓存才能命中。

✅ 推荐结构：
[系统提示词：固定不变，放最前面]  ← 缓存命中
[用户消息：每次变化]               ← 不缓存
[历史对话：逐渐增长]                ← 部分缓存

系统提示词本身也要精简

一个常见的误区是把系统提示词写得像一篇小作文。实际上，模型只需要关键指令。

❌ 2000 Token 的系统提示词：
"你是一个资深的Java架构师，拥有15年的开发经验，曾经在阿里巴巴等大厂工作，
精通Spring Boot、微服务架构、分布式系统...（以下省略1800字）"

✅ 200 Token 的系统提示词：
"你是资深Java架构师。精通Spring Boot/微服务/分布式。
回答要求：代码可运行+注释+最佳实践。用中文。"

缓存成本案例

假设系统提示词 2000 Token，使用 Claude Opus 5（输入 $5/百万，缓存5/百万，缓存$ 5/百万，缓存0.50/百万）：

场景	单次成本	日均 10000 次	月成本
无缓存	$0.01	$100	$3000
缓存命中 90%	$0.00145	$14.5	$435
节省	85.5%		~$2565/月

2.3 输出控制

输出 Token 比输入贵 2-5 倍，控制输出是省钱的关键。

设置 max_tokens

不需要长回答时，把 max_tokens 设小。比如分类任务设 50，摘要任务设 500，问答任务设 1000。

response = client.chat.completions.create(
    model="gpt-5.6-luna",
    messages=messages,
    max_tokens=500,  # 限制输出不超过500 Token
)

在 Prompt 中要求简洁

"用不超过200字回答。"
"直接给出答案，不要解释过程。"
"输出JSON，不要额外文字。"

避免模型重复你的问题

很多模型（尤其是较早的版本）会在回答开头重复"好的，关于你的问题..."。加一句指令即可避免：

"直接回答，不要重复问题，不要说'好的'之类的客套话。"

流式输出不影响计费

stream=True 只是让回复逐字返回，提升用户体验，不会增加或减少 Token 计费。该用就用。

2.4 上下文管理

多轮对话中，历史消息会越积越多，每次请求都要把全部历史发过去，Token 消耗呈线性增长。

及时清理无关历史

不是所有历史对话都需要保留。如果用户问了 10 个不相关的问题，第 11 个问题完全不需要前面的上下文。

滑动窗口策略

只保留最近 N 轮对话，丢弃更早的内容。

def sliding_window(messages, max_turns=10):
    """只保留最近 max_turns 轮对话（系统提示词除外）"""
    system_msg = [m for m in messages if m["role"] == "system"]
    conversation = [m for m in messages if m["role"] != "system"]
    return system_msg + conversation[-max_turns * 2:]  # 每轮2条消息

摘要压缩

当对话变长时，用模型把早期历史压缩成一段摘要，替换原始消息。

原始历史（10轮，~8000 Token）：
[用户1] [助手1] [用户2] [助手2] ... [用户10] [助手10]

压缩后（~1500 Token）：
[系统提示词]
[历史摘要：用户讨论了Java线程池配置，最终决定使用...（约300字）]
[最近3轮对话：用户8] [助手8] [用户9] [助手9] [用户10] [助手10]

Token 从 8000 降到 1500，节省 81%，而关键信息通过摘要保留。

2.5 巧用缓存

缓存是 2026 年最强大的成本优化武器。用好了可以省 90% 的输入成本。

Anthropic Prompt Caching

Anthropic 的缓存机制最成熟，需要在消息中显式标记 cache_control：

from anthropic import Anthropic

client = Anthropic()

response = client.messages.create(
    model="claude-3-5-sonnet-latest",
    max_tokens=1000,
    system=[
        {
            "type": "text",
            "text": "你是一个专业的代码审查助手...",  # 固定系统提示
            "cache_control": {"type": "ephemeral"},  # 标记为可缓存
        }
    ],
    messages=messages,
)

关键参数：

• 缓存读取 ：正常输入价的 10%（如 Opus 5 $5\to 5\; \to$ 5→0.50/百万）
• 缓存写入（5分钟 TTL）：正常输入价的 125%
• 缓存写入（1小时 TTL）：正常输入价的 200%
• 最小缓存块：Haiku/Sonnet 1024 Token，Opus 2048 Token
• 默认 TTL：5 分钟（2026 年 3 月从 1 小时改为 5 分钟，1 小时需显式指定）

什么时候缓存划算？

缓存写入比正常输入贵 25%，但读取只要 10%。盈亏平衡点：

写入成本 = 1.25 × 基价
读取成本 = 0.10 × 基价
无缓存 N 次成本 = N × 基价
有缓存 N 次成本 = 1.25 × 基价 + (N-1) × 0.10 × 基价

盈亏平衡：N × 基价 = 1.25 × 基价 + (N-1) × 0.10 × 基价
→ N ≈ 1.28 次

也就是说，同一段内容只要被读取 2 次以上，缓存就划算。读取 10 次，节省 89%；读取 100 次，节省 89.9%。

OpenAI 自动缓存

OpenAI 的缓存是自动管理的，不需要显式标记。只要请求前缀与之前的请求匹配（系统提示词 + 历史消息一致），就会自动命中缓存。

• GPT-5.6/6 系列：缓存读取 = 基价的 10%，缓存写入 = 基价的 125%
• GPT-4 系列：缓存读取 = 基价的 50%，无写入费用
• 缓存生命周期：自动管理，至少 30 分钟

最大化缓存命中的设计原则：

1. 不变的内容放最前面------系统提示词、固定文档、工具定义放在消息开头
2. 变化的内容放最后------用户最新的问题放在最后
3. 不要频繁修改系统提示词------哪怕改一个字，前缀匹配就会断，缓存全部失效
4. 批量请求时保持前缀一致------同一批任务用相同的系统提示词

2.6 模型分层策略

不是所有任务都需要旗舰模型。用对模型，比优化 Prompt 省更多钱。

任务复杂度分级：

任务类型	复杂度	推荐模型档位	价格区间（输入）
分类、标签、意图识别	极低	轻量/Flash	$0.30-0.30-$ 0.30−1/百万
摘要、翻译、格式化	低	轻量/中端	$0.75-0.75-$ 0.75−2/百万
常规问答、内容生成	中	中端/主力	$2-2-$ 2−5/百万
代码编写、复杂推理	高	旗舰	$5-5-$ 5−10/百万
Agent 长程任务、多步推理	极高	超旗舰	$10/百万+

同一任务在不同模型上的成本对比：

任务：对 1000 条用户评论做情感分类（输入平均 100 Token，输出 10 Token）

模型	输入价	输出价	单次成本	1000 次总成本
GPT-6 Astra	$10/M	$50/M	$0.0015	$1.50
Claude Opus 5	$5/M	$25/M	$0.00075	$0.75
GPT-5.6 Terra	$2.50/M	$15/M	$0.0004	$0.40
Claude Sonnet 5	$2/M	$10/M	$0.0003	$0.30
GPT-5.6 Luna	$1/M	$6/M	$0.00016	$0.16
Gemini 3.8 Flash（促销）	$0.75/M	$3.75/M	$0.00011	$0.11
Gemini 3.5 Flash-Lite	$0.30/M	$2.50/M	$0.000055	$0.055

用 Flash-Lite 代替 GPT-6 Astra，成本降低 96%，而情感分类这种简单任务的准确率差异可能不到 2%。

路由策略（Router Pattern）：

先用轻量模型判断任务复杂度，再决定是否升级到旗舰模型。

用户请求
  ↓
轻量模型分类（成本 < $0.001）
  ├─ 简单任务 → 轻量模型处理（$0.001-$0.01）
  ├─ 中等任务 → 中端模型处理（$0.01-$0.05）
  └─ 复杂任务 → 旗舰模型处理（$0.05-$0.50+）

这种"分级路由"架构，在保证复杂任务质量的同时，让 80% 的简单任务用最便宜的模型处理，整体成本可降低 70% 以上。

2.7 批量处理（Batch API）

对于不需要实时响应的任务，Batch API 可以省一半的钱。

OpenAI Batch API：

• 折扣：50%（标准价格的一半）
• 延迟：异步处理，24 小时内返回结果（通常几小时内）
• 适用场景：离线数据处理、批量翻译、批量分类、数据标注

from openai import OpenAI

client = OpenAI()

# 创建批量任务
batch_input_file = client.files.create(
    file=open("batch_tasks.jsonl", "rb"),
    purpose="batch"
)

batch_job = client.batches.create(
    input_file_id=batch_input_file.id,
    endpoint="/v1/chat/completions",
    completion_window="24h",
)

其他平台的 Batch 优惠：

平台	Batch 折扣	备注
OpenAI	50%	24 小时内返回
Anthropic	50%	需通过 Batch API
Google Gemini	视模型而定	部分模型支持
DeepSeek	按量无额外折扣	但本身价格极低

注意：Batch API 不适合需要实时响应的场景（如聊天机器人），但对于离线处理、数据标注、批量内容生成等任务，是最简单粗暴的省钱方式。

2.8 实际案例：客服机器人成本优化

场景：一个客服机器人，日均 10000 次对话，平均输入 500 Token + 输出 300 Token。

优化前（全部用旗舰模型 GPT-5.6 Terra）：

项目	计算	日成本	月成本
输入	10000 × 500 × $2.50/M	$12.5	$375
输出	10000 × 300 × $15/M	$45	$1350
合计		$57.5	$1725

优化后（80% 轻量 + 缓存 + 输出限制）：

优化措施：

1. 80% 简单咨询用 GPT-5.6 Luna（ $1/1/$ 1/6），20% 复杂问题升级到 Terra
2. 系统提示词（500 Token）固定，缓存命中率 90%
3. 输出限制：简单问题 max_tokens=200，复杂问题 max_tokens=500
4. 历史对话滑动窗口，平均输入从 500 降到 350

项目	计算	日成本	月成本
简单任务输入（80%）	8000 × 350 × $1/M × (0.9×0.1+0.1×1)	$3.64	$109.2
简单任务输出（80%）	8000 × 200 × $6/M	$9.6	$288
复杂任务输入（20%）	2000 × 350 × $2.50/M × (0.9×0.1+0.1×1)	$2.275	$68.25
复杂任务输出（20%）	2000 × 500 × $15/M	$15	$450
合计		$30.5	$915.5

优化效果：月成本从 $1725降到1725\; 降到$ 1725降到915，节省 47%。

如果再加上 Batch API（非实时部分 5 折）和更激进的模型分层，节省比例可达 70%-90%。

省Token的核心不是"少说话"，而访客是"少给无关信息、少让AI走弯路、少产生无效输出"。

---

第三部分：国内国际主流模型对比 📊

了解了 Token 和省钱技巧，接下来看看市面上有哪些模型可选。2026 年的大模型市场已经非常成熟，国内外各有强势玩家。

3.1 国际主流模型

以下为当前最新主力模型（已排除 GPT-4o、Claude 3.5 等 legacy 型号）：

模型	厂商	定位	输入价($/M)	缓存输入($/M)	输出价($/M)	上下文	多模态	开源
GPT-6 Astra	OpenAI	超旗舰 Agent	$10	$1	$50	1.05M	文本+图像	否
Claude Fable 5.1	Anthropic	超旗舰 编码/长程	$10	$0.25	$50	1M	文本+图像	否
Claude Opus 5	Anthropic	旗舰 通用	$5	$0.50	$25	1M	文本+图像	否
GPT-5.6 Sol（促销）	OpenAI	旗舰 通用	$4	$0.40	$20	1.05M	文本+图像	否
GPT-5.6 Terra	OpenAI	主力 平衡	$2.50	$0.25	$15	1.05M	文本+图像	否
Claude Sonnet 5	Anthropic	主力 性价比	$2	$0.20	$10	1M	文本+图像	否
Grok 4.6	xAI	中端 编码	$2	---	$6	256K	文本+图像	否
GPT-5.6 Luna	OpenAI	轻量 高频	$1	$0.10	$6	1.05M	文本+图像	否
Claude Haiku 4.5	Anthropic	轻量 低延迟	$1	$0.10	$5	200K	文本+图像	否
Gemini 3.8 Flash（促销）	Google	轻量 高吞吐	$0.75	$0.075	$3.75	1M+	全模态	否
Mistral Medium 3	Mistral	轻量 欧洲合规	$0.40	---	$2	128K+	多模态	否
Gemini 3.5 Flash-Lite	Google	超轻量 大规模	$0.30	---	$2.50	1M+	全模态	否
Llama 4 Scout	Meta	开源 超长文本	免费(自部署)	---	免费	10M	原生多模态	是
Llama 4 Maverick	Meta	开源 编码	免费(自部署)	---	免费	1M+	原生多模态	是

数据截至 2026-09-08，来源各厂商官方定价页。GPT-5.6 Sol 促销价有效期至 2026-11 月，Gemini 3.8 Flash 促销价至 2026-12-31。

国际阵营点评：

2026 年国际大模型市场呈现四大趋势：

1. 旗舰两极分化 ------GPT-6 Astra 与 Claude Fable 5.1 标价齐平 $10/10/$ 10/50，但竞争焦点从输入输出价转向缓存成本 。Fable 缓存仅 $0.25（基价2.50.25（基价\; 2.5\%），Astra\; 为$ 0.25（基价2.51（基价 10%），长任务实际成本差 4 倍。

2. 中端价格战白热化 ------Sonnet 5 永久 $2/2/$ 2/10、GPT-5.6 Luna $1/1/$ 1/6、Gemini Flash 促销 $0.75/0.75/$ 0.75/3.75，主力模型价格较一年前下降 50%-80%。

3. 上下文窗口普遍迈入百万级，Llama 4 Scout 以 10M 开源最长窗口打破纪录。

4. Agent 能力成为新战场------Computer Use、跨窗口笔记持久化、长程编码等端到端任务能力取代单一 benchmark 成为选型核心指标。

3.2 国内主流模型

模型	厂商	定位	输入价(¥/M)	缓存命中(¥/M)	输出价(¥/M)	上下文	多模态	开源
DeepSeek-V4-Pro	深度求索	旗舰 推理/代码	¥3	¥0.025	¥6	1M	文本	否
Qwen3.8-Max	阿里	旗舰 多模态	¥12	¥1.5	¥36	1M	全模态	是
GLM-5.3	智谱	旗舰 通用	¥8	¥2	~¥28	200K+	多模态	否
Kimi K3	月之暗面	旗舰 长文本/代码	¥20	¥2	¥100	1M	视觉	是
Doubao-Seed-2.1-Pro	字节	旗舰 Agent/代码	¥6	---	¥30	256K	文本+图像	否
DeepSeek-V4-Flash	深度求索	轻量 性价比	¥1	¥0.02	¥2	1M	文本	否
Qwen3.8-Flash	阿里	轻量 高吞吐	¥0.8	¥0.1	¥2.7	128K+	多模态	是
GLM-5.3-Flash	智谱	轻量 多模态	¥0.8	¥0.23	¥2.8	长上下文	全模态	是
Doubao-Seed-2.1-Turbo	字节	中端 平衡	~¥3	---	~¥15	256K	多模态	否
ERNIE-5.1	百度	中端 搜索增强	¥4	---	¥18	128K	多模态	否
混元 Hy4 preview	腾讯	中端 通用	¥6	¥0.3	¥18	128K+	多模态	是
MiniMax M3	MiniMax	旗舰 多模态/长文本	¥4.2	¥0.84	¥16.8	1M	全模态	是
Step-3.7-Flash	阶跃星辰	轻量 低延迟	~¥1.2	---	未公开	256K	---	是
Yi-Lightning	零一万物	超轻量 免费	免费额度150万/月	---	按量	---	---	部分

数据截至 2026-09-08，来源各厂商官方定价页。GLM-5.3-Flash 限时半价至 2026-09-09。

国内阵营点评：

2026 年国内大模型行业呈现三大趋势：

1. 开源旗舰化------Kimi K3（2.8T 参数）、Qwen3.8-Max（2.4T）、GLM-5.3-Flash、MiniMax M3 等万亿参数级模型相继开源。开源模型首次在 Code Arena 等榜单超越闭源模型登顶。

2. 价格两极分化------Flash/轻量模型价格战持续（输入低至 ¥0.8/百万 Token），而旗舰推理模型因算力成本压力集体涨价（Kimi K3 输出达 ¥100）。行业从"低价抢量"进入"能力定价"阶段。

3. Agent 与多模态原生融合------新一代模型普遍原生支持图像/视频输入和长时 Agent 自主任务（豆包 2.1 可跑 18 小时芯片设计、Kimi K3 支持 4000 次工具调用），上下文窗口迈入 1M 时代。

3.3 国内外同档位价格对比（统一美元）

为了公平比较，把国内模型价格按 1 USD ≈ 7.2 CNY 换算成美元：

档位	国际代表	输入($/M)	输出($/M)	国内代表	输入($/M)	输出($/M)	国内便宜多少
超旗舰	GPT-6 Astra	$10	$50	---	---	---	---
旗舰	Claude Opus 5	$5	$25	DeepSeek-V4-Pro	$0.42	$0.83	输入便宜 92%
主力	Claude Sonnet 5	$2	$10	Doubao-Seed-2.1-Turbo	$0.42	$2.08	输入便宜 79%
轻量	GPT-5.6 Luna	$1	$6	DeepSeek-V4-Flash	$0.14	$0.28	输入便宜 86%
超轻量	Gemini 3.5 Flash-Lite	$0.30	$2.50	Qwen3.8-Flash	$0.11	$0.38	输入便宜 63%

结论非常清晰：同档位下，国内模型的价格通常只有国际模型的 10%-30%。 DeepSeek-V4-Pro 作为旗舰推理模型，输入价仅 $0.42/百万，比ClaudeOpus5的0.42/百万，比\; Claude\; Opus\; 5\; 的$ 0.42/百万，比ClaudeOpus5的5 便宜 92%，而推理能力在多项基准上已非常接近。

当然，价格不是唯一因素。国际模型在多模态原生支持、Agent 工具链成熟度、英文语境理解等方面仍有优势；国内模型则在中文理解、国内访问速度、支付便利性、数据合规方面更胜一筹。

---

第四部分：选型建议 🎯

面对 30+ 模型，怎么选？按四个维度逐一匹配。

4.1 按场景选型

场景	首选模型	备选	理由
日常对话/客服	GPT-5.6 Luna / DeepSeek-V4-Flash	Claude Haiku 4.5 / Qwen3.8-Flash	轻量模型足够，成本仅旗舰 1/10-1/20
代码开发	Claude Opus 5 / GPT-5.6 Terra	DeepSeek-V4-Pro / Qwen3.8-Max	Claude 在 SWE-bench Pro 达 79.2%，代码能力顶级
长文档处理	Llama 4 Scout (10M) / Claude Sonnet 5 (1M)	Kimi K3 (1M) / DeepSeek-V4 (1M)	超长上下文 + 低输入价，Sonnet 5 $2/M 性价比极高
Agent 任务	GPT-6 Astra / Claude Fable 5.1	Doubao-Seed-2.1-Pro / Qwen3.8-Max	Astra 的 Computer Use 和 Responses API 集成最深；Fable 缓存便宜适合长程任务
复杂推理	Claude Opus 5 / GPT-5.6 Sol	DeepSeek-V4-Pro / Qwen3.8-Max	Opus 5 AA 指数 60.7（公开模型最高之一）
多模态	Gemini 3.8 Flash / Qwen3.8-Max	GLM-5.3-Flash / MiniMax M3	Gemini 原生支持视频理解；Qwen3.8-Max Vision Arena 全球第二
私有化部署	Qwen3.8-Max / Llama 4	Kimi K3 / GLM-5.3-Flash	开源权重 + Apache 2.0 许可，可自由部署

4.2 按预算选型

月预算	推荐模型组合	说明
免费/极低预算	开源模型自部署（Llama 4 / Qwen3.8）+ 各平台免费额度 + Yi-Lightning（免费 150 万 Token/月）	有 GPU 服务器可自部署开源模型；各平台新用户都有免费额度
< ¥100	DeepSeek-V4-Flash（¥1/¥2）+ Qwen3.8-Flash（¥0.8/¥2.7）+ GLM-5.3-Flash（¥0.8/¥2.8）	轻量模型组合，¥100 可以调用约 5000 万输入 Token
¥100-¥1000	DeepSeek-V4-Pro（¥3/¥6）+ Claude Sonnet 5（ $2/2/$ 2/10）+ Doubao-Seed-2.1-Turbo	主力模型组合，兼顾质量和成本；复杂任务用 Pro，日常用 Flash
¥1000-¥10000	Claude Opus 5（ $5/5/$ 5/25）+ GPT-5.6 Terra（ $2.5/2.5/$ 2.5/15）+ Qwen3.8-Max（¥12/¥36）	旗舰模型组合，核心任务用旗舰，批量任务用中端
旗舰无上限	GPT-6 Astra（ $10/10/$ 10/50）+ Claude Fable 5.1（ $10/10/$ 10/50）	超旗舰组合，只用于最高价值的 Agent 和复杂推理任务

4.3 选型决策流程图

---

第五部分：各种使用技巧 🛠️

选好了模型，怎么用才能效果最好、坑最少？

5.1 Prompt 工程进阶技巧

CoT（Chain of Thought，思维链）

让模型"一步步思考"，推理准确率显著提升。

❌ 零样本：
"这个问题的答案是什么？"

✅ CoT：
"请一步步思考这个问题，先分析已知条件，再推导结论，最后给出答案。"

对于数学题、逻辑推理、复杂分析，CoT 可以提升 10%-40% 的准确率。代价是输出 Token 增加（因为模型要输出思考过程），所以简单任务不需要用。

Few-shot（少样本学习）

给 2-3 个示例，比零样本效果好。示例要覆盖典型情况和边界情况。

请按以下格式提取信息：

示例1：
输入："张三，13800138000，北京市朝阳区"
输出：{"name":"张三","phone":"13800138000","address":"北京市朝阳区"}

示例2：
输入："李四的电话是13900139000，住在上海浦东"
输出：{"name":"李四","phone":"13900139000","address":"上海浦东"}

现在处理：
输入："王五，电话13700137000，深圳市南山区"
输出：

角色设定

❌ 泛泛而谈：
"请回答Java问题。"

✅ 角色设定：
"你是一个有15年经验的资深Java架构师，精通Spring Boot微服务和分布式系统。
回答时先给出核心结论，再展开技术细节，最后给出代码示例。"

角色设定能显著提升回答的专业性和格式一致性。

结构化输出

要求模型输出 JSON / Markdown 表格，方便程序解析。

"请以JSON格式输出，包含以下字段：title（字符串）、tags（字符串数组）、summary（字符串，不超过100字）。
只输出JSON，不要其他文字。"

OpenAI 提供了 Structured Outputs（JSON 模式） ，可以通过 response_format 参数强制模型输出符合 JSON Schema 的内容，从根本上解决格式不稳定问题。

5.2 温度/Token 参数调优

参数	作用	推荐值	场景
temperature	控制随机性。0=确定性，1=创造性	0-0.3	代码、事实问答、数据提取
			0.7-1.0
top_p	核采样，与 temperature 二选一	0.9	大多数场景
frequency_penalty	减少重复词（-2.0 到 2.0）	0.3-0.8	长文本生成、避免重复
presence_penalty	鼓励新话题（-2.0 到 2.0）	0.3-0.6	创意写作、多样化输出
max_tokens	最大输出 Token 数	按需	分类=50，摘要=500，问答=1000
stop	提前终止生成的序列	按需	如 ["\n\n"] 控制段落

调优原则：

• 代码/事实类任务：temperature 0-0.3，top_p 不设或 1.0
• 创意类任务：temperature 0.7-1.0，top_p 0.9
• 不要同时调 temperature 和 top_p，选一个即可
• max_tokens 永远不要用默认值（通常很大），根据场景设小

5.3 多轮对话最佳实践

1. 系统提示词放最前面且保持不变------利于缓存命中，不要每次请求都修改
2. 用户消息和助手消息交替------格式要正确，不要连续两条用户消息
3. 长对话定期摘要压缩------超过 10 轮就考虑压缩早期历史
4. 关键信息在每轮重复------模型对早期信息的"注意力"会衰减，重要约束（如"用中文回答"、"输出JSON"）在系统提示词中固定即可
5. 不要把全部历史塞进去------用滑动窗口或摘要，控制总 Token 在窗口的 50% 以内（留足输出空间）

5.4 Function Calling / Tool Use 技巧

工具描述要精确：

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "查询指定城市的实时天气",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名称，如'北京'、'上海'"},
                    "unit": {"type": "string", "enum": ["celsius", "fahrenheit"], "description": "温度单位"}
                },
                "required": ["city"]
            }
        }
    }
]

• 名称简洁明了（get_weather 而不是 function1）
• description 写清楚工具做什么、什么时候用
• 参数描述精确，包含枚举值和示例

一次不要给太多工具------模型在 10+ 工具中选择时容易困惑或选错。建议单次请求提供 3-5 个最相关的工具，或者用"工具分类+路由"的方式先选类别再选具体工具。

工具结果要简洁------不要把整个 API 返回（可能几千 Token）都塞给模型，只提取关键信息。

❌ 工具返回：
{"status":200,"data":{"current":{"temp_c":25,"condition":{"text":"晴"},"wind_kph":10,"humidity":60,"pressure_mb":1013,"uv":5,"feelslike_c":27},"location":{"name":"北京","country":"中国","lat":39.9,"lon":116.4,"tz_id":"Asia/Shanghai"}},...}

✅ 精简后：
"北京当前天气：晴，25°C，湿度60%，风速10km/h"

并行工具调用------多个独立工具可以并行调用，减少轮次和延迟。GPT-4+ 和 Claude 3+ 都支持并行 Function Calling。

5.5 常见坑与避坑指南

① 幻觉（Hallucination）

模型会编造看似合理但实际错误的事实、引用、代码。

• 应对：关键信息必须验证；用 RAG（检索增强生成）给模型提供真实资料；对事实性输出加"如果不确定，请说不知道"的指令；代码必须运行测试
• 重灾区：法律条文引用、学术论文引用、API 文档、历史事件日期

② 上下文溢出

Token 超过窗口限制会报错或截断。

• 应对 ：用滑动窗口控制历史长度；长文档用 RAG 分段检索；设置 max_tokens 时确保输入 + max_tokens < 上下文窗口

③ 格式不稳定

要求 JSON 但偶尔输出额外文字（如"好的，这是JSON："）。

• 应对：用 OpenAI Structured Outputs / Anthropic 工具调用强制格式；加后处理（正则提取 JSON 部分）；在 prompt 中强调"只输出 JSON，不要任何其他文字"

④ 中文夹杂英文

模型有时用英文回答中文问题。

• 应对：系统提示词中明确"所有回答必须使用中文"；如果仍出现，在用户消息末尾加"请用中文回答"

⑤ 缓存未命中

频繁修改系统提示词导致缓存失效。

• 应对 ：系统提示词一旦确定就不要改；变化的内容（如用户数据）放在用户消息中；监控 cached_tokens 字段确认命中率

⑥ 输出被截断

max_tokens 设太小，回答到一半被切断。

• 应对 ：根据任务类型合理设置 max_tokens；检测返回的 finish_reason，如果是 length 说明被截断，需要增大 max_tokens 或分段请求

5.6 各平台特有功能利用

Claude（Anthropic）：

• Artifact：可以生成完整文件（代码、文档、SVG），在 UI 中直接预览和下载
• Prompt Caching：缓存读取仅正常价 10%，Fable 5.1 更是低至 2.5%，长上下文场景成本优势巨大
• Extended Thinking：模型可以进行深度思考（消耗额外 Token），推理能力显著提升
• Computer Use：可以控制电脑桌面，完成复杂的 GUI 操作任务

GPT（OpenAI）：

• Structured Outputs：强制 JSON 格式输出，保证 100% 可解析
• Batch API：5 折优惠，适合离线批量处理
• Responses API：新一代 API，支持原生工具调用、输入提示词缓存、多模态
• Computer Use（GPT-6 Astra）：端到端计算机操作能力

Gemini（Google）：

• 原生多模态：支持视频理解（最长 1 小时视频）、音频输入、图像理解
• 长上下文：1M+ 窗口，Flash 系列促销期价格极低
• Google 生态集成：与 Google Search、Workspace、Cloud 深度集成

国内模型特色：

• DeepSeek：思考/非思考双模式切换，推理能力强，价格极低
• Qwen：全模态支持（文本/图像/视频/音频），开源生态完善
• Kimi：超长上下文（1M），KDA 技术实现 6.3 倍解码加速
• 豆包：日均 Token 调用量 180 万亿，工程化能力强，支持长时 Agent 任务
• GLM：综合智能指数对标 Claude Opus，Flash 版本原生多模态且开源

---

结语

大模型时代，Token 就是"数字世界的电"。你用的每一个 Token，都在驱动模型进行一次预测、一次思考、一次创造。

本文我们讲透了五件事：

1. Token 是什么------模型的乐高积木，BPE 算法从字符合并出语义单元，中文约 1.5 字/Token，英文约 1.3 词/Token
2. 怎么省钱------精简 Prompt、优化系统提示词、控制输出、管理上下文、巧用缓存（省 90%）、模型分层（省 80%）、Batch API（省 50%）
3. 模型怎么选------国内模型价格仅为国际同档 10%-30%，旗舰选 Claude Opus 5 / GPT-5.6 Sol / DeepSeek-V4-Pro，轻量选 Gemini Flash / DeepSeek Flash / Qwen Flash
4. 选型框架------按场景、预算匹配，私有化选 Qwen/Llama，预算敏感选 Flash，复杂任务选旗舰
5. 使用技巧------CoT 提升推理、temperature 按需调优、Function Calling 精确描述、警惕幻觉和格式不稳定

大模型技术还在快速迭代------模型能力每半年上一个台阶，价格每半年下一个台阶。今天的"旗舰"可能半年后就变成"中端"，今天的"省钱技巧"可能因为新的缓存机制而被颠覆。

保持学习，动手实践，找到最适合你场景的模型和用法。 毕竟，最适合你的模型，不是最贵的那个，而是用对了地方的那个。

一句话金句：懂 Token 的人，用 1 块钱跑出别人 100 块钱的效果。