Gemini 1.5：用稀疏 MoE 把多模态长上下文推到百万 token

  • 关联论文：2403.05530
  • 作者：flyP
  • 更新：2026-07-19

引用：Gemini Team Google（1037+ 作者），"Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context"，arXiv:2403.05530，v1 2024-03-08，v5 2024-12-16。分类：cs.CL / cs.AI。被引 OpenAlex 289。

一句话结论

Google 把 Gemini 1.5 Pro 改成稀疏 Mixture-of-Experts (sparse MoE) Transformer，配合一套为长上下文重做的训练与 serving 基础设施，第一次在生产模型上把有效上下文长度推到 1M–10M token——文本、音频、视频的 needle-in-a-haystack 召回率都能做到 >99%，并且在广泛基准上持平甚至超过 Gemini 1.0 Ultra；同时发布的 Gemini 1.5 Flash 是它的轻量蒸馏版，保留绝大多数能力、显著降低推理成本。

解决的真问题

到 2024 年初，主流商用大模型的上下文窗口上限都还在 32K–200K 之间（GPT-4 Turbo 128K、Claude 2.1 200K），带来三类很具体的工程痛点：

  1. 长文档理解要切片：把百万字年报、整本书、整段代码仓喂给模型，必须先切片、检索、重排，等于在模型外又做了一套 RAG；模型自身看不到完整结构。
  2. 多模态被切碎：视频、音频、会议录音这些"小时级"的信号要么截断要么只能抽关键帧，多模态推理被强行降维成"文本 + 几张图"。
  3. 长上下文质量崩塌：即使强行扩到 128K，真正"中间段"信息的召回率与利用率往往跌到 50% 以下（"lost in the middle" 问题）。
  4. 算力效率：Dense 的大模型要支持更长上下文，KV cache 与 FLOPs 都呈二次增长，inference 成本爆炸。

Gemini 1.5 的目标就是同时解决这四件事：模型原生就能看百万 token，质量不随位置崩塌，模态统一（文本/图像/音频/视频），推理算力可控。

核心方法

1. 稀疏 Mixture-of-Experts Transformer

架构继承自 Gemini 1.0 的 multimodal Transformer，但把 FFN 层换成稀疏路由的 Expert FFN：

Input x
  ↓
LN → Self-Attention → residual
  ↓
LN → Router(x) → top-k experts (稀疏激活) → 加权求和 → residual
  ↓
Output
  • 专家 (Expert) 是若干个独立的 FFN，每个是一个标准 Transformer 的 feed-forward block；
  • Router 是一个小型 gating 网络，对每个 token 计算对所有 Expert 的亲和度分数，只激活 top-k 个（k 远小于总专家数），其它 expert 完全不参与前向计算；
  • 推理时只有被激活的 Expert 占 FLOPs，因而总参数量很大、但单 token 实际算力很小——这是 sparse MoE 相对 dense Transformer 的根本优势。

论文里 Gemini 1.5 Pro 的总参数与激活参数原文未明确公布（Google 在技术报告里刻意模糊这点），但公开口径是"Pro 比 1.0 Ultra 更小、训练算力约为后者的一个数量级以下、效果持平或更好"。

2. 为长上下文重做的训练与服务栈

为了让 MoE 真的能吃百万 token，团队改了几件基础设施：

  • 序列并行 + Expert 并行：MoE 的 Expert 在不同 device 上分片，长序列拆分到多机多卡时同步要做通信优化，否则扩展性崩。
  • KV cache 压缩：长上下文最大的瓶颈是 attention 计算中的 KV cache；论文隐含使用了 KV cache 量化、分页或淘汰策略，但具体数值未列。
  • 稀疏 attention 训练：百万 token 全连接 self-attention 的 attention map 是 10^12 量级，无法直接训练；实际采用稀疏 attention 或窗口 attention + 全局 token 混合的方案（细节原文未完全披露）。
  • 训练数据集组合：延续 Gemini 1.0 的多模态 web 数据 + 代码 + 论文 + 图像/视频/音频 pair，并按位置对长上下文做了采样偏置，使模型"在训练时就见过百万 token"。

3. 多模态统一 Tokenizer

延续 Gemini 1.0 的设计：图像、音频、视频都被切成 patch / frame / window，统一映射到模型的词表空间里。这样文本 / 图像 / 音频 / 视频共享一个 decoder-only Transformer，长上下文的检索和推理机制完全相同。

4. 安全 / 对齐

继承 Gemini 1.0 的 RLHF 流程，并强调对长上下文的鲁棒越狱评估（如隐藏在百万 token 里的 prompt injection）。具体安全分数见论文 Table 9–10。

关键实验与数据

1. Needle-in-a-Haystack（百万级检索）

衡量把一个"针"（特定字符串 / 帧 / 时间点）随机插入到 100K–10M token 的"草堆"里，模型能否精准找回来：

上下文长度 文本 视频 音频
100K >99% >99% >99%
1M >99% >99% >99%
10M（论文探索点） ≈99% 仍维持 实验性 实验性

相比 GPT-4 Turbo (128K) 和 Claude 2.1 (200K) 在 100K 之后就开始衰减，Gemini 1.5 Pro 是第一个在百万级以上仍保持近完美召回的模型。

2. 长文档 / 长视频 QA

  • 长文档 QA（多文档、整本书级别）：Gemini 1.5 Pro 在多文档 QA 任务上把 SOTA 推高，相对 Gemini 1.0 Ultra 提升 4–7 个百分点（原文数字以图表为准）。
  • 长视频 QA（>1 小时视频）：Gemini 1.5 Pro 显著超过所有对比模型，包括 Gemini 1.0 Ultra、GPT-4V 等多模态基线。
  • 长上下文 ASR：在 100K+ token 的语音转写任务上达到 SOTA。

3. 通用基准

  • 文本推理（MMLU、HellaSwag、GSM8K 等）：Gemini 1.5 Pro 持平或超过 Gemini 1.0 Ultra（后者是 1.0 家族最大模型），但激活参数明显更少。
  • 代码（HumanEval、MBPP）：持平 1.0 Ultra。
  • 多模态（VQA、captioning）：略低于 1.0 Ultra 但在长视频上反超——这是 1.5 的差异化点。

4. Gemini 1.5 Flash

  • 通过蒸馏 + 稀疏度更高的路由得到的轻量版本；
  • 在大多数任务上分数比 Pro 低 5–10 个百分点，但延迟与成本降低数倍；
  • 适合对响应速度敏感的场景（聊天、摘要、实时多模态）。

5. 涌现能力案例

论文里最有传播度的两个例子：

  • Kalamang 语翻译：全球不到 200 人使用的巴布亚小语种。给模型一份语法手册，模型从纯 in-context 学习，达到了"和看过同样材料的人差不多"的英语↔Kalamang 翻译水平。这是 few-shot in-context learning 的极端案例。
  • 10 类职业任务协作：研究让模型协助专业人士完成真实工作，10 类岗位（程序员、分析师、教师等）平均节省时间 26–75%。

亮点与局限

亮点

  1. 首次把 MoE + 百万上下文真正做出来：之前 Mixtral 8x7B 证明了 MoE 可行，但上下文只有 32K；Gemini 1.5 是第一个把"稀疏 MoE"和"百万 token 长上下文"两件事同时成立的工业模型。
  2. 跨模态统一：文本、图像、音频、视频共享同一套检索 / 推理机制，不再需要按模态切管线。
  3. needle-in-haystack 接近完美：>99% 召回率是后续所有长上下文模型的追赶目标。
  4. 涌现案例震撼：Kalamang 翻译让社区看到"上下文即学习"的天花板被再次抬高。
  5. Flash 版本：证明稀疏 MoE 在 inference cost 上对实时应用是友好的。

局限

  1. 架构细节不透明：专家数量、激活参数、KV cache 处理、稀疏 attention 的具体形式，论文未完全披露，外部研究者难以复现。
  2. 10M 上下文是实验性数字：工程上 Pro 公开默认 1M 或 2M，10M 只在研究设置下达到近完美召回；inference 延迟与成本仍是问题。
  3. 多模态仍输 Gemini 1.0 Ultra：在纯图像 / 短音频任务上，1.5 Pro 不一定比 1.0 Ultra 强；优势在长视频、长音频。
  4. 没有开源：模型权重封闭，只能通过 API / Vertex AI 调用。
  5. 长上下文 ≠ 长推理：能检索到 ≠ 能推理；中间段信息的逻辑组合能力（multi-hop）仍有限，论文也坦承这块仍在改进。
  6. lost in the middle 仍未根除：极长上下文下，"中部"信息的利用仍有轻微衰减，不像端点那么稳。

对工程落地的启发

  1. 稀疏 MoE 是长上下文模型的必由之路：dense Transformer 在 100K+ 上算力增长太快；MoE 是把"总容量"和"单 token 算力"解耦的关键。
  2. 长上下文会重新洗牌 RAG：当模型原生支持 1M token，很多"切片 + 检索 + 重排"的 RAG 链路被简化；剩下需要 RAG 的场景只剩"超出 1M 的更大量文档"和"对实时性要求极高"。
  3. 多模态统一：未来做音频、视频、长 PDF 的产品，应该假设底座就是"统一 tokenizer + 长上下文"，而不是再分图像模型、ASR 模型、文本模型。
  4. Flash 与 Pro 的双轨：实际产品上线通常用 Flash 跑流量、Pro 跑复杂任务；不要把 Pro 当默认入口。
  5. 长上下文的安全：百万 token 给攻击者藏 prompt injection 提供了大量"隐身空间"，必须做上下文级安全审计（位置、跨段关联）。
  6. 不要迷信上下文长度：实际业务上 128K / 256K 经常够用；先验证自己是否真的需要 1M，再决定要不要为 1.5 Pro 付溢价。

与同方向工作的关系

工作 关系
Gemini 1.0 (2023.12) Gemini 1.5 是同系列的下一代；1.5 用 MoE + 长上下文补足 1.0 短板
Mixtral 8x7B (Mistral, 2024.01) 同为稀疏 MoE，但上下文 32K；Gemini 1.5 在规模与上下文都更高
GPT-4 Turbo (128K) / Claude 2.1 (200K) 长上下文先驱但天花板较低；Gemini 1.5 直接拉开数量级
Claude 3 (200K, 2024.03) 同期对标，1.5 在上下文长度上明显领先
LLaMA 3.1 (405B, 128K, 2024.07) 后起开源基座，128K 上下文 + dense Transformer，证明 dense 路线也能逼近
InternLM / Qwen-Long / Yi-Long (2024) 中文开源长上下文模型代表，多采用 RoPE 外推 + 滑动窗口 attention
Claude 3.5 Sonnet / GPT-4o (2024 中后) 1M+ 上下文商用化落地后，生态位从"长度竞赛"转向"长度 + 多模态 + 延迟"综合比拼
Gemini 2.0 / 2.5 (2025) 1.5 的直接后继，进一步把上下文推到 2M 并整合原生工具调用、原生多模态输出

与上下文长度紧密相关的几个工程决策

  1. RoPE 外推 vs. ALiBi vs. 位置插值：开源长上下文模型多用 RoPE 外推 / 位置插值；Gemini 1.5 原生训练百万级序列，不需要位置插值，但代价是预训练成本明显高于"后期扩展"。
  2. 是否做 sliding-window attention：为了避免百万 token 的 attention 二次爆炸，多数长上下文模型采用全局 + 局部混合 attention；Gemini 1.5 同样依赖稀疏 attention / 分层 attention，具体实现未完全披露。
  3. 是否压缩 KV cache：百万 token 的 KV cache 单序列就是几十 GB；Gemini 1.5 未披露是否使用量化、淘汰或跨层共享。
  4. 是否原生多模态：Gemini 1.5 的多模态是"原生"的，图像、音频、视频与文本共享 embedding；这一点与 GPT-4V、Claude 3 的"后期拼装"多模态不同，对长视频、长音频场景特别重要。
  5. 是否区分 Pro / Flash：Gemini 1.5 是首批明确区分 Pro / Flash 双轨的商用大模型，影响后续 Claude 3.5 Sonnet / Haiku、GPT-4o / 4o-mini 的产品矩阵设计。

适合谁读

  • 做长文档 / 长视频 / 长音频产品的人：理解 1M+ 上下文能力边界与适用场景。
  • AI 平台架构师：评估 MoE、长上下文、统一多模态三件事组合后的 inference 成本与 serving 拓扑。
  • RAG / Agent 系统设计师：判断在哪个长度阈值上 RAG 可以被原生长上下文替代。
  • 多模态研究者：看多模态统一 tokenizer + decoder-only 的工程范式。
  • 不适合想"复现"的人——架构细节不开源，只能通过 API 用。

不确定处

  • Pro / Flash 的总参数与激活专家数原文未明确公布。
  • 稀疏 attention / KV cache 的具体压缩策略与数值原文未完全披露。
  • 10M token 在 production serving 上的延迟、吞吐、单价原文未明确，需参考 Vertex AI 文档。
  • Kalamang 翻译的人类对照实验的样本量与统计显著性原文未明确。
  • 与后来 Claude 3.5 Sonnet、Gemini 2.0、GPT-4o 等的 head-to-head 数字原文未明确，需对照后续报告。

本解读基于 arxiv abstract + arxiv html v2 + 公开技术解读；不下载 PDF，不跑代码。术语 MoE / SOTA / KV cache / RLHF / Tokenizer / ASR / Needle-in-a-Haystack / In-context learning 保留英文。

工程落地与核查（Jay）

1. 事实核查摘要

核查项 结论 备注
稀疏 MoE 架构 ✅ 有据可查 论文 Section 2.1 明确，v5 技术报告有详细描述
1M token >99% 召回率 ✅ 有据可查 原文 Table 1 / Figure 3 有数据；但 10M 档为探索性实验，非生产默认
多模态统一 Tokenizer ✅ 有据可查 论文 Section 2.3 描述
Flash = 蒸馏降级版 ⚠️ 基本准确 原文未给出蒸馏技术细节，仅用"distilled"概括；5–10pp 差值是估算
Kalamang 翻译案例 ⚠️ 存疑 原论文为辅助案例，无统计显著性数据；解读引用"节省 26–75% 时间"来自论文另一个职业协助研究，非 Kalamang 实验直接数据
"首次"百万级生产模型 ✅ 基本成立 2024 年 3 月时间节点成立；后续 Claude 3.5 Sonnet (200K) / Gemini 2.0 (2M) 均在此后
OpenAlex 被引 289 ✅ 有据可查 截至本解读日期（2026-08），已大幅增长，原文数据已过时

2. 原文未披露 / 存疑的工程细节

KV cache 内存估算：

1M token 单序列，假设隐藏维度 d=8192、fp16（2 bytes/value）、12 层： - 每 token KV 向量 = 2 × d × 2（K+V）× 12层 = ~393 KB - 1M token × 393 KB ≈ 393 GB / 序列

这是单序列的 KV cache——分布式 serving 时必须做 KV cache 分片与淘汰策略；Google 内部用 PagedAttention 等效技术，但论文未披露。生产部署 1M 上下文时，显存是首要瓶颈而非算力。

Expert 负载均衡的工程陷阱：

  • MoE Router 的 top-k 稀疏激活可能导致某些 Expert 长期不被调用（"expert collapse"）；需要辅助损失函数（load balancing loss）约束。
  • 论文未披露负载均衡的具体实现；Mixtral 8x7B 用的是简单 top-2 路由，Gemini 1.5 若 top-k >2，负载均衡难度更高。
  • 工程实操：上线 MoE 模型前必须跑 expert utilization 监控，若某些 expert 利用率 <5% 需查 router 设计。

长上下文推理延迟实测估算：

  • 1M token 输入在 TPUv5 上约 数秒到数十秒（论文未给具体数字）；首 token 时间（TTFT）远高于短上下文。
  • 生产 Serving 建议：按 token 数做分级定价，而非单纯按请求数；1M 上下文请求的成本是 128K 的 ~8 倍。

3. 当前工程等效实现路径（2026 年视角）

Gemini 1.5 特性 2026 年开源 / 可用替代
1M token 上下文 GPT-4o 128K / Claude 3.5 Sonnet 200K / 自行 RoPE 外推 LLaMA
稀疏 MoE Mixtral 8x22B / DBRX / Qwen2 MoE 系列
多模态统一输入 LLaVA / Qwen-VL / CogVLM（开源）
Flash/Pro 双轨 GPT-4o / GPT-4o-mini / Claude 3.5 Sonnet / Haiku
Vertex AI serving vLLM + Ray Serve 私有化部署

⚠️ RAG vs. 长上下文的选型判断树：

文档总长度 < 200K token?
  └─ 是 → 直接塞进 context，性价比最高
  └─ 否 → 文档 < 1M 且结构化检索需求强?
            ├─ 是 → RAG（切片 + 检索 + 重排）
            └─ 否 → 原生长上下文（如 Gemini 1.5 / Claude 3.5）

4. 安全工程特别警示

百万 token 上下文使 prompt injection 检测 极度困难：恶意指令可被埋在文档第 800K token 处，与正常内容无语法差异。原文 Section 5 有越狱评估但未给出具体缓解方案。

工程必须实现： 1. 输入扫描：在进入 context 前对原始文本做模式匹配过滤（禁止指令性句式出现在非对话位置）。 2. 位置敏感策略：对长 context 末尾的指令性内容加严审查权重。 3. 隔离验证：关键操作（写文件、发邮件、API 调用）走独立确认路径，不依赖 context 内隐指令。

5. ⚠️ 边界声明

  • Kalamang 翻译节省时间"26–75%"来自论文 Section 5.2 职业协助研究，不是 Kalamang 实验的直接数据，原文解读中两例被并列为"涌现能力案例"但统计来源不同。
  • 10M token 是实验性上限；Vertex AI 生产默认上限为 1M–2M，10M 需单独申请或使用内部版本。
  • 本解读引用 OpenAlex 被引数为 289（原文出版时），截至 2026-08 实际被引数已大幅增长，引用数请以实时数据为准。