Implementeer ML-modellen in productie met automatische schaling

De kloof bij productie-implementatie: waarom de meeste ML-modellen het notebook nooit verlaten

Een getraind model in een notebook en een model dat live verzoeken beantwoordt, zijn verschillende technische problemen. Het tweede is een implementatieomgeving met vereisten voor beschikbaarheid, latentie en schaling, en dit is waar de meeste machine learning-modellen in productie vastlopen.

Wat er nodig is om een model op schaal te serveren (cluster, ingress, autoscaling, monitoring)

Modelselectie en training zijn upstream-problemen. Het klassieke pad om modellen in productie te serveren is een apart proces, een proces dat een cluster, een ingress-controller, een schaalbeleid, een monitoring-stack en een release-pipeline vereist. Elk is een beslissing die een eigenaar vereist. Een data scientist die de modelontwikkeling heeft afgerond, heeft nu cluster-netwerken, load balancing-regels en een metrics-backend nodig voordat één gebruiker een voorspelling ziet.

De checklist: een container-runtime, ingress-regels, schaalbeleid, secrets- en databeheer, log-shipping, release-pipelines, plus een toolchain om elk te onderhouden. Elk item is essentieel, vereist technisch eigenaarschap en geen van deze tools verbetert het model.

Voor een klein team is dat weken werk voordat er enige bedrijfswaarde verschijnt, en het stopt niet bij de lancering. Het resultaat is bekend: modelontwikkeling slaagt, de implementatie loopt vast en het artefact wacht op infrastructuur waar niemand tijd voor heeft om te bouwen.

Waarom doe-het-zelf VM + Flask + nginx bezwijkt onder echt verkeer

De kortere weg is een VM die een Flask-app achter nginx draait. Het werkt in tests en faalt in productie. Eén server is één storingspunt. Geen automatische schaling betekent dat een piek in de belasting verzoeken in de wachtrij plaatst totdat de latentie onacceptabel is. Geen rolling release betekent dat elke nieuwe versie downtime betekent.

Het verbergt ook een kostenprobleem: de instantie draait continu, of het endpoint nu duizend verzoeken per dag bedient of geen, en iemand moet nog steeds het besturingssysteem patchen en certificaten vernieuwen. Efficiënt om op te zetten, duur om te onderhouden.

De verborgen kosten van inactieve GPU-instanties op endpoints van hyperscalers

Beheerde inference-endpoints op de grote hyperscalers lossen de beschikbaarheid op, maar houden de compute-instantie de klok rond draaiende. Een GPU-endpoint dat is gedimensioneerd voor een piek overdag, wordt om 3 uur 's nachts nog steeds gefactureerd terwijl er niets te bedienen valt, en de meeste tijd van de dag is het inactief.

Benutting is de maatstaf die ertoe doet. Een endpoint dat een paar duizend verzoeken per dag bedient op een GPU die is gedimensioneerd voor de piek, kan elke dag, maandenlang, slechts een fractie gebruiken van waarvoor het betaalt. Cloud GPU-instanties zijn logisch wanneer de belasting constant is, maar een instantie per uur is de verkeerde eenheid voor vraag die in pieken binnenkomt.

Facturatie per replica, per minuut in plaats van altijd actieve instanties

Facturering is per replica, per minuut. Een deployment die 's nachts één replica en 's middags acht replica's bevat, kost de som van de minuten dat elke replica heeft gedraaid, niet acht instanties gedurende 24 uur. Facturering voor autoscaling wordt berekend op basis van het minimumaantal replica's dat u definieert; u betaalt alleen voor de piekcapaciteit terwijl deze draait. Prognoses zijn eenvoudig: uw basis is het minimum vermenigvuldigd met de tijd, alles daarboven volgt de vraag en de softwarefactuur behoudt de vorm van de belastingscurve.

Indicatieve tarieven: CPU vanaf slechts €0,04 per core per uur voor klassieke modellen zoals scikit-learn of XGBoost; GPU L4 vanaf €0,91 per replica per uur voor 7B-inferentie, vision en classificatie; GPU A100 rond €1,52 tot €1,85 voor 7B tot 30B; GPU H100 PCIe vanaf €3,10 voor grotere modellen en lange contextvensters. Bevestig de huidige tarieven op de prijspagina.

Schalen naar nul wanneer het verkeer afneemt, opschalen bij echte pieken

Schalen naar nul is algemeen beschikbaar: een implementatie daalt automatisch naar nul replica's wanneer er geen aanroepen zijn, en de kosten bij inactiviteit worden nul. Dat is het belangrijkste economische verschil tussen een schaalbaar beheerd eindpunt en een vaste instantie die u zelf beheert. Het heeft een eerlijke afweging. Terugkeren vanuit nul betekent een koude start terwijl de container opstart en gewichten laadt, dus het eerste verzoek na inactiviteit is traag. Voor een batchtaak of interne tool is dat acceptabel. Voor een gebruikersgerichte applicatie met een latentiebudget, behoudt u minimaal één replica en accepteert u de minimale kosten.

Statische schaling vs. autoscaling (CPU/RAM) vs. autoscaling op basis van aangepaste statistieken

Drie schaalstrategieën, en de keuze volgt uw verkeerspatroon.

Readiness probes en rolling upgrades zonder downtime

Een readiness probe is een HTTP-pad dat het platform pollt voordat het verkeer naar een replica stuurt. Zo zorg je ervoor dat het model klaar is: wijs het naar je /health-route en het eindpunt stuurt geen verzoek door totdat het model is geladen. Zonder dit neemt een replica een verzoek aan terwijl de gewichten worden geladen en geeft het een foutmelding die je client ziet als een mislukt verzoek.

Rolling upgrades gebruiken dezelfde controle. Push een nieuwe versie en pas de update toe, en nieuwe replica's doorstaan de readiness-check voordat oude worden beëindigd. Gebruikers zien geen mislukte verzoeken en een versie die niet door de probe komt, ontvangt nooit verkeer. Elke versie is adresseerbaar, dus dagelijkse releases en een nood-rollback delen één mechanisme.

Live monitoring van GPU, CPU en netwerk per replica

Het dashboard stelt een live set statistieken per replica bloot: een GPU-statistiek, een geheugenstatistiek en een netwerkstatistiek, elk gericht op één replica in plaats van gemiddeld, naast applicatielogs in het Configuratiescherm.

Die set beantwoordt of de implementatie gezond is, of de schaalstatistiek wordt geactiveerd en waar de latentie zich bevindt. Het beantwoordt niet of voorspellingen nog steeds correct zijn. Daarvoor heb je een applicatiestatistiek nodig die je zelf definieert, waarbij nauwkeurigheid op een gelabelde steekproef de gebruikelijke keuze is. Teams die modellen in productie onderhouden, delen meestal één dashboard tussen data science en platform engineering, zodat beiden dezelfde cijfers zien. Deze monitoringfunctie is standaard op elke app.

Stap 1: Verpak het model in een Docker-image (of gebruik een vooraf gebouwde)

Containerisatie is een vereiste, geen optionele extra. De container-image kan afkomstig zijn van Docker Hub, van Managed Private Registry, of van GitHub Packages. Drie vereisten zijn van belang: maak de werkruimtemap aan in de Dockerfile, richt je op linux/amd64 en serveer op poort 8080, tenzij je expliciet een andere declareert, zoals vLLM doet op 8000.

Teams zonder container-expertise kunnen beginnen met de OVHcloud-catalogus van vooraf gebouwde images met PyTorch, TensorFlow, HuggingFace of FastAI al geïnstalleerd. Dat vermindert het werk; het neemt de vereiste niet weg. Machine learning op deze manier implementeren is een efficiënte standaard voor de meeste applicaties, en ML-modellen direct vanuit een catalogus-image implementeren is nog sneller, en de ervaring van het onderhouden van je eigen basislaag is in het begin zelden de moeite waard.

Stap 2: Configureer resources, schaling en toegang via het Configuratiescherm, de API of de ovhai CLI

Maak de implementatie aan vanuit het Configuratiescherm, de API of de ovhai CLI. Kies je rekenresources, stel de schaalstrategie in, wijs de readiness probe naar je health-pad en poort, en stel vervolgens in hoe het eindpunt wordt bereikt.

Bij toegang geldt één regel: een openbaar eindpunt is alleen voor testdoeleinden. Productie-implementaties maken gebruik van beperkte toegang, met AI Platform-gebruikersreferenties of een token, en toegangsbeleid dat je zelf beheert. Elk eindpunt bevindt zich ook achter native DDoS-beveiliging en elk eindpunt behoudt zijn eigen inloggegevens.

ovhai app run --gpu 1 --default-http-port 8080 \
  --probe-path /health \
  --unsecure-http false \
  my-registry/my-model-server:v2

Stap 3: Kies de juiste schaalstrategie voor je verkeerspatroon

Stem het beleid af op de workload. Constante interne scoring: statisch, één of twee replica's, een efficiënte standaard voor interne applicaties en tools met een laag volume. Een klantgerichte API met dagelijkse pieken: automatisch schalen op basis van een gebruiksmetriek, minimaal één replica om koude starts te voorkomen. Incidentele batch-scoring: automatisch schalen met schalen naar nul. Batchwerk is waar die beslissing het makkelijkst is, omdat niemand naar een voortgangsbalk kijkt. Elke batch-run is een kostenpost die je al hebt ingecalculeerd.

Stel het maximum bewust in. Het beperkt tegelijkertijd de doorvoer en de factuur, en het plafond is 10 replica's per app.

Stap 4: Monitor inferentie met het dashboard en de MKS-referentiearchitectuur

Begin met het ingebouwde dashboard voor resourcemetrieken en logs. Voeg voor latentiepercentielen, doorvoer of nauwkeurigheid op modelniveau een externe stack toe: Managed Kubernetes Service die Prometheus en Grafana draait en je eindpunt scrapt. OVHcloud publiceert dit als een referentiearchitectuur.

Twee zaken om continu te monitoren: infrastructuursignalen die u vertellen of schalen werkt, en modelprestaties in productie, die u vertellen of het model zijn werk nog doet. Prestatiebewaking op het tweede punt is wat een stille regressie opvangt, en prestatiemetrieken uit een trainingsdataset zullen u hier niet voor waarschuwen. Drift verschijnt in het tweede punt lang voordat het in het eerste verschijnt. Exporteer een week aan onlinemetrieken naar een bestand voordat u een drempelwaarde optimaliseert, om ervoor te zorgen dat de wijziging de waargenomen belasting volgt. Stel op elk punt een waarschuwing in om ervoor te zorgen dat een regressie naar voren komt uit uw eigen inzichten in plaats van via een klant, zorg dat de drempelwaarde gebaseerd is op een reële basislijn en zorg dat er een eigenaar is.

Stap 5: Push een nieuwe versie met een rolling upgrade zonder downtime

Bouw en push de nieuwe versie, voer daarna ovhai app update uit of pas de wijziging toe vanuit het Configuratiescherm. Het platform start nieuwe replica's, wacht op gereedheid, verplaatst het verkeer en trekt de oude in. Geen downtime, geen onderhoudsvenster.

De Dockerfile is code: houd deze in versiebeheer en houd de basis bijgewerkt, aangezien een verouderde basislaag een veelvoorkomende oorzaak is van een mislukte uitrol. Houd tags voorzien van versienummers in plaats van 'latest' te hergebruiken. Versiebeheer op elke versie maakt van een rollback een operatie met één commando in plaats van een onderzoek.

Waarom CPU/RAM een slechte indicator is voor LLM-belasting

Deep learning-inferentie is een computationele werklast met een wachtrij, geen CPU-gebonden lus, dus de standaardpraktijk van schalen op hardware werkt niet goed. Een LLM-server verwerkt gelijktijdige verzoeken in batches op de GPU. Het CPU-gebruik blijft laag terwijl de wachtrij groeit, waardoor die drempelwaarde te laat of nooit wordt geactiveerd. Het signaal waar het om gaat is hoeveel verzoeken er in behandeling zijn, en een hardwaremetriek kan dat niet zien.

Schalen op vllm:num_requests_running met Prometheus en Grafana op MKS

vLLM stelt vllm:num_requests_running bloot op zijn metrics-eindpunt. Schraap het met Prometheus en schaal automatisch op die waarde in plaats van op een hardware-proxy. Replicas arriveren wanneer de werkelijke gelijktijdigheid stijgt en vertrekken wanneer de wachtrij leegloopt, waardoor de latentie binnen het budget blijft zonder overprovisioning.

Algemeen beschikbaar en gedocumenteerd als referentiearchitectuur. Het heeft Prometheus en Grafana nodig naast je implementatie, dus beschouw het als de geavanceerde aanpak, niet als de standaard.

Installatietijd, inactieve kosten en operationele expertise

Zelfbeheerde inferentie betekent het inrichten van het cluster, node pools, een ingress-controller en een horizontale autoscaler, doorgaans één tot twee weken, plus DevOps- en MLOps-expertise om het draaiende te houden. Jij bent eigenaar van de schaalbeleidsregels, implementatiepijplijnen, manifestbestanden en monitoringstrategieën, en je blijft er eigenaar van na de lancering. Best practices in het veld zijn gedocumenteerd en de tools zijn volwassen, maar in dit vakgebied is een gedocumenteerde praktijk geen robuust draaiend systeem. De GPU-node draait meestal continu, ook bij nul verkeer.

AI Deploy heeft één image en één commando nodig. De installatie duurt minder dan een uur, MLOps-expertise alleen is voldoende en schalen naar nul elimineert inactieve kosten volledig.

Prijzen en cijfers zijn indicatief. Controleer de actuele tarieven op de OVHcloud-prijspagina voordat u publiceert.

Geen blootstelling aan de CLOUD Act voor inference-gegevens

Trainingsdata is niet de enige gevoelige input. Elk verzoek aan een productie-endpoint bevat gebruikers- of bedrijfsgegevens, elk verzoek wordt ergens gelogd, elk verzoek is een invoer die u niet hebt gekozen, en endpointverkeer is continu in plaats van een eenmalige overdracht. Als het endpoint draait bij een provider met het hoofdkantoor in de VS, vallen die gegevens onder de Amerikaanse jurisdictie, ongeacht de regio waar ze worden gehost.

OVHcloud is Europees, zonder Amerikaans moederbedrijf en zonder structurele blootstelling aan de CLOUD Act. Inference-gegevens blijven binnen de EU-jurisdictie onder EU-wetgeving.

AVG, HDS en ISO 27701 voor gereguleerde workloads

OVHcloud beschikt over ISO 27001, ISO 27017, ISO 27018 en ISO 27701, is SOC 2-gecertificeerd en heeft een HDS-certificering voor gezondheidsgegevens in Frankrijk, relevant voor medische inference. Verwerking binnen de EU vereenvoudigt een Data Protection Impact Assessment, en de privacyverplichtingen die u aan uw eigen gebruikers hebt toegezegd, worden eenvoudiger aan te tonen. Support kan een privacyvraag beantwoorden zonder deze te escaleren.

Eén grens om duidelijk te stellen: AI Deploy levert soevereine serving-infrastructuur. Verplichtingen op modelniveau onder de EU AI Act, modelkaarten, auditlogs en biasdetectie blijven uw verantwoordelijkheid als systeemontwikkelaar. Soevereine infrastructuur ondersteunt compliance; het levert deze niet.