QDivZero is now in public beta
Published 15 September 2026 by Marta Barea Sepúlveda7 min read
AI has moved quickly from an experiment to a core part of how teams build products. The choice of models has grown, but the practical work around them has often become harder. Running one reliably can mean coordinating providers, hardware, routing, retrieval, security rules, and several different bills.
We wanted to make that part easier without hiding it. Three months ago, we invited a small group of teams into a private beta to find out whether we were solving a real problem. Their feedback has shaped what QDivZero is today.
The question that started the private beta
The first teams did not ask us for another chat window. They asked questions that come up when an AI product has to work reliably. Which model is right for this job? Where should it run? What happens when that model is no longer the best option? How do we control the cost? What happens to our data?
Those questions are connected, but most infrastructure products treat them separately. The model may come from one place, the GPU from another, the routing logic from the application, and the safety checks from a service added at the end. Every extra connection creates work for the team building the product.
The private beta began with a simple idea. The team using AI should be able to make these decisions from one place and keep its application independent from the infrastructure underneath.
What we learned by working with real teams
The private beta changed the product in useful ways. It showed us that model choice needs to remain flexible, because the right model depends on the job and keeps changing. It showed us that infrastructure cannot be an afterthought, because availability, hardware, and location all affect the result. It also showed us that pricing is easier to understand when it reflects the resource a team is actually using.
Most importantly, the teams reminded us that control is not a feature to add at the end. Data handling, isolation, routing, and request rules belong in the same conversation as performance and cost.
Those lessons became the foundation for the public beta.
QDivZero today
QDivZero is a platform for deploying AI models on managed compute. Each part has a clear job, but the parts are designed to work together.
Compute runs open-weight models and exposes them through an OpenAI-compatible endpoint. The platform can look for compatible infrastructure rather than making the application depend on one fixed provider.
Smart Balancers route requests between models and deployment paths. This lets a team use one application integration while applying different choices for different workloads.
Flexible Vector Database handles the search and retrieval work that gives a model useful context. It also supports semantic search and recommendations.
Firewall applies rules before a request reaches inference. Teams can use it to define which traffic should be allowed, flagged, or blocked.
The result is one operating layer for the model, the compute, the request path, the context, and the controls around them.
Choosing a model should not lock the rest of the stack
AI moves too quickly for a model decision to become a permanent infrastructure decision. New open-weight models arrive, workloads change, and the most suitable place to run a model can change with them.
With QDivZero, the application connects through an OpenAI-compatible API. The team can choose a model, while QDivZero handles the search for compatible compute and the deployment underneath. That gives the product team room to improve the model without making the whole application move every time.
It also gives technical teams a clearer boundary. They can work on the product and its behaviour while QDivZero takes care of the infrastructure needed to run it.
Paying for the resource you use
The private beta also made us look closely at inference pricing. Token-based APIs are convenient for many use cases, especially when usage is small or occasional. For a busy application, however, the bill follows every request while the infrastructure behind it remains difficult to see and plan.
QDivZero is built around deployed compute capacity. You pay for the capacity running your workload rather than for each token processed. This gives teams with steady workloads another way to forecast, compare, and manage inference costs.
| Token-based pricing | QDivZero capacity pricing |
|---|---|
| Cost follows the number of tokens processed | Cost follows the capacity deployed |
| Every request changes the usage total | The running infrastructure is the main cost reference |
| Hardware is hidden behind the service | Hardware is part of the deployment decision |
| Scaling means following a usage meter | Scaling means selecting the capacity the workload needs |
This is not a claim that one pricing model fits every team. It is a different option for teams that run inference continuously and want to connect their costs to the infrastructure doing the work.
Keeping control of the workload
An AI workload can include customer information, internal documents, private prompts, and the output of business processes. For that reason, infrastructure decisions affect trust as much as they affect performance.
QDivZero gives teams a place to make those decisions deliberately. They can choose the deployment approach, define request rules, add routing policies, and use dedicated or private infrastructure when the workload calls for stronger isolation. The goal is straightforward. Your data should stay under your control while the platform runs your models.
One API while the technology underneath evolves
The public beta is built around a stable integration. Existing applications and development tools can connect through an OpenAI-compatible API while teams try different models and deployment options behind it.
That means a change in model does not need to become a change in the application. A change in provider does not need to become a new integration. The platform can evolve underneath the product, and the product can keep moving forward.
Why public beta, and why now
The private beta gave us a working product, useful criticism, and a much better understanding of what teams need from an AI infrastructure layer. It also showed us where we still have work to do.
Opening the public beta is the next step in that process. More teams will bring different models, traffic patterns, regions, and requirements. Their experience will help us decide what to improve next and keep us honest about where QDivZero creates value.
Public beta does not mean that every decision has been made. It means the platform is ready to be used in more real products and shaped by more real teams.
Frequently asked questions
Who is QDivZero for?
QDivZero is for product and engineering teams that need to deploy models, operate them over time, and keep a clear view of the infrastructure around them. It is a good fit for teams with sustained workloads or several infrastructure needs that currently live in separate systems.
What does paying for compute mean?
The deployment is priced around the compute capacity used to run it instead of charging separately for every input and output token. This gives teams another way to plan inference costs when their usage is steady.
Can I deploy open-weight models?
Yes. QDivZero is designed to deploy open-weight models on managed infrastructure and make them available through an OpenAI-compatible endpoint.
Do I have to use one cloud or model provider?
No. QDivZero is designed as a multi-provider infrastructure layer. The application keeps a stable API while compatible compute and deployment options can change underneath it.
The next chapter
QDivZero began with a small group of teams willing to test an idea before it had all the answers. Their questions helped turn that idea into a platform.
Now we are opening the door to more teams. If you want to choose your models with more freedom, understand the infrastructure behind your workloads, and keep control of your data, we invite you to try QDivZero.
