---
title: "使用 10G 私有網路連接 Bestnet Cloud × GPU-VPS，
實作 GPUStack 叢集的步驟"
description: "操作指南 BESTNET-CLOUD GPU-VPS GPUStack 10G [私有網路](https://bestnetllc.co.jp/zh-hant/encyclopedia/%e7%a7%81%e6%9c%89%e7%b6%b2%e8%b7%af-zh-hant/) NFS 共用快取 技術部落格 / 基礎架構建置指南 # 透過 10G 私有網路連接 Bestnet Cloud × GPU-VPS， GPUStack 叢集實作指南 將 Bestnet Cloud 作為控制平面、GPU-VPS 作為推論工作節點分離， 並以共用 NFS 快取集中管理模型檔案。 從客戶主控台的事前準備 到在 Ubuntu 上實作與運作驗證，我們將其整理成一篇操作指南文章。 我們實際在 Ubuntu 24 / GPUStack 0.6.x 系列上執行的初期建置範例10G…"
url: "https://bestnetllc.co.jp/zh-hant/docs/%e4%bd%bf%e7%94%a8-10g-%e7%a7%81%e6%9c%89%e7%b6%b2%e8%b7%af%e9%80%a3%e6%8e%a5-bestnet-cloud-x-gpu-vps%ef%bc%8c%e5%af%a6%e4%bd%9c-gpustack-%e5%8f%a2%e9%9b%86%e7%9a%84%e6%ad%a5%e9%a9%9f/"
updated: "2026-10-14"
category: Tech Blog / GPU 與 LLM 基礎設施
---
# 使用 10G 私有網路連接 Bestnet Cloud × GPU-VPS，
實作 GPUStack 叢集的步驟
操作指南
BESTNET-CLOUD
GPU-VPS
GPUStack
10G [私有網路](https://bestnetllc.co.jp/zh-hant/encyclopedia/%e7%a7%81%e6%9c%89%e7%b6%b2%e8%b7%af-zh-hant/)
NFS 共用快取
技術部落格 / 基礎架構建置指南
# 透過 10G 私有網路連接 Bestnet Cloud × GPU-VPS，
GPUStack 叢集實作指南
將 Bestnet Cloud 作為控制平面、GPU-VPS 作為推論工作節點分離，
並以共用 NFS 快取集中管理模型檔案。
從客戶主控台的事前準備
到在 Ubuntu 上實作與運作驗證，我們將其整理成一篇操作指南文章。
我們實際在 Ubuntu 24 / GPUStack 0.6.x 系列上執行的初期建置範例10G
私有連線1 次
模型下載2 台以上
GPU 工作節點1 處
共用模型儲存空間範圍
### 本文涵蓋範圍
本文介紹的初期建置模式為**在 Bestnet Cloud 上啟動 AI-SRV，將 GPUStack Server + NFS 整合於同一節點**，
**並在 GPU-VPS 端部署多台 GPU 工作節點**。
由於角色分離與共用快取設計為主要主題，公開 IP 位址與內部命名規則皆已替換為範例值。
本設計的核心，是將不需要 GPU 的控制平面與模型儲存位置放在通用雲端一側，
並讓 GPU-VPS 純粹作為推論執行節點。
如此一來，即使日後新增工作節點，也能避免重複的儲存投資，
並只在 Bestnet Cloud 側的共用區域管理實際模型。
不使用 VRRP / Keepalived
模型註冊僅透過 GUI 進行
GPUStack Server + NFS 整合於 AI-SRV
所有工作節點共用 NFS 掛載點 /models**備註：**本文的重點在於「初期建置版」。遷移至 GPUStack 2.x 的內容已整理於[另一篇文章](https://bestnetllc.co.jp/zh-hant/docs/%e5%be%9e-gpustack-v0-7-1-%e9%81%b7%e7%a7%bb%e8%87%b3-v2-1-1-%e7%9a%84%e7%b6%93%e9%a9%97%e5%88%86%e4%ba%ab/)，
在此則清楚整理 0.6.x 系列的建置模式。知識對照
## 依實際建置順序重新解讀 Bestnet Cloud 相關知識
在 Bestnet Cloud 知識庫中，客戶主控台的操作項目已被詳細拆解。
因此在建置 GPU 叢集時，事先決定「哪個知識該在什麼時機使用」可以減少返工。
本文依以下順序整理主控台端的事前準備。
1
**主控台防護**
先決定 MFA 與允許 IP 的處理方式2
**SSH 金鑰註冊**
在部署作業系統前先設定管理用金鑰3
**建立範本**
在 Ubuntu 24 上準備 AI-SRV 與 GPU-VPS4
**[私有網路](https://bestnetllc.co.jp/zh-hant/encyclopedia/%e7%a7%81%e6%9c%89%e7%b6%b2%e8%b7%af-zh-hant/)**
將所有節點連接至 10G 網段5
**防火牆 / NAT**
縮小公開範圍與通訊方向6
**快照**
在初始狀態保留還原點
主控台
### 客戶主控台安全性設定
先確保管理介面本身的安全，才能讓後續的伺服器建立與權限管理更安全。
存取
### SSH 金鑰註冊與管理
與其在伺服器建立後個別插入金鑰，不如在部署範本前先決定金鑰的操作方式。
佈建
### 從範本建立伺服器
將 AI-SRV 與 GPU 工作節點統一使用相同的基礎作業系統，可避免後續指令流程出現差異。
網路
### [私有網路](https://bestnetllc.co.jp/zh-hant/encyclopedia/%e7%a7%81%e6%9c%89%e7%b6%b2%e8%b7%af-zh-hant/)
事先決定 NFS 與叢集通訊的內部路由，即可將公開埠口降到最少。
防護
### 防火牆設定變更
依照不對外公開不必要介面的原則，僅保留 AI-SRV UI、NFS 與 GPU 工作節點的 SSH。
### 快照管理
在作業系統初始化後、GPU 驅動程式安裝後、應用程式安裝前分別建立還原點，可讓測試更容易進行。
擴充
### 雲端資源升級
當容量不足時，優先擴充 AI-SRV 端的共用模型區域，成本效益較佳。
### 虛擬路由器 NAT
若想將 GPU 工作節點設為純私有，也可以選擇僅讓出站通訊經過 NAT 的設定方式。
架構
## 架構設計方式
角色分工十分單純。Bestnet Cloud 端的 AI-SRV 負責**Web UI / API / NFS 共用**，
而 GPU-VPS 端的節點僅專注於**GPUStack Worker 與推論執行**。
透過 10G 私有網路將內部通訊封閉起來，
即可將模型分發、NFS 與叢集連線全部移至私有側。
BESTNET-CLOUD
### control-01
整合 GPUStack Server + NFS 的 AI-SRV
- 提供 Web UI / API
- 透過 NFS 匯出 `/srv/gpustack_models`
- 在本機以繫結掛載至 `/models`
- 將模型實際儲存位置集中於一處
⇄10G [私有網路](https://bestnetllc.co.jp/zh-hant/encyclopedia/%e7%a7%81%e6%9c%89%e7%b6%b2%e8%b7%af-zh-hant/)
NFS / UI / Worker 加入 / 內部通訊⇄
GPU-VPS
### gpu-worker-01 / 02
共用 `/models`、僅負責推論的工作節點群組
- 啟動 GPUStack Worker
- 統一使用 `--cache-dir /models`
- 各工作節點不持有大量模型儲存空間
- 水平擴充時，以相同模式新增節點
透過 GUI 部署模型
→
第一個工作節點僅取得模型一次儲存至共用 NFS
→
其他工作節點從相同的 `/models` 讀取
### 將儲存空間集中於 AI-SRV 端
容量規劃的主戰場在於 AI-SRV。請考量模型本身、暫存下載檔案與未來的模型替換，充分保留共用區域空間。
### 讓 GPU-VPS 保持精簡
GPU 工作節點端的設計，應聚焦於作業系統、GPU 驅動程式、GPUStack Worker 與最小限度的日誌區域，不重複儲存模型本身。
### 將通訊集中於私有側
當 UI、工作節點加入、NFS 與模型重複使用都在私有網路上完成時，公開範圍便會縮小。
設計工作表
## 事先應決定的項目
| 角色 | 所在位置 | 主機名稱（範例） | 私有 IP（範例） | 主要職責 |
| --- | --- | --- | --- | --- |
| Server + NFS | Bestnet Cloud | control-01 | 10.10.0.10 | GPUStack UI / API、NFS、模型儲存 |
| GPU Worker #1 | GPU-VPS | gpu-worker-01 | 10.10.0.21 | 推論執行、共用 `/models` 使用 |
| GPU Worker #2 | GPU-VPS | gpu-worker-02 | 10.10.0.22 | 推論執行、共用 `/models` 使用 |
以上為公開發布用的範例值。實際上線時，請依照自身的命名規則與私有子網路調整。
### 設計檢查要點
- 要為哪些節點配置公開 IP
- 是否要讓工作節點僅限私有
- 要使用 NAT 路由器，或個別提供出站通訊
- 共用模型區域的初始容量與擴充計畫
### 儲存空間估算方式
- 使用中模型的總大小
- 切換期間新舊模型暫時並存的預留空間
- 如 `.part` 之類的暫存檔案空間
- 日誌、運作檔案，以及未來新增工作節點的預留空間
階段 1
## 先確立客戶主控台的事前準備
01
### 保護客戶主控台本身
在建立伺服器之前，先決定管理防護方針。尤其是團隊作業時，
先釐清 MFA 與允許 IP 的處理方式，可避免日後對「誰能從哪裡存取管理介面」產生混亂。
**建議：**在管理主控台啟用雙重驗證，並盡可能限制管理來源 IP。02
### 在建立伺服器前先註冊 SSH 金鑰
與其在建立 AI-SRV 與 GPU 工作節點後才個別插入金鑰，不如事先在客戶主控台的 SSH 金鑰管理中準備好金鑰，
即可在部署範本後立即取得管理存取權。
- 整理團隊作業用的公開金鑰
- 共用金鑰與緊急狀況用的個人金鑰不要混用
- 不要在公開文章中張貼金鑰指紋
03
### 從範本在 Bestnet Cloud 上建立 AI-SRV
AI-SRV 使用 Ubuntu 24 系列範本，同時承載 GPUStack Server 與 NFS。
由於此節點同時作為模型儲存空間，請與作業系統磁碟分開設計，配置充足的儲存空間。
- 角色為 **GPUStack Server + NFS**
- 連接至私有網路
- 僅在需要公開 UI 時才考慮公開側
- AI-SRV 的模型儲存容量應配置得比工作節點更多
04
### 依所需數量在 GPU-VPS 上建立工作節點
由於工作節點用於推論，請依 GPU 類型、VRAM 與未來模型大小選擇 GPU-VPS 方案。
另一方面，由於模型本身保存於 NFS 側，工作節點的儲存空間可輕易縮減至作業系統與執行所需的最小限度。
- 統一使用 Ubuntu 24 系列
- 建立時需可使用 GPU 驅動程式 / CUDA
- 連接至私有網路
- 若不需要公開 IP，可考慮設為僅限私有
05
### 將所有節點置於 10G 私有網路上
NFS 與 GPUStack 的內部通訊，透過連接 Bestnet Cloud 與 GPU-VPS 的 10G 私有連線傳輸。
如此一來，模型取得與工作節點加入都能維持在私有側進行。
- 讓 AI-SRV 與所有工作節點都位於相同的私有網段
- 指派固定 IP，以穩定後續的 NFS 匯出與 systemd 設定
- 若工作節點需要出站通訊，可選擇 NAT 路由器方式或暫時的公開出口
若想將工作節點設為純私有，使用 Bestnet Cloud 的虛擬路由器 / NAT 模式，僅用於作業系統更新與對外擷取，管理上會更輕鬆。
06
### 決定初始防火牆規則
採取「僅允許 AI-SRV 必要的最小限度傳入，工作節點幾乎不允許公開傳入」的方針即可。
在主控台的防火牆畫面中，先確認現有規則，再僅新增必要的埠口。
| 對象 | 埠口 / 通訊協定 | 來源考量 | 用途 |
| --- | --- | --- | --- |
| AI-SRV | `22/tcp` | 僅限於管理來源 IP | SSH |
| AI-SRV | `80/tcp` | 管理網路或私有側 | GPUStack Web UI / API |
| AI-SRV | `2049/tcp` | 僅限私有子網路 | NFS v4 |
| AI-SRV | `111/tcp,111/udp` | 僅在需要時限於私有子網路 | 使用 rpcbind 的設定 |
| GPU Worker | `22/tcp` | 僅限於管理來源 IP | SSH |
假設使用 NFS v4，很容易將埠口統一為 2049/tcp，不過部分環境可能會使用 rpcbind。請務必將公開範圍限制在私有子網路內。
07
### 建立初始快照
在完成作業系統初始建立、金鑰注入、私有網路連接與防火牆設定後，
請為 AI-SRV 與 GPU 工作節點建立快照，以便日後若中介軟體安裝失敗時更容易還原。
階段 2
## 建立作業系統基礎環境
在伺服器與工作節點兩端，請先統一時間同步與 NFS 基礎設定。由於 GPU 工作節點之後會安裝 GPU 驅動程式 / CUDA，
事先完成作業系統更新與重新啟動節點，可讓系統更穩定。
```
# All nodes
sudo apt update
sudo apt install -y nfs-common
# For NFS server (AI-SRV only)
sudo apt install -y nfs-kernel-server
```
### AI-SRV 端要統一的項目
- 時間同步
- NFS 伺服器
- 模型儲存掛載設計
- GPUStack Server 初始部署
### GPU 工作節點端要統一的項目
- 時間同步
- NFS 用戶端
- GPU 驅動程式 / CUDA
- GPUStack Worker 與 `/models` 掛載
階段 3
## 在 AI-SRV 上建置 GPUStack Server + NFS
08
### 安裝 GPUStack Server
在初期建置範例中，我們在 AI-SRV 上部署 GPUStack Server，以便登入管理介面。
記錄初始管理員密碼後，請將其移至安全的保管處，切勿張貼於文章中。
```
curl -sfL https://get.gpustack.ai | sh -s -
cat /var/lib/gpustack/initial_admin_password
# Web UI (example)
# http://10.10.0.10/
```
09
### 建立 NFS 共用目錄
將模型檔案實體存放於 `/srv/gpustack_models`。
僅將此目錄匯出至私有子網路，並在 AI-SRV 本機也以繫結掛載方式掛載為 `/models`。
這樣可讓伺服器端所看到的路徑與工作節點所看到的路徑保持一致。
```
sudo mkdir -p /srv/gpustack_models
echo "/srv/gpustack_models 10.10.0.0/24(rw,sync,no_subtree_check,no_root_squash)" | sudo tee -a /etc/exports
sudo exportfs -ra
# Server itself also bind mount
sudo mkdir -p /models
sudo mount --bind /srv/gpustack_models /models
echo "/srv/gpustack_models /models none bind 0 0" | sudo tee -a /etc/fstab
```
**重點：**務必將匯出範圍限制在私有子網路內。切勿將 NFS 開放至公開側，這一點至關重要。10
### 發行工作節點加入權杖
從 GPUStack GUI 建立工作節點加入權杖。在公開文章中，請以 `` 表示，
切勿張貼實際數值。此外，將 GUI 登入來源限制在私有網路側會更安全。
階段 4
## 在 GPU-VPS 端掛載共用快取並讓工作節點加入
11
### 先透過 NFS 掛載 `/models`
每個工作節點都在相同的路徑 `/models` 掛載由 AI-SRV 匯出的共用區域。
這樣可讓所有工作節點的快取路徑保持一致，避免重複儲存模型。
```
sudo mkdir -p /models
echo "10.10.0.10:/srv/gpustack_models /models nfs defaults 0 0" | sudo tee -a /etc/fstab
sudo mount -a
```
掛載完成後，請以 `mount | grep /models` 確認可看到預期的共用位置。
12
### 安裝 GPUStack Worker
使用 AI-SRV 端發行的權杖，讓各台 GPU-VPS 以工作節點身分加入叢集。
```
curl -sfL https://get.gpustack.ai | sh -s - --server-url http://10.10.0.10 --token
```
13
### 在工作節點服務中固定 `--cache-dir /models`
在共用快取設定中，這項設定最為重要。請在 GPUStack Worker 的 systemd 定義中加入
`--cache-dir /models`，並同時固定 data-dir。
```
[Service]
ExecStart=/root/.local/bin/gpustack start --server-url http://10.10.0.10 --token --cache-dir /models --data-dir /var/lib/gpustack-data
```
```
sudo systemctl daemon-reload
sudo systemctl enable --now gpustack
# If "Using cache dir: /models" appears, OK
journalctl -u gpustack -f
```
14
### 在 GPUStack GUI 中確認工作節點為 Ready
在 GUI 的 Workers 畫面中，確認所有 GPU-VPS 節點均為 Ready 狀態。
若仍為 Not Ready，請依序排查 GPU 驅動程式 / CUDA、NFS 掛載、工作節點日誌。
階段 5
## 模型部署與運作驗證
完成的判斷標準不僅止於工作節點變為 Ready。
請實際從 GUI 以 2 個以上的副本數部署模型，確認僅有第一個節點會下載，
而第 2 個及之後的節點會重複使用相同的共用檔案。
1
### 從 Catalog 部署
將副本數設為 2 個以上，以建立多個工作節點被使用的條件。
2
### 第一個工作節點取得模型
若尚未儲存於 `/models`，則被指派的第一個工作節點會取得模型。
3
### 第 2 個工作節點讀取共用檔案
若共用快取中已存在相同模型，則會在不額外下載的情況下直接載入。
4
### 替換時重新部署
更新模型時，若採取在 GUI 中整理舊版、並重新部署新版的運作方式，會更容易追蹤。
### 此架構所帶來的成本最佳化
由於不需在每台 GPU-VPS 上保存完整的模型，GPU 節點的儲存空間更容易設計得精簡。
模型越大，共用 NFS 快取方式的效果就越明顯。
維運
## 維運時的要點
### 增加工作節點時
新增 GPU-VPS，並以相同的私有網路、相同的 `/models` 掛載、相同的 `--cache-dir` 進行水平擴充。
### 容量吃緊時
首先重新檢視 AI-SRV 端的共用模型區域。與其個別擴充各工作節點的儲存空間，加強共用端會更有效率。
### 變更前的還原點
養成在 GPU 驅動程式更新、CUDA 更新、GPUStack 更新之前先建立快照或備份的習慣，會更安全。
疑難排解
## 監控與疑難排解
### GPUStack 日誌
```
journalctl -u gpustack -f
```
確認 Server / Worker 的行為時，基本上先從這裡查看。
### 模型下載進度
```
ls -lh /models
find /models -name "*.part"
```
若有 .part 殘留，可能表示仍在下載中或下載尚未完成。
### 確認 NFS 狀態
```
mount | grep /models
```
確認工作節點端是否能看到預期的共用位置。
Q. 增加副本數會重新下載嗎？
基本上不會。只要共用 `/models` 中已存在檔案，工作節點就會重複使用該檔案。
Q. 工作節點一定需要公開 IP 嗎？
並非必要。若出站通訊改採 NAT 方式，也可以選擇以僅限私有的方式運作。
Q. 加強哪個部分能提升成本效益？
不是各 GPU 工作節點的儲存空間，而是設有共用模型存放區的 AI-SRV 端。因為模型可以集中在 1 處管理。
總結
## 將 Bestnet Cloud 作為控制端、GPU-VPS 作為執行端加以區分，GPU 叢集就會更容易管理
在 AI-SRV 上整合 GPUStack Server 與 NFS，GPU-VPS 群組則以工作節點身分掛接於私有網路之下。
在此基礎上將 `/models` 設為共用快取，即可在避免儲存空間重複的同時，順暢地擴充 GPU 叢集。
在主控台端，依 SSH 金鑰、範本部署、[私有網路](https://bestnetllc.co.jp/zh-hant/encyclopedia/%e7%a7%81%e6%9c%89%e7%b6%b2%e8%b7%af-zh-hant/)、防火牆、快照的順序完成準備，
在作業系統端則統一 NFS 與 GPUStack 的路徑。僅需如此，便能打造出相當便於實際運作的架構。
10G [私有網路](https://bestnetllc.co.jp/zh-hant/encyclopedia/%e7%a7%81%e6%9c%89%e7%b6%b2%e8%b7%af-zh-hant/)
BESTNET-CLOUD × GPU-VPS
NFS 共用快取
模型僅取得 1 次