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
Buy the final storage chassis now, not a stand-in
In progressPhase 1: V1 rack
A self-contained multimodal AI appliance
PlannedPhase 2: Horizontal scale
More nodes, one logical pool
PlannedPhase 3: Frontier and off-grid
Nothing built in V1 is invalidated
Planned
Phase 0: Now
In progressBuy the final storage chassis now, not a stand-in
- Storage-01 itself: the same 24-bay hot-swap rack-mount server, with ECC, BMC/IPMI, an HBA and redundant power, that lives in the eventual rack. Not a desktop enclosure that gets replaced.
- It sits on a shelf beside the Mac Studio, reached over ordinary 1/10 GbE, until the cabinet is bought. Then it slides in as-is.
- Populated with 4 × 24 TB enterprise SATA for 96 TB raw, expanding toward 8 and then 12 drives in the same chassis.
- ZFS and the S3-compatible object service stand up immediately, so the canonical s3:// namespace is real from day one rather than created during a later migration.
- An independent backup from day one, because a single copy is a single copy whatever it is sitting in.
Outcome: Useful capacity immediately, on the exact hardware that becomes permanent. Nothing bought at this phase is ever replaced, only added to.
Phase 1: V1 rack
PlannedA 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
PlannedMore 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
PlannedNothing 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?
Text version of this diagram
PHASE 0: NOW
Mac Studio
│ 1/10GbE
▼
Storage-01 (final chassis, pre-rack)
S3 / ZFS: live from day one
├── 24TB
├── 24TB
├── 24TB
└── 24TB
= 96TB raw
PHASE 1: V1
Storage-01 (same unit, no migration)
slides into rack as-is
│ + drives toward 12×20-24TB
▼
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.
Text version of this diagram
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.
Text version of this diagram
PNW SOLAR FIELD
~25-30kW V1
│
▼
HYBRID INVERTER
│
┌─────────────┴─────────────┐
▼ ▼
48V LiFePO4 bank generator backup
│ │
└─────────────┬─────────────┘
▼
MIXPEEK APPLIANCE
│
Starlink
│
Tailscale
│
Mac / users / amuxThe purchase sequence
- Purchase 0. The 24-bay storage server itself, four 24 TB enterprise SATA disks and an independent backup. Roughly $5.4K-$10K before backup, useful the day it arrives, and the same unit that later slides into the rack.
- 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.
Not sure what you would actually need?
Tell us the corpus, the workloads and the constraints, and we will size it against the build sheet: drive count, GPU class, fabric, power, and which phase to start at. You own the hardware either way, and the plan is published in full whether you build it yourself or have us do it.
It is fully S3-compatible, with no code change. The object endpoint speaks the S3 API, so anything already talking to S3 points at a new endpoint URL and keeps working. Same SDKs, same bucket and key layout, same tooling.