Service / Cloud
LLM cloud
Run language models on public cloud without handing over your architecture — or your margin.
The bill arrives before the architecture does
Most teams reach production on a single provider's API because it was the fastest way to ship. That is a reasonable start and a poor destination. The pricing is per-token and opaque, the model can change under you, and the thing you built is now shaped around one vendor's assumptions.
The work is not ripping that out. It is putting a layer between your product and the model so that provider, model, and price become decisions you can revisit — and then making those decisions with evidence.
Capabilities
What this covers.
Model selection
Frontier API models against open weights on your own workload, scored on quality, latency and cost per useful task — not on public leaderboards.
Multi-cloud serving
Vertex AI, Bedrock and Azure OpenAI alongside self-hosted open models, behind one interface your application does not have to know about.
Inference gateway
A single ingress for auth, rate limits, quotas, retries and per-team budgets, so model access is governed rather than sprawled across services.
Routing and fallback
Route by task class, context length or tenant. Fail over between providers on error or saturation before your users see a timeout.
Caching
Prompt and prefix caching, plus semantic caching where the workload tolerates it. Usually the largest single cost reduction available.
Cost attribution
Token spend broken down by feature, tenant and team, so unit economics are a number you know rather than a number you discover.
Observability
Traces, token accounting and quality signals wired into the stack you already run — OpenTelemetry, not another dashboard to check.
Rate-limit engineering
Quota negotiation, provisioned throughput sizing, and backpressure that degrades gracefully instead of collapsing.
Exit paths
A documented, tested route off any single provider, so the option to move is real rather than theoretical.
Deliverables
What you're left with.
- A reference architecture for model access, with the trade-offs written down
- A working gateway deployed in your cloud, in your IaC, under your CI
- A model evaluation harness pointed at your workload, that your team can re-run
- Cost model and unit economics per feature, with the levers identified
- Runbook and handover session with the engineers who will own it
Stack
What we work in.
- Vertex AI
- AWS Bedrock
- Azure OpenAI
- vLLM
- LiteLLM
- Envoy
- Terraform
- OpenTelemetry
Tools follow the problem. If your team already runs something that works, we would rather extend it than replace it.
Questions
Asked often.
Do we have to leave our current provider?
No. Most engagements keep the incumbent and put a layer in front of it. The goal is optionality — being able to move a workload when the economics or the quality change — not migration for its own sake.
Is self-hosting cheaper than an API?
Sometimes, and the crossover is workload-specific. It depends on utilisation, latency targets and how much engineering time you are willing to spend. We model it on your numbers and will tell you when the answer is to stay on the API.
Can you work inside our existing platform team's conventions?
That is the default. Work lands in your IaC, your CI, your observability stack and your review process. If it only runs on a consultant's laptop, it is not finished.