Day 9｜vLLM 實測：官方容器、並發吞吐曲線，與剛出爐的新模型 Ornith 1.5

2026 iThome 鐵人賽

DAY 9

AI Engineering

128GB 統一記憶體的三十天：DGX Spark 地端 LLM 與生成式 AI 部署實戰系列第 9 篇

18th鐵人賽

ivanusto

2026-08-22 02:40:09

51 瀏覽

分享至

換引擎：從單人工作站到多人服務器

背靠背文章的第二篇，昨天 llama.cpp 給了我們單用戶場景的基準線。今天換上 vLLM，這個引擎的存在理由只有一個字，強大的吞吐能力。PagedAttention 把 KV cache 做成分頁管理減少記憶體浪費，continuous batching 讓不同請求動態併批填滿 GPU，這兩招在單請求場景都是很快的，在並發場景則會帶來很優秀的加速。

所以今天的量測分兩段，第一段沿用昨天的方法論跑單請求，測看看 vLLM 單請求會不會比較慢這件事，第二段才是它的主場，並發吞吐曲線，回答一個對地端 AI 部署最實際的問題：這台機器到底適合服務幾個人。

部署可選官方 vLLM 容器映像

NVIDIA 為 DGX Spark 維護官方 vLLM 容器映像，ARM64 加 Blackwell 的相容性都處理好了，這是 Spark 上跑 vLLM 最省事的路線。模型用 Day 5 入庫的 safetensors 原始格式，vLLM 不吃 GGUF，這也是當初模型庫要分 huggingface 與 gguf 兩層的原因：

docker run -d --name gptoss-vllm \
  --network host --ipc host --shm-size 16g --gpus all \
  -v /mnt/nas/AIModels/huggingface:/models:ro \
  -e VLLM_USE_DEEP_GEMM=0 -e VLLM_MOE_USE_DEEP_GEMM=0 \
  -e PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True \
 nvcr.io/nvidia/vllm:26.07-py3 \
  /models/gpt-oss-120b \
    --served-model-name gpt-oss-120b \
    --max-model-len 32768 \
    --gpu-memory-utilization 0.7 \
    --max-num-seqs 32 \
    --kv-cache-dtype fp8_e4m3 \
    --enable-prefix-caching \
    --enable-chunked-prefill \
    --host 0.0.0.0 --port 8000

幾個設定值在統一記憶體架構上有特別的眉角。

--gpu-memory-utilization 從保守值起步。 傳統獨顯上這個值常開到 0.9 以上，但統一記憶體是 CPU 與 GPU 共用一池，系統本身也需要記憶體，這邊如果你開太高會把作業系統推到牆角。Spark 社群的共識是從 0.5 到 0.7 起步再往上試，我這裡用 0.7。權重 60 GB 已經吃掉半台機器，0.7 換到的 KV cache 是 16.48 GiB。

--kv-cache-dtype fp8_e4m3。 KV cache 用 FP8 存放，容量直接省一半，換取的品質代價，在大多數應用場景是可接受的，這是 128GB 跑大模型加並發的關鍵設定值。

--enable-prefix-caching 與 --enable-chunked-prefill。 前者讓共用開頭的請求重用已算好的 KV cache，後者把長 prefill 切塊與 decode 交錯排程，改善並發下的 TTFT。這兩個對服務場景幾乎是必開。

--max-num-seqs 32，不是 8。 我原本寫 8，然後打算量到並發 16。這兩件事放在一起是矛盾的，伺服器同時只肯跑 8 條，第 16 路量到的就不是 continuous batching，變成是排隊中的數字。

兩個 DeepGEMM 開關都要關。 這是 GB10 上跑任何 FP8 路徑需要設定的，只關一個，MoE 模型還是會死在 Unknown SF transformation，因為它同時走密集層與專家層兩個路徑。

服務啟動後：681 秒就緒，其中 591 秒花在讀那 15 個 safetensors 分片檔案，引擎初始化為 30.13 秒（含 CUDA graph 編譯 10.84 秒）。常駐占用 85,930 MiB，KV cache 拿到 16.48 GiB，換算 849,942 個 token，在 32,768 的上下文下，最大並發是 25.94 倍。

第一段：單請求對照

同一套提示詞、同一個模型、同一套方法論，vLLM 與昨天 llama.cpp 相比的話。vLLM 單請求 decode 34.33 t/s，比 llama.cpp 的 58.59 慢，符合預期的結果，這其實是 vLLM 的架構特性，它服務機制的固定成本在單請求下無從攤提，所以在單請求情況下，單人用戶跑這款模型，用 llama.cpp 是比較快的方式。

測試	llama.cpp（Day 8）	vLLM	差異
prefill pp2048（t/s）	1922.66 ± 10.93	4092.79	vLLM 2.13×
prefill pp8192（t/s）	1899.19 ± 10.56	3547.65	vLLM 1.87×
decode（t/s）	58.59 ± 0.06	34.33	vLLM 0.59×

第二段：並發吞吐曲線，本篇的主菜

接著，我用 vLLM 內建的 benchmark 工具對服務端打並發，並從 1、4、8、16 逐步往上走，每級記三個指標：

vllm bench serve \
  --base-url http://localhost:8000 \
  --model gpt-oss-120b \
  --dataset-name random \
  --random-input-len 2048 --random-output-len 128 \
  --max-concurrency 【1/4/8/16】 \
  --num-prompts 64

看這張表的方法， TTFT 降低到體感不可接受的那一級，則為本台機器的服務上限。所以服務上限這樣判讀，以「每人拿到的生成速度不低於閱讀速度、最慢的請求不等超過四秒」為標準，這台機器跑 gpt-oss-120b 的甜蜜點是並發 8，每人 11.78 t/s、P99 TTFT 3.93 秒。並發 16 每人只剩 7.06 t/s 且 P99 逼近 8 秒，屬於能用但不快的程度。

如果把這個數字直接用商業邏輯來看，一台 Spark 跑 120B 模型，以可接受的體驗大約能同時服務到 16 個使用者。對評估地端導入的中小企業，這是一個可考量容量規劃的起點。而且要注意這是每筆 2048 token 輸入的結果，真實 agent 流量的提示詞往往長得多，可用人數算 8 人會更實在些。

時事插播：一款為這種機器而生的新模型 Ornith 1.5

寫這篇的同時，DGX Spark 社群這幾天正熱鬧測試這款新模型，由 DeepReinforce 釋出的 Ornith 1.5 家族。其中 35B-A3B 這個尺寸幾乎是替 128GB 統一記憶體量身訂做，BF16 全精度權重約 70GB 單機直接放下，MoE 啟用參數僅 3B 等級讓 decode 保持輕盈，原生 262K 上下文，官方同步提供 NVFP4 量化權重，速度也快。NVIDIA 開發者論壇上已有玩家用 spark-vllm 容器發布完整 recipe 與跑分，pp2048 超過 3,000 t/s，生成穩定在 31 t/s 附近，長上下文堆到 32K 深度時生成速度僅小幅下滑，agentic 與工具呼叫的評測分數也相當亮眼（來源：NVIDIA Developer Forums 的 DGX Spark 版，DeepReinforce Ornith-1.5 family released 討論串）。

我自己也把這個模型下載初步測試，第一印象不錯，繁中品質也還可以、工具呼叫表現與或速度體感俱佳。注意它的 recipe 裡同樣出現 gpu-memory-utilization 保守起步、KV cache FP8 等等這些今天文章中提過的設定值，社群的調參智慧正在收斂成 Spark 上的標準做法。這款模型的詳細用法和實作敬請期待，會與 Qwen3.8-27B 同場比較。

順帶一提，那份 recipe 的作者在跑分前寫了一段話，大意是跑分只拿來校準期望值，不拿來追逐，真正的考驗是實際工作負載。這個態度與本系列的誠實原則完全一致，引為同道，respect。

今天的結論

llama.cpp 與 vLLM 的關係在資料面前很清楚。單請求 vLLM 的 decode 成績受到架構問題所以不高，但換來 prefill 快一倍，把人加到 8 個，總吞吐回到 2.71 倍，加到 32 個是 4.20 倍。 一個人的話用選前者，服務一群人則絕對選後者喔，是可以規劃和預期的角色分工。