小明：最近在研究长文档处理，发现Gemini 1.5 Pro能处理100万token？这也太夸张了吧，其他模型128K就已经很吃力了。
小林：确实夸张，但不是玄学。你先想一个问题——标准Transformer的注意力复杂度是多少？
小明：O(n²)吧。
小林：对。那从4K涨到1M，计算量涨多少？
小明：我算算……(1000000/4000)² = 62500倍？？？
小林：所以啊，直接硬算根本不现实。Gemini能做到，是因为它在架构、分布式、训练三个层面都做了特殊处理。我们一个一个拆。
第一关：架构——MoE稀疏激活
小明：那它到底用了什么架构？
小林：核心是 MoE（Mixture of Experts），混合专家。你知道这个吗？
小明：知道个大概，就是有很多「专家网络」，每次只激活其中几个？
小林：没错。你想象一个这样的结构：
输入token
│
▼
┌──────────┐
│ Router │ ← 路由器决定这个token该交给谁
└────┬─────┘
│
├──→ Expert 1 ✓ 选中
├──→ Expert 2 ✗ 休眠
├──→ Expert 3 ✗ 休眠
├──→ Expert 4 ✓ 选中
└──→ Expert N ✗ 休眠
最终输出 = Expert1结果 × 权重 + Expert4结果 × 权重
小明：所以参数量很大，但实际计算量不大？
小林：对。假设有64个专家，每次只激活2个，那实际计算量只有全参数模型的 2/64 ≈ 3%，但模型的容量和表达能力接近64个专家的总和。这就是用参数量换计算效率。
小明：那这对长上下文有什么帮助？
小林：两方面。第一，计算量可控，100万token不至于把显卡算爆。第二，不同专家可以专门处理不同类型的上下文模式——有的专家擅长局部语法，有的擅长长距离依赖，有的擅长跨段落推理。分工协作。
第二关：注意力——GQA + 位置编码
小明：MoE解决了计算量的问题，但注意力本身的O(n²)还是在吧？
小林：在，但还有一个隐形杀手你可能没想到——KV Cache。标准Multi-Head Attention里，每个头都有独立的K和V。假设32个头，100万token，每个K/V向量128维，fp16精度：
小明：我算算……32 × 1000000 × 128 × 2 × 2字节……大约16GB，光存KV就一张卡没了。
小林：所以Gemini用了 Grouped-Query Attention（GQA）：
# 标准 Multi-Head Attention
Q_heads = 32
K_heads = 32 # 每个Q头配一个K头
V_heads = 32
# KV Cache: 32组
# Grouped-Query Attention (Gemini的做法)
Q_heads = 32
K_heads = 8 # 4个Q头共享1个K头
V_heads = 8 # 同上
# KV Cache: 8组，直接砍掉75%
小明：4个Q头共享一个K头，精度不会掉吗？
小林：会有微小的精度损失，但Google的实验表明，在长上下文场景下这个trade-off非常值得。显存省下来的上下文长度，远比精度损失的价值大。
小明：有道理。那位置编码呢？100万token的位置怎么编码？
小林：这个更有意思。Gemini用的是 RoPE（旋转位置编码） 的扩展版本。
小明：RoPE我知道，通过旋转矩阵编码相对位置。但它不是有个频率基线 theta = 10000 吗？超出训练长度就失效了吧？
小林：所以要做频率扩展。核心思路：
# 原始RoPE
theta_i = 10000^(-2i/d) # 固定基线
# 长上下文扩展（类NTK-aware方法）
theta_i = (10000 * scale)^(-2i/d) # 放大基线
# 效果：低频分量（负责长距离）被拉伸
# 高频分量（负责局部）保持不变
小明：就是说……通过调一个参数，就能让模型「外推」到更长的序列？
小林：对，而且不需要从头训练。在原有checkpoint上微调就行，成本低很多。
第三关：Ring Attention——分布式才是真正的杀招
小明：等等，就算GQA把KV Cache砍了75%，100万token还是装不下一张卡吧？
小林：装不下。所以真正的关键不是「单卡能装多少」，而是能不能分摊到多张卡上。这就是 Ring Attention 的作用。
小明：这是什么？
小林：你想象一个场景——4张GPU，每张卡负责25万token的子序列。标准做法需要所有token的K、V同时在一张卡上，这不可能。Ring Attention的思路是：
初始状态:
GPU-0 持有: Q[0..250K], K[0..250K], V[0..250K]
GPU-1 持有: Q[250K..500K], K[250K..500K], V[250K..500K]
GPU-2 持有: Q[500K..750K], K[500K..750K], V[500K..750K]
GPU-3 持有: Q[750K..1M], K[750K..1M], V[750K..1M]
第1轮: 各GPU用本地K,V计算部分注意力
→ 同时把K,V块发给下一个GPU（环形传递）
第2轮: 每个GPU收到上一个GPU的K,V块
→ 用新收到的K,V计算注意力，累加结果
→ 继续把K,V发给下一个GPU
...循环4轮后...
所有GPU都「见过」所有K,V → 注意力计算完成
小明：所以每张卡只需要存一份K、V，不需要全部？
小林：对！显存占用从 O(n) 变成 O(n/p)，p是GPU数量。4张卡就能处理4倍的上下文长度。理论上，上下文长度可以随GPU数量线性扩展。
小明：那通信开销呢？每轮都要传K、V，不会很慢吗？
小林：这是Ring Attention最巧妙的地方——计算和通信可以重叠。当GPU-0在用本地K,V计算注意力的时候，同时在后台把K,V发给GPU-1。等计算完了，下一块K,V也传过来了。几乎不增加额外延迟。
小明：所以Gemini的100万token，本质上是靠Google的TPU集群撑起来的？
小林：没错。这不是单卡能力的突破，是系统工程。Google有TPU v5p集群，几千张卡连在一起，Ring Attention往上一跑，100万token自然就出来了。
第四关：训练——怎么教会模型读长文
小明：架构和分布式都OK了，但模型得会用吧？直接拿100万token的数据训练？
小林：那训练直接崩了。Google用的是渐进式上下文扩展：
阶段1: 4K → 学语言基础
阶段2: 32K → 学中等距离依赖
阶段3: 128K → 学长文档理解
阶段4: 1M → 超长序列微调
每个阶段复用上一阶段的checkpoint
小明：为什么不直接上1M？
小林：两个原因。第一，梯度稳定性——超长序列的梯度传播路径太长，容易梯度消失或爆炸。渐进式训练让模型先学会短距离依赖，再逐步扩展。第二，位置编码泛化——RoPE的频率扩展需要模型在不同长度上都有经验，渐进式训练自然覆盖了各个尺度。
小明：那训练数据呢？100万token的高质量文档应该很稀缺吧？
小林：确实。Google用了一些trick：
- 语义拼接：把相关的短文档按主题拼成超长文档
- 层次化采样：在句子、段落、章节、文档不同粒度采样
- 合成任务：比如在长文档中随机插入关键信息，训练模型检索
小明：相当于自己造数据？
小林：对。而且RLHF阶段也专门针对长上下文做了优化——训练reward model识别「能在长文档中准确引用信息」的回答，惩罚幻觉和遗漏。
实际表现：真的好用吗？
小明：说了这么多原理，实际效果怎么样？
小林：有个经典测试叫 Needle In A Haystack（大海捞针）——在100万token的不同位置插入一条关键信息，然后让模型找出来。Gemini 1.5 Pro的结果：
插入位置: 开头 25% 50% 75% 末尾
准确率: 99.7% 99.2% 98.8% 99.1% 99.6%
几乎没有 "Lost in the Middle" 问题
小明：50%的位置也有98.8%？其他模型不是在中间位置会断崖式下降吗？
小林：这就是多方面技术叠加的效果。MoE让不同专家专注不同位置模式，GQA减少了注意力头的冗余，Ring Attention让每张卡都能看到全局信息。不是靠单一技术，是系统性的胜利。
但是，别神化
小明：听起来Gemini在长上下文上已经无敌了？
小林：别急，有几个局限得说清楚：
- 成本高：100万token的推理成本是128K的几十倍，不是所有场景都值得
- 延迟高：首次处理超长文档的TTFT（首token时间）明显更长
- 不是越长越好：很多任务合理的RAG + 短窗口反而更高效
- 复杂推理仍有衰减：NIAH是简单检索任务，真正的复杂推理（跨文档因果分析）准确率还是会下降
小明：所以长上下文不是银弹？
小林：从来都不是。关键不是能装多少，而是装进去之后还能不能用好。Gemini的回答是：可以，但代价不低，要看场景。
总结
小明：最后帮我总结一下，Gemini的长上下文到底靠什么？
小林：一张表搞定：
| 层面 | 关键技术 | 解决什么问题 |
|---|---|---|
| 架构 | MoE稀疏激活 | 参数大但计算可控 |
| 注意力 | GQA + RoPE扩展 | 省显存 + 位置外推 |
| 分布式 | Ring Attention | 多卡分摊，线性扩展 |
| 训练 | 渐进扩展 + 长文档对齐 | 训练稳定 + 检索精准 |
本质是架构、基础设施、训练策略的三重突破，不是单一技术的功劳。
参考文献：
- Gemini 1.5 Technical Report (Google DeepMind, 2024)
- Ring Attention with Blockwise Transformers (Liu et al., 2023)
- GQA: Training Generalized Multi-Query Transformer Models (Ainslie et al., 2023)
- Lost in the Middle: How Language Models Use Long Contexts (Liu et al., 2023)
KULAAI(k.kulaai.cn)
