vLLM Decision 3.0 地端實測

讓 LLM 做分類或路由判斷時，是不是也常常等待 JSON 慢慢吐字，甚至有時候還會遇到格式解析失敗？

vLLM 官方 Semantic Router 專案近期推出的 Decision 3.0 (d3) 打破了這個痛點，作為一款開源的多模態基礎決策模型，它的最大特色是「完全不生成文字」，而是直接在單次 Forward Pass 中輸出 Choice、Yes/No 與 Score 的校準機率分佈，這不僅免去了文字生成的延遲，更徹底根絕了格式錯誤的問題。

下面的文章我們將實測如何在單張 24GB VRAM 的地端環境中，利用 d3 解決 DevOps 事故自動分流，甚至挑戰高難度的醫療影像結構化判斷。

24GB VRAM 扛得住嗎？

在模型選擇時，發現 27B 模型原生 BF16 權重高達 52.2 GB，我的24G VRAM 一定是ＧＧ，不過透過 bitsandbytes 動態掛載為 4-bit NF4 量化，也成功將它塞進單張 24GB 的 VRAM 裏。

實測記錄下來的真實硬體開銷如下：

指標	9B (d3-flash)	27B (d3 原版)
運行精度	原生 BF16	BitsAndBytes 4-bit (NF4)
磁碟快取空間	14.9 GB	52.2 GB
冷啟動載入時間	4.51 秒	15.49 秒
GPU VRAM 佔用	15.64 GB	14.33 GB
文字 3 題並行延遲	239.5 ms	808.6 ms
CXR 高解析影像延遲	~2,500 ms	~5,900 ms
8 秒影片裁判延遲	~1,900 ms	~5,000 ms

實測數據中最反直覺的亮點在於 VRAM 佔用：27B 透過 4-bit 量化後（14.33 GB），居然比 9B 原生 BF16（15.64 GB）還要低。不過，代價反映在運算成本上，27B 的推論耗時約 808 毫秒，比 9B 慢了 3 倍。但若對比傳統 27B LLM 動輒數秒的生成延遲，這樣的回應速度在決策任務上依然極具優勢。

DevOps 實戰：CI/CD 事故自動診斷與分流

我們挑選了現代軟體工程中最常造成工程師半夜驚醒的四個具體維運情境，讓兩顆模型同時回答一組結構化問題。

1. 案例：CI/CD 建置失敗自動診斷（Sidecar 連線逾時）

• 輸入情境：GitLab CI 跑測試時失敗，Log 結尾顯示 Error: connect ECONNREFUSED 127.0.0.1:5432 與 postgres service failed to start within 30s，但本次 PR 僅修改前端 CSS 按鈕樣式。
• 模型判斷：
  • 故障歸因：9B 與 27B 皆以 99.9% 機率精準圈選 dependency_service_timeout，沒有誤判為程式碼錯誤。
  • 是否安全重試（Yes/No）：9B 給出 94.06% YES，27B 給出 98.35% YES。
  • 阻擋等級：兩者皆正確評定為 Feature PR Branch，未引發虛驚。

兩者皆可以判別這是常見的依賴容器delay start，直接自動Retry 即可解，無需人為介入。

多模態極限測試：胸部 X 光急診分流盲測

多模態是 Decision 3.0 最具威脅性的戰場，我們給了 4 張不同臨床特徵的真實胸部 X 光片，要求模型同步輸出「影像診斷分類（Choice）」、「急性危急生命指標（Noul）」與「門診急診分流佇列等級（Score 3 級：Routine / Urgent / STAT）」。

CXR 案例	9B (d3-flash) 判定結果	27B (d3 4-bit) 判定結果	臨床分流深度觀察
案例 1：正常常規胸片 cxr_normal.png (4.2MB)	• 診斷：normal_clear (98.33%) • 急診：NO (0.24%) • 分流：Routine (99.52%) • 耗時：2,651 ms	• 診斷：normal_clear (97.73%) • 急診：NO (0.34%) • 分流：Routine (99.64%) • 耗時：6,054 ms	兩者皆零誤報，無症狀常規體檢胸片完全不佔用急診資源。
案例 2：急性氣胸 cxr_pneumothorax.jpg (1.2MB)	• 診斷：pneumothorax (99.66%) • 急診：YES (94.02%) • 分流：STAT (88.46%) • 耗時：2,430 ms	• 診斷：pneumothorax (99.90%) • 急診：YES (97.81%) • 分流：STAT (98.79%) • 耗時：5,951 ms	27B 的決策果斷很多。9B 分流時留了 11.33% 機率在 Urgent，而 27B 直接以 98.79% 壓倒性機率觸發紅燈 STAT 廣播。
案例 3：大葉性肺炎 cxr_lobar_pneumonia.jpg (3.2MB)	• 診斷：lobar_pneumonia (99.65%) • 急診：YES (92.62%) • 分流：Urgent (63.74%) / STAT (35.74%) • 耗時：2,509 ms	• 診斷：lobar_pneumonia (97.98%) • 急診：YES (81.81%) • 分流：Urgent (90.28%) / STAT (6.65%) • 耗時：5,992 ms	臨床階層認知的明顯落差。大葉性肺炎需當日住院抗生素治療（Urgent），但不至於像張力性氣胸需立即插胸管（STAT）。9B 出現 35.74% 誤分流到 STAT，27B 則以 90.28% 準確分流至 Urgent。
案例 4：心律調節器導線 cxr_pacemaker_leads.jpg (48KB)	• 診斷：pacemaker_implant (99.26%) • 急診：NO (1.42%) • 分流：Routine (97.94%) • 耗時：545 ms	• 診斷：pacemaker_implant (98.85%) • 急診：NO (4.29%) • 分流：Routine (75.36%) • 耗時：1,556 ms	小圖（48KB）視覺 patch 數量少，推論速度翻倍，且兩者均精確辨識植入物並排除急性氣胸。

---

落地部署建議：非對稱的雙層防禦架構

如果在地端的VRAM資源有限，又想要把這兩顆模型都部署到開發或產品環境裡，分工邏輯非常明確：高頻即時與第一線守門直接選 9B BF16，文字決策約 240 毫秒、多模態影像約 2 秒、VRAM 佔用 15.6 GB，掛在 CI/CD Webhook、內部 Slack Bot 或前台影像上傳當做第一道篩檢守衛，完全不會拖慢系統回應。

而關鍵防線與高風險門禁則交給 27B 4-bit，文字決策約 800 毫秒、多模態影像約 5 到 6 秒，VRAM 反而只吃 14.3 GB，如果當遇到線上漏洞評級、資料庫Migrate變更、或是涉及臨床醫療分流（如區分氣胸 STAT 與肺炎 Urgent）時，27B 對微小線索的洞察力與嚴謹度顯著優於 9B，甚至資源夠時，也可以略過量化的步驟。

Decision 3.0 的出現，為需要低延遲、高穩定性的結構化決策場景提供了一個極佳的開源方案，讓我們能在有限的地端算力下，打造出兼具速度與準確度的企業級 Agent 路由中樞。

你目前在 DevOps 或 MLOps 流程中，也有遇到 LLM 輸出不穩定或 API 延遲過高的痛點嗎？歡迎在留言區分享你的看法。