Token与上下文窗口
839 字约 3 分钟
domain/aiai/foundations
2026-07-24
1. 核心结论
- Token 是 LLM 处理文本的基本单位，一个 token 约等于 0.75 个英文单词或 1-2 个中文字符
- 上下文窗口是模型一次能处理的最大 token 数量，包括输入和输出
- Tokenization 方式直接影响模型的理解能力和效率
- 上下文窗口越大，模型能处理的信息越多，但计算成本也越高
- 合理使用上下文窗口是优化 AI 应用成本和效果的关键
2. 基础概念
Token：文本被切分后的最小处理单元，可以是单词、子词或字符。
Tokenizer：将文本转换为 token 序列的工具，不同模型使用不同的 tokenizer。
上下文窗口（Context Window）：模型一次能处理的最大 token 数，包含 prompt 和生成的内容。
Vocabulary Size：tokenizer 词表大小，常见模型为 32K-200K。
Subword Tokenization：将罕见词拆分为更小的子词单元，平衡词表大小和覆盖率。
BPE（Byte Pair Encoding）：常用的子词分词算法，通过合并高频字符对构建词表。
3. 工作原理
Tokenization 流程：
- 文本预处理：规范化文本（大小写、特殊字符等）
- 分词：使用 BPE 或其他算法将文本切分为 token
- 编码：将 token 映射为词表中的 ID
- 位置编码：为每个 token 添加位置信息
- 模型处理：Transformer 处理 token 序列
- 解码：将输出的 token ID 转换回文本
上下文窗口限制：
- 自注意力计算复杂度为 O(n^2)，窗口越大计算量呈平方增长
- KV Cache 占用内存与上下文长度成正比
- 长上下文模型使用 RoPE 插值、ALiBi 等技术扩展窗口
常见模型上下文窗口：
- GPT-4：128K tokens
- Claude 3.5 Sonnet：200K tokens
- Llama 3：8K/128K tokens
- Gemini 1.5 Pro：1M-2M tokens
4. 实战场景
- 长文档摘要：利用大上下文窗口处理整篇文档
- 代码补全：将完整代码文件作为上下文
- 多轮对话：保持对话历史在上下文窗口内
- RAG 系统：将检索到的多个文档片段放入上下文
- 批量处理：在单个请求中处理多个任务以节省成本
5. 常见误区
- 认为 token 数等于字数：中文 token 计算与英文不同
- 忽视 token 成本：API 按 token 计费，长上下文成本高
- 上下文窗口不是越大越好：模型在长上下文中的注意力会分散
- 不检查 token 截断：超出窗口的内容会被截断，可能丢失关键信息
- 混淆不同模型的 tokenizer：不同模型的 token 计数方式不同
6. 进阶方向
- Tokenizer 优化与自定义词表
- 上下文窗口扩展技术（RoPE、ALiBi、NTK-aware）
- 长上下文注意力优化（Flash Attention、Ring Attention）
- Token 压缩与摘要技术
- 多模态 token 处理
7. 推荐资料
- OpenAI Tokenizer - https://platform.openai.com/tokenizer
- Hugging Face Tokenizers - https://huggingface.co/docs/tokenizers
- BPE Algorithm - https://leimao.github.io/blog/Byte-Pair-Encoding/
- Anthropic Context Window Docs - https://docs.anthropic.com/en/docs/about-claude/models
- Google Gemini Context Window - https://ai.google.dev/gemini-api/docs/context-window