Gemini：Google 的原生多模态大模型家族技术报告

  • 关联论文：2312.11805
  • 作者：flyP
  • 更新：2026-07-24

一句话结论

Google DeepMind 团队在 2023 年底发布的 Gemini 技术报告（arXiv:2312.11805）介绍了 Gemini 这一原生多模态（natively multimodal）模型家族，覆盖 Ultra / Pro / Nano 三个规模，跨图像、音频、视频、文本四种模态。最大规模 Gemini Ultra 在 32 项基准测试里有 30 项达到 SOTA，最关键的标签是第一个在 MMLU 上达到人类专家水平的模型，并在 20 多项多模态基准中全部刷新 SOTA。

解决什么真问题

在 2023 年下半年，"多模态 LLM" 主流做法还是松散拼接：一个视觉 encoder（如 ViT）+ 一个文本 LLM，跨模态对齐靠 adapter。这是 GPT-4V、LLaVA、Qwen-VL 等很多工作的隐含选择。

这条路有两个明显的局限：

  1. 模态之间学到的是"接口对齐"，而不是真正的"跨模态推理能力"——模型能识别图，但难以在文本/图像之间做复杂互推；
  2. 音频、视频能力大多要外挂单独模型，端到端协同非常困难。

Google 同时面对的另一重压力，是MMLU 这个老牌 benchmark 卡在 86% 左右已经很久，被普遍认为是 LLM 是否"达到人类水平"的标尺。2023 年 11 月 OpenAI 还没正式发布 GPT-4 Turbo 的传闻下，Google 急需一篇旗舰技术报告同时刷新 LLM + multimodal 两个 SOTA 表。

Gemini 工作要同时解决：

  • natively multimodal：模态解耦不再显式存在，模型从一开始就在多模态联合分布上训练；
  • 能力广：Ultra 要既能手写代码、又是数学专家、又要能处理百万 token 上下文；
  • 规模谱系：Ultra（云）、Pro（数据中心）、Nano（设备端、内存受限场景）一条贯通。

核心方法

1. 模型家族的整体设计

报告里这个家族由 3 个尺寸组成：

  • Gemini Ultra：旗舰能力，主打复杂推理；
  • Gemini Pro：主力部署在 Bard / Workspace / Vertex AI；
  • Gemini Nano：1.8B / 3.25B 两个尺寸，针对设备端推理做了蒸馏和量化。

每一种都从一开始就原生支持文本、图像、音频、视频，统一用 Transformer decoder 来建模 token 序列（跨模态 token）。

2. 训练管线

训练大致可以分成四步，原文用了较多产品语言，但拆开看很标准：

# （示意，不是原文代码）
# 步骤 1：多模态预训练
model = TransformerDecoder(...)
for batch in huge_multimodal_corpus():
    text_tok = tokenize(batch.text)
    img_tok = vq_img_tokenizer(batch.image)
    aud_tok = aud_tokenizer(batch.audio)
    vid_tok = vq_vid_tokenizer(batch.video)
    tokens = concat(text_tok, img_tok, aud_tok, vid_tok)
    loss = cross_entropy(model(tokens), tokens.shift(1))

# 步骤 2：多模态指令微调（SFT）
finetune(model, instruct_dataset_mix(
    text=..., images=..., audio=..., video=...))

# 步骤 3：RLHF（只对 Ultra/Pro，不一定对外公开细节）
train reward_model on human_prefs()
run PPO / RLOO over model

# 步骤 4：安全 / 红队 / 评测

3. 多模态 token 化

为了让 Transformer decoder 能同时吃下不同模态，Gemini 的关键决定是：把图像、音频、视频全部离散化为 token 序列，与文本 token 拼接到同一序列里。具体：

  • 图像使用类似 ViT 的 patch + 离散 tokenizer；
  • 音频以 16 kHz 提取 mel 谱，再以类似 SoundStream/USM 的方式编码为 token；
  • 视频切成帧，每帧按图像处理后拼接序列。

这样做的好处：模型在前向、训练目标（next-token prediction）、推理时全部统一——一切都是序列建模。

4. 关于"原生"的隐含意义

值得特别说明的是，原文并没有把"原生多模态"和"拼接多模态"的界限描述得很技术化。从上下文看，"原生"主要意味着：

  • 训练数据中多模态信号从一开始就同时出现（不像 adapter-based 系统只看文本和图文配对数据）；
  • 跨模态理解（如视频里问"这个声音是从哪里来的"）出现在预训练目标中，而不是后补 adapter；
  • 同一组 Transformer weights 直接处理所有模态，没有"分头编码再融合"。

论文没有像 PaLI-X 那样给出"分阶段训练 vs 联合训练"的对比数据，"原文未明确"——但这是后续多模态工作反复讨论的一点。

4.5 评估流程的几个实用细节

报告还披露了一些对工程圈很有价值的评测做法，例如：

  • 跨模态评测时会提前准备一个统一的 prompt 模板库，避免不同任务在指令表述上的偶然偏差被记在模型头上；
  • 对多选题，使用 log-likelihood 比较答案选项而不是直接让模型 generate；这种"可能性对比 + argmax"的处理今天仍然是多项选择评测的标准做法；
  • 对长上下文任务，采用 needle-in-a-haystack + 多跳综合问答等评测组合，而不是只看它在 1M 输入下的逐字检索能力。

这些细节本身不是主论文贡献，但反映了一个工业体系"评测层也是产品"的成熟思路：评测质量会反过来影响微调和部署决策。

5. 关键工程杠杆

报告对高效训练基础设施做了较多描述：

  • TPUv4 / TPUv5e 集群；
  • GSPMD（Google 的 JAX-based 大规模并行）作为分割编译器；
  • 跨数据中心级别的模型并行 + 数据并行。

这些硬件 / 调度层细节让 Ultra 级别的训练"从论文规模到工程规模"成为可能，是 Gemini 能在 2023 年底就拿出 Ultra 的关键。

关键实验与数据

论文评测规模巨大，摘录最关键的几个对照点：

  • MMLU：Gemini Ultra 报告 90.04% (5-shot CoT@32) / 83.7% (zero-shot)，是首个宣称"超过人类专家" 90.0% 基准的模型；
  • GSM8K (数学)：Ultra 报告接近 SOTA，具体数字见原文 table，不在本文中另写精确数字；
  • HumanEval (代码)：报告的 Ultra 比之前最佳公开数 +2 位数级别；
  • MMMU、VQA v2、DocVQA、InfographicVQA：20 项多模态基准"全部刷新 SOTA"；
  • 上下文长度：Gemini 1.0 原版报告的上下文窗口为 32K tokens；1M tokens 为 Gemini 1.5 (2024) 的核心特性，不宜直接归入本报告；
  • 音频：在 FLEURS、AudioCaps、CoVoIT 2 等基准上同时击败 Whisper 等上一代音频模型；
  • 视频：在几个动作识别 / 时序 QA 基准中取得领先。

安全 / Responsible AI：报告专门写了一节讲部署前的 red-team evaluation、bias measurement、child-safety check 等。它和 OpenAI 的 system card 文化基本同源，是 2023 年下半年起大家普遍采用的安全披露模式。

关于"广度"——报告里有一个Big-Bench Hard、AGIE 等综合性推理 benchmark 的部分，明确把 Gemini 定位为"通用助手"而非任何单点最强。

亮点与局限

亮点

  • 首个宣称超过人类 MMLU 水平的模型——这一里程碑在 LLM 史上被反复引用；
  • 一次性完整覆盖"图文音视频 + 文本"，让 Gemini 系列可以统一对外；
  • 提供 1M token 上下文，是 2023 年底最大的"窗口"声明之一；
  • 报告本身写得十分详细、附带评测表与安全披露，是工业界最透明的技术报告之一；
  • Nano 在小尺寸上提供了端侧的多模态能力，让 Android 设备第一次可以本地跑原生多模态 LLM。

局限（原文基础上我的补充）

  • 报告没有公开训练数据规模和明细——这是 2023-12 时已被批评的"de-distillation"压力下的折衷，但对研究者来说几乎不可复现；
  • 在很多细分子任务上 Gemini Ultra 不是 SOTA——比如部分代码、长尾事实、复杂指令 following，闭源模型之间各占山头；
  • "natively multimodal" 的具体训练协议在报告里写得相对产品化，复现可行性受限；
  • 与 GPT-4V 之间的直接对比公布得有限——更多依赖第三方评测（如 LMSYS Arena）；
  • 事实性幻觉：原生多模态模型对视频 / 音频的事实引用特别容易幻觉，论文承认但没有给出彻底解法；
  • 安全部分主要集中在"已知类危险内容"，对新兴风险（agent misuse、合成身份、生物风险）讨论略少。

对工程落地的启发

  • 多模态 token 化是趋势：报告把"四种模态统一成 token"作为设计前提，验证了这条路可扩展。后续 LLaVA-NeXT、InternVL、Qwen2-VL 等开源工作都沿着这条线走；
  • 分尺寸家族化部署：Ultra / Pro / Nano 三档模式证明：一个家族、多个尺寸比"单旗舰模型"更适合工业落地，工程团队可以沿用这个 pattern；
  • 长上下文不是单点优化：1M token 的支持意味着在很多场景下可以把整本说明书 / 整个代码仓 / 一段长视频直接塞给模型，减少工程上的 RAG 切片复杂度；
  • 负责任部署的产品化：从 red-team 到 Gemini 服务里的事实核查、用户反馈渠道，示范了一种把安全嵌入产品栈的做法；
  • 从消费者入口到企业入口：报告里强调 Vertex AI、Gemini Advanced、Bard 等多渠道分发，是"模型即服务"商业化的典型打法——今天大部分中国厂商也在学这个 pattern。

三个常见误解解答

为了让读者在对话场景下不至于误会 Gemini 的能力，下面纠正几个常见误解：

  • 误解 1：Gemini Ultra = "全能超人类"。事实是：它在"MMLU 是人类专家水平"这个意义上是领先的，不是说在所有任务上超人类。代码、数学、问答、推理都各有一些 SOTA 是别的模型；
  • 误解 2：原生多模态 = 完全跨模态推理。事实是：原生只意味着训练阶段联合出现，并不保证每一层都对每个模态全部详细加工；在工程实践中这种区分很重要；
  • 误解 3：1M 上下文 = 能能记住 1M token。事实是：上下文长度大部分时间是"能不能丝滑推理"，但针一挑到中段还是有采率下跌；Gemini 1.5 对此做了更细致展示。

这三个误解有助于在进入下一步研究/工程时，避免"只看 abstract 介绍"的高位侧读。

与同方向工作的关系

  • 同代最强对手：GPT-4 / GPT-4V（OpenAI，技术报告没那么公开）、Claude 2 / Claude 3（Anthropic）、Qwen-VL、LLaVA、InternVL；
  • 在同一时间节点，Mistral、Mixtral 等 MoE 工作也在推进 LLM infra 改写 Gemini 的训练玩法；
  • 原生多模态方向的接续工作：Gemini 1.5 (2024) 把长上下文推到 10M，是这篇工作的能力延伸；
  • 安全层面与 Anthropic Constitutional AI、OpenAI system card 一起构成 2023-2024 LLM 责任披露的"三块拼图"；
  • 1M 上下文方向被 Moonshot Kimi、LongLLaMA、Mistral 7B 长上下文版本 等共同推动，是 2024 年最重要的工程级话题之一。

适合谁读

  • LLM / 多模态方向研究者：了解"原生多模态"这条线在 2023 年底的设计哲学；
  • 企业 AI 平台架构师：在选 Ultra / Pro / Nano 做云-边协同部署时参考；
  • 安全 / 治理研究者：研究 2023-2024 LLM 旗舰模型责任披露格式；
  • 想理解"LMM 到底有什么不一样"的开发者：不需要读 60 页全文，看技术报告 + 这份解读就能在 30 分钟内建立基本图谱；
  • 教学场景：作为"工业级 LLM 技术报告样板"——它示范了"训练 / 评测 / 安全 / 部署"四节式经典结构，是科研报告写作的良好范例。

备注：本文涉及的"SOTA 30/32、20 多项多模态基准"等表述直接引自原文 abstract；其它像具体 GSM8K / HumanEval 的具体百分数有"原文未明确"的部分，本文不在解读中编造。

工程落地与核查（Jay）

事实核查修正

原文表述 核查结论 建议修改
"能处理百万 token 上下文" 存疑：Gemini 1.0 原版（2312.11805）披露的上下文窗口为 32K；1M 是 Gemini 1.5 (2024) 的核心特性（arXiv:2403.05530），不宜归入本文 "Gemini 1.5 公开支持 10M tokens；Gemini 1.0 为 32K"
"GSM8K ... 94.4%" 存疑：正文已标注"原文未明确"但仍出现精确数字，存在矛盾 删去 94.4%，改为"接近 SOTA，具体数字见原文 table"
"音频以 16 kHz 提取 mel 谱，再以类似 SoundStream/USM 的方式编码" 待核：原报告音频 tokenizer 未显式引用 USM；USM 是独立论文（Zhang et al. 2023） 改为"以自研离散 audio tokenizer 编码为 token"，避免误将 USM 归因

工程落地要点

1. 多模态 token 化：实际系统怎么用

Gemini 的核心工程选择是"一切皆序列"——图像/音频/视频均被离散化为 token，与文本拼接到同一序列。这意味着： - 部署侧：模型本质是 single-token-prediction decoder，推理引擎可以直接复用文本 LLM 推理栈（vLLM、TGI 等）加以多模态扩展，不需要额外的 cross-attention 适配层； - 预处理侧：需要部署 image tokenizer、audio tokenizer（如 Mel + RVQ）和 video frame tokenizer。Google 内部这套预处理栈不开源，开源社区多用 CLIP/ViT visual encoder 替代； - 坑：不同模态 token 的长度差异极大（一张 224×224 图像对应 ~256 tokens，1 秒 16kHz 音频对应 ~75 tokens），拼接后 attention 成本为 O(n²)，长视频 + 长音频 + 长文本的组合场景下上下文长度管理是主要瓶颈。

2. 三档部署：具体怎么选

场景 推荐档位 关键注意事项
云端复杂推理 / 代码生成 Ultra (API) 成本高；优先用于需要强推理的任务，文档摘要等简单任务不值得
对话助手 / 中等推理 Pro (API / 私有化) 性价比最优；支持 32K 上下文可直接处理长文档
移动端 / 设备端 Nano (AICore / 量化部署) Android AICore 仅支持特定骁龙芯片；3.25B 量化后约 1.5 GB，内存受限设备需进一步剪枝
离线 / 低延迟场景 Nano 无网络延迟，但多模态能力（尤其是音频）因设备算力限制有明显降级

3. 实际系统集成的常见坑

  • 幻觉问题在多模态场景更严重：视频/音频的 factual grounding 需要外挂 retrieval 或 grounding 模块（如 Google 的 Grounding API），Gemini 原生不具备可靠的 source citation；
  • API 成本：Gemini Ultra API pricing 按 token 计，多模态输入（图像/音频 token 数量远超等效文本）导致成本比纯文本高出数倍，工程预算需单独建模；
  • 多模态输入 size limit：Gemini 1.0 对单张图像有分辨率和 token 上限（≈ 768 tokens/图），超高清图需 downscale，影响文档 OCR 精度；
  • 安全过滤：Gemini 的 safety filter 会在多模态输入上做额外检查，某些合规场景（如医疗影像）需申请 safety bypass 或使用私有化部署；
  • 私有化限制：Gemini Pro/Ultra 不支持完全的私有化部署，企业用户只能通过 Vertex AI 或 API 调用，数据主权场景不适用。

4. 评测工程化的经验

Gemini 报告里"log-likelihood 比较答案"的做法在工程中可直接迁移：不要让模型直接 generate 多选题答案，而是计算每个选项的 log-likelihood 后取 argmax。这在 API 不支持 logprobs 返回时尤其有用——可以用 nucleus sampling + temperature=0 近似。needle-in-a-haystack 的评测组合（检索 + 综合）也是实际 RAG pipeline 验收的标准套餐。

5. 对开源复现的价值

Gemini 的工程选择（统一 token 化、规模谱系、post-training pipeline）对后来者影响深远： - LLaVA-NeXT、InternVL 2、Qwen2-VL 等开源多模态模型均沿用"image tokenizer → LLM decoder"这条统一 token 化路线； - Google 的 TPU + JAX + Pathways 训练栈不开源，但 Hugging Face 上的 DeepMind GEMMA 系列（ Gemma 2B/7B）是其开放权重版本，可作为复现 benchmark 的起点。

核查清单（工程接入前必读）

  • [ ] 上下文窗口：Gemini 1.0 = 32K；若需要 1M+ 上下文，确认用的是 Gemini 1.5 API；
  • [ ] 多模态幻觉：生产系统必须配 grounding / retrieval 层，不要裸用 Gemini 输出作为 fact source；
  • [ ] 音频 tokenizer：原报告描述为自研，不是 USM，开源复现不要直接用 USM checkpoint；
  • [ ] 成本：多模态 token 计费 ≠ 文本 token 计费，图像/音频密集场景需单独做 ROI 模型；
  • [ ] 设备端 Nano：确认目标设备芯片在 AICore 支持列表内，不支持则需 TFLite/ONNX 量化版本。