vLLM eller TGI: 24 ganger mer kapasitet møter lavere haleforsinkelse

Velg vLLM som første kandidat når mange forespørsler skal betjenes samtidig, og mål TGI særskilt hvis en interaktiv bruker først og fremst venter på starten av svaret. En studie med LLaMA-2 på NVIDIA A100 målte med vLLM 0.6.1 og TGI 2.3.0 opptil 24 ganger høyere tokengjennomstrømning for vLLM ved 200 samtidige forespørsler; ved moderat last hadde TGI lavere p99-tid til første token, mens vLLM hadde lavere p99-tid til ferdig svar.

For en ny tjeneste taler både høylastresultatet og prosjektets videre utvikling for å begynne med vLLM. Hugging Faces TGI-dokumentasjon oppgir at TGI er i vedlikeholdsmodus, begrenser videre arbeid til mindre feilrettinger og vedlikehold og anbefaler blant annet vLLM og SGLang fremover. Den beskriver også kontinuerlig batching og PagedAttention i TGI, så disse teknikkene alene forklarer ikke forskjellen i den eldre testen. En eksisterende TGI-tjeneste kan likevel ha en målbar fordel for sin egen trafikk.

Første token og ferdig svar er ulike mål

Ved strømming merker brukeren pausen før det første tokenet kommer. Tid til første token er derfor nyttig for chat og annen interaktiv bruk. Total svartid måler når hele svaret er klart, og er viktigere når et program ikke kan gå videre før genereringen er fullført. En motor kan starte raskt og likevel avslutte sent hvis resten av tokenene produseres langsommere.

Haleforsinkelse beskriver de tregeste forespørslene, ofte ved p95 eller p99, i stedet for et gjennomsnitt som kan skjule dem. Den må alltid knyttes til en bestemt måling: p99 for første token og p99 for ferdig svar kan peke mot hver sin motor. For lange strømmede svar er også tiden mellom tokenene relevant. Rykkvis tekst etter en rask start kan gi en annen brukeropplevelse enn målet for første token antyder.

Samtidighet avgjør hvilken fordel som teller

Gjennomstrømning er produksjonen av forespørsler eller tokener over tid. Høy gjennomstrømning er verdifull når batchjobber, evalueringer eller flere API-kunder skal dele GPU-kapasitet. En tjeneste med få samtidige brukere kan i stedet prioritere ventetiden for hver forespørsel. Derfor er arbeidslasten et bedre utgangspunkt for valget enn ett samlet fartsresultat.

• Ved interaktiv enkeltbruk: sammenlign tid til første token og tid til ferdig svar under lav og moderat last. TGI er en reell kandidat hvis fordelen gjelder den delen av ventetiden brukeren faktisk merker.
• Ved batcharbeid: mål tokener per sekund og hvor lang tid hele køen tar. vLLM er første kandidat når samlet produksjon veier tyngst.
• Ved høy samtidighet: mål gjennomstrømning sammen med køtid og p99-latens. Høy produksjon hjelper lite dersom forespørsler overskrider tjenestens krav til svartid nær metning.
• Ved blandet trafikk: kjør interaktive forespørsler mens batchjobbene pågår. Kapasitet eller køer som skilles etter jobbtype, kan være mer nyttig enn å velge én motor ut fra en ren batchtest.

Forskjellen mellom lastprofilene er også en grense for hva studien kan si om en ny tjeneste. Et resultat ved stor samtidighet beskriver ikke automatisk en chat med sporadiske spørsmål, og en rask start ved moderat last sier ikke hvor mange forespørsler motoren tåler før køen vokser. Valget må gjelde den forventede trafikken og latenstidskravet samtidig.

Modell, maskinvare og GPU-minne

En hastighetsfordel er uten verdi hvis motoren ikke kjører den aktuelle modellen med riktig kontekstlengde og funksjoner. TGIs modelloversikt skiller mellom optimalisert støtte og modeller som kan forsøkes startet uten garantert ytelse. Kontroller derfor den konkrete modellvarianten, presisjonen og eventuelle krav til strukturert utdata før ytelsestall sammenlignes.

Maskinvaren setter en tilsvarende grense. vLLMs installasjonsoversikt oppgir blant annet NVIDIA CUDA, AMD ROCm og Intel XPU som støttede plattformer. Oppføringen sier at det finnes en installasjonsvei; den fastslår ikke at alle modeller, presisjoner og optimaliseringer oppfører seg likt på hver plattform. Studien brukte én bestemt GPU-familie, så resultatet må måles på nytt ved annen maskinvare.

Mål toppbruk av GPU-minne under belastning, ikke bare minnet som trengs for å laste modellvektene. Nøkkel- og verdibufferen vokser når flere forespørsler og lengre kontekster holdes aktive. En konfigurasjon som får plass i tomgang, kan derfor få mindre rom for samtidige svar enn et enkelt oppstartsforsøk antyder. For en stor modell kan tilgjengelig minne bli avgjørende før forskjellen i ren tokengjennomstrømning får betydning.

Vedlikehold og migreringskostnad

Vedlikeholdsmodus gjør fremtidige modellbytter og funksjonskrav til en del av motorvalget. Det er særlig relevant for en ny plattform som skal leve gjennom flere oppgraderinger. For en TGI-installasjon som allerede oppfyller kravene, kan det derimot være mer arbeid å bytte motor enn å beholde den en stund. Den målte latenstidsfordelen må veies mot sannsynligheten for at tjenesten senere trenger funksjoner som får begrenset videre utvikling i TGI.

Migreringsarbeidet ligger ofte i klientenes forventninger rundt motoren: strømmet svar, stoppsekvenser, strukturert utdata, feilhåndtering og driftsmålinger. En vellykket API-tilkobling viser bare at forespørselen når frem. Samme inndata bør også gi akseptabelt svarformat, og tjenesten må fortsatt oppfylle latenstidskravene under belastning. Dette er konkrete kostnader ved å flytte en fungerende tjeneste, selv når en annen motor ser raskere ut i en publisert test.

Slik gjentar du sammenligningen

En egen måling bør skille mellom latenstid og kapasitet fra starten. vLLMs benchmarkverktøy har egne målinger for latenstid i én batch, nettbasert gjennomstrømning og offline gjennomstrømning. Til en direkte sammenligning av motorene trengs dessuten samme lastgenerator og like forespørsler mot begge, slik at forskjeller i testklienten ikke blir forvekslet med forskjeller i serveren.

1. Frys modellfil og tokenizer, motorversjon, GPU, presisjon, kontekstgrense og genereringsinnstillinger. Registrer om svar strømmes, og om kvantisering eller andre optimaliseringer er aktivert.
2. Lag et utvalg som ligner trafikken tjenesten skal betjene, med relevante lengder på inndata og svar. Hold fordelingen lik mellom motorene. Varm opp begge før måleseriene, og skill kald oppstart fra stabil drift hvis oppstartstid betyr noe.
3. Kjør enkeltforespørsler, moderat last og forventet toppbelastning med samme ankomstmønster. Gjenta seriene og behold rådata. Ved blandet trafikk bør batchjobber være aktive også mens de interaktive forespørslene måles.
4. Rapporter fullførte forespørsler og tokener per sekund, tid til første token, tid til ferdig svar, p95 og p99 samt toppbruk av GPU-minne. Ta med avviste forespørsler og tidsavbrudd; ellers kan en motor se rask ut fordi krevende jobber ikke ble fullført.

Den aktuelle motoren er den som oppfyller kravene til både respons og kapasitet ved forventet belastning, med støtte for modellen og rom i GPU-minnet. Er målingene jevne, får vedlikeholdsstatus og kostnaden ved en overgang større vekt enn små forskjeller i gjennomsnittsfart.

Les også:

• Motion eller Reclaim: Oppgavelisten og kalenderen gir hver sin vinner
• Kit eller beehiiv: fire ganger større gratisliste møter bedre annonseverktøy
• Metricool eller Hootsuite: merkevarer og brukere gir ulik regning