8GB 显存跑 Gemma 4 12B：llama-cli 混合卸载参数怎么配

8GB 显存想跑 Gemma 4 12B，最大的问题不是硬盘空间，而是运行时显存。

以 Q4_K_M 这类 GGUF 量化版为例，模型文件本身可能已经接近 8GB。真正跑起来时，还要额外放 KV cache、临时计算缓冲、系统桌面占用和驱动开销。结果就是：模型看起来“差一点能塞下”，实际一开长上下文就 OOM。

如果机器只有 8GB 显存，更合理的思路不是硬塞全 GPU，而是走显存和系统内存混合卸载：把尽量多的层放进 GPU，剩下的层留在内存里由 CPU 参与计算。

推荐脚本

假设模型路径是：

1

./models/gemma-4-12b-it-Q4_K_M.gguf

Linux / macOS 可以创建 run_gemma4.sh：

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

#!/usr/bin/env bash
set -e

MODEL_PATH="./models/gemma-4-12b-it-Q4_K_M.gguf"

./llama-cli \
  -m "$MODEL_PATH" \
  -ngl 26 \
  -c 8192 \
  -t 8 \
  --flash-attn \
  --mlock \
  -n -1 \
  --color \
  -i

赋予执行权限：

1

chmod +x run_gemma4.sh

运行：

1

./run_gemma4.sh

Windows 可以创建 run_gemma4.bat：

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

@echo off
set MODEL_PATH=.\models\gemma-4-12b-it-Q4_K_M.gguf

llama-cli.exe ^
  -m "%MODEL_PATH%" ^
  -ngl 26 ^
  -c 8192 ^
  -t 8 ^
  --flash-attn ^
  -n -1 ^
  --color ^
  -i

Windows 下通常不建议默认写 --mlock。不同版本、权限和系统配置下表现不完全一致，先跑通更重要。Linux 上如果内存很足，再优先使用 --mlock。

为什么要混合卸载

-ngl 是这套配置里最关键的参数。它控制有多少层卸载到 GPU。

1

-ngl 26

对于 8GB 显存，目标不是把模型全部塞进显卡，而是留出足够余量给 KV cache 和运行时缓冲。-ngl 26 可以作为一个起步值：显存放一部分模型层，内存接住剩余层。

调参方法很简单：

8GB 显存的机器不要只盯着模型大小。真正要看的，是模型层、KV cache、显存碎片和桌面占用加起来是否还有余量。

--flash-attn：8GB 显存建议打开

1

--flash-attn

这个参数对小显存很有帮助。它可以降低注意力计算的显存压力，并改善长上下文推理效率。

如果你的 llama.cpp 构建版本、GPU 后端或显卡架构不支持 Flash Attention，启动时可能会报错。遇到这种情况可以先去掉 --flash-attn 跑通，再更新 llama.cpp 或检查 CUDA / Metal / Vulkan 后端支持。

对 8GB 显存来说，能开就开；开不了，就先降上下文。

-c 8192：先把上下文压到 8K

1

-c 8192

上下文越长，KV cache 越大。很多模型标称支持很长上下文，但小显存机器不能直接按上限开。

8GB 显存上，8192 是比较稳的起点。它足够日常聊天、代码片段分析和中短文处理，又不会像 32K、64K 那样迅速吃光显存。

如果仍然 OOM，可以继续降：

1

-c 4096

如果你换成更小体积的量化版，并且显存还有明显富余，再尝试：

1

-c 12288

不要一开始就追求最大上下文。先稳定，再扩容。

--mlock：减少内存换出

1

--mlock

如果系统内存比较充裕，这个参数的作用是尽量把模型驻留在物理内存中，避免被操作系统换到慢速 swap 或页面文件里。

在混合卸载模式下，部分层会留在内存中。如果这些内存页被换出，响应会明显变慢，甚至出现卡顿。--mlock 能减少这种情况。

注意两点：

• Linux 上可能需要调整 ulimit -l 或相关权限。
• Windows 下不一定需要默认开启，先跑通模型更重要。

如果开启 --mlock 后启动失败，可以先删掉它。它是稳定性和速度优化项，不是必须项。

-t 8：CPU 线程数别盲目拉满

1

-t 8

-t 控制 CPU 线程数。混合卸载时，没放进显存的层需要 CPU 参与计算，所以线程数会影响速度。

建议设置为 CPU 物理核心数，而不是逻辑线程数。比如：

线程数不是越高越好。拉太满可能导致系统调度、内存带宽和桌面响应都变差。可以从物理核心数开始，再用实际 tokens/s 微调。

关于 -p "<|think|>\n"

原始脚本里有这一段：

1

-i -p "<|think|>\n"

这里建议谨慎使用。不同模型、不同 GGUF 转换、不同模板，对思考标记的支持并不一样。把 <|think|> 强行塞进 prompt，不一定会稳定开启所谓“深度思考”，还可能污染输出格式。

更稳妥的做法是先只开交互模式：

1

-i

如果你确认当前 Gemma 4 GGUF 的聊天模板需要特定系统提示或特殊 token，再按模型卡说明添加。不要把某个标记当成通用开关。

第一次运行建议用保守版

如果担心 8GB 显存不稳，可以先用更保守的脚本：

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

#!/usr/bin/env bash
set -e

MODEL_PATH="./models/gemma-4-12b-it-Q4_K_M.gguf"

./llama-cli \
  -m "$MODEL_PATH" \
  -ngl 20 \
  -c 4096 \
  -t 8 \
  --flash-attn \
  --mlock \
  -n 512 \
  --color \
  -i

这个版本牺牲了上下文和 GPU 卸载层数，但更容易跑起来。确认稳定后，再调回：

1

-ngl 26

以及：

1

-c 8192

想提速，优先换量化

如果 Q4_K_M 在 8GB 显存上只能卸载二十多层，速度会受 CPU 和内存带宽影响。想明显提速，最直接的方法是换更小的量化版本。

可以尝试：

换到 Q3_K_M 或 Q3_K_L 后，可以尝试：

1

-ngl 34

甚至：

1

-ngl 38

如果模型大部分层都能进 GPU，速度会明显改善。但量化越低，输出质量越可能下降。建议同一组 prompt 对比，不要只看 tokens/s。

内存带宽也很关键

混合卸载不是免费午餐。没进显存的层会走 CPU 和系统内存，速度受内存带宽影响很大。

建议检查：

• 系统内存是否双通道。
• DDR5 是否开启 XMP / EXPO。
• 后台是否有大量占用内存带宽的程序。
• 笔记本是否处于高性能电源模式。

如果内存是单通道，混合卸载速度会明显差。对于 8GB 显存 这种配置，系统内存容量够用只是第一步，带宽也要跟上。

排障顺序

遇到 OOM，不要一次改一堆参数。按这个顺序排：

1. 降低上下文：

1

-c 4096

2. 降低 GPU 卸载层数：

1

-ngl 22

再不行：

1

-ngl 20

3. 去掉 --mlock：

1

# 删除 --mlock

4. 如果 --flash-attn 报错，先去掉它确认是否是后端支持问题：

1

# 删除 --flash-attn

5. 换更低 bit 量化模型。

每次只改一个参数，记录 tokens/s、显存占用和是否 OOM。这样才知道真正的瓶颈在哪里。

一个调参表

8GB 显存最忌讳一步到位。更好的方式是先用保守参数跑通，再把 -ngl 和 -c 一点点往上推。

小结

8GB 显存 跑 Gemma 4 12B Q4_K_M，重点是混合卸载。推荐从 -ngl 26、-c 8192、--flash-attn、--mlock、-t 8 开始；如果 OOM，就先降上下文，再降 GPU 层数。

如果追求速度，换 Q3_K_M 或 Q3_K_L 往往比死磕 Q4_K_M 更有效。系统内存能兜住混合卸载的一部分压力，但真正决定体感速度的，还是 GPU 卸载层数、KV cache 大小和内存带宽。