Gemma 精读：从部署约束反推模型设计

长文档放得进去，不代表生成时的显存和延迟也能接受。这篇先用 Gemma 3 的 local / global attention 把这笔账算清，再看 3n 和 4 改了哪些地方。想先懂原理，读到缓存算例就够；准备选模型，可以接着看版本区别与评估方法。

先分清 Gemma 3 的几个尺寸

Gemma 3 的一个关键选择是：多数层只读取附近的 token，少数层读取完整历史。它减少了长上下文的缓存需求，但不是让长上下文免费，也不是每个型号都支持图像。

先认准型号：官方型号列表中的 Gemma 3 270M / 1B 是文本模型；4B / 12B / 27B 支持图文输入。前两者的上下文为 32K，后三者为 128K；输入和生成内容共用这份长度预算。Gemma 3 model card

先看长上下文的账

flowchart TB
    A["文本；支持视觉时可加图像"] --> B["输入表示"]
    B --> C["局部层：附近的 token"]
    C --> D["全局层：可见的完整历史"]
    D --> E["后续 decoder 层<br/>预测下一个 token"]

这是推理路径；teacher 不在这条路径里。Gemma 3 报告采用每五个局部层接一个全局层的安排，局部窗口为 1024。下面缩小数字来理解它，不复刻某个 checkpoint。报告 §2

一层看不到，不代表多层都看不到

假设只有八个位置，编号 0–7，因果窗口宽度为 3，包含当前位置。位置 7 在一层里直接读取 5、6、7，读不到 4。但上一层的位置 5 已经能读取 3、4、5，所以再叠一层，位置 7 就有了接触 3、4 的间接通路。

这说明的是计算图里“有路可走”，不是远处的信息一定被保留下来。信息经过多次混合，具体还记住多少要用任务检验。反过来，一个全局层也不是只给附近窗口贴标签：它可以直接读取完整的可见历史。

六层的缓存，差多少？

自拟一个六层模型：五层 local、一层 global；每层有 8 个 KV heads，每头 128 维，K/V 用 BF16。一个请求已经有 32768 个位置，local 层仅保留最近 1024 个。各层的每个缓存位置需要 2 × 8 × 128 × 2 = 4096 bytes。

def mixed_cache_mib(tokens, local_layers=5, global_layers=1, window=1024):
    positions = local_layers * min(tokens, window) + global_layers * tokens
    bytes_per_position = 2 * 8 * 128 * 2
    return positions * bytes_per_position / (1024 ** 2)

assert mixed_cache_mib(32768) == 148
assert mixed_cache_mib(32768, local_layers=0, global_layers=6) == 768
assert mixed_cache_mib(131072) == 532
assert mixed_cache_mib(512) == 12

这个结果有实现前提：local 层需要真正回收或覆盖窗口之外的缓存。若程序只是加 attention mask，却仍为每层分配完整长度的 K/V，显存不会自动降到这个数。图中也没有权重、分块浪费、临时张量或图像编码器（encoder）；它是存储量算例，不是 GPU benchmark。

还要分开看 prefill 与 decode。理想窗口实现中，local 层的 attention 工作量随 $T W$ 增长，而全局层仍可能随 $T^2$ 增长；decode 时则分别读取至多 $W$ 和 $T$ 个历史位置。投影、FFN 和实际 kernel 速度需要另算。

结构之外，还要看什么

1. 窗口限制的是直接读取范围。 多层仍能传播信息，全局层提供更直接的远距离通路；不要把“少看一些历史”写成“和全局 attention 一样，只是更便宜”。
2. 图像也要花预算。 Gemma 3 的视觉编码器把一个图像视图（view）压成 256 个视觉 token；Pan & Scan 可以增加裁剪视图。读整页小字时，缩图可能丢掉线索，多看裁剪又会增加工作量。报告 §2.1、§5.5
3. 蒸馏（distillation）不是必须等预训练（pre-training）结束才做。 报告的预训练就使用 teacher 分布，后训练也使用蒸馏信号。teacher 的偏差可能被继承，但没有一般定理保证 student 每项能力都不超过 teacher。报告 §2.2、§3

再看 Gemma 3n 和 4：哪些不能照搬？

截至 2026-10-10，不能再把 Gemma 3 的配置当作这个家族的完整介绍。下面是阅读较新型号时最有用的区别，不是所有衍生版本的目录。

版本依据：3n 官方说明、Gemma 4 型号与模态表。effective、active、total 是不同口径。例如一份教学假设里的 26B 权重，如果全部以 BF16 常驻，就约有 52 GB（十进制）的原始权重；每个 token 只激活约 4B，并不会把剩下的权重文件变没。

Gemma 4 的 E2B / E4B 还在层间共享 KV cache，报告给出的共享比例分别是 20/35 和 18/42；因此上面的“两份 K/V × 每层各存一份”只是独立缓存的基线（baseline），不能直接当 Gemma 4 的显存计算器。共享是模型结构的一部分，不是推理时随意删一半缓存。Gemma 4 报告 v2（2026-07-24）§2

同样，支持 thinking mode 不代表回答越长就越好。比较时固定任务和工具权限，分别记录输出预算、成功率和延迟；不能拿一个开 thinking 的版本与另一个关闭的版本，仅凭总分推断架构收益。怎样在相同计算下比较，见测试时计算：怎么比较、怎么读数字。

取舍表

拿一个实际任务试试

例如做一个“从设备说明书找出正确接线方法”的助手，先别只问它能否放进整份 PDF。可以按下面的顺序做一组小实验：

保留一组没参与调参的说明书。每次记录 checkpoint、processor / chat template、输入和输出长度、缓存实现与设备。这些是建议做的实验；本站只验证了上面的算术，没有运行 Gemma 模型或复现厂商性能。

自检

• local attention 为什么能降低成本，又为什么不会立刻切断全局信息？
• 视觉 token 对上下文和延迟有什么影响？
• 怎样验证模型真的看了图，而不是猜文本先验？
• 蒸馏提升小模型时，为什么仍需要独立评估？
• 为什么 A4B、E4B 和总共 4B 不能混着算显存？

继续读：KV cache · MoE 的系统代价 · 蒸馏。

原始资料

• Gemma 3 Technical Report
• Gemma: Open Models Based on Gemini Research and Technology
• Gemma 3n 官方说明
• Gemma 4 Technical Report