How B3IQ works: from bare metal to sovereign AI.

The stack at a glance

The figure leaves out what each layer keeps. The host agent keeps the machine's identity and its measurements. The control plane keeps the signed benchmarks, heartbeats, and receipts those measurements produce. The gateway keeps the account boundary around every request. The host agent is on the box from day one; the control plane and gateway are hosted, so the software serving a model is also the software that can prove what the machine did.

Identity starts on the machine

The host agent gives every machine a cryptographically verifiable identity when it comes online. Hardware inventory, benchmarks, uptime, and served work are measured on the box and signed at the source. The control plane organizes those attestations; the numbers come from the machine.

Machine records carry their source identity. A signature establishes which machine produced a record; it does not establish independent validation, future availability or a financial return. Hourly marketplace earnings and their payment records are a separate ledger.

Outbound-only connectivity

A node does not need a public inbound port to join the fleet. The host agent establishes an outbound connection to the control plane, and management traffic travels back through that channel.

The same principle applies when an owner or operator needs shell access. Managed SSH uses the agent’s existing outbound tunnel, so direct access does not mean adding an internet-facing port or changing a firewall rule.

This architecture shrinks the public attack surface and makes deployment repeatable across a rack in Oregon, a partner facility, or hardware an owner already controls.

One API surface, hard account boundaries

On the serving side, an owner’s machines appear behind an OpenAI-compatible API. The OpenAI SDK quickstart covers the supported chat, streaming, and model-list methods. List models with your own gateway key before making a request.

The gateway scopes API keys to an account and limits eligible targets to that account’s machines. An organization key uses the organization’s machines; a key can be narrowed further to named machines. If none can serve a request, the request fails. There is no public inference pool or third-party provider fallback.

That routing boundary is different from operational workload isolation. Confirm any dedicated workload or regulated-data requirements with B3IQ before provisioning. The security page explains default request handling, 90-day operational metadata, saved Playground conversations and encrypted private-job retention.

Behind that interface, the runtime layer handles model distribution, engine selection, and performance tuning for the silicon underneath. A single machine can serve locally, and a managed fleet can present several machines through the same API surface.

For workload planning, the Qwen3 Coder guide covers a coding model and the BGE-M3 guide covers retrieval embeddings. These are research references; each machine’s installed runtime and current serving state determine what it can run.

From one node to a fleet

The control plane is what makes single machines a fleet you can run: it provisions each machine's serving environment and feeds its signed data into the dashboard.

For training and batch work, owners have full access to their machines and run their own orchestration, such as Kubernetes. For inference, the same fleet is optimized around long-running model servers and predictable routing.

Machines racked by B3IQ start from a preconfigured image and enroll with a one-time code. That reduces a new deployment to a repeatable appliance-like sequence: rack it, power it, establish identity, and let it find the control plane.

Bare metal and Earn mode

An owned machine can serve the owner directly, or it can opt into outside GPU work when the owner is not using it. The two roles are separate operating modes, set per machine.

In Bare metal mode, the machine serves the owner’s workloads without a per-request B3IQ inference charge. In Earn mode, B3IQ offers the machine’s time to external GPU marketplaces by the hour. The machine withdraws from B3IQ inference and SSH access and boots a separate encrypted volume for the renter. Private serving and Earn are mutually exclusive. Serving an inference request produces no per-request earnings.

Earning is optional and controlled per machine. It can help offset carrying costs, but it does not remove hardware risk: GPUs depreciate, demand changes, and ownership makes the most sense for teams that expect AI to remain in their cost structure.

Why this stack exists

B3 built the software for its own AI needs, then combined it with Andromeda Insights’ facility in Oregon, where machines are built by hand and stress-tested for 48 hours.

Gaming systems and inference nodes share the hard physical work: procurement, thermals, power, assembly, and validation. Pairing that capability with the host agent, control plane, and private gateway made it possible to operate owned machines end to end instead of reselling access to someone else’s cloud.

The result is a customer-owned neocloud: machines you own, operated by B3IQ, with software to use and inspect them.