Bottom Line: LiteLLM is a gateway (+2 ms median / +13 ms p99 at 1,170 RPS on 4 small instances); vLLM, Ollama and LocalAI are engines. On one A100-40GB with Llama-3.1-8B FP16, vLLM peaks at 793 tok/s / 80 ms p99 versus default Ollama at 41 tok/s / 673 ms p99 โ a 19ร gap that appears only under concurrency. A saturated single-H100 vLLM node serving Llama-3.3-70B FP8 costs $0.17โ0.81 per 1M output tokens in GPU rent ($0.5โ1.75 after a 3โ5ร ops multiplier), at or below hosted Llama-3.3-70B APIs ($0.10โ1.04) and 12โ60ร below GPT-5 output ($10.00); the same node at 1 user costs $3.45โ16.16 per 1M. Utilization, not engine choice, dominates TCO. Reference stack: LiteLLM โ vLLM, with Prometheus, Postgres and Redis. No defensible LocalAI concurrency or CPU-only cost-per-token figure exists as of 2026-09-16.
Scope and method
Every figure below carries a source, hardware and date, compiled 2026-09-16, tagged [P] primary (vendor docs or method-disclosed benchmark), [S] secondary (aggregator, method not re-run) or [U] unverified (no primary source; caveated). Where sources conflict both values are shown. Derived cost figures are calculated from cited inputs and labelled as such.
The four tools are two categories
vLLM, Ollama and LocalAI execute model weights. LiteLLM runs no models; it proxies 100+ upstream providers behind one OpenAI-compatible schema. Engines are measured in tokens per second, a gateway in requests per second plus added latency, and a production deployment stacks them: gateway โ engine(s).
Throughput and latency benchmarks
vLLM
The one primary-source head-to-head is Red Hat Developer's run (published 2025-08-08, updated 2026-07-13): Llama-3.1-8B-Instruct FP16 on 1ร A100-PCIe-40GB, CUDA 12.4, OpenShift 4.17, vLLM 0.9.1, load generated by GuideLLM 0.2.1 sweeping 1โ256 concurrent users for 300 s per run [P].
- Peak throughput: 793 tok/s.
- P99 latency at peak: 80 ms.
A secondary 2026 single-run from Spheron on a larger model โ Llama-3.3-70B-Instruct FP8, 1ร H100 SXM5 80GB bare metal, vLLM v0.18.0, 200 prompts averaging 512 input / 256 output tokens โ gives the scaling curve [S]:
| Concurrency | Throughput | TTFT p50 / p95 | Peak VRAM |
|---|---|---|---|
| 1 | 120 tok/s | โ | โ |
| 10 | 650 tok/s | 120 ms / 195 ms | โ |
| 50 | 1,850 tok/s | โ | 76 GB |
| 100 | 2,400 tok/s | โ | 78 GB |
Cold start on that configuration was ~62 s [S]. Caveat: the Spheron figures are blog-grade, single-run, with no raw data published; they are corroborated in shape (near-linear scaling with concurrency) but not in exact value by the Red Hat primary run.
Ollama
Same Red Hat rig, same model at llama3.1:8b-instruct-fp16, Ollama 0.9.2 [P]:
- Peak throughput: 41 tok/s (derived ratio: 19.3ร below vLLM's 793 tok/s).
- P99 latency at peak: 673 ms (derived ratio: 8.4ร vLLM's 80 ms).
The gap is a configuration consequence, not only an engine one. Ollama's OLLAMA_NUM_PARALLEL defaults to 1 and queued requests are processed in FIFO order [P: Ollama FAQ]. Raising it narrows the gap, but memory scales linearly with parallel slots ร context length [P: Ollama FAQ], and no primary benchmark of tuned Ollama at high concurrency was found [U] โ the 19ร figure applies to default settings only.
At a single user the picture inverts. Secondary sources report Ollama TTFT of ~45 ms versus vLLM ~82 ms on Llama-3.1-8B [S: Markaicode], and SitePoint's 2026 comparison puts Ollama 18% faster on single requests while vLLM delivers 2.3ร the throughput at 8 concurrent [S]. At 50 concurrent, Markaicode measured Ollama plateauing at ~155 tok/s total with ~3,200 ms TTFT versus vLLM ~920 tok/s and ~145 ms TTFT [S โ hardware undisclosed; prefer the Red Hat rows where both exist].
LocalAI
No independent, method-disclosed LocalAI server throughput or concurrency benchmark was found [U]. LocalAI's default backend is llama.cpp and it can also load a vLLM backend [P: LocalAI features], so its ceiling is approximately the chosen backend's ceiling minus an unmeasured gRPC-hop overhead. The closest proxies are single-stream llama.cpp figures from Presenc AI (2026) [S]: 130โ150 tok/s for 7B Q4 on an RTX 5090, 14โ22 tok/s for 70B Q4 on the same card (offloaded, >32 GB VRAM), 35โ45 tok/s for 70B Q4 on a DGX Spark, and 95โ110 tok/s for 7B Q4 on a Mac Studio M5 Max 128GB via MLX. None of these measures LocalAI itself; state any LocalAI throughput as "โ backend performance, overhead unmeasured."
LiteLLM
LiteLLM's published benchmarks on 4 instances ร (4 vCPU, 8 GB), v1.79.1-stable [P]: added overhead 2 ms median / 8 ms p95 / 13 ms p99; 1,170 RPS sustained at 100 ms median / 150 ms p95 / 240 ms p99 end-to-end. Separately (version not stated), the Realtime API reached 1,207 RPS at 59 / 67 / 99 ms on 4 instances with 1,000 users [P]. A high-throughput profile on v1.101.0 (33 pods ร 4 workers, 528 GiB requested) reached 3,000 RPS at p50 30.6 / p95 54.0 / p99 91.6 ms [P].
An independent stress test (agentgateway, 2026-06-26, Docker with undisclosed host specs, 18 workers, Fortio 32 connections, 1 KB payloads) measured p50 7.08 ms / p90 17.99 ms / p99 32.19 ms at a 3,198 QPS peak with 11.8 GB peak RSS [S]. The memory figure is the operational takeaway: LiteLLM's Python hot path is not free at multi-thousand QPS.
A vendor-internal Rust hot-path rewrite is reported at ~0.05 ms overhead versus ~7.5 ms Python and 6,782 versus 453 req/s at 50 clients [U โ pre-GA, 2026-06-22]. Do not size capacity on these numbers.
Comparison table
Throughput and latency rows use the highest-confidence source available per tool. $/1M output token figures are derived in the TCO section below.
| Dimension | LiteLLM (gateway) | vLLM | Ollama | LocalAI |
|---|---|---|---|---|
| Role | Proxy / router, runs no models | GPU inference engine | GPU/CPU engine (llama.cpp) | Multi-backend engine (llama.cpp, vLLM, transformers, diffusers, whisper) |
| Throughput (best primary) | 1,170 RPS @ 4 small instances [P] | 793 tok/s, 8B FP16, 1ร A100-40GB [P] | 41 tok/s, same rig, default config [P] | None measured [U]; โ backend |
| Latency | +2 ms median / +13 ms p99 overhead [P] | 80 ms p99 at peak [P] | 673 ms p99 at peak [P]; ~45 ms TTFT single-user [S] | Not measured [U] |
| Derived $/1M output tokens | n/a (adds 1 vCPU + 4 Gi per pod) | $0.17โ0.81 (70B FP8, H100, 100 concurrent); $0.70 (8B, A100 @ $1.99) | $13.48 (8B, A100 @ $1.99, default config) | Not derivable [U] |
| Multi-provider routing / fallback | โ
routing_strategy, Redis-shared state [P] |
โ | โ | โ ๏ธ P2P federation across LocalAI nodes only [P] |
| OpenAI-compatible API | โ 100+ providers โ one schema | โ chat, completions, embeddings, transcription, batch [P] | โ
/v1/* subset |
โ chat, embeddings, images, STT/TTS, realtime WS, tools [P] |
| Continuous batching | n/a | โ PagedAttention | โ FIFO slots | Backend-dependent |
| Multi-GPU | n/a | โ tensor + pipeline parallel [U โ flags not on fetched page] | โ ๏ธ layer split only, not tensor parallel [P] | โ ๏ธ listed, per-backend [P] |
| Auth | โ master + virtual keys, per-key RPM/TPM budgets, teams [P] | โ ๏ธ single shared --api-key [U] |
โ none; port 11434 open by default [P] | โ ๏ธ API key; no per-key quotas found |
| Rate limiting | โ per key / team / model [P] | โ (--max-num-seqs only) |
โ | โ none found |
| Observability | โ Prometheus, OTEL/Langfuse, spend logs in Postgres [P] | โ
Prometheus /metrics [P] |
โ /metrics unconfirmed [U] |
โ unconfirmed |
| Stateful deps | Postgres โฅ12 + Redis (multi-instance) [P] | none | none | none |
| Licence gate | Some features enterprise-licensed (SSO/audit) [P] | Apache-2.0 | MIT | MIT |
Trade-offs per tool
LiteLLM
- Advantage: the only component in the set with per-key budgets, team-scoped rate limits, cross-provider fallback and spend accounting [P]. Overhead is 2 ms median at 1,170 RPS [P].
- Drawback: two stateful dependencies (Postgres โฅ12, Redis) for multi-instance use [P], 1 vCPU + 4 Gi per pod [P], 11.8 GB RSS at 3.2k QPS in an independent test [S], and SSO/audit behind an enterprise licence [P]. Throughput scales with pod count, so it is a recurring cost line.
vLLM
- Advantage: highest measured throughput in the set โ 793 tok/s at 80 ms p99 on an A100-40GB [P]; 2,400 tok/s at 100 concurrent on a 70B FP8 H100 model [S]. Native Prometheus metrics [P].
- Drawback: GPU-only; ~62 s cold start on 70B FP8 [S]; 76โ78 GB VRAM at 50โ100 concurrent leaves no headroom on an 80 GB card [S]. Single shared API key and no rate limiting [U/P] make it not suitable for direct multi-tenant exposure. Quantization list and TP/PP flags were not confirmed on the fetched docs page [U].
Ollama
- Advantage: fastest single-user TTFT in the set (~45 ms vs vLLM ~82 ms) [S], runs on CPU or GPU, MIT-licensed, zero stateful dependencies.
- Drawback: 41 tok/s and 673 ms p99 at default config [P], 19ร below vLLM on identical hardware; no server auth, port 11434 open by default [P];
/metricsunconfirmed [U]. Not suitable for shared traffic without a tunedOLLAMA_NUM_PARALLEL(memory grows linearly [P]) and an authenticating reverse proxy.
LocalAI
- Advantage: widest modality surface โ chat, embeddings, images, STT/TTS, realtime WebSocket and function calling in one binary [P]; can host a vLLM backend for GPU throughput or llama.cpp for CPU; P2P federation across nodes [P]; MIT.
- Drawback: zero method-disclosed throughput or concurrency data [U]; API-key protection exists but per-key quotas and metrics are unconfirmed. Any LocalAI capacity plan needs an in-house load test before commitment.
Reference architecture
The deployment that follows from the feature matrix places the gateway in front of one or more engines, with auth, quotas and spend accounting at the gateway and raw metrics scraped from both layers.
flowchart LR
C[Clients / apps] -->|OpenAI schema, virtual key| G[LiteLLM proxy<br/>N pods x 1 vCPU / 4 Gi]
G -->|route: local-70b| V1[vLLM node A<br/>1x H100, Llama-3.3-70B FP8]
G -->|route: local-70b| V2[vLLM node B<br/>1x H100, Llama-3.3-70B FP8]
G -->|route: small-cpu| O[Ollama or LocalAI<br/>CPU / small GPU, <=8B Q4]
G -->|fallback| API[Hosted API<br/>Together / Bedrock / OpenAI]
G --- R[(Redis<br/>router state, rate limits)]
G --- P[(Postgres >= 12<br/>keys, spend logs)]
V1 -->|/metrics| M[Prometheus]
V2 -->|/metrics| M
G -->|/metrics + OTEL| M
M --> D[Grafana / alerting]
G -->|callbacks| L[Langfuse / OTEL traces]
Three consequences: auth lives only at the gateway, because neither vLLM (single shared key [U]) nor Ollama (no auth [P]) should be reachable outside the private network; the engine tier scales by node with a ~62 s cold start [S] while the gateway tier scales by pod; and the hosted-API fallback is what lets the self-hosted tier run near saturation, since overflow leaves the box instead of queueing.
TCO
Inputs
GPU on-demand rates (verified 2026-08-20) [S]: H100 from $1.49/hr (Vast.ai floor) through $1.99 PCIe / $2.69 SXM community and $2.99 SXM5 Secure Cloud (RunPod), $3.99 (Lambda), $4.25 (CoreWeave), up to $6.98 (hyperscalers). A100 from $1.99/hr.
API baselines, $ per 1M tokens (Sept 2026): Llama-3.3-70B cheapest listed $0.10 in / $0.32 out [S]; DeepInfra $0.23โ0.40 blended [S]; Together serverless $0.54 (early 2026) or $1.04 flat (Sept 2026) โ sources conflict, quote the range [S]; AWS Bedrock $0.72 flat [S]; Groq $0.59 in / $0.79 out, moved to enterprise-only on 2026-08-26 [S]. GPT-5 $1.25 in / $10.00 out; GPT-5-mini $0.25 / $2.00; GPT-5-nano $0.05 / $0.40 [P: OpenAI pricing, 2026-08-21].
Derived self-hosted $/1M output tokens
Formula: $/1M = hourly_rate รท (tok_per_s ร 3600 รท 1e6). GPU rent only; these are calculations from the cited inputs, not published figures.
| Stack | tok/s | tok per hour | @ $1.49 | @ $2.99 | @ $3.99 | @ $6.98 |
|---|---|---|---|---|---|---|
| vLLM, 70B FP8, 1ร H100, 100 concurrent | 2,400 | 8.64 M | $0.17 | $0.35 | $0.46 | $0.81 |
| same, 50 concurrent | 1,850 | 6.66 M | $0.22 | $0.45 | $0.60 | $1.05 |
| same, 10 concurrent | 650 | 2.34 M | $0.64 | $1.28 | $1.71 | $2.98 |
| same, 1 concurrent | 120 | 0.43 M | $3.45 | $6.92 | $9.24 | $16.16 |
| vLLM, 8B FP16, 1ร A100-40GB, peak | 793 | 2.85 M | โ | @ $1.99: $0.70 | โ | โ |
| Ollama default, 8B FP16, same A100 | 41 | 0.148 M | โ | @ $1.99: $13.48 | โ | โ |
Readings: a saturated single-H100 vLLM 70B node sits at $0.17โ0.81 per 1M, below or at parity with every hosted Llama-3.3-70B option ($0.10โ1.04) and 12โ60ร below GPT-5 output at $10.00. The identical box at 1โ10 concurrent costs $0.64โ16.16 per 1M, worse than every open-weight API; the 20ร spread between the 1-user and 100-user rows exceeds any engine-to-engine difference except Ollama's default-config penalty, which makes it 19ร the cost of vLLM on the same A100 ($13.48 vs $0.70). Third-party corroboration: Mixtral 8x7B on H100 falls from $15.25 to $0.87 per 1M as load rises from 1 to 25 RPS [S: LeanLM]; "Llama 4 70B on H100 at batch=8 โ $0.18/1M output" [S: Spheron].
Ops overhead and break-even
LeanLM's all-in multiplier over raw GPU rent is 3โ5ร, with a coverage ratio of one mid-level MLOps engineer per 4โ6 GPUs [S]. Applied to the saturated-H100 row, effective cost becomes $0.5โ1.75 per 1M, which is roughly at parity with Together ($0.54โ1.04) and Bedrock ($0.72) and still well below frontier APIs โ but only at saturation. SitePoint places break-even against a managed API at roughly 2โ5 M tokens per day on reserved capacity over a 12-month window [S].
Add the gateway line: 1 vCPU + 4 Gi per LiteLLM pod plus Redis and Postgres [P]. At 3.2k QPS an independent test saw 11.8 GB RSS [S], so budget memory per pod, not only CPU.
CPU-only cost
No 2026 source with disclosed method gives tok/s per CPU-dollar for a multi-user server-class CPU [U]. Single-stream consumer figures exist (Mac M5 Max, 7B Q4, 95โ110 tok/s [S]) but carry no price. CPU hosting should be stated as viable for fewer than 5 concurrent users on โค8B Q4 models, with no cost-per-token claim.
Deployment blueprint
Sizing figures below come from the cited benchmarks; adjust after an in-house load test.
Step 1 โ Engine tier
- Model: Llama-3.3-70B-Instruct FP8 on 1ร H100 80GB per node; expect 76โ78 GB VRAM at 50โ100 concurrent [S], leaving no room for a co-resident model.
- Set
--max-num-seqsto the concurrency you have benchmarked (the Spheron curve suggests 50โ100 on this card) [S]. vLLM has no rate limiting beyond this flag. - Plan for a ~62 s cold start [S]: keep a warm standby or pre-pull weights before scaling events.
- Bind only to the private network. Verify the
--api-key, quantization and tensor-parallel flags againstdocs.vllm.aibefore launch โ they were not confirmed on the fetched docs page [U]. - For a small-model or CPU pool, run Ollama with
OLLAMA_NUM_PARALLELraised from its default of 1 [P]; memory scales linearly with slots ร context [P]. Never expose port 11434 directly [P].
Step 2 โ Gateway tier
- LiteLLM at 1 vCPU + 4 Gi per pod, 1 uvicorn worker per pod, scaled horizontally [P]. Four such instances sustained 1,170 RPS at 2 ms median overhead [P].
- Provision Postgres โฅ12 and Redis; both are required for shared router state and rate limits across instances [P].
- Define one virtual key per team with RPM/TPM budgets [P]. Configure
routing_strategywith the two vLLM nodes as primary and a hosted API as fallback.
Step 3 โ Observability and auth
- Scrape vLLM
/metrics[P] and LiteLLM Prometheus metrics [P]; wire LiteLLM OTEL or Langfuse callbacks for traces [P]; spend logs land in Postgres [P]. - Do not rely on an Ollama
/metricsendpoint: its existence is unconfirmed in official docs [U], and if present it is reportedly unauthenticated. - SSO and audit logs on LiteLLM are enterprise-licensed [P]; budget for the licence or front the gateway with an external IdP.
Step 4 โ Validate before commitment
Run a 300 s sweep at 1โ256 concurrent (the Red Hat method [P]) on your own node; published $/1M varies 20ร with utilization on identical hardware, so only your own curve sets a defensible figure.
Final verdict by scenario
Single-node development. Ollama. Its ~45 ms single-user TTFT [S], CPU/GPU flexibility and zero dependencies fit a one-person loop. Do not extrapolate its numbers to production: 41 tok/s and 673 ms p99 at default config [P].
Multi-GPU production. vLLM behind LiteLLM. vLLM is the only engine with primary-source throughput data (793 tok/s, 80 ms p99 [P]) and native metrics; LiteLLM supplies the auth, quotas and fallback that vLLM lacks. At saturation this stack lands at $0.17โ0.81 per 1M raw, $0.5โ1.75 all-in [derived], versus $10.00 for GPT-5 output [P]. Below roughly 2โ5 M tokens/day [S], a hosted Llama-3.3-70B API at $0.10โ1.04 [S] is cheaper.
CPU-only. Ollama or LocalAI on โค8B Q4 models for fewer than 5 concurrent users. No cost-per-token figure can be defended from available sources [U]; treat this as a capability decision, not a cost one. Choose LocalAI over Ollama only if you need STT/TTS, images or realtime in the same binary [P].
Multi-provider routing. LiteLLM is the only tool in the set that does this [P]; the others are engines. Accept the Postgres + Redis dependency, 1 vCPU + 4 Gi per pod and up to 11.8 GB RSS at 3.2k QPS [S] as the price of per-key budgets and cross-provider fallback. Ignore the Rust hot-path numbers until GA [U].
Omitted by design. LocalAI concurrency throughput, tuned-Ollama high-concurrency throughput, and CPU-only $/1M โ no source with a disclosed method exists for any of the three as of 2026-09-16.
Sources
- Red Hat Developer โ Ollama vs vLLM deep dive (2025-08-08, upd. 2026-07-13): https://developers.redhat.com/articles/2025/08/08/ollama-vs-vllm-deep-dive-performance-benchmarking
- Spheron โ vLLM vs TensorRT-LLM vs SGLang H100 (2026): https://www.spheron.network/blog/vllm-vs-tensorrt-llm-vs-sglang-benchmarks/
- LiteLLM docs โ Benchmarks: https://docs.litellm.ai/docs/benchmarks
- LiteLLM docs โ Production: https://docs.litellm.ai/docs/proxy/prod
- Markaicode โ LiteLLM production latency (2026): https://markaicode.com/benchmarks/litellm-production-benchmark-latency/
- Markaicode โ Ollama vs vLLM (2026): https://markaicode.com/benchmarks/ollama-vs-vllm-performance/
- SitePoint โ Ollama vs vLLM 2026: https://www.sitepoint.com/ollama-vs-vllm-performance-benchmark-2026/
- Ollama FAQ: https://docs.ollama.com/faq
- Ollama issue #3144 (metrics): https://github.com/ollama/ollama/issues/3144
- LocalAI features: https://localai.io/docs/features/
- vLLM online serving docs: https://docs.vllm.ai/en/latest/serving/online_serving/
- Presenc AI โ local tok/s benchmarks 2026: https://presenc.ai/research/local-llm-tokens-per-second-benchmarks-2026
- IntuitionLabs โ H100 rental prices (verified 2026-08-20): https://intuitionlabs.ai/articles/h100-rental-prices-cloud-comparison
- Spheron โ RunPod H100 pricing 2026: https://www.spheron.network/blog/runpod-h100-pricing-2026/
- SynpixCloud โ cloud GPU pricing 2026: https://www.synpixcloud.com/blog/cloud-gpu-pricing-comparison-2026
- OpenAI pricing (2026-08-21): https://developers.openai.com/api/docs/pricing
- PricePerToken โ Llama 3.3 70B: https://pricepertoken.com/pricing-page/model/meta-llama-llama-3.3-70b-instruct
- Markaicode โ Llama 3.3 70B API cost: https://markaicode.com/pricing/llama-33-pricing/
- CloudZero โ Groq pricing 2026: https://www.cloudzero.com/blog/groq-pricing/
- AI Pricing Guru โ Together pricing: https://www.aipricing.guru/together-pricing/
- LeanLM โ self-hosting cost: https://leanlm.ai/blog/self-hosting-llm-cost
- SitePoint โ self-hosted LLM costs 2026: https://www.sitepoint.com/self-hosted-llm-costs-2026/
- Spheron โ GPT-6 vs self-hosted 2026: https://www.spheron.network/blog/gpt-6-vs-self-hosted-llm-2026/