BESTNET-CLOUD
GPU-VPS
GPUStack
10G 专用网络
NFS 共享缓存
技术博客 / 基础设施搭建指南
通过 10G 专用网络连接 Bestnet Cloud × GPU-VPS,
实施 GPUStack 集群的步骤 #
将 Bestnet Cloud 作为控制平面、GPU-VPS 作为推理工作节点进行分离,
并通过共享 NFS 缓存将模型文件集中管理。
从客户门户的准备工作开始,
直到在 Ubuntu 上完成实施与运行验证,我们将其整理为一篇操作指南文章。
专用链路
模型下载
GPU 工作节点
共享模型存储
本文的适用范围 #
本文介绍的初始搭建模式为在 Bestnet Cloud 上启动 AI-SRV,将 GPUStack Server + NFS 整合于其上,
并在 GPU-VPS 一侧部署多台 GPU 工作节点。
由于本文的主题是角色分离与共享缓存设计,公网 IP 地址和内部命名规则均已替换为示例值。
本设计的核心是将不需要 GPU 的控制平面以及模型存储位置放在通用云一侧,
而将 GPU-VPS 纯粹作为推理执行节点。
这样一来,即使增加工作节点,也可以避免重复的存储投入,
并且只需在 Bestnet Cloud 一侧的共享区域集中管理模型实体。
仅通过 GUI 进行模型注册
将 GPUStack Server + NFS 整合到 AI-SRV
所有工作节点共享 NFS 挂载点 /models
这里为了便于理解,整理的是 0.6.x 系列的搭建模式。
将 Bestnet Cloud 的知识按实际搭建顺序重新梳理 #
在 Bestnet Cloud 知识库中,客户门户的操作任务被细致地拆解开来。
因此,在搭建 GPU 集群时,事先确定”在什么时机使用哪部分知识”可以减少返工。
本文按照以下顺序整理了门户端的准备工作。
门户防护
首先确定 MFA 和允许 IP 的应对方式
SSH 密钥注册
在部署操作系统之前设置好管理用密钥
创建模板
在 Ubuntu 24 上准备好 AI-SRV 和 GPU-VPS
专用网络
将所有节点接入 10G 网段
防火墙 / 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 - 将模型实体存储集中到一处
NFS / UI / 工作节点加入 / 内部通信
GPU-VPS
gpu-worker-01 / 02 #
共享 /models、只负责推理的工作节点组
- 启动 GPUStack Worker
- 统一使用
--cache-dir /models - 各工作节点不持有大容量的模型存储
- 横向扩展时以相同模式添加节点
→
第一个工作节点仅获取一次模型
→
其他工作节点从同一个
/models 读取
需要事先确定的事项 #
| 角色 | 所在位置 | 主机名(示例) | 专用 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 使用 |
以上为公开示例值。在实际生产环境中,请根据自身的命名规则和专用子网进行调整。
首先做好客户门户的各项准备 #
保护客户门户本身 #
在创建服务器之前,先确定管理防护策略。特别是对于团队运维而言,
提前明确 MFA 和允许 IP 的处理方式,可以避免日后出现”谁可以从哪里访问管理界面”这类混乱。
在创建服务器之前先注册 SSH 密钥 #
与其在创建 AI-SRV 和 GPU 工作节点之后再逐台插入密钥,不如事先在客户门户的 SSH 密钥管理中准备好密钥,
这样在模板部署完成后即可立即进行管理访问。
- 整理团队运维用的公钥
- 不要将共享密钥与紧急情况下使用的个人密钥混用
- 不要在公开文章中张贴密钥指纹
在 Bestnet Cloud 上从模板创建 AI-SRV #
AI-SRV 使用 Ubuntu 24 系列模板,同时承载 GPUStack Server 和 NFS。
由于该节点还兼作模型存储,请将存储区域与操作系统磁盘分开设计,并预留充足空间。
- 角色为 GPUStack Server + NFS
- 接入专用网络
- 只有在确实需要暴露 UI 时才考虑公网一侧
- 为 AI-SRV 分配比工作节点更大的模型存储容量
在 GPU-VPS 上按需创建工作节点 #
由于工作节点用于推理,请根据 GPU 类型、显存以及未来的模型规模来选择 GPU-VPS 套餐。
另一方面,由于模型本身保存在 NFS 一侧,工作节点的存储容量可以轻松缩减到仅供操作系统和执行所需的最小限度。
- 统一使用 Ubuntu 24 系列
- 创建时确保可用 GPU 驱动 / CUDA
- 接入专用网络
- 如不需要公网 IP,可考虑纯私有配置
将所有节点置于 10G 专用网络上 #
NFS 与 GPUStack 的内部通信通过连接 Bestnet Cloud 与 GPU-VPS 的 10G 专用链路进行传输。
这样一来,模型获取和工作节点加入就可以留在私有一侧。
- 让 AI-SRV 与所有工作节点处于同一个专用网段
- 分配固定 IP,以便后续 NFS 导出和 systemd 设置更加稳定
- 如果工作节点需要出站通信,可选择 NAT 路由器方式或临时公网出口
如果想将工作节点推向纯私有,仅在操作系统更新和外部获取时使用 Bestnet Cloud 的虚拟路由器 / NAT 方式会更便于管理。
确定初始防火墙规则 #
“只对 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。请务必将公网开放范围限制在专用子网内。
创建初始快照 #
在操作系统初始创建、密钥注入、专用网络接入以及防火墙设置全部完成之后,
请为 AI-SRV 和 GPU 工作节点创建快照,以便日后中间件安装失败时更容易恢复。
建立操作系统基线 #
无论是服务器还是工作节点,都要先统一时间同步和 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 上搭建 GPUStack Server + NFS #
安装 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/创建 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签发工作节点加入令牌 #
从 GPUStack GUI 创建工作节点加入令牌。在公开文章中,请以 <WORKER_JOIN_TOKEN> 的形式表示,
不要张贴实际数值。此外,将 GUI 登录来源限制在专用网络一侧会更加安全。
在 GPU-VPS 一侧挂载共享缓存并让工作节点加入 #
首先将 /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 确认预期的共享位置已经可见。
安装 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>固定 --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-datasudo systemctl daemon-reload
sudo systemctl enable --now gpustack
# If "Using cache dir: /models" appears, OK
journalctl -u gpustack -f在 GPUStack GUI 中确认工作节点已处于 Ready 状态 #
在 GUI 的 Workers 界面上,确认所有 GPU-VPS 节点均为 Ready 状态。
如果一直处于 Not Ready,请按 GPU 驱动 / CUDA、NFS 挂载、工作节点日志的顺序进行排查。
模型部署与运行验证 #
完成的判定标准并不仅仅是工作节点变为 Ready。
请实际从 GUI 以 2 个以上的副本数部署一个模型,确认只有第一个节点会进行下载,
而第二个及之后的节点则复用同一份共享文件。
- 通过 10G 专用网络连接 Bestnet Cloud × GPU-VPS,实施 GPUStack 集群的步骤
- 本文的适用范围
- 将 Bestnet Cloud 的知识按实际搭建顺序重新梳理
- 客户门户安全设置
- SSH 密钥的注册与管理
- 从模板创建服务器
- 专用网络
- 防火墙配置变更
- 快照管理
- 云资源升级
- 虚拟路由器 NAT
- 架构思路
- control-01
- gpu-worker-01 / 02
- 将存储集中到 AI-SRV 一侧
- 让 GPU-VPS 保持精简
- 将通信集中到私有一侧
- 需要事先确定的事项
- 设计检查要点
- 存储估算方法
- 首先做好客户门户的各项准备
- 保护客户门户本身
- 在创建服务器之前先注册 SSH 密钥
- 在 Bestnet Cloud 上从模板创建 AI-SRV
- 在 GPU-VPS 上按需创建工作节点
- 将所有节点置于 10G 专用网络上
- 确定初始防火墙规则
- 创建初始快照
- 建立操作系统基线
- AI-SRV 一侧需要统一的项目
- GPU 工作节点一侧需要统一的项目
- 在 AI-SRV 上搭建 GPUStack Server + NFS
- 安装 GPUStack Server
- 创建 NFS 共享目录
- 签发工作节点加入令牌
- 在 GPU-VPS 一侧挂载共享缓存并让工作节点加入
- 首先将 /models 通过 NFS 挂载
- 安装 GPUStack Worker
- 固定 --cache-dir /models 参数,用于工作节点服务
- 在 GPUStack GUI 中确认工作节点已处于 Ready 状态
- 模型部署与运行验证
- 从 Catalog 部署
- 第一个工作节点进行获取
- 第二个节点读取共享文件