為什麼要多寫一天

Day 27 把雙機的兩種用法量完了，合體買一個 2.44 倍的主力，分家買三款模型同時活著，切換 40 分鐘。IFA 那週 NVIDIA 新發表的 PAIR（Personal AI Router）看起來像第三種，不合體、不分家，把網路上所有閒著的 GPU 自動發現、自動配對、按誰有空就把請求丟給誰。 NVIDIA 官方的說法很吸引人，超過一半的美國家庭有兩台以上的電腦，大部分時間閒著。閃光和我用的書房裡有兩台 DGX Spark、一台 RTX 5060 Ti 桌機、一台 RTX 3060 桌機，正好是它想像中的客群。

但先把它的邊界講清楚，免得期待放錯地方。官方 FAQ 明說它不把多台機器合併成一款虛擬 GPU，它路由的是彼此獨立的請求，一個請求從頭到尾在一台機器上跑。所以它解的是 Day 21 那種「subagent 開分身、幾個請求撞在同一秒」的排隊問題，不是 Day 27「單機裝不下 FP8 權重」的容量問題。這兩件事在本系列都量過，今天正好有對照組。

第二個邊界更關鍵：它目前只支援 Ollama 與 LM Studio 當後端。本系列從 Day 8 起的主力引擎是 llama.cpp、vLLM 與 ds4，一個都不在名單上。要用 PAIR，每個節點都得裝 Ollama，而 Day 11 量過 Ollama 在同一款模型上比調校過的 llama.cpp 讓掉 29%。所以今天的核心問題不是「PAIR 能不能跑」，是**「用 Ollama 稅換來的跨機路由，划不划算」**。

先說結論，因為效率比較慢，要支付的 Ollama 稅今天已經不是 29%，而真正要付的代價在別的地方。

如果你的機器本來就只跑 Ollama，PAIR 幾乎是免費的橫向擴展，裝上去、配對、什麼都不用改，四台就是 2.59 倍。如果你已經在用 vLLM，先看第三關那張表，你的一台打得過它的四台，先把第二台也換成 vLLM 會更划算。

NVIDIA PAIR（Personal AI Router）是什麼呢?

這是 NVIDA 推出的免費開源 AI 推論路由軟體（Apache 2.0，本文測的是 2026-08-28 發布的 v0.1.1），Windows、macOS、Linux 都有，x64 與 arm64 都有，圖形與終端機介面各一。運作分三段，mDNS 在區網發現相容節點（RTX 20 系以上、RTX PRO、DGX Spark、Apple M4 以上），mTLS 配對建立加密通道，然後對上層應用露出單一本地端點，把每個請求排程到某一台機器。上層應用不用改，因為端點對外長得跟 Ollama 或 LM Studio 一樣。

排程規則很簡單，並決定了後面所有的數字。官方的架構文件寫得很清楚，分兩步：

1. 過濾：只留下「有公告這款模型」的節點。沒有任何節點有，就直接回 502，連引擎都不會被打擾。
2. 排序：用 待辦工作數 + GPU 壓力 排，壓力是把忙碌程度用 40%、70%、85% 三個門檻映射成 0 到 3 的粗略級距，每秒對帳一次。

官方的 known issues 自己補了一句更重要的訊息，這個排程不看 GPU 型號、不看可用記憶體、不看模型有沒有暖機、也不看這個請求看起來多貴，所以混合叢集可能路由得很沒效率。這句話等一下會變成本篇最有畫面的一張圖。

第一節：把四台機器配成一個叢集

節點清單與各自的角色：

第一個意外在安裝這一步。Linux 的 .deb 與 Windows 的 .exe 之外，官方還放了 service-binaries-<平台>.zip：十三支執行檔，解到家目錄就能跑，不需要 root、不需要管理員、不需要桌面環境。四台我都走這條路，兩台 Spark 的 aarch64 完全沒有問題，broker 加十一支 worker 全部正常起停。beta 版對 DGX OS 的支援這個風險，開箱就消掉了。

第二個意外是它對既有 Ollama 的態度並不一致。Spark 1 上早就有系統版的 ollama 0.32.15（Day 11 那次留下的），PAIR 看都不看，回報 installed: false，然後自己下載一份 0.34.0 裝進 ~/.config/Nvidia Corporation/Personal AI Router/engine-bin/ollama，2.1 GB。桌機 1 上的 Ollama 桌面版它倒是直接接管了，於是那台節點跑的是 0.33.3。同一個叢集裡引擎版本不一致，這件事沒有任何介面會提醒你，是我去比對才發現的。

模型鋪兩層。四台共用一款小模型，用來測四節點路由Day 14 的 Qwen3.8-27B q4_k_m 只放兩台 Spark，用來看 PAIR 會不會正確地只把它的請求送去有模型的節點。

共用的那款原本想用 Qwen3.8 家族的小尺寸，但 Ollama 官方庫的 qwen3.8 只有 27b，沒有小的，所以改用同代的 qwen3.5:9b-q4_K_M（9.7B、Q4_K_M、6.6 GB），3060 的 12 GB 放得下而且還有餘裕給 KV。

這裡有本篇第一個地雷：Ollama 的 OpenAI 相容端點沒辦法逐請求指定 num_ctx，而預設的視窗遠小於 Day 21 那種 7.8K token 的提示，不處理就會被靜默截斷，量到的是另一個工作負載。解法是用 Modelfile 固定下來，四台逐字相同：

FROM qwen3.5:9b-q4_K_M
PARAMETER num_ctx 16384
PARAMETER temperature 0

兩台 Spark 之間的 23 GB 權重走 CX7 直連 rsync，51 秒（457 MB/s），兩台的 blob 逐位元組相同兩台桌機各自從官方庫拉，6.6 GB 各約 112 秒。四台 ollama list 出來的 ID 是同一個，這一點必須確認，否則四台跑的其實是不同的模型，整篇數字作廢。

配對本身很簡單。在 Spark 1 上對每一台送出邀請，對方會收到一組六位數 PIN，輸入就完成。mDNS 每 5 秒掃一輪，四台在同一個 /24 裡互相看得到彼此，同時公告 LAN 位址與 CX7 位址。從邀請到成為 member，機器這一側是秒級的，我這邊的耗時全花在把 PIN 從一台搬到另一台。

配對之後還有一個行為值得記：模型清單只在配對後才互通。未配對時對端的 models 是 None，配對完成的那一刻，四台才開始看得見彼此有哪些 tag。這也表示「有沒有這款模型」這個過濾條件，只在信任邊界之內成立。

安全面先記一筆給 Day 29 的治理清單用。三個問題我都實測過：

• 憑證存哪：~/.config/Nvidia Corporation/Personal AI Router/cluster/，裡面是 node.crt、node.key（0600）、identity.json，以及 trusted/<對方 UUID>.json（0600）。節點身分是開機時自產的 UUID，我把整個 engine-bin 從一台複製到另一台時，身分並沒有跟著被複製，這一點做得對。
• 能不能撤銷：可以，nodes:remove 把對方從信任清單移掉。PIN 官方自己說是「臨時 bootstrap code，不是高熵憑證」，所以配對要在你信任的網路裡做。
• 端點有沒有認證：沒有。本機 curl http://127.0.0.1:11434/api/tags 不帶任何憑證直接 200。但它同時是 loopback-only 的，從另一台機器打會拿到 403：

{"code":"loopback-only","error":"plaintext requests are accepted only from loopback; cluster peers must use the mTLS ingress"}

換句話說，信任邊界是「這台機器上的任何行程」。節點之間走 mTLS，對外沒有開明文的洞，但同一台機器上的任何程式都能無條件用掉整個叢集的算力。要進辦公室網段的話，這一條就是 IT 維運的重點了。

第二節：路由行為，它真的會把請求送去有空的機器嗎

先講怎麼看。PAIR 的 broker 有一個 JSON-RPC 介面，proxy:proxy/request 事件每筆帶 target、ttfb_ms、duration_ms，workloads:upsert 還帶 scheduledOn。所以落點不必靠各節點的 Ollama 日誌對時間，路由器自己就有帳可查。下面每一個落點都出自這份紀錄。

用 Day 21 那個 subagent 任務的形狀（母 agent 加三個分身，四個請求撞同一秒，每個提示 7.3K 到 8.2K token，輸出上限 200 token）打 PAIR 的端點，三趟的結果一模一樣：

（三趟的整趟時間是 8.60、8.77、8.52 秒，落點都是一台一個，只有哪個請求去哪台會換。）

三件事可以判讀。

一是它真的分散，而且分得很平。 四個請求四台機器，三趟都是。這不是運氣，是排程的設計：每個 proxy 在轉發之前會先替自己預約一個名額，所以同一瞬間進來的一批請求不會全部撲到同一台。

二是最慢的那條就是 3060。 同樣的 8K prefill，兩台 Spark 與 5060 Ti 都在 3.0 秒上下，3060 要 5.3 秒，差 1.7 倍。排程不看 GPU 型號，所以它照樣分到一份工作，而整趟的完成時間就被它決定。這正是官方 known issues 那句話的實物。

三是 27B 那款的請求有正確避開兩台桌機。 打 day31-27b:q4km（只鋪在兩台 Spark）四個請求，4/4 落在 Spark，桌機零次。再打一個四台都沒有的 tag，拿到的是：

HTTP/1.1 502 Bad Gateway
{"error":"no available node advertises the requested model"}

引擎完全沒被打擾。模型過濾這一條是紮實的。

順帶一提，這個「分得很平」只在請求真的撞在一起時成立。我用連續（非並發）的請求暖機時，八個請求全部落在同一台，而且不是本機，是節點 UUID 排序的第一台。待辦數都是零的時候，排序的尾數就是節點 ID。單請求的負載用 PAIR，收益是零。

把負載加到官方示範的規模，五個 subagent，三種配置對打（每種三趟取中位數）：

四台對單台是 2.59 倍，兩台對單台是 1.72 倍。加上兩台桌機是幫忙，不是拖後腿，即使其中一台是 3060。

原因在 Ollama 這一側：每個節點一次只跑一個請求。PAIR 兩台的那一組看得最清楚，同一台 Spark 上的三個請求，完成時間是 8.3、16.5、24.8 秒，整整齊齊排隊。既然每台都是單工，加節點就等於減排隊深度，收益幾乎就是節點數，慢節點的代價只有它自己那一份工作變慢。

我原本預期異質叢集的尾端延遲會讓四台輸給兩台，結果沒有。要讓那個預期成真，得讓請求數少於節點數、或者讓節點快慢差到一個數量級。

第三節：Ollama 稅對上 vLLM，本篇的正題

這一節把 PAIR 放回本系列的座標系。先更正草稿裡一個自己的錯：Day 21 那組 5.71 / 8.27 / 10.85 秒的分身 TTFT，是雙機 vLLM TP=2 的 ds4-flash，不是單機。所以對照組做兩個，一個是控制變因的（同一款模型、單台機器、只換引擎），一個是沿用系列座標的（Day 21 的原始配置）。

同一個五 subagent 任務：

第三欄要小心讀。它跑的是 Day 21 的原始配置，也就是雙機 TP=2 的 DeepSeek-V4-Flash，
模型大了一個級距，五個請求合計 35K token 的 prefill 本身就要那麼久，而且它答得比較短
（輸出合計 262 token 對另外兩欄的 800）。這一欄回答的不是「路由對批次」，
是「系列的主力後端碰到同一個 subagent 瞬間會怎樣」：25.05 秒，最慢的首 token 23.17 秒。
另外它需要暖機，前兩趟是 43.08 與 32.36 秒，第三趟起才穩定在 25 秒上下，六趟裡我取後四趟的中位數。

判讀先講最乾淨的那一格：同一台機器、同一款模型，只把引擎從 Ollama 換成 vLLM，42.46 秒變成 22.57 秒，1.88 倍。 這就是 Ollama 稅在併發負載下的真實大小，跟 decode 快不快沒什麼關係，它輸在一次只服務一個請求。vLLM 把五個請求收進同一個批次，最慢的首 token 從 37.48 秒掉到 7.15 秒。

再看橫向：四台 Ollama 的 16.41 秒，確實贏過單台 vLLM 的 22.57 秒，1.38 倍。 所以那個「橫向擴展壓過縱向最佳化」的結局是成立的，但它成立的條件很窄：你要有四台機器，而且四台都只跑 Ollama。換個說法，PAIR 的四台只換到單台 vLLM 的 1.38 倍，如果那四台裡有任何一台本來就能跑 vLLM，先把那台的引擎換掉比把四台串起來划算得多。

功耗那一列是空的，理由要講清楚。Day 29 的兩款 Tapo 插座只夠量兩台 Spark，
而這一節的三個配置分別動用四台、一台、兩台機器，用兩款插座量出來的「合計」
只會涵蓋其中一部分，拼起來的數字比不量更容易誤導。所以這裡沿用 Day 29 對桌機的口徑：未量測。
可以先借 Day 29 的既有讀數當量級參考：單台 Spark 滿載牆插 140.2 W，TP=2 每台 164.8 W，
兩台桌機從來沒有量過。真要補，正確的作法是把插座移到桌機上重跑一次，並且說明那是兩趟相加。

順手更新 Day 11 那 29%

那個 29% 是 Day 11 用 gpt-oss-120b 量的，當時拆成「權重約一半、binary 約一半、旗標無辜」。今天用同一個 GGUF 檔餵兩個引擎，把權重那一半直接歸零（zhwriter-v1-q4_k_m.gguf，Qwen3.8-27B 微調，單請求 decode，256 token，三趟取中位數）：

29% 不見了。 同權重之下 Ollama 比自編的 llama.cpp 快 2.1%（對 -np 1）到 11.3%（對 -np 8 -cb），方向還反過來。原因不難猜：Ollama 0.34.0 綁的 llama.cpp 比我本機 8 月 27 日編的那版新。順帶修正 Day 11 的另一句，-np 8 -cb 在單請求下要付 8.2%，「旗標無辜」在這個配置不成立。

所以今天的 Ollama 稅不在 decode，在服務模型：一次一個請求。這也解釋了為什麼第三關那兩欄差那麼多。

附帶一個地雷：本機的 llama.cpp build 10669 載不進 Qwen3.5 的 GGUF，qwen35.rope.dimension_sections has wrong array length; expected 4, got 3。新模型先到 Ollama、再到自己編的 llama.cpp，這個時間差在系列裡第一次咬到我。

第四節：它跟 Day 18 的閘道是什麼關係

PAIR 對上層露出單一端點，LiteLLM 也是，兩個都叫路由，讀者一定會問是不是重複了。層次不同：LiteLLM 做的是用途別名對後端的路由（zh-writer 指誰、daily 指誰），PAIR 做的是同一個後端類型內的節點路由（這個 Ollama 請求去哪台）。理論上可以疊，LiteLLM 的某個別名指向 PAIR 的端點，PAIR 再往下分。

實測疊得起來，而且很安靜。gb10-proxy 是 host network，容器內的 127.0.0.1 就是主機的 loopback，PAIR 的 loopback-only 限制沒有擋到它。

• 通不通：通。pair-9b 這個別名走 :8100 一次就成功。
• 多一跳的延遲：直打 PAIR 中位數 52.5 ms，經 LiteLLM 56.9 ms，多 4.4 ms（各 20 次，max_tokens: 1）。
• Day 26 的護欄還在不在：在。別名設 max_output_tokens: 512，送 max_tokens: 4096 與 max_completion_tokens: 4096 都被壓到 512，finish_reason 是 length。兩個欄位都吃。
• 健康檢查怎麼看 PAIR 那一層：/health 把它當成一般 OpenAI 後端，看得到 PAIR 是 healthy。看不到的是「PAIR 底下有四台、其中一台不見了」，那一層的狀態只有 PAIR 自己知道。

順便記一個跟 Day 25 同款的地雷：Ollama 的 OpenAI 端點靜默忽略 think: false 與 chat_template_kwargs，只有 reasoning_effort: "none" 真的關得掉思考。Qwen3.5 預設會思考，不關的話 200 個輸出 token 有一大半花在 reasoning 欄位，而客戶端如果只看 content 會以為模型什麼都沒回。

第五節：合體、分家、路由，三種用法的定位

把三天的資料放在同一張表：

PAIR 不是合體與分家的替代品，是第三個象限，而它的入場條件（全節點 Ollama 或 LM Studio）決定了它在本系列這種已經深度調校的環境裡的定位。給讀者的判斷是這樣：如果你的機器本來就只跑 Ollama，PAIR 幾乎是免費的橫向擴展，裝上去、配對、什麼都不用改，四台就是 2.59 倍。如果你已經在用 vLLM，先看第三關那張表：你的一台打得過它的四台，先把第二台也換成 vLLM 比較划算。

路上踩到的四個地雷

這四個都不在官方文件裡，而且每一個都會讓你以為是別的東西壞了。

一、Windows 會自己建封鎖規則。 用免安裝的 zip 起 PAIR，Windows 防火牆會替 ollama-proxy.exe、nvpair-ui-broker.exe、lmstudio-proxy.exe 各建一條 Block 規則，而 Block 永遠贏過 Allow。症狀極具欺騙性：那台節點被發現、被配對、模型清單也正常，就是永遠分不到請求。我一開始以為是排程器不喜歡 3060，直到把那六條規則刪掉，它才開始接活。用官方安裝檔的人不會遇到，用 zip 的人一定會遇到。

二、手動釘選節點是壞的。 終端機介面的文件說 Proxies 分頁按 enter 可以把流量釘在某一台，按 a 回到自動。對應的 RPC 我打了，回傳值正確、查詢也顯示已選，流量照樣去別台。0.1.1 這個功能等於不存在，所以本文的三種配置是用「讓節點上下線」做出來的，不是釘選。

三、連續請求不分散，而且不優先本機。 前面提過，待辦數全是零的時候排序退化成節點 ID 順序。你在自己機器上打一個請求，它可能跑去房間另一頭那台。

四、think: false 沒有用。 見第四關。

番外的結論

PAIR 在這個環境跑起來的體感，比我預期好很多：aarch64 的 DGX OS 開箱可用、免 root、四台配對加鋪模型一個下午就完成，量測期間零失敗請求。它的工程品質不像 0.1.1。

Ollama 稅值不值得，要看你在哪一格。Day 11 那個 29% 今天已經不存在了，真正的稅是 Ollama 一次只服務一個請求，而這筆稅 PAIR 幫你用節點數補回來：四台 2.59 倍，剛好夠贏過單台 vLLM 1.38 倍。但如果你手上那台機器本來就跑得動 vLLM，這筆交易就不划算，因為同一台換引擎就有 1.88 倍，而且尖峰 TTFT 好上五倍。

對「家裡有幾台閒著的電腦」的一般讀者，PAIR 是這一整個系列裡最容易得到的那一次加速：不用改程式、不用懂張量平行、不用買第二張卡。對「已經有 Spark」的讀者，它是一個補洞的工具，補的是「桌機那張卡整天閒著」這個洞，不是「主力模型不夠快」那個洞。最後回到 Day 30 那個分流的框架：PAIR 是分流在地端內部的再一次分流，而且它分的是最不需要思考的那一種請求，多、小、彼此獨立。

系列到此真正結束。腳本與紀錄在 repo。

（本篇為番外，PAIR 為 beta 版 v0.1.1，行為與支援清單以發文當日官方文件為準。）

Day 1｜為什麼 2026 年是地端 AI 部署元年：系列規劃與硬體總覽
Day 2｜DGX Spark GB10 深度解析：128GB 統一記憶體到底解決了什麼問題
Day 3｜網路與儲存規劃：10GbE 骨幹、雙 Spark 直連與 NFS 集中模型庫
Day 4｜開箱之後：DGX OS 初始環境建置與 CUDA、Docker 生態確認
Day 5｜NFS 模型庫實戰：下載工具、權限設計與版本管理
Day 6｜llama.cpp、vLLM、TensorRT-LLM 、Ollama、DS4 與 Unsloth 的定位與取捨
Day 7｜第一個模型上線：gpt-oss-120b 從模型庫到 API 的完整流程
Day 8｜llama.cpp 實測：先定量尺與 SOP
Day 9｜vLLM 實測：官方容器、同時處理吞吐曲線，與剛出爐的新模型 Ornith 1.5
Day 10｜TensorRT-LLM 實測：我花了一個下午，跟它的預設值搏感情
Day 11｜地端 AI 三大推論引擎綜合評測，同場加映神秘嘉賓
Day 12｜量化格式解析：「4-bit」兩個字，古今多少事 ? 都付笑談中
Day 13｜Perplexity 把整套 Agent 搬上 DGX Spark：地端元年的官方背書
Day 14｜Qwen3.8-27B 與 Flash-Next 加碼實測：地端模型世代對決與落地評估
Day 15｜Ornith 1.5 實測：為 AI agent 而生的 35B-A3B
Day 16｜模型選型方法論：五個問題幫你跳脫排行榜迷失，找到適合自己任務用的 AI 模型
Day 17｜ds4 深度解析：Redis 之父只為一種模型造了一個引擎
Day 18｜OpenAI 相容 API 層：地端 AI 多模型常駐好助手
Day 19｜地端 agent 框架總覽：它們到底對你的端點做了什麼呢?
Day 20｜DeepSeek Harness 實戰：21 萬款星的外掛式 harness 接上地端
Day 21｜herdr 是地端 AI 同時跑多個 AI agent 的最佳解
Day 22｜語意錨點對上 prefix cache，FreeToken VS vLLM，以及三個關於統一記憶體的教訓
Day 23｜ComfyUI 部署與 NFS 模型庫整合：把集中管理的哲學帶進生圖世界
Day 24｜MiniMax-H3 地端影片生成：h3-ui 與四步蒸餾版的三段對決
Day 25｜Unsloth 微調實戰：教一款模型用繁體中文思考，並遵守台灣的編輯規範
Day 26｜微調的最後一哩路：合併、轉檔、量化、上線
Day 27｜雙 DGX Spark GB10 合體與分工合作的部署與實測
Day 28｜雙NVIDIA DGX Spark GB10 維運篇
Day 29｜成本與治理：地端 AI 到底值不值得，是否能進客戶環境?
Day 30｜三十天製作了一張可複製的地端 AI 藍圖
Day 31｜NVIDIA PAIR：合體與分工合作之外，第三種用法值不值得付 Ollama 稅