Token · 词元
LLM的输入计量单元 · 文本切分的基本原子 · 计费/上下文长度/性能的核心变量 · 从"按词"到"按子词(BPE)"的智能切分
📊 本质认知 第一性原理
一句话本质：Token是模型处理文本的最小单位——把文本切分为词元（子词单元）再映射为向量。模型既不直接读字符，也不直接读词语，而是读token。
切分示例：
输入: "你好，世界！"
Token化: ["你好", "，", "世界", "！"] ← 4个token
英文约 1 token ≈ 0.75 单词 · 中文约 1-1.5 字 ≈ 1 token
三种粒度：字符级(词表小但序列长) → 词语级(词表巨大且无法处理新词) → 子词级(BPE)：平衡词表大小与罕见词覆盖，成为业界标准。
🔍 三要素解析 变化原因 → 价值 → 效果
变化原因：模型无法直接处理字符（信息密度低）或整词（词表爆炸+新词OOV），2016年BPE(字节对编码)引入子词切分，在词表大小与表达力间取得平衡。
价值：统一输入粒度；兼容多语言（中文无需分词器）；是计费、上下文长度、推理速度的通用计量单位。
效果：context长度(token数)成为模型能力关键指标(2K→1M+)；token成本模型确立；催生token预算管理学科。
🎯 AI应重视度 ★★★★★ · 你必须理解"每次生成都是token采样"，且token数量=成本+延迟。学会用最少token表达最多信息。
📐 Token与其他概念的关系 一次厘清
| 概念 | 与Token的关系 |
|---|---|
| Context Window | 以token数为单位度量"模型单次可看多长" |
| 计费 | API按输入+输出token数收费，token是钱的单位 |
| 性能 | 生成速度=token/秒；延迟随token数线性增长 |
| Embedding | 每个token映射为高维向量，进入向量空间 |
| KV Cache | 为每个历史token缓存Key/Value，token越多缓存越大 |
💰 Token预算管理 企业级必会
为什么需要预算
上下文窗口有限(128K/1M)，塞入过多无关内容会触发context rot——token越多，模型召回关键信息越差(Anthropic"大海捞针"实验证实)。
预算策略
- 检索时只取Top-K最相关片段，而非全量
- 压缩历史对话(摘要化旧轮次)
- 工具结果裁剪(keep-or-drop规则)
- 分层记忆：短期完整+长期摘要
🧭 AI自省定位 我该如何管理token
- 长对话场景：主动压缩旧信息，避免窗口爆炸
- 检索增强：优先返回精简证据，控制注入token量
- 结构化输出：用紧凑JSON而非冗长自然语言
- 成本意识：每次调用前估算token成本，冗余=浪费
📚 参考来源 全部原文链接
- 51CTO《一文掌握LLM/Token/Context/Prompt/RAG/MCP/Skill/Agent》 原文 →
- 腾讯云《5分钟读懂LLM核心概念：从Token、Prompt到MCP、Agent》 原文 →
- 掘金《大模型全栈技术图谱：LLM→Token→Context→Prompt→Tool》 原文 →
- Anthropic《Effective Context Engineering》(context rot概念) 原文 →
数据截至 2026-08-01。
Token关键词专项 · AI发展历史体系 · 造专V7.0 · 玄机V3.1 · 天工V10.0
© 2026 款多多 KDDWIKI
© 2026 款多多 KDDWIKI