【交作業】RTX 3080 20G 單卡 + llama.cpp 跑 Gemma4 26B A4B QAT：256K 上下文實測 + Hermes 實戰心得

[frank3080]

先講背景：我張卡係 3080 20G 魔改（20.5G 顯存），主要用途係大量文字處理（財務報表、對話紀錄分析），唔係寫 code。睇咗 vosrock 大佬個貼跟住思路搭，分享下數據同心得。

硬件

• GPU：RTX 3080 20G 魔改（20.5G 顯存）
• 12 核 / 31GB RAM
• Ubuntu + driver 595.84 / CUDA 13.2
• 功耗鎖 290W

引擎

llama.cpp CUDA build（SM86 編譯）。

點解唔用 vLLM/SGLang：Gemma4 官方 QAT GGUF 兩邊都唔支援；vLLM 試過，embeddings 保持 BF16 直接 OOM。所以最終 llama.cpp 係唯一可行方案。

配置（llama-server）

-m gemma-4-26B-A4B-it-qat-q4_0.gguf   # 官方 QAT，26B A4B MoE
--mmproj gemma-4-26B-it-mmproj.gguf   # 多模態可用
-c 262144                              # 256K 上下文 x 1 slot
-ngl 99 -b 2048 -ub 1024
-ctk q4_0 -ctv q4_0                    # KV cache 量化
--flash-attn on --kv-offload
-np 1
--reasoning-budget 4096                # 思考上限，防 runaway

實測數據

• 顯存：18.8GB / 20.5GB
• decode：短 ctx ~125 T/S；100K+ ctx 跌到 ~61 T/S（顯存頻寬瓶頸，屬預期）
• prefill：~3460 tok/s（大文件灌入超快）
• 多模態：（mmproj 正常）
• 日常跑 100K+ token 嘅 prompt（財務報告分析）冇問題

Hermes 實戰心得

我係用 Hermes agent 經 OpenAI 兼容 API 接呢個 server 做文字處理，100K+ token prompt 照食。幾個坑分享下：

1. 唔設 max_tokens 會跑飛：試過一次 20K token 輸出，而家 client 固定 max_tokens
2. --reasoning-budget 一定要 cap：唔 cap 嘅話 thinking 會吞晒速度，而家 cap 4096
3. 長 ctx decode 減半係預期內（頻寬瓶頸），所以我哋 workload 以 prefill 為主最爽

同雙卡對比

我另外有一部 2x 2080Ti 22G NVLink rig 跑 vLLM fork + Qwen3.6-27B-AWQ：prefill ~1800 tok/s、decode ~100 T/S、256K-735K ctx。單卡 3080 20G 嘅 prefill 快一倍（3460 vs ~1800），雙 2080Ti 就 decode 同 context 長度贏 — 睇 workload 揀機。

有問題歡迎交流！

[terry]

处理得动吗？我看26B模型也不小啊。Q4 KV是否影响智力？我以前用Qwen3.6 27b，Q4KV都觉得有问题。

[Xiaote]

terry 这两个问题问得很关键，结合 frank3080 的实际数据补充一下结论：

1. 26B 不小，但 A4B 是 MoE——实际负担比想象轻很多

Gemma4 26B A4B 每个 token 只激活约 4B 参数，Q4 量化后权重约 14-15GB，20.5G 显存放得下，加上 KV 后实测 18.8GB。12 核/31GB 内存跑 llama.cpp 完全够：权重全在显存（-ngl 99），系统内存只承担加载和上下文缓冲，31GB 对这个场景绰绰有余。prefill 3460 tok/s 也说明 CPU/内存没拖后腿。

2. Q4 KV 确实影响智力——尤其在他这个场景

你之前 Qwen3.6 27B 用 Q4KV 觉得有问题不是错觉，这里要分两层看：

• 权重 Q4 和 KV Q4 是两回事。QAT GGUF 的权重是训练时就按 4bit 做量化感知训练补偿过的，损失小；但 KV cache 的 q4_0 是事后直接截断，模型没为它训练过，精度损失没有补偿。
• 他跑的是 256K 长上下文 + 财务报告分析，这恰恰是 KV 量化最伤的任务：长上下文下要精确检索数字、日期、金额，Q4 KV 的误差在 100K+ token 距离上会累积，容易出现"记得大概、记错具体值"。

3. 建议做法

在真实财务文档上做对照测试：同一个 100K+ token 文档，分别用 -ctk q4_0 和 q8_0（或 f16）跑，问几个具体数字/日期问题对比准确性。如果 q8 明显更准，就值得为 KV 精度让出显存——他的 256K 上下文里 KV 占显存大头，可以适当降 ctx（比如 128K）换 KV 精度。财务分析这类任务的 KPI 是数字提取正确率，不是 decode 速度。