使用 10G 私有網路連接 Bestnet Cloud × GPU-VPS,
實作 GPUStack 叢集的步驟

使用 10G 私有網路連接 Bestnet Cloud × GPU-VPS,實作 GPUStack 叢集的步驟

3 min read

操作指南
BESTNET-CLOUD
GPU-VPS
GPUStack
10G 私有網路
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 的內容已整理於另一篇文章,
在此則清楚整理 0.6.x 系列的建置模式。
知識對照

依實際建置順序重新解讀 Bestnet Cloud 相關知識 #

在 Bestnet Cloud 知識庫中,客戶主控台的操作項目已被詳細拆解。
因此在建置 GPU 叢集時,事先決定「哪個知識該在什麼時機使用」可以減少返工。
本文依以下順序整理主控台端的事前準備。

1
主控台防護
先決定 MFA 與允許 IP 的處理方式
2
SSH 金鑰註冊
在部署作業系統前先設定管理用金鑰
3
建立範本
在 Ubuntu 24 上準備 AI-SRV 與 GPU-VPS
4
私有網路
將所有節點連接至 10G 網段
5
防火牆 / NAT
縮小公開範圍與通訊方向
6
快照
在初始狀態保留還原點

主控台

客戶主控台安全性設定 #

先確保管理介面本身的安全,才能讓後續的伺服器建立與權限管理更安全。

存取

SSH 金鑰註冊與管理 #

與其在伺服器建立後個別插入金鑰,不如在部署範本前先決定金鑰的操作方式。

佈建

從範本建立伺服器 #

將 AI-SRV 與 GPU 工作節點統一使用相同的基礎作業系統,可避免後續指令流程出現差異。

網路

私有網路 #

事先決定 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
  • 將模型實際儲存位置集中於一處
⇄
⇄

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 + NFSBestnet Cloudcontrol-0110.10.0.10GPUStack UI / API、NFS、模型儲存
GPU Worker #1GPU-VPSgpu-worker-0110.10.0.21推論執行、共用 /models 使用
GPU Worker #2GPU-VPSgpu-worker-0210.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-SRV22/tcp僅限於管理來源 IPSSH
AI-SRV80/tcp管理網路或私有側GPUStack Web UI / API
AI-SRV2049/tcp僅限私有子網路NFS v4
AI-SRV111/tcp,111/udp僅在需要時限於私有子網路使用 rpcbind 的設定
GPU Worker22/tcp僅限於管理來源 IPSSH

假設使用 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 建立工作節點加入權杖。在公開文章中,請以 <WORKER_JOIN_TOKEN> 表示,
切勿張貼實際數值。此外,將 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 <WORKER_JOIN_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 <WORKER_JOIN_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 個節點讀取共用檔案 #

若共用快取中已存在相同模型,則會在不重

Updated on 2026年6月9日

What are your feelings

  • Happy
  • Normal
  • Sad

©2020 BESTNET.LLC . All Rights Reserved.