Tokios im Vergleich zu LiteLLM für die Routing-Logik lokaler LLMs

​

Übersicht

LiteLLM ist ein Open-Source-Python-Proxy und API-Gateway. Es steht vor den LLM-Backends und übersetzt Anfragen zwischen den Schnittstellen verschiedener Anbieter wie OpenAI, Anthropic, Azure, Bedrock sowie mehr als 100 weiteren. Zusätzlich stellt es virtuelle API-Schlüssel, Budgetüberwachung, Lastverteilung sowie Überwachungsfunktionen bereit. Es bildet somit eine leistungsstarke Schicht für Routing und Kostenkontrolle. Der entscheidende Unterschied: LiteLLM ist ein Proxy, kein Tunnel. Es regelt den API-Datenverkehr zwischen Anfragen und Backends, löst jedoch nicht das Netzwerkproblem, lokale Modelle aus dem Internet erreichbar zu machen. Für Fernzugriff ist weiterhin ein separater Tunnel wie Tailscale, Cloudflare oder Tokios erforderlich. Tokios vereint den Tunnel, das API-Gateway, benutzerbezogene API-Schlüssel sowie ein Verwaltungs-Dashboard in einem 1 verwalteten Service. Dieser übernimmt sowohl die Netzwerkschicht – wodurch Ihr Modell erreichbar wird – als auch die API-Schicht, zu der Authentifizierung, Streaming sowie Protokollübersetzung zählen.

​

Vergleichstabelle

​

Wo LiteLLM seine Stärken ausspielt

• Open Source. Der vollständige Quellcode steht zur Verfügung; die Software lässt sich selbst hosten, ohne Abhängigkeiten von Drittanbietern. Sie können den Code prüfen, abzweigen und anpassen.
• 100+ Anbieter. Sie können Anfragen an OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex, Together AI sowie zahlreiche weitere Dienste senden – alles über eine einheitliche OpenAI-kompatible API.
• Fortgeschrittenes Routing. Gewichtete Lastverteilung, Routing nach Latenz, automatische Ausweichlösungen bei Ausfällen von Anbietern sowie spezielle Logik zur Vermeidung von Überlastungen bei Modellen.
• Präzise Budgetsteuerung. Legen Sie Ausgabenlimits pro virtuellem Schlüssel, Team oder Projekt fest. Verfolgen Sie die Kosten pro Modell, Nutzer und Tag. In diesem Bereich ist LiteLLM deutlich ausgereifter.
• Umfassende Beobachtbarkeit. Native Integrationen mit Langfuse, Datadog, Prometheus, Helicone sowie benutzerdefinierten Callback-Funktionen. Jede Anfrage wird detailliert protokolliert – inklusive Tokenanzahl und Latenzwerten.
• Genaue Kostenzuordnung. Erfahren Sie exakt, welches Team wie viel für welches Modell ausgegeben hat. Für Organisationen, die mehrere Cloud-Anbieter nutzen, ist dies von großer Bedeutung.

​

Wo Tokios seine Stärken zeigt

• Enthält den Tunnel. Bei LiteLLM ist weiterhin eine separate Netzwerkschicht nötig, damit ein lokales Modell aus dem Internet erreichbar ist. Tokios stellt den ausgehenden Tunnel bereits bereit – ohne cloudflared, ohne Tailscale und ohne nginx-Konfiguration.
• Verwalteter Service. Es ist kein Docker-Container zu starten, keine Kubernetes-Deployment nötig und auch keine Python-Umgebung zu pflegen. Tokios besteht aus einem Connector-Binary sowie einem webbasierten Dashboard.
• Integriertes Dashboard. Über eine einzige Oberfläche lassen sich Connectors, Deployment sowie API-Schlüssel verwalten. Das Admin-Dashboard von LiteLLM erfordert hingegen zusätzliche Einrichtung und Konfiguration.
• Protokollübersetzung am Gateway. Am Tunnel-Endpunkt werden OpenAI- und Anthropic-Formate unterstützt. LiteLLM wandelt die Formate in OpenAI-Format um, spricht aber gegenüber Anfragern kein Anthropic-Protokoll.
• Einfacher für lokale Modelle. Falls das Ziel lautet, „ein lokales Ollama-Modell mittels API-Schlüssel aus dem Internet erreichbar zu machen“, ist Tokios in 2 Minuten einsatzbereit. Bei LiteLLM ist ein Docker-Deployment, eine Konfigurationsdatei sowie eine separate Tunnel-Einrichtung erforderlich.

​

Die Netzwerklücke

Dies ist der grundlegende Unterschied: LiteLLM fungiert als Proxy-Schicht, die zwischen Anfragern und Backends im selben Netzwerk (oder erreichbaren Netzwerken) vermittelt. Läuft das Modell auf einem Heimserver hinter CGNAT, kann LiteLLM es allein nicht aus dem Internet erreichbar machen. Dazu ist Folgendes nötig:

1. Ein Tunnel (Cloudflare Tunnel, Tailscale Funnel oder Tokios), der den LiteLLM-Proxy öffentlich zugänglich macht
2. LiteLLM hinter diesem Tunnel zur Verwaltung von Routing, Schlüsseln und Budgets
3. Die LLM-Backends hinter LiteLLM

Insgesamt sind 3 Ebenen einzurichten und zu pflegen. Tokios fasst die Ebenen 1 und 2 zu einem einzigen verwalteten Service zusammen – ersetzt jedoch nicht die Multi-Provider-Routing-Fähigkeiten von LiteLLM.

​

Die beide Tools gemeinsam nutzen

Bei komplexen Deployment-Szenarien ergänzen sie sich gegenseitig:

• LiteLLM läuft in Ihrem lokalen Netzwerk und leitet Anfragen an mehrere Backends weiter – etwa lokale vLLM-Instanzen sowie Cloud-basierte OpenAI- und Azure-Dienste – wobei es Kosten nachverfolgt und Lastverteilung gewährleistet.
• Tokios stellt den öffentlich zugänglichen Tunnel-Endpunkt bereit, der mittels API-Schlüsseln gesichert ist; dadurch können externe Nutzer sowie KI-Agenten problemlos auf Ihren LiteLLM-Proxy zugreifen, ohne dass Sie einen separaten Tunnel einrichten müssen.

In dieser Architektur verweist der Tokios-Connector auf Ihren LiteLLM-Proxy statt direkt auf ein Backend. Anfragen erfolgen über api.tokios.com unter Verwendung des sk-tok-…-Schlüssels; Tokios leitet diese dann an Ihren Rechner weiter, wo LiteLLM die Weiterleitung an die jeweiligen Provider übernimmt.

​

Wann Sie sich für LiteLLM entscheiden sollten

• Routing zwischen mehreren Cloud-Providern. Sie benötigen eine Verteilung von Anfragen auf OpenAI, Anthropic, Azure sowie lokale Modelle inklusive Ausweichlösungen und Lastverteilung.
• Fortgeschrittene Kostenkontrolle. Für Sie sind Team-spezifische Budgets, projektbezogene Ausgabenobergrenzen sowie detaillierte Kostenzuordnungen von Bedeutung.
• Verfügen Sie über DevOps-Kenntnisse. Sie können ein Docker- oder Kubernetes-Deployment mit Konfigurationsdateien sowie Monitoring-Elementen betreiben und pflegen.
• Sie benötigen eine breite Palette an Providern. Sie integrieren 5 verschiedene LLM-Provider und wünschen sich eine einheitliche API-Schnittstelle.

​

Wann Sie sich für Tokios entscheiden sollten

• Ihre lokalen Modelle benötigen einen öffentlichen API-Endpunkt. Ihr Hauptziel besteht darin, Modelle auf Ihrer Hardware so zu erschließen, dass externe Nutzer mittels Authentifizierung darauf zugreifen können.
• Sie wünschen einen verwalteten Service. Es gibt keine Infrastruktur zu betreiben, keine Container zu orchestrieren sowie keine Python-Umgebungen zu verwalten.
• Sie benötigen Tunnel, Proxy sowie API-Schlüssel in einer einzigen Lösung. Ein einziges Werkzeug übernimmt Netzwerkfunktionen, Authentifizierung sowie Datenübertragung – statt 3 separater Komponenten.
• Einfache Einrichtung einer lokalen Backend-Umgebung. Nur ein oder zwei lokale Modelle über Ollama oder vLLM – kein komplexes Routing-Netzwerk mit mehreren Anbietern.