OpenLLM: OpenAI-kompatible Endpunkte für selbst gehostete Modelle

Welches Problem OpenLLM adressiert

Die Ausgangslage ist bekannt: Ein offenes Modell lässt sich mit llama.cpp oder einem Python-Skript lokal starten, aber die Anbindung an bestehende Anwendungen ist Handarbeit. Jeder Client spricht ein anderes Protokoll, jede Bibliothek erwartet andere Endpunkte, und ein Wechsel des Modells bedeutet meist Änderungen im Anwendungscode. OpenLLM setzt genau hier an und liefert einen Server, der die OpenAI-kompatible API-Oberfläche nachbildet. Laut README lauscht der Server standardmäßig auf http://localhost:3000 und stellt die Endpunkte unter /v1 bereit, sodass der OpenAI Python Client, LlamaIndex und andere Werkzeuge ohne Anpassung dagegen laufen. Die Zielgruppe sind damit nicht Endanwender, die ein Modell ausprobieren wollen, sondern Entwickler und Plattform-Teams, die eine bestehende Anwendung auf ein selbst gehostetes Modell umbiegen möchten, ohne den Client-Code neu zu schreiben. Der Anspruch des Projekts ist ausdrücklich Cloud-Deployment über Docker, Kubernetes und BentoCloud, nicht der lokale Einzelplatzbetrieb.

Modell-Repository als zentrale Indirektion

Das eigentliche Architekturmerkmal ist das Modell-Repository. Ein Repository in OpenLLM ist ein Katalog verfügbarer LLMs, und das Projekt pflegt einen Standard-Katalog im Repository bentoml/openllm-models. Aufgelöst wird über einen Bezeichner der Form name:version, etwa llama3.2:1b oder deepseek:r1-671b. Die CLI bietet dafür drei Befehle: openllm model list zeigt alle Modelle aus dem Standard-Repository und allen zusätzlich eingebundenen Repositories, openllm repo update synchronisiert die lokale Liste mit den entfernten Quellen, und openllm model get llama3.2:1b gibt die Informationen zu einem einzelnen Modell aus. Diese Indirektion ist der Grund, warum Modellwechsel nicht zwingend Codeänderungen nach sich ziehen: Der Client spricht weiterhin mit demselben Endpunkt, nur der Bezeichner beim Start des Servers ändert sich. Sie hat aber auch eine Kehrseite. Wer ein Modell außerhalb des Katalogs betreiben will, muss ein eigenes Repository einrichten, und die README behandelt diesen Fall nur als Abschnitt "Set up a custom repository", ohne den vollständigen Ablauf im vorliegenden Auszug zu zeigen. Das ist ein reales Einstiegshindernis für alle, die ein feinabgestimmtes oder internes Modell servieren wollen.

Vom Befehl zum laufenden Endpunkt

Der Einstieg ist bewusst kurz gehalten. Nach pip install openllm führt openllm hello durch eine interaktive Erkundung. Ein Server startet mit openllm serve llama3.2:1b, eine Chat-Sitzung im Terminal mit openllm run llama3:8b. Ein wichtiger Hinweis steht im README: OpenLLM speichert keine Modellgewichte selbst. Für gated Modelle ist ein Hugging-Face-Token nötig, das als Umgebungsvariable HF_TOKEN gesetzt wird. Der Ablauf ist dort in drei Schritten beschrieben: Token erstellen, Zugriff auf das Modell beantragen, Token exportieren. Wer das überspringt, bekommt beim Start einen fehlgeschlagenen Download statt einer hilfreichen Fehlermeldung, denn der Fehler entsteht in der Hugging-Face-Schicht und nicht in der OpenLLM-CLI. Auf der Client-Seite sind drei Angaben relevant: die Host-Adresse, der Modellname und ein optionaler API-Schlüssel. Im README-Beispiel wird base_url='http://localhost:3000/v1' mit api_key='na' verwendet, und als Modellname erscheint der vollständige Hugging-Face-Pfad meta-llama/Llama-3.2-1B-Instruct. Dass der Bezeichner beim Serve-Befehl und der Modellname im Client unterschiedlich aussehen, ist eine Stolperstelle, die sich durch die Dokumentation zieht. Wer den Namen aus dem Serve-Befehl in den Client kopiert, erhält einen Fehler.

Hardware-Anforderungen als Auswahlkriterium

Die Modelltabelle im README nennt zu jedem Eintrag den GPU-Bedarf, und diese Spalte ist der praktisch nützlichste Teil der Dokumentation. Kleine Modelle wie gemma2:2b, gemma3:3b oder llama3.2:1b sind mit 12 beziehungsweise 24 GB angegeben. llama3.1:8b, mistral:8b-2410 und qwen2.5:7b liegen bei 24 GB, also im Bereich einer einzelnen Workstation-GPU. Nach oben wird es schnell unhandlich: llama3.3:70b benötigt laut Tabelle 80Gx2, mistral-large:123b-2407 80Gx4, llama4:17b16e 80Gx8 und deepseek:r1-671b sogar 80Gx16. Diese Zahlen sind Startpunkte für die Kapazitätsplanung, keine Zusagen über den tatsächlichen Durchsatz bei einer gegebenen Kontextlänge. Wer mit einem 7B-Modell auf einer 24-GB-Karte beginnt, kann die Architektur später nicht ohne weiteres auf ein 70B-Modell übertragen, weil sich die Anzahl der benötigten GPUs und damit die Deployment-Topologie ändert. Die Modellwahl ist deshalb eine Infrastrukturentscheidung, die vor dem ersten Deployment getroffen werden sollte, nicht danach.

Wo OpenLLM die falsche Wahl ist

Die README beschreibt OpenLLM als Werkzeug für Cloud-Deployment, und genau darin liegt die Einschränkung. Für einen Entwickler, der ein Modell auf dem Laptop ausprobieren will, ist der Aufwand mit Modell-Repository, Hugging-Face-Token und Serverprozess höher als bei Werkzeugen, die auf lokalen Einzelplatzbetrieb zugeschnitten sind. Der zweite Fall betrifft alle, die ein Modell außerhalb des Standard-Katalogs betreiben. Ohne eigenes Repository lässt sich ein feinabgestimmtes Modell nicht über den name:version-Bezeichner ansprechen, und der Auszug der README zeigt den vollständigen Ablauf dafür nicht. Ein dritter Punkt ist die API-Abdeckung. Die README belegt Chat Completions und die Modellliste über client.models.list(). Ob weitere Teile der OpenAI-API wie Embeddings, Function Calling in allen Varianten oder die Responses-API abgedeckt sind, geht aus dem vorliegenden Material nicht hervor. Wer diese Oberflächen benötigt, muss das vor der Entscheidung prüfen, statt es anzunehmen. Schließlich sagt die README nichts über Multi-Tenancy, Rate Limiting oder Authentifizierung über den optionalen API-Schlüssel hinaus. Für einen öffentlich erreichbaren Endpunkt ist das eine offene Frage.

Abgrenzung zu vLLM und Ollama

Der naheliegende Vergleich ist vLLM, das ebenfalls einen OpenAI-kompatiblen Server bereitstellt, sich aber auf die Inferenz-Engine konzentriert: PagedAttention und Continuous Batching stehen dort im Mittelpunkt, das Deployment drumherum bleibt dem Nutzer überlassen. OpenLLM setzt eine Ebene höher an und liefert mit dem Modell-Repository, der CLI und der Anbindung an BentoML und BentoCloud die Betriebsseite mit. Wer die Inferenzleistung selbst optimieren und die Deployment-Schicht kontrollieren will, ist bei vLLM besser aufgehoben. Wer dagegen einen Endpunkt braucht, der sich wie ein Modellkatalog verhält und über Kubernetes ausrollbar ist, findet bei OpenLLM mehr fertige Bausteine. Ollama wiederum adressiert den lokalen Einzelplatzbetrieb mit einem eigenen Modellformat und einer eigenen Registry. Der Unterschied liegt weniger in der Inferenz als im Betriebsmodell: Ollama zieht Modelle lokal und ist auf einen Rechner zugeschnitten, OpenLLM zielt auf den Serverbetrieb. Wer OpenLLM auf einem Laptop startet, nutzt es außerhalb seines vorgesehenen Einsatzbereichs und zahlt den Preis in Form von Konfigurationsaufwand.

Wartung, Releases und Lizenz

Der letzte veröffentlichte Stand in den vorliegenden Daten ist v0.6.30 vom 21. April 2025, davor v0.6.29 und v0.6.28 im Abstand von wenigen Tagen. Der letzte Push auf den main-Branch datiert auf den 7. September 2026. Aus diesen Angaben lässt sich eine gewisse Aktivität ableiten, aber kein Urteil über die Qualität einzelner Releases, und die kurzen Abstände zwischen 0.6.28 und 0.6.30 deuten auf einen Patch-Zyklus hin, dessen Inhalt hier nicht sichtbar ist. Wer OpenLLM produktiv einsetzt, sollte die Release Notes der jeweiligen Version lesen, bevor aktualisiert wird, weil Versionssprünge in der 0.x-Reihe keine Stabilitätsgarantie mit sich bringen. Die Lizenz ist Apache-2.0, was die kommerzielle Nutzung und Weitergabe grundsätzlich erlaubt, sofern die Lizenzbedingungen eingehalten werden. Das betrifft ausdrücklich nicht die Modellgewichte: OpenLLM speichert sie nicht, und die Lizenz eines Modells wie Llama kann eigene Auflagen für die Nutzung enthalten. Diese beiden Lizenzen sind getrennt zu prüfen. Für rechtliche Fragen ist das keine Beratung, sondern nur der Hinweis, wo die Prüfung ansetzen muss.

Redaktionelles Fazit

OpenLLM passt zu Teams, die bereits BentoML oder Kubernetes einsetzen und einen OpenAI-kompatiblen Endpunkt für ein einzelnes, klar benanntes Modell brauchen. Wer nur eine lokale Chat-Oberfläche sucht, ist mit Ollama besser bedient, und wer viele Modelle parallel mit eigenen Scheduling-Regeln betreiben will, sollte zuerst prüfen, ob OpenLLM oder vLLM die bessere Grundlage ist. Vor dem Rollout ist zu klären, ob das gewählte Modell im Repository von openllm-models liegt oder als eigenes Repository eingebunden werden muss, welcher Inferenz-Backend-Parameter für die Zielhardware gesetzt wird und ob der Hugging-Face-Zugriff für gated Modelle vorab freigeschaltet ist.

Offizielle Quellen

1. bentoml/OpenLLM on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases