.nbx: one container format for every AI model

Ask how a model is "supported" by an inference stack and the honest answer is usually: someone wrote code for it. A pipeline class, a loader, a set of special cases for its attention, its cache, its preprocessing. Multiply by every model and every modality, and the stack becomes a museum of pipelines.

NeuroBrix runs 49 models in 9 families with no per-model code. The reason is the .nbx container.

What a .nbx holds

A .nbx is one file format that holds a model's graph and its weights. The graph says what to compute; the weights are what it computes with. Together they are enough for the engine to run the model, whatever family it belongs to: a language model, a speech recogniser, a text-to-speech voice, an image or video generator, an upscaler.

One engine reads them all

Because every model arrives in the same shape, the engine has one job: read the container, plan it, execute it.

Prism, the memory and placement planner, reads the container and your hardware profile and decides how the model is placed: one GPU, several GPUs, streamed, or with its largest operations tiled.
One of two engines executes it: the Triton engine on nbxtensor (no PyTorch) or the optional PyTorch engine.
Certified kernels do the work, with settings proven once per GPU class.

The family is read from the container, so the command line asks for the inputs that family needs — a prompt for a language model, an audio file for speech recognition, an image for an upscaler — and the rest is the same path:

neurobrix import openai/whisper-large-v3-turbo neurobrix run --model whisper-large-v3-turbo --audio recording.wav neurobrix upscale --model Real-ESRGAN-RealESRGAN_x4plus --input photo.png --output photo_x4.png

Why a standard helps

Adding a model does not add code. It adds a container. The engine, the planner and the kernels do not change.

Fixes are shared. A bug fixed in the engine is fixed for every model at once, because every model runs through the same code.

Validation is uniform. Every NeuroBrix release runs all 49 models on both engines through the same entry point — for 0.6.0, 196 of 196 cells on 4x V100 — and compares outputs byte for byte with judged outputs. That is only practical because there is one path to test, not 49.

Portability is inherited. A model in a .nbx runs wherever the engine runs: Linux, Windows and macOS, on NVIDIA, AMD, Intel and Apple GPUs.

Adding a model is adding a container

Because the engine never knows which model it runs, a new model is not a code change. It is a new container that the same engine, the same planner and the same certified kernels execute, on every platform the engine supports. That is how the catalogue grows with every release, and why the 49 models of 0.6 are a starting point rather than a ceiling. Missing a model you need? Request it through the issues: it becomes a container, not a fork.

Getting containers

The models are published on the NeuroBrix hub and listed at neurobrix.org/models. neurobrix import <name> downloads and unpacks one; neurobrix run --model <name> runs it.

github.com/NeuroBrix/neurobrix — Apache 2.0

The way we build it

This post is one piece of a consistent method:

One engine, zero per-model code. The runtime knows tensors, graphs and plans; it never knows which model it is running. A fix in the engine is a fix for every model.
.nbx, one container for every model: graph and weights in one file format.
Prism decides from facts: placement chosen from a hardware profile, not from heuristics in code.
Certified, not autotuned: every kernel setting checked against a float64 oracle, timed once per GPU class, shared by pull request.
Validated through the real entry point: all 49 models on both engines at every release (196 of 196 cells for 0.6.0 on 4x V100), outputs compared byte for byte with judged outputs, runs deterministic from one repetition to the next.

The ecosystem

NeuroBrix Engine: the inference engine, pip install neurobrix.
nbxtensor: the tensor library without PyTorch, pip install nbxtensor.
Model Hub: .nbx containers for 49 models at neurobrix.org/models, more with every release.
triton-ext: our Triton build for Apple GPUs.
Studio: a desktop application for Linux, Windows and macOS, in development.

Where we are going

Faster than the frameworks (kernel fusion, graph-level simplification), every processor (AMD and Intel GPUs, many-core CPUs, ARM64, accelerators beyond GPUs, multi-GPU across NVLink, PCIe and networks), community-certified hardware, training in nbxtensor, local agents, a local server and a JSON interface for applications, Studio for everyone, nbxtensor 2.0 in Rust, and .nbx as an open model standard.