Jämförelse av inferensservrar: Öppen källkodslösningar för AI-modeller

Vad en inferensserver gör

En inferensserver tillhandahåller en redan tränad AI-modell för förfrågningar. En applikation skickar indata till en API, servern vidarebefordrar dem till en modellkörning, som bearbetar dem med de laddade modellvikterna. Resultatet skickas tillbaka till applikationen via servern. När det gäller en språkmodell kan detta vara ett textsvar; beroende på gränssnitt kan det även matas ut stegvis som en ström av token.

Server, runtime och modell är olika komponenter. Vikterna innehåller de inlärda parametrarna; runtime utför beräkningarna på den tillgängliga hårdvaran. Servern organiserar däremot åtkomsten till och vidarebefordran av förfrågningarna. Ett byte av server ersätter därför inte automatiskt modellen, men kan kräva ett annat format eller en annan runtime.

För användarhantering och affärslogik krävs oftast ett extra applikationslager. Det avgör till exempel vilka användare som får skicka en förfrågan, vilka data som skickas till modellen och hur modellens svar integreras i ett arbetsflöde. En tillgänglig modell-API räcker inte för att hantera dessa regler; även åtkomstskydd och loggning måste planeras in som en del av helhetssystemet.

En LLM-server som är utformad för textgenerering är dessutom inte automatiskt en plattform för bildklassificering eller andra modelltyper. För detta krävs stöd för respektive modellarkitektur och en lämplig runtime-miljö. Triton har ett bredare tillvägagångssätt: det vidarebefordrar förfrågningar till backend-system via modellspecifika schemaläggare. Om en specifik modell kan köras där beror dock på att rätt backend finns tillgänglig.

Kontrollera modell, hårdvara och rättigheter

Börja urvalet med uppgiften och en konkret Modellrevidering: En chattmodell, en inbäddningsmodell och en bildklassificerare ställer olika krav. Notera dessutom det aktuella viktformatet och kontrollera om den önskade körningsmiljön stöder just denna arkitektur och version. Ett känt modellnamn räcker inte i sig för att man ska kunna utgå från att kompatibilitet eller konsekventa resultat föreligger.

• Ange uppgift, modellrevidering och tillgängligt viktformat.
• Kontrollera CPU eller GPU, tillgängligt minne, drivrutiner och nödvändigt backend.
• Användarrättigheter för servrar, modellvikter och ytterligare komponenter ska klargöras separat.
• Dokumentera förväntad förfrågningslängd, parallellitet och krav på åtkomstskydd.

Valet av hårdvara handlar om mer än bara frågan om det finns ett grafikkort. Vikter måste rymmas i det tillgängliga minnet tillsammans med körningstid och ytterligare data; även drivrutiner och backend måste passa plattformen. Tritons dokumentation om backend påpekar att inte alla backend-lösningar stöds på alla plattformar. Kontrollera därför kombinationen av serverversion, modell, backend och hårdvara, istället för att utgå från produktnamnet när du bedömer stödet.

Formatet kan också begränsa urvalet: enligt projektdokumentationen kräver llama.cpp modeller i GGUF-format. För andra format beskriver projektet en konvertering; det innebär dock inte att varje arkitektur eller modellvariant fungerar utan ändringar. Källkoden finns i utvecklingsgrenen. Innan du genomför en driftsättning bör du därför jämföra uppgifterna med den valda versionen.

En öppen källkodsserver överför inte sin licens till modellvikterna. Kontrollera separat för båda om den planerade interna eller kommersiella användningen är tillåten och vilka villkor som gäller. Att vikterna kan laddas ner innebär i sig inte att de får användas eller vidarebefordras hur som helst.

Hur LLM-förfrågningar belastar resurserna

Vid en textförfrågan bearbetar modellen först indata. Denna fas kallas Förifyllning. Därefter genererar den svaret token för token i avkodningssteget. En kort prompt och ett långt svar innebär att en annan del av arbetet läggs på genereringen jämfört med ett långt dokumentutdrag med ett kort svar. Båda fallen bör därför beaktas i kapacitetsplaneringen.

Under genereringen lagrar runtime-miljön mellanliggande data i KV-cache för att redan bearbetat sammanhang ska kunna utnyttjas i efterföljande steg. Detta minnesbehov läggs till modellvikterna och varierar beroende på sekvensernas längd och antalet förfrågningar som bearbetas samtidigt. Att modellen ryms i minnet innebär inte nödvändigtvis att den förväntade belastningen också ryms där.

Continuous Batching sammanför löpande genereringsförfrågningar på ett flexibelt sätt, istället för att bara vänta på en fast gemensam kö. PagedAttention organiserar minnet i KV-cachen i block. Båda metoderna beskrivs för vLLM och kan förbättra resursanvändningen. Hur mycket de bidrar beror dock bland annat på förfrågningarnas storlek, parallellitet och hårdvara; det går därför inte att dra slutsatsen att de är en fördel för alla arbetsbelastningar.

Triton beskriver däremot en allmän serverarkitektur: En modellbaserad schemaläggare tar emot förfrågningar och vidarebefordrar dem till den ansvariga backenden. Dynamisk batchning kan konfigureras för en modell. Detta innebär inte att varje backend internt hanterar LLM-förfrågningar på samma sätt eller använder samma lagringsmetoder som vLLM. För en jämförelse är det därför den konkreta kombinationen av backend och modell som är avgörande.

För en intern chattjänst räcker det därför inte med en enda siffra för antalet token per sekund. Förutom utmatningshastigheten påverkar tiden till det första tokenet och väntetiderna vid samtidiga förfrågningar användarupplevelsen. Jämför kandidater med representativa in- och utmatningslängder samt samma parallellitet innan du fattar ett beslut om hårdvara.

Klassificera fyra lösningar, notera SGLang som ett alternativ

Följande översikt klassificerar vLLM, llama.cpp, Triton och TGI utifrån deras dokumenterade tillvägagångssätt. Den utgör inte någon jämförelse av funktioner eller prestanda kopplad till specifika versioner. SGLang förblir ett icke-värderat alternativförslag: Hugging Face rekommenderar det tillsammans med vLLM som efterföljare till TGI, men därifrån går det inte att utläsa vare sig modellformat, gränssnitt eller hårdvarustöd för en specifik SGLang-version.

Källkodsbasen innehåller dokumentationssidor som kan ändras samt en utvecklingsgren för llama.cpp. Det finns därför inga belägg för att någon fullständig testning har genomförts för vLLM 0.10.2, llama.cpp b6000, Triton 25.10 eller TGI 3.3.7. Dessa versionsmotsvarigheter används därför inte som jämförelseunderlag. Innan en driftsättning måste du kontrollera de nödvändiga egenskaperna för den faktiskt valda serverversionen och modellrevisionen.

Den faktiska Rörelsens kostnader beror bland annat på modelltillhandahållande, åtkomstskydd och övervakning. Det går inte att göra en direkt jämförelse av arbetsinsatsen utifrån tabellen: En lokal enskild installation och en plattform med flera backend-system har olika krav. Kontrollera därför först vilka uppgifter installationen faktiskt måste klara av.

Hugging Face leder TGI inom Underhållsläge och nämner vLLM och SGLang som alternativ. En befintlig installation behöver därför inte bytas ut omedelbart. För nya projekt bör man dock ta hänsyn till den begränsade vidareutvecklingen i planeringen; innan en migrering genomförs bör API-beteendet och modellkvaliteten jämföras separat.

Triton och vLLM utesluter inte varandra i princip: Triton kan använda ett vLLM-backend. Det måste dock ändå kontrolleras om en viss modell fungerar med de valda versionerna och den befintliga plattformen för just denna kombination. Den allmänna Triton-arkitekturen i sig innebär inte att varje backend stöds på varje plattform.

Förbereda den lokala prototypen

För en lokal prototyp ska du först fastställa uppgiften och några typiska indata. Välj sedan en specifik modellversion som verkar lämplig för detta och kontrollera dess användarvillkor. Serverns licens anger inte i sig om du får ladda ner, ändra eller använda modellvikterna för det avsedda ändamålet.

llama.cpp använder formatet GGUF. Leta efter en lämplig GGUF-variant eller kontrollera om utgångsmodellen kan konverteras med de dokumenterade verktygen. Projektdokumentationen beskriver sådana konverteringar på utvecklingsgrenen; den utgör inte något bevis för att varje äldre version stöder varje arkitektur eller konverteringsalternativ.

Kontrollera innan du laddar ner om den valda varianten stöds av din CPU eller GPU med det avsedda backend-systemet och om det finns tillräckligt med minne tillgängligt för vikter och körtid. En kvantiserad variant kan minska minnesbehovet för vikterna. Jämför dock resultaten med dina kvalitetskrav, istället för att dra slutsatsen att resultaten är oförändrade bara för att filstorleken är mindre.

Välj en specifik build för prototypen och jämför installations- och serverinställningarna med dokumentationen för den. För den tidigare nämnda builden b6000 finns här ingen dokumenterad versionsspecifik kontroll; den rekommenderas därför inte som en testad utgångspunkt. Den befintliga modelldokumentationen på utvecklingsgrenen ersätter varken serverdokumentationen för den valda builden eller dess kompatibilitetskontroll.

Starta tjänsten först endast lokalt och skicka flera representativa förfrågningar. Jämför då inte bara om ett svar visas, utan också om inmatningsformatet, modellen och genereringsinställningarna passar din planerade applikation. Ett lyckat enskilt anrop bevisar varken att tjänsten klarar högre belastning eller att alla svar är av hög kvalitet.

Notera tre olika resultat separat: kvaliteten på innehållet utifrån dina testfall, den upplevda svarstiden samt tidsåtgången för nedladdning, konvertering och tillhandahållande. På så sätt kan du till exempel se om en modell som snabbt har satts upp är olämplig ur ett fackmässigt perspektiv. För separat hantering av Linux-värden erbjuder Översikt över 1Panel som serverhanteringsverktyg kompletterande sammanhang; en serverpanel ersätter inte kontrollen av modellens körtid.

Planera belastning och lagringsbehov

I en intern chattjänst varierar förfrågningarna ofta kraftigt: En kort fråga med ett kort svar kräver andra resurser än ett långt dokumentutdrag med ett utförligt svar. Registrera därför typiska och större längder på in- och utdata samt det förväntade antalet samtidiga användare. En enskild lyckad förfrågan ger inte en tillräcklig bild av situationen under belastning.

Lagringsbehovet består inte bara av modellernas storlek. Körtider och mellanvärden kräver också utrymme; vid parallella LLM-förfrågningar ökar dessutom behovet av KV-cache. Längre sammanhang och fler samtidigt bearbetade förfrågningar kan därför pressa en konfiguration till dess gränser, även om vikterna i sig ryms i det tillgängliga minnet.

Continuous Batching och PagedAttention är dokumenterade metoder inom vLLM för hantering av pågående förfrågningar respektive cacheminnet. De tar inte över kapacitetsplaneringen åt dig: vilken kombination av parallellitet och kontextlängd som är praktiskt genomförbar beror på modellen, hårdvaran och den valda konfigurationen. Man kan inte dra slutsatsen att detta ger en generell prestandaförbättring för varje arbetsbelastning.

En enkel mängdberäkning underlättar förberedelserna: 100 hypotetiska förfrågningar med vardera 200 utdelningstoken ger sammanlagt 20 000 utdelningstoken. Det är ingen mätning av genomströmningen. Utan uppgifter om tidsperiod, inmatningslängder, parallellitet och övriga driftsdata kan man inte dra några slutsatser varken om antalet token per sekund eller om kostnaderna.

För en senare jämförelse skapar du en testmatris med modell och revision, kvantisering, serverversion, hårdvara och tillgängligt minne. Variera in- och utdatalängd samt parallellitet på ett kontrollerat sätt. Registrera tiden till det första tokenet, utmatningshastigheten och felfrekvensen; utvärdera svarskvaliteten separat utifrån samma testfall. Genereringsparametrar och chattmallar ska också ingå i protokollet så att skillnaderna förblir spårbara.

Att driva API på ett säkert och övervakningsbart sätt

En nåbar Inferensserver är ännu inte en säker tjänst. Begränsa först nätverksåtkomsten till de system som behöver skicka förfrågningar eller administrera servern. För extern åtkomst bör ett åtkomstskydd placeras före API:et; kontrollera då alla tillgängliga slutpunkter och inte bara vägen för textgenerering.

Varning: Enligt dokumentationen skyddar vLLM:s API-nyckelalternativ inte alla slutpunkter. En inställd nyckel ersätter därför varken nätverksavskiljning eller en uppströms åtkomstkontroll som även tar hänsyn till administrativa och andra tillgängliga gränssnitt. Testa reglerna från respektive nätverk innan du aktiverar tjänsten.

Frågor och svar kan innehålla konfidentiell information. Bestäm därför i förväg vilka uppgifter som ska loggas, vem som får ta del av dem och när de ska raderas. För felsökning räcker det ofta med tekniska uppgifter som tidpunkt, modellversion, feltyp och förfrågans varaktighet; du bör endast registrera fullständigt innehåll om det finns ett välgrundat behov.

Die Observerbarhet bör mäta väntetid, tid till första token, utmatningshastighet och fel separat. Om till exempel väntetiden ökar vid samtidiga förfrågningar, medan enskilda svar går snabbt efter att de har påbörjats, tyder detta på en annan flaskhals än en långsam tokenutdelning. Utvärdera dessa nyckeltal tillsammans med förfrågningsstorlekar och parallellitet.

För driften av de underliggande värdarna kan administrationsverktyg samordna uppgifter och ansvarsområden. För att separat välja denna administrationsnivå tillhandahåller Jämförelse mellan ISPConfig och Froxlor kompletterande sammanhang. Valet av en serverpanel är ett separat infrastrukturbeslut; en sådan panel ersätter varken säkerhetsåtgärderna för modell-API:et eller övervakningen av inferenstjänsten.

Identifiera fel och migrera TGI

Om en modell inte startar, kontrollera först modellversionen och formatet mot den valda körmiljön. För llama.cpp är GGUF det format som krävs; en konvertering i sig bevisar dock inte att den specifika arkitekturen och uppgiften fungerar. Därefter kontrollerar du om det valda backendet och hårdvarukombinationen stöds och om det finns tillräckligt med minne tillgängligt.

Om servern startar men ger oväntade svar i chatten, kontrollera följande: Chattmall och de angivna genereringsparametrarna. Ett OpenAI-kompatibelt gränssnitt innebär inte att varje parameter implementeras på exakt samma sätt: I vLLM-dokumentationen anges även parametrar som inte stöds eller som ignoreras. Jämför därför de inställningar som faktiskt används och inte bara formen på API-anropet.

För en befintlig TGI-tjänst inleds migreringen med en inventering: detta omfattar modellrevidering, använda API-anrop, samplingsinställningar och krav på svarets kvalitet. Hugging Face kör TGI i underhållsläge och nämner bland annat vLLM och SGLang som alternativ. Detta gör det värt att överväga ett byte, men innebär inte att befintliga installationer omedelbart slutar fungera.

Bygg den Målinstallation Testa dem separat och jämför de båda tjänsterna med samma representativa indata, utdatalängder och belastningsförhållanden. Kontrollera inte bara svarens kvalitet och eventuella fel, utan även om klienterna klarar av det nya gränssnittet och dess parametrar. Byt inte över trafiken förrän resultaten är acceptabla för den avsedda användningen och en återgångsplan finns på plats.

Hugging Faces-guiden för inferensändpunkter rekommenderar också att man skapar en ny ändpunkt och utför testanrop innan man byter över. Detta är en användbar modell för planering, men ingen universell steg-för-steg-guide för egen drivna installationer: nätverk, driftsättning och trafikstyrning kan vara organiserade på ett annat sätt där.

Välja rätt arkitektur

För en lokal prototyp är llama.cpp en självklar utgångspunkt när en lämplig GGUF-modell och passande hårdvarustöd finns tillgängliga. Detta innebär dock inte någon rekommendation av en specifik build. Det avgörande är inte bara om servern startar: jämför även kvaliteten på den önskade uppgiften, svarstiden och arbetsinsatsen för modellvikterna. Modell- och backend-stöd måste fortfarande testas för den specifika kombinationen.

För en intern chattjänst kan vLLM komma ifråga som testkandidat: Den dynamiska dokumentationen beskriver ett OpenAI-kompatibelt chattgränssnitt med nödvändig chattmall. Det finns därmed inga bevis för att version 0.10.2 har testats. SGLang förblir här ett icke-utvärderat alternativ som nämns i TGI-dokumentationen; utan teknisk testning av den aktuella versionen går det inte att jämföra det på lika villkor.

En plattform för bildmodeller och språkmodeller ställer andra krav än en enskild chatt-ändpunkt. Triton är en testpunkt tack vare sina modellbaserade schemaläggare och backend-system, även om version 25.10 inte har verifierats här. Denna arkitektur gör att Backend-stöd När det gäller den avgörande detaljfrågan: Inte alla backend-system stöds på alla plattformar, och varje modell som behövs måste testas i just den kombinationen.

Fastställ modellversion, serverversion, hårdvara, backend och användarrättigheter inför beslutet. Jämför därefter kvalitet, svarstider vid förväntad belastning samt arbetsinsatsen för säkerhetsåtgärder, uppdateringar och felsökning. En lösning som räcker för ett lokalt test kan kräva ytterligare infrastruktur vid flera användare eller modelltyper; en generell ranglista skulle dölja dessa skillnader.