Scaling and roadmap
Every phase leaves the previous one intact
The Mixpeek Appliance grows in four phases. The first purchase is disks, not a rack, and those disks end up in the rack. Each later phase adds a dimension without invalidating what is already running.
How do you scale a private AI data center without rebuying it?
By starting small and extending, so every phase reuses the last rather than replacing it. Each kind of pressure then has exactly one answer: more throughput adds a compute pod, a larger model adds an accelerator, more capacity adds disks or a storage pod, shared multi-node access adds the parallel filesystem tier, and more bandwidth moves the fabric up a generation. Extending the rack is also how NVMe and inference end up co-located with the object store, which is the point at which search over your own storage runs end to end without leaving the cabinet.
Because none of those touch the s3:// namespace, adding a future accelerator node does not orphan the first one, and filling a rack means adding a rack rather than migrating anything.
Phase 0: Now
Storage first, so no disk is ever stranded
- Enterprise SATA drives chosen specifically because they move from a Mac-attached enclosure into server storage later.
- An 8-bay Thunderbolt JBOD, starting at 4 × 24 TB for 96 TB raw and expanding toward 192 TB.
- An independent backup from day one, so the eventual migration is never a single-copy event.
- Data organized against stable s3:// object namespaces before the object store exists.
Outcome: Useful capacity immediately, with disks that survive the move into the rack.
Phase 1: V1 rack
A self-contained multimodal AI appliance
- Compute-01: RTX PRO 6000 Blackwell 96 GB, Threadripper PRO 9975WX, 512 GB ECC, mirrored boot, model and scratch NVMe.
- Storage-01: 24-bay hot-swap server starting around 12 × 20-24 TB enterprise SATA.
- Durable data exposed through an S3-compatible object API; local NVMe is cache and scratch, never the source of truth.
- The full local Mixpeek stack, Ray, vector services and video extraction, plus vLLM, SGLang and TensorRT-LLM for serving.
- 100 GbE-ready internal fabric, an isolated management network, BMC/IPMI and a local break-glass console.
Outcome: Private large-scale ingestion, multimodal inference and model training in one 27-32U cabinet.
Phase 2: Horizontal scale
More nodes, one logical pool
- Compute-02/03/N join as Kubernetes and Ray workers under the GPU Operator and KubeRay.
- Lustre arrives only when multiple workers genuinely need the same active working set. S3 stays the durable truth.
- The fabric moves 100 GbE → 200/400 GbE RDMA, with a distinct compute fabric where model parallelism warrants it.
- Storage-02/N or dense shelves take capacity from hundreds of TB toward petabytes.
Outcome: Compute, storage and bandwidth scale independently of each other.
Phase 3: Frontier and off-grid
Nothing built in V1 is invalidated
- Future NVIDIA-qualified RTX PRO, MGX, HGX or DGX nodes join the existing cluster.
- Dense storage shelves scale the object pool without touching compute.
- An optional off-grid power module: solar, a 48 V LiFePO4 bank, hybrid inverter and generator, with energy-aware scheduling.
- Satellite WAN plus the secure overlay keeps the site reachable without depending on local infrastructure.
Outcome: A private AI cluster where newer accelerator nodes join without changing the object namespace.
How do the same disks move between phases?
PHASE 0 - NOW
Mac Studio
│ Thunderbolt
▼
ThunderBay 8
├── 24TB
├── 24TB
├── 24TB
└── 24TB
= 96TB raw
PHASE 1 - V1
ThunderBay corpus
│ copy + verify
│ 10/100GbE
▼
Storage-01
S3 / ZFS
12×20-24TB
│
├──────── Compute-01
│ 96GB GPU
│
└──────── Mixpeek
PHASE 2 - SCALE
Kubernetes / Ray
│
100→400GbE fabric
┌─────────────┼─────────────┐
▼ ▼ ▼
Compute-01 Compute-02 Storage-01
│ │ │
└─────── Lustre V2 ─────────┘
shared hot data
PHASE 3 - PB / FRONTIER
Compute-01 Compute-02 MGX/HGX/DGX future
\ | /
└── high-speed fabric ──┐
▼
Storage cluster
S3 + Lustre
│
dense JBOD shelves
hundreds TB → PBsWhat do I add, and when?
One pressure, one answer. The value of writing it down is that it stops a capacity problem being solved by buying compute, which is the usual mistake.
Need more inference/training throughput? → Add Compute Pod Need a larger model? → Add GPU / accelerator node Need more durable capacity? → Add disks / Storage Pod / JBOD Need shared multi-node data throughput? → Add/expand Lustre Need more fabric bandwidth? → 100G → 200/400G / IB Need remote autonomy? → Add off-grid power module Rack full? → Add another rack
Running it off-grid
An optional power module rather than part of the core build. Sizing is site and workload dependent, so the figures on the specifications page are planning ranges rather than a design.
PNW SOLAR FIELD
~25-30kW V1
│
▼
HYBRID INVERTER
│
┌─────────────┴─────────────┐
▼ ▼
48V LiFePO4 bank generator backup
│ │
└─────────────┬─────────────┘
▼
MIXPEEK APPLIANCE
│
Starlink
│
Tailscale
│
Mac / users / amuxThe purchase sequence
- Purchase 0. An 8-bay enclosure, four 24 TB enterprise SATA disks and an independent backup. Roughly $2.3K-$3.3K before backup, and useful the day it arrives.
- Purchase 1. Build Compute-01 and Storage-01. Copy the existing corpus into the canonical object pool, verify it, then repurpose the original disks.
- Purchase 2. Add Compute-02 and the shared hot tier when multi-node data access becomes a measured bottleneck, not before.
- Purchase 3. Dense storage shelves and newer accelerator nodes, without changing the object namespace or discarding V1.