BlogInfrastructure
Deciding whether an AI feature should run on your own infrastructure
Keep a managed model endpoint unless a specific requirement rules it out, or until a measured workload shows that self-hosting costs less once you count the people who run it. The requirements worth testing are where data may be processed, which model you must use, latency and how long a model must stay available. A cost that is easy to leave out is operating a model service around the clock. This guide turns both into checks against your own workload.
Name the constraint that raised the question
Self-hosting comes up for different reasons, and each one has its own test:
- Data handling: a contract or policy restricts where data may be processed. Test whether any managed option, under your contract terms, meets it.
- Model choice: you need an open-weight or fine-tuned model. Test whether a managed service can serve your weights.
- Latency: the feature has a strict response-time target. Measure the 95th percentile on the managed endpoint with real prompts before assuming it fails.
- Model lifecycle: providers retire models on their own schedule, and Anthropic notes that partner platforms set their own retirement dates. Count how often you would be forced to migrate and what each migration costs you.
- Cost at volume: spend grows with traffic. Test it with the worksheet below.
Read what the managed terms already settle
Teams sometimes assume a managed endpoint keeps their data indefinitely. Read the current terms instead. OpenAI's API documentation, for example, states that API data is not used for training unless the customer opts in, that abuse monitoring logs can contain prompts and responses and are kept for up to 30 days by default unless law or harm prevention requires longer, that some features store application state, and that eligible customers can apply for Zero Data Retention or Modified Abuse Monitoring. Other providers publish different terms by product and plan. Whether any of them is acceptable is for your data protection and legal owners to decide; the engineering task is to describe the data flow precisely enough for that decision.
What you take on when you serve the model yourself
- Capacity sized for peak traffic with headroom, paid for while idle unless someone builds scaling for it
- Serving metrics someone watches: vLLM, for example, exposes Prometheus metrics such as time to first token, end-to-end request latency and KV cache usage
- Upgrades of models, serving software and drivers, each checked against your evaluation set
- Security of the hosts, the model weights and the endpoint's credentials
- On-call cover for failures outside office hours
The last item is easy to miss in a cost comparison. Google's SRE book derives a minimum of eight engineers for a single-site team to sustain a round-the-clock rotation with a primary and a secondary, under its own rule that no more than a quarter of an engineer's time goes to on-call. Your rules may differ, and an internal tool may only need support in office hours, but the calculation shows that 24/7 operation is a staffing decision as much as a hardware one.
A worksheet for measuring the workload
- Requests per day and how they spread over the day and week, including peaks
- Input and output tokens per request, measured from logs rather than estimated
- The latency target and whether requests can be batched or queued
- An evaluation set that any self-hosted model must pass
- Managed cost per month, taken from invoices
- Self-hosted cost per month: compute for peak with headroom, storage and networking, plus engineering and on-call time
A hypothetical example shows how the pieces combine. Say an internal document classifier has steady daytime traffic and uses a usage-billed managed API costing M per month. An open-weight model that passes the evaluation set needs two GPU instances for redundancy at G per month each, plus an assumed quarter of one engineer's time for upgrades and monitoring, costing E. Self-hosting is cheaper only if 2G plus E is below M. If traffic stops at night, the instances sit idle unless someone builds scale-down, while the usage-billed API charges only for tokens used. Provisioned or dedicated managed capacity is billed for capacity as well, so it enters the comparison the way GPUs do. The balance can shift when traffic is high and steady, or when a smaller fine-tuned model passes the same evaluation at a lower serving cost, so measure both.
Options between the two
The choice is rarely binary. A provider's models offered through your cloud account and region, dedicated capacity from a provider, or routing where one high-volume task goes to a small self-hosted model and the rest stays managed each move part of the operating work to you. Each also has its own terms and lifecycle, so the checks above apply per option. A practical next step is to fill in the worksheet with one month of real logs before anyone sizes hardware.
Questions
Is self-hosting automatically more private?
It keeps inference inside your environment, but privacy then depends on your own controls: who can read prompts in logs, how long traces are kept and how the hosts are secured. For a team without that capacity, a managed endpoint with suitable terms can be the more controlled option.
Can we start managed and move later?
Yes, if the integration stays portable: a thin internal interface to the model, prompts and evaluation sets under version control, and no dependence on provider-only features you could not replace. The evaluation set is what lets you compare a self-hosted model with the managed one before switching.
Which open-weight model should we run?
Shortlist models whose licence and size fit your requirements and hardware, then pick the one that passes your evaluation set at your latency target. Public leaderboard positions are a weak guide to performance on your task.
Related services
AI engineering and architecture
Assistants, voice interfaces and agents in the products you sell, with the serving and retrieval underneath.
Custom model training
A small open-weight model trained for one task and compared with your current model on cost and accuracy.
LLM cost optimisation
Agent spend broken down by team and task, then lowered through defaults, budgets and routing your platform team can run.
More from the blog
Model provider failover
How to fail over to another model during an outage without silently changing quality, permissions or data terms: a fallback contract, switch triggers, equivalence tests and rollback.
Runbooks for AI features
What on-call engineers should do when an AI feature is slow, unavailable, expensive, wrong or acting outside its limits: symptom classes, runbook entries, safe switches and owners.
AI trace data retention
What to log to debug agents without keeping every sensitive prompt: three tiers of trace data, content capture off by default, the limits of redaction and retention set by your policy owners.
Talk to an engineer
Bring one piece of work you would like to improve. The call takes 30 minutes and needs no access to your systems or your data.
Booking runs on Google Calendar.
Prefer to write first? Leave your email and a few lines, and we reply with times.
Look for the draft in your email program
Send it from there, and an engineer replies in person with times for a 30-minute call. If no draft has opened, write to us at miki@cloudsail.com.