小團隊 GPU 排程：1-2 台 5090 主機的可行架構

Question

有1-2台5090顯卡主機，希望讓團隊成員能夠很方便地在該台電腦上自動排程訓練模型。目前已有DVC管控dataset，但不同應用（VLA、3DGS）每次都要拉資料到對應機器，造成排程問題和儲存空間/人工輪流使用的困擾。

Answer

核心問題拆解

問題有兩個獨立層：

儲存層：DVC 資料每次都要 pull 到 GPU 機器，佔空間且重複下載
排程層：多人/多專案搶占 GPU，目前靠人工協調

這兩層需要分別解決，然後再接合。

解法一：共享 NFS 儲存（解決資料層）

最高 CP 值的改動：在 GPU 機器旁加一台 NAS 或指定一台機器當 NFS server，讓兩台 GPU 主機都掛載同一個路徑。

NAS / NFS Server
    └── /data/
        ├── datasets/     ← DVC remote 指向這裡
        ├── checkpoints/
        └── outputs/

GPU 機器 A & B
    └── /mnt/data → (NFS mount to NAS)

DVC remote 改指向 NFS 路徑後，dvc pull 只需 NFS 網路傳輸（不需從 S3/外部拉），且兩台機器共享 cache——VLA 在機器 A 拉過的資料，機器 B 可直接使用。

硬體建議：若沒有 NAS，可用任何 Linux 主機裝 TrueNAS Scale（免費）+ SSD/HDD。10GbE 內網讓資料存取速度夠快。

解法二：Job Scheduler（解決排程層）

根據團隊規模和技術背景，有三個層次選項：

選項 A：Determined AI（推薦給小型 ML 團隊）

Determined AI 是專門為 ML 訓練設計的開源平台，核心功能：

Web UI 提交訓練任務，不需 SSH 進機器
GPU 佇列自動排程：任務排隊，前一個跑完自動啟動下一個
實驗追蹤（內建，不需另裝 MLflow）
多 GPU / 多機器支援
支援 PyTorch、TensorFlow、JAX

# 安裝（每台 GPU 主機裝 agent，一台主機裝 master）
pip install determined
det deploy local cluster-up
 
# 提交訓練任務
det experiment create config.yaml .

適合場景：團隊成員技術背景中等，希望有 Web UI，不想管 Kubernetes。

選項 B：SLURM（推薦給學術/HPC 風格）

SLURM 是 HPC 標準排程器，1-2 台機器也可以用。

# 提交任務腳本
sbatch train_vla.sh
 
# 查看排隊狀態
squeue
 
# train_vla.sh 範例
#!/bin/bash
#SBATCH --gres=gpu:1
#SBATCH --job-name=vla_training
python train.py --config vla_config.yaml

優點：業界標準，文檔豐富，可精確控制 GPU 數量分配（例如 VLA 用 2 張，3DGS 只用 1 張）。缺點：設定較複雜，沒有 ML 特有功能。

選項 C：最輕量（適合 2-3 人小團隊）

用 RunAI 開源版或直接用 enroot + pyxis（NVIDIA 的容器排程）。或更極簡：

# gpu-queue：用 Redis + RQ（Python）自建任務佇列
pip install rq redis
 
# 提交任務
python -c "from rq import Queue; from redis import Redis; q=Queue(connection=Redis()); q.enqueue('train.run', config='vla')"
 
# 在 GPU 機器上啟 worker（開機自動啟動）
rq worker --with-scheduler

解法三：整合 DVC + 排程器的標準工作流

[開發者電腦]
    dvc push → [NFS/NAS]
    git push → [Git server]
    
[提交訓練任務]
    det experiment create / sbatch
    
[GPU 機器（自動執行）]
    git pull（取得最新訓練程式碼）
    dvc pull（從 NFS 取資料，幾乎零延遲）
    python train.py
    mlflow log metrics（寫入共享 MLflow server）
    
[MLflow UI]
    比較 VLA vs 3DGS 實驗結果

關於 3DGS vs VLA 資料混用

3DGS（3D Gaussian Splatting）訓練資料通常是 scene-specific 的影像序列，體積大但不重複。VLA 訓練資料（robot demonstrations）也是大型資料集。建議：

分目錄管理：/data/datasets/3dgs/ 和 /data/datasets/vla/
DVC 分專案 repo：各專案有自己的 dvc.yaml，dvc pull 只拉該專案需要的資料
儲存配額：NFS 設 quota，避免某個專案吃光空間

Sources

Vault notes consulted:

Clippings-Our journey from Gitlab to Kubeflow — GitLab CI 到 Kubeflow 的遷移故事，說明 GPU runner 擴展是小型 ML 團隊共同痛點，Kubeflow 在 2021 年對小團隊仍過重
Clippings-machine-learning-operations-mlops-for-beginners-towards-data-science — DVC + MLflow 工具棧整合，確認 DVC remote 指向共享存儲是標準做法
Clippings-Fundamentals of MLOps — Part 1 A Gentle Introduction to MLOps — ML 系統中基礎設施成本遠超 ML 程式碼本身的框架，強調 reproducibility 和 automation 原則
Clippings-人人都是深度学习工程师-autoresearch如何改变训练方法论 — Karpathy autoresearch 架構展示了以 git commit 作為實驗記憶系統的輕量排程模式

Follow-up Questions

Determined AI 的 checkpoint 儲存是否可以直接整合到 NFS 路徑？
兩台 5090 機器是否需要 InfiniBand 或 10GbE 才能做分散式訓練（VLA 模型通常很大）？
3DGS 訓練是否需要特殊 CUDA 版本，和 VLA 環境是否衝突？若是，需要容器隔離
若未來擴展到 4-8 台 GPU 機器，SLURM 遷移成本如何？

bot_vault

Explorer