Sovereign AI
LiteLLM vs Xinity
Short answer: LiteLLM is a gateway. It sits in front of language models and decides where each request goes. Xinity is the platform behind that gateway: it runs the models on your own servers and keeps them running. The two do different jobs, and they can run together.
We hear this question in some first calls with an IT team, so here is the full answer.
What is LiteLLM?
LiteLLM is an open-source, self-hosted AI gateway. It gives applications one OpenAI-compatible endpoint for more than 100 model providers. On top, it adds virtual keys, budgets, spend tracking, load balancing, guardrails and logging, and gives agents access to MCP tools. Its documentation recommends the gateway when more than one application or person sends requests to language models.
LiteLLM does not run models itself: it forwards each request to the provider of the model. Its supported providers include OpenAI, Anthropic, Azure OpenAI and AWS Bedrock, as well as self-hosted model servers. When a request goes to a cloud provider, the prompt leaves the building, and providers based in the US fall under the CLOUD Act.
What is Xinity?
Xinity is a sovereign AI platform that runs open-weight models on your own servers. It covers the whole stack: models checked against your hardware before they are deployed, inference serving across your GPU nodes, an OpenAI-compatible API, a management dashboard with single sign-on and role-based access, an audit trail, and the day-to-day operation of all of it. It runs on NVIDIA, AMD or Intel GPUs, or on CPUs alone. Your teams get a cloud-like experience, and no prompt leaves your premises.
How do LiteLLM and Xinity differ?
LiteLLM | Xinity | |
|---|---|---|
What it is | A gateway in front of models | The platform the models run on |
Where models run | Wherever the gateway sends them: a cloud provider or your own servers | On your own servers |
What you get | One API for 100+ providers, keys, budgets, guardrails, logging | Models running on your hardware, validated and governed, with audit and operation |
Built for | Teams that send requests to many models and providers | Banks, insurers, hospitals and public bodies that need on-prem AI without building a GPU team |
Problem it solves | One API and central control across providers | Running AI in production while keeping data inside the organisation |
Where do they overlap?
Xinity has a gateway of its own: an OpenAI-compatible API with API keys, usage tracking, rate limiting and load balancing. That layer does part of the same job as LiteLLM. So an IT team may reasonably ask: why not run LiteLLM in front of a few GPU servers and build the rest ourselves?
Can we just run LiteLLM in front of our own GPU servers?
You can. The gateway is one layer. Beneath it sits the rest of the work:
Hardware: fitting each model onto the GPUs you actually have, by memory, driver and vendor, across several servers.
Model lifecycle: downloading weights, starting the inference engine on each server, and restarting it when it fails.
Performance: tuning inference so answers arrive in seconds when fifty people use it at nine on a Monday.
Model choice: finding which open-weight model holds up on your documents and in your languages, and proving it.
Updates: downloading and installing each new model version on every server before any traffic can reach it.
If you point LiteLLM only at your own servers, the layer beneath the gateway is yours to build and maintain. With Xinity, it comes as one platform.
Can LiteLLM and Xinity work together?
Yes. LiteLLM can route to any OpenAI-compatible endpoint, and Xinity is one. If your developers already use LiteLLM, Xinity becomes one of the providers it routes to. Your applications keep the same gateway. The requests simply land on models running in your own building instead of in someone else's cloud.
Here is what that looks like in practice. One use case runs the same Qwen model in two Xinity deployments, one on CPU servers and one on GPU servers. LiteLLM sits in front and shares the requests between both. Xinity installs and runs each deployment on your hardware and records every request.

If different teams have different use cases, they do not need a gateway in front at all. Each use case gets its own model endpoint in Xinity, served on the servers that fit it.
Which one do you need?
You want one API and central control across several model providers: a gateway like LiteLLM covers it.
You need AI on your own premises, with validated models, audit and failover, and no GPU team of your own: that is what Xinity is for.
You already run LiteLLM and want to bring the models in-house: keep the gateway, put Xinity behind it.
Open-weight models are free. Knowing which one to trust in production is not. Book a call to see Xinity running on your hardware.
Information about LiteLLM is taken from its public documentation as of October 2026: LiteLLM AI Gateway and OpenAI-compatible endpoints. LiteLLM is a product of BerriAI and is named here for comparison only.
This article was written with the support of AI and reviewed and edited by the Xinity team. |