硬體

RTX 3060 12GB，安裝在一台Intel 6核心與64GB主記憶體的Unraid NAS上頭。

軟體

llama-swap，運行於docker容器中，推論引擎是llama.cpp，使用Cuda backend。

模型

Gemma 4 26B A4B QAT與12B QAT，選擇它是因為它是相對來說知識較廣泛的模型。

運作參數，這是寫在llama-swap的設定檔中

llama-server
    --port ${PORT}
    --host 0.0.0.0
    --fit-target 1331
    -np 1
    --no-webui
    -c 131072
    -ctk q8_0
    -ctv q8_0
    --model /models/gemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf
    --temp 1.0
    --top-p 0.95
    --top-k 64
    --jinja
    --chat-template-file /models/g4-chat_template.jinja
    --spec-type draft-mtp --spec-draft-n-max 3
    --model-draft /models/mtp-gemma-4-26B-A4B-it-qat.gguf
    --mmproj /models/mmproj-Gemma-4-26b-a4b-bf16.gguf
    --image-max-tokens 1120
    --ubatch-size 1536
    --no-mmproj-offload
  • –fit-target是要保留多少VRAM，單位MB，因為-fit參數不會把MTP與mmproj模型納入計算，所以經常會在載入模型時出現OOM的情況，因此改使用–fit-target參數預先保留VRAM來載入這些模型。
  • -np 1，平行處理推論的數量，預設是4。這個參數有個副作用，比如設定為4，context size設定為128k，實際上每個client能夠使用的context size是32k，也就是128k/4=32k。只有一個人在使用的話，強烈建議設定為1
  • -c 131072，把context size設定為128k，這會需要佔用VRAM，越大用的越多。
  • -ctk與-ctv是指KV快取，預設的資料儲存格式是f16，改成q8_0可以減少KV快取佔用VRAM的量（大約是原本的53%，而且資料精度幾乎是無損），可以把這些多出來的VRAM拿去載入更多tensor層數或者加大context size。需要注意q4_0或者使用不對稱的設定（q8_0搭配q4_0）會降低品質或者額外的副作用。
  • –image-max-tokens是模型在做影像識別時，可使用的預算上限。Gemma 4建議設定為1120
  • –ubatch-size是指prefill階段送給模型處理的批次大小，預設是512。因為調整了–image-max-tokens的大小，這個值也必須增加到至少超過1120。加大這個值會需要額外佔用VRAM，但也有好的一面，如果GPU的性能不錯，prefill的處理性能也會相應增加。對於agentic workflow來說，prefill的性能很重要。
  • –no-mmproj-offload是指不要把圖像辨識模組載入到VRAM，而是載入到主記憶體，缺點是圖像辨識會比較慢，優點則是可以把多出來的VRAM拿去載入更多tensor層數或者加大context size。

根據我的測試，使用上面的參數，Prefill的速度大約在1000t/s上下，而Decode則是在40~5x左右。Prefill是指把提示詞送給模型運算的階段，而Decode則是模型開始回答的階段。假設提示詞有35k token，那prefill階段就得花上至少35秒以上，這是因為prefill的處理性能會隨著提示詞長度下降，一開始有1000，但是很快就會下降到9xx。

Hermes Agent建議的context長度至少要有64k，這也是建議-np設定為1的原因，而且設定為2以上的話，經常會導致快取失效，因為有可能接到不同的cache slot，明明是在同一個對話(session)，prefill階段都要重新計算完整長度的提示詞，而不是後來增加的部份，效率大幅降低。