---
title: "通过 10G 专用网络连接 Bestnet Cloud × GPU-VPS，<br>实施 GPUStack 集群的步骤"
description: "操作指南 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…"
url: "https://bestnetllc.co.jp/zh-hans/docs/%e9%80%9a%e8%bf%87-10g-%e4%b8%93%e7%94%a8%e7%bd%91%e7%bb%9c%e8%bf%9e%e6%8e%a5-bestnet-cloud-x-gpu-vps%ef%bc%8c%e5%ae%9e%e6%96%bd-gpustack-%e9%9b%86%e7%be%a4%e7%9a%84%e6%ad%a5%e9%aa%a4/"
updated: "2026-10-14"
category: Tech Blog / GPU与LLM基础设施
---

# 通过 10G 专用网络连接 Bestnet Cloud × GPU-VPS，<br>实施 GPUStack 集群的步骤

操作指南
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 的内容将在[另一篇文章](https://bestnetllc.co.jp/zh-hans/docs/gpustack-%e4%bb%8e-v0-7-1-%e8%bf%81%e7%a7%bb%e8%87%b3-v2-1-1-%e7%9a%84%e7%bb%8f%e5%8e%86/)中介绍，
这里为了便于理解，整理的是 0.6.x 系列的搭建模式。知识映射

## 将 Bestnet Cloud 的知识按实际搭建顺序重新梳理

在 Bestnet Cloud 知识库中，客户门户的操作任务被细致地拆解开来。
因此，在搭建 GPU 集群时，事先确定”在什么时机使用哪部分知识”可以减少返工。
本文按照以下顺序整理了门户端的准备工作。

1
**门户防护**
首先确定 MFA 和允许 IP 的应对方式2
**SSH 密钥注册**
在部署操作系统之前设置好管理用密钥3
**创建模板**
在 Ubuntu 24 上准备好 AI-SRV 和 GPU-VPS4
**专用网络**
将所有节点接入 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
- 将 `/srv/gpustack_models` 通过 NFS 导出
- 在本地绑定挂载到 `/models`
- 将模型实体存储集中到一处

⇄10G 专用网络
NFS / UI / 工作节点加入 / 内部通信⇄

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 工作节点 #1 | GPU-VPS | gpu-worker-01 | 10.10.0.21 | 推理执行、共享 `/models` 使用 |
| GPU 工作节点 #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 类型、显存以及未来的模型规模来选择 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 工作节点 | `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，以便登录管理 UI。
记录下初始管理员密码后，请将其移至安全的保险库中保管，切勿张贴在文章中。

```
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

### 首先将 `/models` 通过 NFS 挂载

每个工作节点都在同一路径 `/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 个以上的副本数部署一个模型，确认只有第一个节点会进行下载，
而第二个及之后的节点则复用同一份共享文件。

1

### 从 Catalog 部署

将副本数设置为 2 个以上，以创造多个工作节点被使用的条件。

2

### 第一个工作节点进行获取

如果尚未保存到 `/models`，被分配到的第一个工作节点会获取该模型。

3

### 第二个节点读取共享文件

如果共享缓存中已存在相同的模型，则无需额外下载即可加载。

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 集群就会更易于管理

将 GPUStack Server 与 NFS 整合到 AI-SRV 上，GPU-VPS 组则作为工作节点通过专用网络挂接在其下。
在此基础上，将 `/models` 作为共享缓存，就能在避免存储重复的同时，顺畅地扩展 GPU 集群。

在门户一侧，按照 SSH 密钥、模板部署、专用网络、防火墙、快照的顺序做好准备，
在操作系统一侧统一 NFS 与 GPUStack 的路径。仅需做到这些，就能得到相当便于实际运维的配置。

10G 专用网络
BESTNET-CLOUD × GPU-VPS
NFS 共享缓存
模型只需获取 1 次