要在 16GB 顯存的消費級顯示卡（如 RTX 5060 Ti）上部署 27B 至 35B 規模的大語言模型，記憶體配置與參數調校是影響實用性的關鍵。先前因為測試 MiniMax H3 音視訊生成，後台的 ComfyUI 常駐佔用了約 12.9GB VRAM，因此在進行 LLM 評測時，必須先停止 ComfyUI 服務以釋放完整顯存。

在將 16GB VRAM 完整留給 LLM 後，我針對 Qwen 3.8 27B 的多個量化版本以及 Ornith 35B MoE 進行了一週的壓力測試。本文紀錄實測數據、Gated DeltaNet 架構在 CPU Offload 下的效能折損、MTP 投機解碼的記憶體開銷，以及生產環境的啟動配置。

RTX 5060 Ti 16GB 本地 Qwen3.8 27B 極限實測

💡 AI 封面圖 Prompt 參考：A sleek technical futuristic illustration showing a high-performance Nvidia RTX graphics card running local artificial intelligence neural network models, circuit board glow, matrix data streams, cyan and dark blue glowing neon lights, cyberpunk aesthetic, clean high resolution 16:9 ratio, no text.

1. 測試環境與軟硬體規格

評測使用的本地硬體與軟體環境配置如下：

  • CPU：Intel Core i7-13700（llama.cpp 設定 6~8 threads）
  • RAM：23GB DDR5（加上 /data 磁碟 32GB Swap）
  • GPU：NVIDIA GeForce RTX 5060 Ti 16GB（實際可用 VRAM 約 16,311 MiB，Blackwell 架構 sm_120）
  • 儲存：NVMe SSD (/data)
  • 推理引擎：llama.cpp CUDA build（b10499 升級至 b10606 / commit 6036c635e）
  • CUDA 版本：12.8
  • 常用啟動參數：-fa on、KV Cache q4_0、--jinja、--reasoning auto --reasoning-preserve

2. Gated DeltaNet 架構的全卸載限制

測試 Qwen 3.8 27B 時，第一個遇到的瓶頸是「部分層數卸載到 CPU（Partial Offload）」。

傳統 Transformer 模型在 VRAM 吃緊時，通常可以將部分 Layer 移至 CPU RAM 執行，雖然速度變慢但仍可維持運作。但在 Qwen 3.8 採用的 Gated DeltaNet 混合架構中，CPU Offload 會帶來嚴重的效能懲罰。

實測數據對比（同一 Prompt 生成 600 Tokens）

# 量化版本 VRAM 卸載設定 Context Size 生成速度 MTP 接受率 VRAM 駐留
A UD-IQ4_XS (14.25G) -ngl 99（GPU 全卸載） 68K 39.9 tok/s 49% 15,738 MiB
B UD-IQ4_XS (14.25G) -ngl 58（部分卸載至 CPU） 92K 13.0 tok/s 50% 15,460 MiB
C UD-IQ3_XXS (11.90G) -ngl 99（GPU 全卸載） 92K 43.2 tok/s 47% 14,278 MiB
D UD-IQ3_XXS (11.90G) -ngl 99（GPU 全卸載） 144K 42.3 tok/s ~50% 15,682 MiB

原因分析

當設定 -ngl 58 時，生成速度從 39.9 tok/s 降至 13.0 tok/s（下滑近 70%）。

主要原因在於 Gated DeltaNet 架構高度依賴 GPU 上的 Fused Kernels。一旦有層數落入 CPU，融合計算核心便無法發揮作用，且層間計算必須頻繁透過 PCIe 進行 GPU 與 CPU 的同步等待。因此在該架構下，選擇能在 GPU 內完全卸載（-ngl 99）的較低量化版本，實測效能優於較高量化但部分 Offload 的配置。

3. Qwen 3.8 27B Q4 量化版本比較

在確定必須全卸載的前提下，我在 16,311 MiB VRAM 限制內掃描了四個 Q4 量化變體：

評測指標 Bucoid Uncensored Huihui Abliterated 官方 Unsloth Heretic-Ara-MTP
檔案大小 13.91 GB 14.40 GB 14.25 GB 14.33 GB
最高穩定 Context 92K 72K（長文發生 OOM） 76K ~88K（估算）
空載生成速度 49.8 tok/s 34.8 tok/s 39.9 ~ 41.0 tok/s 未測試
帶 14K Context 生成 49.1 tok/s ~33.0 tok/s 33.0 tok/s 未測試
Prompt 處理 (PP) 846 tok/s 819 tok/s 726 tok/s —
MTP 平均接受率 79% ~50% 62% —
VRAM 殘餘預留 860 MiB 433 MiB 573 MiB ~100 MiB
結論 採用 不推薦 備用 不推薦

Huihui 變體 OOM 狀況復盤

Huihui 變體模型檔較官方版大約 150MB，導致 VRAM 剩餘空間壓縮至 433MB。在處理包含 9,728 tokens 的 Prompt 時，llama.cpp 執行 mul_mat_q 因無法取得足夠計算緩衝而觸發 CUDA Out of Memory，造成服務崩潰。

這表示在 llama.cpp 中，VRAM 預留空間若低於 500MB，容易在長 Prompt Decode 時發生不穩定。

4. 參數設定：--no-warmup 與 MTP 記憶體開銷

測試過程中發現兩項影響系統穩定度的設定細節。

4.1 --no-warmup 的動態分配陷阱

llama.cpp 的 VRAM 分配分為三個階段：

若使用 --no-warmup 參數，第 3 階段（Flash-Attention 工作區）會延遲到接收第一個請求時才分配。這會導致模型載入時顯示成功，但在實際進行首次推理時因記憶體不足而瞬間崩潰。建議生產環境保留 Warmup 流程以提前驗證 VRAM 足夠。

4.2 MTP (Multi-Token Prediction) 的記憶體開銷

MTP 投機解碼能提升解碼吞吐量，但草稿頭需要額外佔用約 1.4GB 權重與 Draft KV Cache。

在 16GB 顯存下：

  • 開啟 MTP：最大 Context 上限約 76K~92K，生成速度為 41.0 ~ 49.8 tok/s。
  • 關閉 MTP：Context 可擴充至 120K，但生成速度降至 26.7 tok/s（速度降低約 35%）。

權衡程式碼生成與 Agent 互動的回應速度，選擇保留 MTP 並採用 Bucoid IQ4_XS (92K Context) 配置。

5. Ornith-1.5-35B-A3B MoE 評測比較

做為對照組，我也測試了 Ornith-1.5-35B-A3B-APEX-MTP-I-Mini（36B MoE 架構，每 token 激活 3B）。

數據表現

  • 空載生成速度：關閉 MTP 下達到 108.4 tok/s；在 128K Context 滿載下為 62.5 tok/s。
  • Prompt 處理 (PP)：最高達 1,862 tok/s。

限制說明

  1. MTP 效益極低：因 I-Mini 為極致量化版本，草稿頭精度較低，MTP 接受率僅 10.5%。開啟 MTP 反而使速度降至 67 tok/s，因此測試時必須關閉 MTP。
  2. 程式碼生成表現：在複雜程式碼重構與邏輯推理任務上，I-Mini 量化的精準度明顯低於 Qwen 3.8 27B IQ4_XS。

Ornith 適合對回應時間要求極高且任務較單純的場景；若需要高品質的程式碼生成，Qwen 3.8 27B 仍是較穩妥的選擇。

6. 生產環境部署腳本與紀錄

目前採用的 start-llama-server-4bit.sh 啟動指令如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#!/usr/bin/env bash
# ~/start-llama-server-4bit.sh - Qwen 3.8 27B 92K Context 配置

exec llama-server \
  -m /data/LLM/models/Qwen3.8-27B-Uncensored-IQ4_XS_4BPW.gguf \
  --gpu-layers-draft all \
  --spec-type draft-mtp \
  --spec-draft-n-max 2 \
  --n-gpu-layers 99 \
  --threads 6 \
  --fit off \
  --no-mmap \
  --flash-attn on \
  --ctx-size 94208 \
  --parallel 1 \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --batch-size 256 \
  --ubatch-size 128 \
  --jinja \
  --chat-template-kwargs '{"reasoning_effort": "medium"}' \
  --host 0.0.0.0 \
  --port 1234

📌 注意：Qwen 3.8 的 Jinja 模板只支援 low、medium 與 xhigh。傳入 high 會引發 HTTP 500 (Unexpected reasoning effort high)。

實際長跑統計（n=54 筆請求）

  • 生成速度 (TG)：中位數 37.9 tok/s，平均 38.3 tok/s。
  • Prompt 處理 (PP)：大 Context (≥8K tokens) 讀取中位數 759 tok/s。
  • MTP 草稿接受率：平均 71%。
  • 長文測試：處理 62,188 tokens 的 Prompt 耗時 100 秒（618 tok/s），背載 62K Context 下生成速度保持在 31.0 tok/s。

7. 地端部署決策樹

根據測試經驗整理的量化與配置決策流程：

8. 總結與調參建議

  1. 維持 100% GPU 全卸載：在 Gated DeltaNet 架構下，避免任何 Layer 落在 CPU。若顯存不足應調低量化版本而非減少卸載層數。
  2. 預留 VRAM 緩衝：建議保持 500MB 以上可用顯存，避免長 Prompt 在 Decode 階段崩潰。
  3. 保留 Warmup 流程：避免 --no-warmup 延遲顯存配置而掩蓋動態分配問題。
  4. 評估 MTP 效益：高接受率模型（如 Qwen 3.8）建議開啟 MTP；低接受率模型則應關閉 MTP 節省記憶體。
  5. 推薦組態：16GB VRAM 顯卡建議採用 Qwen3.8-27B-Uncensored-IQ4_XS_4BPW.gguf 搭配 92K Context 與 MTP，可取得最佳的速度與實用性平衡。