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.

Storage hierarchyMixpeek addresses a logical object ID. Underneath, durable objects live behind the S3 API, a shared POSIX tier appears at V2, and node-local NVMe is disposable scratch.

                         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 workloads

How is the system laid out end to end?

End-to-end systemClients reach the rack over a secure overlay. Inside, a management plane and a 100 GbE data fabric connect compute pods to the S3/ZFS storage pod, with a shared hot tier added later.

                         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.

Network planesFour separate planes: secure access for people, a service plane for APIs, an isolated management network for BMC and controllers, and the high-speed data fabric.

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 parallelism

What does the rack physically hold?

Physical rackA 27-32U cabinet: console and switching at the top, then the compute pod, a slot for a second, the 24-bay storage pod, room for the hot tier, and power at the base.

┌─────────────────────────────────────────┐
│ 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.

Component-level specifications · How each layer scales