小朋友才做選擇，前面兩篇我們分別試過 《實測 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 地雲混合推論實測三部曲
- 第一篇（算力網格）：實測 NVIDIA PAIR：RTX 3050 串接 Colab A100 混合叢集
- 第二篇（語意大腦）：實測 NVIDIA Switchyard：RTX 3050 邊緣與雲端混合路由
- 第三篇（本篇）：實測 NVIDIA Switchyard 疊加 PAIR：雙層混合推論架構
