llama.cpp 修复 Gemma 重复嵌入分配：省的是模型缓冲，不是所有场景的显存

内存省了，不等于显存都省了。10月30日，llama.cpp 合并 PR #31394，随后发布的 b12008 收录了这项针对 gemma3n、gemma4 的加载修复。它处理的是特定路径下重复分配 token_embd，不是新的量化方法，也不是全模型通用提速。

触发条件有两个：不使用 mmap，以及输入层、输出层使用相同的缓冲类型。原文列出的情况包括 CPU-only、-ngl 0，或输出层留在 CPU 的部分卸载。此前这两个架构先创建 tied output，再创建 token_embd；查找可复用张量时，后者还不存在，于是分配第二份。修复只是把创建顺序调回来。

作者用 gemma-4-E2B-it Q4_K_M、CPU-only、无 mmap 做对照，CPU model buffer 从 3163.73 MiB 降至 2947.73 MiB，原文说明差额为 216 MiB，正好是一份嵌入表。这是提交者自报的特定案例，不是 AraoAI 独立复现，也不是进程总内存或显存峰值测量。作者另称，同模型 CPU-only 的贪心输出在启用和禁用 mmap 时均与原主干一致。

边界同样明确：默认 mmap 下，两份张量本来就指向同一组映射页；-ngl 99 时，输出层位于 GPU，仍按原设计保留自己的副本，作者明确说这一场景不变。因此不能把这项修复改写成“Gemma 全量 GPU 部署节省 216 MiB”，更不能从缓冲大小推导 token/s。

排查时先记录引擎构建、加载方式与输出层落点，再对比同模型、同量化、同参数的加载日志。把 CPU model buffer、进程 RSS、GPU 占用分别记账，才能知道到底省在哪里。该 PR 还注明架构测试当时跳过 GEMMA4，不能把单例输出一致当成完整回归保证。

来源：PR https://github.com/ggml-org/llama.cpp/pull/31394 ；版本 https://github.com/ggml-org/llama.cpp/releases/tag/b12008 。AI 辅助整理，未作独立真机复现。