The LoRA multi-adapter setup guide proves shared serving works: one base model in VRAM, a hundred adapters swapped in per request, one GPU instead of a hundred. LoRA inference cost optimization doesn't stop at proving the pattern, though. Adapter counts keep climbing, GPU-cache slots don't, and every swap that misses that cache carries a latency cost that a spreadsheet comparing GPU-hours alone never sees. This is the breakeven math, with the SLO cost of adapter swaps priced in rather than ignored.
TL;DR: When Does LoRA Inference Cost Optimization Favor Shared Adapters?
Shared adapters win on GPU-hours almost everywhere; the exception is cache concurrency, not tenant count.
- GPU-hours: Spheron's A100 80GB on-demand runs $1.48/hr and its H100 SXM5 on-demand runs $2.64/hr, both as of 17 Sep 2026; splitting one H100 across 100 shared tenants beats paying for a dedicated A100 per tenant by a wide margin on raw GPU-hours.
- Cache ceiling: vLLM's production default holds 8 adapters in GPU cache, 64 in CPU RAM; inside that window, swaps cost sub-millisecond to tens of milliseconds.
- Swap miss cost: a CPU-RAM eviction measured 30 to 50ms at p50 in a production 40-adapter deployment; a disk or S3 load runs meaningfully worse still.
- The real breakeven: once active concurrent tenants exceed the CPU-RAM tier, SLO cost, not GPU-hours, should drive the call. See the GPU cost optimization playbook.
The Setup: Cost Per Tenant on Shared LoRA Serving vs Dedicated GPUs
Two architectures serve the same population of LoRA-fine-tuned tenants. Dedicated gives every tenant their own GPU instance running their own adapter merged into (or loaded alongside) the base model. Shared gives every tenant a slot in one base model's VRAM, with vLLM's LoRAManager swapping the right adapter in per request. The multi-tenant LLM serving guide already worked out the unit economics for full-model multi-tenancy; this is the same question one layer down, where the thing being shared is adapter weights rather than entire models.
What Dedicated-Per-Tenant Actually Costs (GPU-Hours, Idle Capacity, VRAM)
A dedicated GPU per tenant bills by the hour whether or not a request ever arrives. For an 8B base model, an A100 80GB is enough headroom; on Spheron's live marketplace, single-GPU on-demand A100 80GB offers run $1.48/hr as of 17 Sep 2026. Holding the rate captured on 14 Sep 2026, $1.43/hr, fixed for this worked example and running it 24/7 for a month (720 hours), one tenant costs roughly $1,030, independent of whether they send ten requests a day or ten thousand. Rerun the math against the live rate above before treating that figure as current. At low, typical SaaS volumes, most of that GPU sits idle: the multi-tenant serving benchmark measured a shared H100 running under 2% utilization at 5M tokens/day, with headroom for 50x more volume before the GPU bottlenecks, and a dedicated-per-tenant GPU at the same volume is exactly as idle, just billed to one customer instead of split across fifty.
The VRAM math is just as lopsided. A 16GB FP16 8B model sitting alone on an 80GB GPU wastes the other 64GB unless something else shares it, and nothing does in a dedicated architecture, by definition.
What Shared Multi-Adapter Serving Costs (Base Model + Adapter Overhead)
Shared serving pays for one base model's VRAM and GPU-hours once, then amortizes that cost across every tenant whose adapter can fit in cache or load fast enough on demand. Per the setup guide's own VRAM breakdown, a Llama 3.1 8B base model plus 100 rank-16 LoRA adapters (8 resident in GPU cache, 92 buffered in CPU RAM) totals around 22.5GB, comfortably inside an 80GB card with room for KV cache and batching headroom.
But "shared" is not free of per-adapter cost. That's the tax for turning LoRA support on at all, separate from anything to do with swapping between adapters. It's the first line item any shared-serving cost model has to account for, and it's easy to miss if you only benchmark the base model and assume LoRA is free.
Where the Curve Crosses: Adapter Count vs Per-Tenant Cost
The Cost-Per-Tenant Formula and Its Inputs
The cost-per-million-tokens formula (cluster $/hr divided by measured tokens/sec) is the right building block, applied per architecture:
- Dedicated: cost per tenant per month = (GPU $/hr × hours/month), flat, regardless of tenant count or volume.
- Shared: cost per tenant per month = (GPU $/hr × hours/month) ÷ (tenants the pool can serve at that adapter rank and volume before hitting either the compute ceiling or the cache-eviction SLO wall).
The dedicated side has one input and no economies of scale. The shared side has three: GPU cost, the compute ceiling (tokens/sec throughput against total token volume across all tenants), and the cache ceiling (how many adapters fit warm before swaps start costing latency). Most cost models for multi-adapter serving stop at the compute ceiling. That's the mistake this post is here to correct.
The Breakeven Table: Tenant Count vs GPU Needed as Shared Saturates
Spheron's live on-demand rate for a single H100 SXM5 is $2.64/hr as of 17 Sep 2026. The table below holds the rate captured on 14 Sep 2026, $2.64/hr, fixed as a worked-example input, applied against vLLM's production defaults (--max-loras 8, --max-cpu-loras 64) and a pool of 100 registered tenants:
| Active concurrent tenants | Adapter tier they're served from | Swap behavior | Per-tenant monthly cost (shared, 100 registered tenants) |
|---|---|---|---|
| 1-8 | GPU cache | Sub-millisecond, on every request | ~$19.01 |
| 9-64 | CPU RAM (LRU cycling) | 30-50ms p50 per swap, measured on a production 40-adapter deployment | ~$19.01, latency now variable |
| 65+ | Disk / S3 | Cold load, measurably worse than the CPU-RAM tier | ~$19.01, SLO risk becomes material |
| Approaching the compute ceiling (~50x the 50-tenant, 100k-tokens/day baseline) | n/a, GPU itself saturates | GPU adds a second instance | Cost per tenant stays roughly flat; the pool splits |
The dollar figure barely moves across the table. What moves is latency risk, and that's the part a GPU-hours-only spreadsheet never shows.
The rate behind that table was live on 14 Sep 2026 and is held fixed so the per-tenant figures stay internally consistent; it is not the current price. For that, see the live rate earlier in this section or the pricing page.
Pricing fluctuates based on GPU availability. Spheron's live single-GPU on-demand rates are as of 17 Sep 2026 and may have changed since the worked example above was captured. Check current GPU pricing → for live rates.
What Moves the Breakeven Point (Adapter Rank, Request Volume, Base Model Size)
Three variables shift where the SLO wall sits:
Adapter rank. Higher rank means bigger per-adapter weights, which means fewer adapters fit in each cache tier. The setup guide's rank table shows rank-8 adapters fitting 200+ in GPU cache on an H100 80GB against rank-64 adapters fitting only 25+. A tenant base running rank-64 fine-tunes hits the CPU-RAM tier, and then the disk tier, at a fraction of the concurrent-tenant count that rank-8 adapters would tolerate on the same GPU.
Request volume per tenant. The compute ceiling, not the cache ceiling, becomes the binding constraint once per-tenant volume climbs.
Base model size. A larger base model raises the fixed cost both architectures pay, but it raises the dedicated side's per-tenant cost linearly while the shared side's per-tenant cost keeps falling as tenant count grows, because that fixed cost is still split across everyone sharing it. A 70B base model needs multiple H100s regardless of architecture; the shared pool's advantage over dedicated per-tenant GPUs actually widens at that scale, not narrows, since a dedicated 70B-class GPU allocation per tenant is far more wasteful at 2% utilization than an 8B one.
The Latency Trade-off Nobody Prices In: Adapter Swap Overhead at Scale
What an Adapter Swap Actually Costs: Cache Hit vs CPU-RAM vs Disk/S3 Miss
vLLM's LoRAManager serves a cached adapter with sub-millisecond overhead, the fast path the setup guide's cache design already banks on.
Those numbers compound with the base-model LoRA tax already covered: a request that misses cache is paying both the up-to-50% base LoRA throughput overhead and the swap latency on top of it. Teams that benchmark only warm-cache requests, which is what most quick load tests do, never see this stack.
For teams running quantized backends instead of full-precision vLLM, Aphrodite Engine's per-request LoRA hot-swap follows the same cache-hit-vs-cache-miss shape, since it shares vLLM's architectural pattern for adapter residency, just paired with EXL2, GGUF, and GPTQ kernels instead of full-precision weights.
Turning Swap Latency Into an SLO Violation Rate, and a Dollar Figure
An SLO violation happens when a swap-miss penalty pushes a request over its latency budget. Take a P95 time-to-first-token budget of 500ms as a working example, the same order of magnitude used in production agent-serving benchmarks. If the base model's own P95 TTFT under load already consumes 300-400ms of that budget, a CPU-RAM swap miss adding 30-50ms is usually absorbable. A disk or S3 miss, the tier the 40-adapter deployment above deliberately engineers around, is far more likely to blow the budget outright on its own, regardless of how fast the base model runs.
The SLO violation rate is a function of how often a request's adapter has fallen out of the warm tiers, which rises as active concurrent tenants exceed the 8-slot GPU cache and then the 64-slot CPU-RAM buffer. Turning that into a dollar figure is contract-specific, but the shape of the math is the same everywhere: SLO cost per month = (violating requests per month) × (whatever your contract or churn model prices a violation at, whether that's a stated SLA credit or an estimated customer-lifetime-value hit from repeated slow responses). A tenant contract with, say, a 5% monthly-fee credit for any hour where P95 TTFT breaches 500ms turns a handful of bad hours a month into a real number against the GPU savings shared serving was supposed to deliver.
Research systems exist specifically to push this ceiling back out rather than accept it. Punica reports 12x higher throughput in serving multiple LoRA models compared to state-of-the-art LLM serving systems while only adding 2ms latency per token, by batching decode steps across adapters instead of treating each swap as a serial event.
When SLO Cost Flips the Breakeven Back Toward Dedicated GPUs
The breakeven flips when the monthly SLO cost of running a tenant on the shared pool exceeds the monthly GPU-hours saved by not giving them a dedicated instance. At 100 shared tenants on an H100 SXM5, that savings is roughly $1,000/tenant/month (the gap between the ~$1,030 dedicated figure and the ~$19.01 shared figure above). A tenant would need to be generating serious, repeated SLO violations, the kind that trigger real contractual credits or visible churn risk, before that gap closes. In practice this almost never happens from GPU-hours pressure; it happens from concurrency pressure on a handful of unusually heavy tenants sharing a pool sized for everyone else. The fix is rarely "move everyone to dedicated." It's moving the specific tenants whose concurrency or SLA terms don't fit the shared pool's cache ceiling, and leaving the rest exactly where they are.
Bursty, spiky access patterns are a related but distinct case from steady high concurrency.
Decision Framework: LoRA Inference Cost Optimization by Tenant Profile
| Tenant profile | Recommended architecture | Why |
|---|---|---|
| Many tenants, low volume each, active concurrency usually under 8 | Shared, single GPU, vLLM defaults | This is the 100-customers-on-one-H100 case; GPU cache absorbs everyone, no swap risk |
| Many tenants, active concurrency regularly in the 9-64 range | Shared, but monitor swap-miss rate against your SLO budget | CPU-RAM tier is usually fine; watch it, don't ignore it |
| A handful of tenants with heavy, steady concurrency beyond 64 active | Hybrid: dedicated GPU for the heavy tenants, shared pool for the rest | Matches the multi-tenant guide's hybrid recommendation one layer down at the adapter level |
| Bursty, spiky traffic with strict TTFT SLOs | Serverless-style LoRA architecture (ServerlessLoRA-pattern) over plain vLLM cache tiers | Cold-start-dominated failure mode, not eviction-dominated |
| Any tenant with data sovereignty or regulatory isolation requirements | Dedicated, regardless of cost math | Isolation requirement overrides the economics; see also token-level GPU pooling for the model-level version of this same tradeoff |
| High adapter rank (32+) across a large tenant base | Recheck cache-tier capacity before scaling registered tenant count further | Rank directly shrinks how many adapters fit warm; the breakeven table above moves with it |
For the broader FinOps lens this sits inside, beyond just the shared-vs-dedicated question, the AI inference cost economics playbook covers the other three optimization layers (model, runtime, infrastructure) that apply whether or not LoRA is in the picture at all.
Spheron fits both sides of this comparison on the same platform: on-demand rates aggregated live across 5+ providers, per-minute billing with no minimum rental term, and spot pricing on select GPUs for further savings on the shared-pool side. That per-minute billing matters more than it sounds for the dedicated side of this math specifically, since an idle dedicated-per-tenant GPU billed by the hour instead of the minute exaggerates the exact waste this post is measuring. What Spheron doesn't provide is a managed multi-adapter serving product or documented MIG/vGPU partial-GPU isolation; a team choosing shared serving still owns the vLLM or Aphrodite adapter-routing layer itself, and the cache-tier latency numbers above come entirely from that software layer, not from anything the GPU rental terms guarantee. For provisioning details beyond what's covered here, the Spheron docs cover instance setup end to end.
Whether the math favors a shared adapter pool or a dedicated GPU per tenant, both sides of this comparison run on the same Spheron capacity, so the cheaper answer never means switching providers.
H100 GPU pricing → | A100 80GB on Spheron → | View all pricing →
Frequently Asked Questions
On raw GPU-hours alone, almost never: a shared H100 SXM5 running vLLM multi-adapter serving stays cheaper per tenant up to roughly the same headroom the underlying multi-tenant benchmark found, about 50x the compute a 50-tenant, 100k-tokens/day-each pool uses. The number that actually flips the decision is concurrency against the adapter cache, not tenant count. vLLM's default production config keeps 8 adapters in GPU cache and 64 in CPU RAM; once active concurrent tenants (not total registered tenants) routinely exceed 64, swap misses start landing on disk or S3 and the SLO cost of those misses can exceed what a second shared GPU, or a dedicated GPU for the heaviest tenants, would have cost.
A GPU-cache hit costs vLLM's LoRAManager sub-millisecond overhead. A miss served from CPU RAM costs tens of milliseconds, and one production deployment serving 40 concurrent adapters measured 30-50ms at p50 for that tier specifically. A cold load from disk or S3, the tier below CPU RAM, is measurably worse still, which is why that same production deployment sizes its CPU pool to keep real customer traffic from ever hitting it. Which tier a given request hits depends on whether its adapter survived LRU eviction from the 8 GPU-cache slots and the 64 CPU-RAM slots vLLM's defaults allocate.
Yes, and this is separate from swap-miss latency. That overhead is the cost of the LoRA code path itself, before you've added a second tenant or a single cache miss.
Raise --max-loras and --max-cpu-loras so more adapters stay warm before falling to disk, keep adapter rank as low as your fine-tune quality allows since rank directly sets how many adapters fit in each cache tier, and pre-warm high-traffic tenants at startup so they never take a cold-load hit. Research systems push the ceiling further: Punica reports 12x higher throughput than earlier multi-tenant LoRA serving at only 2ms of added latency per token, and CaraServe's CPU-assisted prefill reports up to 99% SLO attainment in multi-tenant rank-aware serving. Vanilla vLLM with tuned cache sizes covers most production cases; those systems matter once concurrency and SLO tightness outgrow vLLM's defaults.
