Gemma 4 本地部署显存：E2B、E4B、12B、26B 与 31B 怎么选

Gemma 4 的本地部署型号不能只列 E2B、E4B、26B 和 31B。Google 官方资料还包含 12B。其中带 E 或 A 的名称涉及嵌入/激活参数表达，不能仅看名称猜权重体积。

本文把三类数据分开：Google 官方给出的近似推理内存、社区 GGUF 文件大小，以及你在具体后端上的峰值显存。只有第三项能回答“我的电脑实测占多少”。

型号定位

具体架构、输入模态和上下文上限以对应官方模型卡为准。

为什么显存表只能当起点

Google 文档中的近似内存表用于说明权重加载量级，但明确不包含所有运行开销。本地 GGUF 还会受到以下因素影响：

• Q4_K_M、Q5_K_M、Q6_K、Q8_0 等实际平均位宽；
• KV cache 类型和上下文长度；
• 并发请求数与批大小；
• GPU offload 层数；
• 图像编码器或多模态投影文件；
• llama.cpp、Ollama 等后端版本。

因此，不能把“GGUF 文件为 9GB”直接写成“最低只需 9GB 显存”。

消费级显卡选型起点

下表是保守的测试方向，默认量化、短上下文、单并发；不是官方保证或统一实测：

如果型号的量化文件尚未发布，或后端尚未支持对应架构，就不能根据数学体积宣称“可部署”。

下载时怎样避免拿错模型

1. 从 Google 官方 Gemma 页面进入对应模型卡；
2. 核对 base 与 it（instruction-tuned）版本；
3. 使用 GGUF 时追溯转换仓库的上游权重；
4. 保存文件名、量化、分片和 SHA256；
5. 检查 Gemma 许可证是否适合你的使用和分发方式。

Windows 计算哈希：

1

Get-FileHash .\gemma-model.gguf -Algorithm SHA256

llama.cpp 实测流程

先确认当前 llama.cpp 版本支持目标 Gemma 架构，然后用 4K 上下文启动：

1
2
3
4
5
6
7

.\llama-server.exe `
  -m .\gemma-model.gguf `
  -ngl 999 `
  -c 4096 `
  -np 1 `
  --host 127.0.0.1 `
  --port 8080

另开窗口：

1

nvidia-smi -l 1

记录启动日志里的模型缓冲、KV cache、计算缓冲和 GPU offload。完成固定提示词后，再把上下文改为 8192 重测；不要同时改变模型、量化和上下文，否则无法判断显存变化来自哪里。

判断结果

• 启动即 OOM：先降上下文和并发，再换更低量化；
• 能加载但速度极慢：检查是否大量 CPU offload；
• 输出格式异常：核对 tokenizer 和 chat template；
• 图像输入失败：确认模型、投影文件与后端都支持多模态；
• 同量化占用不同：比较后端版本、KV 类型和 offload 参数。

部署前先盘点四类资源

只看显卡型号容易漏掉系统内存、磁盘和 CPU。下载模型前，先记录：

1
2
3
4
5
6
7
8

Get-CimInstance Win32_VideoController |
  Select-Object Name, AdapterRAM, DriverVersion

Get-CimInstance Win32_ComputerSystem |
  Select-Object TotalPhysicalMemory

Get-PSDrive -PSProvider FileSystem |
  Select-Object Name, Free, Used

AdapterRAM 在部分 Windows 驱动中可能显示不准确，最终以 nvidia-smi 或显卡控制工具为准。系统内存至少要能承接模型文件、未 offload 的权重和操作系统本身；磁盘还要为下载分片、合并文件和不同量化版本留空间。

CPU 也会影响部分 offload 的速度。相同显卡下，双通道内存与单通道内存、DDR4 与 DDR5、不同 CPU 指令集都可能带来明显差异。

五个型号分别怎样落地

E2B：优先验证设备兼容性

E2B 适合先确认后端能否正确识别 Gemma 4、聊天模板是否正常，以及应用能否连通本地 API。它的目标通常是低延迟和低资源，而不是替代更大的模型完成复杂推理。

可从较高精度量化开始，再根据设备容量向下调整。若 E2B 仍然只跑 CPU，问题多半在 GPU 后端或驱动，而不是模型太大。

E4B：8GB 与 12GB 显卡的常用起点

E4B 更适合聊天、摘要、分类和轻量代码任务。先用 Q4 或 Q5、4K 上下文测试，然后比较质量是否值得升级到 Q6/Q8。

如果要处理图片，还要单独记录视觉投影文件占用。纯文本测试结果不能直接外推到图文输入。

12B：先给 KV cache 留余量

12B 量化权重可能接近 12GB 显卡的舒适上限。不要在模型文件刚好能装入显存时就把上下文拉满；应先预留约 1–2GB 给桌面程序和运行缓冲，再从 2K/4K 上下文开始。

如果 Q4 能全量放入 GPU，而 Q5 需要少量 CPU offload，实际体验未必是 Q5 更好。应同时比较任务正确率和生成速度。

26B A4B：激活参数不是加载体积

A4B 容易被误解成“只占 4B 模型的显存”。它描述的是激活规模，不会自动消除其他专家权重。消费级单卡通常要依赖较低量化或 CPU offload。

评估时先确认后端明确支持该 MoE 结构，再观察日志是否正确加载专家，而不是只看服务端口成功启动。

31B：把速度门槛写进验收

31B 在 24GB 单卡上通常需要量化和严格的上下文控制。即使能通过 CPU offload 加载，也应设置最低可接受速度，例如首 token 不超过多少秒、生成至少多少 tokens/s。

没有速度门槛，“成功运行”很容易变成只能用于截图、无法日常工作的配置。

从 GGUF 文件名读出关键信息

常见文件名可能包含模型、指令版、量化和分片信息，例如：

1
2

gemma-4-12b-it-q4_k_m.gguf
gemma-4-26b-a4b-it-q5_k_m-00001-of-00003.gguf

下载时逐项确认：

• base 还是 it；
• 参数规模是否与目标型号一致；
• 量化是否为计划测试的版本；
• 多分片文件是否全部下载；
• 仓库是否提供上游模型与转换说明；
• 文件总大小是否符合该参数规模的合理范围。

如果某个所谓 26B 或 31B 文件小得异常，不要直接运行。先检查它是否只是视觉投影、LoRA、索引或第一段分片。

用元数据确认模型没有拿错

llama.cpp 构建支持时，可读取 GGUF 元数据或观察加载日志。至少确认：

• 架构被识别为预期的 Gemma 版本；
• tokenizer 与 chat template 存在；
• 上下文参数没有被后端静默改写；
• 模型分片全部打开；
• 没有出现 unknown tensor、unsupported architecture 等错误。

出现模板问题时，先按官方模型卡和转换仓库说明修复，不要用不断修改系统提示词来掩盖角色格式错误。

上下文要按阶梯测试

建议固定模型与量化，只改变上下文：

每一轮都重启服务，确保上一次模型或缓存已经释放。若后端支持选择 KV cache 类型，要把该参数写进记录，否则不同人的结果不可比较。

部分 GPU offload 怎么调

当 -ngl 999 导致 OOM，可以逐步降低 GPU 层数，而不是立即换最低量化：

1
2
3
4
5
6
7

.\llama-server.exe `
  -m .\gemma-model.gguf `
  -ngl 40 `
  -c 4096 `
  -np 1 `
  --host 127.0.0.1 `
  --port 8080

具体层数由模型与后端决定。每次只减少一段，并记录：

• GPU 与系统内存峰值；
• prompt processing 速度；
• token generation 速度；
• 首 token 延迟；
• 是否发生系统换页。

如果系统开始大量使用页面文件，即使没有 OOM，体验通常也会迅速恶化。此时应换小模型或低量化，而不是继续增加虚拟内存。

多卡不能只看显存相加

两张显卡的总显存看似足够，但还要考虑后端是否支持张量分割、两张卡的速度差异和 PCIe 拓扑。混用不同容量显卡时，平均分配可能让小卡先 OOM。

多卡测试应记录每张卡的显存、利用率和功耗：

1

nvidia-smi --query-gpu=index,name,memory.total,memory.used,utilization.gpu,power.draw --format=csv -l 1

如果模型在卡间频繁传输导致速度反而下降，单卡加 CPU offload 可能更简单。最终应以端到端延迟判断，而不是只看两张卡都亮起利用率。

验证本地 API 而不只看网页

服务启动后先检查模型列表：

1

curl.exe http://127.0.0.1:8080/v1/models

再发送固定测试：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

$body = @{
  model = 'local-gemma'
  messages = @(
    @{ role = 'user'; content = '把 17×23 的计算过程写成两步。' }
  )
  temperature = 0
} | ConvertTo-Json -Depth 5

Invoke-RestMethod `
  -Uri 'http://127.0.0.1:8080/v1/chat/completions' `
  -Method Post `
  -ContentType 'application/json' `
  -Body $body

检查 HTTP 状态、模型字段、回答内容和服务日志。若网页能聊天但 API 失败，应优先排查端点与请求格式，不要重新下载模型。

常见选择问题

12GB 显卡选 E4B 还是 12B

需要速度、长上下文或同时运行其他软件时选 E4B；更重视回答质量且可以接受短上下文时，再测试 12B Q4。用同一组任务比较，而不是只按参数量决定。

24GB 显卡能否直接选 31B

可以把 Q4、短上下文作为实验起点，但不能保证所有权重与缓存都留在 GPU。先看真实 GGUF 文件、启动日志和峰值显存。

为什么同一个 Q4 有不同文件大小

Q4 只是大类。不同量化方案、混合精度张量、分组方式和元数据会改变平均位宽，必须写完整量化名称。

模型加载后显存为何继续增长

新对话 token 会进入 KV cache；并发、批大小和视觉输入也会增加缓冲。应区分启动后空载显存与完成一次最长请求后的峰值。

保存一份可复核的 Gemma 测试记录

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

GPU / 显存：
驱动：
后端与版本：
Gemma 型号（base/it）：
GGUF 文件与 SHA256：
量化：
上下文 / 并发：
GPU offload：
空载与峰值显存：
首 token 延迟 / tokens/s：

只有这些条件齐全，显存和性能结果才具有可比较性。

Google 与推理后端资料

• Google Gemma 入门文档
• Gemma 核心模型与内存说明
• llama.cpp 官方仓库

读懂 Gemma-4-31B-it 这类模型名称

模型名要逐段看。Gemma-4 表示模型家族与代际；31B 表示总参数规模约 310 亿，不等于运行时只占 31GB，也不代表每次推理都会激活全部参数；it 通常表示 instruction-tuned，即在预训练基础上针对指令、问答和对话做过调整。普通聊天、摘要、代码辅助和 Agent 场景优先选 -it，基础模型更适合继续训练或研究，不应把两者的对话表现直接比较。

下载页还可能附带量化、精度和格式后缀，例如 Q4_K_M、Q8_0、BF16、GGUF。这些后缀才直接影响文件大小、后端兼容性和显存需求。遇到名称与官方型号表不一致时，先查看模型卡、仓库所有者和元数据，不要仅凭文件名判断它是官方发布。

笔记本配置与验收

笔记本的限制通常不只是显存，还包括共享内存、散热和持续功耗。16GB 系统内存且没有独显时，优先从 E2B/E4B 的低比特量化开始，并把上下文先设为 4K；8GB 显存适合验证 E4B Q4，12GB 至 16GB 显存才适合谨慎尝试 12B Q4。Apple Silicon 使用统一内存，不能把总内存全部留给模型，至少给 macOS 和应用保留数 GB 余量。

首次运行时关闭占用显存的浏览器标签、游戏和视频软件，接通电源并观察温度。不要一开始追求 32K 或 128K 上下文：KV cache 会随上下文增长，模型刚加载成功也可能在长提示后溢出。

1
2

ollama ps
nvidia-smi

验收至少记录模型完整标签、量化、上下文、后端、首 token 延迟、生成速度与峰值内存。CPU-only 能返回答案只说明兼容，不代表可交互使用；若持续降频、系统开始交换内存或每秒 token 低于需求，应降低模型/量化/上下文，而不是反复重启。升级前保留原模型文件或 Modelfile，确认新配置稳定后再清理缓存。