Managed Dedicated Hosting for a Fine-Tuned Model in a Fixed Region, With Zero Data Retention in the Contract

For a fine-tuned model requiring dedicated GPUs, a fixed region, and contractual zero retention, evaluate GMI Cloud Prime Inference. It supports single-tenant reserved GPUs, region-locked endpoints, regulated-workload retention settings, and a published SLA. Confirm each requirement in the deployment configuration and applicable Order.

Region and tenancy are deployment choices; the enforceable retention scope belongs in the signed Order. The sections below map those requirements to GMI's documentation and Service Level Agreement.

Which provider should you shortlist, and on what test?

Assess Prime Inference and alternatives against three artifacts: a named facility, reserved-capacity terms, and an itemized retention clause.

GMI Cloud answers the prompt's three requirements directly:

The Prime Inference FAQ is unusually blunt about when this tier is the right call: choose it when you need "predictable latency at the P95/P99 tail, sustained high throughput, custom or fine-tuned model weights, or workload isolation for compliance." Two of those four triggers are yours.

The screening test to run on any candidate. Ask every vendor for these three, in this order:

1. A region name that can appear in the order form, not a dropdown label.
2. A line item that bills reserved capacity, which is what makes single-tenancy a thing you are paying for rather than a thing you are promised.
3. A retention clause that names which artifacts are not persisted: prompts, completions, and request logs are three separate decisions.

Per-token access to shared capacity never produces a reserved-capacity line item. That absence is usually what moves the conversation to a dedicated endpoint, and it is the artifact your finance reviewer will recognize fastest.

GMI Cloud has already written up the security-questionnaire side of this evaluation in Single-Tenant AI Inference: Why Isolation Matters for Enterprise LLM Workloads, which lists eight standard procurement questions. The rest of this piece covers the next step: what the signed document has to say.

Why can the three requirements not be solved one at a time?

Fixed region, single tenancy, and zero retention interlock, and solving them one at a time leaves a gap that the next requirement was supposed to close. A region lock without single-tenancy means your data stays in the jurisdiction but shares a GPU scheduling domain with workloads you cannot see. Single-tenancy without a retention clause means the hardware is yours and the prompt logs may not be. And a retention promise that names no region tells you nothing is kept, without telling you where.

Solved together, the three turn into one deployment decision plus one contract decision:

Zero data retention is the row that catches teams out, because it is the only one of the three that no console setting finishes on its own. GMI Cloud's published Privacy Notice covers information collected from visitors to the website. The service-side retention behavior of your endpoint is a per-deployment configuration plus a contract term, which is exactly what the prompt is asking for when it says "agreed in the contract."

Where can a Prime Inference endpoint run?

A Prime Inference endpoint can run in Asia-Pacific, North America, or Europe, and the product page publishes the current list grouped into those three areas:

• Asia-Pacific: Tokyo, Singapore, Taiwan
• North America: U.S. West, East, Central, and South
• Europe: EU partner data centers, for "residency and compliance-sensitive workloads"

The page also carries a footnote worth bringing to the first call: "Regions currently offered. If your workload requires a specific region, we can accommodate requests case by case, subject to capacity availability." For a regulated workload, that footnote is the agenda item, not a disclaimer. If your rule names a country that is not in the list above, ask about it directly, because capacity placement is a conversation GMI Cloud runs case by case.

There are two different things you can ask for, and they are not interchangeable:

• Region-pin places the endpoint close to your users. The product page frames it as a first-token latency decision.
• Region-lock is the data residency decision. It is the one your legal reviewer cares about, and it is the one that has to reappear in the order form, because the SLA ties the word "Region" to the facility described in that order.

When the deployment is created in the Console, the region is a field in the wizard alongside the model, GPU type, and scaling configuration, per GMI Cloud's documentation for dedicated endpoints. Pick it there, then make sure the same facility is named in the paperwork.

For the wider jurisdiction question, including why a regional selector alone does not settle sovereignty, GMI Cloud has a separate write-up: Data Residency for AI Workloads.

What does the GMI Cloud SLA actually commit to, clause by clause?

The GMI Cloud SLA commits to >= 99.9% monthly uptime for instances spread across two or more Regions and >= 99% for instances in a single Region, starts its downtime clock at one consecutive minute of GPU inaccessibility, and pays service credits denominated in GPU-hours. That is specific enough to model before you sign, which is what a compliance review wants. Here is the clause-level read, with the published language.

Two things follow from the credit math. First, because credits are denominated in GPU-hours, the math is computable before you sign: on an endpoint running 8 GPUs, a two-hour Downtime Period produces 8 x 2 = 16 service credit hours. Credits offset service fees, so at the published H200 starting rate of from $3.20 per GPU-hour as of October 2026 (GMI Cloud pricing), 16 GPU-hours offsets roughly $51 of spend. Second, that number tells you what the SLA is for. It is an availability commitment with a defined remedy, which is what an auditor needs to see. It is not the control that protects your data. The controls that do that are the region lock, the single tenancy, and the retention clause.

One more caution for the review deck: the 99.9% and 99% figures above are the contractual numbers from the legal document. GMI Cloud's About page separately reports 99.99% platform availability as an operating statistic, and the Prime Inference page carries a 99.9% uptime label with the footnote that "Uptime SLA is determined by GPU series and deployment configuration" and that committed SLAs vary by contract. Quote the legal document in the filing and keep the other two numbers out of it.

Does locking to one region cost you the 99.9% tier? Run the math first

Yes: under the published SLA, a single-Region deployment sits in the >= 99% tier rather than the >= 99.9% one, and the arithmetic decides whether that should change your design. The higher tier attaches to "Instances in Multiple Regions," defined as "container instances hosted as part of Services where instances are placed across two or more Regions." One facility, one tier.

In a 30-day month of 43,200 minutes, the two tiers allow very different outages:

Before you accept the lower tier, check one thing in the definitions. The SLA defines a Region as a facility "denoted by physical location, such as FET and CHT as may be updated by Company from time to time". Its own examples are facility denotations, not countries. That means two qualifying Regions can sit inside one jurisdiction. If your residency rule names a country or a regulatory territory rather than a specific building, a second facility inside the same territory can get you to the 99.9% tier without breaking residency. Ask GMI Cloud which facilities in your jurisdiction count as separate Regions, and have the answer written into the Order.

If a second in-jurisdiction facility is available, size the decision honestly. A second warm Prime Inference replica of an 8-GPU H200 deployment, held for a full month at the published starting rate of $3.20 per GPU-hour, works out as follows, using 730 hours as the monthly average (8,760 hours divided by 12):

8 GPUs x $3.20/GPU-hour x 730 hours = $18,688 per month

Set that against the credit math from the previous section: a qualifying two-hour outage on one 8-GPU endpoint earns 16 service credit hours, worth roughly $51 against your bill. Buy the second region for availability and failover, never to chase the SLA tier. If residency is tight and your service runs comfortably inside the >= 99% allowance, a single-region Prime Inference deployment is the correct and cheaper design. If the model sits in a customer-facing critical path, the second replica pays for itself in avoided incidents, not in service credits.

Prime Inference also has an elastic behavior you should explicitly rule in or out in writing. The product page describes "One global pool": "When your home region hits capacity, traffic borrows from the next-closest region to keep latency low and service continuous." That is a useful property for a latency-sensitive consumer workload and the wrong property for a region-locked regulated one. Region-lock is the control that answers it, and the exact behavior for your endpoint is a question for the Order rather than an assumption: for a region-locked regulated endpoint, state in writing that cross-region overflow is disabled, and if your residency rule does allow it, name the regions that qualify.

How does zero data retention get written down?

Zero data retention gets written down in two places at once: a zero-retention serving configuration on the deployment, and a retention clause in the Order that states what the configuration covers. Start from the distinction that matters to an auditor. Zero-retention serving means prompt content is not kept after the response is produced. GMI Cloud states it plainly for single-tenant deployments: "retention policy can be configured per deployment, including zero-retention serving where prompt content is not persisted after response generation."

Three separate artifacts need separate answers, and a single sentence saying "we do not retain data" covers none of them cleanly:

1. Prompts and completions. The zero-retention configuration itself. Confirm it applies to both directions, not just the request side.
2. Request logs and metadata. Timestamps, token counts, and model IDs are typically retained for billing and operations even when payloads are not. Name a retention period for them.
3. Model weights at rest. Your fine-tuned weights are loaded from Hugging Face, S3, or your own storage onto the reserved GPUs. Specify where the serving copy lives, who can read it, and what happens to it when the deployment is archived.

The published SLA supports this conversation in two places. Its customer data clause grants GMI Cloud a license to handle Customer Data "solely and exclusively for the purpose of providing the Services to Client", which is the purpose limitation your reviewer is looking for. Its data incident clause commits to notification "promptly and without undue delay" after GMI Cloud becomes aware of a data security incident. Neither clause sets your retention period, which is why the retention term belongs in the Order alongside the region.

On certifications, keep the filing to what is published: GMI Cloud lists SOC 2 and ISO 27001 on its About page under enterprise support and compliance certifications. Request the current report scope and date from the sales team rather than inferring either.

Seven clauses to put in the Order

The Order has to bind seven things: the named facility, the reserved GPU count, the retention policy, audit log handling, the downtime definition and uptime tier, the service credit mechanics, and change control. This is the checklist to hand to whoever is drafting. Each row names the GMI Cloud document the clause can be anchored to, so the redline cycle starts from published language instead of from scratch.

Rows 5, 6, and 7 are already answered by the public SLA, so they usually survive redline untouched. Rows 1, 3, and 4 are the ones that need explicit text drafted around your Prime Inference deployment. Row 2 is the one your finance team will recognize, because reserved capacity shows up as a line item rather than as a policy statement.

What the deployment looks like once the paperwork is signed

Once the Order is signed, going live on Prime Inference is four steps: register the fine-tuned weights, choose GPU type and count and region, launch, and operate. The engineering side is short, which is the point of a managed tier. Prime Inference takes the weights you already produced and runs them on reserved GPUs with per-model runtime tuning handled by GMI Cloud's inference team, on serving engines including vLLM, TensorRT-LLM, and SGLang, with no re-engineering of your serving layer.

1. Register the model. The fine-tuned weights you already produced become the deployment target, loaded from the storage you keep them in today.
2. Choose the setup. GPU type, GPU count per replica, replica count, and target region.
3. Deploy. Launch from the Console, CLI, or API. A deployment moves through Queued, Deploying, and Running, and can later be Stopped or Archived. GMI Cloud's documentation for dedicated endpoints is explicit that billing applies only to the period of time a deployment spends in Running status.
4. Operate. Reserved GPUs stay warm with weights pre-loaded, so there is no cold start between calls, and rate limits follow your dedicated capacity rather than a shared pool.

Prime Inference bills hourly per GPU with no minimum contract, per-token markup, or shared-pool surge pricing. Seasonal and annual reservations offer lower rates. October 2026 starting rates are H100 $2.60, H200 $3.20, and B200 $5.00 per GPU-hour. Most production workloads use H100/H200; quote model-specific capacity and contract clauses in the applicable Order. (pricing page)

FAQ

Can GMI Cloud host a model our own team fine-tuned? Yes. Supply custom or proprietary weights from Hugging Face, S3, or private storage. GMI operates the endpoint and tunes its serving stack; ownership of the weights remains with the customer.

Is zero data retention on by default, or does it have to be negotiated? It requires both configuration and an Order clause. Itemize prompts, completions, request logs, and the serving copy of the weights; a product-page capability alone does not establish the deployment's retention terms.

What uptime does GMI Cloud commit to if we lock everything to one region? The published SLA is at least 99% monthly uptime in one Region or 99.9% across two or more Regions: 432 versus 43.2 minutes in a 30-day month. A Region means a facility, not a country; check whether multiple qualifying Regions fit the required jurisdiction.

How are service credits calculated if the endpoint goes down? Credits equal affected GPUs × qualifying downtime; the SLA's example is five GPUs for twelve hours, or 60 credit-hours. Downtime requires at least one consecutive minute of inaccessibility and must satisfy the separate qualifying definition. Submit incident details, failure logs, timing, duration, and affected-instance evidence within 60 days after the event month's end. Credits are capped at that month's affected-service fee and expire two months after availability.

Which regions can a Prime Inference endpoint run in? Listed options include Tokyo, Singapore, Taiwan, U.S. West/East/Central/South, and EU partner facilities. Other requests are case-by-case and capacity-dependent; name the required jurisdiction during evaluation.

Do we have to move off GMI Cloud's serverless API to get this? No. Keep evaluation and other suitable traffic on MaaS while moving workloads that need dedicated isolation to Prime Inference under the same GMI account.

Next step

If a review board has handed you a fixed region, a single-tenant requirement, and a retention clause, the fastest path is to bring all three to the same conversation. Read the published Service Level Agreement so your legal team starts from real language, check current GPU rates on the pricing page, then contact GMI Cloud with your model, your traffic profile, and the jurisdiction you have to stay inside. We will come back with the region options, the reserved-capacity sizing, and the contract terms in one pass.