A public build brief · Omarchy ML monster

Put the model on the desk.

A dream local-AI workstation running Omarchy Linux: enough VRAM for serious open-weight models, enough CPU and memory for research, and enough receipts to know when the expensive rectangle is actually helping.

See the build Help fund the machine ↗

The dream configuration

Capacity first. Repairability second. Hype nowhere.

The machine is designed around local model capacity, multi-GPU experimentation, fine-tuning, and concurrent agents. Omarchy supplies the human-facing layer; the hardware supplies the actual power.

Workstation core

One local AI lab.

The flagship version uses a WRX90 platform with enough PCIe lanes, memory channels, cooling, and power headroom to make multi-GPU work possible without pretending that model parallelism is free.

Threadripper PRO 9995WX96 cores · 192 threads512 GB ECC RDIMM4 × 96 GB GPUs2 TB system NVMe8 TB active NVMe

384 GBaggregate physical VRAM

1,200 WGPU board power, Max-Q configuration

128usable PCIe 5.0 lanes, CPU platform maximum

70B–120Bsingle-GPU model territory, quantization-dependent

The software stack

Arch underneath. Receipts on top.

Omarchy is not a magic performance potion. It is a clean, opinionated interface to a machine whose critical boundaries remain visible.

Omarchy + CUDA

Encrypted Btrfs and Limine for the workstation base. NVIDIA open kernel modules and pinned CUDA/PyTorch environments for fewer update-induced surprises.

llama.cpp

GGUF inference, quantization experiments, GPU offload, CPU fallback, and the simplest path from a model file to a local OpenAI-compatible endpoint.

vLLM + training

Continuous batching and tensor parallelism for serving; Transformers, PEFT, and TRL for fine-tuning. Containers keep experiments reproducible.

01 · BOOTOwn the machine

Encrypted local storage. No private model files sent away by default.

02 · LOADFit the model

Measure weights, context, KV cache, quantization, and actual memory use.

03 · RUNServe the work

Use local models for research, coding, agents, vision, and bounded experiments.

04 · LOGPublish the miss

Record throughput, latency, energy, quality, and the cases where the monster was slower than the cloud.

What it could run

Model capacity is not model quality.

These are engineering targets, not promises. Quantization, context length, architecture, interconnect topology, and framework support decide whether a model merely fits or is pleasant to use.

Comfortable

7B–32B models with large context windows, multiple resident services, vision tools, embeddings, and local agent loops.

Serious

70B-class models on one 96 GB GPU. 100B–120B-class models are plausible with suitable low-bit formats and a disciplined context budget.

Experimental

200B–400B-class models through multi-GPU sharding. Capacity may work before latency does. The market has enough benchmark theatre already.

The first build should be smaller.Start with one 96 GB GPU and validate Omarchy, CUDA, llama.cpp, vLLM, thermals, and update recovery. Add the other cards only when a measured workload—not the desire to possess a small data center—requires them.

The funding boundary

Support the experiment, not a fantasy invoice.

Contributions support the research and construction of the local AI workstation described here. The target configuration is a design, not a purchased asset. Hardware, power, taxes, availability, and prices can change. We will publish what was actually bought, what it cost, and what it can actually do.

Donate through Stripe ↗Return to BIPU ↗

Stripe checkout is an existing BIPU support link. It is not a hardware pre-order, equity offering, token sale, or promise of financial return. Stripe collects payment details; we do not put credentials or payment logic in this static page.

The next receipt

Build the single-GPU version first.

Then measure whether the second GPU earns its slot. The thesis means nothing without the artifact. Ship the pipeline. Measure the outcome. Publish the miss.

Discuss the build Support the build ↗