Sammenligning af inferensservere: Open source-løsninger til AI-modeller

Hvad en inferensserver kan

En inferensserver stiller en allerede trænet AI-model til rådighed for forespørgsler. En applikation sender inddata til en API, hvor serveren videregiver dem til en modelkørsel, som behandler dem ved hjælp af de indlæste modelvægte. Resultatet sendes tilbage til applikationen via serveren. I tilfælde af en sprogmodel kan dette være et tekstsvar; afhængigt af grænsefladen kan det også udlæses trin for trin som en strøm af tokens.

Server, kørselsmiljø og model er forskellige komponenter. Vægtene indeholder de indlærte parametre; kørselsmiljøet udfører beregningerne på den tilgængelige hardware. Serveren organiserer derimod adgangen til og videresendelsen af forespørgslerne. Et skift af server erstatter derfor ikke automatisk modellen, men kan kræve et andet format eller et andet kørselsmiljø.

Til brugeradministration og forretningslogik er der som regel behov for et ekstra applikationslag. Det afgør blandt andet, hvilke brugere der må sende en forespørgsel, hvilke data der sendes til modellen, og hvordan modellens svar integreres i en arbejdsgang. En tilgængelig model-API alene afspejler ikke disse regler; også adgangsbeskyttelse og logføring skal planlægges som en del af det samlede system.

En LLM-server, der er designet til tekstgenerering, er desuden ikke automatisk en platform til billedklassificering eller andre modeltyper. Til det formål skal den pågældende modelarkitektur og et passende kørselsmiljø understøttes. Triton følger en bredere tilgang: Den videresender forespørgsler til backend-systemer via modelrelaterede schedulere. Om en bestemt model kan køres der, afhænger dog stadig af, at der er et passende backend.

Kontroller model, hardware og rettigheder

Start udvælgelsen med opgaven og en konkret Modelrevision: En chatmodel, en embedding-model og en billedklassifikator stiller forskellige krav. Notér desuden det anvendte vægtformat, og kontroller, om den ønskede kørselstid understøtter netop denne arkitektur og revision. Et kendt modelnavn er ikke i sig selv tilstrækkeligt til at antage kompatibilitet eller ensartede resultater.

• Angiv opgave, modelrevision og tilgængeligt vægtformat.
• Kontroller CPU eller GPU, tilgængelig hukommelse, drivere og det nødvendige backend.
• Brugsrettigheder til servere, modelvægte og yderligere komponenter skal afklares separat.
• Dokumenter forventede forespørgselslængder, parallelitet og krav til adgangsbeskyttelse.

Valget af hardware handler om mere end blot, om der er en GPU til rådighed. Vægte skal sammen med kørselstid og yderligere data kunne rummes i den tilgængelige hukommelse; også drivere og backend skal passe til platformen. Tritons backend-dokumentation påpeger, at ikke alle backends understøttes på alle platforme. Kontroller derfor kombinationen af serverversion, model, backend og hardware, i stedet for at udlede understøttelsen ud fra produktnavnet.

Formatet kan også indskrænke udvalget: Ifølge projektdokumentationen kræver llama.cpp modeller i GGUF-format. For andre formater beskriver projektet en konvertering; det betyder dog ikke, at enhver arkitektur eller modelvariant fungerer uændret. Kildekoden findes i udviklingsgrenen. Inden en implementering bør du derfor sammenligne oplysningerne med den valgte udgivelse.

En open source-server overfører ikke sin licens til modelvægtfilerne. Kontroller for hver af dem separat, om den planlagte interne eller kommercielle anvendelse er tilladt, og hvilke betingelser der gælder. Det faktum, at vægtfilerne kan downloades, er i sig selv ikke en tilladelse til enhver form for brug eller videreformidling.

Hvordan LLM-forespørgsler belaster ressourcerne

Når der indtastes en tekstforespørgsel, behandler modellen først indtastningen. Denne fase kaldes Forudfyldning. Derefter genererer den i afkodningsfasen svaret token for token. En kort prompt og et langt svar flytter en anden del af arbejdet over til genereringsfasen end et langt dokumentuddrag med et kort svar. Begge tilfælde bør derfor indgå i kapacitetsplanlægningen.

Under genereringen gemmer kørselsmiljøet midlertidige data i KV-cache for at sikre, at allerede behandlet kontekst kan udnyttes i de efterfølgende trin. Dette hukommelsesbehov kommer oven i modelvægtningerne og varierer afhængigt af sekvensernes længde og antallet af forespørgsler, der behandles samtidigt. Selv om modellen alene kan være i hukommelsen, er det ikke ensbetydende med, at den forventede belastning også kan rummes der.

Continuous Batching samler løbende genereringsanmodninger på en fleksibel måde i stedet for blot at afvente en fast, fælles batch. PagedAttention organiserer KV-cache-hukommelsen i blokke. Begge metoder beskrives for vLLM og kan forbedre ressourceudnyttelsen. Hvor stor en hjælp de er, afhænger dog blandt andet af forespørgselstørrelser, parallelitet og hardware; det er derfor ikke muligt at konkludere, at de udgør en fordel for enhver arbejdsbyrde.

Triton beskriver derimod en generel serverarkitektur: En modelbaseret scheduler modtager forespørgsler og videresender dem til det relevante backend. Dynamisk batching kan konfigureres for en model. Dette betyder ikke, at hvert backend internt behandler LLM-forespørgsler på samme måde eller anvender de samme lagringsmetoder som vLLM. Til sammenligningen er det derfor den konkrete kombination af backend og model, der er afgørende.

For en intern chattjeneste er et enkelt tal for tokens pr. sekund derfor ikke tilstrækkeligt. Ud over udgivelseshastigheden påvirker tiden indtil det første token og ventetiderne ved samtidige anmodninger brugeroplevelsen. Sammenlign kandidater med repræsentative indgangs- og udgangslængder samt samme parallelitet, inden du træffer en beslutning om hardware.

Sorter de fire løsninger, og noter SGLang som et alternativ

Følgende oversigt klassificerer vLLM, llama.cpp, Triton og TGI ud fra deres dokumenterede tilgange. Den er ikke en sammenligning af funktioner eller ydeevne baseret på specifikke udgivelser. SGLang forbliver et uevalueret alternativ: Hugging Face anbefaler det sammen med vLLM som efterfølger til TGI, men heraf kan man hverken udlede modelformater, grænseflader eller hardwareunderstøttelse for en bestemt SGLang-udgivelse.

Kildekoden indeholder midlertidige dokumentationssider og en udviklingsgren i llama.cpp. Der foreligger således ingen dokumentation for, at der er foretaget en afsluttet test af vLLM 0.10.2, llama.cpp b6000, Triton 25.10 eller TGI 3.3.7. Disse versionstilknytninger anvendes derfor ikke som sammenligningsgrundlag. Inden en implementering skal du kontrollere de nødvendige egenskaber for den faktisk valgte serverversion og modelrevision.

Den faktiske Driftsomkostninger afhænger blandt andet af modeludlevering, adgangsbeskyttelse og overvågning. Det er ikke muligt at udlede en direkte sammenligning af omkostningerne ud fra tabellen: En lokal enkeltinstallation og en platform med flere backends stiller forskellige krav. Undersøg derfor først, hvilke opgaver installationen rent faktisk skal udføre.

Hugging Face fører TGI i Vedligeholdelsestilstand og nævner vLLM og SGLang som alternativer. En eksisterende installation behøver derfor ikke straks at blive udskiftet. Ved nye projekter bør den begrænsede videreudvikling dog indgå i planlægningen; inden en migrering skal API-adfærd og modelkvalitet sammenlignes hver for sig.

Triton og vLLM udelukker ikke hinanden som udgangspunkt: Triton kan anvende et vLLM-backend. Det skal dog stadig kontrolleres, om en bestemt model fungerer med de valgte versioner og den eksisterende platform for denne kombination. Den generelle Triton-arkitektur i sig selv garanterer ikke understøttelse af ethvert backend på enhver platform.

Forberedelse af lokal prototype

Til en lokal prototype skal du først definere opgaven og nogle typiske indtastninger. Vælg derefter en konkret modelversion, der synes egnet til formålet, og tjek dens brugsbetingelser. Serverens licens alene angiver ikke, om du må downloade, ændre eller anvende modelvægtningerne til det påtænkte formål.

llama.cpp bruger formatet GGUF. Søg efter en passende GGUF-variant, eller kontroller, om udgangsmodellen kan konverteres med de dokumenterede værktøjer. Projektdokumentationen beskriver sådanne konverteringer på udviklingsgrenen; den er ikke et bevis på, at hver eneste ældre udgave understøtter enhver arkitektur eller konverteringsmulighed.

Kontroller inden download, om den valgte variant understøttes på din CPU eller GPU med det påtænkte backend, og om der er tilstrækkelig hukommelse til vægte og kørselstid. En kvantiseret variant kan reducere hukommelsesbehovet for vægtene. Sammenlign dog resultaterne med dine kvalitetskrav, i stedet for at antage, at den mindre fil giver uændrede resultater.

Vælg en konkret build til prototypen, og sammenlign installations- og serverindstillingerne med dokumentationen for denne. For den tidligere nævnte build b6000 findes der ingen dokumentation for en versionsspecifik test; den anbefales derfor ikke som et testet udgangspunkt. Den eksisterende modeldokumentation på udviklingsgrenen erstatter hverken serverdokumentationen for den valgte build eller dens kompatibilitetstest.

Start med at køre tjenesten lokalt og send flere repræsentative forespørgsler. Sammenlign ikke kun, om der kommer et svar, men også om indtastningsformatet, modellen og genereringsindstillingerne passer til din planlagte anvendelse. Et vellykket enkeltkald er hverken et bevis på, at tjenesten kan klare en større belastning, eller på kvaliteten af alle svarene.

Notér tre resultater hver for sig: den indholdsmæssige kvalitet ud fra dine testtilfælde, den oplevede responstid og den tid, det tager at downloade, konvertere og stille indholdet til rådighed. På den måde kan du for eksempel se, om en model, der er hurtigt sat op, er fagligt uegnet. Til separat administration af Linux-værten tilbyder Oversigt over 1Panel som serveradministrationsværktøj supplerende kontekst; et serverpanel erstatter ikke kontrollen af modellens kørselstid.

Planlægning af belastning og lagerbehov

I en intern chattjeneste varierer forespørgslerne ofte meget: Et kort spørgsmål med et kort svar kræver andre ressourcer end et langt dokumentuddrag med et udførligt svar. Du bør derfor registrere typiske og større indtastnings- og udskriftslængder samt det forventede antal samtidige brugere. Et enkelt vellykket opkald giver ikke et tilstrækkeligt billede af situationen under belastning.

Hukommelsesbehovet består ikke kun af modellernes størrelse. Kørselstid og mellemværdier kræver også plads; ved parallelle LLM-forespørgsler stiger behovet desuden for KV-cache. Længere kontekster og flere samtidigt behandlede forespørgsler kan derfor bringe en konfiguration til dens grænse, selvom vægtene i sig selv kan rummes i den tilgængelige hukommelse.

Continuous Batching og PagedAttention er dokumenterede tilgange inden for vLLM til håndtering af igangværende forespørgsler henholdsvis cache-hukommelsen. De overtager dog ikke kapacitetsplanlægningen for dig: Hvilken kombination af parallelitet og kontekstlængde der er praktisk anvendelig, afhænger af modellen, hardwaren og den valgte konfiguration. Man kan ikke udlede en generel ydelsesforbedring for enhver arbejdsbelastning ud fra dette.

En simpel mængdeberegning kan hjælpe med forberedelsen: 100 hypotetiske anmodninger med hver 200 udstedelsestokens giver tilsammen 20.000 udstedelsestokens. Det er ingen måling af gennemstrømningen. Uden oplysninger om tidsperiode, indtastningslængder, parallelitet og andre driftsdata kan der hverken udledes noget om antallet af tokens pr. sekund eller om omkostningerne.

For at kunne foretage en senere sammenligning skal du oprette en testmatrix med model og revision, kvantisering, serverversion, hardware og tilgængelig hukommelse. Varier indgangs- og udgangslængden samt paralleliteten på en kontrolleret måde. Registrer tiden indtil det første token, udgangshastigheden og fejlraten; vurder svarets kvalitet separat ud fra de samme testtilfælde. Genereringsparametre og chat-skabeloner skal også medtages i protokollen, så forskelle forbliver sporbare.

Sikker og overvåget drift af API’er

En tilgængelig Inference-server er endnu ikke en sikker tjeneste. Begræns i første omgang netværksadgangen til de systemer, der skal sende forespørgsler eller administrere serveren. Ved ekstern adgang skal der være en adgangsbeskyttelse placeret foran API’et; kontroller i den forbindelse alle tilgængelige endepunkter og ikke kun ruten til tekstgenerering.

Advarsel: Ifølge dokumentationen beskytter vLLM’s API-nøgle-indstilling ikke alle slutpunkter. En indstillet nøgle erstatter derfor hverken netværksadskillelse eller en forudgående adgangskontrol, der også tager højde for administrative og andre tilgængelige grænseflader. Test reglerne fra de respektive netværk, inden du frigiver tjenesten.

Prompts og svar kan indeholde fortrolige oplysninger. Du bør derfor på forhånd fastlægge, hvilke data der overhovedet skal logges, hvem der må se dem, og hvornår de skal slettes. Til fejlfinding er tekniske oplysninger som tidspunkt, modelversion, fejltype og forespørgselens varighed ofte tilstrækkelige; du bør kun registrere det fulde indhold, hvis der er et begrundet behov herfor.

Die Observerbarhed bør ventetid, tid indtil det første token, udleveringshastighed og fejl registreres separat. Hvis ventetiden for eksempel stiger ved samtidige forespørgsler, mens de enkelte svar kører hurtigt efter start, tyder det på en anden flaskehals end en langsom tokenudlevering. Vurder disse nøgletal sammen med forespørgselsstørrelser og parallelitet.

Administrationsværktøjer kan samle opgaver og ansvarsområder i forbindelse med driften af de underliggende værter. Til separat valg af dette administrationsniveau leverer Sammenligning af ISPConfig og Froxlor supplerende kontekst. Valget af et serverpanel er en selvstændig infrastrukturbeslutning; et sådant panel erstatter hverken sikringen af model-API’en eller overvågningen af inferenstjenesten.

Indsnævre fejlen og migrere TGI

Hvis en model ikke starter, skal du først kontrollere modelversionen og formatet i forhold til den valgte kørselstid. I llama.cpp er GGUF det krævede format; en konvertering alene beviser dog ikke, at den konkrete arkitektur og opgave fungerer. Derefter skal du afklare, om det valgte backend og hardwarekombinationen understøttes, og om der er tilstrækkelig hukommelse til rådighed.

Hvis serveren starter, men leverer uventede chat-svar, skal du kontrollere det Chat-skabelon og de overførte genereringsparametre. En OpenAI-kompatibel grænseflade betyder ikke, at alle parametre implementeres på samme måde: vLLM-dokumentationen angiver også parametre, der ikke understøttes eller ignoreres. Sammenlign derfor de faktisk anvendte indstillinger og ikke kun formen på API-kaldet.

For en eksisterende TGI-tjeneste begynder migreringen med en statusopgørelse: Her indgår modelrevision, anvendte API-kald, sampling-indstillinger og krav til svarets kvalitet. Hugging Face kører TGI i vedligeholdelsestilstand og nævner blandt andet vLLM og SGLang som alternativer. Det gør det værd at overveje et skifte, men betyder ikke, at eksisterende installationer straks vil gå ned.

Byg den Målinstallation Opdel dem og sammenlign de to tjenester med de samme repræsentative inddata, uddatalængder og belastningsforhold. Ud over svarets kvalitet og fejl skal du også kontrollere, om klienterne kan håndtere den nye grænseflade og dens parametre. Skift først trafikken over, når resultaterne er acceptable for den påtænkte anvendelse, og der er forberedt en tilbagevej.

Vejledningen til Hugging Faces-inferensendepunkter anbefaler ligeledes, at man opretter et nyt endepunkt og udfører testkald, inden man skifter over. Dette er en nyttig fremgangsmålsmodel til planlægning, men ikke en universel trin-for-trin-vejledning til selvdrevne installationer: Netværk, implementering og trafikstyring kan være organiseret anderledes i disse tilfælde.

Vælg den rette arkitektur

For en lokal prototype er llama.cpp et oplagt udgangspunkt, når der foreligger en egnet GGUF-model og passende hardwareunderstøttelse. Dette udgør dog ikke en anbefaling af en bestemt build. Det afgørende er ikke kun, om serveren starter: Sammenlign også kvaliteten af den ønskede opgave, responstiden og indsatsen for modelvægtningerne. Model- og backend-understøttelse skal stadig testes for den konkrete kombination.

Til en intern chattjeneste kan vLLM komme i betragtning som testkandidat: Den dynamiske dokumentation beskriver en OpenAI-kompatibel chatgrænseflade med den nødvendige chat-skabelon. Der foreligger således ingen test for version 0.10.2. SGLang forbliver her et ikke-vurderet alternativ fra TGI-dokumentationen; uden en teknisk test af den aktuelle version kan det ikke sammenlignes på lige fod.

En platform til billedmodeller og sprogmodeller stiller andre krav end et enkelt chat-endepunkt. Triton er et testpunkt på grund af sine modelbaserede schedulere og backends, selvom version 25.10 ikke er blevet verificeret her. Denne arkitektur gør, at Backend-support Hvad angår det afgørende detalje: Ikke alle backend-systemer understøttes på alle platforme, og hver enkelt model, der skal bruges, skal testes i den konkrete kombination.

Når du skal træffe beslutningen, skal du tage højde for modelrevision, serverversion, hardware, backend og brugsrettigheder. Sammenlign derefter kvalitet, svartider under forventet belastning samt omkostningerne til sikkerhed, opdateringer og fejlfinding. En løsning, der er tilstrækkelig til et lokalt forsøg, kan kræve yderligere infrastruktur, hvis der er flere brugere eller modeltyper; en generel rangliste ville skjule disse forskelle.