Model serving

Hvad er model serving?

Model serving er at tage en færdigtrænet AI-model og gøre den tilgængelig for brug. Det er broen mellem “vi har en god model” og “brugere kan bruge den.”

Tænk på det som forskellen mellem at lave en opskrift i dit køkken og at drive en restaurant. At træne en model er at perfektionere opskriften. Model serving er at åbne restauranten: sikre at retten kan serveres til hundredvis af gæster samtidig, konsistent, hurtigt og uden nedbrud.

Når du sender en besked til ChatGPT, sker der model serving i baggrunden: din forespørgsel modtages af en server, sendes til den rette GPU, modellen genererer et svar, og svaret streames tilbage til dig. Alt dette (routing, load balancing, GPU-allokering, fejlhåndtering, skalering) er model serving.

Hvorfor er model serving vigtigt?

1. Det er flaskehalsen. Du kan have verdens bedste model, men hvis den ikke kan serves pålideligt og hurtigt, skaber den ingen værdi. Model serving afgør om brugerne oplever en hurtig, pålidelig tjeneste eller en langsom, ustabil en.
2. Økonomi. GPU’er er dyre. Effektiv model serving (at udnytte GPU’erne maksimalt) er forskellen mellem en rentabel og en tabsgivende AI-tjeneste.
3. Skalerbarhed. En model i et Jupyter notebook håndterer én bruger. Model serving i produktion skal håndtere tusindvis eller millioner af samtidige brugere.
4. Pålidelighed. Nedetid er uacceptabelt for produktionstjenester. Model serving inkluderer redundans, failover og health checks for at sikre høj tilgængelighed.

Fra træning til serving

Rejsen fra trænet model til produktion:

1. Træning. Modellen trænes på en GPU-klynge over uger eller måneder. Resultatet er et sæt modelvægte. En stor fil (gigabytes til terabytes).
2. Optimering. Modellen optimeres til inference: quantization (lavere præcision), compilation (TensorRT, ONNX) og eventuelt pruning.
3. Packaging. Modellen pakkes med sin kode, afhængigheder og konfiguration. Typisk i en Docker-container.
4. Deployment. Containeren deployes til en server med GPU’er. Model serving-frameworket starter og loader modellen i GPU-hukommelsen.
5. Endpoint. Et API-endpoint oprettes så applikationer kan sende forespørgsler til modellen.
6. Monitorering. Systemer overvåger latency, throughput, fejlrate og GPU-udnyttelse løbende.

Nøglekoncepter i model serving

Request routing

Når en forespørgsel ankommer, skal den dirigeres til den rette model på den rette server:

1. Load balancing. Fordel forespørgsler jævnt mellem flere GPU-servere for at undgå overbelastning.
2. Model routing. Hvis flere modeller er tilgængelige (f.eks. Haiku, Sonnet, Opus), sendes forespørgslen til den korrekte model.
3. Rate limiting. Begræns antal forespørgsler per bruger for at beskytte systemet og sikre fair adgang.

Batching

Saml flere forespørgsler og processér dem sammen:

1. Static batching. Saml N forespørgsler og processér dem som én batch. Simpelt men ineffektivt. Alle venter på den langsomste forespørgsel.
2. Dynamic batching. Saml forespørgsler der ankommer inden for et kort tidsvindue (f.eks. 10ms) og processér dem sammen.
3. Continuous batching. Den mest avancerede teknik: nye forespørgsler indsættes løbende i en kørende batch efterhånden som andre afsluttes. Maksimerer GPU-udnyttelse.

Scaling

Tilpas kapaciteten efter behov:

1. Horizontal scaling. Tilføj flere servere med GPU’er når belastningen stiger.
2. Vertical scaling. Brug kraftigere GPU’er (opgradér fra A100 til H100).
3. Autoscaling. Automatisk tilpasning af antal servere baseret på aktuel belastning. Skalér op i spidsbelastning, ned i stille perioder.
4. Scale to zero. For sjældent brugte modeller: luk serverne helt ned og start dem igen når en forespørgsel ankommer. Sparer penge men tilføjer cold start-latency.

Caching

Genbrug resultater for at spare compute:

1. Response caching. Gem svar for identiske forespørgsler. Hvis 100 brugere stiller det samme spørgsmål, beregnes svaret kun én gang.
2. KV-cache. Gem mellemresultater fra modellens beregninger. Afgørende for effektiv token-generering i sprogmodeller.
3. Prefix caching. Genbrug beregninger for identiske prompt-prefixes (f.eks. system prompts der er ens for alle forespørgsler).

Serving-frameworks

vLLM

Det mest populære open source framework til LLM serving:

1. PagedAttention. Intelligent hukommelseshåndtering der eliminerer spild og tillader flere samtidige forespørgsler.
2. Continuous batching. Maksimal GPU-udnyttelse via løbende indsættelse af nye forespørgsler.
3. Quantization-support. Kør modeller i lavere præcision for hurtigere inference.
4. OpenAI-kompatibelt API. Drop-in erstatning for OpenAIs API. Nemt at skifte fra cloud til self-hosted.

TGI (Text Generation Inference)

Hugging Faces serving-framework:

1. Optimeret til Hugging Face-modeller. Sømløs integration med Hugging Faces modelbibliotek.
2. Tensor parallelism. Fordel store modeller over flere GPU’er automatisk.
3. Grammars og structured output. Garanter at output følger et bestemt format (JSON, etc.).

NVIDIA Triton Inference Server

Enterprise-grade serving fra NVIDIA:

1. Multi-framework. Understøtter PyTorch, TensorFlow, ONNX, TensorRT og mere i samme server.
2. Multi-model. Kør mange forskellige modeller på samme server med intelligent ressource-deling.
3. Ensemble. Kæd flere modeller sammen i en pipeline (f.eks. tokenizer → model → postprocessing).
4. Optimeret til NVIDIA hardware. Tæt integration med CUDA og TensorRT.

TensorRT-LLM

NVIDIAs optimerede LLM-runtime:

1. Maksimal ydeevne. Kompilerer modeller til optimerede CUDA-kernels for maksimal hastighed på NVIDIA GPU’er.
2. Inflight batching. NVIDIAs implementation af continuous batching.
3. Quantization. Avancerede quantization-teknikker (INT4, FP8) for hurtigere inference.

Ollama

Simplified serving til lokal brug:

1. Enkel installation. ollama run llama3, det er alt der kræves.
2. Modelbibliotek. Kurateret samling af optimerede modeller klar til download.
3. API. Lokalt REST API der er kompatibelt med mange applikationer.
4. Ikke til produktion. Designet til personlig og udviklingsbrug, ikke til at serve tusindvis af brugere.

Model serving i praksis

Startup der bygger en AI-chatbot

1. Vælger Claude API (Anthropic) som model-backend. Ingen serving at håndtere selv.
2. Bygger applikationslogik oven på API’et.
3. Betaler per token og skalerer automatisk med brugertal.
4. Overvejer self-hosted serving (vLLM + open source-model) når volumenet gør API-prisen for høj.

Virksomhed der hoster egen model

1. Fine-tuner Llama 70B på proprietære data.
2. Optimerer modellen med quantization (INT4 via GPTQ).
3. Deployer via vLLM på en klynge af 4x H100 GPU-servere.
4. Sætter autoscaling op: minimum 2 servere, maksimum 8 ved spidsbelastning.
5. Monitorerer latency, throughput og GPU-udnyttelse via Prometheus + Grafana.

AI-udbyder i stor skala

1. Kører hundredvis af GPU-servere med forskellige modeller (small, medium, large).
2. Intelligent routing sender simple forespørgsler til små, hurtige modeller og komplekse til store.
3. Continuous batching maksimerer GPU-udnyttelse til 80-95%.
4. Geografisk distribuerede datacentre for lav latency globalt.
5. Redundans og failover sikrer 99.9%+ oppetid.

Udfordringer

1. Cold start. At loade en stor model i GPU-hukommelse tager sekunder til minutter. Problematisk for scale-to-zero setups.
2. GPU-hukommelse. Store modeller fylder meget. En 70B-model i FP16 kræver ~140GB GPU-hukommelse. Mere end én GPU kan tilbyde.
3. Tail latency. De fleste forespørgsler er hurtige, men nogle er langsome (lange outputs, komplekse prompts). At sikre konsistent latency er svært.
4. Multi-tenancy. At serve flere kunder på samme hardware uden at de påvirker hinandens ydeevne kræver omhyggelig isolation.
5. Modelopdateringer. At rulle en ny modelversion ud uden nedetid (rolling deployment) er komplekst med GPU-baseret infrastruktur.
6. Omkostning. GPU-servere koster $10.000-100.000+ per måned. Ineffektiv serving brænder penge.

Metrics og monitorering

De vigtigste tal at overvåge:

1. Latency (P50, P95, P99). Mediantiden og worst-case svartider. P99 under 5 sekunder er typisk et mål for LLM’er.
2. Throughput. Tokens per sekund eller forespørgsler per minut. Bestemmer kapacitet og omkostning.
3. GPU-udnyttelse. Hvor stor en andel af GPU’ens kapacitet der bruges. Over 80% er godt, under 50% er spild.
4. Fejlrate. Procent forespørgsler der fejler. Bør være under 0.1%.
5. Queue depth. Antal ventende forespørgsler. Stigende kø indikerer kapacitetsproblemer.
6. Time to First Token (TTFT). Tiden fra forespørgsel til første token genereres. Afgørende for brugeroplevelsen.