大模型支持百万 Token 及使用技术说明

1. 百万Token 说明

大模型宣称的百万Token支持，是多轮对话的全上下文总容量，并非单个Prompt的额度，核心规则是：系统提示词 + 所有历史对话（用户提问+模型回复） + 当前Prompt + 模型待生成的输出，这几部分的Token总数，共同占用百万Token的窗口额度。http://www.cndba.cn/dave/article/131826

简单说，不是单条Prompt能塞100万Token，而是整个对话的“上下文账本”总规模上限为100万Token，这也是大模型长上下文的通用计算规则，从256K到100万Token，这个核心逻辑没有变化，只是总容量提升了。http://www.cndba.cn/dave/article/131826

一、百万Token窗口的完整计算范围（无例外，所有模型均遵循）

这是最容易踩坑的点，很多人会忽略系统提示词和历史对话的占比，具体包含4部分，全部计入总Token数：

系统提示词（System Prompt）：固定的指令类文本（如“你是一个AI助手，回答需专业简洁”），哪怕只有几百Token，也会占用基础额度；
多轮历史对话：从对话开始到当前的所有内容，包括每一轮用户说的话、模型对应的回复，是占比最高的部分；
当前Prompt：你当下发出的提问/指令；
模型输出：模型即将为你生成的回复内容。

以上4部分共享百万Token额度，输入类内容（1+2+3）占比越高，模型可生成的输出内容（4）就越少，反之亦然。比如百万Token窗口中，若输入类内容占了99万Token，模型最多只能生成约1万Token的回复。

二、实际多轮对话中的核心表现（结合百万Token的特点）

历史对话会持续累积：随着对话轮次增加，历史内容的Token数会不断叠加，直到接近百万上限；若继续发新Prompt，模型会自动截断最早的历史对话内容（保留最新上下文），以满足总额度限制，这也是所有长上下文模型的通用处理方式。
单条Prompt可占比极高（但非全部）：如果是单轮对话（无历史），当前Prompt可以接近百万Token（比如99万），剩下1万留给输出，这是单条Prompt能利用的最大额度，适合一次性上传整本书、大文档做分析（这也是百万Token的核心应用场景）。
部分模型的轻量优化不改变总规则：少数模型会对历史对话做无损/轻量压缩（比如对重复内容、冗余表述做Token精简），看似能容纳更多历史内容，但本质是“压缩后的数据占百万额度”，并非突破总容量，核心计算规则仍不变。

三、简单举例（直观理解百万Token的分配）

以某百万Token模型为例，窗口总容量=1,000,000 Token，实际分配场景：

场景1（单轮大文档分析）：系统提示词(1,000) + 无历史对话 + 当前Prompt(989,000) → 模型可输出(10,000) Token；
场景2（多轮深度对话）：系统提示词(1,000) + 历史对话(800,000) + 当前Prompt(189,000) → 模型可输出(10,000) Token；
场景3（短Prompt多轮闲聊）：系统提示词(1,000) + 历史对话(100,000) + 当前Prompt(1,000) → 模型可输出(898,000) Token（能生成超长回复）。

四、和256K Token模型的核心规则对比

从256K到100万Token，仅总容量提升，上下文计算规则完全一致，差异仅在：

256K模型：多轮对话容易快速触达上限，需要频繁截断历史，适合普通短对话、中小文档分析；
百万Token模型：多轮对话的“历史容纳能力”提升约4倍，也支持单轮超大Prompt的长文档处理，解锁全本书、代码库、海量日志分析等场景。

核心结论

百万Token的核心是“对话全生命周期的总上下文容量”，而非单条Prompt的额度；所有输入类内容（系统词+历史+当前Prompt）和输出内容共享该额度，这是大模型长上下文的底层设计逻辑，不会因容量从256K提升到百万而改变。

2. 使用技术说明

你的问题非常关键——“支持百万 token”已成为 2024–2026 年大模型宣传的核心卖点，但背后的技术路径差异巨大。下面我将以 具体模型为案例，从 计算方式、核心技术、训练策略、推理优化 四个维度，系统拆解不同厂商如何实现从 256K 到 1M+ token 的跨越。

一、Token 计算基础：什么是“100 万 token”？

英文：1 token ≈ 0.75 个单词（如 “unbelievable” → [“un”, “believ”, “able”]）
中文：1 token ≈ 1.3–1.8 个汉字（因 tokenizer 对常见词合并）
- 实测：《三体》全书约 90 万字 → 约 65 万 tokens
100 万 token ≈ 75 万英文单词 / 60–70 万汉字 ≈ 2000–3000 页 A4 文本

✅ 所以“百万 token”不是噱头，而是真实可处理整本书、大型代码库、多年财报的能力。

二、主流模型技术方案详解（按厂商分类）

1. Anthropic – Claude 3.5 Sonnet / Opus 4.6（100 万 token）

🔧 核心技术：

位置编码：ALiBi（Attention with Linear Biases）
http://www.cndba.cn/dave/article/131826
- 不使用 RoPE，而是在注意力分数中加入 与距离成正比的负偏置：
  score(i,j) = Q_i·K_j - m·|i−j|
- 优势：训练时用短上下文（如 8K），推理时可外推至 100 万 token 而不崩溃
- ALiBi 在长序列中避免了 RoPE 的周期性模糊问题
训练策略：两阶段微调http://www.cndba.cn/dave/article/131826
- 基座模型在 8K–16K 上预训练
- 长上下文能力通过 高质量长文档微调（法律卷宗、GitHub 仓库）获得
- 微调数据量小，成本可控
推理优化：
- 使用定制版 FlashAttention-2 + 内存分页（PagedAttention）
- 支持 提示缓存（Prompt Caching）：对重复系统提示/文档，缓存 KV Cache，降低 90% 成本

📊 效果：

在 “Needle in a Haystack” 测试中，100 万 token 下仍能准确召回中间位置信息（缓解“迷失在中间”问题）
定价：>200K token 时，输入 $6/百万，输出 $22.5/百万

2. Google – Gemini 1.5 Pro（100 万 token，实验支持 1000 万）

🔧 核心技术：

滑动窗口注意力 + 稀疏注意力混合
http://www.cndba.cn/dave/article/131826
- 全局注意力用于关键 token（如开头、结尾、指令）
- 局部使用 滑动窗口（Sliding Window），只关注邻近 256K token
- 结合 Ring Attention 实现多 GPU 分布式计算
位置编码：改进型 RoPE（YaRN 或 NTK-aware）http://www.cndba.cn/dave/article/131826http://www.cndba.cn/dave/article/131826
- 通过 动态缩放 RoPE 频率（NTK extrapolation）扩展有效长度
- 在 100 万 token 下仍保持位置区分度
训练架构：MoE（Mixture of Experts）
- 每个 token 只激活部分专家，降低计算密度
- 配合长上下文，实现高吞吐推理

📊 效果：

支持 多模态百万 token（文本+图像+音频）
在 100 万 token 下可完整分析 3 万行代码库或 10 小时视频元数据

3. 阿里云 – Qwen3-Max（100 万 token）

🔧 核心技术：

Chunk Flow 技术（阿里自研）http://www.cndba.cn/dave/article/131826
- 将长输入切分为 固定大小 chunk（如 8K）
- 每个 chunk 独立编码，再通过 跨 chunk 注意力融合 语义
- 类似“分段摘要 + 全局整合”，但端到端训练
PAI Flash Infer
- 阿里 PAI 平台的推理引擎，优化 KV Cache 存储
- 显存占用降低 60%，100 万 token 推理仅需 8×H800
MOE 架构 + Thinking 版本
- Thinking 版本在推理时生成 内部思维链（chain-of-thought），再输出答案
- 长上下文用于存储完整思考过程，提升复杂推理能力

📊 效果：

100 万 token 推理速度 68 秒，成本 0.3 元人民币
数学、代码任务表现突出（MATH 基准接近满分）

4. MiniMax – M1（100 万 token，开源）

🔧 核心技术：

闪电注意力（Lightning Attention）
- 自研注意力变体，结合 稀疏激活 + 动态路由
- 在生成 10 万 token 时，FLOPs 仅为 DeepSeek-R1 的 25%
MoE 架构
- 总参数 456B，每 token 激活 45.9B
- 支持 40K / 80K 思考预算（即 CoT 长度）
训练策略：
- 基于 MiniMax-Text-01 微调
- 使用 512×H800 训练 3 周，完成 RLHF

📊 效果：

唯一开源支持 100 万 token 的推理模型
在数学任务上全球第一，代码排名第 10（LMArena）

5. MIT / 学术界 – RLM（递归语言模型）

⚠️ 注意：RLM 不是新模型，而是一种 推理时策略（Inference-time Method）

🔧 核心思想：Prompt 即环境（Prompt as Environment）

不将百万 token 全部输入模型
而是把长文本存入 外部 REPL 环境（如 Python 变量）
模型作为 智能体（Agent），生成代码（如 context[10000:20000]）按需读取片段
支持 递归调用子模型（llm_query(sub_task)）

📊 优势：

绕过物理上下文限制：任何模型（GPT/Qwen/Claude）都可使用
抗上下文腐烂：只加载相关片段，避免注意力稀释
成本对数增长：输入越长，单位 token 成本越低

✅ 这是未来“超长上下文”的轻量化方向。

6. 智谱 AI – GLM-4 + Glyph 视觉压缩

🔧 Glyph 技术（创新路径）：

将超长文本 渲染为图像（类似 PDF 页面）
用 多模态大模型 读取图像，每个视觉 token 代表多个文字
实现 3–5 倍压缩率
- 例如：100 万字符 → 渲染为 20 万像素图像 → VLM 处理为 20 万 visual tokens

📊 效果：

让原本仅支持 128K 的模型“间接”处理百万级内容
特别适合 表格、代码、公式 等结构化文本

三、技术对比总结表

模型	上下文长度	核心技术	是否开源	特色
Claude 3.5	1M	ALiBi + Prompt Caching	❌	长上下文检索最强，编程体验好
Gemini 1.5 Pro	1M（实验 10M）	Sliding Window + Ring Attention	❌	多模态支持，企业级应用
Qwen3-Max	1M	Chunk Flow + PAI Flash Infer	❌（API 开放）	低成本（0.3 元/1M）、数学强
MiniMax-M1	1M	Lightning Attention + MoE	✅	唯一开源百万 token 推理模型
GLM-4 + Glyph	~1M（压缩后）	视觉 token 压缩	部分	跨模态压缩，适合结构化文本
RLM（通用方法）	无限（理论上）	外部化上下文 + Agent	✅	适用于任何模型，抗遗忘

四、为什么之前最大只有 256K？

硬件限制：256K 的注意力矩阵 ≈ 655 亿元素，需 ~130GB 显存（float16）
训练成本：长上下文训练需要更大 batch size 和更长 step，成本指数增长
算法瓶颈：RoPE 在 >50K 后位置编码失效，模型“记不住顺序”

而如今通过 ALiBi、FlashAttention、Ring Attention、MoE、视觉压缩、RLM 等技术，绕过了原始 Transformer 的 O(n²) 瓶颈，才让百万 token 成为可能。

五、开发者建议

若需 高可靠长上下文：用 Claude 3.5 API
若需 低成本本地部署：尝试 MiniMax-M1（INT4 量化版 250GB）
若处理 代码/数学：Qwen3-Max 或 DeepSeek-R1
若想 自己实现超长上下文：采用 RLM 框架 + vLLM + PagedAttention

签到成功

CNDBA社区