](http://)

把社群推薦神機從開機到可以工作的整備

前三天把架構藍圖說明清楚以及重要基礎概念先講過一遍後，今天來進行設定的實作。一台剛開箱或重置後的 DGX Spark 距離可以開始部署模型之間，還有一段整備工作，系統更新、驅動確認、容器環境驗證、網路設定、掛上模型庫。這篇把這段路走完，並且整理成一份可以照抄的檢查清單，之後第二台 Spark 要加入叢集時，同一份清單再走一次就好。

這款機器被社群推薦，近期也有很多人在徵求這一款機器的二手機，或買到更大機型 DGX 伺服器的企業也不少，剛好是一個地端 AI 的發展期。

DGX OS:熟悉的 Ubuntu，加上打點好的 NVIDIA 全家桶

DGX Spark 和其他 DGX Server 出廠都是預先安裝好的 DGX OS 這套 Linux Distro，本質上是 Ubuntu Linux 的 NVIDIA 客製化版本，NVIDIA 把 GPU 驅動、CUDA 工具鏈、Docker 與 NVIDIA Container Toolkit 都預先整合好了。這是它與自組伺服器、工作站、PC 最大的體驗差異，你不需要經歷「裝驅動、對 CUDA 版本、修 Docker runtime」的傳統流程

開機完成初始設定後，第一件事是把系統更新到最新，在終端機視窗中，下這個指令，如一般 Ubuntu、Debian 系列 Linux 更新軟體與系統的方式一樣。

sudo apt update && sudo apt full-upgrade -y

更新完重開機，然後開始逐項確認環境。以下每一步都附上驗證指令，任何一步的輸出不如預期，就停下來處理，不要帶著問題往下走，不然後面還是要研究一下怎樣處理，會比較花時間。

檢查點一:GPU 與驅動

nvidia-smi

這個指令之後算是很常用到的，除了標準的指令外，還可以加上參數確認更多事情，或定時更新資料來看。這邊我們只要先確認三個事情即可，也就是驅動程式版本、CUDA 版本、GPU 型號正確辨識為 GB10。這邊請特別看一下記憶體欄位，統一記憶體架構下這裡顯示的可用量與傳統獨顯的邏輯不同，系統與 GPU 共享同一池，實際可用量會隨系統占用而產生浮動的變化，這是正常現象。

free -h

對照一下系統看到的總記憶體。128GB 的標示扣掉韌體與系統保留後，實際可用會略少，這是正常的。

檢查點二:Docker 與 GPU 容器

地端 AI 的工作負載幾乎都活在容器裡，重開方便，且資料在本機 SSD 上或 NAS 上持久化，所以 Docker 能不能吃到 GPU 是重要關鍵:

docker run --rm --gpus all ubuntu nvidia-smi

容器內能跑出與宿主機一致的 nvidia-smi 輸出，代表 NVIDIA Container Toolkit 運作正常。這一步過了，後面 vLLM、llama.cpp、ComfyUI 的容器化部署就都有了地基。

這邊我順手也把目前使用者加入 docker 群組，省去每次 sudo:

sudo usermod -aG docker $USER

這時只要登出再登入後，該設定就生效了。也順便做一個資安提醒，docker 群組等同於 root 權限的入口，這台機器如果不是單人使用，要做這一步的話請三思。

檢查點三:NGC 容器庫

NVIDIA 官方為 DGX Spark 維護的容器映像都放在 NGC(NVIDIA GPU Cloud)，包括我們近期會用到的 vLLM 官方映像。先拉一個基礎 CUDA 映像檔，我們來驗證看看連線與執行的狀態:

docker pull nvcr.io/nvidia/cuda:13.0.0-base-ubuntu24.04
docker run --rm --gpus all nvcr.io/nvidia/cuda:13.0.0-base-ubuntu24.04 nvidia-smi

映像標籤以 NGC 目錄當下提供的版本為準，重點是驗證從 nvcr.io 拉取與執行的整條路是通的。

檢查點四:10GbE 網路設定

依照 Day 3 的規劃，這台 Spark 透過 10GbE 介面接上骨幹交換器。確認連線速率有跑滿:

ip -br addr
ethtool <介面名稱> | grep Speed

請看圖片下方的 Speed 有顯示 10000Mb/s。這裡我設定了靜態 IP，模型庫掛載與各節點互連都需要固定 IP 比較好用，DHCP 租約變動在這種環境是問題， IP 跑掉的話，測試程式和 AI 推論平台就會連不到了。DGX OS 使用 Netplan 管理網路，設定檔改完套用:

sudo netplan apply

檢查點五:掛上 NFS 模型庫

把 Day 3 設計的集中模型庫接上來。安裝 NFS 客戶端、建立掛載點、寫入 fstab (設定值請參考 Day 3 這篇)，然後驗證:

sudo apt install -y nfs-common
sudo mkdir -p /mnt/models
sudo mount -a
df -h /mnt/models

看到 TS-464 的容量出現在輸出裡，讀寫測試一個小檔案確認權限正常，模型庫就緒。

檢查點六:日常工具

最後補上維運日常會用到的工具:

sudo apt install -y htop nvtop tmux iperf3

nvtop 是 GPU 版的 htop，觀察推論時的 GPU 使用率與記憶體變化非常直覺，本系列後面的截圖也會看到的。iperf3 則留給網路吞吐驗證，Day 3 提到的 10GbE 實務有效吞吐，我們可以自己量:

# NAS 或另一台節點作為 server 端
iperf3 -s
# Spark 作為 client 端
iperf3 -c <對端 IP>

我環境的實測結果約 9.4X Gbps，這個數字之後在模型載入時間的計算會用到。

整備完成檢查清單

這裡我也順便整理成清單，第二台 Spark 要加入這個 AI 算力叢集時再走一遍一樣的即可:

• [ ] 系統更新至最新並重開機
• [ ] nvidia-smi 確認驅動與 GB10 辨識
• [ ] 容器內 GPU 可用(docker run --gpus all)
• [ ] NGC 拉取與執行驗證通過
• [ ] 10GbE 連線速率確認，靜態 IP 就位
• [ ] NFS 模型庫掛載並通過讀寫測試
• [ ] htop、nvtop、tmux、iperf3 就位

明天預告

環境整備完成，接著會進入 NFS 模型庫的實戰細節，包括目錄結構的實際建置、模型下載工具的選擇、多主機共用時的權限設計，以及模型版本管理的做法。把倉庫整備好，推論引擎實測就會更順利些，省掉公司部署的時間。

我們 Day 5 見囉。

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