vLLM eller TGI? Ved høj belastning kan forskellen blive 24-dobbelt

Ved høj samtidighed er vLLM det stærkeste udgangspunkt, hvis målet er flest genererede tokens fra den samme GPU. I et forsøg med LLaMA-2-7B på én NVIDIA A100 80GB leverede vLLM op til 24 gange TGI’s gennemløb ved 200 samtidige forespørgsler, mens TGI fik det første token hurtigere frem ved let, interaktiv trafik. Forskellen er et resultat fra den afprøvede konfiguration, ikke en fast egenskab ved alle modeller og GPU’er.

For et nyt system trækker kapacitetsbehovet derfor ofte mod vLLM, men en eksisterende chat med få samtidige brugere kan have større glæde af TGI’s korte ventetid på svarets begyndelse. Hugging Faces TGI-vejledning angiver samtidig, at projektet er i vedligeholdelsestilstand, og anbefaler blandt andet vLLM eller SGLang til nye Inference Endpoints. Det ændrer vurderingen af et langsigtet valg, selv når den nuværende TGI-installation opfylder sine svartidskrav.

Hvad fortæller gennemløbstallet?

Gennemløb beskriver, hvor meget arbejde serveren afslutter på tværs af alle forespørgsler. Når mange brugere genererer svar samtidig, kan motorens håndtering af aktive sekvenser, kø og GPU-hukommelse afgøre, hvor mange tokens installationen producerer. Det gør høj samtidighed særlig relevant for en fælles model-API eller en tjeneste med store belastningstoppe.

En enkeltbrugerchat stiller et andet spørgsmål: Hvor længe venter den enkelte på et synligt svar? Et højt samlet gennemløb kan godt følges af en mærkbar kø for nogle brugere. Omvendt kan en server starte ét svar hurtigt uden at have størst kapacitet, når mange svar skal genereres på samme tid.

Forsøgets resultat bør også holdes inden for dets arbejdsprofil. Modelstørrelse, GPU, præcision, længden af input og ønsket svarlængde påvirker alle, hvor mange forespørgsler der kan være aktive. Lange input bruger kapacitet, før svaret begynder, mens lange output holder plads i hukommelsen under genereringen. En måling af tokens pr. sekund fra en anden model eller en anden fordeling af promptlængder besvarer derfor ikke samme kapacitetsspørgsmål.

Første token kan vinde, selv om hele svaret taber

Tiden til første token og tiden til et færdigt svar måler forskellige dele af oplevelsen. I en strømmet chat ser brugeren svarets begyndelse, før modellen er færdig; her er en kort startventetid værdifuld. En baggrundsproces, som først bruger resultatet, når hele svaret er modtaget, har mere gavn af kort samlet svartid.

Det afprøvede TGI-setup havde en fordel for starten på interaktive svar, mens vLLM klarede færdiggørelsen bedre under den målte moderate belastning. Det er grunden til, at en påstand om den hurtigste server kræver en præcis latenstidsmåling. Teamet bør skelne mellem første token, hastigheden mellem efterfølgende tokens og tidspunktet for sidste token, især når svarene varierer meget i længde.

Gennemsnittet skjuler desuden de langsommere forespørgsler. p95 for første token viser startventetiden i den tunge ende af fordelingen, mens p95 for hele svaret viser, hvor længe de langsommere afslutninger tager. Hvis køen vokser under en spids, kan begge mål ændre sig, selv om gennemløbet fortsat ser højt ud. Den nyttige kapacitet er derfor den trafik, serveren kan gennemføre, mens produktets krav til svartid stadig er opfyldt.

GPU-hukommelse sætter grænsen for samtidighed

En models vægte optager kun en del af GPU-hukommelsen. Aktive forespørgsler kræver også plads til deres kontekst under genereringen, og længere kontekster eller flere samtidige sekvenser øger presset. Tomgangsforbrug alene siger derfor lidt om, hvorvidt en installation kan klare spidsbelastningen uden kø eller afvisninger.

Hugging Faces vLLM-konfiguration beskriver blandt andet grænser for samtidige sekvenser og tokens i en batch samt valget mellem at fordele modelvægte over flere GPU’er og at køre flere modelkopier. De indstillinger påvirker både den tilgængelige hukommelse og den trafik, installationen kan behandle. Samme antal GPU’er er derfor ikke nødvendigvis samme ressourcefordeling.

For en rimelig sammenligning skal begge motorer bruge samme modelvægt, præcision og GPU-type samt ens grænser for input og output. Notér batchgrænser, kvantisering og fordeling over GPU’er sammen med resultaterne. En ændring, der giver plads til flere aktive anmodninger, kan også påvirke latenstiden eller den kontekstlængde, applikationen kan tilbyde. Det er den brugbare kapacitet inden for disse grænser, der er relevant for valget.

Sådan testes serverne på virksomhedens trafik

Begynd med et anonymiseret udsnit af faktiske anmodninger, hvor fordelingen af korte og lange input samt ønskede svarlængder er bevaret. Kør samme belastning gennem samme klient mod begge motorer på ens hardware. Start med let interaktiv trafik, øg derefter samtidigheden til den forventede spids, og hold model og genereringsindstillinger faste mellem kørslerne.

Registrér gennemførte forespørgsler og genererede tokens pr. sekund sammen med tid til første token, p95 for det færdige svar og maksimalt GPU-hukommelsesforbrug. Medtag fejl, afvisninger og køtid, så et højt tokenantal ikke skjuler forespørgsler, som brugerne ikke fik svar på. Gentag belastningen efter opvarmning og se på spredningen mellem kørslerne frem for at lade ét godt resultat afgøre valget.

vLLM’s benchmarkværktøjer omfatter måling af latenstid for en batch, gennemløb ved online-servering samt kold og varm opstart. Ved en direkte sammenligning skal begge servere dog belastes fra samme måleklient med samme anmodninger. Opstartstid er et særskilt mål for tjenester, der skalerer ned mellem belastningstoppe; den bør ikke blandes sammen med gennemløbet fra en allerede varm server.

Kompatibilitet og migration kan afgøre valget

Et nyt endpoint er kun en reel erstatning, hvis applikationens kald og svar fungerer som forventet. Kontrollér derfor de anvendte modeller, svarformater, streaming, tokenbegrænsninger og eventuelle funktioner, som applikationen er afhængig af. Test både normale forespørgsler og dem, der ligger tæt på grænserne for inputlængde og samtidighed.

På Hugging Face Inference Endpoints kan motoren på et eksisterende endpoint ikke skiftes direkte. En overgang fra TGI kræver et nyt endpoint med vLLM, testkald og derefter flytning af trafikken; den gamle rute kan først pauses eller slettes efter overgangen. For en selvhostet installation afhænger selve trafikskiftet af teamets egen infrastruktur, men en parallel kørsel giver mulighed for at sammenholde kapacitet, latenstid og svarformat under samme belastning.

Høj samtidighed og behov for fremtidig videreudvikling gør vLLM til et oplagt første valg at afprøve. Hvis TGI allerede leverer den ønskede interaktive svartid, bør en flytning bygge på målt gevinst eller et konkret kompatibilitetsbehov. Beslutningen falder dér, hvor den valgte motor både kan bære virksomhedens spidstrafik og levere den svartid, brugerne faktisk mærker.

Læs også:

• GitHub Actions eller GitLab CI? Samme pipeline kan tage dobbelt så lang tid
• Kickstarter eller Indiegogo? Små bidrag gør samme 5 pct. forskellige
• Tech-ETF eller enkeltaktier? 143 selskaber kan stadig være koncentreret