Modelservering (model serving)

En stak til modelservering har genkendelige lag. Nederst ligger en inferensmotor, der ejer GPU'en: den indlæser vægte, håndterer KV-cachen, planlægger forespørgsler og kører optimerede kernels. Udbredte LLM-motorer er vLLM, SGLang, NVIDIA TensorRT-LLM og llama.cpp; generelle servere som NVIDIA Triton Inference Server kan huse mange modeltyper i én proces. Ovenover ligger et API-lag, meget ofte en OpenAI-kompatibel HTTP-grænseflade med server-sent events til streaming, derefter en gateway eller router, der står for autentificering, kvoter, routing mellem modeller og logning, og et orkestreringslag (fx Kubernetes med KServe), der placerer replikaer på GPU-noder og skalerer dem.

Den afgørende teknik for LLM'er er continuous batching, også kaldet planlægning på iterationsniveau, som blev introduceret med Orca-systemet (Yu m.fl., OSDI 2022). Klassisk statisk batching venter på, at en batch bliver fyldt, og holder alle pladser, indtil den længste sekvens er færdig; continuous batching optager og afslutter sekvenser i hvert decode-trin og holder dermed GPU'en beskæftiget, selv om svarlængderne varierer meget. Sammen med sidebaseret styring af KV-cachen, prefix caching, chunked prefill (opdeling af lange prompter, så de ikke blokerer igangværende decode) og speculative decoding hæver det typisk gennemløbet flere gange i forhold til naiv servering. Store installationer adskiller i stigende grad prefill og decode på separate GPU-puljer, fordi den første er compute-bound og den anden memory-bound.

Modeller, der er større end én GPU's hukommelse, deles op. Tensorparallelisme fordeler hvert lags matricer over GPU'er i en node og kræver en hurtig interconnect; pipelineparallelisme placerer på hinanden følgende lag på forskellige enheder; ekspertparallelisme fordeler eksperterne i mixture-of-experts-modeller. Kapaciteten bestemmes af hukommelsen: vægte plus KV-cache til den ønskede samtidighed og kontekstlængde skal kunne ligge der med plads til aktiveringer. Autoskalering er sværere end for tilstandsløse webtjenester, fordi en kold start indebærer at hente ti- eller hundredvis af gigabyte vægte og varme kernels op, så driften holder varme puljer, skalerer på kødybde eller KV-cache-udnyttelse frem for CPU og sætter eksplicitte grænser for kontekst- og svarlængde.

Driftshensynene rækker ud over hastighed. Det er i serveringslaget, at service level objectives håndhæves (percentiler for TTFT og TPOT, fejlrate), at modelversioner rulles ud med canaries og rulles tilbage, og at observability registrerer tokens, latens og omkostning pr. lejer. Det er også en sikkerhedsgrænse: prompter og svar er ofte personoplysninger eller fortrolige data, så logning, opbevaring, dataplacering og isolering af caches mellem lejere skal designes bevidst, og endpointet skal have rate limiting og autentificering som ethvert andet API. Modelservering adskiller sig fra træning ved at være en løbende tilgængelig, latensfølsom produktionstjeneste frem for et batchjob, og for en udbredt model kan den over levetiden koste mere, end træningen gjorde.