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

釐清本質:NVIDIA PAIR 到底能做什麼、不能做什麼?

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

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)。

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

  1. 地端 RTX 3050 專責「日常例行雜工」:掛載 llama3.1:8b,專門處理 Bash 語法檢查、Regex 提取、FastQC 數值解讀。單題耗時落在 0.7s ~ 4.2s,地端零傳輸成本、零額外網路暴露。
  2. 雲端 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 的高檔水位。

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

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

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

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

  1. 取得 NVIDIA PAIR 核心二進位檔: 從官方倉庫 NVIDIA/Personal-AI-Router 的 Releases 下載 Linux 版二進位包(內含 nvpair-proxy、inference-dispatcher 與 nvpair-cluster-manager)。
  2. 建立背景連線隧道: 使用你慣用的 SSH 工具(或 Colab CLI)將遠端 GPU 伺服器的 11434 連接埠映射至本機的閒置連接埠(如 11435),或是如果你的Local就有兩個 Node,網路也是通的就可以略過這個步驟。
  3. 設定統一路由轉發: 設定 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 建議還是先不要XD 有太多架構上 HAProxy 或是 Failover 這篇都省略了 XD

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