模型放哪裡，是小問題也是架構問題

昨天我們用 Qwen3.8-27B 簡單做了一個記憶體的比較，和實務上為何要那麼多 VRAM 或統一記憶體來協助地端 AI 運算，這邊先 recap 一下，也就是有夠多的記憶體能載入這些開放模型權重是一件事情，但要留有足夠的剩餘記憶體空間，讓它能夠跑 KV Cache ，才有足夠的上下文，不然你的 AI 代理人，跑很多任務時，它記憶體很快就爆掉了，你的任務根本就沒辦法用。如果是一問一答那種 Open Web-UI 形式的聊天機器人，簡單的問題還可以，多問一下更多的內容它也是會爆掉，所以不實用。較小的顯示卡記憶體如 16GB 的，我會讓它拿來算圖算影片產音樂，這是比較能夠做的。

回到今天的主題，這些 AI 模型權重檔案的大小，動輒 15GB 到 56GB，甚至 100GB 或更多 (如參數超大，檔案上 TB 等級的)。所以呢，今天換一個角度想，當你的環境裡不只一台機器要跑模型的時候，這些權重檔案該放哪裡才好呀?

最直覺的做法，是每台機器的本機碟各放一份。三台機器就是三份，模型更新一次就要同步三次，過兩個月你就會分不清哪台上面的是哪個版本。這在單人實驗環境還能忍，放進任何需要被管理的企業環境時，就會變成災難。

本系列採用的做法是透過簡單的 NFS 集中模型庫方法，讓模型權重只存一份在 NAS 上，所有運算節點透過網路掛載同一個目錄，如果有 CEPH 分散式儲存結構也行，這個更適合更大型的企業專案。今天這篇，則是說明一下我自己的整體網路拓撲怎麼規劃、NFS 怎麼設定，以及誠實去面對這種相對較簡單省成本架構的效能代價。

全景:這個環境裡有哪些角色呢?

按照 ISO 慣例，先談全景，我們先盤點本系列實驗環境的完整成員，後續文章提到任何一台機器時都會以這裡的名稱為準:

運算節點

DGX Spark 1(128GB 統一記憶體):主力 AI 推論節點，目前常駐在執行 DeepSeek V4 Flash 0731
DGX Spark 2(128GB 統一記憶體):剛歸隊的第二台 GB10，解除原本任務重新加入本叢集，雙機分散式推論是本系列的環節之一
桌機 1(Intel 平台，128GB RAM，RTX 5060 Ti 16GB):次要推論與 ComfyUI 節點
桌機 2(AMD 平台，32GB RAM，RTX 3060 12GB):輕量推論與測試節點

儲存節點

QNAP TS-464(10GbE):NFS 集中模型庫的家

虛擬化平台

Proxmox VE 節點 x 3:周邊服務與實驗環境，主力節點為 i5 處理器搭配 64GB RAM
Vmware 節點 x 1:實驗環境，蜂巢虛擬化

網路

10GbE 交換器一台，為核心交換意，全環境骨幹
2.5GbE 交換器一台，擔任邊緣交換器
雙 Spark 之間另有一條 QSFP28 直連線路，暫時只有跑 100GbE

畫成拓撲是這個樣子:

兩層網路的設計邏輯

注意雙 Spark 有兩條路可走，這不是浪費，是刻意的流量分離:

10GbE 層負責「搬模型」與管理流量

所有節點從 TS-464 掛載 NFS 讀取模型權重、SSH 管理、監控資料回傳，都走這一層。10GbE 的實務有效吞吐約 1.1GB/s 出頭，載入一個 4-bit 量化的 27B 模型(約 15GB)大約十幾秒，載入 BF16 全精度(約 56GB)則要接近一分鐘。這個速度用於開機時載入一次的場景完全可以接受，之後每次推論或 AI 代理人任務就不會碰到這種較長載入的時間。

100GbE 直連層負責「跑分散式推論」

當一個模型大到單台 Spark 的 128GB 裝不下，或想用兩台的算力合跑一個模型時，兩張 GPU 之間在每一層運算都要交換張量，這種流量對延遲與頻寬極度敏感，走 10GbE 交換器會直接讓效能掛掉。而 DGX Spark 內建的 ConnectX-7 網卡支援到 200GbE，目前我手上的線材是 QSFP28，這條透過電商網購大概五百元左右而已，所以先跑 100GbE，之後升級 QSFP56 線材就能解鎖 200GbE，屆時會有前後對比實測。

一個簡單的概念和原則是這樣的，大流量、低延遲需求的東西給雙機之間的高速專線，其他的流量一切走 10GbE 骨幹網路為主。這個原則在企業網路設計中是簡單的流量工程，在家庭實驗室 HomeLab 裡，也是流量工程，並省下一台 100GbE 交換器的錢。

TS-464 上的 NFS 模型庫實作

模型庫的目錄結構我採用「來源/模型家族/版本」三層:

/share/models/
├── huggingface/
│ ├── Qwen3.8-27B/
│ ├── DeepSeek-V4-Flash-0731/
│ └── ...
├── gguf/
│ ├── qwen3.8-27b-q4_k_m/
│ └── ...
└── comfyui/
├── checkpoints/
├── loras/
└── vae/

分層的理由很實際，Hugging Face 原始格式(safetensors)給 vLLM 與 Transformers 用，GGUF 給 llama.cpp 用，ComfyUI 的模型目錄結構自成一格，混在一起只會互相干擾，所以分開比較好。

NAP 端在「控制台 → Win/Mac/NFS」啟用 NFS 服務後，對 models 共享資料夾設定 NFS 存取權限，限制只允許內網運算節點的 IP 段掛載。

運算節點端的掛載參數才是重點。以常見的 fstab 寫法為例：

192.168.0.5:/share/models /mnt/models nfs rw,noatime,vers=4.1,rsize=1048576,wsize=1048576,nconnect=8,hard,timeo=600,retrans=2,_netdev 0 0

我自己則是寫成 systemd 的 mount unit，/etc/systemd/system/mnt-nas.mount：

[Mount]
What=192.168.0.5:/Public
Where=/mnt/nas
Type=nfs
Options=rw,hard,nconnect=8,timeo=600,retrans=2,noatime,nofail,vers=4.1
TimeoutSec=60

sudo systemctl start mnt-nas.mount 之後：

$ mount | grep nfs
192.168.0.5:/Public on /mnt/nas type nfs4 (rw,noatime,vers=4.1,rsize=1048576,
wsize=1048576,namlen=255,hard,fatal_neterrors=none,proto=tcp,nconnect=8,
timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.3,local_lock=none,addr=192.168.0.5)

參數說明。rsize/wsize 讓每次 RPC 搬更多資料，不過這兩個值是跟 NAS 協商出來的，這台協商結果本來就是上限 1 MiB，寫不寫都可以。noatime 這個設定呢，則省掉讀取時回寫存取時間。hard 這項是確保 NAS 短暫離線時 IO 等待重試而不是報錯，載入 safetensors 時 soft 報錯會讀到半截權重，比載入卡住更不好喔。timeo=600 的單位是十分之一秒，也就是 60 秒，坊間很多範例寫的 timeo=30 其實只有 3 秒，太短就較不建議這樣設。nconnect=8 建立多條 TCP 連線平行搬運，這個參數，實際上沒有大家說的那麼神。

本機 NVMe 約是 NAS 的 2.8 倍。

誠實這個架構會慢的代價

集中模型庫其實沒有那麼美好，實際上它有三個瓶頸要面對。

第一，NAS 的磁碟陣列可能比網路先到頂。10GbE 的 1.1GB/s 聽起來很快，但 TS-464 是 4-bay 機種，如果裡面裝的是傳統硬碟組 RAID，循序讀取可能連 10GbE 都餵不飽。要讓這個架構發揮，NAS 端的讀取來源最好是 SSD，或至少讓熱門模型落在 SSD 快取上。

第二，冷啟動變慢是事實。本機 NVMe 的循序讀取是 GB/s 起跳好幾倍，從 NFS 載入一定比本機慢。我的取捨是常駐使用的主力模型(例如 DeepSeek V4 Flash)在 Spark 本機 NVMe 留一份快取，需要切換不同用途、實驗性質、久久跑一次的模型則全部走 NFS 用網路載入。NFS 集中庫負責所有的模型都有一份可以給其他裝置共用，本機快取負責速度，所以兩者並不衝突。

第三，NFS 是單點，所以會有單點風險/單點故障。當 NAS 萬一當機或掛掉的時候，可能服務不能用或要等系統重啟，或更嚴重是需要維修，所有節點的模型庫一起消失。以實驗室規模而言，我接受這個風險，但是換到企業場景時，就要考慮到副本或分散式儲存，實務上我們就會做 NAS HA 機制，或二台 NAS 一主一備，而要用到分散式儲存，你手上的設備得夠多才騰得出來，因此企業至少低消要二台 NAS 這點無庸置疑，之後企業級規劃會延伸討論留到系列後段的維運篇。

明天預告

網路與儲存就位之後，明天回到 DGX Spark 本身，DGX OS 初始環境建置、Docker 與 CUDA 生態確認，把一台開箱狀態的 Spark 整備到可以用的狀態，以及其他奇妙的東西。

Day 4 見。

Day 1｜為什麼 2026 年是地端 AI 部署元年：系列規劃與硬體總覽
Day 2｜DGX Spark GB10 深度解析：128GB 統一記憶體到底解決了什麼問題
Day 3｜網路與儲存規劃：10GbE 骨幹、雙 Spark 直連與 NFS 集中模型庫
Day 3｜Day 4|開箱之後：DGX OS 初始環境建置與 CUDA、Docker 生態確認