DEV Community: JH5

實測 NVIDIA Switchyard 疊加 PAIR：雙層混合推論架構

JH5 — Thu, 29 Oct 2026 06:58:54 +0000

小朋友才做選擇，前面兩篇我們分別試過《實測 NVIDIA Switchyard：RTX 3050 邊緣與雲端混合路由》和《實測 NVIDIA PAIR：RTX 3050 串接 Colab A100 混合叢集》，也在文章稍微提過混合使用的可能情境，這一篇就來測試一下撒尿牛丸吧。

為什麼單一路由層無法滿足生產環境？

實際落地時，單一方案都會在現場撞牆：

只用 Switchyard 的硬傷：Switchyard 雖然能精準辨識出「日常庶務，派給本地 8B 即可」（見第二篇：《實測 NVIDIA Switchyard：RTX 3050 邊緣與雲端混合路由》），但它預設只能指派給單一的本地端點，當 Multi-Agent 同時併發 10 個子任務時，單張 3050 顯卡當場被塞爆。
只用 PAIR 的硬傷：PAIR 擅長在區域網路內做負載平衡輪詢（見第一篇：《實測 NVIDIA PAIR：RTX 3050 串接 Colab A100 混合叢集》），不過它缺乏「對話語意辨識」與「多輪執行期狀態追蹤」能力，因此，當 Agent 在工具調用中連續 Deadlock 或ＧＧ後，PAIR 無法理解先前 context 的嚴重性，只是會一直撞牆的把請求拋給小模型，導致 Agent 陷入無限迴圈。

實測一：A100 14B 熱機純推論效能重測

在第一篇 PAIR 混合叢集實測中，我們觀察到階層模型路由把任務送給 Colab A100 時，總耗時達 51.65 秒，會因為模型初次載入 VRAM 時包含了檔案讀取與權重載入的冷啟動成本（Cold-start Overhead），因此這次測試在權重完全就緒的狀態下，我們重新執行了相同的 5 組不同的評測任務：

非小細胞肺癌 EGFR L858R 標靶抗藥性多步論證
Nextflow K8s Parabricks 容錯架構設計
TP53 突變 ACMG/AMP 鑑別
nnU-Net 3D CT 顯卡 VRAM OOM
跨節點推論調度

實測數據對比（冷啟動 vs 熱機）：

評測項目	冷啟動階段 (Cold Start)	熱機就緒階段 (Warm Cache)
5 題總牆鐘時間	51.65 秒	15.68 秒
平均單題推論延遲	10.33 秒	3.14 秒
穩定生成速度	~14.5 tok/s	70.35 tok/s

數據顯示，扣除初次權重載入的硬體 I/O 後，A100-SXM4 憑藉 1.6 TB/s 的 HBM2e 記憶體頻寬，能以每秒超過 70 個 token 的極速穩定輸出 14B 深度推理報告。第一道題目因包含 KV-Cache 預熱花費 7.14 秒，後續四道題目全部整齊劃一地在 2.13 秒 內瞬間完工。

實測二：雲端節點斷線之 Failover

將雲端臨時算力（如 Google Colab、Spot Instance）納入叢集時，最擔憂的硬傷就是：如果雲端節點突然被 Google 收回或網路中斷， Agent 會不會直接崩潰？

我們在路由器中實作了主動健康監控與降級重試機制，並設計了包含 8 道連續請求的測試：

前 3 題：正常派發至雲端 Colab A100。
第 4 題至第 8 題：刻意阻斷雲端的 Port，模擬遠端伺服器中斷。

實測日誌與故障排除軌跡：

👉 請求 #1 [NORMAL]: "Check Docker status on worker-node-01..."
   ⚠️ [FAULT DETECTED] 主要節點無回應 (timed out)，觸發 PAIR 毫秒級容錯切換 (耗時 1501.6ms)...
   🔄 [RETRY/FALLBACK] 自動將請求重試轉發至地端 RTX 3050 (llama3.1:latest)...
   ⚡ 完成！伺服節點: Fallback (RTX 3050 Local) | 總耗時: 3.6631s | 產出: 80 tok

👉 請求 #2 [NORMAL]: "Parse FastQC summary text for adapter contamination..."
   🔄 [RETRY/FALLBACK] 自動將請求重試轉發至地端 RTX 3050 (llama3.1:latest)...
   ⚡ 完成！伺服節點: Fallback (RTX 3050 Local) | 總耗時: 0.7328s | 產出: 80 tok

容錯切換關鍵結論：

Client Zero-Failure：8 筆請求在遭遇斷線的情況下，Client 端回傳成功率依然是 8/8 (100%)，沒有任何一筆請求噴出 500 錯誤或 ConnectionRefused。
故障熔斷速度：初次逾時在 1.5 秒內即完成健康度標記並自動重新執行，改成 Request 本地 3050，單題延遲降回 0.73 秒。

Switchyard + PAIR 實測

在完成前面的驗證後，我們正式啟動 Switchyard + PAIR 的驗證，並將後端目標直接綁定 PAIR 與雲端 API：

# routes.toml 關鍵雙層設定節錄
[routes.semantic_task_route]
id = "semantic_task_route"
type = "llm_classifier"
classifier_target = "node_3050_judge"
strong_target = "flagship_sonnet"
weak_target = "node_3050_8b"

[routes.agent_resilience_route]
id = "agent_resilience_route"
type = "stage_router"
picker = "efficient_first"
capable_target = "flagship_sonnet"
efficient_target = "node_3050_8b"

在包含單輪語意分流與多輪 Agent 故障排除的四組聯調實測中，端到端耗時與路由行為紀錄如下：

測試案例	情境描述	路由通道	實際命中節點	總耗時 (ms)
CASE 1	Routine Bash 指令	semantic_task_route	雲端 (Sonnet)	2,030.8 ms
CASE 2	分散式快取時序撕裂	semantic_task_route	雲端 (Sonnet)	2,002.1 ms
CASE 3	DevOps Agent 正常排障	agent_resilience_route	地端 (3050)	431.3 ms
CASE 4	DB 死鎖除錯排查	agent_resilience_route	地端 (3050)	550.1 ms

另外測試的過程中也紀錄一些 Note：

正規表達式與 Traceback 格式匹配的嚴格性：在 CASE 4 中，若工具僅回傳純文字錯誤（如 ERROR 40001）而不是標準 Traceback (most recent call last): ，Switchyard 會判定由本地 3050 處理，而在第二篇 Switchyard 實測中，只要帶有完整的單元測試日誌，才會在 0.011 ms 內觸發 repeated_failure 並切換到雲端模型。
未微調 Judge 的 Fallback 防禦：在 CASE 1 中，地端 8B 裁判對提示詞的格式解析稍有偏差時，Switchyard 的安全機制還是有發揮作用，果斷將請求送往雲端模型，不至於讓 Request 卡死在格式錯誤上。

推論的三個 Must

經過這一輪測試也可以整理出一些經驗來分享：

大腦與肌肉必須分工：不要在單一工具內搞定所有事。讓 NeMo Switchyard 專注做語意分析與 Agent 狀態管理（大腦），讓 PAIR 專注做 GPU 資源與連線管理（肌肉），架構最乾淨、維護成本最低。
模型預熱是剛性需求：在生產管線啟動前，務必對叢集內的模型發送一次輕量 probe 進行模型預熱，避免第一位使用者承擔冷啟動成本。
雲地混合必備熔斷降級：任何外部算力節點（不論是 Colab 還是雲端 Spot 執行個體）都必須在本地保留等效或輕量的 fallback 副本，才能在享受雲端算力擴展的同時，守住系統 99.9% 的可用性。

實測 NVIDIA Switchyard：RTX 3050 邊緣與雲端混合路由

JH5 — Thu, 29 Oct 2026 06:58:53 +0000

每次看到月底 API 帳單上那些忽多忽少的美元的扣款，心裡總是噴血，點開日誌一看裡面有八成竟然都只是在叫 Claude 讀個檔案、跑個 Linter、處理 Git...
如果在每個打到雲端 API 前的任務再加個 Routing，地端可以接球再決定要不要轉傳，是不是就可以幫忙處理很多種任務前置分流與動態執行任務的日常運用？

釐清架構盲點：為什麼單輪任務與 Agent 升級不能混為一談？

很多團隊在評估動態模型路由（Model Routing）時，最常犯的直覺錯誤就是把所有請求當成同一種東西在分流。

而 NVIDIA NeMo Switchyard 是基於 Rust 開發的開源動態模型路由層，特點是能將 Agent 在多輪對話中的每一步請求依據即時狀態分流到不同成本與能力的 LLM。

但仔細看它的核心設計，其實切成了兩套運作邏輯截然不同的路由範式：

                              ┌── 範例 A：任務型前置分流 (Task Routing)
                              │   單輪進門 ──► 裁判模型預判難度 ──► 派發 (8B vs 旗艦)
  ─────    應用範例  ──────────┤
                              └── 範例 B：執行期動態升級 (Stage Routing)
                                  多輪 Agent ──► 預設本地 8B 跑雜工 ──► 連續撞牆 ──► 雲端旗艦模型接棒

如果你拿單輪的 URL 參數解析、SQL 分頁或常規文本摘要去跑多輪專用的 stage_router，Switchyard 根本沒有進行任何語意推理，它只是因為你設了 picker = "efficient_first" 而無腦套用預設值，那只能稱作靜態 fallback。

真正的分流架構，必須把這兩件事拆開：

任務前置分流（Task Routing）：由輕量 Judge 或意圖分類器在入口把關，依據單輪任務複雜度決定走便宜通道還是旗艦通道。
執行期動態升級（Stage Routing）：專門為 Tool-Using Coding Agent 或 SRE 診斷腳本打造。前幾輪看檔案、跑 linter、查 status 全丟給本地端 RTX 3050（成本為 0 元）；只有在工具回傳連續報錯、卡死時，才強行 hot-swap 到雲端旗艦模型（例如 Claude-Sonnet-5.5 或 GPT-6）來收尾。

不過這裡也有一個可能會發生的架構卡點：Switchyard 本質上是一個「語意決策大腦」，預設是將本地任務指派給單一端點，當前端 Multi-Agent 同時併發多個任務時，單張 3050 顯卡依然可能被排隊隊列塞爆。如果要為本地端引入跨卡或跨設備的硬體推論網格，可以參考第一篇：《實測 NVIDIA PAIR：RTX 3050 串接 Colab A100 混合叢集》；而將兩者融合成「大腦＋肌肉」的終極雙層架構，則記錄在第三篇：《實測 NVIDIA Switchyard 疊加 PAIR：雙層混合推論架構》。

格式避坑：Switchyard 雙路由 TOML

網路上包括 KDnuggets 在內的多數教學文章都停留在 0.2.0 版本，好多範例都是過時的 routes.random.yaml，在 0.3.0 版中，底層原生 Rust 伺服器已全面改為 TOML 結構。

在 Python 環境安裝套件非常直接，直接安裝預編譯 wheel 檔即可：

pip install nemo-switchyard

在這次的邊緣與雲端混合架構中，我們在同一份 routes.toml 裡同時定義兩個不同用途的路由：task_route 負責單輪前置判定，agent_stage_route 負責多輪 Agent 工具監控。

schema_version = 1

[llm_clients.ollama_local]
format = "openai_chat"
base_url = "http://127.0.0.1:11434/v1"

[llm_clients.cloud_upstream]
format = "openai_chat"
base_url = "http://127.0.0.1:19800/v1"

[targets.local_edge]
id = "llama3.1:latest"
llm_client = "ollama_local"

[targets.cloud_flagship]
id = "claude-sonnet-5-5"
llm_client = "cloud_upstream"

[targets.local_judge]
id = "llama3.1-judge"
llm_client = "ollama_local"

# 範式一：單輪任務前置意圖分流 (Task-level Pre-Routing)
[routes.task_route]
id = "task_route"
type = "llm_classifier"
classifier_target = "local_judge"
strong_target = "cloud_flagship"
weak_target = "local_edge"
base_threshold = 0.5
threshold_step = 0.0
classify_trigger = "new_session"

# 範式二：多輪自主 Agent 執行期動態升級 (Stage-level Execution Routing)
[routes.agent_stage_route]
id = "agent_stage_route"
type = "stage_router"
picker = "efficient_first"
capable_target = "cloud_flagship"
efficient_target = "local_edge"
confidence_threshold = 0.5

這裡有一個很大的設定陷阱：Switchyard 的 Rust 引擎在同一條 route 內是拿 model id 當 key，如果你把 classifier_target 跟 weak_target 都指向同一個字串 llama3.1:latest，伺服器在初始化時會直接報錯，目前暫時的解決辦法是在 Ollama 裡用 ollama cp llama3.1:latest llama3.1-judge 複製一個別名來暫時通過 Init 的驗證。

在 Python 裡拉起原生伺服器只要兩行：

from switchyard_rust.server import Server

# 啟動 Rust 監聽伺服器
sy_server = Server("routes.toml", port=19888)
print(f"Switchyard 路由伺服器已上線：{sy_server.base_url}")

拆解任務前置分流：llm_classifier 在本地端到底靈不靈？

第一個測試，我們先測試了全端開發常見的錯誤的分流能力

當請求打到 task_route 時，Switchyard 會先掛起請求，把任務送進 classifier_target（我們部署在 RTX 3050 上的 llama3.1-judge），接著，Switchyard 會透過 TaskClassifierVerdict，要求裁判模型輸出 crux、primary_rule、capability_boundary 以及解題機率 p_solve。

在全端常見錯誤（例如前端與 API Gateway 最頻繁遇到的 URL Query 參數解析與缺失防禦）中，裁判模型判斷小模型具備充足能力，信心值直接給出 1.0，請求順利被分發給本地 3050 上的 8B 模型：

INFO switchyard.request: libsy.run: switchyard_libsy::algorithms::util::llm_judge: consulting llm judge target="llama3.1-judge"
INFO switchyard.request: libsy.run: Model selected algorithm="llm_task_classifier" target=llama3.1:latest confidence=1.0
INFO switchyard.request: switchyard_server::request: LLM request handled wire_format=openai_chat status=200 requested_model="task_route" selected_model="llama3.1:latest"

而因為我的前端選的是 Next.js，過程中好幾次遇到 Server Actions 引發的 JWT Session Cookie 覆蓋跟 WebSocket 斷線的錯誤，裁判模型判定超出能力範圍，Switchyard 果斷將請求直送雲端 Claude-Sonnet-5.5。

另一個發現是，Switchyard 內建的 capability classifier 規範了 SUP-1 到 SUP-5 的規則列舉，如果本地 8B 裁判對提示詞的理解稍微有一點格式偏差，Switchyard 會直接將判定標記為無效，並觸發 fall_through 安全轉換到比較強模型，這種保守的設計保證了生產環境不會因為判斷出錯而ＧＧ，但也代表在日常的業務情境下，如果要精準發揮前置分流的威力，還是必須要微調小模型或改寫專屬 prompt 。

實測執行期動態升級：捕捉 repeated_failure

前面有提到另一個常見場景就是 stage_router的應用

在 Coding Agent 與 DevOps 維運場景中，我們實測了四個常見的日常：

第一組是規範檢查：Coding Agent 讀取 src/auth_service.py 裡的 JWT 驗證邏輯，接著調用 run_linter 工具，工具回傳 SUCCESS: 0 warnings, 0 errors，確認了在 Switchyard 的歷史紀錄中看見全數正常，維持在本地 3050 處理，端到端耗時僅 438 ms。

第二組是環境維護：DevOps Agent 執行 git status 確認工作目錄乾淨，再執行 hadolint 驗證多階段 Dockerfile ，沒有任何異常訊號，全程在本地 8B 解決。

第三組是deadlock除錯：Agent 嘗試修復並呼叫 pytest 工具，結果第一次ＧＧ：

Traceback (most recent call last):
  PostgreSQLError: 40001 could not serialize access due to concurrent update (deadlock detected)
FAILED tests/test_concurrency.py::test_deduct_balance

Agent 嘗試修改程式碼後再次執行測試，又噴出了一模一樣的 40001 錯誤，不過就在連續失敗兩次後，Switchyard 發揮了它的價值～

INFO switchyard.request: switchyard_libsy::algorithms::util::stage: stage router override decision_source="override" override_reason="repeated_failure" target=claude-sonnet-5-5
INFO switchyard.request: libsy.run: Model selected algorithm="stage_router" target=claude-sonnet-5-5 confidence=1.0
INFO switchyard.request: switchyard_server::request: LLM request handled wire_format=openai_chat status=200 requested_model="agent_stage_route" selected_model="claude-sonnet-5-5" handling_duration_ms=300.96

從判斷出 repeated_failure 到切換，只花了 11 微秒（0.011 ms），信心度也被拉到 1.0，直接將下一輪提示詞切換至雲端 Claude-Sonnet-5.5，讓雲端模型分析與接手處理。

第四組是 Kubernetes 故障排查：DaemonSet Pod 連續兩次噴出 ExitCode 137 (OOMKilled)，Switchyard 也順利的觸發了 critical_error ，同樣的順利傳球給雲端模型接手處理。

實際運用的架構取捨

雖然 Switchyard 的反應很快，但在生產環境部署與雲端混合架構時，實測完後還是有一些需要考慮的架構取捨問題。

第一個是雲端 Prompt Caching 的失效問題，在一般的雲端架構裡，如果多輪對話全走同一家雲端 API，重複的前文享有高達 50% 到 90% 的快取折扣，但是在混合架構下，前三輪在本地 3050 跑 8B 模型，第四輪才因為 repeated_failure 突然切換到雲端 Claude-Sonnet-5.5 時，上下文已經累積了一定數量的 tokens，這一次跳轉產生的首次 pre-fill 費用，可能還是會吃掉前幾輪省下來的差價。

第二個是小模型的 Tool Use 穩定度，要讓本地 8B 模型跑前面幾輪的前提，是該模型必須具備穩定的 Function Calling 能力，如果 8B 模型在第二輪就產生了無效的 JSON 參數，導致工具根本無法執行，那它連觸發 repeated_failure 的機會都沒有，反而會直接把 Agent 卡死在語法錯誤上。

Switchyard 實測了幾天，的確是可以幫忙解決在 routine 工作的不少小雜事，下一步要解決的，可能還有兩件事，第一個是前面有提到的，要怎麼從拿到適當的訓練資料來做微調，讓他分流可以更為精準，第二個則是目前另一個大花費，讓 Agent 在控制瀏覽器時如果多次遇到 repeated_failure ，可以從local的 Gemma4 自動換到雲端的模型，並順利接手前面試過的這些 screen context ，如果有測試到不錯的結果再來跟大家分享。

實測 NVIDIA PAIR：RTX 3050 串接 Colab A100 混合叢集

JH5 — Thu, 29 Oct 2026 06:58:46 +0000

不知道你有沒有過這種經驗，你手邊腳邊剛好有很多小卡，每張卡 VRAM 都可以支撐一些 7B/8B 的小模型，看起來就很適合拿來派發給 Subagent 同步開跑，只是實際上要怎麼部署，要怎麼跨節點來處理，要怎麼在降低延遲建立統一 API 端點，處理負載平衡與階層模型路由場景，這一篇適合在找尋低成本幫本地 Agent 佇列塞車解法的人來看一下。

釐清本質：NVIDIA PAIR 到底能做什麼、不能做什麼？

在社群第一次看到 NVIDIA PAIR（Personal AI Router）開源時，直覺以為它是某種「VRAM 黑科技」，還幻想把家裡 8GB 小卡跟其他小卡記憶體黏在一起跑 70B 模型（光是網路就崩潰了ＸＤ）

NVIDIA PAIR 是基於 Apache 2.0 協議開源的本地推論路由代理層，特點是能將區域網路或混合雲的多台運算節點統一封裝為標準 OpenAI 與 Ollama 相容端點，透過請求層級（Request-level）的調度解決平行任務排隊問題。

基本上，它不做 Tensor Parallelism，也不做跨機器的模型 Sharding，所以如果你跟我前面幻想的一樣，那應該是無解，但是它真正解決的痛點是：當主 Agent 同時喚起多個 Subagent 分頭進行程式碼撰寫、靜態分析、Code Review 解析與網路查詢時，單張顯卡只能循序一個個排隊處理，而 GPU 運算單元在單一請求未達 batch 飽和時又吃不滿，這時，PAIR 的價值在於扮演 LB，可以幫忙把互不相干的獨立推論請求瞬間打散到多個閒置節點上並行跑完。

這邊要特別注意的是，PAIR 只專注於處理對話 Request 的負載平衡，它本身並不負責解讀對話內容的難易度，如果你需要的是更具彈性的「語意大腦」，讓小模型扛日常雜工、遇到連續出錯才自動升級雲端高級模型，這需要搭配另一套路由機制（詳見第二篇：《實測 NVIDIA Switchyard：RTX 3050 邊緣與雲端混合路由》）。

架構搭橋：透過 Colab CLI 與 SSH Tunnel 打通網路

先前的文章有介紹過免費的 Colab CLI A100/H100 真香 :) ，因此最近我都是把腳邊的小卡串接colab用好用滿，但是要把 Google Colab 上的 A100 納入本地 PAIR 叢集，最麻煩的是 Colab 執行個體位於 Google 內部容器網路，沒有固定公網 IP。

如果用 ngrok 或 Cloudflare Tunnel，也免費頻寬限制，每次重連還得手動抓新網址，維護成本很高，後來我都是直接用 google-colab-cli 提供的 colab ssh --proxy-mode，配合 SSH 指令建立 WebSocket-stdio Tunnel:

# 1. 在本地背景建立一條專屬的 SSH 本地連接埠轉發 (Port Forwarding)
ssh -N -L 11435:127.0.0.1:11434 \
    -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=30 \
    -o ServerAliveCountMax=3 \
    -o StrictHostKeyChecking=no \
    -o UserKnownHostsFile=/dev/null \
    -o ProxyCommand="/home/lamanwu/.local/bin/colab ssh --proxy-mode -s a100-c2c" \
    root@colab &

建起來後地端程式只要存取 http://127.0.0.1:11435，封包就會透過 WebSocket 直通 Colab A100 上跑的 Ollama 服務。

實際測一下連線品質，地端的 RTT 僅 3.08 ms，而 Colab 隧道的 RTT 落在 107.56 ms，如果是自己在家裡使用，100 ms 出頭的 delay 完全可以忽略。

基準實測

我整理了一些平常開發或是工作滿常遇到的案例來測試 Agent 並行子任務，再觀察一下 Wall-clock time。

1. 單節點處理

當 10 個請求同時灌進地端 llama3.1:8b 時，雖然底層推理服務具備基本的並行批次能力，但受到 VRAM 頻寬與運算核心限制，後續請求理所當然需要乖乖的排隊

總耗時：9.138 秒
總產出 Token：1,147 tokens
叢集有效吞吐量：125.52 tok/s
平均每題等待延遲：3.634 秒

2. PAIR 叢集負載平衡（RTX 3050 + Colab A100 對半平分）

接著將相同 10 組任務交由 PAIR 分流器以 Round-Robin 方式平均指派：5 題送地端 3050，5 題送雲端 A100。兩端均使用相同的 llama3.1:8b：

總耗時：4.611 秒
總產出 Token：1,160 tokens
叢集有效吞吐量：251.56 tok/s

測試架構	實體節點規格	總執行耗時 (s)	叢集吞吐量 (tok/s)	加速倍率
單節點基準	地端 RTX 3050 (8GB) 獨扛	9.138 s	125.52 tok/s	1.00x (基線)
PAIR 負載平衡	RTX 3050 (8GB) + Colab A100 (40GB)	4.611 s	251.56 tok/s	1.98x
高並發壓力	20 請求灌入雙節點 (100% 成功率)	4.930 s	243.46 tok/s	1.94x

最亮眼的發現是：即使雲端 A100 承受了 107 ms 的網路往返延遲，但由於 A100 的強大記憶體頻寬（1.6 TB/s）與 40GB VRAM 容量，其單題生成速度完全彌補了網路損耗，雙節點完美維持同步收尾節奏。

階層式模型分流：大小模型各司其職的生產實踐

除了齊頭式平分同一個模型之外，多節點混合架構另一個巨大優勢是模型階層分流（Model Tiering）。

在現實的軟體工程或生醫管線中，並不是每個請求都需要動用大參數模型。我們實測了這種工作流組態：

地端 RTX 3050 專責「日常例行雜工」：掛載 llama3.1:8b，專門處理 Bash 語法檢查、Regex 提取、FastQC 數值解讀。單題耗時落在 0.7s ~ 4.2s，地端零傳輸成本、零額外網路暴露。
雲端 Colab A100 專責「深度邏輯推理」：掛載參數較大的 qwen2.5:14b，專門扛下非小細胞肺癌 EGFR 標靶抗藥性機轉、Li-Fraumeni 症候群 TP53 致病性判斷等複雜多步論證。

在 10 題階層分級實測中，地端 3050 在 5 秒內就迅速清理完所有 routine 雜工，而 A100 則在 40GB VRAM 悠哉的完成 5 個 14B 深度推理報告。

20 並行任務高壓考驗：叢集容錯與真實瓶頸

為了驗證架構在高峰時期的穩定度，我把並發任務稍微拉高到 20 個請求同時灌入 PAIR 叢集。

實測結果也是滿不錯的：

20 個並行請求全部成功回傳（成功率 100%，無任何 timeout 或連線中斷）。
總耗時僅 4.93 秒，整體吞吐量維持在 243.46 tok/s 的高檔水位。

不過這次也小踩了兩個小坑：

Colab 連線生命週期風險：Google Colab 免費或 Pro 執行個體隨時有因閒置或搶佔（Preemption）而斷線的可能，實際測試過程中就常常ＧＧ要再重新建立Tunnel，還好一般在正式環境中，PAIR 可以搭配Heartbeat 與「自動 Fallback」的重試機制，否則網路一斷，掛在上面的 Agent 就會現場翻車。
多節點 Model Cache 暖機成本：第一次將請求派給尚未載入 VRAM 的節點時，Ollama 載入權重會產生一次性的記憶體搬移延遲（例如 3050 冷啟動約 16 秒）。因此在正式啟動 Agent 批量作業前，還是需要先對各節點發送請求來暖機一下。

三步搭建自己的 PAIR 混合叢集

如果也想要在自己的開發環境踹踹這套架構，只需要三個具體步驟：

取得 NVIDIA PAIR 核心二進位檔：從官方倉庫 NVIDIA/Personal-AI-Router 的 Releases 下載 Linux 版二進位包（內含 nvpair-proxy、inference-dispatcher 與 nvpair-cluster-manager）。
建立背景連線隧道：使用你慣用的 SSH 工具（或 Colab CLI）將遠端 GPU 伺服器的 11434 連接埠映射至本機的閒置連接埠（如 11435），或是如果你的Local就有兩個 Node，網路也是通的就可以略過這個步驟。
設定統一路由轉發：設定 PAIR 代理監聽在本地 19800，將本機 11434 與隧道 11435 登記為後端池，日後前端任何 Agent 框架（如 LangChain、LlamaIndex ）只要將 Base URL 指向 http://127.0.0.1:19800/v1，就能自動享受有 LB 的 LLM Endpoint。

直上 Production 嗎？

但如果你跟我一樣三不五時就把 Agy/ Opencode 額度燒完，又三不五時會有一些小需求要處理，目前這樣搭配 3050 + 免費 A100 已經可以處理滿多日常任務了，很多目前在本地 N8N上的日常抓資料小作業，我已經這樣 run了快一週了好像也沒出什麼太大差錯（偶爾tool calling會秀逗秀逗），趁 Google 還沒把這台 A100 連線收回去之前，我應該會再把一些 Endpoint assign到這些endpoint上來玩～

Production 建議還是先不要ＸＤ有太多架構上 HAProxy 或是 Failover 這篇都省略了ＸＤ

自訓練Unsloth決策模型讓 CVE 漏洞分流

JH5 — Tue, 20 Oct 2026 09:44:19 +0000

前兩篇我們聊過 vLLM Decision 3.0 地端實測與來訓練自己的 Jev 模型吧：)，大家對 Jev 與非自回歸決策架構應該都不陌生了。

但回到日常開發的現場，痛點往往更現實：每次 GitLab CI 或 GitHub Actions 跑完 Trivy 容器掃描，吐出一整大坨 CVE 清單，如果無腦拿去餵一般 LLM，寫一堆「請輸出包含 severity、attack_vector、remediation_sla 的 JSON 格式」，後果通常很慘烈。

當模型收到文字要先跑 Prefill，接著解碼 token 吐括號、鍵值和雙引號，而遇到新漏洞沒有明確 Patch 時，模型常在解碼階段胡思亂想，直接把下游的 Webhook 或自動化腳本炸爛。

設計決策目標

這次選用的標準資料集是美國國家漏洞資料庫的 harinpurumandla/cve-severity-dataset，收錄超過 15 萬筆資料。每筆資料包含原始 CVE 描述與標準 CVSS v3.1 向量字串（例如 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）。

我們寫了一套專屬的 CVSS 解析邏輯，直接從向量欄位抓取特徵，並將整體分類任務拆解為 3 個工程維運決策頭：

嚴重度分類 (severity)：critical、high、medium、low 四個等級。
攻擊路徑 (attack_vector)：network（網路攻擊）、adjacent（相鄰網路）、local（本機攻擊）、physical（實體接觸）。
修補 SLA 期限 (remediation_sla)：資安應變中心（SOC）的處理規範，包含 4h_emergency（4 小時內緊急處置）、24h_hotfix（24 小時內上熱修補）、next_sprint（併入下個迭代處理）。

把這 3 個欄位封裝成 Decision Head 定義，整個架構就成了標準的多工分類器。模型完全不需要花心力學習怎麼生逗號或引號，只要在潛在空間把注意力集中在描述中的關鍵漏洞 Pattern 即可：

# 3 個決策頭的題目與選項結構
questions = {
    "severity": {
        "question": "What is the severity of this vulnerability?",
        "choices": ["critical", "high", "medium", "low"],
    },
    "attack_vector": {
        "question": "What is the attack vector of this CVE?",
        "choices": ["network", "adjacent", "local", "physical"],
    },
    "remediation_sla": {
        "question": "What is the remediation SLA policy?",
        "choices": ["4h_emergency", "24h_hotfix", "next_sprint"],
    },
}

# 單次 Forward Pass 同步推論 3 個頭（僅 296 ms）
prediction = FastDecisionModel.predict(
    model, tokenizer, state=cve_description, questions=questions
)

# 輸出結果保證合法，包含各頭的信心度分數：
# {
#   "severity": {"label": "critical", "confidence": 0.884},
#   "attack_vector": {"label": "network", "confidence": 0.921},
#   "remediation_sla": {"label": "4h_emergency", "confidence": 0.852}
# }

實測單卡訓練

測試硬體是單張 NVIDIA GeForce RTX 3090 24GB，軟體環境為 PyTorch 2.6.0、CUDA 12.4 與 Unsloth 2026.10.3，底層模型挑選 unsloth/Qwen3.5-4B，載入 4-bit 量化權重，並設定 LoRA rank 16、alpha 16。

我們從資料庫抽取 1,000 筆作為訓練集，250 筆作為完全沒見過的獨立測試集。在微調前，我們先對驗證集進行 Zero-shot 評估，未訓練的隨機決策頭在 3 個目標上的綜合準確率只有 29.0%，而且 3 個頭同時猜對的機率直接見底掛零。

訓練過程：

Step 10: Loss = 1.1505 | Grad Norm = 1.76 | LR = 1.80e-4
Step 20: Loss = 0.8963 | Grad Norm = 1.17 | LR = 1.84e-4
Step 30: Loss = 0.7319 | Grad Norm = 10.32| LR = 1.36e-4
Step 40: Loss = 0.7806 | Grad Norm = 5.99 | LR = 7.51e-5
Step 50: Loss = 0.7162 | Grad Norm = 2.35 | LR = 2.29e-5
Step 60: Loss = 0.6414 | Grad Norm = 1.05 | LR = 1.97e-7

整整 60 個 Step 總共只跑了 547.8 秒（約 9.1 分鐘），最驚訝的是訓練過程中的 VRAM 峰值只有 7.453 GB，這也代表可以在同張卡背景掛另一個小模型做監控，VRAM 依然綽綽有餘。

訓練完成後重新驗證：

驗證集總體準確率從 29.0% 暴增到 75.67%，提升 +46.67%。
3 個決策全部同時命中的比例，直接從 0% 飆升到 55.0%。

在完全未參與訓練與校準的 250 筆獨立測試集（Held-out Test Set）上，模型拿到了 52.67% 的準確率，3 個決策頭同時命中率為 26.8%，對於一個只餵了不到 1,000 筆資料、跑不到 10 分鐘的 4B 模型來說，它已經能精準抓出 CVE 描述裡的關鍵攻擊特徵，應該已經很有潛力繼續往下探索了。

推論測試

模型訓練出來之後，上不上線完全取決於推論延遲速度。

我們抽取 50 筆測試案例讓微調後的 Decision Model 推論，因為是單次 Forward Pass 同時算完 3 個分類頭，50 筆全部跑完只花了 14.8 秒，平均每筆樣本耗時 296.2 毫秒。

為了公平比對，我們載入同樣是 4-bit 量化的 unsloth/Qwen3.5-4B 標準語言模型（FastLanguageModel），使用系統 Prompt 要求它解析相同 CVE 並輸出乾淨的 JSON 欄位。

在同樣的GPU上，生成平均產生 60 個 tokens 就花了 4,076.28 毫秒。

評測維度	傳統生成式 LLM (JSON Prompt)	Unsloth 決策模型 (FastDecisionModel)
單次推論延遲	4,076.28 ms	296.20 ms
推論吞吐量 (Throughput)	~0.24 筆/秒	~3.38 筆/秒
訓練 VRAM 峰值	~14-16 GB (全量文字微調)	7.453 GB (LoRA + 決策頭)
結構化保證	依賴 Regex 驗證或重試	100% 型別與合法值約束
輸出內容	自回歸生成 token 字串	各決策頭 Logits 與信心度數值

296 毫秒對 CI/CD 與資安通報意味著什麼？過去每分鐘只能處理 14 筆通報的單卡 Worker，換成決策模型後每分鐘可以消化超過 200 筆。當 Pipeline 掃完幾十個容器映像檔、湧入幾百筆 CVE 需要快速分流時，這 13 倍的差距就是 Pipeline 在 10 秒內跑完跟直接Timeout的差別。

執行溫度校準：讓決策頭信心度貼近真實防禦門檻

決策模型還有一個生成式 LLM 難以望其項背的優勢：機率校準。

生成式模型說「我 90% 確定這是 Critical」，通常只是當下 token 預測機率產生的假象，但決策模型輸出的是標準 Softmax 分佈，這讓我們可以透過驗證集計算溫度係數（Temperature Scaling）來縮放各決策頭的 Logits，讓模型回傳的信心度能真實對應到現實世界的命中機率。

實測結果滿有趣的，在 250 筆未參與微調的獨立測試集上，校準前的預期校準誤差（ECE, Expected Calibration Error）為 0.1457，但經過 100 筆驗證集算出來後，ECE 反而微幅飄到了 0.1799。

當驗證集只有 100 筆時，溫度參數容易過度貼合該小樣本的特定邊界，一旦推論到真實分佈稍有偏移的外部分佈（OOD）測試集，就會造成輕微的「過度平滑（Over-smoothing）」，這也告訴我們在正式環境裡，拿來算校準溫度的驗證集規模至少要拉到 500 到 1,000 筆或更多才夠讓表現更穩健。

不過即使是 0.1799 的水準，也足以讓我們在自動化流程中設定合理的門檻：例如「只有當 severity 信心度超過 0.85 時才自動觸發 PagerDuty 或開 Jira Ticket，其餘降級為人工二次檢核」，避免日常工作被垃圾告警疲勞轟炸。

盤點實作踩坑

在將 Qwen3.5 移植為決策模型的過程中，有兩個 Note:

第一，ClefDecisionModel 沒有 .generate() 方法。當你用 FastDecisionModel.from_pretrained() 載入模型時，Unsloth 會把 Transformer Backbone拔掉底層的 lm_head 改接 JointClassifierHead，如果你想在同一個物件上呼叫 .generate() 測試生成，程式會直接拋出 AttributeError 錯誤給你看，要進行生成式比對，還是必須另外透過 FastLanguageModel 載入標準權重。

第二，Qwen3.5 的 Processor 輸入格式要求。Qwen3.5 預設載入的是多模態的 Qwen2_5_VLProcessor，在呼叫 Tokenizer 時，如果直接寫 tokenizer(prompt)，在某些版本的 Hugging Face 套件中，會被誤判成帶有未指定影像特徵的參數，請明確指定關鍵字參數：tokenizer(text=prompt, return_tensors="pt")，才能保證單純的文字輸入正確被轉換。

評估架構選型：高併發 AIOps 該選生成還是決策？

當所有人都在談 Agent、都在想著怎麼讓模型用 Function Calling 寫 JSON 時，我們常常忘了工程的核心是「用最低成本、最快速度、最高可靠度解決問題」。

文字生成模型適合寫長篇分析、出滲透測試報告，但面對 Trivy 掃出來成百上千筆的 CVE 分流、Log 等級降噪、SRE 告警過濾這些需要確定性的日常雜工，把它們丟進一般的 LLM 根本是大砲打蒼蠅，還很容易給未來的自己挖坑。

而簡單訓練過後的決策模型，不到 10 分鐘的訓練時間、7.5 GB 的顯卡記憶體，換來的是 296 毫秒的極速反應與 100% 格式合規，在追求吞吐量與極致穩定的 CI/CD 現場，這才是把大模型落地最乾淨、最不折磨人的工程實踐。

來訓練自己的 Jev 模型吧：)

JH5 — Mon, 19 Oct 2026 14:14:02 +0000

覺得在應用中頻繁呼叫 Microsoft-Decision-1 或 Jev 等決策模型 API 太昂貴嗎？在現代的 AI Agent 架構中，高達八成的判斷節點需要的其實是「System 1」的直覺反射，而非傳統語言模型耗時的自回歸生成。

接下來的文章將完整記錄如何利用手邊的消費級GPU，在本地環境訓練出與微軟同款 Decision Head 架構的 Qwen3.5 決策模型，紀錄完整的訓練流程、A/B 對照組的延遲數據、機率校準表現，以及實際的應用場景，適合不想被雲端 API 綁架、希望在私有環境建立毫秒級高吞吐決策節點的工程師參考。

微軟 Microsoft-Decision-1 與 Jev 到底在做什麼

微軟在 2026 年 10 月推出了 Microsoft-Decision-1，號稱決策速度比 GPT-6 快上 35 倍，目前也直接掛在 Azure Foundry 和 OpenRouter 上收費，翻開規格一看，微軟採用的底模其實就是阿里巴巴開源的 Qwen3.5-9B，把開源底座加上分類訓練結果直接開賣，在商業上的手腳超快。

就想我們上一篇提到的，vLLM Decision 3.0 地端實測，
過去我們要把一段 Log 或工單分類，標準做法是寫一段長長的 Prompt，請模型「請只回傳 JSON 格式 {"category": "billing"}」，接著祈禱它不要加上 markdown 語法，然後在應用端用 Pydantic 或正規表達式硬解，一個二選一的問題，模型在背後自回歸吐了數十到數百個 token，動輒花費數秒，偶爾還會吐出格式炸裂的字串導致系統噴錯。

決策模型走的則是完全相反的路線。它代表的是認知架構裡的「System 1」— 直覺反射神經。

傳統語言模型在最後一層要將隱藏狀態投影到高達 15 萬維度（Vocab Size 約 152,064）的詞表空間，計算成本極為昂貴，而像 TypeSafe AI 的 Jev、Cloudflare 的 Clef，或是 Unsloth 這次整合的 Decision Head，是把 Sequence 的最後隱藏狀態抓出來做 Pooling，直接接上一組精簡的 Decision Head 再做一次 Forward Pass，幾百個維度的選項機率就全部算完了，推論過程根本不需要 decoding 迴圈。

24GB VRAM 微調

我拿手邊這台有 24GB VRAM 的機器來進行完整訓練與驗證。

底模選擇 unsloth/Qwen3.5-4B，搭配 4-bit 量化與 LoRA（rank=16, alpha=16），資料集採用開源決策基準 LocalLLaMA/typed-decisions，包含 1,120 筆訓練樣本、80 筆驗證樣本以及 400 筆獨立測試樣本。

訓練與驗證的核心數據如下：

指標項目	基準數據 / 實測結果
底模與量化	Qwen3.5-4B (4-bit QLoRA)
訓練峰值 VRAM	7.95 GB
訓練耗時	910.6 秒（約 15 分鐘）
零樣本初始準確率	30.5%
訓練後驗證集準確率	80.5%
400 筆未見測試集準確率	74.9%
期望校準誤差（ECE）	0.187 → 0.036
單次前向傳播平均延遲	191.4 ms

VRAM 的花費滿省的，4B 模型在 4-bit 狀態下，整趟訓練跑完 VRAM 最高峰值只有 7.95 GB，換算一下微軟採用的 Qwen3.5-9B 的 base Model，換算下來 VRAM 大概落在 14 到 16 GB 之間，如果手邊機器資源允許的話也可以上9B模型。

對照推論速度

雖然知道決策模型一定快，但是為了驗證「到底快了多少」，我在相同的 GPU 上進行了嚴格的 A/B 測試，一邊用傳統 Prompt 叫 Qwen3.5-4B 吐 JSON，另一邊用微調後的 Decision Head 進行測試。

實測數據差距：

對比項目	傳統生成式 Prompt	決策模型（Decision Head）
平均推論延遲	3,679.8 ms（約 3.7 秒）	191.4 ms（0.19 秒）
運算機制	逐 Token 生成（耗損 64 tokens）	單次 Forward Pass
格式可靠性	頻繁冒出 `<think>` 思考鏈、未完結	保證 100% 符合 JSON 格式
信心度資訊	無	自帶校準機率分佈向量

在測試傳統生成式模型時，新一代推理模型甚至在 Prompt 中自動冒出 <think> 思考標籤，寫到一半就撞上 max_tokens 限制，根本連 JSON 閉合括號都沒吐出來。而決策模型在 191 ms 內就交出乾淨的機率字典。

壓測多元任務並行

由於現實的情境通常沒那麼單純，我整理了幾種情況來測試它在多任務擴展與面對異常資料時的表現。

1. 多題擴展邊際成本：每題僅多 16 ms

在很多場景中，我們常希望同一段文字能同時回答多個問題（例如同時判斷「負責組別」與「緊急程度」）。

實測推論延遲的拆解結果：

單一問題（只問 team）：平均 175.28 ms
雙重問題（同時問 team + priority）：平均 191.35 ms
多問一個問題的邊際耗時：16.07 ms

主要原因還是因為整個context的 Backbone 特徵編碼只需要算一次，後面掛載的 Decision Head 只是非常輕量級的線性投影，這也意味著就算一次掛載 5 個分類判斷（組別、急迫性、情感、PII 洩漏、語言），推論延遲頂多增加 60 到 80 ms。

2. 面對無關垃圾訊息與歧義的機率反應

當我們丟入完全不相干的文字（例如抒情詩句「秋風穿過月光下的金黃落葉」）時，模型會亂問亂答嗎？

實測顯示，模型的最高信心度直接從原本的 99.9% 暴跌至 54.3%，機率被分散到各個選項中（billing 15.7%、technical_support 30.0%、account_management 54.3%）。

這個結果剛好可以用簡單的門檻值過濾異常輸入，避免LLM服務上線時被拿來亂戳亂打。

驗證跨領域場景

訓練完成後，我挑了兩個跨領域的實際情境來踹踹

情境一：高爭議客服工單路由

輸入情境：

"Hi, I was charged twice for invoice #4411. Please refund the duplicate transaction today."

模型輸出結果：

{
  "team": {
    "type": "choice",
    "choice": "billing",
    "confidence": 0.9997,
    "probabilities": {
      "billing": 0.9997,
      "technical_support": 0.0001,
      "account_management": 0.0002
    }
  },
  "priority": {
    "type": "choice",
    "choice": "high",
    "confidence": 0.8931,
    "probabilities": {
      "high": 0.8931,
      "medium": 0.1053,
      "low": 0.0016
    }
  }
}

模型毫不猶豫地給出 99.97% 的 billing 機率，並且把牽涉到重複扣款的問題評定為 89.31% 的 high priority。

情境二：生物資訊管線次世代定序（NGS）品質異常警報

在我們的基因檢測分析管線中，定序批次的品質檢測往往需要工程師人工看圖判斷。我給了模型一段真實的品質異常描述：

"Sample HG002 WGS sequencing run finished. FastQC reports mean Phred score Q18 at read cycle 120-150, duplication rate 42%, GC content abnormal spike at 65%. DeepVariant call rate dropped by 28%."

要求模型給出處置動作與風險評估：

{
  "action": {
    "type": "choice",
    "choice": "manual_bioinfo_review",
    "confidence": 0.7721,
    "probabilities": {
      "resequence": 0.2215,
      "manual_bioinfo_review": 0.7721,
      "pass_to_pipeline": 0.0063
    }
  },
  "risk_level": {
    "type": "choice",
    "choice": "moderate",
    "confidence": 0.847,
    "probabilities": {
      "critical": 0.1527,
      "moderate": 0.847,
      "low": 0.0002
    }
  }
}

這個結果滿有意思的，模型沒有直接放行（pass 機率只有 0.63%），但也沒有武斷地要求重跑，而是給出 77.21% 的信心度要求人為介入複查。

專模專用的 System 1 架構

過去兩年，我們習慣依賴大型語言模型解決「複雜邏輯推理」與「表達」的問題。但回到真實的系統架構中，每天成千上萬次的意圖路由、資安過濾或狀態判斷，需要的只是快、準、省資源的「條件反射」。

在我的實測經驗中，如果系統每天需要吞吐大量決策，完全不值得承擔雲端 API 的 Token 費用與動輒數百毫秒的網路延遲。只要有一張消費級顯卡，我們就能在本地端完成 Decision Head 訓練與部署。特別是對於需要處理機敏資料或病患資訊（如前述的基因定序品質檢測）的場景，資料不落地且自帶機率信心度的決策模型，才是企業級 AI 應用真正具備高性價比的架構選擇。

vLLM Decision 3.0 地端實測

JH5 — Mon, 19 Oct 2026 13:19:50 +0000

讓 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 延遲過高的痛點嗎？歡迎在留言區分享你的看法。

免費的 Colab CLI A100/H100 真香 :)

JH5 — Tue, 13 Oct 2026 07:56:52 +0000

前幾天同事在 Slack 丟了 AIPostHub 那篇 Google AI Pro 加入 Colab 算力：A100 80GB 能讓 Gemma 實驗走多遠？，大家都在討論手上訂閱的 Google AI Pro 到底能不能拿來當臨時運算節點。畢竟在Lab平常腳邊只有 24 GB VRAM，平常測 26B 或 31B 模型 VRAM 塞到 20.7 GB 就快見底，稍微放長一點的 Prompt 就容易 OOM。

剛好手上有訂閱，決定直接拿本地主機連上去，從認證、實例開立到模型載入，把整個真實工作流徹底測過一遍。

拆解 CLI 雙胞胎

在本地終端機想要自動化調度 Colab，第一個最常踩的巨雷就是套件名稱。

PyPI 上有一個老套件叫 colab-cli（版本 2.2.5），如果你下了 pip install colab-cli，它會把環境裡的 click 降級到 7.1.2，當場套件依賴衝突直接翻車。翻一下它的原始碼就知道，它只是幾年前包了 pydrive 的上傳小工具，只能把本地 .ipynb 同步到 Google Drive 再幫你開瀏覽器分頁，根本沒有遠端調用 GPU 的能力。

真正的官方工具是 Google 在 2026 年推出的 google-colab-cli（最新版本 0.7.4，執行檔名稱為 colab，要求 Python 3.12+）：

# 用 uv 安裝官方 CLI
uv tool install --python 3.12 google-colab-cli

安裝完成後敲 colab --help，你會看到包括 colab new、colab exec、colab ssh、colab usage、colab log、colab run 在內的整套現代管理指令。

接軌官方工具：google-colab-cli 搞定 OAuth 與 A100 實例

第一次使用時，執行 colab usage 會觸發 Google OAuth 授權流程。終端機會印出一串 Google 帳號授權 URL，用瀏覽器打開、登入訂閱了 Google AI Pro 的帳號並核准權限後，把網頁上的授權碼貼回終端機：

Enter the authorization code: 4/0AXlqoi4...
Current balance: 200.00 compute units
Usage rate: 0.00/hr
Active assignments: 0

Google AI Pro 帳號直接帶入 200.00 點運算單元（Compute Units）。

接著直接下一行指令，在背景向 Google 要求一台 A100 執行個體：

colab new --session gemma-test --gpu A100

只花了大約 5 秒鐘，終端機就回傳 [colab] Session READY.。

實測 Gemma 4 推論：100% GPU 卸載飆出 179 tok/s

A100 是 NVIDIA 專為高負載計算設計的加速卡，特點是具備極高的記憶體頻寬與張量核心算力，能讓大規模語言模型維持全 GPU 卸載執行。

我們透過 colab exec 直接在遠端實例部署 Ollama，並拉取參數量達 25.8B 的 gemma4:26b（GGUF Q4_K_M，檔案 17.9 GB）進行臨床變異推論測試。

在 Colab A100 上的實際執行數據如下：

# 查詢遠端實例 VRAM 分佈
nvidia-smi --query-gpu=name,memory.total,memory.used --format=csv
# 輸出：NVIDIA A100-SXM4-40GB, 40960 MiB, 20072 MiB

模型順利吃下 20,072 MiB VRAM，達到 100% GPU 卸載，主機還有 83.5 GB RAM 與超過 20 GB 的 VRAM 緩衝空間。

我們輸入經典的乳癌基因臨床考題：

"What is the role of BRCA1 in breast cancer? Give a 2-sentence clinical summary."

模型先觸發內建的思考鏈（Thinking Process）完成約 270 個 tokens 的自我推導，隨後產出結構完整的兩句話臨床結論：

BRCA1 is a critical tumor suppressor gene responsible for maintaining genomic stability through the repair of double-strand DNA breaks via homologous recombination. Pathogenic mutations in this gene impair DNA repair mechanisms, significantly increasing the lifetime risk of developing hereditary breast, ovarian, and other related malignancies.

效能表現相當驚人：

生成時間：2.16 秒（共產出 369 tokens）
生成速度：⚡ 179.42 tok/s
上下文視窗：Ollama 預設分配 32,768 tokens（32K context）

盤點即時監控維度：從點數流速到一鍵導出 ipynb

當你的任務正在 Colab 遠端執行時，你還可以透過 CLI 監控健康度與資源消耗：

1. 算力與點數計費狀態（`colab usage`）

這條指令會回傳帳號層級的點數流速：

Current balance: 197.28 compute units
Usage rate: 5.30/hr
Active assignments: 1

我們從一開始的 200.00 點跑完環境建置、下載 18GB 模型與推論，大約過了 30 分鐘，點數扣至 197.28 點，實際驗證扣款速率確實鎖定在 5.30 點/小時。

2. 實例運作狀態（`colab status -s gemma-test`）

查詢實例生命週期與最近一次命令執行：

[gemma-test] gpu-a100-s-kkb-usc1f1-ryarjq9kw3qd | Hardware: A100 | Shape: Standard | Variant: GPU | Status: IDLE
  Last Execution: stdin at 2026-10-12 08:26:15

當任務正在跑時狀態會轉為 RUNNING，空閒時為 IDLE。

3. 硬體級別監控（`colab exec -s gemma-test "nvidia-smi"`）

可以直接撈出 GPU 實體指標：

溫度與功耗：32°C，待機 47.19W（推論瞬間衝上 180W+，硬體上限 400W）
VRAM 分配：20,072 MiB / 40,960 MiB（空載時僅佔 6 MiB）
主機組態：12 個 CPU 邏輯核心、83.47 GB 主機記憶體、235.68 GB NVMe 磁碟空間

4. 服務層監控（`colab exec -s gemma-test "ollama ps"`）

確認模型是否真正常駐 VRAM：

NAME          ID              SIZE      PROCESSOR    CONTEXT    RUNNER
gemma4:26b    001e5dafc3c7    1.2 GB    100% GPU     32768      llamacpp

Ollama 預設在閒置 5 分鐘後會自動釋放 VRAM，避免背景長駐佔用資源。

5. 執行歷史與一鍵導出 Notebook（`colab log`）

這是我認為官方 CLI 最強大的功能之一。它在本地紀錄了每次透過 stdin 或檔案丟上去的 microsecond 級別執行日誌。下這行指令：

colab log -s gemma-test -o colab_a100_gemma4_replay.ipynb

它會直接把這半小時內所有的輸入、輸出、測試日誌自動打平成一份 728 KB 的標準 .ipynb 檔案。其他人打開就能看見所有 cell 的輸出結果，完全重現實驗。

解讀點數與定價機制：Pay As You Go 隨選加購怎麼算

在 Colab 介面點選資源分頁的「深入瞭解」，或者在終端機敲 colab pay，系統會直接引導你打開官方的 Colab 付費方案與定價說明頁面（Colab Paid Services Pricing）。

這個頁面說明了 Google 對 Colab 算力的計費哲學：

Google AI Pro / Colab Pro 訂閱制：
- 每月固定配發算力點數（如 Google AI Pro 配發 200 點）。
- 解鎖高階硬體配額（A100、TPU v5e 等），並擁有比免費版更高的排隊優先權。
Pay As You Go（隨選運算單元）加購制：
- 當你的 200 點在某個月高強度微調用光時，不需要被綁定更貴的企業合約，可以單次隨選加購點數（100 點約 9.99 美元）。
- 加購的運算單元只要帳號有效就不會過期，會自動接在每月的免費額度後面扣除。
真實消耗時間折算：
依我們這次實測的真實扣點速率（標準 A100 實例每小時扣除 5.30 點）：

   200 點 ÷ 5.30 點/小時 ≈ 37.7 小時

連續跑能撐 37.7 小時。如果每一次 Prompt 評測只佔用 20 分鐘，這 200 點足夠支撐超過 100 次完整的推論工作階段。

最省錢的操作是利用 CLI 提供的 Ephemeral Job Runner：

colab run -s gemma-eval --gpu A100 my_benchmark.py

這個指令會在雲端開機、跑完腳本、抓回輸出、立刻自動關機釋放，連手動下 colab stop 都不用，點數一秒鐘都不會多漏。

結語與日常建議

「免費的 Colab CLI + A100/H100」是個漂亮的社群包裝，本質上是 Google AI Pro 每月 200 點運算額度的精準變現。

換算下來每個月能拿來跑約 37.7 小時的 A100 高算力。只要搭配 google-colab-cli 的自動化指令，配合 colab run 或跑完隨手 colab stop，把它當作地端 3090 吃緊時的臨時雲端外掛，就是目前性價比最高的用法。

「辛苦弄了半天，老闆卻說：這一定是 AI 做的吧？」這兩年導入 AI 開發，很多人面臨一個荒謬的循環：功勞被 AI 稀釋，但只要有一點小 Bug，責任就被無限放大，被唸說「你是不是都貼 AI 產生的沒檢查？」。這其實是「AI 功勞歸因偏誤」。旁人只看見 AI 三秒產出程式碼，卻忽略了工程師為了驗證輸出、處理系統特例所花費的龐大心力。過去在白板上的討論與掙扎，現在都被隱藏在跟 AI 的對話框裡了。身處 AI 時代，我們該如何自處？ #軟體工程 #工程師 #技術管理 #職場溝通 #職涯發展 #AI

JH5 — Wed, 30 Sep 2026 13:14:37 +0000

JH5

Sep 30

做得好算 AI 的、做錯算你無腦貼？拆解 AI 功勞歸因偏誤與瑞士刀求生法

#career #productivity #management #ai

1 min read

KubeSummit 2026 小記

JH5 — Mon, 14 Sep 2026 14:15:09 +0000

上週去了 KubeSummit 2026，每年晃去總會湧現一股「想當年」的懷舊感，腦海中不禁浮現早期為了架設 1.1x 環境而加班的日子，不過也強烈感受到 Kubernetes 生態系已經徹底從早期的微服務調度，全面轉向 AI 工作負載 (AI Workloads) 。

特別是 Agent AI 跳耀式發展的這兩年，跟平台工程有關的的技術討論收斂非常明顯，稍微記錄一下有聽到＋沒聽到＋有想到的幾個議題。

K8s 基礎設施的 M 型化這兩年來這1-2年來特別是 DRA 的成熟，解決了過去 GPU 資源分配僵化的痛點，對 GPU 切割 (MIG, Time-slicing) 有了更原生的支援，而 eBPF 提供的Observability也幾乎解掉過去網路與資安的不少盲點＆issue。

從現場的擺攤的幾家大型地端提供商來看，因為 AI 算力資料不出境、醫療或高科技製造的隱私需求，企業必須在地端自建龐大的 GPU 叢集，而這也促使各大基礎設施廠商快速跟進，提供整合式的 GPU 驅動與監控方案，整體技術成熟度與客戶規模都有著顯著的成長。

Day 2 維運與 SRE Agent 的實踐

面對極度複雜的 Day 2 維運，SRE Agent 成為釋放 Infra 團隊壓力的解方，今年議程中展示了利用類似 ReAct 模式的 Agent 架構來處理系統異常。當開發者遇到 Pod Pending 或 OOM 時，SRE Agent 能自動調用 kubectl 或查詢log/metrics，並用自然語言回覆診斷結果，必要時也可以在規定的namespace內直接動手修復，這種將 LLM 結合工具呼叫 (Tool Calling) 的應用，直接把SRE 升級成高級大人版ＸＤ。

不過，相比於年中在 CyberSec 看到各大廠積極推展的 SIEM Agent，K8s 領域的 SRE Agent 實際落地的企業案例在體感上似乎相對較少，這點值得持續觀察。

也記錄一下一些想聽沒聽到的topic

Ray Serve + vLLM
雖然 vLLM 已經是 LLMOps 的標配，但在處理大規模、跨節點的分散式推論請求時，滿多blog post 都會推崇 Ray Serve 作為排程與資源分配的上層框架，再結合底層的 vLLM 引擎，這次好像沒有看到類似的分享。
企業級地端 LLM Serving 的架構斷層
大家都知道怎麼用 vLLM 把模型跑起來，現場的解決方案商也都有在自己的場次提到可行，但要讓內部開發者享受到類似 Claude 或 GitHub Copilot 的體驗，地端架構在「算力」與「體驗」之間仍存在一層厚厚的斷層。這包含了需要 LiteLLM 來統一 API 與分流任務、上下文管理、RAG 基礎設施，以及完整的工具呼叫層。如果有個support百人團隊的地端 Qwen/Gemma 服務經驗分享，是不是很棒？
WebAssembly (Wasm) 與邊緣輕量化
Wasm 比 Container 更極致的微秒級冷啟動速度與沙盒安全性，對於未來需要部署到極端邊緣 (Edge AI) 或是高度要求冷啟動效能的 Serverless 推論場景，Wasm 與 K8s 的深度綁定極具潛力，也十分期待未來能聽到更多相關的實戰技術體驗。

從 Infrastructure as Code 到現今的 AI as a Service，Kubernetes 正在經歷一場本質上的蛻變，它不再只是一個單純的容器調度平台，而是逐漸成為企業級 AI 算力與 Agentic 應用的底層作業系統。

用 Vercel AI SDK 玩轉 Chrome Built-in AI

JH5 — Sat, 29 Aug 2026 01:02:59 +0000

Google 官方關於 Chrome Built-in AI 與 Vercel AI SDK 的文件寫了一大堆，但看完會發現官方範例只教你怎麼印出 Hello World，好多坑都沒有交代。

如果模型還沒下載完該怎麼辦？瀏覽器不支援時怎麼辦？Tool Calling 的介面要怎麼安全的接上？附上在 Chrome上的一些踩坑小筆記，幫你想在前端加上本地 LLM 時少走彎路（雖然彎路的都記得比較久ＸＤ）！

官方範例

Google 官方有兩篇基礎教學，繁體中文版都寫得清楚：

看完你大概可以了解，可以用browserAI() 把 model 丟進 generateText、streamText、Output.object，大概 30 行就能跑，但官方範例大多著重在「API 長什麼樣」...

@browser-ai/core

@browser-ai/core 是 Chrome Built-in AI 接到 AI SDK 的 provider，特點是同時支援 AI SDK v5-7，且跨三個本地引擎(Prompt API、Transformers.js、WebLLM )共用同一套 API，目前在「瀏覽器本地推理」這個領域已經是最主要的Tool。

作者是 jakobhoeg/browser-ai的 Jakob Hoeg Mørk，2025 年開始維護，進過 Chrome for Developers 的贊助名單，現在掛在 Vercel OSS Program 底下。

import { generateText } from "ai";
import { browserAI } from "@browser-ai/core";

const result = await generateText({
  model: browserAI(),
  prompt: "Invent a new holiday.",
});

當「模型還沒下載」的狀況發生時，availability() 會回 unavailable（瀏覽器不支援）或 downloadable（可以下載），配合 createSessionWithProgress 我們就能拿到下載百分比，這對于前端無論開發什麼樣的應用，都是給使用者第一層的UX，大部分的首次下載要吞好幾 GB的等待時間。

next-hybrid

在 jakobhoeg/browser-ai 同一個 repo 底下的 examples/next-hybrid 也滿值得一看的，它比官方範例完整太多，而且目前都是完整的可demo範例，建議可以直接當 template 複製，他也像我們之前測試transformer/webgpu 一樣，同時接了三種引擎（browser / transformers-js / web-llm）也在ＵＩ上做了下拉選單可以即時切換，讓使用者可以同一份 streamText 程式碼，本地模型、WebGPU 模型、雲端模型切換成整合或是測試。

有兩個實作細節滿值得整合前端應用的參考的：

自訂 ChatTransport 接 useChat
用 ClientSideChatTransport 把 React 的 useChat 綁到本地模型來讓整個聊天流程跑在客戶端，連 server 都不用起，萬一有一天你不想用本地模型了，換回 DefaultChatTransport 就切到 server API，前端程式碼一行不用改。
tool calling 的完整流程
它示範了 webSearch（用 Exa API）和 getCurrentTime 兩個 tool，加上 toolApproval 的確認 UI，如果模型想動用外部 API 前，會先跳出一個確認框讓使用者同意確認，這對安全敏感的醫療或金融企業場景，可以配合紀錄一些符合法規面需求的Audit Log

domainstack.io

jakejarvis/domainstack.io 是目前找得到最接近 production 的案例，而且是少數用 @browser-ai/core 的第三方專案，它做的是網域名稱查詢工具，雖然串接 AI 只是其中一小部分功能，但架構完整到可以拿來當作範本。

跟我們前面提到的場域類似，核心設計是三種模式自動切換：local（本機）、cloud（雲端）、auto（本機不可用就 fallback），useBrowserAI hook 會先查 availability()，如果瀏覽器不支援就默默的切到雲端 API，對於使用者完全無感。另外它示範了讓本地模型呼叫 tRPC 的 tool（WHOIS、DNS、SSL 查詢），也證明本地 LLM 做 agentic workflow 是可行的，不是只能聊天。

實測小小筆記

API 只能在安全環境（Secure Context）運行
如果你在 about:blank 測試，window.LanguageModel 會直接回傳 undefined，改到 http://localhost 或 HTTPS 環境下，API 才會正常。
模型下載必須由「真實使用者互動」觸發
直接在程式碼初始化呼叫 LanguageModel.create() 會直接報錯：NotAllowedError: Requires a user gesture，這代表不能在頁面載入時自動背景下載，必須由使用者點擊按鈕等主動觸發。因此，如果你用 Headless 測試，必須透過 CDP（Chrome DevTools Protocol）發送 Input.dispatchMouseEvent 來模擬真實的滑鼠點擊事件才可以正常的執行。
硬體硬性門檻
在 chrome://on-device-internals 的 Broker State 系統紀錄中，明確標示需要 20480 MiB required，測試時我的 MBA 原本只剩 4.7GB，模型下載停住，直到清出 23GB 空間後，下載狀態才順利轉綠開始執行。

總結來說，Chrome Built-in AI 的核心優勢不在於頂尖的算力或模型表現，而是在於零 API Key 成本、零代管費用，以及資料絕對不出裝置的隱私安全，再搭配 Vercel AI SDK 後，本地模型與雲端 LLM 的切換只需要一行 Provider 設定就可以搞定。

如果你正準備踹踹，建議路線如下：

快速驗證：用 browserAI() + generateText，30 行內快速跑通。

完整架構學習：直接 Fork next-hybrid 當專案骨架。

生產環境：參考 domainstack.io 的自動 Fallback 策略與 Tool Calling 設計。

目前整個瀏覽器本地 AI 生態還處於早期階段，大部分開發者都還在摸索，趁現在掌握這些工具與解決方案，就能為你的前端專案搶先整合本地 AI 的優勢！

如何用 WebMCP 讓你的網站對 Agent 開放？

JH5 — Thu, 20 Aug 2026 13:52:13 +0000

想像一下，未來的 AI Agent 幫你在網頁上訂機票、買東西時，不再需要靠「螢幕截圖 + 猜按鈕」這種網站一改版就崩潰的方式，而是你的網站主動對 Agent 宣告：「我有這些 API，你可以直接呼叫」。

這就是 W3C 正熱烈討論中的 WebMCP（Web Model Context Protocol）。

如果說各路大神推出的 MCP 是讓 AI 操作你的「後端伺服器」，那麼 WebMCP 就是讓 AI 直接在「使用者瀏覽器」裡流暢操作 UI 的關鍵最後一哩路，這篇文章會用 Chrome 151 實測，帶你快速掌握宣告式（Declarative）與命令式（Imperative）API 的差異，並透過官方 3 個真實使用者案例，看看工具如何隨頁面動態長出！

WebMCP 是什麼?

WebMCP（Web Model Context Protocol）是 W3C 正在討論的網頁標準，核心概念是網站用 JavaScript 或 HTML 註解，向具備代理能力的瀏覽器註冊「工具」，而當 Agent 代理碰到註冊過的工具，就可以直接呼叫相關函式並拿到結構化結果，不用再靠螢幕截圖 + 猜按鈕。

MCP 是後端標準，讓代理連到你的伺服器拿資料；WebMCP 是前端標準，讓代理在你開著的這個分頁裡操作 UI。

MCP 的生命週期是永久的（伺服器常駐），而WebMCP 是暫時的（關掉分頁就沒了），在你的服務上如果同時提供了MCP與WebMCP，便可以理解成 MCP 管核心邏輯，WebMCP 管最後一哩的使用者介面處理。

宣告式 API：兩個屬性，表單直接變成工具

宣告式 API 是 WebMCP 的最吸引人的部分，你不用寫一行 JavaScript，直接在 <form> 上加上 toolname 和 tooldescription的注記就完成tool的註冊：

<form toolname="createSupportRequest"
      tooldescription="Submits a request for customer support.">
  <label for="name">姓名</label>
  <input type="text" id="name" name="name">
  <label for="topic">問題類型</label>
  <select name="topic" toolparamdescription="決定問題要路由給哪個團隊">
    <option value="billing">帳單問題</option>
    <option value="tech">技術問題</option>
  </select>
  <button type="submit">送出</button>
</form>

實測後發現 document.modelContext.getTools() 會自動把這個表單轉成完整的 JSON Schema——<select> 的選項變成 anyOf + enum，toolparamdescription ，而 <label> 的中文文字變成欄位說明，也就是說當Agent 識別到這個 schema 後，就知道這個表單可以填什麼，以及每個欄位接受什麼值。

進階控制有三個屬性可以玩：

toolparamdescription：單一欄位的用途說明，沒寫就用 <label> 的文字。
toolautosubmit：加上後，代理呼叫工具會直接提交表單並導航，不用等人按送出。
SubmitEvent.agentInvoked：表單提交時這個布林值會告訴你「這次提交是代理發起的」。搭配 respondWith(Promise) 可以讓代理拿到非同步的執行結果。

另外還有 :tool-form-active 和 :tool-submit-active 兩個 CSS pseudo-class，讓代理在填表單時可以用來顯示正在輸入的欄位，使用者也可以看得到「AI 正在幫我填」的ＵＩ顯示。

命令式 API

命令式 API 適合在不是表單處理的場景來做使用——像是查訂單狀態、跑診斷、做狀態管理，主要提供三個方法，全部掛在 document.modelContext 上：

// 註冊工具
await document.modelContext.registerTool({
  name: 'get_order_status',
  description: '查詢訂單狀態，回傳訂單編號、運送狀態與地點',
  inputSchema: {
    type: 'object',
    properties: {
      orderId: { type: 'string', description: '訂單編號' }
    },
    required: ['orderId']
  },
  execute: async ({ orderId }) => {
    return `訂單 ${orderId} 已出貨，狀態：運送中`;
  },
});

// 列出可用工具
const tools = await document.modelContext.getTools();

// 手動執行工具
const result = await document.modelContext.executeTool(tools[0], '{"orderId": "ORD-123"}');

實測的三個方法全部正常：registerTool 成功註冊、getTools() 同時列出自訂工具和宣告式表單工具、executeTool 正確回傳執行結果，另外 toolchange 事件在工具清單變更時會觸發，AbortSignal 則可以取消工具執行或註冊。

不過有個說明有寫但是不是太清楚的部分是，Chrome 150 已把 navigator.modelContext 淘汰，改用 document.modelContext （W3C Web Incubator Community Group 討論中）。不過我的 Chrome 151 上兩者都還是 object，記得此時此刻如果要開工的話，就一律用 document.modelContext 就對了。

官方 demo 的旅程

官方 webmcp-tools repo 的 demos 資料夾有 15 個情境，我試了幾個比較完整 UX 的實測，這邊有一個跟Server MCP比較不一樣的，WebMCP 工具不是一次全給的，而是會跟著頁面狀態長出來

WebMCP Sports

WebMCP Sports 是 Angular 寫的體育用品電商，首頁有 5 個全站工具：

search_product
view_product
get_product_info
open_cart
get_store_promos_and_rules

在實測中 search_product {"query":"basketball","category":"BASKETBALL"}，得到回傳 count:5 並切到搜尋結果頁，getTools() 結果直接變成 8 個，多出

refine_search
get_current_search_results
add_search_result_to_cart

接著再呼叫 open_cart 開購物車，工具一口氣長到 13 個ＸＤ
結帳相關的tool都飄出來了

start_checkout
confirm_order
update_cart_delivery_option
remove_from_cart
get_cart

突然有一種以前在練習寫購物車的架構與function標準答案一一浮現的感覺。

三層 scope 的設計讓全站工具、搜尋頁工具、購物車工具分層註冊，Agent 當下能看到的最小工具set，永遠只跟目前 UI 狀態匹配，比起一般的 MCP 一次註冊 20 個工具，這種設計讓Agent不會亂呼叫不該叫的工具反而好很多，應該也比較省Token。

而工具自己也會驗證參數。我故意傳 {"price_range":"wrong"} 給 refine_search，結果 WebMCP 回傳 {"success":false,"message":"Invalid price range 'undefined'. Must be one of: 'all', '0-49.99', '50-99.99', '100+'"}。

另外它還內嵌一個 Gemini on-site AI assistant，站在網站自己那一側幫你聊天導購。「網站自帶代理」跟瀏覽器層級的代理是兩條路線，這個 demo 兩條都示範了。

L'Atelier 飯店訂房

另一個範例 L'Atelier 是 React 寫的豪華飯店訂房 app，東京、巴黎、紐約三家分店。首頁先是註冊了三個工具。

search_location
view_hotel
lookup_amenity

我從 DevTools Protocol 直接呼叫 executeTool(search_location, {"query":"Tokyo"})，回傳值是這樣的：

{"content":[{"type":"text","text":"{\"success\":true,\"message\":\"Navigated to search results for Tokyo with active search filters applied.\"}"}]}

這邊要注意的是回傳的結果包了一層 content 陣列，很多時候 WebMCP 的執行結果就是 MCP 的 content block 格式，而在我呼叫完 getTools()，工具清單又變成 6 個，多出了

filter_search_results
get_current_search_results
reset_filters

搜尋結果頁有自己的工具，代理跳到哪一頁，哪一頁的工具才上線。

除了基本的防呆之外，WebMCP 也提供狀態檢查，我手癢直接 view_hotel，回傳 {"success":false,"error":"Could not find a hotel matching \"1\". Please search first."}。

而代理亂呼叫也是會被擋的，start_booking 在搜尋結果頁根本不存在，要到飯店詳情頁才註冊，而整條操作旅程的最後一步（complete_booking 填客人資料）是宣告式表單，命令式 API 開頭、宣告式API 收尾，跟在真實 app 裡的架構上滿match的。

一些小限制們

WebMCP 有三個明確的限制：

一定要有瀏覽器環境。 工具呼叫是在 JavaScript 裡處理的，所以代理必須真的開著一個可見的分頁或 WebView，headless 環境下無法呼叫，這跟 MCP server 隨時待命完全不同。

網站太複雜會很痛。 如果頁面狀態複雜，要利用 JavaScript 去處理應用程式和 UI 狀態的同步，宣告式 API 也幫不了你，Agent能不能利用工具來探索性也是問題，也之後就會有給 Agent看的 sitemap ？

權限政策和跨源 iframe。 工具預設被 tools Permissions Policy 擋住（Same-Origin Policy），跨源 iframe 要加 allow="tools" 且網域需在白名單內，跨源分享工具還要 exposedTo + fromOrigins 兩個參數都設定才生效，以防止潛在的 Clickjacking 與工具注入攻擊

開始的起手式

開 flag：chrome://flags/#enable-webmcp-testing 設為 Enabled，重啟 Chrome。正式環境去加入 WebMCP origin trial。
選一個表單下手：找站上最常用的搜尋或表單，加上 toolname 和 tooldescription，最多 5 分鐘。
用 Inspector 驗證：裝 Model Context Tool Inspector 擴充功能，看工具有沒有正確註冊、schema 對不對，再用自然語言 prompt 叫代理執行。

從「給人看」到「給 Agent 用」的 Web 前端新浪潮

WebMCP 的核心價值，不是讓網站多一個花哨的 AI 聊天視窗，而是讓你的網站直接升級為 Agent Ecosystem（代理生態系）的成員。

瀏覽器跑 LLM 的實際體感與骨感限制

JH5 — Thu, 13 Aug 2026 03:07:17 +0000

直接在瀏覽器跑 LLM，既兼顧隱私又不用複雜的GPU設定，太完美了吧？

從 WebLLM 到 Transformers.js，前端社群有一群反骨仔吹起一股「邊緣 LLM」的熱潮，可是，當真正將模型落地到使用者的瀏覽器時，第一個面對的考驗就是，WebGPU 真的有比 WASM 快嗎？

這陣子實測的結論比想像中更加戲劇化， 500M 以下的微型模型，WASM 反而快了 12%，但是對於 3B 以上的大模型，WASM 直接變成悲劇，直接讓Chrome撞的頭破血流（Chrome 沒有頭＝ Headless Chrome）。

測試環境

項目	規格
機器	MacBook Air M2, 8GB RAM
GPU	Apple M2, 8 核心
磁碟可用空間	9.7GB
瀏覽器	Chrome 136 (Playwright headless)
框架	WebLLM 0.2.84, @xenova/transformers 2.17.2

一開始遇到我的破MBA 8GB 機型的磁碟剩 9.7GB，這直接觸發了瀏覽器 Cache API 的物理配額限制（約為可用空間的 10%，即 ~970MB），這個限制直接決定了前端能載入的模型體積。

Phi-3.5 Mini @ MBA

原定計畫是測試熱門輕量級模型 Phi-3.5-mini-instruct（3.8B 參數），然而在 8GB MacBook Air 上，模型連載入都不行。

Phi-3.5-mini-instruct-q4f16_1-MLC 需佔用約 2,520 MB VRAM，當權重檔案下載到瀏覽器後，就出線 QuotaExceededError，即使換了一些快取的策略，還是都不行：

Cache API（預設）：QuotaExceededError: Quota exceeded
IndexedDB：ArtifactIndexedDBCache failed to fetch
OPFS：SecurityError: unsafe file access

在 8GB 記憶體且磁碟空間不足的裝置上，3.8B 模型完全無法運作，瀏覽器儲存配額（Storage Quota）直接被吃滿。

Phi-3.5 Mini @ MStudio

為了確認是否是儲存配額問題，我改用 M2 Max 運行相同的 WebLLM 代碼與 Phi-3.5-mini-instruct-q4f16_1-MLC 模型：

結果：

指標	M2 Max
tok/s	57.4
準確率	90.0%（10 題對 9 題）
總 tokens	956
總時間	16.66s
模型載入	一次成功

輸出 57.4 tok/s 速度在中文字的回覆上極度流暢，簡單的丟了一些問題，數學邏輯題，程式碼產出與生物資訊（Variant calling/WES）相關問答回答的也是有模有樣的。

輕薄的Client跑不動前端 LLM，真正的第一道關卡往往是瀏覽器的 Storage Allocator，而非 GPU 本身，那我的 MBA 到底可以跑什麼模型？

1. TinyLlama-1.1B

改用 @xenova/transformers (v2.17.2) 執行 TinyLlama-1.1B-Chat 時，雖然可成功下載權重，但推理的瞬間會拋出錯誤，
RangeError: offset is out of bounds at Uint8Array.set
，餵狗後發現這應該是舊版 ONNX Runtime Web 處理特定運算子時超越 WASM 記憶體上限的已知issue。

2. SmolLM2-360M

再測試了 SmolLM2-360M-Instruct (q4f16)：

速度：38.4 tok/s

聽說底層做了編譯優化，跑起來也是相當的穩定。但 360M 參數推理能力相當有限，回答問題的能力連ChatGPT剛出來時都不如啊... (雖然也知道參數大小差很多，但是已經被LLM寵壞了)

WebGPU vs WASM 效能對比

我內心還是覺得應該要公平比較 WebGPU vs WASM在效能上的差異，因此又找了一些模型在MAC Studio 上來比拼，先用 GPT-2（124M）跑了兩輪。

GPT-2（124M）是 2019 年的模型，答題水準大概長這樣...

Q: What is 2 + 2?
A: The answer is 2 + 2.  ← ...

Q: How many legs does a cat have?
A: The answer is no.  ← WTF

Q: Write a Python function to add two numbers:
A: def add_number(x, y): return x + y + 1 + 1 + 1 + 1...  ← 有 def，但多加了一堆 1

Q: What is the capital of France?
A: The capital of France is the capital of France.  ← 跳針

結果

後端	tok/s	準確率	總時間
WASM	23.2	30%	16.39s
WebGPU	20.4	30%	18.68s

在 124M 模型下，WASM 竟然反超 WebGPU 約 12%！

為什麼微型模型下 WASM 會贏？

資料傳送Overhead：Token 需要頻繁在 CPU 與 GPU 記憶體間複製，當計算量不夠大時，搬運時間直接侵蝕效能。
Kernel 啟動成本：每次啟動 GPU Kernel 都有固定開銷，無法被小規模平行運算攤平。
WASM 的進化：成熟的指令集與 JIT 優化，已足以讓 CPU 高效處理 124M 規模的矩陣運算。

3.8B 模型對比

上面 GPT-2 的結論是「124M 小模型 WASM 贏 12%」，好像就直接打臉我上一篇的農場標題ＸＤ TensorFlow.js 快看不到 LiteRT.js 的車尾燈了，
那如果換成更大的模型呢？我在 M2 Max上用同一個 Phi-3.5-mini-instruct-q4f16_1 模型分別跑了 WebGPU和 WASM，來看看結果如何。

後端	tok/s	準確率	總 tokens	總時間
WebGPU	59.7	70%（10 題對 7 題）	490	8.20s
WASM	0.5	60%（10 題對 6 題）	413	827s（13.8 分鐘）

結果看去裡，WASM 慢了 119 倍，總共 10 題要跑將近 14 分鐘，而且單題延遲 72-100 秒，WebGPU 只要 0.8 秒左右。

為什麼差這麼多？合理的推測是因為 WASM 是 CPU 跑，CPU 的記憶體頻寬和算力是固定的（還是MAC的CPU問題？），而模型從 124M 漲到 3.8B，每單位 token 的計算量跟著漲，但 CPU 的速度不會變。WebGPU 則是把運算丟給 GPU 的 parallel cores，理論上模型越大、GPU 的相對優勢越明顯。

反而像GPT-2 那種 124M 的規模，GPU 的 kernel 啟動和資料傳輸開銷反而吃掉平行化的好處，超過某個臨界點（大概 1B 左右）之後，WebGPU 的優勢就出現了。

又手癢補跑了一顆更大的模型 Qwen2.5-7B-Instruct（7B，q4f16）在 WebGPU 上：

指標	數值
tok/s	35.5
準確率	80%（10 題對 8 題）
總 tokens	643
總時間	18.13s

7B 的模型在瀏覽器裡能跑到 35.5 tok/s，還能答對 8 題，不過這顆模型的變異較大，跑起來很明顯的卡頓與瀏覽器快往生的感覺，又回頭處理scaling 的部分，Phi-3.5 Mini 在 WebGPU 上把 max_tokens 從 50 拉到 400，準確率從 70% 升到 100%，tok/s 穩定在 59.7-65.2 之間，給模型更多生成空間，答案品質會明顯變好，而且速度幾乎不受影響。

小結

小模型不用硬上 WebGPU：若任務僅需 <500M 的微型模型，直接採用 WASM 即可，不僅可以避開 WebGPU 在不同瀏覽器（如舊版 Safari）的相容性問題，也無需撰寫繁複的 Fallback 邏輯。
儲存空間是隱形殺手：部署 >1B 模型時，除了關心使用者的顯示卡，務必優先檢查 Storage Quota。使用者硬碟空間不足導致的快取失敗，往往才是用戶體驗崩潰的主因。

DEV Community: JH5

實測 NVIDIA Switchyard 疊加 PAIR：雙層混合推論架構

為什麼單一路由層無法滿足生產環境？

實測一：A100 14B 熱機純推論效能重測

實測數據對比（冷啟動 vs 熱機）：

實測二：雲端節點斷線之 Failover

實測日誌與故障排除軌跡：

容錯切換關鍵結論：

Switchyard + PAIR 實測

推論的三個 Must

延伸閱讀：NVIDIA 地雲混合推論實測三部曲

實測 NVIDIA Switchyard：RTX 3050 邊緣與雲端混合路由

釐清架構盲點：為什麼單輪任務與 Agent 升級不能混為一談？

格式避坑：Switchyard 雙路由 TOML

拆解任務前置分流：llm_classifier 在本地端到底靈不靈？

實測執行期動態升級： 捕捉 repeated_failure

實際運用的架構取捨

延伸閱讀：NVIDIA 地雲混合推論實測三部曲

實測 NVIDIA PAIR：RTX 3050 串接 Colab A100 混合叢集

釐清本質：NVIDIA PAIR 到底能做什麼、不能做什麼？

架構搭橋：透過 Colab CLI 與 SSH Tunnel 打通網路

基準實測

1. 單節點處理

2. PAIR 叢集負載平衡（RTX 3050 + Colab A100 對半平分）

階層式模型分流：大小模型各司其職的生產實踐

20 並行任務高壓考驗：叢集容錯與真實瓶頸

三步搭建自己的 PAIR 混合叢集

直上 Production 嗎？

延伸閱讀：NVIDIA 地雲混合推論實測三部曲

自訓練Unsloth決策模型讓 CVE 漏洞分流

設計決策目標

實測單卡訓練

推論測試

執行溫度校準：讓決策頭信心度貼近真實防禦門檻

盤點實作踩坑

評估架構選型：高併發 AIOps 該選生成還是決策？

來訓練自己的 Jev 模型吧：)

微軟 Microsoft-Decision-1 與 Jev 到底在做什麼

24GB VRAM 微調

對照推論速度

壓測多元任務並行

1. 多題擴展邊際成本：每題僅多 16 ms

2. 面對無關垃圾訊息與歧義的機率反應

驗證跨領域場景

情境一：高爭議客服工單路由

情境二：生物資訊管線次世代定序（NGS）品質異常警報

專模專用的 System 1 架構

vLLM Decision 3.0 地端實測

24GB VRAM 扛得住嗎？

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

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

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

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

免費的 Colab CLI A100/H100 真香 :)

拆解 CLI 雙胞胎

接軌官方工具：google-colab-cli 搞定 OAuth 與 A100 實例

實測 Gemma 4 推論：100% GPU 卸載飆出 179 tok/s

盤點即時監控維度：從點數流速到一鍵導出 ipynb

1. 算力與點數計費狀態（colab usage）

2. 實例運作狀態（colab status -s gemma-test）

3. 硬體級別監控（colab exec -s gemma-test "nvidia-smi"）

4. 服務層監控（colab exec -s gemma-test "ollama ps"）

5. 執行歷史與一鍵導出 Notebook（colab log）

解讀點數與定價機制：Pay As You Go 隨選加購怎麼算

結語與日常建議

做得好算 AI 的、做錯算你無腦貼？拆解 AI 功勞歸因偏誤與瑞士刀求生法

KubeSummit 2026 小記

用 Vercel AI SDK 玩轉 Chrome Built-in AI

官方範例

@browser-ai/core

next-hybrid

domainstack.io

實測小小筆記

如何用 WebMCP 讓你的網站對 Agent 開放？

WebMCP 是什麼?

宣告式 API：兩個屬性，表單直接變成工具

命令式 API

官方 demo 的旅程

WebMCP Sports

L'Atelier 飯店訂房

實測執行期動態升級：捕捉 repeated_failure

1. 算力與點數計費狀態（`colab usage`）

2. 實例運作狀態（`colab status -s gemma-test`）

3. 硬體級別監控（`colab exec -s gemma-test "nvidia-smi"`）

4. 服務層監控（`colab exec -s gemma-test "ollama ps"`）

5. 執行歷史與一鍵導出 Notebook（`colab log`）