硬件

• 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 揀機。

有問題歡迎交流！