先講背景：我張卡係 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 照食。幾個坑分享下：
- 唔設 max_tokens 會跑飛：試過一次 20K token 輸出，而家 client 固定 max_tokens
- --reasoning-budget 一定要 cap：唔 cap 嘅話 thinking 會吞晒速度，而家 cap 4096
- 長 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 揀機。
有問題歡迎交流！