OptiLLM als Proxy vor die LLM-API: was der Präfix-Trick wirklich leistet
Optimizing inference proxy for LLMs
Auf einen Blick
- Was ist das?
- OptiLLM setzt einen OpenAI-kompatiblen Proxy vor bestehende API-Endpunkte und wählt die Optimierungstechnik über einen Präfix im Modellnamen. Der Ansatz ist elegant, verlagert aber Rechenzeit und Kosten in den Inferenzpfad.
- Für wen ist es gedacht?
- Sinnvoll ist OptiLLM für Teams, die ihre bestehende OpenAI-kompatible API ohne Modellwechsel verbessern wollen und die zusätzliche Latenz akzeptieren. Wer deterministische Antwortzeiten oder feste Kosten pro Anfrage braucht, sollte davon Abstand nehmen.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 59 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem der Proxy adressiert
Sprachmodelle antworten auf eine einzelne Anfrage mit einem einzelnen Vorwärtsdurchlauf. Bei Aufgaben, die mehrstufiges Schlussfolgern verlangen, ist das der eigentliche Engpass. OptiLLM setzt genau dort an: Es nimmt die Anfrage entgegen, zerlegt sie intern in mehrere Aufrufe an das dahinterliegende Modell und setzt die Teilergebnisse zu einer Antwort zusammen. Das README formuliert den Anspruch als "2-10x accuracy improvements on reasoning tasks with zero training". Wer ein Modell also nicht neu trainieren oder feintunen kann oder will, bekommt hier einen Hebel auf der Inferenzseite.
Die Zielgruppe ist entsprechend eng umrissen. Es sind Teams, die bereits gegen eine OpenAI-kompatible Schnittstelle entwickeln und diesen Code nicht anfassen möchten. Laut README werden OpenAI, Anthropic, Google, Cerebras und über LiteLLM weitere Anbieter unterstützt. Der Wechsel geschieht über die Basis-URL und den Modellnamen, nicht über neue SDK-Aufrufe. Für Anwendungen, die bereits eine feste Modell- und Kostenkalkulation haben, ist das eine andere Rechnung als für Prototypen, bei denen Genauigkeit vor Latenz geht.
Der Modellname als Konfigurationsschalter
Der zentrale Mechanismus ist ein Präfix im Feld model. Im README steht das Beispiel model="moa-gpt-4o-mini", das Mixture of Agents aktiviert. Der Proxy entfernt den Präfix, wählt die zugehörige Technik und ruft das eigentliche Modell auf. Die Client-Seite bleibt unverändert, weil das Anfrageformat dem der OpenAI-Chat-Completions entspricht.
Das ist mehr als eine Bequemlichkeit. Es bedeutet, dass die Optimierung pro Anfrage und nicht pro Deployment gewählt wird. Dieselbe Anwendung kann für eine schwierige Teilaufgabe einen teuren Slug verwenden und für eine triviale einen günstigen. Die Technikliste im README umfasst unter anderem mars, cepo, cot_reflection, plansearch und re2, insgesamt nennt die Beschreibung 20+ Verfahren. Einige davon, etwa cot_reflection, arbeiten mit expliziten Abschnitten im Prompt, die das Modell ausfüllen soll. Andere, etwa plansearch, führen eine Suche über Kandidatenpläne durch. Die Datenflussrichtung bleibt in allen Fällen gleich: Client, Proxy, Anbieter-API, zurück durch den Proxy, zurück zum Client.
Installation und die drei Startwege
Der kürzeste Weg ist pip install optillm, danach der Aufruf optillm, nachdem OPENAI_API_KEY gesetzt wurde. Der Server lauscht laut Beispiel auf http://localhost:8000/v1, der Client wird mit base_url auf diese Adresse gezeigt. Die Startausgabe im README nennt geladene Plugins und die Zeile "Starting server with approach: auto", was darauf hindeutet, dass ohne weitere Angabe ein Standardverfahren greift.
Für Container gibt es drei Varianten. latest enthält alle Abhängigkeiten inklusive lokaler Inferenz und Plugins, latest-proxy ist die kleinste Variante ohne lokale Inferenz, latest-offline bringt vorab geladene Modelle mit und arbeitet ohne Netzzugriff. Die Wahl ist keine Geschmacksfrage: Wer im Proxy-Modus startet, kann keine lokalen Modelle ausführen und muss einen externen Endpunkt ansprechen. Wer im Offline-Modus arbeitet, transportiert ein deutlich größeres Image.
Für SSL gibt es zwei Schalter. optillm --no-ssl-verify beziehungsweise OPTILLM_SSL_VERIFY=false deaktiviert die Zertifikatsprüfung, was das README ausdrücklich als unsicher und nur für die Entwicklung markiert. Sauberer ist optillm --ssl-cert-path /path/to/ca-bundle.crt oder OPTILLM_SSL_CERT_PATH für eine eigene CA, etwa hinter einem Unternehmensproxy.
Wo die Rechnung nicht aufgeht
Jede dieser Techniken erzeugt zusätzliche Modellaufrufe. Ein Best-of-N-Verfahren vervielfacht die Anfragen, eine Suche über Pläne tut dasselbe mit dem Unterschied, dass die Anzahl der Knoten nicht vorab feststeht. Die Latenz einer einzelnen Anfrage steigt damit deutlich, und die Tokenkosten steigen mit ihr. Das README nennt das selbst als Preis: "by doing additional compute at inference time". Wer eine interaktive Anwendung mit festem Zeitbudget betreibt, für den ist das der falsche Hebel.
Hinzu kommt die Fehlerfläche. Wenn der Proxy mehrere Aufrufe orchestriert, kann jeder einzelne scheitern, und die Frage, ob ein Teilausfall zu einer schlechteren oder zu gar keiner Antwort führt, hängt von der jeweiligen Implementierung ab. Das README gibt dazu keine Auskunft. Ebenso unklar bleibt, wie sich die Slugs zu Streaming verhalten. Der Proxy gibt sich als OpenAI-kompatibel aus, aber ob eine Technik, die intern mehrere Durchläufe ausführt, Token für Token streamen kann, lässt sich aus dem Material nicht bestätigen. Wer Streaming voraussetzt, muss das vor der Einführung klären. Ein weiterer Punkt: Die Techniken sind nicht unabhängig vom Modell. Ein Verfahren, das für ein großes Modell entworfen wurde, verhält sich auf einem kleinen anders, und das README liefert für die meisten Slugs keine Angabe, für welche Modellklassen sie gedacht sind.
Was die Zahlen im README belegen und was nicht
Die Ergebnistabelle nennt unter anderem MARS auf Gemini 2.5 Flash Lite mit 43,3 auf 73,3 Punkte bei AIME 2025, CePO auf Llama 3.3 70B mit 51,0 auf 69,6 bei Math-L5 und MOA auf GPT-4o-mini, das laut README auf Arena-Hard-Auto das Niveau von GPT-4 erreicht. Diese Werte stammen aus dem Projekt selbst. Sie sind nicht unabhängig nachvollzogen, und die Tabelle sagt nichts über die Kosten pro Anfrage, die zu diesen Werten geführt haben. Genau diese Zahl fehlt aber in einer Adoptionsentscheidung.
Auffällig ist die Bandbreite der Verbesserungen. Sie reicht von einem knappen Plus bei AutoThink auf DeepSeek-R1-1.5B bis zu 30 Punkten bei MARS. Das ist kein Widerspruch, sondern erwartbar: Der Effekt hängt davon ab, wie viel Kopfrechnen das Basismodell bereits leistet. Ein schwaches Modell profitiert stärker von zusätzlichen Zwischenschritten. Wer aus der Tabelle eine allgemeine Verbesserung um den Faktor zwei bis zehn ableitet, liest sie falsch. Die Spanne bezieht sich auf einzelne Technik-Modell-Benchmark-Kombinationen, nicht auf einen Durchschnitt.
Der Vergleich mit einem Gateway ohne Suchschicht
LiteLLM wird im README selbst als Transportweg für über 100 Modelle genannt, ist aber primär ein Routing- und Übersetzungsgateway. Es vereinheitlicht Anbieter-APIs, kümmert sich um Schlüsselverwaltung und Fallbacks. Es verändert die Anfrage nicht inhaltlich. OptiLLM setzt eine Ebene darüber: Es verändert, wie oft und mit welcher Struktur das Modell aufgerufen wird.
Der Unterschied zeigt sich im Betrieb. Ein Gateway lässt sich ohne Änderung der Antwortqualität austauschen, weil es nichts zur Antwort beiträgt. Ein Proxy mit Such- und Reflexionsschritten ist Teil des Ergebnisses. Fällt er aus, fällt die Antwort aus, nicht nur die Weiterleitung. Umgekehrt lässt sich ein Gateway nicht dazu bringen, eine Aufgabe durch mehrere Modellläufe zu lösen. Wer beides braucht, wird LiteLLM als Transport und OptiLLM als vorgelagerte Schicht kombinieren, wobei dann zwei Komponenten im Pfad liegen und die Fehlerdiagnose entsprechend aufwendiger wird.
Pflege, Versionen und Lizenz
Die letzten Releases liegen dicht beieinander: v0.3.20 und v0.3.21 am 5. Juli 2026, v0.3.22 am 18. Juli 2026. Der letzte Push fällt auf denselben Tag wie v0.3.22. Das Muster deutet auf kurze Release-Zyklen in der 0.3er-Reihe hin. Für Betreiber heißt das: Die Versionsnummer signalisiert keine API-Stabilität im Sinne von Semantic Versioning, und ein Update kann Verhalten ändern. Wer den Proxy produktiv einsetzt, sollte die Version pinnen und die Slugs, die tatsächlich genutzt werden, nach jedem Sprung gegen die eigenen Testfälle laufen lassen.
Die Lizenz ist Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die Beibehaltung der Lizenzhinweise und, bei Weitergabe veränderter Dateien, einen Hinweis auf die Änderungen. Wer den Proxy als Teil eines eigenen Produkts ausliefert, muss diese Pflichten prüfen. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass die Wahl der Lizenz hier relevant wird, sobald OptiLLM nicht mehr nur intern betrieben wird.
Ein Kostenfaktor, der leicht übersehen wird: Die drei Docker-Varianten unterscheiden sich erheblich im Umfang. Das Offline-Image enthält vorab geladene Modelle, was sich in Pull-Zeiten und Speicherbedarf niederschlägt. Wer nur proxyt, sollte latest-proxy wählen, sonst zahlt man bei jedem Deployment für Abhängigkeiten, die nie ausgeführt werden.
Redaktionelles Fazit
Sinnvoll ist OptiLLM für Teams, die ihre bestehende OpenAI-kompatible API ohne Modellwechsel verbessern wollen und die zusätzliche Latenz akzeptieren. Wer deterministische Antwortzeiten oder feste Kosten pro Anfrage braucht, sollte davon Abstand nehmen. Vor dem Einsatz zu klären: ob der eigene Endpunkt Streaming und die vom gewählten Slug erwartete Anzahl an Aufrufen unterstützt, und ob die Apache-2.0-Lizenz zu den eigenen Weitergabepflichten passt.
Community-Notizen