Two decisions define Zarx. We serve only open-weight models, and we serve them on servers NPAW owns and operates. Neither is the path of least resistance. Both are the reason the rest of the story holds together.
Renting capacity moves the jurisdiction
The fast way to launch an inference service in Europe is to rent GPU instances from a cloud provider with a datacenter in Frankfurt or Madrid and put a model server on them. It is fast, and it changes less than it appears to.
The building is in Europe. The operator of the machines, the network and the control plane is whoever owns the cloud, and for the largest providers that is a company under US law with the legal exposure that comes with it. The contract will say the right things about data location. It cannot change who can be compelled, by whom.
NPAW has run its own data infrastructure since 2008, first for video analytics, in its own racks and on its own network. When we started running language models for our products, we bought the hardware, as we always had. The result is that the sovereignty claim on Zarx is not a paragraph in a contract. It is a set of servers, in Spain, operated by a Spanish company, on an IPv4 block registered to NPAW in the RIPE database. You can look it up.
What owning the iron costs
It costs money up front, and it costs a team. Datacenter-class accelerators are expensive, they need power and cooling that ordinary racks do not provide, and they need people who know how to keep an inference stack healthy at two in the morning.
It also means committing to hardware generations. Today Zarx runs on AMD Instinct MI300X accelerators, with 192 GB of HBM3 memory per GPU, serving models with SGLang and vLLM on ROCm. NVIDIA GB300 systems are arriving, and the Rubin generation is planned. Choosing hardware is choosing what you can serve well for the next few years, and there is no vendor to blame when the choice is wrong.
We accept these costs because they are the costs of being the operator, and being the operator is the point.
A closed model is a provider in the path
The second decision follows from the first. If the model can only be reached through its provider’s API, then the provider is in your data path, and no amount of owning servers changes that. Every prompt goes to them.
Open-weight serving breaks that dependency. The weights are published and the license is public, so the capability can run on infrastructure we own and operate. Zarx keeps the implementation behind each public level out of the product promise. You choose Z Ultra, Z Pro or Z Fast by the work you need to do, while the API and the data path stay stable.
Stable levels, honest operation
The public catalog is deliberately simple. Each level has a clear job, a documented reasoning policy and an announced change process. A level reaches the service only after it has run on our iron and the NPAW team can stand behind the way it behaves in production.
Open weights and sovereignty are the same argument
People sometimes treat “European” and “open” as two separate virtues. For inference they are one. A closed model served from a European datacenter still routes every prompt to its provider. An open-weight model served from a rented US cloud still puts a US operator between you and the machine. Only the combination, open weights on iron a European operator owns, removes the foreign provider from the path entirely.
That combination is Zarx. It is more work than the alternatives. It is also the only version of the promise we would be comfortable making to a bank.
If you want to run inference this way, request access and tell us which models you need.