B3IQ’s visible product is a physical GPU machine. The less visible product is the software stack that turns that box into private, managed AI infrastructure without asking the owner to become a datacenter operator.
This is the technical companion to why we think AI companies should own their compute. It stays at architectural altitude, but it makes the boundaries concrete: what runs on the machine, what the control plane does, how traffic is isolated, and how a node changes roles.
The stack at a glance
Every B3IQ deployment has three layers:
- The host agent on the machine establishes identity, inventories hardware, installs and runs model-serving software, measures the node, and maintains its outbound control connection.
- The control plane enrolls machines, dispatches work, watches health, and collects the signed benchmarks, heartbeats, and receipts produced at the source.
- The gateway and dashboard expose the fleet as one OpenAI-compatible surface while preserving the account boundary around every request and every machine.
The point is not that any one layer is exotic. The point is that the same stack arrives on the box from day one, and the thing serving a model is also the thing that can prove what that 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 can organize those attestations, but it does not invent them.
That distinction matters for an owned-compute network. A dashboard claim about a server should resolve to something the server itself measured, not a row that an operator could edit after the fact. Signed machine data makes health and performance auditable and creates the foundation for verifiable settlement when a machine takes outside work.
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. Existing applications can change a base URL and key instead of adopting a proprietary inference client.
Compatibility does not mean pooling every request. The gateway scopes API keys to an account, and the router limits eligible targets to machines on that account. The owner’s prompt does not get silently balanced across a stranger’s machine, and outside prompts do not land on the owner’s private serving environment.
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.
From one node to a fleet
The control plane turns individual machines into an operable fleet. It handles enrollment, provisions the serving environment, watches health, dispatches work, and feeds signed node data into the dashboard.
For training and batch workloads, model teams can deploy work to a single node or a cluster, with support for common orchestration approaches 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. Those roles are explicit operating modes, not two workloads casually sharing the same environment.
In Bare metal mode, the machine is the owner’s private environment. In Earn mode, it can accept eligible outside work through the network. The separation is there so private serving and marketplace work remain operationally distinct.
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’ Oregon hardware operation: a team already skilled at sourcing, assembling, burning in, cooling, and stress-testing high-end machines.
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 the core B3IQ idea: more independently owned AI capacity, with machine claims that can be verified down to signed receipts.