Cloud Model Serving

Cloud model serving turns a trained model into a scalable API. Training gives you a file of weights; serving puts those weights behind an endpoint that takes requests and returns predictions — and handles the GPUs, batching and scaling so you don't.

Where you meet it

Any "AI feature" in a product — search, recommendations, classification, image tagging.
An LLM chat or completion endpoint answering thousands of users at once.
Managed platforms (SageMaker, Vertex AI) and dedicated engines (Triton, vLLM, TGI).

What it does

It exposes a POST /predict-style endpoint. A request comes in, the model runs a forward pass, a prediction goes back — wrapped in the operational layer real traffic needs: batching, autoscaling, versioning and monitoring. The model is the engine; serving is the car around it.

The model is the engine; serving is the car around it. Batching, scaling and versioning are where production lives — or breaks.

How it works

You register a trained model, point a serving runtime at it, and get a URL. The serving layer does the heavy lifting:

Dynamic batching — incoming requests are grouped on the fly so the GPU processes many at once instead of one at a time, raising throughput.
Autoscaling — replicas scale with traffic (some platforms down to zero), so you pay for load, not for idle.
Versioning — models are tagged v1, v2, … so you can roll forward or back without touching clients.

LLMs need more than plain batching. Engines like vLLM and TGI use PagedAttention (KV-cache memory managed in pages, like virtual memory) and continuous batching — new requests join the running batch token-by-token instead of waiting for the slowest one to finish. That can lift throughput by an order of magnitude at similar latency.

Watch out

Latency vs throughput. Bigger batches mean more predictions per second but more wait per request. Tune the trade-off to your SLA, don't max one blindly.
GPU cost is the bill. Idle GPUs burn money. Watch utilization; right-size the instance and the batch.
Cold starts. Scale-to-zero is cheap but loading a multi-GB model into GPU memory takes seconds — bad for spiky, latency-critical traffic.
A model is not a product. Pre/post-processing, input validation, versioning and rollback, and monitoring for drift all live around the model — not in it.

Go deeper

Cloud Model Serving macht aus einem trainierten Modell eine skalierbare API. Training liefert dir eine Datei mit Gewichten; Serving stellt diese Gewichte hinter einen Endpoint, der Requests entgegennimmt und Vorhersagen zurückgibt — und der die GPUs, das Batching und die Skalierung übernimmt, damit du es nicht musst.

Wo es vorkommt

Jedes "KI-Feature" in einem Produkt — Suche, Empfehlungen, Klassifikation, Bild-Tagging.
Ein LLM-Chat- oder Completion-Endpoint, der tausende Nutzer gleichzeitig bedient.
Managed-Plattformen (SageMaker, Vertex AI) und dedizierte Engines (Triton, vLLM, TGI).

Was es tut

Es stellt einen Endpoint im Stil POST /predict bereit. Eine Anfrage kommt rein, das Modell rechnet einen Forward-Pass, eine Vorhersage geht zurück — eingebettet in die Betriebsschicht, die echter Traffic braucht: Batching, Autoscaling, Versionierung und Monitoring. Das Modell ist der Motor; Serving ist das Auto drumherum.

Das Modell ist der Motor; Serving ist das Auto drumherum. In Batching, Skalierung und Versionierung entscheidet sich die Produktion.

Wie es funktioniert

Du registrierst ein trainiertes Modell, richtest eine Serving-Runtime darauf aus und bekommst eine URL. Die Serving-Schicht macht die Schwerarbeit:

Dynamisches Batching — eingehende Requests werden zur Laufzeit gebündelt, sodass die GPU viele auf einmal statt einzeln verarbeitet, was den Durchsatz hebt.
Autoscaling — Replicas skalieren mit dem Traffic (manche Plattformen bis auf null), du zahlst für Last, nicht für Leerlauf.
Versionierung — Modelle werden mit v1, v2, … getaggt, sodass du vor- oder zurückrollst, ohne die Clients anzufassen.

LLMs brauchen mehr als plumpes Batching. Engines wie vLLM und TGI nutzen PagedAttention (KV-Cache-Speicher seitenweise verwaltet, wie virtueller Speicher) und Continuous Batching — neue Requests klinken sich Token für Token in den laufenden Batch ein, statt auf den langsamsten zu warten. Das kann den Durchsatz um eine Größenordnung steigern, bei ähnlicher Latenz.

Worauf achten

Latenz vs Durchsatz. Größere Batches bringen mehr Vorhersagen pro Sekunde, aber mehr Wartezeit pro Request. Tune den Trade-off auf dein SLA, statt eine Seite blind zu maximieren.
GPU-Kosten sind die Rechnung. Leerlaufende GPUs verbrennen Geld. Auslastung beobachten; Instanz und Batch passend dimensionieren.
Cold Starts. Scale-to-zero ist günstig, aber ein Multi-GB-Modell in den GPU-Speicher zu laden dauert Sekunden — schlecht bei spitzem, latenzkritischem Traffic.
Ein Modell ist kein Produkt. Pre-/Post-Processing, Input-Validierung, Versionierung und Rollback sowie Drift-Monitoring leben um das Modell herum — nicht darin.