大模型提示词Token经济学万字指南：从底层分词机制到工程级成本优化

为什么我们需要关心Token？做环保经济的使用者、开发者

在大型语言模型（LLM）日益普及的今天，无论是调用API还是部署本地模型，Token都是绕不开的核心概念。它不仅是模型处理文本的基本单位，更是成本计量的直接依据。

然而，许多开发者对Token的理解仍停留在表面——“一个汉字等于一个Token”、”文言文更省Token”等误区广泛流传。这些误解不仅影响使用体验，更可能导致不必要的成本浪费。

本文将从最底层的分词机制讲起，系统性地拆解Token的生成原理、影响因素、优化策略，并提供可直接落地的工程实践方案。无论开发者是API调用者、本地部署者，还是模型开发者，都能从中找到有价值的参考。

---

第一章：Token到底是什么？

1.1 Token的本质

Token是语言模型处理文本的最小单位。但它既不是”字”，也不是”词”，而是通过特定算法从文本中切分出来的片段。

以GPT系列使用的BPE（Byte-Pair Encoding，字节对编码）算法为例，分词过程大致如下：

1. 初始阶段：将文本拆分为单个字符（或字节）。
2. 统计合并：统计相邻片段共现频率，将最高频的一对合并为一个新Token。
3. 迭代压缩：重复步骤2，直到达到预设的词汇表大小。

最终生成的词汇表，就是模型”认识”的所有Token。输入文本时，分词器会按照”最长匹配优先”的原则，将文本切分为词汇表中存在的Token序列。

1.2 为什么不能简单地”按字计费”？

很多人直觉上认为：一个汉字 = 一个Token。但实际情况要复杂得多。

关键原因在于：分词器的词汇表是基于训练语料构建的。

• 如果某个词在训练语料中高频出现，分词器会倾向于将它合并为一个Token。
• 如果某个组合极其罕见，它可能会被拆成多个更小的单元。

这就解释了为什么”天气”可能只需要1-2个Token，而”蒹葭苍苍”可能需要6个Token——前者是现代汉语高频词，后者是低频古文组合。

1.3 不同模型的分词器差异

不同模型使用的分词算法和词汇表大小不同，导致同一个文本在不同模型上的Token数量可能差异显著。

模型	分词器	词汇表大小	中文友好度
GPT-3/3.5	BPE	50,257	较低
GPT-4	BPE（改进版）	~100,000	中等
Claude	BPE	~100,000	中等
通义千问	自研	~150,000	较高
Llama 2/3	SentencePiece	32,000/128,000	较低/中等
Qwen系列	自研BPE	~151,643	高

结论：中文优化的模型（如通义千问、Qwen）通常能实现接近1汉字=1Token的效率，而以英文语料为主的模型（如早期GPT、Llama）中文Token消耗偏高。

---

第二章：什么因素影响Token数量？

2.1 语言类型

英文：由于BPE算法天然适合英文，常见英文单词通常能被合并为单个Token。例如：

• “hello” → 1 Token
• “understanding” → 可能1-2 Tokens
• 但生僻词如”antidisestablishmentarianism”会被拆成多个Token

中文：情况更复杂。

• 高频词（”我们”、”今天”）→ 1-2 Tokens
• 低频词/生僻字 → 可能1字=2-3 Tokens
• 标点符号 → 通常1 Token/个

混合文本：中英文混排时，分词器需要在两种语言的切分规则之间切换，通常会导致Token数量略高于纯中文或纯英文。

2.2 文本内容与风格

文言文 vs 白话文

这是最常见的误区之一。让我们用实测数据说话：

文本	字数	GPT-4 Token数	通义千问 Token数
用户彻底怒了	5	3	5
客官震怒	4	4	4
她永远不会回来了	7	3	7
永失吾爱	4	4	4
蒹葭苍苍，白露为霜	8	6-8	8
你好，请帮我翻译这段话	10	8-10	10

分析：

• 在GPT-4上，部分文言文表达反而更费Token，因为”震””怒”等单字在英文语料为主的词汇表中未被充分合并。
• 在通义千问等中文优化模型上，1汉字≈1Token的规律更稳定，文言文和白话文差异不大。
• 但无论如何，文言文的”字数少”优势在Token层面被大幅削弱甚至逆转。

代码 vs 自然语言

代码的Token消耗通常高于同等长度的自然语言，因为：

• 变量名、函数名等标识符多为低频组合
• 特殊符号（{}[]()<>=!）各自占用Token
• 缩进和空格在某些分词器中也被计入

2.3 格式与结构

Markdown格式：#、**、- 等符号各自占用Token，但通常能提升模型理解效率，属于”值得的开销”。

JSON/XML结构：键名重复出现时会重复计费。例如：

{"name": "张三", "age": 25, "name": "李四", "age": 30}

“name”和”age”各出现两次，Token消耗翻倍。

列表与编号：1.、2. 或 - 前缀会增加少量Token，但能显著提升输出的结构化程度。

---

第三章：提示词设计的Token优化策略

3.1 输入端优化：极简指令

原则：只保留模型执行所需的核心语义，删除一切冗余。

去客套话

"你好，能不能麻烦你帮我把下面这段中文翻译成英文，谢谢？"
"中译英："

节省：约10-15 Tokens

去解释性文字

"我希望你能作为一名专业的SEO专家，帮我优化下面这篇文章，让它更符合搜索引擎的要求，同时保持可读性"
"SEO优化下文："

节省：约20-30 Tokens

用符号替代连接词

"先分析这段代码的问题，然后给出修改建议，最后提供完整的修正代码"
"分析→建议→完整代码："

节省：约5-10 Tokens

用术语替代描述

"让文章更符合搜索引擎要求"
"SEO优化"

节省：约5-8 Tokens

3.2 输出端优化：严控格式

输出Token通常比输入Token贵3-5倍（API定价），因此控制输出是省钱的关键。

指定输出格式

"只输出JSON，不要其他内容"
"只输出代码，不要解释"
"只给结论，不要推理过程"

限制长度

"限50字内"
"列出3点"
"一句话总结"

禁止废话

在System Prompt中预设：

"不要寒暄"
"不要说'好的'、'当然可以'"
"不要总结'希望以上信息对你有帮助'"

3.3 穴居人模式（Caveman Mode）

这是一种极端的Token节省技巧，核心是让模型用最原始的方式交流：

规则：

• 去掉冠词（a/an/the）
• 去掉填充词（just/really/basically）
• 去掉礼貌用语
• 使用电报式短句

示例：

"Could you please help me translate the following text into Chinese?"
"Translate to Chinese:"

效果：实测可节省约60-70%的英文Token，且不影响技术任务的准确性。

注意：此模式适合技术类任务，不适合需要细腻表达的场景。

3.4 结构化提示词模板

以下是一套经过验证的高效模板结构：

[角色] 你是一名[专业领域]专家
[任务] [动词][对象]
[约束] 
- 格式：[JSON/列表/代码]
- 长度：[X字/X点]
- 禁止：[不要X/不要Y]
[输入] 
[内容]

示例：

[角色] 你是一名Python工程师
[任务] 重构以下代码
[约束]
- 格式：只输出代码
- 要求：PEP8规范，添加类型注解
- 禁止：不要解释，不要注释
[输入]
def foo(x):
    return x+1

---

第四章：工程级优化方案

4.1 Prompt缓存

原理：许多API提供商（如OpenAI、Anthropic）支持Prompt缓存功能。将固定的System Prompt缓存后，后续请求只需传输动态部分，缓存部分的Token成本可降低90%以上。

适用场景：

• 固定的角色设定
• 固定的输出格式要求
• 固定的知识库片段

实现示例（伪代码）：

# 首次请求：建立缓存
response = client.chat.completions.create(
    model="gpt-4",
    messages=[
        {"role": "system", "content": system_prompt, "cache": True},
        {"role": "user", "content": user_query}
    ]
)

# 后续请求：复用缓存
response = client.chat.completions.create(
    model="gpt-4",
    messages=[
        {"role": "system", "content": system_prompt, "cache": True},  # 命中缓存
        {"role": "user", "content": new_query}
    ]
)

成本对比：

• 无缓存：System Prompt每次全额计费
• 有缓存：System Prompt成本降低90%+

4.2 模型路由

原理：不同任务对模型能力的要求不同。简单任务使用轻量模型，复杂任务才调用大模型。

路由策略：

任务类型	推荐模型	原因
文本分类	小模型/专用模型	规则明确，无需推理
简单翻译	小模型	任务单一
代码生成	代码专用模型	针对性优化
复杂推理	GPT-4/Claude 3	需要深度思考
创意写作	中等模型	平衡质量与成本

实现示例：

def route_model(task_type, input_text):
    if task_type == "classification":
        return "gpt-3.5-turbo"
    elif task_type == "translation" and len(input_text) < 500:
        return "gpt-3.5-turbo"
    elif task_type == "code_generation":
        return "gpt-4"
    elif task_type == "complex_reasoning":
        return "gpt-4"
    else:
        return "gpt-3.5-turbo"

4.3 流式输出与早停

流式输出：虽然不直接减少Token，但能提升用户体验，让用户在生成过程中即可开始阅读，减少等待焦虑导致的重复请求。

早停机制：

• 设置max_tokens上限，防止模型生成过长内容
• 使用stop参数指定停止序列，如["\n\n", "END"]

response = client.chat.completions.create(
    model="gpt-4",
    messages=messages,
    max_tokens=500,  # 限制最大输出
    stop=["END"]     # 遇到END即停止
)

4.4 本地部署的Token优化

对于本地部署的开源模型，Token优化思路略有不同：

1. 选择高效的分词器

• 优先选择词汇表较大的模型（如Qwen-72K、Llama-3-128K）
• 中文场景优先选择中文优化的模型

2. KV Cache优化

• 启用KV Cache复用，避免重复计算
• 使用PagedAttention等技术提升显存效率

3. 量化与蒸馏

• 使用4-bit/8-bit量化降低推理成本
• 使用蒸馏后的小模型处理简单任务

---

第五章：常见误区与澄清

5.1 误区一：文言文更省Token

澄清：如前文实测所示，文言文在多数主流模型上并不比白话文省Token，甚至可能更费。原因是：

• 文言文用字低频，难以被分词器合并
• 生僻字在字节层面占用更多空间

建议：使用精炼的现代白话文，而非文言文。

5.2 误区二：英文比中文省Token

澄清：这取决于具体模型。

• 在GPT-3.5等英文优化模型上，英文确实更省
• 在通义千问等中文优化模型上，中英文差异不大
• 在Llama 3等新一代模型上，差距已大幅缩小

建议：根据所用模型选择语言，而非一概而论。

5.3 误区三：Token越少越好

澄清：Token优化需要平衡”成本”与”效果”。过度压缩可能导致：

• 模型理解偏差
• 输出质量下降
• 需要多次重试，反而增加总成本

建议：在保证任务完成质量的前提下优化Token，而非盲目追求最少。

5.4 误区四：所有模型的Token计算方式相同

澄清：不同模型的分词器不同，同一文本的Token数可能差异很大。

建议：使用官方提供的Token计数器进行精确计算，而非凭经验估算。

---

第六章：实战案例分析

6.1 案例一：客服机器人

背景：某电商公司使用GPT-4构建客服机器人，每月API成本约5万元。

优化前：

System Prompt: "你是一名专业的客服代表，请热情、耐心地回答用户的问题。如果用户有任何不满，请先表示歉意，然后提供解决方案。回答要详细、全面，确保用户满意。"

问题：

• System Prompt过长，每次请求全额计费
• “热情””耐心”等主观描述增加Token但不提升效果
• 输出无长度限制，模型经常生成冗长回复

优化后：

System Prompt（缓存）: "角色：客服。要求：简洁、专业、解决问题。禁止：寒暄、道歉套话。"
User: "[问题]"

效果：

• System Prompt缓存后成本降低90%
• 输出长度限制使平均输出Token减少40%
• 总体成本降低约60%

6.2 案例二：代码生成助手

背景：开发团队使用Claude 3生成代码片段。

优化前：

"请帮我写一个Python函数，用来计算两个数的最大公约数，希望能用递归的方式实现，代码要简洁易懂"

优化后：

"Python递归GCD函数，只输出代码"

效果：

• 输入Token减少70%
• 输出Token减少50%（无解释文字）
• 总成本降低约60%

6.3 案例三：批量文本分类

背景：内容平台需要对海量文章进行分类。

优化前：逐条调用API，每条单独请求。

优化后：

• 使用批量API
• 将多条文本合并为一次请求
• 使用小模型（GPT-3.5）而非大模型

效果：

• 请求次数减少90%
• 单次请求Token增加但总成本降低50%

---

第七章：Token优化的边界与反思

7.1 过度优化的风险

Token优化并非没有代价。以下是一些需要警惕的风险：

1. 语义损失
过度压缩可能导致关键信息丢失，模型无法准确理解意图。

2. 可维护性下降
极简提示词对新人不友好，增加团队协作成本。

3. 鲁棒性降低
过于精简的提示词可能对输入变化更敏感，容错率降低。

4. 边际效应递减
当Token已经优化到一定程度后，继续压缩的收益会越来越小，而风险会越来越大。

7.2 何时不应该优化Token？

以下场景建议优先保证效果，而非追求Token最少：

• 高价值任务：如法律文档分析、医疗诊断辅助，准确性远比成本重要
• 首次探索：在新任务上，先用完整提示词验证效果，再逐步优化
• 用户体验敏感：如面向C端用户的产品，自然流畅的交互比节省几毛钱更重要
• 合规要求：某些行业需要保留完整的对话记录和操作日志

7.3 Token优化的哲学

Token优化的本质是在成本、效果、效率三者之间寻找平衡点。

• 成本：API费用、计算资源
• 效果：输出质量、任务完成率
• 效率：响应速度、开发效率

优秀的工程师不会盲目追求某一项指标的极致，而是根据具体场景做出合理的权衡。

---

第八章：未来展望

8.1 分词技术的演进

随着模型架构的进步，分词技术也在不断演进：

1. 更大的词汇表
新一代模型（如Llama 3、Qwen 2）使用更大的词汇表（128K+），能更好地覆盖多语言场景，减少中文Token消耗。

2. 字符级模型
部分研究探索完全抛弃分词，直接在字符/字节级别建模。这可能彻底解决Token相关问题，但目前推理效率仍是挑战。

3. 多模态融合
随着多模态模型的发展，Token的概念可能扩展到图像、音频等领域，统一的多模态Token表示是研究热点。

8.2 成本结构的變化

1. 推理成本持续下降
随着硬件进步和算法优化，单位Token的推理成本将持续下降，Token优化的紧迫性可能降低。

2. 定价模式多元化
除了按Token计费，未来可能出现按请求次数、按响应时间、按任务复杂度等多元化定价模式。

3. 本地部署普及
随着开源模型质量提升和硬件成本下降，更多企业会选择本地部署，Token成本将转化为固定的硬件成本。

8.3 提示词工程的未来

1. 自动化提示词优化
AI自动优化提示词的工具将越来越成熟，手动优化Token的需求可能减少。

2. 提示词编译技术
类似编译器将高级语言编译为机器码，未来可能出现”提示词编译器”，自动将自然语言指令转换为最优的Token序列。

3. 语义压缩
研究如何在不损失语义的前提下，将信息压缩到更少的Token中，可能是重要方向。

---

第九章：常用技巧

场景一：日常对话 / 个人使用

核心矛盾：单轮便宜，但聊久了上下文膨胀，不知不觉就贵了。

实操技巧：

• 滑动窗口 + 自动摘要：只保留最近 5-10 轮对话，更早的内容让模型压缩成两三句摘要作为新上下文。每 10-15 轮做一次”快照重置”。
• 设定”无情”人设：在 System Prompt 里直接写”禁止寒暄、禁止过渡句、禁止总结性废话、禁止说’好的/当然可以’”。实测能砍掉 30%-50% 的输出冗余。
• stop 参数兜底：如果你只需要一行答案，把 \n 设为停止符，模型答完一句就闭嘴，不会追加”希望以上信息对你有帮助”。
• Few-shot 只留 1-2 个：示例不是越多越好，覆盖核心格式要素即可，堆砌例子是典型的”花钱买冗余”。

---

场景二：API 调用 / 工程化部署

这是降本空间最大的场景，按优先级排列：

1. Prompt 缓存（立竿见影，省 90%+）

把 System Prompt、工具定义等固定前缀保持不变，云厂商会对缓存部分按极低折扣计费（DeepSeek V4 Flash 缓存输入 $0.0028/百万 Token，比非缓存省 97%）。

关键细节：System Prompt 里不要塞时间戳、随机 ID 等动态变量，否则前缀无法逐字匹配，缓存失效。

2. 语义缓存（零 Token 返回结果）

对用户 Query 做向量化，相似度超过阈值（如 95%）直接返回历史答案，跳过模型调用。FAQ 类场景命中率可达 60%-80%，相当于砍掉六成大模型调用量。

实现思路：用 Redis 或向量数据库存 <query_embedding, answer> 键值对，TTL 设 24 小时，模型/知识库更新时自动失效。

3. 模型路由（省 40%-70% 总成本）

建立”任务难度 → 模型选择”的映射：

任务类型	推荐模型档位	原因
分类/提取/格式化	轻量级（GPT-4o-mini / Qwen-Turbo / DeepSeek-Flash）	规则明确，无需推理
翻译/润色	轻量级	任务单一
代码生成	中档	需要语法理解
复杂推理/多步规划	旗舰模型	需要深度思考

进阶玩法：用小模型做前置意图识别，70% 的简单请求在小模型层就消化掉，只有 30% 才路由到大模型。

4. 批量合并请求

把多个独立短问题合并到一次 API 调用中，共享 System Prompt。输入 Token 可减少 20%-40%，单位成本降低约 50%。

# 10 次单独调用 → 1 次批量调用
batch_inputs = ["翻译A", "翻译B", "翻译C", ...]
response = client.batch_create(inputs=batch_inputs)

5. Token-aware Chunking（RAG 场景省 30%-50%）

不要用固定字符数切分文档，而是用 tiktoken 等工具按 Token 数切分，确保每个 chunk 的 Token 数精确可控，避免”看似 500 字实际 800 Token”的溢出。

---

场景三：RAG / 知识库问答

核心矛盾：检索回来的文档片段往往包含大量无关内容，全塞进 Prompt 既贵又干扰模型判断。

实操技巧：

• 相关性过滤前置：先用小模型（max_tokens=1）对每个检索片段做”是否包含答案信息”的二分类，只把 Yes 的片段送入大模型。
• Top-K 精准召回：不要全量投喂，只取 Top 3-5 个高相关片段。配合重排序（Rerank）模型精排，命中率可显著提升。
• 层次化摘要：超长文档先分块摘要，再把摘要链起来作为上下文，而非原文。
• Embedding 缓存：RAG 系统中 90% 的 query 是高频重复的，对 embedding 结果做缓存，命中率通常 > 80%，省 70%-90%。

---

场景四：Agent / 多步推理

核心矛盾：Agent 每步推理都会重复加载工具定义和上下文，Token 消耗呈指数级增长。

实操技巧：

• 工具路由器（Tool Router）：不要把所有工具定义全塞进 Prompt。先用超轻量模型判断用户意图，只下发最相关的 2-3 个工具定义。
• 中间结果缓存：Agent 多步推理中，如果某子问题之前遇到过，直接复用先前步骤的答案或决策模式，避免重复计算。
• 迭代上限 + 预算告警：设置 Agent 最大迭代次数和 Token 预算阈值，防止死循环或过度推理。
• 三层加载结构：元数据常驻上下文，工具正文触发时加载，参考文件按需读取，控制正文长度在 500 行以内。

---

场景五：代码生成 / 技术任务

• TOON 替代 JSON：在 LLM 边界使用 Token-Oriented Object Notation 等紧凑格式，Schema 只写一次，后续只传值，可再省 30%-40%。
• 只输出代码，不要解释：明确”只输出代码块，不要注释、不要解释、不要’以下是代码’”，输出 Token 可减少 90%。
• temperature=0：代码生成不需要随机性，设为 0 确保输出确定性，减少重试。

---

场景六：批量数据处理 / 离线任务

• 错峰调用：部分平台（如 DeepSeek V4 Pro）有峰谷计费，高峰期价格翻倍。把非紧急的批量任务放到闲时调用，省 50%。
• 本地预处理：文本清洗、格式转换、HTML 标签移除等可本地完成的计算，提前处理后再送入模型，从源头削减无效 Token。
• 能用脚本就不用模型：重复性、流程明确的工作（如文件重命名、数据格式转换），做成脚本或可复用工具，只有真正需要判断和生成的环节才调用大模型。

---

一张速查表

场景	最高收益技巧	预期节省
日常对话	滑动窗口 + 摘要	40%-60%
API 调用	Prompt 缓存	90%+（缓存部分）
API 调用	语义缓存	50%-60% 调用量
API 调用	模型路由	40%-70% 总成本
RAG	相关性过滤 + Top-K	30%-50%
Agent	工具路由 + 中间结果缓存	30%-50%
批量任务	错峰调用 + 批量合并	50%+

---

如果你告诉我具体在用哪个平台（OpenAI / DeepSeek / 通义千问等）和什么场景，我可以帮你排一个更有针对性的优化优先级。

第十章：推荐速查参考

一、输入端：极简指令模板

1.1 通用结构模板

[角色] 你是一名[专业领域]专家
[任务] [动词][对象]
[约束] 
- 格式：[JSON/列表/代码/纯文本]
- 长度：[X字/X点/X行]
- 禁止：[不要寒暄/不要解释/不要总结]
[输入] 
[内容]

示例：

[角色] Python工程师
[任务] 重构以下代码
[约束]
- 格式：只输出代码块
- 要求：PEP8规范，添加类型注解
- 禁止：不要解释，不要注释，不要"以下是代码"
[输入]
def foo(x):
    return x+1

1.2 常用指令缩写对照表

完整表达	极简表达	节省
“你好，能不能麻烦你帮我…”	（直接删掉）	5-10 Tokens
“我希望你能作为一名专业的…”	“[角色] 你是…”	10-15 Tokens
“请帮我把下面这段中文翻译成英文”	“中译英：”	10-12 Tokens
“让文章更符合搜索引擎要求”	“SEO优化”	5-8 Tokens
“先分析…然后给出…最后提供…”	“分析→建议→代码：”	5-10 Tokens
“如果可以的话，麻烦…”	（直接删掉）	5-8 Tokens
“谢谢” / “感谢”	（直接删掉）	2-3 Tokens

1.3 符号替代连接词

自然语言	符号替代
“然后” / “接着”	→
“和” / “以及”	&
“或者”	|
“因为…所以…”	∵ ... ∴
“等于” / “结果是”	=
“例如”	eg.
“即” / “也就是说”	i.e.

---

二、输出端：严控格式模板

2.1 禁止废话预设（放入 System Prompt）

禁止以下输出：
- 寒暄语（"你好"、"很高兴帮助你"）
- 确认语（"好的"、"当然可以"、"没问题"）
- 过渡句（"让我来分析一下"、"以下是我的回答"）
- 总结语（"希望以上信息对你有帮助"、"如有问题请继续提问"）
- 解释过程（除非明确要求）

2.2 格式约束模板

# 只要结果
"只输出JSON，不要其他内容"
"只输出代码，不要解释"
"只给结论，不要推理过程"
"只输出最终答案，单位：[单位]"

# 限制长度
"限50字内"
"列出3点"
"一句话总结"
"每个要点不超过20字"

# 指定结构
"输出格式：{key: value}"
"用Markdown表格呈现"
"用无序列表，每项一行"

2.3 Stop 参数兜底

# Python 示例
response = client.chat.completions.create(
    model="gpt-4",
    messages=messages,
    stop=["\n\n", "END", "---"],  # 遇到这些序列立即停止
    max_tokens=200                 # 硬性上限
)

---

三、工程级优化清单

3.1 Prompt 缓存

 做：
- System Prompt 保持完全一致（无时间戳、无随机ID）
- 工具定义、角色设定等固定前缀不变
- 只变动 user 消息部分

 不做：
- 在 System Prompt 中插入动态变量
- 每次请求都修改固定前缀的任何字符

收益：缓存部分成本降低 90%+

3.2 模型路由决策树

用户请求
  │
  ├─ 是/否分类？ → 小模型（GPT-4o-mini / Qwen-Turbo）
  ├─ 简单翻译/提取？ → 小模型
  ├─ 代码生成？ → 中档模型
  ├─ 复杂推理/多步规划？ → 旗舰模型（GPT-4 / Claude 3 Opus）
  └─ 创意写作？ → 中档模型

收益：总成本降低 40%-70%

3.3 语义缓存

# 伪代码
def smart_query(user_input):
    embedding = get_embedding(user_input)
    cached = vector_db.search(embedding, threshold=0.95)
    if cached:
        return cached.answer  # 零 Token 返回
    else:
        result = llm.generate(user_input)
        vector_db.store(embedding, result)
        return result

收益：FAQ 类场景调用量减少 50%-60%

3.4 批量合并

#  10 次单独调用
for item in items:
    response = client.create(input=item)

#  1 次批量调用
response = client.batch_create(inputs=items)

收益：单位成本降低约 50%

---

四、场景专用模板

4.1 翻译任务

#  费 Token
"你好，能不能麻烦你帮我把下面这段中文翻译成英文，谢谢？"

#  省 Token
"中译英：[内容]"

# 进阶：指定风格
"中译英，正式商务风格：[内容]"
"英译中，口语化：[内容]"

4.2 代码生成

#  费 Token
"请帮我写一个Python函数，用来计算两个数的最大公约数，希望能用递归的方式实现，代码要简洁易懂"

#  省 Token
"Python递归GCD函数，只输出代码"

# 进阶模板
"[语言][功能]，[约束]，只输出代码"
# 例："Rust快速排序，无unsafe，只输出代码"

4.3 文本摘要

#  费 Token
"请阅读下面这篇文章，然后帮我总结一下它的主要内容和核心观点"

#  省 Token
"摘要，3点，每点≤20字：[内容]"

# 进阶模板
"摘要，[X]点，每点≤[Y]字：[内容]"

4.4 信息提取

#  费 Token
"请从下面的文本中提取出所有的人名、地名和时间，并以JSON格式返回"

#  省 Token
"提取人名/地名/时间，JSON：[内容]"

# 进阶：指定 Schema
"提取{name, location, date}，JSON：[内容]"

4.5 分类任务

#  费 Token
"请判断下面这条用户评论的情感倾向是正面、负面还是中性"

#  省 Token
"情感分类[正/负/中]：[内容]"

# 进阶：Few-shot（只留1-2个）
"分类[正/负/中]：
eg. '太棒了'→正
'很失望'→负
[内容]→"

4.6 RAG 问答

# System Prompt（缓存）
"基于以下材料回答问题。材料外知识不使用。无答案时回答'未知'。"

# User Prompt
"材料：[Top 3-5 相关片段]
问题：[用户问题]
回答：限50字"

---

五、穴居人模式（Caveman Mode）速查

适用于英文任务，极致省流：

# 规则
- 去掉冠词 a/an/the
- 去掉填充词 just/really/basically
- 去掉礼貌用语 please/thank you
- 使用电报式短句

# 对比
 "Could you please help me translate the following text into Chinese?"
 "Translate to Chinese:"

 "I would like you to write a Python script that can sort a list of numbers"
 "Python sort list:"

收益：英文 Token 减少 60%-70%

---

六、日常检查清单

每次发送 Prompt 前，快速过一遍：

• 删掉了”你好/请/谢谢/麻烦”等客套话？
• 删掉了”我希望你能…””如果可以的话…”等解释性文字？
• 用符号（→/:/-）替代了连接词？
• 用术语（SEO/GCD/JSON）替代了描述性文字？
• 指定了输出格式（JSON/代码/列表）？
• 限制了输出长度（X字/X点）？
• 在 System Prompt 中禁止了寒暄和废话？
• 设置了 stop 参数和 max_tokens？
• 固定前缀可以缓存？
• 是否可以用小模型完成？
• 是否可以批量合并请求？

---

七、收益速查表

技巧	预期节省	实施难度
删除客套话	5-15 Tokens/次
符号替代连接词	5-10 Tokens/次
禁止输出废话	30%-50% 输出
指定输出格式	50%-90% 输出
Stop 参数兜底	防止溢出
Prompt 缓存	90%+（缓存部分）
模型路由	40%-70% 总成本
语义缓存	50%-60% 调用量
批量合并	50% 单位成本
穴居人模式	60%-70% 英文

---

核心原则：最好的 Token 优化，是让模型一次就做对。一次成功的请求，胜过十次精打细算的重试。

---

结语

Token优化是一门兼具技术性和艺术性的学问。它要求我们深入理解模型的底层机制，同时具备工程实践的敏锐直觉。

回顾一下，核心要点可以概括为：

1. 理解本质：Token不是字，也不是词，而是分词算法的产物
2. 实测为准：不同模型、不同文本的Token消耗差异很大，不要凭直觉判断
3. 输入输出并重：输出Token通常更贵，控制输出比优化输入收益更大
4. 工程化思维：缓存、路由、批处理等工程手段的收益往往大于提示词本身的优化
5. 平衡为王：在成本、效果、效率之间找到适合你场景的平衡点

最后，记住一句话：最好的Token优化，是让模型一次就做对。 一次成功的请求，胜过十次精打细算的重试。

---

附录：常用工具与资源

A.1 Token计数器

• OpenAI Tokenizer：https://platform.openai.com/tokenizer
• Tiktoken：OpenAI官方Python库
• Hugging Face Tokenizers：支持多种模型的分词器

A.2 成本计算器

• OpenAI Pricing Calculator：官方定价计算器
• LLM Cost Calculator：第三方多模型成本对比工具

A.3 参考模型Token效率对比

模型	中文效率	英文效率	代码效率
GPT-3.5	1字≈1.5-2 Token	1词≈1 Token	中等
GPT-4	1字≈1.2-1.5 Token	1词≈1 Token	高
Claude 3	1字≈1.3-1.6 Token	1词≈1 Token	高
通义千问	1字≈1 Token	1词≈1.2 Token	中等
Llama 3	1字≈1.3-1.8 Token	1词≈1 Token	中等

注：以上数据为近似值，实际消耗因文本内容而异。

A.4 最后强调一点：Prompt发展到今天，随着模型的不断迭代，已经复杂到成为一种工程化的管理，任何理论是空洞的，不同模型的处理方式和表现也不同，要以实际测试效果为准。