我的使用情境很清楚：單併發。一個人、一張 RTX 5090 32G，跑本地 Qwen3.8-27B 做 DeepSeek Harness（DSH）與 Codex 這類 agent 任務。llama.cpp 在這目標上已經很快（DSH 約 44 tok/s），換到 SGLang 後同卡同模型單人 decode 升到 65–85 tok/s。本篇記錄這次換引擎的真實經過，包含三個轉折——架設路線從 GPT 編譯失敗轉到 Docker 映像檔、DSpark 推測解碼因 VRAM 不足關掉、顯示器切到 CPU 內顯救回 1.4GB VRAM。

結論先說：如果你的場景是「單人、單併發、要單人速度越快越好 + 多模態 + 256K 長上下文」，SGLang 比 llama.cpp 更快（DSH 44→65–85 tok/s，快 48–93%），且原生支援多模態與 agent tool-call。SGLang 的多工能力是附帶的，對純單併發不是必要賣點。真正決定 5090 32G 上跑得好不好的，是 VRAM 餘裕够不够——最後兩節會詳細講。

為什麼換

1. llama.cpp 端，單人速度已經夠快，但多模態與 agent 架構是短板。 你的 llama.cpp 設定 -np 1，DSH 場景單人 decode 約 44 tok/s，對單併發來說已不算慢。問題不在速度，而在架構：llama.cpp 的多模態要靠外部 --mmproj 投影器、agent tool-call 要自己解析。換 SGLang 主要為了原生多模態、更強的 tool-call parser、以及單人 decode 速度，不是為了多工。

2. SGLang 單人 decode 直接快 48–93%。 同卡同模型，SGLang 在 DSH 場景實測約 65 tok/s、Codex 場景約 85 tok/s，對比 llama.cpp 的 44 tok/s。原因不是多工，而是 NVFP4 權重更輕（省 ~7GB 全數餵給 KV cache 與狀態池）+ FlashInfer 後端 + RadixAttention 把同一次對話重複的 system prompt 不重算。對「單人跑 agent 長任務」這類場景，前綴重用是實打實的省時，跟多工無關。

3. VRAM 帳本是單併發能不能撐住 237K 的關鍵。 llama.cpp 端 Q5_K_XL 約 22–24GB，SGLang 端 NVFP4 約 16.5GB。省下的 7GB 全數餵 KV 與 Mamba 狀態。但 NVFP4 + 237K + Mamba 狀態池把 32GB 逼到邊——最後剩餘 VRAM 只剩 0.4GB。這正是後兩節的主角。

換後得到什麼

重點澄清：多工不是這次換的原因。 SGLang 的 continuous batching 能跑 4 併發 425 tok/s，在團隊共用場景很有價值——但我的場景是單併發。換 SGLang 贏在單人速度（44→65–85）、原生多模態、agent tool-call parser、前綴重用，這些跟多工無關。

架設路線的轉折：GPT 編譯失敗到 Docker 映像檔成功

在講 VRAM 之前，先講這段路——SGLang 本身很好架，但「怎麼架」差很多。早期我請 GPT 幫我建置 SGLang，它走的是模型編譯路線：從原始碼 build SGLang kernel、編譯 CUDA 扩展、對齊 Blackwell sm_120 的算子、處理 JIT 快取與版本對齊。這條路線極其複雜，中間踩了許多 Bug——編譯器版本對不上、CUDA 13 與 kernel 的 sm_120 不支援、JIT 快取缺失導致反覆重編、跑起來 CUDA graph 異常——最終都架設失敗。卡了相當久都沒有跑起來。

後來在 抡锤者 YouTube 頻道 看到版主提到用 Docker + 官方映像檔的方式架設 SGLang——把整份 kernel 與 CUDA 工具鏈都打包進映像檔，只掛模型目錄與設定啟動參數，不用自己 build 任何東西。這個做法大幅簡化架設流程：拉映像檔 → 掛載模型 → 一條 python3 -m sglang.launch_server 起來。照著做，才真正把 SGLang 架起來。之後才能往下調 NVFP4、DSpark、VRAM 這些事。

給同樣想架 SGLang 的人：5090 / Blackwell sm_120 上，用官方 Docker 映像檔比從原始碼編譯省事太多。原始碼路線要處理 CUDA 版本對齊、kernel JIT 快取、sm_120 算子支援，Bug 密度高、時間成本高。官方映像檔把這些都封裝好了，你只負責掛模型與啟動參數。抡锤者頻道那篇是關鍵轉折，省了幾周的踩坑時間。

兩個 VRAM 踩底線的轉折

架起來之後，才開始面對 VRAM 這件事。這是 32GB 顯卡跑 27B 稠密模型最現實的限制。

轉折一：DSpark 推測解碼因 VRAM 不足關掉

SGLang 支援 DSpark（block-diffusion 推測解碼，同 DFlash2 路線），開了能把單人 decode 再推 ~10–15%。我原本要開，但載入 draft 模型後剩餘 VRAM 直接逼近 0，max_total_num_tokens 被擠到只剩約 94K——原本 237K 的上下文池被 DSpark 的 draft 模型與額外狀態池吃掉一大半，對單人跑 agent 長任務來說可用上下文砍到不足一半，代價太大了。最終於是把 DSpark 關掉，速度由開 DSpark 的 ~95 tok/s 掉到 ~85 tok/s，每秒差 10 tok/s、約 11%。差異不大，但換來的是 max_total_num_tokens 恢復到 317,282（約 310K）、KV 池與 Mamba 狀態池全數還給模型、不再 OOM。關掉 DSpark 不只省 VRAM，等於白捡 170K+ 的可用上下文——這在單併發、要 256K 長任務的場景比 10 tok/s 的速度差重要得多。

實測數字：開 DSpark 時 max_total_num_tokens 只剩 ~94K、~95 tok/s；關掉 DSpark 後 max_total_num_tokens=317,282（約 310K）、~85 tok/s。速度差 10 tok/s / 約 11%，但可用上下文由 94K 暴增到 317K——對單併發 256K 長任務，關 DSpark 是正確取捨。

轉折二：顯示器切到 CPU 內顯，救回 1.4GB VRAM

關掉 DSpark 後，剩餘 VRAM 仍只有 0.4GB，SGLang 長時間跑 agent 任務偶爾還是會被 OOM 打斷。關鍵洞察是：電腦的顯示輸出佔用 NVIDIA 顯示卡的 VRAM——桌面 compositor、多解析度 monitor、desktop window manager 全數吃 5090 的 VRAM。我把顯示輸出從 RTX 5090 切到 i9-14900K 內建的 Intel UHD 770，剩餘 VRAM 從 0.4GB 一路漲到 1.8GB，多了 1.4GB 餘裕。這 1.4GB 讓 SGLang 的 KV 池與 Mamba 狀態池都穩住，長時間跑 DSH 不再被 OOM。這是 5090 32G 跑 27B 時最划算的「免費」VRAM——不用降量化、不用縮上下文，只要把顯示器從 NVIDIA 切到 CPU 內顯。

這招值得抄：RTX 5090 32G 跑 27B 稠密模型時，把顯示輸出切到 CPU 內顯（UHD 770 或同級），可把被桌面 compositor 吃掉的 VRAM 還給模型池。實測剩餘 VRAM 從 0.4GB 升到 1.8GB，對長時間 agent 任務穩定度幫助很大。

兩點誠實標註

1. 量化不同，不是 apples-to-apples。 Q5_K_XL vs NVFP4 意味著「同卡同上下文」比較時，SGLang 端是 4-bit 權重。要嚴格比同量化，需另跑 SGLang GPTQ/AWQ 5-bit——但 NVFP4 是 Blackwell 上 27B 進 32GB 的標準答案。文中所有 SGLang 數字都基於 NVFP4 checkpoint（RadixArk，Apache 2.0）。

2. 85 tok/s 是「關 DSpark、切內顯後」的穩定值，且可用上下文最大。 開 DSpark 時 ~95 tok/s，但 max_total_num_tokens 被擠到 ~94K；關掉後 max_total_num_tokens=317,282（約 310K）、~85 tok/s。對單併發 256K 長任務，關 DSpark 換回 317K 可用上下文是正確取捨，速度只少 11%。

成本

• 硬件：0（同卡，顯示器切到已有 CPU 內顯，不需新硬體）
• 模型權重：NVFP4 checkpoint 免費（RadixArk，Apache 2.0）
• 架設：從 GPT 編譯路線（失敗）轉到 Docker 映像檔（成功），省了幾周踩坑時間；SGLang 官方映像檔免費
• VRAM 取捨：為求穩定與可用上下文關掉 DSpark（~95→~85 tok/s，max_total_num_tokens 由 ~94K 恢復到 317,282），再切內顯救回 1.4GB VRAM（剩餘 0.4→1.8GB）
• 機會成本：換掉的是 llama.cpp「單人最易調、冷啟動最快」的優勢；SGLang 旗標多、Mamba GDN 混合架構在 5090 上有已知的 prefill CUDA graph hang（需 --disable-prefill-cuda-graph 或新版本已修），要跟著版本走

你的兩組實際執行參數

llama.cpp（Q5_K_XL + Q8_0 KV + 256K）

llama-server.exe ^
  -m "D:\AI\llama.cpp\models\Qwen3.8-27B\Qwen3.8-27B-UD-Q5_K_XL.gguf" ^
  --mmproj "D:\AI\llama.cpp\models\Qwen3.8-27B\mmproj-F16.gguf" ^
  --alias qwen38-27b-q5 ^
  --host 0.0.0.0 --port 8080 ^
  -ctk q8_0 -ctv q8_0 ^
  -c 262144 ^
  -ngl 99 ^
  -b 4096 -ub 256 ^
  -np 1 ^
  -t 32

參數說明：

SGLang（NVFP4 + FP8 KV + 237K + FlashInfer，DSpark 關、顯示切內顯）

python3 -m sglang.launch_server \
  --model-path /model \
  --served-model-name qwen38-27b-nvfp4 \
  --host 0.0.0.0 --port 30000 \
  --trust-remote-code \
  --context-length 237568 \
  --mem-fraction-static 0.92 \
  --kv-cache-dtype fp8_e4m3 \
  --attention-backend flashinfer \
  --mm-feature-transport cpu \
  --max-running-requests 1 \
  --max-mamba-cache-size 5 \
  --mamba-radix-cache-strategy extra_buffer_lazy \
  --enable-cache-report \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder

參數說明（單併發導向）：

若要重開 DSpark（需 VRAM 夠、且接受 94K 上下文上限）

  --speculative-algorithm DFLASH \
  --speculative-draft-model-path incoai/Qwen3.8-27B-DFlash2 \
  --speculative-num-draft-tokens 8 \
  --mem-fraction-static 0.91 \
  --chunked-prefill-size 1024

加上這四行可把 ~85 tok/s 推回 ~95 tok/s。但代價是 max_total_num_tokens 由 317,282 縮回 ~94K——32G 上 27B + DSpark draft 模型會擠爆 KV 池，可用上下文砍到 94K，對 256K 長任務不夠。若要在你的配置重開 DSpark，先切內顯把那 1.4GB 救回來、且接受 94K 上下文上限，再試；否則單併發長任務場景關著比較划算。

決策速查（單併發導向）

數據來源：llama.cpp 端為用戶 RTX 5090 實測（DeepSeek Harness 場景 Q5_K_XL + Q8_0 KV + 256K，約 44 tok/s）。SGLang 端為用戶 RTX 5090 實測（NVFP4 checkpoint，DSH 約 65 tok/s、Codex 約 85 tok/s；開 DSpark 時 ~95 tok/s 但 max_total_num_tokens 僅 ~94K，關掉後 ~85 tok/s、max_total_num_tokens=317,282；顯示器切到 i9-14900K 內建 Intel UHD 770 後剩餘 VRAM 由 0.4GB 升至 1.8GB；架設路線由 GPT 原始碼編譯失敗轉為 Docker 官方映像檔成功，來源：抡锤者 YouTube 頻道）。所有 SGLang 數字基於 NVFP4 W4A4 checkpoint（RadixArk，Apache 2.0），與 llama.cpp 端 Q5_K_XL 量化不同，比較時請注意此差異。DSpark 為 z-lab / inco.ai 提供的 lossless block-diffusion 推測解碼，greedy 輸出與目標模型完全相同。