AIO Server Build Guide: Dual B70 GPUs for a Local AI Assistant

From Benchmarks to Intelligence: The Evolution of AIO Servers

It's been a while since the last build, and in 2026, AI has become an unavoidable tide. So at this point in time, what should an All-in-One (AIO) server built for a studio actually be capable of?

According to Bilibili creator SuOuTuo's analysis, the answer is no longer just about throwing hardware at the problem. A powerful CPU and GPU only gets you so far — cloud gaming, transcoding. Even the eight-bay, 10GbE NAS setup has become old hat. The form factor that truly represents the future is one that can see, listen, speak, and get things done on its own.

This machine can remind you at 6:30 PM that "you've worked hard today, time to clock out." If it notices you've been scrolling your phone too long during work hours, it'll tell you to "put down the phone and get back to work." When someone enters the server room in the middle of the night, it simultaneously pushes an alert and sends a screenshot to your phone via Feishu. Ask it "what's going on right now?" from across town, and it'll check the camera and tell you. The core of this entire system is fully localized compute — zero API costs.

Hardware: Two Hearts Beating in a Dual-B70 Build

The foundation of this machine is the Mingxuan AI Micro Station workstation barebone, featuring a split-chamber design: the lower chamber houses the processor, memory, and ATX power supply, while the upper chamber provides two multi-slot PCIe GPU slots. The two GPUs face opposite directions for their airflow, keeping thermals independent. If you skip the dual-GPU config, one of the GPU bays can be converted via a bracket into four 3.5-inch drive bays — the motherboard even has a Mini-SAS header, making it quite friendly for pure storage use cases.

Core Specs

• CPU: Intel Core Ultra 9 275HX, 24 cores, with 4 memory slots
• RAM: A cobbled-together setup totaling 96GB (the author openly admits this is a "reckless" move given current memory prices)
• Storage: Two 4TB M.2 drives as the base, with a PCIe 4.0 x4 slot available for expansion
• GPUs: Two Mingxuan ARC Pro B70

The B70 uses the BMG G31 die, with 32 Xe-core clusters, 32GB of VRAM, and 608GB/s memory bandwidth. The real value here is that 32GB of VRAM — it's the physical foundation that allows multiple clients to run concurrently without fighting over resources.

OS & Deployment: OpenCode Handles Everything

Ubuntu 24.04 was chosen as the base OS for a straightforward reason: its kernel version is 7.0, and the Battlemage architecture B70 requires kernel 6.17 or higher for proper recognition. After installation, both GPUs are immediately recognized, appearing as two nodes under /dev/dri (Render D128 and D129).

Make sure to enable SSH during OS setup, because virtually all subsequent deployment is done remotely via OpenCode — no manual command-line work required. A practical tip here: run OpenCode locally and connect to the server via SSH. That way, even if the server reboots, your session stays intact. Running OpenCode directly on the server means a reboot will drop your connection.

Dual-GPU Task Division

• GPU0 (First B70): Dedicated to running Qwen 3.6 35B A3B as the AI brain. Deployment is as simple as feeding the Intel-specific vLLM (LMScaler) project URL to OpenCode — it auto-configures and even downloads the model.
• GPU1 (Second B70): Runs ComfyUI with the XPU backend, which has solid Intel GPU support, handling video, image, and audio generation.

Why not use tensor parallelism? A single card's 32GB VRAM already supports up to 256K context — the native ceiling for a 35B model — so splitting across cards isn't necessary. With one card per instance, one handles conversation and the other handles creation, with no VRAM contention.

Benchmark Results

Using INT4 dynamic quantization for weights and FP8 for KVCache, weights occupy 21.9GB of VRAM and KV takes 8.5GB, with utilization pushed to 0.95. Under this configuration, single-session max context is 256K, and total KVCache capacity is 850K tokens. Real-world testing shows peak single-user speed around 80 tokens/sec, with concurrent throughput exceeding 500 tokens/sec — more than enough to handle multiple users and applications simultaneously.

MiLocal + OpenCode: Giving the Server Eyes and a Brain

The real magic comes from using MiLocal and OpenCode to tie the entire machine together.

MiLocal is Xiaomi's open-source smart home monitoring and management solution. Its design philosophy: use a lightweight Omni model for "seeing" (camera feed recognition), and a cloud model for "thinking" (reasoning, planning, and tool calling). When a scene is detected, it triggers preset alerts or Mijia device actions.

Two Key Modifications for Full Local Operation

The official setup had two pain points for a studio environment, which the author addressed with custom modifications:

1. Local model routing: The official setup sends both models to the cloud, generating a continuously growing API bill during 24/7 operation — and you probably don't want everything that happens in your studio logged by a third-party service. The fix was simple: point both MiLocal's and OpenCode's model endpoints to the local vLLM API. Since local inference uses the standard API format, the change is straightforward. API costs drop to zero, and no alerts leak to the outside.
2. Camera compatibility: The official setup only works with Xiaomi cameras. Switching to the universal RTSP protocol allows any camera in the server room to connect. However, RTSP streams can't currently be integrated into MiLocal's WebUI, so a separate monitoring page was built to track events.

The Closed-Loop Workflow

The division of labor is clean: MiLocal handles "seeing" — the feed goes through upsampling and gating, skipping frames with no change to save compute, and only forwarding significant changes to the 35B model for structured understanding. OpenCode handles "thinking and doing" — acting as an agent that calls the local 35B, interprets tasks, breaks them into steps, and executes via MCP tools.

Example: camera spots an unknown person entering the server room → MiLocal rule triggers → OpenCode pushes an alert to Feishu + plays a TTS voice announcement. Loop closed. The large KVCache and strong concurrency enabled by 32GB VRAM is exactly what prevents two clients calling the 35B model simultaneously from queuing up and blocking each other.

Real-World Capabilities: See, Remember, Manage

Perception and Queries

Ask on your phone "what's going on at the studio right now?" and it summarizes recent events. Ask "who's in the frame?" and it uses MiLocal's facial recognition to name them — registered whitelist members get identified by name; unregistered individuals are flagged as strangers. All events are saved as snapshots (video clips + inference logs), searchable by query like "what happened in the server room at 10 AM?" or "how many times did I goof off on my phone yesterday?" — not a single event missed, and no pre-training needed to understand what's happening on screen.

Natural Language Rules

A single sentence is all it takes to set a rule: "Alert me if someone's on their phone during work hours," or "Alert me if someone's moving the desktop." No pre-training, no model swapping, no flowchart required. A few extreme test scenarios:

• Smoke detection: Simulated smoke in front of the lens — the 35B immediately concluded "smoke detected, possible fire" and triggered the highest-level alert — no specialized flame detection model, just a large model reading the scene.
• Intruder detection: An unregistered person enters the server room late at night. Facial recognition flags them as non-whitelist. Voice warning + Feishu push with a snapshot as evidence. Entire process takes only a few dozen seconds.
• Smart automation: A whitelisted member walks in during work hours — the system can auto-enable the AC, play a voice greeting, and even comment on what they're wearing.

Self-Management and NAS Functionality

The server can also manage itself: send "check server status" via Feishu and get back a full operational report. Ask "which port is vLLM running on?" and it answers directly (it remembered from deployment). If ComfyUI acts up, tell it to restart the container — it confirms, restarts, and reports back, all in one flow. It also doubles as a NAS, configurable with plain-language instructions.

One caveat: when asking OpenCode to create scheduled inspection tasks, this type of AI tooling burns through paid token quotas at an alarming rate — three scheduled services configured with a ~¥200/month Coding Plan were exhausted within days. For simple polling tasks, using the free local 35B model is far more cost-effective.

Creative Capabilities: Zero-Day Support for MiniMax H3

Beyond looking after itself, the machine's primary purpose is creative work. For video generation, the B70 had previously been tested with LTX 2.3 — but this time it's different. MiniMax H3 just went open-source, and B70 support landed on day zero, with the official workflow working out of the box.

Video Generation Benchmarks

Default workflow, native resolution, no upscaling:

• 480P, 5 seconds: ~200 seconds
• 720P: ~60 seconds
• 1080P, 5 seconds: ~2,300 seconds

With an acceleration LoRA, you can shave off another 2–3x. The key differentiator is that H3 can handle shot cuts and transitions directly from prompts — camera angles, movement, and scene transitions all follow what you write. The resulting footage is a full tier above LTX 2.3 in terms of practical usability. The studio has already switched the entire pipeline to H3: "Before, we'd generate cautiously one at a time; now we kick off two or four at once without a second thought."

With 32GB of VRAM, you can run the FP16 and FP8 original model weights directly — no need for GGUF quantization. The original is the quality ceiling. Voice generation and text-to-image are also handled in one place.

Honest Assessment: Promising But Still Raw

This setup is still very much in its early stages:

• Facial recognition: With few whitelist samples, it can misidentify people — similar body types can trigger false positives and erroneous rule activations.
• Event detection: When scene changes are too dramatic or a scenario isn't covered by existing rules, events can occasionally be missed.

Even so, this machine demonstrates the genuine potential of fully localized compute. Three capabilities together make it shine: compatibility (H3 day-zero support, runs mainstream models), large VRAM (32GB enabling high KVCache and long context windows), and concurrency (multi-user vLLM access without queuing). It may be a rough prototype, but every mature system starts as one.