Service

Managed Open Models

Open-weight models selected for your task and run on GPU infrastructure dedicated to you, on your own hardware, in your cloud account, or across both, with the retrieval layer, gateway, spend controls, monitoring, and upgrades operated by us.

Talk to us about Managed Open Models See what we deliver

Operated 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. Where it runs on hardware you own, the hardware stays yours and we operate what runs on it.

Because inference runs inside your environment, your prompts, documents, and outputs are not sent to a third-party model API unless you choose to add one as a fallback. That makes the answer easier to give when your own customers ask where their data goes.

Where it runs

The service goes to your infrastructure. That can be GPU servers you already own, in your own facility or in colocation; capacity from a cloud provider; or both at once, holding inference on regulated data inside your own facility while other work draws on provider capacity when demand rises.

We work in all three. Disconnected environments are included: where an air gap is a requirement, models and patches reach the environment through a controlled transfer process we agree with you up front, and the monitoring and upgrade path are designed around the absence of egress instead of assuming it. We can evidence the capability under NDA when you need us to.

We design, build, and run platforms on AWS, Google Cloud, and Azure, and we are also an UpCloud reseller, which gives teams in the UK and the Benelux a European provider with flat pricing and included outbound transfer. On UpCloud, GPU Servers are currently offered from Helsinki, with GPU quotas set per account. Where we resell infrastructure, the margin we earn goes back into your platform as engineering hours, agreed in your contract and shown on your monthly invoice. Our UpCloud partnership announcement sets out that relationship.

On your own hardware, the pieces we operate are the same ones: the serving stack, the retrieval layer, the gateway, the monitoring, and the upgrade path, deployed as code. Because the service is the operating layer above the infrastructure, moving between providers, or off one entirely, changes where it runs and leaves what we run intact.

What Managed Open Models delivers

What we run between an open-weight model and your production service.

Model selection

Task-Based Evaluation

We evaluate candidate models against your own tasks and data, and recommend the smallest model that does the job well. The use case sets the model type, and our longest-running work is in vision and financial modelling as well as language models and agentic assistants. Where the use case is not yet defined, our Accelerate sprints align on a single measurable problem first. Sometimes the evaluation points to a managed API instead, and we will tell you which one.

Built by Data & AI

Model selection

Model Set and Upgrades

We run Kimi, GLM, Qwen, and OLMo in production today, with Mistral and Gemma 4 outside production. Where another open-weight model suits your task better, we evaluate it on your own work and operate it if it holds up. When a stronger candidate appears, we evaluate it against your task, compare it with your current model, and you decide whether to switch.

Built by Data & AI

Serving

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.

Built by Cloud Managed Services

Serving

Capacity and Performance

GPU sizing, quantisation choices, and concurrency tuning matched to your workload, with the measurements behind each choice shared with your team.

Built by Cloud Managed Services

Retrieval

Retrieval Layer

Retrieval-augmented generation on PostgreSQL with pgvector by default, as a managed extension where your provider offers one and installed and operated by us on your own hardware, and a dedicated vector store where your scale or filtering needs call for one.

Built by Data & AI

Retrieval

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.

Built by Data & AI Managed Services

Control

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.

Built by Cloud Security Managed Services

Control

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.

Built by Data & AI Managed Services

Evidence

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. These are the records supplier questionnaires tend to ask for, assembled while the platform runs instead of reconstructed at audit time.

Built by Security Managed GRC Services Praxis

Evidence

Regulatory Mapping

The same records can support EU AI Act log-keeping for deployers of high-risk systems, accountability and security obligations under EU and UK GDPR, due diligence and audit of ICT third-party arrangements under DORA Article 28, and the supply-chain measures and incident evidence that NIS2 and its Dutch implementation ask for. They are also the material SOC 2 examinations test. Which obligations apply depends on your use case, and we work that mapping out with you.

Built by Security Managed GRC Services Praxis

Evidence

Security Baseline

Network isolation, secrets management, and access controls across the serving stack, gateway, retrieval layer, and network path, built with the same practices as our Security capability.

Built by Security Enclave

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.

Where It Runs

Where you already own GPU servers, or a policy or contract keeps a class of data inside a particular facility, the service runs there. This is work we do, and the requirement usually arrives from a policy or a regulator. We can evidence that under NDA when it matters to your procurement. Where an air gap is a requirement, the change is in how artefacts move: models, patches, and configuration reach the environment through a controlled transfer process with verification at the boundary, and monitoring and upgrades are designed for an environment with no egress. We will set out that process before you commit to it, because it determines how quickly a security advisory can be acted on.

On hardware in your own facility, residency is that facility. On a cloud provider, it is the region you select, so prompts and retrieved context can be processed in one country while your databases run in another. In a hybrid deployment, one class of data can be held to one location while other work runs elsewhere. Every engagement records the processing location of each component, and we will put that record in your contract.

The Model Set

In production: Kimi from Moonshot AI, GLM from Z.ai, Qwen from Alibaba Cloud, and OLMo from the Allen Institute for AI, across sizes from a single GPU to long-context work on several. Outside production we also work with Mistral's Apache 2.0 models and with Gemma 4 from Google, which is published under Apache 2.0. The list above is what we run today, and it is not the limit of what we will operate. Where an open-weight model suits your task we will evaluate it and, if it holds up on your own work, operate it. The serving stack, gateway, retrieval layer, and monitoring are the same whichever family you choose, which is what makes adding one a scoped piece of work.

Where your procurement policy excludes an originator, that policy sets the eligible set before evaluation starts, and we will tell you what it leaves and what it costs you in capability. Three of the families we run in production originate with Chinese labs, and for many buyers that is a question their board will raise. Weights and a service are different things: we run the weights inside your environment, so the originator receives no prompts, no outputs, and no telemetry. We record the source and checksum of each artefact and verify it against the published reference, which establishes that the weights you run are the weights the originator published, and nothing about how they behave. Behaviour is what evaluation against your own tasks is for.

Most of what we run is Apache 2.0 or MIT, some add conditions above a usage threshold, and some models are research-only and excluded from client work. Earlier Gemma releases carry Google's own terms, whose prohibited use policy bars automated decisions in domains affecting material rights including finance and insurance, which is why we work with Gemma 4 under Apache 2.0 instead of the family in general. We identify the terms that apply to each candidate before you choose it, including any that would attach to your own product.

How We Operate It

Delivery is performed by Sakura Sky engineers. The monitoring, gateway, and log components run inside your environment, so your prompts, documents, and telemetry are not handed to a third-party monitoring service, ticketing system, or log aggregator. Where we resell infrastructure, the provider hosts the environment under the terms in your contract. Any other third-party tool with access is named in the dependency inventory in your contract, with what each can and cannot reach, and nothing is added without your approval. Access is restricted to named engineers in the jurisdictions your policy allows, so where your regulator limits support to the EEA or the UK, the people who can reach your deployment are limited to match. The named list, the jurisdictions, and the roles each can reach are a schedule to the contract. Logs are written to storage in your environment under the retention period you set, and we will configure and test whatever window you need. The audit trail sits in your storage, so it is yours to hold, export, and produce.

You keep the facility, power, physical access, the hardware itself, its firmware, and the management controller. We take the container runtime, the serving stack, model artefacts and their provenance records, the retrieval layer and its pipelines, gateway operation, monitoring, and alerting. Your source systems and the access controls inside them stay with you, and gateway policy is yours while we operate it. Host OS and kernel patching sits with us where we have access to the environment, and with you where an air gap prevents that. GPU driver and runtime versions are pinned against a tested matrix we maintain and moved in an agreed window, so the serving stack and the driver underneath it stay in step. The split is written into the engagement before work starts, line by line, including who is paged and when.

We work into the recovery and break-glass procedures you already have, and strengthen the parts of them that the model platform touches, which usually means the artefact store, the configuration you would need to rebuild from, and the order things come back in. Your emergency access controls govern, and what we hold is scoped to what your own governance authorises. The arrangement is agreed up front and recorded with the responsibility split.