Key facts
| Managed pricing | Plugsky self-serve is flat monthly with unlimited fair-use usage; no per-token billing |
| Self-hosting costs | GPUs, serving runtime, autoscaling, monitoring, patching and on-call |
| Model access | Plugsky: 30+ models under one plan; self-hosting: only Llama variants you run |
| Utilisation | Self-hosting needs high, steady GPU usage to beat managed pricing |
| Deployment | Plugsky offers cloud, VPC, on-prem and air-gapped options |
| Operations | Serving stacks need upgrades, capacity planning and incident response |
| Free plan | 2 free models (plugsky-micro and plugsky-lite), no card required |
| Product status | Chat, streaming, function calling, embeddings and RAG are live |
TL;DR
- Hardware price is the smallest part of self-hosting cost — operations decide.
- Self-hosting wins with high, steady utilisation or absolute data control.
- Plugsky wins on breadth, time to value and zero GPU operations.
- On-prem and air-gapped deployment covers many sovereignty requirements without a GPU fleet.
- A hybrid split is common: managed for most workloads, self-hosted for a few.
How it works, step by step
- Estimate required GPU capacity for your peak concurrency and context length.
- Price hardware or reserved instances plus power, rack space and network.
- Add serving-stack engineering, autoscaling, monitoring and on-call time.
- Model utilisation: what percentage of the month are those GPUs busy?
- Compare total cost with the Plugsky flat plan covering the same usage.
- Check whether residency requirements can be met by VPC, on-prem or air-gapped managed deployment.
- Pilot the managed API first and self-host only workloads that clearly justify it.
Try it yourself
Open the self-hosting break-even calculator →
The full cost of running Llama yourself
Self-hosting starts with GPUs but does not end there. A production deployment needs a serving runtime, model weight management, autoscaling and queueing, health checks, observability, security patching, capacity planning and on-call. Each layer is engineering time you are not spending on the product.
Utilisation is the swing factor. GPUs that run near capacity for most of the month can beat managed pricing; GPUs that idle between bursts pay for capacity nobody uses.
Where Plugsky wins on cost and speed
- Time to value. An OpenAI-compatible endpoint works in minutes, not quarters.
- No idle hardware. Flat monthly plans with unlimited fair-use usage mean cost tracks users, not utilisation.
- Model breadth. 30+ models under one API, so routing stays a code decision.
- Operations. No serving stack, no GPU fleet, no inference on-call.
- Residency without hardware. VPC, on-prem and air-gapped options cover regulated deployments.
Where self-hosting Llama wins
- Absolute data control. When weights, prompts and outputs may never leave your infrastructure — though sovereign managed deployment covers many of these cases.
- Custom weights. Fine-tuned or modified Llama variants that no provider hosts.
- High, steady utilisation. Continuous workloads that keep GPUs busy can beat metered or flat pricing.
- Latency engineering. Co-locating inference with application logic when network round trips matter.
If two or more of those do not apply, the managed route is usually cheaper once operations are counted honestly.
A decision method you can run today
- Measure peak concurrency, context length and monthly tokens from your application.
- Size GPUs for peak with headroom, then compute the monthly hardware cost.
- Add one-third to one-half of a platform engineer's time for operations, plus monitoring and on-call.
- Compare total with the Plugsky flat plan covering the same usage.
- Stress both with 2x traffic and with a quiet month.
The break-even calculator structures the comparison. Revisit it after any model or traffic change — the answer moves.
Honest comparison
| Factor | Plugsky | Self-hosting Llama | Hybrid |
|---|---|---|---|
| Upfront cost | None — free plan to start | GPU capex or reserved instances | Managed start, staged build |
| Ongoing cost | Flat monthly plan, no per-token billing on self-serve | Hardware, power, operations, on-call | Mixed fixed and capex |
| Model access | 30+ models under one plan | Only Llama variants you run | Host the few you need |
| Operations | Provider-run | Serving stack, upgrades, monitoring | Smaller on-call surface |
| Scaling | Fair-use limits, enterprise committed capacity | You size and autoscale GPUs | Burst to managed |
| Data control | Region choice, VPC, on-prem, air-gapped | Absolute | Absolute for sensitive workloads |
Frequently asked questions
Is it cheaper to self-host Llama or use an API?
It depends on utilisation. Self-hosting wins when GPUs stay busy most of the month or when custom weights and absolute data control are required. Add operations and on-call costs before comparing.
What does self-hosting Llama actually cost?
GPUs or reserved instances, serving software, autoscaling, monitoring, security patching and engineering time. The hardware quote is the smallest part; operations usually dominate the total.
Can I get data residency without running GPUs?
Yes. Plugsky offers region selection plus VPC, on-prem and air-gapped deployment, so regulated teams can meet residency requirements without operating their own inference stack.
How many models do I get with Plugsky?
30+ models through one OpenAI-compatible API and one flat plan on self-serve, from small fast models to frontier reasoning and embedding models.
Does Plugsky charge per token?
No. Self-serve plans are flat monthly with unlimited fair-use usage, and there are no per-token charges or overage fees. See the live pricing page for current plans.
What utilisation makes self-hosting break even?
It depends on hardware and operations cost, so run the numbers with your own quotes. The break-even calculator models GPU cost, utilisation and operations against measured API usage.
Can I move between self-hosted and managed?
Yes. Plugsky's API is OpenAI-compatible, so applications can move between cloud, VPC, on-prem and air-gapped deployments without rewrites.
Which is better for a small team?
Managed. A small team rarely has the capacity to run a serving stack, monitor GPUs and handle inference incidents while shipping product. Start managed and revisit only if a workload clearly justifies self-hosting.