NeuroBrix proposes .nbx, a universal container format for AI model inference

NeuroBrix has put forward .nbx, a container format meant to package any AI model — its computation graph and its weights — into a single file, and to let one inference engine run the result regardless of the model's family. In a post on dev.to, NeuroBrix's Hocine Benkelaya says the approach already covers 49 models spanning nine families, from language models and speech recognisers to text-to-speech voices, image and video generators and upscalers, with no model-specific code anywhere in the stack.

What the format holds

According to the post, a .nbx file carries two things: a graph describing what to compute, and the weights used in the computation. Because that pairing fully describes a model, the engine reading the container never needs to know which architecture it is executing — only that there is a graph to plan and weights to load.

How the engine runs it

NeuroBrix splits execution into three parts. A planner called Prism reads the container together with a hardware profile and settles placement: whether the model fits on one GPU, should be spread across several, streamed, or have its largest operations broken into tiles. Execution then goes through one of two engines — a Triton-based engine built on the project's own nbxtensor library, which does not use PyTorch, or an optional PyTorch engine. The work itself is done by what the project calls certified kernels, whose settings are proven once per GPU class rather than autotuned on every run.

The command-line experience follows from the container. The model's family is read from the file, so the tool asks for the inputs that family needs — text for a language model, audio for speech recognition, an image for an upscaler — and everything after that follows the same path.

The claimed benefits

Benkelaya argues the format changes the economics of model support. Adding a model means packaging a container, not writing a loader or pipeline class, so the engine, planner and kernels stay untouched. When a bug is fixed in the engine, every model benefits at once because they all travel the same code path.

Validation is the other cited benefit. Each release reportedly runs all 49 models through both engines from a single entry point — the 0.6.0 release is said to have passed 196 of 196 test cells on 4x V100 hardware, with outputs compared byte for byte against judged reference outputs and repeated runs producing identical results. Portability, the post adds, comes from the engine rather than from each model: containers are said to run on Linux, Windows and macOS across NVIDIA, AMD, Intel and Apple GPUs.

Ecosystem and roadmap

The project is available under an Apache 2.0 licence on GitHub and installable via pip, with a Model Hub distributing the 49 containers. Surrounding pieces include nbxtensor, the PyTorch-free tensor library; triton-ext, a Triton build for Apple GPUs; and Studio, a desktop application for the three major desktop platforms that is still in development. Missing models can be requested through GitHub issues, where they become containers rather than forks of the engine.

Planned work includes kernel fusion and graph-level simplification for speed; support for AMD and Intel GPUs, many-core CPUs, ARM64 and multi-GPU setups across NVLink, PCIe and networks; community-certified hardware profiles; training inside nbxtensor; local agents; a local server with a JSON interface for applications; nbxtensor 2.0 rewritten in Rust; and establishing .nbx as an open model standard.

Why it matters

Support for a new model in most inference stacks today arrives as code — a pipeline class, a loader, special cases for a particular attention scheme or cache layout — and that cost multiplies across every model and modality a stack wants to cover. A universal container reframes the problem: if graph and weights are enough, integration becomes packaging work, engine fixes land for every model simultaneously, and cross-platform support is inherited rather than rebuilt per model. A runtime indifferent to model identity would also weaken the framework lock-in that comes with stack-specific model code. The caveat is provenance: all coverage and validation figures come from NeuroBrix's own announcement, and whether .nbx becomes a genuine open standard will depend on adoption outside the project's own hub.