Self-Hosted vs Managed LLM Gateway (LiteLLM, One API)

Whether to self-host an LLM gateway or use a managed one comes down to a single question: does your team want to own the work that sits around the gateway? Self-hosting an open-source project such as LiteLLM, One API, or New API costs nothing in licenses and gives you full control over where it runs. But you still open an account, sign terms, and fund a balance with every model vendor, and your team owns high availability, quotas, audit, billing reconciliation, and keeping up with new models and price changes. A managed gateway bundles that work into a service, at the cost of letting the provider decide how it is deployed. Teams with strict data-residency rules or existing vendor contracts are often better off self-hosting. Teams that want several departments on several model families quickly, without adding ops headcount, usually save time with a managed gateway.

What self-hosting an open-source gateway actually involves

LiteLLM is both a Python SDK and a self-hosted gateway server (LiteLLM Proxy). One API and New API are open-source gateways you deploy yourself; they expose many model APIs behind an OpenAI-compatible format and include key and quota management. They solve the unified-interface problem. The rest stays with you:

Vendor accounts and balances. An open-source gateway does not supply models; it translates and routes requests. To use Claude, GPT, Gemini, DeepSeek, and Qwen, you register with each vendor, pass verification or sign a contract, add a payment method, and watch each balance separately.
Deployment and high availability. The gateway, its database, and its cache all need deploying and backing up. Multiple instances, health checks, upgrades, rollbacks, monitoring, and alerting are yours to build. When the gateway goes down, every AI call in the company goes down with it.
Mapping keys, quotas, and audit to your org chart. Open-source projects typically ship virtual keys and quotas. Departments, who may change a quota, and how detailed the audit trail is are things you configure, or build.
Billing reconciliation. Each vendor invoices separately, in its own currency and with its own billing rules. At month end, someone matches gateway logs against every invoice and allocates the cost to departments.
New models and price changes. When a vendor launches a model, renames a model ID, or changes a price, the gateway's model list and price table need updating, or internal cost reports drift.
Protocol compatibility. Streaming, tool calls, and the differences between Anthropic Messages and the OpenAI format need re-testing with every gateway upgrade.

What a managed gateway covers (HopBase as the example)

One account, one balance: Claude, GPT, Gemini, DeepSeek, Qwen, GLM, Kimi, Doubao, Hunyuan, Grok, plus image and video models such as Seedance, Kling, and Hailuo. Usage is billed in USD at each vendor's list price × the group discount, so there is no vendor-by-vendor signup.
Two protocols: OpenAI-compatible at https://api.hop-base.com/v1; Anthropic Messages at https://api.hop-base.com (no /v1).
Capacity and failover: each request is served by one of the key's groups, backed by pooled redundant capacity with automatic failover.
Team governance: the enterprise owner and enterprise admins manage members, departments, and keys. Quotas apply at three levels (key, member, department), and monthly quotas reset on a billing day you choose (1st–28th). When quota runs out, requests are rejected before processing with HTTP 402.
Key controls: each key holds 1–10 groups and can carry a quota, an expiry date, an IP list, and a concurrency limit. Keys can be disabled or revoked at any time; the server stores only a one-way hash.
Audit and reconciliation: org, member, quota, and key changes are all logged. The Usage page exports CSV filtered by date, key, member, or department, and every row can be recomputed as list cost × discount ÷ exchange rate = amount charged. Failed requests are not billed.
Data: prompts and outputs are used only to complete the request, are not retained as business data, and are not used for training. TLS end to end.

To be clear about the limits: HopBase does not offer on-premises deployment. If that is a hard requirement, self-hosting should come first.

Comparison: self-hosted vs managed LLM gateway

Dimension	Self-hosted (LiteLLM / One API / New API)	Managed (HopBase)
Vendor accounts and contracts	One per vendor; you sign and fund each	One account covers many model families
Where it runs / data residency	Your data center, chosen cloud region, or private network	HopBase's service; no on-premises option
High availability	You build instances, backups, monitoring, upgrades	Pooled redundant capacity and automatic failover included
Keys, quotas, audit	Basic features; org structure is yours to configure or build	Three-level quotas, departments, audit log out of the box
Billing reconciliation	Several invoices and currencies, merged by hand	One USD bill; CSV recomputable row by row
New models and pricing	You update model lists and price tables	Model catalog and list prices maintained for you
Customization	Change the code, add plugins, wire into internal systems	Limited to what the console and API offer
Main costs	Vendor fees + servers + ops time	Pay as you go; enterprise volume quoted by sales

How to choose

Choose self-hosted if:

Compliance requires requests to stay in a specific region or inside your network, without passing through a third-party service.
You already have enterprise contracts or committed capacity with model vendors and want to keep using them directly.
You need on-premises deployment or deep integration with internal systems.
Someone owns operations and you accept debugging gateway incidents yourself.

Choose managed if:

You need several model families and do not want to sign up, top up, and reconcile vendor by vendor.
You want quotas and spend by department, member, and key without building it.
There is no dedicated ops team, and you want availability and failover handled by the service.
Finance needs a usage export it can recompute line by line.

Or combine them

If you already run LiteLLM Proxy, keep it as your internal entry point and add HopBase as an OpenAI-compatible provider: prefix the model ID with openai/ and set api_base to https://api.hop-base.com/v1. See the LiteLLM setup guide.

A four-step decision process

List requirements: which models, which workloads, and whether data may leave your network.
Estimate effort: for self-hosting, count person-days for deployment, on-call, monthly reconciliation, and model updates.
Pilot small: pick one department and run each option for a week. Compare uptime, reconciliation time, and incident handling.
Test against a checklist: protocol completeness, behavior under concurrency, billing transparency. Our team gateway checklist lists the tests, and the engineering behind high concurrency and failover is in this write-up.

To try the managed route, sign up for HopBase; once you create an enterprise account you can add members and departments. For bank transfer, invoices, or enterprise settlement, contact sales@hop-base.com.

FAQ

How much does it cost to self-host LiteLLM?

The software is free. The costs are vendor usage fees, servers and databases, and ops time. Ops time is what most teams underestimate: deployment, upgrades, monitoring, reconciliation, and model updates all need steady attention.

Do I still need my own model credits after deploying One API or New API?

Yes. These gateways unify the interface and dispatch requests; the model capacity still comes from the accounts you open with each vendor. Each vendor's balance, rate limits, and invoices are managed separately.

What should we check first when choosing an enterprise AI gateway?

Data requirements. If requests must stay inside your network or a specific region, start with self-hosting. If not, compare ops effort, the number of model families you need, and how hard reconciliation will be.