Inference Server im Vergleich: Open-Source-Lösungen für KI-Modelle

Was ein Inference Server leistet

Ein Inference Server stellt ein bereits trainiertes KI-Modell für Anfragen bereit. Eine Anwendung sendet Eingaben an eine API, der Server übergibt sie an eine Modelllaufzeit und diese verarbeitet sie mit den geladenen Modellgewichten. Das Ergebnis gelangt über den Server zurück an die Anwendung. Bei einem Sprachmodell kann das eine Textantwort sein; je nach Schnittstelle lässt sie sich auch schrittweise als Tokenstrom ausgeben.

Server, Laufzeit und Modell sind unterschiedliche Bestandteile. Die Gewichte enthalten die erlernten Parameter; die Laufzeit führt die Berechnungen auf der verfügbaren Hardware aus. Der Server organisiert dagegen den Zugang und die Weitergabe der Anfragen. Ein Wechsel des Servers ersetzt daher nicht automatisch das Modell, kann aber ein anderes Format oder eine andere Laufzeit erfordern.

Für Benutzerverwaltung und Geschäftslogik ist meist eine zusätzliche Anwendungsschicht nötig. Sie entscheidet etwa, welche Nutzer eine Anfrage stellen dürfen, welche Daten an das Modell gelangen und wie dessen Antwort in einen Arbeitsablauf eingebunden wird. Eine erreichbare Modell-API allein bildet diese Regeln nicht ab; auch Zugriffsschutz und Protokollierung müssen als Teil des Gesamtsystems geplant werden.

Ein auf Textgenerierung ausgelegter LLM-Server ist zudem nicht automatisch eine Plattform für Bildklassifikation oder andere Modelltypen. Dafür müssen die jeweilige Modellarchitektur und eine geeignete Laufzeit unterstützt werden. Triton verfolgt einen breiteren Ansatz: Es leitet Anfragen über modellbezogene Scheduler an Backends weiter. Ob ein konkretes Modell dort ausführbar ist, hängt dennoch vom passenden Backend ab.

Modell, Hardware und Rechte prüfen

Beginne die Auswahl mit der Aufgabe und einer konkreten Modellrevision: Ein Chatmodell, ein Embedding-Modell und ein Bildklassifikator stellen unterschiedliche Anforderungen. Notiere außerdem das vorliegende Gewichtsformat und prüfe, ob die gewünschte Laufzeit genau diese Architektur und Revision unterstützt. Ein bekannter Modellname allein reicht nicht, um Kompatibilität oder gleichbleibende Ergebnisse anzunehmen.

• Aufgabe, Modellrevision und verfügbares Gewichtsformat festhalten.
• CPU oder GPU, verfügbaren Speicher, Treiber und benötigtes Backend prüfen.
• Nutzungsrechte für Server, Modellgewichte und zusätzliche Komponenten getrennt klären.
• Erwartete Anfragelängen, Parallelität und Anforderungen an Zugriffsschutz dokumentieren.

Die Hardwareentscheidung betrifft mehr als die Frage, ob eine GPU vorhanden ist. Gewichte müssen zusammen mit Laufzeit und zusätzlichen Daten in den verfügbaren Speicher passen; auch Treiber und Backend müssen zur Plattform passen. Tritons Backend-Dokumentation weist darauf hin, dass nicht jedes Backend auf jeder Plattform unterstützt wird. Prüfe deshalb die Kombination aus Serverversion, Modell, Backend und Hardware, statt Unterstützung aus dem Produktnamen abzuleiten.

Das Format kann die Auswahl ebenfalls einschränken: llama.cpp benötigt laut Projektdokumentation Modelle im GGUF-Format. Für andere Formate beschreibt das Projekt eine Konvertierung; daraus folgt aber nicht, dass jede Architektur oder jede Modellvariante unverändert funktioniert. Die Quelle liegt auf dem Entwicklungszweig. Vor einem Deployment solltest du die Angaben deshalb mit dem gewählten Release abgleichen.

Ein Open-Source-Server überträgt seine Lizenz nicht auf die Modellgewichte. Prüfe für beide getrennt, ob der geplante interne oder kommerzielle Einsatz erlaubt ist und welche Bedingungen gelten. Dass Gewichte heruntergeladen werden können, ist für sich genommen noch keine Freigabe für jede Nutzung oder Weitergabe.

Wie LLM-Anfragen Ressourcen beanspruchen

Bei einer Textanfrage verarbeitet das Modell zunächst die Eingabe. Diese Phase heißt Prefill. Anschließend erzeugt es im Decode-Schritt die Antwort Token für Token. Ein kurzer Prompt und eine lange Antwort verlagern einen anderen Teil der Arbeit in die Generierung als ein langer Dokumentauszug mit einer knappen Antwort. Beide Fälle sollten daher in der Kapazitätsplanung vorkommen.

Während der Generierung hält die Laufzeit Zwischendaten im KV-Cache vor, damit bereits verarbeiteter Kontext bei nachfolgenden Schritten genutzt werden kann. Dieser Speicherbedarf kommt zu den Modellgewichten hinzu und verändert sich mit der Länge der Sequenzen und der Zahl gleichzeitig bearbeiteter Anfragen. Passt das Modell allein in den Speicher, ist damit noch nicht belegt, dass auch die vorgesehene Last hineinpasst.

Continuous Batching bündelt laufende Generierungsanfragen flexibel, statt nur einen festen gemeinsamen Stapel abzuwarten. PagedAttention organisiert den Speicher des KV-Caches in Blöcken. Beide Verfahren werden für vLLM beschrieben und können die Ressourcennutzung verbessern. Wie stark sie helfen, hängt jedoch unter anderem von Anfragegrößen, Parallelität und Hardware ab; ein Vorteil für jede Arbeitslast ist daraus nicht ableitbar.

Triton beschreibt dagegen eine allgemeine Serverarchitektur: Ein modellbezogener Scheduler nimmt Anfragen entgegen und gibt sie an das zuständige Backend weiter. Dynamisches Batching kann für ein Modell konfiguriert werden. Das legt nicht fest, dass jedes Backend LLM-Anfragen intern gleich behandelt oder dieselben Speicherverfahren wie vLLM verwendet. Für einen Vergleich zählt deshalb die konkrete Backend- und Modellkombination.

Für einen internen Chatdienst genügt deshalb keine einzelne Zahl zu Tokens pro Sekunde. Neben der Ausgabegeschwindigkeit beeinflussen die Zeit bis zum ersten Token und Wartezeiten bei gleichzeitigen Anfragen das Nutzungserlebnis. Vergleiche Kandidaten mit repräsentativen Eingabe- und Ausgabelängen sowie derselben Parallelität, bevor du daraus eine Hardwareentscheidung ableitest.

Vier Lösungen einordnen, SGLang als Alternative vormerken

Die folgende Übersicht ordnet vLLM, llama.cpp, Triton und TGI anhand ihrer dokumentierten Ansätze ein. Sie ist kein releasebezogener Funktions- oder Leistungsvergleich. SGLang bleibt ein unbewerteter Alternativhinweis: Hugging Face empfiehlt es neben vLLM für die Nachfolge von TGI, doch daraus lassen sich weder Modellformate noch Schnittstellen oder Hardwareunterstützung eines bestimmten SGLang-Releases ableiten.

Die Quellenbasis enthält bewegliche Dokumentationsseiten und bei llama.cpp einen Entwicklungszweig. Damit ist keine abgeschlossene Prüfung für vLLM 0.10.2, llama.cpp b6000, Triton 25.10 oder TGI 3.3.7 belegt. Diese Release-Zuordnungen werden deshalb nicht als Vergleichsgrundlage verwendet. Vor einem Deployment musst du die benötigten Eigenschaften für die tatsächlich gewählte Serverversion und Modellrevision prüfen.

Der tatsächliche Betriebsaufwand hängt unter anderem von Modellbereitstellung, Zugriffsschutz und Überwachung ab. Ein direkter Aufwandvergleich lässt sich aus der Tabelle nicht ableiten: Eine lokale Einzelinstallation und eine Plattform mit mehreren Backends haben unterschiedliche Anforderungen. Prüfe deshalb zunächst, welche Aufgaben die Installation tatsächlich erfüllen muss.

Hugging Face führt TGI im Wartungsmodus und nennt vLLM und SGLang als Alternativen. Eine bestehende Installation muss deswegen nicht sofort ersetzt werden. Für neue Vorhaben sollte die eingeschränkte Weiterentwicklung jedoch in die Planung einfließen; vor einer Migration sind API-Verhalten und Modellqualität getrennt zu vergleichen.

Triton und vLLM schließen sich nicht grundsätzlich aus: Triton kann ein vLLM-Backend nutzen. Ob ein bestimmtes Modell mit den ausgewählten Versionen und der vorhandenen Plattform funktioniert, ist trotzdem für diese Kombination zu prüfen. Die allgemeine Triton-Architektur allein belegt keine Unterstützung für jedes Backend auf jeder Plattform.

Lokalen Prototyp vorbereiten

Für einen lokalen Prototyp legst du zuerst die Aufgabe und einige typische Eingaben fest. Wähle dann eine konkrete Modellrevision, die dafür geeignet erscheint, und prüfe ihre Nutzungsbedingungen. Die Lizenz des Servers allein sagt nicht, ob du die Modellgewichte für deinen vorgesehenen Zweck herunterladen, verändern oder einsetzen darfst.

llama.cpp verwendet das Format GGUF. Suche nach einer passenden GGUF-Variante oder prüfe, ob sich das Ausgangsmodell mit den dokumentierten Werkzeugen konvertieren lässt. Die Projektdokumentation beschreibt solche Konvertierungen auf dem Entwicklungszweig; sie ist kein Nachweis dafür, dass jeder ältere Release jede Architektur oder Konvertierungsoption unterstützt.

Prüfe vor dem Download, ob die gewählte Variante auf deiner CPU oder GPU mit dem vorgesehenen Backend unterstützt wird und ob genügend Speicher für Gewichte und Laufzeit verfügbar ist. Eine quantisierte Variante kann den Speicherbedarf der Gewichte senken. Vergleiche ihre Antworten aber mit deinen Qualitätsanforderungen, statt aus der kleineren Datei auf unveränderte Ergebnisse zu schließen.

Wähle für den Prototyp einen konkreten Build und gleiche Installation sowie Serveroptionen mit dessen Dokumentation ab. Für den zuvor genannten Build b6000 ist hier keine versionsgebundene Prüfung belegt; er wird deshalb nicht als geprüfter Ausgangspunkt empfohlen. Die vorhandene Modelldokumentation auf dem Entwicklungszweig ersetzt weder die Serverdokumentation des gewählten Builds noch dessen Kompatibilitätsprüfung.

Stelle den Dienst zunächst nur lokal bereit und sende mehrere repräsentative Anfragen. Vergleiche dabei nicht nur, ob eine Antwort erscheint, sondern auch, ob Eingabeformat, Modell und Generierungseinstellungen zu deiner geplanten Anwendung passen. Ein erfolgreicher Einzelaufruf belegt weder die Eignung für höhere Last noch die Qualität aller Antworten.

Halte drei Ergebnisse getrennt fest: die inhaltliche Qualität anhand deiner Testfälle, die wahrgenommene Antwortzeit und den Aufwand für Download, Konvertierung und Bereitstellung. So erkennst du beispielsweise, ob ein schnell eingerichtetes Modell fachlich ungeeignet ist. Für die davon getrennte Verwaltung des Linux-Hosts bietet der Überblick zu 1Panel als Serververwaltung ergänzenden Kontext; ein Serverpanel ersetzt nicht die Prüfung der Modelllaufzeit.

Last und Speicherbedarf planen

Bei einem internen Chat-Dienst unterscheiden sich Anfragen oft stark: Eine kurze Frage mit knapper Antwort beansprucht andere Ressourcen als ein langer Dokumentenauszug mit ausführlicher Ausgabe. Erfasse deshalb typische und größere Eingabe- und Ausgabelängen sowie die erwartete Zahl gleichzeitiger Nutzer. Ein einzelner erfolgreicher Aufruf beschreibt die Situation unter Last nicht ausreichend.

Der Speicherbedarf besteht nicht nur aus den Modellgewichten. Laufzeit und Zwischenwerte benötigen ebenfalls Platz; bei parallelen LLM-Anfragen wächst zudem der Bedarf für den KV-Cache. Längere Kontexte und mehr gleichzeitig bearbeitete Anfragen können deshalb eine Konfiguration an ihre Grenze bringen, obwohl die Gewichte allein in den verfügbaren Speicher passen.

Continuous Batching und PagedAttention sind bei vLLM dokumentierte Ansätze zur Verwaltung laufender Anfragen beziehungsweise des Cache-Speichers. Sie nehmen dir die Kapazitätsplanung nicht ab: Welche Kombination aus Parallelität und Kontextlänge praktikabel ist, hängt vom Modell, der Hardware und der gewählten Konfiguration ab. Ein pauschaler Leistungsgewinn für jede Arbeitslast lässt sich daraus nicht ableiten.

Eine einfache Mengenrechnung hilft bei der Vorbereitung: 100 hypothetische Anfragen mit jeweils 200 Ausgabetokens ergeben zusammen 20.000 Ausgabetokens. Das ist keine Durchsatzmessung. Ohne Zeitraum, Eingabelängen, Parallelität und weitere Betriebsdaten folgt daraus weder eine Aussage über Tokens pro Sekunde noch über die Kosten.

Für einen späteren Vergleich erstellst du eine Testmatrix mit Modell und Revision, Quantisierung, Serverversion, Hardware und verfügbarem Speicher. Variiere Eingabe- und Ausgabelänge sowie Parallelität kontrolliert. Erfasse Zeit bis zum ersten Token, Ausgabegeschwindigkeit und Fehlerrate; bewerte die Antwortqualität anhand derselben Testfälle gesondert. Generierungsparameter und Chat-Template gehören ebenfalls ins Protokoll, damit Unterschiede nachvollziehbar bleiben.

API sicher und beobachtbar betreiben

Ein erreichbarer Inference Server ist noch kein sicherer Dienst. Begrenze den Netzwerkzugriff zunächst auf die Systeme, die Anfragen stellen oder den Server administrieren müssen. Für externen Zugriff gehört ein vorgeschalteter Zugriffsschutz vor die API; prüfe dabei sämtliche erreichbaren Endpunkte und nicht nur die Route für die Textgenerierung.

Warnung: Die API-Key-Option von vLLM schützt laut Dokumentation nicht sämtliche Endpunkte. Ein gesetzter Schlüssel ersetzt deshalb weder Netzwerktrennung noch eine vorgeschaltete Zugriffskontrolle, die auch administrative und andere erreichbare Schnittstellen berücksichtigt. Teste die Regeln aus den jeweiligen Netzen, bevor du den Dienst freigibst.

Prompts und Antworten können vertrauliche Informationen enthalten. Lege deshalb vorab fest, welche Daten überhaupt protokolliert werden, wer sie einsehen darf und wann sie gelöscht werden. Für die Fehlersuche reichen häufig technische Angaben wie Zeitpunkt, Modellversion, Fehlerart und Anfragedauer; vollständige Inhalte solltest du nur bei begründetem Bedarf erfassen.

Die Beobachtbarkeit sollte Wartezeit, Zeit bis zum ersten Token, Ausgabegeschwindigkeit und Fehler getrennt erfassen. Steigt beispielsweise die Wartezeit bei gleichzeitigen Anfragen, während einzelne Antworten nach Beginn zügig laufen, deutet das auf eine andere Engstelle als eine langsame Token-Ausgabe hin. Werte diese Kennzahlen zusammen mit Anfragegrößen und Parallelität aus.

Für den Betrieb der zugrunde liegenden Hosts können Verwaltungswerkzeuge Aufgaben und Zuständigkeiten bündeln. Zur separaten Auswahl dieser Verwaltungsebene liefert der Vergleich von ISPConfig und Froxlor ergänzenden Kontext. Die Auswahl eines Serverpanels ist eine eigene Infrastrukturentscheidung; ein solches Panel ersetzt weder die Absicherung der Modell-API noch die Überwachung des Inference-Dienstes.

Fehler eingrenzen und TGI migrieren

Wenn ein Modell nicht startet, prüfe zuerst Modellrevision und Format gegen die gewählte Laufzeit. Bei llama.cpp ist GGUF das benötigte Format; eine Konvertierung allein belegt aber noch nicht, dass die konkrete Architektur und Aufgabe funktionieren. Danach grenzt du ein, ob das gewählte Backend und die Hardwarekombination unterstützt werden und ob ausreichend Speicher verfügbar ist.

Startet der Server, liefert aber unerwartete Chat-Antworten, kontrolliere das Chat-Template und die übergebenen Generierungsparameter. Eine OpenAI-kompatible Schnittstelle bedeutet nicht, dass jeder Parameter identisch umgesetzt wird: Die vLLM-Dokumentation nennt auch nicht unterstützte oder ignorierte Parameter. Vergleiche daher die tatsächlich verwendeten Einstellungen und nicht nur die Form des API-Aufrufs.

Bei einem bestehenden TGI-Dienst beginnt die Migration mit einer Bestandsaufnahme: Modellrevision, verwendete API-Aufrufe, Sampling-Einstellungen und Anforderungen an die Antwortqualität gehören dazu. Hugging Face führt TGI im Wartungsmodus und nennt unter anderem vLLM und SGLang als Alternativen. Das macht einen Wechsel prüfenswert, bedeutet aber keinen sofortigen Ausfall bestehender Installationen.

Baue die Zielinstallation getrennt auf und vergleiche beide Dienste mit denselben repräsentativen Eingaben, Ausgabelängen und Lastbedingungen. Prüfe neben Antwortqualität und Fehlern auch, ob Clients mit der neuen Schnittstelle und ihren Parametern zurechtkommen. Schalte Verkehr erst um, wenn die Ergebnisse für den vorgesehenen Einsatz akzeptabel sind und ein Rückweg vorbereitet ist.

Hugging Faces Anleitung für Inference Endpoints empfiehlt ebenfalls, einen neuen Endpunkt anzulegen und vor der Umschaltung Testaufrufe durchzuführen. Das ist ein hilfreiches Vorgehensmodell für die Planung, aber keine universelle Schritt-für-Schritt-Anleitung für selbst betriebene Installationen: Netzwerk, Deployment und Verkehrssteuerung können dort anders organisiert sein.

Die passende Architektur auswählen

Für einen lokalen Prototyp ist llama.cpp ein naheliegender Prüfpunkt, wenn ein geeignetes GGUF-Modell und passende Hardwareunterstützung vorliegen. Daraus folgt keine Empfehlung für einen bestimmten Build. Entscheidend ist nicht nur, ob der Server startet: Vergleiche auch die Qualität der gewünschten Aufgabe, die Antwortzeit und den Aufwand für die Modellgewichte. Modell- und Backendunterstützung bleiben für die konkrete Kombination zu prüfen.

Für einen internen Chat-Dienst kommt vLLM als Prüfkandidat infrage: Die bewegliche Dokumentation beschreibt eine OpenAI-kompatible Chat-Schnittstelle mit erforderlichem Chat-Template. Eine Prüfung für Version 0.10.2 ist damit nicht belegt. SGLang bleibt hier ein unbewerteter Alternativhinweis aus der TGI-Dokumentation; ohne technische Release-Prüfung lässt es sich nicht gleichwertig gegenüberstellen.

Eine Plattform für Bildmodelle und Sprachmodelle stellt andere Anforderungen als ein einzelner Chat-Endpunkt. Triton ist wegen seiner modellbezogenen Scheduler und Backends ein Prüfpunkt, ohne dass hier Release 25.10 verifiziert wurde. Diese Architektur macht die Backend-Unterstützung zur entscheidenden Detailfrage: Nicht jedes Backend wird auf jeder Plattform unterstützt, und jedes benötigte Modell muss in der konkreten Kombination geprüft werden.

Halte für die Entscheidung Modellrevision, Serverversion, Hardware, Backend und Nutzungsrechte fest. Vergleiche anschließend Qualität, Antwortzeiten unter erwarteter Last und den Aufwand für Absicherung, Updates und Fehlersuche. Eine Lösung, die für einen lokalen Versuch genügt, kann bei mehreren Nutzern oder Modelltypen zusätzliche Infrastruktur erfordern; eine pauschale Bestenliste würde diese Unterschiede verdecken.