老闆和資安會問的兩張表

28 天的資料，最後要回答兩個問題。第一個是老闆會問的，花這些錢，換到什麼，比雲端划算嗎。第二個是資安或稽核會問的，這套東西放進企業環境，資料去了哪裡、誰能動什麼、出事有沒有紀錄? 因此今天給大家兩張表做參考囉。

先把前提講清楚，成本那半只算本系列實際跑過的配置與實際量到的數字，硬體價格以閃光當時的採購金額或當前公開牌價為準，電費用 Day 28 的 GPU 軌實測加上今天補測試的牆插實測，雲端用 2026 年 9 月的公開牌價。治理那半只寫本系列實際踩過或驗過的東西。

牆插電力實測的部分，是採用 Tapo 智慧插座的做法，它有 API 可以取得電源使用資料，真的是很方便。

二個買起來總共新台幣 748 元，剛好也是特價去買的。

成本表一：三張入場券

系列裡實際存在過三種地端配置，各自能跑什麼，Day 22 與 Day 27 已經測試過：

硬體那一列先講清楚怎麼算的。雙 Spark 是兩台 ASUS Ascent GX10 各 100,900 元，加上一條 100G QSFP28 DAC 直連線 545 元。這個價錢閃光買得很便宜，都在漲價前買的，同期 NVIDIA 官方 Founders Edition 在美國市場是 4,699 美元，而且那是 4TB 版本，我這兩台是 1TB 版本。1TB 機種的問題就是有時候可能空間不夠，Day 28 量到根目錄只剩 38.1 GB、今天剩 36 GB，就是 1TB 這張入場券的後續帳單，因此會需要搭配外接SSD 或 NAS 來放權重檔案。

桌機那一格只算增購：RTX 5060 Ti 16GB 15,090 元，加上四支 32GB DDR4 3200（兩組 64GB 套裝各 3,088 元）6,176 元。主機本體、CPU、主機板、電源都不計，因為那台本來就在那裡。所以桌機那格不是「兩萬一就能買到一台跑 AI 的機器」，它是「已經有一台桌機的人，多花兩萬一可以走到哪裡」。

然後要注意的是，這是閃光和我購買的金額和價格，都是在漲價前入手的，因此實務上，目前市場購買的價格遠高於此，計算的攤提成本就會很不同，但理論和方式是類似的，請當作參考。

換成每一份吞吐的成本：雙 Spark 每 t/s 花 2,136 元，桌機每 t/s 花 3,458 元，單 Spark 最貴，每 t/s 花 5,602 元。單機那格貴在它付了完整硬體的錢卻只拿到 2-bit 的並發表現，這正是 Day 27 那個「第二台買的是什麼」的另一種說法。

桌機的 128 GB 是實體記憶體，引擎實際只看得到 110 GiB。 .wslconfig 給 WSL 的上限是 112 GB，扣掉之後 vLLM 那一側看到的是 110 GiB。這不是雞蛋裡挑骨頭，那正是它只能跑剪枝版的原因，完整權重在桌機的 110 GiB 與 Spark 的 121 GiB 兩個場地都放不下，於是只剩剪枝變體這一條路，而剪枝變體在 agent 迴圈裡會語言漂移到 JSON 壞掉。入場券的價差買到的不只是速度，是「你有沒有選擇權」。

牆插功耗：Day 28 欠的那一格，以及它為什麼不是一個倍率

Day 28 說得很明白：「在 GB10 上，你唯一拿得到的功耗數字是 GPU 那一軌」，整機牆插功耗那一格給不出來，而那些數字「是下限，不是估計值」。今天採用了 Tapo P110M 上線測試，所以補上了這一格的測試資料。

先講一件我原本打算寫錯的事。我本來想給讀者一個倍率，讓大家拿 nvidia-smi 的讀數乘一下就估得出電費。測試之後發現那樣寫是錯的。

倍率從 7.34 到 2.98，差了 2.5 倍。 拿任何一個當常數去乘，都會在另一端錯得很難看。原因是整機功耗的結構不是乘法而是加法：非 GPU 的那一堆東西（Grace CPU 待命、128 GB LPDDR5x 記憶體自動更新資料用的電、四張網卡、NVMe、電源轉換損耗）畫的是一條幾乎不動的底線，GPU 只是疊在上面。

六個工作點做最小平方，這台機器的關係是：

整機牆插瓦數 ≈ 24.1 + 2.55 × nvidia-smi 的 power.draw
（R² = 0.9956，六個工作點的最大殘差 4.4 W）

這條公式有兩個讀法，兩個都重要。

第一，基座耗電量是 24.1 W。 這是一台什麼都沒做的 GB10，光是通電就要付的錢。

第二，那個係數是 2.55，不是 1。 GPU 軌每多一瓦，牆插要多付 2.55 瓦。也就是說 nvidia-smi 的讀數只涵蓋了增量功耗的三成九，剩下六成一散在記憶體、互連、供電效率與跟著一起忙起來的 CPU 上。這是統一記憶體架構的直接後果，這台機器的「GPU 在算」從來不是只有 GPU 在動。
然後 NVIDIA 的高速網路晶片那二個連接埠會非常熱，實務上，只要這二台機器都有使用到 100GbE、200GbE 網路，那個耗電量就會是高的，不會低。

這條公式的邊界，我特地測了一個反例

上面那六個點都是 GPU 主導的負載。為了知道這條線在哪裡失效，我多跑了一相：把二十顆核心全部灌滿，但 GPU 完全不給事做。

GPU 軌只動了 2.5 瓦，牆插多了 81 瓦，模型錯了 114%。 那八十瓦全是 Grace CPU 和主機板與網路卡晶片，而 nvidia-smi 對它一無所知。

同一件事在權重載入那一相也出現過，只是溫和得多，載入時 GPU 軌 12.97 W 跟閒置沒兩樣，牆插卻是 57.17 W，多出來的是 NFS 拉 155 GiB 檢查點的 CPU 與網路工作。

所以這條公式要附上使用說明：它描述的是 GPU 主導的推論負載。 拿它去估編譯、資料前處理、權重載入或任何 CPU 重的階段，會低估到離譜。統一記憶體把 CPU 與 GPU 綁在同一顆晶片上，但功耗遙測只從其中一邊拉了一條線出來。

兩台的合計。 這兩格繞了一圈才拿到。量測當下 Spark 2 那顆插座的本機認證是壞的：同一個 Tapo 帳號、同樣的參數，Spark 1 那顆通得過，Spark 2 那顆一律回 did not match our challenge。KLAP 與 AES、login version 1 與 2、五種帳號字串變體全試過，斷電重開也沒用，最後是在 App 裡原廠重設並重新加入才修好，韌體前後同版。

所以我先用 Spark 1 的擬合式套上 Spark 2 實測的軌功耗做了推估，等插座修好之後重跑同一組相位驗證。結果是推估站得住腳：

同一件事測了兩次的重現性也很好，Spark 1 的常駐閒置在兩輪分別是 54.97 與 54.98 W，滿載是 164.81 與 162.51 W。

順帶記一個量測上的教訓。Spark 2 修好之後我先在它開機一分鐘時取了一個閒置窗，當下 fwupd 還在跑、load average 0.60，那不是真的閒置。我補了第二個窗（開機十分鐘後）當基準，結果兩者只差 0.57 W。提出的疑慮量過之後不成立，這件事也該寫下來，否則下次還會再擔心一次。

那組資料還帶出一個比模型更準的觀察：Spark 1 裸機閒置的「牆插減軌」是 37.68 W，Spark 2 是 37.75 W，兩台的基座只差 0.07 W。但拿 Spark 1 的擬合線去預測 Spark 2 卻差了 7 W，因為那條線的斜率被滿載點主導，往低軌功耗外推會偏低。差值比模型準，這正是「加法不是乘法」的另一個證據。

成本表二：電費、攤提、與雲端的損益兩平

電費用 Day 28 的算法，台電夏月邊際級距，1 W 連續一個月是 0.73 度：

（雙機那兩列的牆插值，Spark 1 是實測、Spark 2 是用擬合式推估，理由見上一節。）

冷氣是電費表上沒有的那一列。 這套環境是我們家的書房，上面的電費沒有算空調，但 328 W 的牆插功耗最後全部變成熱，夏天這筆帳躲不掉。以家用分離式冷氣 COP 3.5 估算，兩台滿載時冷氣要多做約 94 W 的功，常駐閒置時約 31 W，換成夏月電費是常駐每月多約 23 度、滿載多約 69 度，等於上面那張表在夏天大約再乘 1.3。這是估算不是實測，COP 隨機型與室溫變動，而且冷氣本來就開著的話邊際成本更低。三種環境的差別值得寫明：辦公室有中央空調，這筆熱被整層樓的冷房量攤掉，通常看不出來。機房用 PUE 換算，1.3 到 1.6 之間，也就是電費再乘上那個係數。家用環境最尷尬，冷氣是為人開的不是為機器開的，而機器發的熱會直接反映在室溫上，Day 24 與 Day 28 那個「起跑時機殼多熱決定撐多久」的看門狗，環境溫度就是它的起始條件，夏天沒開冷氣的房間（我們家的書房）會讓那條 88 度的線更早到。

Day 28 那句「電費不是這套系統的成本瓶頸」今天驗證了，而且驗證的方式有點尷尬：那個下限低估了 4.6 倍。 常駐閒置從每月 17.6 度變成 79.0 度，滿載從 74.8 度變成 236.0 度。以金額看，常駐閒置一個月從 90 到 113 元變成 406 到 509 元。

但結論沒有翻。 就算把整月滿載的 1,520 元當成上限，那也還不到雙 Spark 每月攤提 5,621 元的三分之一，而且沒有人會整個月維持滿載。真正的持有成本是「常駐閒置 + 零星滿載」，落在每月五百元上下。電費仍然不是瓶頸，硬體攤提才是，只是這句話現在有數字撐著，不是靠一個低估四倍半的下限。

攤提以三年直線計算，殘值以零計。這個假設對地端有利，所以要講出來：三年後那兩台不是變成零，只是我不想在一篇講成本的文章裡替二手行情背書。雙 Spark 每月 5,621 元，單 Spark 每月 2,803 元。把電費加上去（常駐閒置的牆插實測，取兩個級距的中點），每月持有成本分別是 6,078 元與 3,027 元。這是「不管你用不用，它就是這個價」的固定成本。

產能用本系列真實負載換算，不用理論峰值，也不用單一任務。

這裡要挑對基準。Day 20 那個吃 473,207 輸入 token、27,691 輸出的任務，跑的是 dsh 加 Qwen3.8-27B-FP8，不是雙機 DS4-Flash，拿它當雙機的產能基準會張冠李戴（同一篇的 DS4-Flash 對照組是 335,018 輸入、9,473 輸出、12.9 分鐘）。真正接近日常形狀的是 Day 21 那個二十分鐘窗：三個 agent 同時打向同一顆雙機，窗內 113 次模型呼叫、累計輸入 3,273,059 token、prefix cache 命中 91.8%、產出 20 份文件 2,703 行。那是這套系統實際被用起來的樣子，所以產能用它外推。

那個窗的完整帳是：輸入 3,273,059 token、輸出 83,848 token、快取命中 91.8%。我用「一天十二個這種窗」外推，也就是一天四小時維持那個強度。這個假設是我自己訂的，不是量出來的，所以它會明白寫在圖上，你可以換成自己的數字重算。一個月就是 360 個窗、11.8 億輸入 token、3,019 萬輸出 token。

雲端對照用同一顆模型，不換能力等級。地端跑的是 DeepSeek-V4-Flash，雲端就用 DeepSeek 官方 API 的 V4-Flash，2026 年 9 月牌價每百萬 token 輸入 0.14 美元、輸出 0.28 美元。這樣沒有「你拿弱模型來比」的爭議。

但這裡有一個陷阱，不講清楚會把整篇數字的計算走向弄錯。

雲端也有 prefix cache 折扣。 V4-Flash 的快取命中價是每百萬 0.0028 美元，是未命中價的五十分之一。Day 21 實測的命中率是 91.8%，套上去之後的有效輸入單價是：

0.918 × 0.0028 + 0.082 × 0.14 = 0.0141 美元 / 百萬 token

只有牌價的十分之一。 如果照未命中價算雲端帳單，會把雲端算貴十倍，地端就會假贏一場。所以下面這張表把兩種算法並列：

這張表最重要的不是任何一個數字，是那兩欄的差距。 同一份工作負載、同一個牌價、同一天的匯率，只因為認不認雲端自己的快取折扣，雲端月費就從 5,454 元變成 786 元，差 6.9 倍。而地端的固定成本剛好落在這兩個數字中間，於是結論整個翻面：

用未命中價算，雲端月費 5,454 元對上地端固定成本，大約 1.1 倍就打平，地端看起來理直氣壯。
用實測命中率算，雲端月費 786 元，要跑到 7.7 倍的量地端才打平，也就是每天 92 個窗、超過 30 小時，比一天還長。以同樣三個 agent 的強度，24 小時不停也只到 6 倍，除非把並發推到 Day 27 量過的並發 8 甜蜜點，讓同一個小時吃進更多工作。

我自己的負載離 7.7 倍差得遠。所以誠實的答案是：以 token 計價，我這套地端回不了本。 那不是這套東西的失敗，是這個問題問錯了。撐住地端的從來不是省錢，是資料主權、離線可用、以及成本可預測（固定成本那條線是水平的，雲端那條線不是）。這也正是 Day 13 那個混合架構為什麼是多數企業的真實答案。

要注意雲端那兩個數字都是樂觀的它們假設你能一直維持 91.8% 的命中率，而 Day 20 那輪是 82.2%、Day 22 回放是 79.7% 與 55.9%。命中率掉到 55.9% 的話，雲端月費會往未命中價那條線靠過去。命中率是這整張表最敏感的參數，比硬體價格敏感得多。

換一個替代方案，答案就換一次

上面那個 7.7 倍是拿地端跟「雲端上的同一顆模型」比。但真實世界裡，沒有人的替代方案只有一個。同一份負載（每月 11.8 億輸入 token、3,020 萬輸出、命中率 91.8%），換成別家的牌價：

表格說明，DeepSeek 兩個型號有公告的快取命中明價，Claude、OpenAI、Gemini 三家都只說「最多省 90%」，所以我一律用牌價的 0.1 倍當快取命中價。這是估計不是牌價，會影響三家的數字但不影響排序。

這張表把問題整個換掉了。 原本的問法是「地端划不划算」，答案是「看你不買地端的話會用什麼？」：

• 替代方案是 DeepSeek 自家的便宜 API，地端永遠回不了本，差 7 倍
• 替代方案是 Gemini 3.8 Flash 或 Claude Haiku 4.5，大致打平，1.5 到 2 倍
• 替代方案是 Claude Sonnet 5 或 GPT-5.6 Terra，地端便宜 4 倍
• 替代方案是旗艦（Opus 5、GPT-5.6 Sol），地端便宜 10 倍

但這裡有一個不能跳過的但書：越往上比，比的東西越不對等。 地端那台跑的是 DeepSeek-V4-Flash，它做不到 Opus 5 或 GPT-5.6 Sol 能做的事。拿它的成本去對照旗艦的帳單，只有在「這份工作 V4-Flash 就夠用」的前提下才成立。如果那份工作真的需要旗艦，地端不是便宜十倍，是根本做不到。

所以誠實的結論不是「地端贏」也不是「雲端贏」，而是：這從來不是二選一的答案，是雲地 AI 分流。

分流才是真實答案

把上面兩件事疊起來看，地端的成本是固定的、與用量無關，雲端的成本是變動的、與能力等級高度相關。這兩條曲線的形狀不同，所以最佳解一定是雲地 AI 混合：

機敏資料、可預測的日常負載、V4-Flash 級能力就夠的工作 → 走地端。 這部分的邊際成本趨近於零，資料不出門，而且用得越多越划算。合規要求越高，這條線畫得越寬。

需要旗艦能力、資料不機敏、量不大的工作 → 走雲端。 這部分你買的是能力天花板，而且按次付費比養一台買不到那個能力的機器划算。

Day 13 拆 Portable Computer 看到的就是這個形狀：本地優先，需要升級時走審批式外送。那不是妥協，那是把兩條成本曲線各自放在它擅長的區間。而分流的那道閘門在哪裡、怎麼留紀錄，就是下半篇治理表的第 2 條。

三筆帳單上沒有的成本，寫給準備跟老闆提案的人：

時間。 這三十天的維運時間沒有進上面任何一格。TensorRT-LLM 一個下午重啟七次，雙機叢集每次重載 20 到 45 分鐘，三次合併嘗試，Unsloth 兩個坑，還有兩次半的停擺。就在寫這篇的今天，141 重開機之後 NFS 掛載在開機時序裡失敗，systemd 限速之後就不再重試，於是 worker 找不到權重、head 空轉重啟三次，:8008 整個不通。查出來只花十分鐘，但那十分鐘本來可以拿去做別的事。地端的真實成本裡有一大塊是人的時間，而這塊在雲端是零。

品質稅。 單 Spark 跑 2-bit 付的 PPL 代價、桌機跑剪枝變體的語言漂移，這些都是「便宜的那張入場券」看不見的價格，Day 27 用數字量過。順帶一提，Day 27 加測第三份語料之後結論還修正過一次：劣化跟語言沒關係，跟「模型對這段文字有多有把握」有關係，繁中那 13.6% 的訊噪比只有 3.0 個合併標準誤，是三份語料裡最軟的一個。

能力天花板。 地端最強的那顆模型跟雲端最強的那顆之間有差距，Day 13 Perplexity 的做法是本地優先加審批式外送，那個混合架構才是多數企業的真實答案，全地端是資料主權要求極高時的選項。

第二台 Spark 的錢買的是什麼

Day 27 留的問題，有答應說今天要計算出來。實務上，它買的不是兩倍算力。能源效率反而從 2.18 掉到 1.20 tok/s/W，這個數字要帶兩個但書：那兩列跑的不是同一顆模型（雙機那款檔案較大的模型，單機根本裝不下，這正是合體的理由），而且它算的是 GPU 軌不是牆插，所以它是「兩種可行組合的效率差」，不是同模型的對照。

它買的是二選一：一個 2.44 倍的主力（合體，FP8 品質、94.72 t/s 並發、兩百多萬 token 級的 KV 池），或者三顆模型同時活著（分家，主力降回 2-bit）。切換要 40 分鐘。

KV 池那個數字要小心引用。同一份權重、同一個設定，跨日量到七個值，從 2,468,694 到 2,702,825，最大最小差 9.5%。它不是模型的固有屬性，引用一定要標明是哪一輪。

用成本表二的數字換算，第二台加上那條線材的攤提是每月 2,818 元。把這筆錢丟到雲端會買到什麼？以 DeepSeek V4-Flash 的實測命中率計價，2,818 元一個月買得到 1,290 個 Day 21 等級的窗，也就是每天 43 個。而我假設的使用強度是每天 12 個。光是第二台的錢，在雲端就能買下我現有負載的 3.6 倍。

所以如果問題是「這樣划算嗎」，第二台的答案很明確：不划算。但這個問題本身是錯的，因為那 2,818 元買的東西雲端根本不賣：它買的是那顆模型在我家裡跑。 單機裝不下 FP8 的完整權重，要嘛降到 2-bit 付繁中 PPL 高 13.6% 的品質稅，要嘛把資料送出去。第二台買的是「不用二選一」。

我自己的答案是：如果你的理由是省錢，別買第二台。如果你的理由是那份資料不能離開這個房間，那第二台不是加速器，是入場費。

治理表：用 CIA 三性走一遍，每條都有證據

換一頂帽子。以下每一條都對照本系列實測到的事，Annex A 條號依 ISO/IEC 27001:2022，供做控制項對應時參考。

機密性：資料去了哪裡

資料主權是地端的第一價值，但地端不等於資料不落地。 ds4 的磁碟 KV 目錄在 /var/lib/ds4-kv，現在 49.2 GB、256 個 .kv 檔，最舊的檔案是 8 月 13 日、二十六天前的還在。裡面是算過的對話前綴，也就是提示詞內容的可重建形式，躺在 NVMe 上沒有淘汰機制。Day 20 的 dsh session 事件流是逐事件的完整紀錄（單一任務 22,363 個事件），內含每一次工具呼叫的完整參數。這些是稽核資產，同時也是資料落地點，進客戶環境前要問：這些檔案加密了嗎、誰能讀、保存多久、怎麼銷毀（A.8.10 資訊刪除、A.8.24 密碼學使用、A.5.33 記錄的保護，以及如果提示詞裡會出現客戶個資，A.5.34 隱私與 PII 保護）。

順帶一提那個沒有淘汰機制的代價正在變現：Day 28 記的根目錄剩餘空間是 38.1 GB，一天後的今天是 36 GB，掉的那 2 GB 正好對上日均寫入 1.89 GB 的估算。照這個速度，離塞爆還有二十天上下。要追的是空間不是碟的壽命，Percentage Used 還是 0%。

外送要有閘門。 Day 13 拆 Portable Computer 看到的審批式雲端升級（每一步外送都要人同意且留紀錄），是企業合規最想要的形狀。自建的話，Day 18 那層閘道就是做這件事的位置。

本系列的閘道目前沒有做這件事，而且可以講得很具體。我把 litellm-config.yaml 整份對 anthropic、openai、azure、gemini、bedrock、vertex、together、groq 與任何 https:// 掃過一遍，零命中：所有 api_base 都指向本機或內網，telemetry 是 false，唯一的對外憑證是進來方向的 master key。所以「資料不會外流」這句話在這套設定下是真的。

但沒有外送不等於有閘門。那份設定裡沒有 budget、沒有 guardrail、沒有速率限制、沒有人工核可，唯一的 callback 是把 max_tokens 夾住的成本護欄。今天要是有人加一行 provider 進去，沒有任何一層會攔它、也沒有任何一層會記下這件事發生過。審批機制在這套架構裡存在於 harness 層而不在閘道層（aiops-approval-audit.jsonl、dsh 的 settings.yaml），這正好就是下面第 4 條說的「缺一層要有補償控制」的實例：閘道那一層目前是空的，靠 harness 補（A.8.12 資料外洩防護是這件事的主控制項，A.5.23 雲端服務的資訊安全次之）。

外掛不受沙箱管。 Day 20 的探針實驗證明 dsh 的外掛跟 harness 同權限，裝一個外掛等於多跑一支完整權限的程式。控制手段只有一層：整個 harness 跑在專用容器、模型庫與資料目錄唯讀掛載（Day 5 的一寫多讀原則在這裡是安全控制不只是整潔）（A.8.18 特權公用程式的使用、A.8.19 作業系統上軟體的安裝）。

完整性：誰能改什麼

權限邊界要分層。 Day 21 的結論是指揮層看得見狀態看不見風險等級，harness 層有審批閘門但不含策略，閘道層做用量與速率限制。三層各做自己的事，沒有一層能單獨負責（A.5.15 存取控制、A.8.3 資訊存取限制）。

護欄要認得所有欄位。 Day 20 那個閘道只讀 max_tokens，客戶端送 max_completion_tokens 就無感繞過，這不是 harness 的錯，是護欄假設過時。任何在閘道層做的限制，都要對照客戶端實際送的請求驗一次（A.8.28 安全程式設計、A.8.29 開發與驗收中的安全測試）。

模型供應鏈。 Day 5 的 MANIFEST 記來源、sha256、授權，Day 12 提醒同名檔案配方不同（兩顆 MXFP4 注意力層一顆 BF16 一顆 q8_0），Day 22 的剪枝變體在 agent 迴圈裡語言漂移且 JSON 壞掉，Day 27 的 21 個 NGC tag 只有一個能用。模型是供應商提供的軟體元件，要用供應商管理的規格對待：來源可驗、版本固定、變更留痕。IFA 同週 NVIDIA 宣布收購 Hugging Face，整個開放權重生態的主要發行管道所有權變動，這是供應鏈集中風險的教科書案例，MANIFEST 裡的來源欄位從此不只是紀錄，是你在管道變動時能否重建供應鏈的依據（A.5.19 供應商關係中的資訊安全、A.5.20 供應商協議中的資訊安全處理、A.5.21 ICT 供應鏈的資訊安全）。

衍生模型的授權。 Day 26 的 zh-writer 底模 Apache 2.0 所以衍生跟著走，Flash-Next 換成 qwen-community-1.0 要讀條款。微調產物是交付物的一部分，授權要寫進 MANIFEST 與合約（A.5.32 智慧財產權）。

可用性：它撐不撐得住

Day 28 整篇。 停擺兩次半、43 分鐘倒數、看門狗、兩層健康檢查、20 到 45 分鐘重啟。以稽核的眼光，可用性控制的證據不是「我們有監控」，是「哪一次故障被哪一條規則接住了」，Day 28 那張每行對應一次真實故障的清單就是這種證據的形狀（A.8.16 監控活動、A.5.30 ICT 備援）。

兩台不等於備援。 這一條值得單獨寫，因為它最容易被誤讀。買了第二台之後，直覺是「一台掛了還有一台」。實際上兩台是合體成一顆模型，掛一台等於整個服務不見，而且分家回單機要 40 分鐘。今天那個 NFS 掛載失敗就示範了一次：141 少了一個掛載點，整個叢集就起不來。雙機在這裡是效能配置不是高可用配置，寫進提案文件的時候不要含糊（A.8.14 資訊處理設施的備援）。

監控的獨立性。 Day 28 發現每日巡檢是靠模型寫的，而模型正是被巡檢的東西，後端一掛報告就不存在，最需要報告的日子剛好沒有。稽核會問的問題是監控系統與被監控系統是否獨立，答案在這個架構裡是否，而且這是「用 agent 做維運」內建的耦合。至少要有一份不依賴模型的存活紀錄（sysstat 那種裝好就在跑的東西），而且要知道它留幾天（A.8.15 日誌記錄）。

變更管理。 每次重啟 20 到 45 分鐘，設定改了不 restart 不生效，KV 池每次啟動都漂。變更要批次、要記錄、要有回滾路徑（Day 26 那個註解掉的區塊就是回滾路徑）（A.8.32 變更管理）。

稽核軌跡：出事能不能重建

這是本系列在治理面最強的一項。DeepSeek Haness，dsh 的 session 事件流是 append-only、逐事件、可重播，每一次工具呼叫、完整參數、每一次審批的問與答、每一次沙箱模式變更都在裡面（Day 20 的評語是「及格有餘」）。閘道的逐請求記錄器把每一個請求的完整 messages 序列化落檔（Day 19 到 22 的所有流量解剖都靠它）。NVMe 的 Unsafe Shutdowns 計數器是一份不會過期、不需要維護的硬故障紀錄。

三份紀錄的共同課題是保存期限與存取控制，Day 28 那個「sysstat 只留七天差三天就刪掉」的險勝，換成稽核語言就是日誌保存政策沒有定義。進客戶環境的第一件事是把三份紀錄的保存期限、輪替、存取權限寫下來（A.5.28 證據的蒐集、A.8.15 日誌記錄、A.8.17 時鐘同步，兩台機器的時間戳要能對齊）。

給 MSP 與企業的治理清單

如果我要把這套架構帶進客戶環境，合約與部署文件裡會有這十二條：

1. 資料落地清單：KV 快取、session 紀錄、閘道日誌、模型庫，各自的位置、加密、保存期限、銷毀方式
2. 外送閘門：任何離開地端的請求要經過審批或明確的白名單，且留紀錄
3. harness 跑在專用容器，模型庫與資料目錄唯讀，外掛視同完整權限程式審查
4. 三層權限：閘道限量、harness 審批、指揮層可觀測，缺一層就要有補償控制
5. 閘道護欄對照客戶端實際請求驗證，新舊欄位都要認得
6. 模型供應鏈：MANIFEST 含來源、雜湊、授權、量化配方，版本固定，發行管道變動時可重建
7. 衍生模型授權寫進交付文件
8. 可用性證據以「故障對規則」的形式呈現，不以「有監控」為足
9. 至少一份不依賴模型的獨立存活紀錄，保存期限明訂
10. 變更批次化、留紀錄、有回滾路徑，重啟時間以最壞值排程
11. 提示詞與輸出的再利用政策：預設不進入訓練資料、不外送做評估，例外要書面同意
12. 兩台機器、NAS 與閘道的時鐘同步，否則三份稽核紀錄對不起來

第 4 與第 5 條都落在閘道層，看起來可以合併，我刻意分開：一條講的是權限邊界，一條講的是那個邊界有沒有被實際驗證過。Day 20 那個 max_completion_tokens 就是邊界畫對了但沒驗過的例子。

明天預告

三十天的最後一篇，把整個系列收成一張可複製的地端 AI 藍圖，硬體、網路、儲存、引擎、模型、agent、微調、維運、成本、治理，每一層一句話與一個數字，加上 IFA 之後的產業展望（RTX Spark Windows 機十月上市、NVIDIA 收購 Hugging Face 對開放權重生態的意義），以及這三十天我自己的結論。番外的 Day 31 留給 NVIDIA PAIR，把桌機那兩張卡也拉進來的第三種雙機用法。

我們 Day 30 見囉。

我為這個系列文製作的二個專案已經公開放 GitHub 上

https://github.com/ivanusto/gb10-ops
https://github.com/ivanusto/llm-zhtw-agent-exam

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 藍圖