Architecture
Durable objects, shared hot data, local scratch
How the Mixpeek Appliance is put together: three storage tiers with one rule between them, four network planes that stay separate, and a compute layer built so it can be replaced without disturbing the data.
What is the architecture of a private multimodal AI data center?
Three storage tiers and one rule. An S3-compatible object store holds durable truth. A parallel POSIX filesystem holds the shared hot working set, and only appears once more than one node needs the same active data. Node-local NVMe holds scratch and is disposable. Data flows downward from objects to scratch, and nothing above the object tier is ever the source of truth.
Around that sit four separate network planes: a secure overlay for people, a service plane for APIs, an isolated management network for BMC and controllers, and a high-speed data fabric that keeps storage traffic from starving the GPUs.
How do the storage tiers relate?
Mixpeek addresses a logical object ID. Where the bytes physically sit is a detail underneath that, which is what makes the disks, the filesystem and the servers replaceable without touching a single pipeline.
Text version of this diagram
MIXPEEK / MVS
│
logical object ID
│
┌──────────────────────┼──────────────────────┐
│ │ │
▼ ▼ ▼
DURABLE OBJECTS SHARED HOT DATA LOCAL SCRATCH
S3-compatible API Lustre V2 NVMe
│ │ │
Storage Pod(s) NVMe / fast disks Compute Pod
HDD / EC / ZFS shared POSIX disposable
└──────────────────────┼──────────────────────┘
▼
GPU workloadsHow is the system laid out end to end?
Text version of this diagram
CLIENTS / CONTROL
┌──────────────────────┬──────────────────────┐
│ │ │
Mac Studio / amux Engineer laptop Customer client
│ │ │
└──────────────────────┴──────────────────────┘
│
TAILSCALE / VPN
SECURE ACCESS PLANE
│
▼
┌──────────────────────────────────────────────────────────────────────┐
│ MIXPEEK APPLIANCE │
│ │
│ MANAGEMENT: BMC/IPMI · K8s controllers · UPS · sensors │
│ SERVICES: Mixpeek API · inference · SSH/admin │
│ │
│ 100 GbE DATA FABRIC │
│ future 200/400G RDMA │
│ │ │
│ ┌──────────────────┼──────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌────────────────────┐ │
│ │ COMPUTE-01 │ │ COMPUTE-02 │ │ STORAGE-01 │ │
│ │ 96GB GPU │ │ [future] │ │ S3 / ZFS │ │
│ │ 512GB ECC │ │ │ │ 12→24 HDDs │ │
│ │ local NVMe │ │ │ │ canonical corpus │ │
│ └──────┬───────┘ └──────┬───────┘ └─────────┬──────────┘ │
│ │ │ │ │
│ └──────────────────┼─────────────────────┘ │
│ ▼ │
│ LUSTRE [V2] │
│ shared hot POSIX │
└──────────────────────────────────────────────────────────────────────┘Why are the networks separate?
Because they fail differently and they are trusted differently. Losing the data fabric should not cost you the ability to reach a BMC and fix it, and a client on the access plane should never be adjacent to controller traffic.
Text version of this diagram
SECURE ACCESS
Tailscale / approved VPN
Mac · amux · engineers · customer clients
│
▼
SERVICE / API PLANE
Mixpeek · inference · SSH/admin
MANAGEMENT
1/10GbE isolated
BMC/IPMI · K8s controllers · UPS · sensors
DATA / STORAGE
100GbE initially → 200/400GbE RDMA
S3 · Lustre · media · checkpoints
COMPUTE [future]
200/400GbE or InfiniBand-class
distributed training · model parallelismWhat does the rack physically hold?
Text version of this diagram
┌─────────────────────────────────────────┐ │ 27-32U ENCLOSED VERTICAL RACK │ │ │ │ 1U status display / local console │ │ 1U management/client network │ │ 1U 100G data switch │ │ 1U K8s control shelf │ │ │ │ 4U COMPUTE-01 │ │ RTX PRO 6000 96GB │ │ 512GB ECC │ │ model + scratch NVMe │ │ GPU #2 / 400G-ready │ │ │ │ 4U COMPUTE-02 [future] │ │ │ │ 4U STORAGE-01 │ │ 24 hot-swap bays │ │ S3 / ZFS │ │ │ │ 2-4U LUSTRE HOT TIER [V2] │ │ │ │ UPS / PDU / expansion │ └─────────────────────────────────────────┘
What runs on it?
The whole stack is local. Nothing in the list below calls out to a hosted service to do its job.
- Mixpeek local stack
- Ray / KubeRay
- Kubernetes
- NVIDIA GPU Operator
- vLLM
- SGLang
- TensorRT-LLM
- NeMo
- Megatron
- PyTorch
- Hugging Face
- Qdrant
- S3-compatible object service
- ZFS
- Lustre (V2)
- Prometheus / Grafana-class observability
The rule that keeps it portable
The control environment is a client, not an infrastructure dependency. A workstation or an operator's laptop can be off, replaced or absent and the rack keeps serving, because nothing in the data path routes through it. That is also what makes the air-gapped configuration a substitution rather than a redesign: swap the secure overlay for an approved on-premise access solution and everything else is unchanged.
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.