Perplexity 把整套 Agent 搬上 DGX Spark：地端元年的官方背書

一則讓本系列文章瞬間很有感的新聞

寫到第十三天，發生了一件讓我對著螢幕關注的事。Perplexity 推出了 Portable Computer，一套完整的本地優先 AI agent 堆疊，而它首發先指定的硬體，就是本系列的主角 NVIDIA DGX Spark。

攤開它的架構，官方講得比我預期的更細，包括 orchestrator、planner、tool router、scheduler、durable task queue 與本地搜尋索引全部跑在機器上。本地模型有兩個可選，選單上寫著 Qwen 3.8 27B 與 PPLX 27B（模型管理介面官方標示「推薦」），NVIDIA 的 Nemotron 3.5 Lightning 30B 則顯示即將推出。

任務過程中若某一步需要網頁搜尋或雲端等級的推理，orchestrator 會先跳出來徵求用戶同意，才把那一步送去雲端（該公司提供 15 個以上的尖端模型可選），結果再帶回本地的執行流程裡。硬體需求寫明 GB10、128 GB 統一記憶體、至少 1 TB 儲存，Pro 與 Max 訂閱者今天就能下載使用，Linux 版本先上，Windows 要等九月才會釋出。

把這個架構跟本系列前十二天的內容並排看，地端 AI 硬體選 Spark（Day 1 到 4）、模型選 27B 級（Day 2 的記憶體帳）、量化壓尺寸（Day 12）、敏感工作留本地而雲端當外援（Day 1 的資料主權論）。一家一線 AI 公司用產品做出了類似的選擇。我自己認為的 2026 年是地端 AI 元年這個開篇論點，今天也多了一家 AI 新創大廠的官方背書。

這個產品有幾個設計是很有意思的，值得觀察看看，而讀者常問的如本機 SSD 放不下太多模型，模型檔案可以放 NAS 嗎? 等等問題，正好可以用我在這兩週的實測資料回答。

Perplexity 推的 Portable Computer，採用的是 vLLM 當底層，正是我 Day11 文章｜地端 AI 三大推論引擎綜合評測，同場加映神秘嘉賓中提到的， AI 代理人比較適合使用 vLLM，然後它是正是用 Docker 來跑 vLLM。

官方自己的數字，講了一件跟直覺相反的事

先看一組我覺得比產品發表更值得談的資料。Perplexity 同步發了一篇技術文章，裡面有張圖是在 DGX Spark 上跑 53 題、每題三次的內部基準：

看下面三列：同一個 Qwen 3.8 27B，只是換一套 harness，分數差 8.6 分。 再看上面兩列：同一套 harness，換成他們自己後訓練的模型，只多 2.8 分。

也就是說，用官方自己的資料，harness 對成敗的影響大約是模型後訓練的三倍。這跟大多數人的直覺相反，大家習慣把注意力放在換哪個模型、開幾位元量化，但真正在決定「這個 agent 能不能把事情做完」的，是外面那層負責控制迴圈、決定何時停手、何時要求驗證的程式碼。

這一點我自己做幾個開源 harness 的對照測試時也碰過類似的事情，光看成績分不出高下，差異反而會在於知道何時停手。今天官方用 53 題把它量成了數字。

三個值得玩味的設計決定

第一，它選了 27B 加混合精度，而且媒體普遍講錯了位元數。 我把兩個模型都下載了並檢視其檔案結構。

某些媒體的報導寫「3-bit 量化，下載 17.4 GB」。實際下載的東西不是這樣。hf_quant_config.json 逐張量列出設定，寫的是 MIXED_PRECISION：

直接讀 safetensors 檔頭更清楚：F8_E4M3 390 個張量、U8（NVFP4 打包成位元組）186 個、BF16 776 個未量化。磁碟上兩個各 26 GB，app 介面自己標的是 38.6 GB 與 27.6 GB。沒有一個數字接近 17.4 GB，也沒有一個部位是 3 位元。 27B 真壓到 3 位元只會是 10 GB 上下。

還有一件事：選單上那個「Qwen 3.8 27B」也不是 Hugging Face 上的原版。它拉的是 perplexity-ai/pplx-computer-qwen-3-8-27b-dflash2-20260819，跟 PPLX 那個（-20260824）是同一個倉庫家族。兩個的 config.json 逐欄位比對，680 個欄位只有 2 個不同，量化設定檔的 md5 甚至完全相同。兩個選項是同一套配方的不同權重，不是「原版 vs 後訓練版」。

架構本身也值得一提，64 層裡有 48 層走線性注意力、16 層完整注意力，每 4 層一次，上下文開到 256K。四分之三的層是線性注意力，這才是 27B 級模型敢開這麼長窗的原因。

回到產品思維那一點，結論不變只是數字要換：一個約 26 GB 的模型配 128 GB 的機器，剩下的空間留給沙箱、多工與第二個模型。

第二，審查式雲端升級的設計，比我原本以為的更嚴謹。 官方那張流程圖畫得很清楚，簡單說明一下：

• 任何要離開這台機器的內容，都要過一道 Egress Gate，而閘門上標的兩件事是「approval」與 「PII flagging」。不只是問你要不要送，還會先掃一遍要送出去的東西裡有沒有個人識別資訊。
• 雲端那個模型在圖上的身分是 Remote Advisor，方框裡直接寫著 no direct tools or files, guidance text only。它拿不到你的檔案，也碰不到你的工具，只能回文字建議，動手的永遠是本地那一套。
• 另一張架構圖的副標更關鍵：「Harness code controls the loop; the local LLM proposes each step」。控制流由確定性的程式碼掌握，模型只負責提議下一步。

裝完之後我把這三點逐一做測試檢驗，確實都成立：

PII 篩檢是一個獨立的本地模型，不是關鍵字比對。 它跟主模型一起下載，是 28 層的 Qwen3 token classification 模型，跑在同一個容器的第二個 vLLM server 上，只分到 5% 的 GPU 記憶體。我丟三段文字測它（個資全是非真實的個資）：純技術句只有 9% 的 token 被標記，塞滿假 email、假電話、假卡號的那段被標了 91%，含假地址的那段 80%。而且它每個 token 輸出 38 個類別的分數，能夠區分出是「哪一種個資」，不只是標示有沒有。

預設值是 fail-closed。 安裝完的設定檔裡，local_mode_adviser_enabled（雲端顧問）、local_mode_external_calls_enabled（外部呼叫）、local_mode_connectors_enabled（連接器）三個往外的開關預設全部是 false，唯一預設 true 的是 local_mode_pii_mask_enabled。這比多數產品的預設值保守得多。

以資安日常和資安稽核的角度看，第三點的價值最高。多數 agent 產品的控制迴圈本身就是模型在跑，你很難回答「為什麼它會決定去做那件事」，有時候也會不清楚究竟是怎麼回是。但是把迴圈交還給程式碼，等於把「可稽核」這件事寫進了架構，而不是靠事後的日誌拼湊。加上每一次外送都留下明確授權紀錄與個人資料 PII 掃描，這正是企業合規最想要的狀態，比那些廠商宣稱「相信我們不會亂送機敏資料」的黑箱作業誠實得多。

第三，本地執行 AI 模型不需要另外計費。 官方用的單位是 credit 不是 token，重點一樣，自有硬體上跑的那些步驟不按量計費。他們特別強調 repo 等級的遷移、批次摘要這類高量工作適合放本地。

這正是本系列文章中關於成本的內容會計算的，而官方這次順手把座標給了。同一篇技術文章的 Terminal Bench 2.1（89 題，全部用同一套 harness）顯示：

如果採用混合模式花 63% 的成本，就能拿到約八成九的分數，這樣一來，可以思考的是，地端 AI 的損益兩平點，取決於你有多少「量大但不需要尖端推理」的工作，這張表就是很好的呈現。

那本地這一端跑多快？我在自己的 Spark 上量了一輪（桌面閒置、分母用伺服器自己回報的 token 數、每輪換提示詞避開 prefix cache），貪婪解碼 24.98 tok/s，用模型預設的取樣設定 25.39 tok/s。長提示的首字延遲，1K token 是 0.86 秒、12K token 是 9.31 秒。

它本身預設就開著投機解碼（DFlash2，一次猜 7 個 token），實測草稿接受率貪婪 64.9%、取樣 59.7%。很妙的是，這個實作在取樣下吞吐留存 101.6%，實質沒有損失。

讀者提問模型檔案可以放 NAS 嗎

買了 Spark 裝了 Portable Computer 的人，看到官方要求 1 TB 本機儲存，多半會冒出這個念頭，我家有 NAS，模型放那邊行不行？我這兩週把三條儲存路徑實測了一輪，直接給結論。

先看三種路徑的原始實力（循序讀取實測，cat 到 /dev/null，每趟前清 page cache）：

這三格的 readahead 設定並不相同。Linux 預設是 128 KB，本機 NVMe 要調到 1 MB、NAS 走 10GbE 要調到 15 MB，才拿得到上面的數字，而入門 NAS 那台調不調都在 540 到 556 MB/s 之間，所以瓶頸不在 readahead。

看起來 NAS 慢很多，但真正的判斷不是比吞吐，是回答兩個問題。

問題一，模型放得進記憶體嗎？

26 GB 對 128 GB 來說綽綽有餘，放得進。放得進的話，NAS 的代價只有「冷啟動多等二十幾秒」這一次性成本，之後權重常駐記憶體，儲存在本機或 NAS 都沒關係。

我實測過反例，當模型大小逼近可用記憶體餘裕時，走 NFS 的總載入時間就會變慢，因為記憶體同時裝不下模型跟載入過程產生的中間副本。但這次的模型只有 26GB 的話，確實就不用擔心變慢這件事情，會很順利地從 NFS 透過網路載入。

問題二，loader 吃不吃儲存速度？

這是最反直覺的地方。之前這幾天，有實測過兩種極端。同一個碟、同一個 readahead 設定（1 MB，當時碟能給 5,389 MB/s）當分母，vLLM 載入時只跑到 161 MB/s，用掉磁碟能力的 3%，瓶頸在它自己的反序列化，而 GGUF 系的 mmap 載入跑到 4,351 MB/s，吃掉 81%，很明顯有差異。

原本不知道 Portable Computer 屬於哪一種。現在可以直接回答，我把它裝起來、讓它把模型載入一次，然後去看容器日誌：

INFO [default_loader.py:430] Loading weights took 143.76 seconds

主模型三個分片在磁碟上是 22.90 GB。換算：

22.90 GB ÷ 143.76 s = 159 MB/s
159 ÷ 5,389 = 2.95%

159 MB/s。我獨立測試到的 vLLM 是 161 MB/s，差 1.1%。佔碟能力 2.95%，就是那個 3%。

它底層確實是 vLLM（版本 0.27.2rc1.dev193，跑在 Docker 容器裡），而且引擎設定寫的是 load_format=auto，用的就是我量過的那條預設載入路徑。所以結論是 把這個模型放本機 NVMe 還是放 NAS，對它的載入時間幾乎沒有差別，因為它根本沒有吃滿硬碟的能力。 冷啟動那二十幾秒的差距在總載入時間裡是影響很小。

但我的建議還是：照官方要求，模型放本機。 理由已經完全不是效能了，而是它用一個 GUI app 自己管理模型路徑（實際落在 ~/.local/share/perplexity-rpc-server/local-models/，走的是 Hugging Face 的快取結構），也不需要用符號連結把它改到 NFS 上去挑戰沒人測過的路徑。NAS 在這個場景的正確角色是 Day 5 講的集中模型庫與備份，服務自己部署的那些引擎，而不是接管套裝軟體預設好的執行路徑。

順手送一個所有 Spark 玩家都該做的免費加速，而且這次我把自己先前的建議一起再最佳化。

Linux 預設的 readahead 是 128 KB，對大模型檔太小。我這次每格重複三次重測了一輪（29 GB 的 safetensors，每趟前清 page cache）：

轉折點在 8 MB，比 1 MB 還快 26%，而 15 MB 只再多 0.6%。

echo 8192 | sudo tee /sys/block/nvme0n1/queue/read_ahead_kb

但這一行最佳化的指令重開機就沒了。 要固定下來得寫成 udev rule：

# /etc/udev/rules.d/60-nvme-readahead.rules
ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/read_ahead_kb}="8192"

注意是 queue/read_ahead_kb，不要用 bdi/read_ahead_kb，後者是指到 /sys/class/bdi/ 的符號連結，udev 走符號連結不可靠。

readahead 拉大對隨機讀取是白做工，也會多佔 page cache。如果這台機器只拿來載入與服務大模型，8 MB 值得；如果它同時是你的開發機、跑著資料庫或大量小檔存取，1 MB 是比較保守的折衷。

裝起來才看得到的三件事

官方說「one-click setup via the Perplexity app」，媒體寫「apt 裝一個套件」，兩句話合起來才是完整的。我實際裝了一遍，就發現有以下三件事只有裝了才會知道。

第一，apt 那一步裝的不是 agent，是一個 Electron 殼。

套件 perplexity 版本 26.8.4，下載 161 MB、裝完 577 MB。從相依清單（libgtk-3-0、libnss3、libnotify4、bubblewrap）就看得出來。Portable Computer 本體是你把 app 開起來、登入訂閱帳號、在模型選單裡選一個之後才下載的。實際落地約 32 GB，模型 26 GB、vLLM 的 Docker 映像 4.3 GB（以 tar 離線匯入，解出來是 20.7 GB）、PII 模型 1.2 GB、語音模型 0.13 GB。

這對兩種讀者有不同意義。如果你的 Spark 接著螢幕當工作站用，完全沒問題。但如果你像我一樣把它當成機房裡一台純 SSH 的推論伺服器，那就得先有圖形桌面才裝得起來。

第二，那個「OS 層強制沙箱」指的是 bubblewrap，不是 AppArmor。

套件附了一份 AppArmor profile，內容只有這麼多：

profile "perplexity" "/opt/Perplexity/perplexity" flags=(unconfined) {
  userns,
}

flags=(unconfined) 的意思是這份 profile 不拿 AppArmor 去關住這支程式，那行 userns 才是重點：它是在 Ubuntu 24.04 上放行 unprivileged user namespace，好讓 bubblewrap 建得起沙箱。所以做隔離的是 bwrap，AppArmor 在這裡只是開門的，這個區別在稽核文件上會差很多。

第三，PII 篩檢跟同意是兩個分開的模組。 同一份字串表裡有 pii_screening.rs 與 pii_consent.rs，還有 permissions.rs、authorizations/user/store.rs 與 authorizations/enterprise/store.rs。偵測與授權分開實作，對上了官方那張 Egress Gate 的圖。順帶一提，官方公告只說 Pro 與 Max 訂閱者可用，但 enterprise 的授權儲存已經在程式碼裡了。

另外一個實裝細節也想和大家分享，該公司官方寫安之裝「至少 1 TB 儲存」，而 1 TB 的 NVMe 格式化後實際是 931.5 GB。我這台 GB10 就是這樣，名目達標、數字沒達標，這款軟體不含下載模型權重的使用空間，實際要用的空間大約 20 GB，所以真正的問題只是那個 precheck 會不會不讓玩家安裝而已，答案是不會。

自建地端 AI 與套裝開箱即用

最後把 Portable Computer 放進本系列的座標系。它跟我們這二十九天在做的事是同一件事的兩種解法：

這張表沒有好壞之分，主要探討的是定位。而且兩者不互斥，一台 128 GB 的 Spark 裝了 Portable Computer 之後還有不少記憶體的可用空間，跑自己的 vLLM 服務綽綽有餘。真正的重點是方向，當套裝產品開始把地端 agent 做成 apt 加一次登入就能用的東西，預期地端 AI 在大中小規模的企業都有機會陸續提高部署率。

工程做得比行銷好，這在 AI 產品裡很少見

這次實測的感想，它在資料保護方面，把三個往外的開關預設全關、只有 PII 遮罩預設開，願意這樣設代表不是喊口號。個資 PII 篩檢是一款 28 層、38 個類別的專用模型，不是關鍵字表，而且跟主模型擠在同一張 GPU 上分 5% 的運算。該公司架構圖那句「Harness code controls the loop; the local LLM proposes each step」也不是文案，容器裡就看得到確定性的控制流。

flock 看門狗是我最欣賞的細節，通常在以往做類似專案，GPU 容器變孤兒是個沒人願意處理的髒問題，他們用一個唯讀掛載的鎖檔解掉，實測 5 秒回收乾淨。埠只綁 loopback、模型掛載唯讀、映像用 tar 離線匯入不依賴 Docker Hub，這些都是比較少會注意到，但錯了會出事的地方。

他們也有碰到 lmheadfix，而且是從模型端（exclude_modules 排除 lm_head 與 MTP）跟引擎端（自己 patch vLLM）同時解，是真的有解決問題，不是把現成元件黏一黏，這個效益是好的。

最後，他們自己還公布了一個對自己不利的數字。同一款 Qwen 3.8 模型換 harness 差 8.6 分、換成他們自家後訓練版只多 2.8 分。這等於說「我們的模型沒那麼特別，是外面那層有價值」。願意把這個放進發表文，我認為是加分的。

模型的部分，選單上寫「Qwen 3.8 27B」，實際給的是 pplx-computer-qwen-3-8-27b-dflash2-20260819，跟「PPLX 27B」那個量化設定檔 md5 完全相同、config 680 個欄位只差 2 個。使用者選 Qwen 是以為自己在選開放權重原版，實際上兩個選項的差別比介面暗示的小得多。

"asr": {"kind": "soniox"}。 公告說 dictation「runs locally」，本地 sherpa-onnx 模型確實下載了，但預設值是雲端服務。

需要圖形桌面這件事，我覺得是產品定位的問題，DGX Spark 很多人是當機房裡的推論節點在用。三支執行檔我全試過，Electron 殼沒有 DISPLAY 直接 segfault、rpc-server 獨立跑會 panic、pplx-search 要 app 在跑才能用，沒有 headless 路徑。該公司選了「桌面 app」當主軸，就會把不少 Spark 使用者排除在外。

Perplexity Portable Computer 定位

至於它的定位，實測成績是 25 tok/s、256K 上下文、48 GB KV cache，這個速度做 AI 代理人工作是堪用，但沒有到很快。而他們自己的 Terminal Bench 說純本地 59.6% 的成績，改連 Opus 5 分數到 73.0%。這兩個數字放在一起，就是吃了誠實豆沙包，這是一台大部分事情自己做完、難的那幾步還是要出去問的產品，不是取代尖端模型的東西，他們也是這樣講的，沒有吹過頭。

對他們的框架我自己的想法覺得，儘管本地 AI 執行沒有 credit 費或 token 費用是真的，但真正的成本不是 credit，是我們先花了幾千美金買機器後。當碰到它說純本地只有 59.6% 的成績，這對很多實際工作是不夠的，一旦不夠你還是在付那 $0.415 美元的費用去呼叫雲端。真正的省錢場景是「量大、單題簡單、資料敏感」這個交集，比行銷暗示的要再窄一點囉，所以屆時他們更新的模型能力，後續才是競爭的關鍵。

明天預告

巧的是，Portable Computer 內建其中一款模型正是 Qwen 3.8 27B，而今天測試本篇之後，之後的內容自然更清楚了。它用的是注意力 FP8 加 MLP NVFP4 的混合精度，正好落在我已經量過的兩種精度之間。剛好明天 Day 14 是探討 Qwen 模型，我會有完整版 BF16 全精度、FP8、多檔量化的部署實測與繁中品質評估，並且把 Perplexity 這個混合配方接進 Day 12 那條量化階梯，用同一份語料、同一個尺規比一次。

順帶回答今天多出來的一個問題，一個為了跑 agent 而後訓練過的 27B，跟原版比起來到底換到了什麼。

我們 Day 14 見囉。

（本篇產品資訊來源：Perplexity 官方產品頁 perplexity.ai/hub/products/portable-computer，2026 年 8 月，以及與研究文 A Local-First Agent for Private and Cost-Effective Knowledge Work。量化配方、模型大小、推論引擎、載入吞吐與 PII 模型行為等項目官方均未載明，本文的依據是在自己的 DGX Spark 上安裝 perplexity 26.8.4 之後，檢視下載的模型檔、容器啟動參數與執行日誌。所有測試用的個資皆為非真實個資。）

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 模型