OVHcloud separates managed model APIs from custom inference deployment

OVHcloud offers two useful entry points for AI applications: call a model through AI Endpoints, or deploy a custom container through AI Deploy. The first removes model-serving infrastructure from the application team’s work. The second provides more control over what runs. Model availability, data location and billing units determine which route fits.

01 / ProductThe managed catalog and the custom runtime solve different needs

AI Endpoints supplies access to supported language, embedding and other AI models through APIs. The application selects a model and supplies input while OVHcloud operates the serving infrastructure. This is useful when the required model and features already exist in the catalog.

AI Deploy exposes a different boundary: the customer supplies a container and selects CPU or GPU resources. OVHcloud manages deployment infrastructure, while the application team remains responsible for the container, model behavior and service design. It is the more relevant route when a catalog endpoint cannot run the desired application.

This coverage concerns OVHcloud’s infrastructure and inference services. Gladia’s September 2026 announcement describes a transaction involving OVH Groupe, OVHcloud’s parent, while retaining Gladia’s separate brand, API and customer relationship and noting closing conditions. That announcement is not evidence that Gladia’s transcription service is included in an OVHcloud AI Endpoints purchase.

The distinction protects the buying decision. A customer should evaluate the actual API or deployment service it will use, with its own model list, processing terms and bill. Corporate adjacency does not establish a combined technical integration or a shared entitlement.

02 / AudienceA defined processing job makes infrastructure choice easier

A team extracting structured fields from incoming business documents can begin with AI Endpoints if a supported model handles the required input and output. It needs a reliable application wrapper, but does not necessarily need to own model-serving software. Variable demand can make consumption billing attractive when long idle periods would leave dedicated hardware unused.

A team with a fine-tuned model, specialized preprocessing or an unsupported runtime should examine AI Deploy. More control can be worthwhile, but it adds container maintenance, startup behavior and capacity decisions. A custom runtime is useful when it satisfies an actual requirement that the managed catalog cannot meet.

The Mistral blueprint is a useful comparison when model selection and the model provider’s own services are central. The Hugging Face blueprint helps assess model artifacts and deployment routes. An identical model family name does not prove the same quantization, feature set, version or operating terms across providers.

OVHcloud’s European infrastructure positioning can also matter to procurement. The right question is which service, processing location and agreement cover the intended workload. A provider’s headquarters or a general sovereignty claim cannot by itself establish the treatment of every application dependency or customer-generated log.

03 / WorkflowA proposed document extractor validates meaning after validating JSON

Consider a proposed extractor for supplier delivery notes. The application receives an authorized document, identifies the relevant text and asks for a small schema containing supplier name, delivery reference, date and line items. Keep the original file and its identifier available to a human reviewer so uncertain fields can be checked against evidence.

Follow the getting-started guide to establish project access and an API key. Use an authenticated project route for the application. Anonymous examples may be convenient for experimentation but have tighter limits and do not form an appropriate production access design for business documents.

Choose a currently supported model with the required response format. The structured-output guide distinguishes ordinary text, a JSON-object mode and JSON-schema output. It directs readers to model-specific compatibility. Preserve the selected model identifier and schema together so later changes can be evaluated against the same examples.

Design the schema to represent missing information explicitly. A missing delivery date should remain missing rather than becoming today’s date because the application requires a value. Constrain the fields and types, but remember that a structurally valid response can still contain the wrong supplier or line-item quantity.

Validate the result in application code and compare important fields with the source. Route ambiguous identifiers, contradictory totals and unsupported file types to a person. If the next step creates an accounting or inventory record, require the normal approval process; the model’s output should be a proposed extraction rather than an unreviewed transaction.

The capabilities guide documents rate and payload limits. Authenticated requests are limited per project and model; most endpoint bodies have a default size limit, with different rules for some media types. Segment or preprocess documents according to the actual model constraints, and handle a 429 response with bounded backoff rather than duplicate downstream records.

Build a small queue with a stable job identifier and explicit states for received, processing, awaiting review and accepted. If a request fails, retain the original document reference and retry only the model step. This lets the team distinguish an infrastructure failure from a reviewer correction and prevents a successful retry from creating a second delivery entry.

Run proposed evaluations on unusual supplier layouts, incomplete scans and documents containing misleading instructions. Compare both extraction correctness and human review effort. A reduction in malformed JSON is useful, but the operational result depends on whether the fields a person approves are correct and traceable.

04 / PricingConsumption tariffs and container runtime charges need separate budgets

The public price list gives model-specific AI Endpoints units. The worldwide page consulted displays US-dollar prices excluding VAT, including distinct input and output token rates for language models. Use the customer’s applicable region and currency when purchasing; a worldwide listing is not a universal tax-inclusive invoice amount.

AI Deploy is billed for selected compute during documented lifecycle states rather than per inference call. Its billing guide identifies SCALING and RUNNING as billable phases and separates optional object storage and private registry costs. It also documents standby behavior when scale-to-zero is enabled, which should be evaluated against acceptable startup delay.

For the document extractor, estimate complete documents rather than isolated prompts. Text extraction, retries, storage and reviewer handling remain outside the headline model rate. If a custom deployment becomes attractive, compare its occupied compute time at representative throughput with the managed API’s consumption for the same accepted documents.

05 / DistinctionsThe product exposes useful control without requiring a custom serving stack

AI Endpoints combines a managed catalog with familiar API integration and structured output on compatible models. That can reduce the initial serving work for a developer who already knows how to build an application around an API. Its usefulness comes from the match between the chosen endpoint and the job, not simply from the number of models in a catalog.

AI Deploy provides an adjacent route for workloads that need a custom container. The same project can therefore make a deliberate decision between API consumption and compute operation. That flexibility is valuable when the team documents why a model or runtime requires the additional control.

The documented model lifecycle is another meaningful detail. A hosted model is an evolving dependency, so clear retirement notices and migration work matter to application continuity. A team that treats a model identifier as permanent can be surprised even while the cloud provider and the overall AI service remain active.

06 / QuestionsModel retirement is an immediate planning issue for new applications

The billing and lifecycle guide lists scheduled removals, including Mistral-7B-Instruct-v0.3 and Qwen3-Coder-30B-A3B-Instruct-FP8 on 1 October 2026. The proposed workflow should choose a supported alternative after evaluation rather than launch on a model already close to removal. A model remaining on a price page does not override a lifecycle notice.

The capabilities page describes processing infrastructure in Gravelines, France and states that data is not stored or shared during or after model use. Treat that as the vendor’s service statement and confirm the applicable agreement and route for sensitive workloads. Application storage, monitoring and upstream preprocessing need their own data handling decisions.

The product page also labels batch processing as beta and says it has no SLA while in beta. Use the established synchronous route for a workflow that depends on those terms, or explicitly accept the batch limitations. The existence of a lower-cost deferred mode does not make its operating commitments identical to the base service.

07 / DecisionChoose between a supported endpoint and a justified custom runtime

OVHcloud is worth evaluating when the application’s data location and model-serving responsibilities are explicit. Start with a supported catalog endpoint for a bounded job, keep a migration test set and monitor retirement notices. Choose AI Deploy when the runtime requirements justify operating a container and its capacity, with the different billing lifecycle clearly understood.