Task-Based Evaluation
We evaluate candidate models against your own tasks and data, and recommend the smallest model that does the job well. Sometimes the evaluation points to a managed API instead, and we will tell you which one.
Service
Managed Open Models
Open-weight models selected for your task and run on GPU infrastructure dedicated to you, with the retrieval layer, gateway, spend controls, monitoring, and upgrades operated by us.
Talk to us about Managed Open Models
See what we deliverOperated for You
Open Models on Infrastructure Dedicated to You
Managed Open Models is a recurring service for teams that want the control of running their own models without building a model operations team to do it. We choose open-weight models against the task you need done, serve them on GPU capacity in an environment dedicated to you, and operate everything around them: the retrieval layer that connects them to your data, the gateway that controls access and spend, the monitoring, and the upgrade path as better models arrive. The cloud account is held in your name, and we operate it for you.
Because inference runs there, your prompts, documents, and outputs are not sent to a third-party model API unless you choose to add one as a fallback. That gives you a clear answer when your own customers ask where their data goes, and costs that track capacity rather than tokens once your volume is steady.
Where it runs
On UpCloud, a European cloud provider headquartered in Helsinki, inference runs on dedicated GPU servers in Helsinki. Managed Kubernetes and PostgreSQL can run in London or Amsterdam, and object storage in Helsinki, Stockholm, or Frankfurt, so we can show you where each part of your data lives. Sakura Sky is an UpCloud reseller, and all of the margin we earn on that spend goes back into your platform as engineering hours, agreed in your contract and shown on your monthly invoice. The service also runs on AWS, Google Cloud, and Azure when that is where your data already lives. Read more in our UpCloud partnership announcement.
What Managed Open Models delivers
What we run between an open-weight model and your production service.
Model Set and Upgrades
Our current model set spans Kimi, GLM, Qwen, and Gemma, and it will change as better models are released. When a stronger candidate appears, we evaluate it against your task, compare it with your current model, and you decide whether to switch.
Serving Stack Operation
Open-source serving stacks such as vLLM, deployed as code, version-pinned, and patched through staged rollouts when security advisories are published, with fixes validated before they reach production.
Capacity and Performance
GPU sizing, quantisation choices, and concurrency tuning matched to your workload, with the measurements behind each choice shared with your team.
Retrieval Layer
Retrieval-augmented generation on PostgreSQL with pgvector by default, using the managed extension, and a dedicated vector store where your scale or filtering needs call for one.
Data Pipelines
Pipelines that keep your documents and records current in the retrieval layer, with access controls that mirror the source system wherever it exposes them.
Gateway and Spend Controls
An OpenAI-compatible gateway in front of every model, with per-team keys, budgets, rate limits, and failover between your model deployments, so a runaway job is held to its own team’s limits rather than taking over shared capacity.
MLOps for Inference
Model and configuration changes ship through a pipeline, with evaluation against your task before release, staged rollout, quality and drift monitoring in production, and rollback if a change underperforms. Latency, throughput, error, and cost monitoring with alerting sits alongside it, run by our Managed Services team. By default, monitoring and gateway logs record operational metadata, not prompt or output content, and content logging stays off unless you enable it.
Evidence Stream
Model provenance records, configuration snapshots, and gateway audit logs produced as a by-product of operation, with output labelling where your use case calls for it. This covers much of what supplier questionnaires ask for, and it supports obligations under regimes such as UK GDPR and the EU AI Act.
Security Baseline
Network isolation, secrets management, and access controls on every layer, built with the same practices as our Security capability.
Use cases and approach
Is It Right for You?
Dedicated GPU capacity is priced by the server rather than by the token, so it suits workloads with steady, sustained usage. We are measuring where that crossover sits for typical workloads. If your volume is still low or uneven, a metered API hosted in the EU is often the simpler start, and we are happy to help you choose one and plan the move later.
Managed inference catalogues cover a limited set of models and versions. Running the model yourself means you can choose the exact model, quantisation, and context length your task needs, and keep that choice stable until you decide to change it, subject to security patching.
Some teams need to pin versions for validation, run models next to sensitive data, or integrate tightly with their own platform. With a dedicated serving stack, you approve how models are deployed, versioned, and upgraded, and we do the operational work.
When the model runs on infrastructure dedicated to you, prompts and outputs stay in that environment unless you add a third-party fallback, and the evidence stream records what ran, where, and under which configuration. That makes supplier questionnaires and audit requests easier to answer.
The Model Set
We currently work with Kimi from Moonshot AI, GLM from Z.ai, Qwen from Alibaba Cloud, and Gemma from Google DeepMind, from small models that fit a single GPU to large models for long-context work. The set will change as the field moves, and we review your model against your task as it does.
Residency is about where your data is processed. On UpCloud, inference currently runs on GPU servers in Helsinki, so prompts and retrieved context are processed in Finland, within the EU, even when your databases sit in London or Amsterdam. Unless you add the developer's own API as a fallback, the model's developer receives no prompts or outputs, because the model is served within your environment.
Provenance is about where the model comes from and what its licence allows. We document the source, checksum, and licence terms of every model we deploy, and where your policy excludes a particular originator, we adjust the set to suit.
Related reading
Running open models and AI platforms in production, from the engineers who do the work.
The CTO Playbook for Agentic Systems
· 6 minutes
A 71-page operating manual for engineering leaders whose software has started to reason, decide, and write the software that carries out …
A 150B MoE on a Developer Laptop: An Upper Bound on What Faster Storage Buys You
· 18 minutes
A 150-billion-parameter mixture-of-experts model streamed from NVMe on an ordinary developer laptop with no usable GPU. Across a 200-token …
Tollgate v0.2.3: What Long-Context Pricing Does to a Spend Cap
· 11 minutes
Some models bill the whole request at a higher rate above a size threshold. What that does to a spend cap, and what changed in Tollgate …