monster/modelbeast
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
27ce69782d
modelbeast/docs/CUDA-WORKER.md
MODELBEAST 27ce69782d docs: CUDA worker setup guide (T490s + 2080Ti eGPU on tailnet) 
Ready-to-follow checklist for standing up a headless Linux + eGPU CUDA node to
offload the CUDA-only 3D/mocap jobs the Mac can't run (splat->mesh, GVHMR mocap).
Bare-metal Linux required (no VM GPU passthrough on Mac hosts). Planned remote-CUDA
operators: sugar_mesh, gvhmr_mocap.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 10:58:32 +10:00

3.2 KiB
Raw Blame History

CUDA Worker Setup — T490s + 2080 Ti eGPU on the tailnet

Goal: a headless Linux box with the RTX 2080 Ti (11GB) eGPU, live on Tailscale, that MODELBEAST (on the M3 Ultra) offloads the CUDA-only jobs the Mac can't run — gaussian-splat → mesh extraction (SuGaR/2DGS), research-grade video mocap (GVHMR/WHAM/TRAM), NeRF/tiny-cuda-nn, nvdiffrast/PyTorch3D.

Why a ThinkPad and not the Intel iMac: no T2 chip = no Secure-Boot/Thunderbolt fight; laptop idles ~6–10W (+ ~20W eGPU) vs ~55–75W for the iMac; battery = built-in UPS. The 2080 Ti is EOL-ish (Turing: no bf16/fp8, 11GB) — it's a compatibility box, not a performance one. It will not beat the M3 Ultra at anything the Mac already does; it only unlocks the CUDA-locked tail.

Do this at the shop (once)

  1. Ubuntu 24.04 LTS, bare metal (dual-boot Win11 or wipe — bare-metal, NOT a VM; macOS/Windows hypervisors can't pass a physical GPU through, so a Linux VM can't do CUDA on the eGPU).

  2. Thunderbolt authorize the eGPU (plug in the Razer Core first):

    sudo apt install bolt
boltctl list                      # find the enclosure UUID
boltctl enroll --policy auto <UUID>

  3. NVIDIA driver + CUDA:

    sudo ubuntu-drivers autoinstall   # or the latest official driver branch
sudo apt install nvidia-cuda-toolkit
sudo reboot
nvidia-smi                        # must list the 2080 Ti over Thunderbolt

    If it doesn't appear: confirm the eGPU was connected at boot, re-check boltctl, ensure the thunderbolt module loads before nvidia_drm.

  4. Tailscale:

    curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --ssh          # --ssh lets the M3 Ultra SSH in over the tailnet
tailscale ip -4                   # note this IP → put it in MODELBEAST settings

  5. Headless / low-power: run lid-closed → sudo sed -i 's/#HandleLidSwitch=suspend/HandleLidSwitch=ignore/' /etc/systemd/logind.conf then sudo systemctl restart systemd-logind. Enable Wake-on-LAN in BIOS + ethtool if you want it to sleep and wake on demand.

MODELBEAST integration (I'll build this when the box exists)

The operator framework already shells out to tools; a remote-CUDA operator wraps that pattern: rsync the input to cuda_host:~/work/, ssh cuda_host to run the CUDA tool in its venv, rsync results back, register as assets. Planned operators:

  • sugar_mesh — splat .ply → textured mesh (closes the Brush→mesh gap; the Mac can't extract meshes from splats).
  • gvhmr_mocap — video → world-grounded SMPL → FBX (research-grade, replaces the cloud/manual path).

Add a cuda_host setting (the tailnet IP + user) to the vault so these operators know where to reach it. Fits in 11GB: SuGaR/2DGS/gsplat (~5-6GB), GVHMR/WHAM (light). Does NOT fit: FLUX, 20B+ models — those stay on the Mac.

Reality check

Only worth it because the card's already owned. If you were buying, a used RTX 3090 (24GB, bf16) would be strictly better and unlock FLUX/video too. Turing's runway is shrinking (newer 3D wheels drop 20-series), so treat this as "use the free card for the CUDA-only leftovers," not a long-term foundation.