Tokios im Vergleich zur eigenen Entwicklung einer lokalen LLM-Infrastruktur

​

Wie eine solche individuell erstellte Infrastruktur aussehen kann

Eine produktionsreife lokale LLM-API umfasst 7 Ebenen. Im Folgenden wird erläutert, welche Funktion jede Ebene erfüllt sowie welche Werkzeuge üblicherweise verwendet werden: Jede Ebene erfordert ein eigenständiges Werkzeug, das installiert, konfiguriert, aktualisiert und debuggt werden muss. Die Wechselwirkungen zwischen diesen Werkzeugen sind nicht immer offensichtlich: So beeinflusst das Puffern durch nginx das Streaming von Server-Sent Events, Zeitüberschreitungen bei Tunnelverbindungen wirken sich auf Proxy-Timeouts aus, und Authentifizierungs-Middleware muss das jeweilige API-Protokoll verstehen.

​

Vergleich der Einrichtungsmöglichkeiten

​

Wo die Eigenentwicklung Vorteile bietet

• Vollständige Kontrolle. Sie verfügen über die Kontrolle über alle Ebenen. Sie können alles überprüfen, anpassen und debuggen. Zwischen Ihrem Client und Ihrem Modell gibt es keinen undurchsichtigen verwalteten Service.
• Keine Datenweitergabe an Dritte. Der gesamte Datenverkehr verbleibt auf Infrastrukturen, die Sie selbst steuern. In regulierten Umgebungen wie dem Gesundheitswesen, der Finanzbranche oder im Regierungsbereich stellt dies eine zwingende Voraussetzung dar – nicht bloß eine Option.
• Keine Abhängigkeit von einem Anbieter. Sollte Tokios den Betrieb einstellen oder die Preise ändern, wären Sie abhängig. Bei einer selbst erstellten Infrastruktur hingegen können Sie diese dauerhaft selbst verwalten.
• Unbegrenzte Anpassungsmöglichkeiten. Sie können individuelle Ratenbegrenzungen festlegen, eigene Protokollierungsmechanismen nutzen, modellspezifische Routingregeln definieren sowie A/B-Tests durchführen – alles ist möglich, da Sie die Proxy-Konfiguration kontrollieren.
• Bei großem Umfang potenziell geringere Kosten. Bei mehr als 100 Nutzern kann der Kostenanteil pro Nutzer bei einem verwalteten Service die Ausgaben für eine selbst gehostete Infrastruktur übertreffen. Im großen Maßstab ist die Eigenentwicklung wirtschaftlicher.

​

Wo Tokios die bessere Wahl ist

• Minuten statt Stunden. Die gesamte Einrichtung von Tokios – Connector installieren, Modell registrieren, API-Schlüssel erstellen – dauert nur 2 bis 5 Minuten. Bei einer Eigenentwicklung benötigt die Ersteinrichtung selbst für erfahrene Nutzer 4 bis 8 Stunden.
• Kein Wartungsaufwand. Zertifikate werden automatisch erneuert, Tunnel erneut verbunden und das Gateway stets aktualisiert – ohne Ihr Zutun. Bei einer Eigenentwicklung müssen Sie sich ständig um Zertifikatsabläufe, Tunnelausfälle sowie Sicherheitsupdates für nginx kümmern.
• Integrierte Streaming-Unterstützung. Die SSE-Streaming-Funktion funktioniert direkt nach der Installation. Bei einer Eigenentwicklung müssen Sie hingegen explizit proxy_buffering in nginx deaktivieren, proxy_read_timeout konfigurieren und sicherstellen, dass der Tunnel keine Antworten puffert.
• Integrierte Authentifizierung. Nutzerbezogene API-Schlüssel mit Bereichszuweisung zur Deployment-Verwaltung. Bei einer Eigenentwicklung müssen Sie hingegen eine Authentifizierungs-Middleware programmieren, Schlüssel sicher speichern und eine Logik zur Widerrufung implementieren.
• Umgang mit CGNAT. Die rein ausgehende Verbindung von Tokios funktioniert hinter jedem NAT-Netzwerk. Eine selbst erstellte Tunnel-Configuration kann CGNAT entweder bewältigen oder auch nicht – Cloudflare Tunnel schafft das, doch nginx sowie Let’s Encrypt allein nicht.
• Keine Sicherheitsaspekte, die man verwalten müsste. Es gibt keine offenen Ports, kein Zertifikatsmanagement und keine Schwachstellen im Bereich Authentifizierung. Der Connector initiiert die Verbindung; das Gateway übernimmt den Rest.

​

Die typischen Fallstricke beim Streaming

Hier scheitern selbst erstellte Systeme bei LLM-Arbeitslasten am häufigsten. 3 verschiedene Ebenen können dabei dazu führen, dass eine Streaming-Antwort gepuffert oder zeitlich begrenzt wird:

1. Pufferung durch nginx. Standardmäßig puffert nginx Antworten vom Upstream-Server. Für Ihren LLM-Endpunkt müssen Sie proxy_buffering off; sowie proxy_cache off; im Location-Block angeben. Fehlen diese Angaben, werden alle Tokens erst am Ende in einem einzigen Datenblock übermittelt.
2. Zeitüberschreitungen bei Proxies. Der Standardwert für proxy_read_timeout in nginx beträgt 60 Sekunden. Bei langen Generationsprozessen auf Consumer-Hardware wird diese Grenze oft überschritten. Setzen Sie den Wert daher auf mindestens 300 Sekunden. Bei Verwendung eines Tunnels (z. B. Cloudflare Tunnel) gilt als neue Obergrenze ein Wert von etwa 100 bis 120 Sekunden.
3. Konfiguration von SSE. Der Content-Type: text/event-stream-Header muss vom Backend durch alle Proxy-Ebenen bis zum Client weitergegeben werden. Entfernt oder überschreibt irgendeine Ebene diesen Header, kann es zu unerwünschter Pufferung kommen.

Jedes dieser Probleme lässt sich lösen – doch es handelt sich um 3 getrennte Konfigurationen, die in 2 bis 3 verschiedenen Tools umgesetzt werden müssen. Zudem bleibt der Fehler meist unbemerkt: Das Streaming scheint zu funktionieren, tatsächlich werden jedoch alle Tokens auf einmal gesendet oder die Übertragung bricht mit einem 524 bzw. 504-Fehler ab. Das Gateway von Tokios verarbeitet alle 3 Aspekte standardmäßig korrekt, da es speziell für dieses Datenfluss-Muster entwickelt wurde.

​

Wann lohnt sich eine Eigenentwicklung?

• Strikte Regulierungsbereiche. Branchen wie Gesundheitswesen, Finanzwesen oder Regierungsbehörden, in denen keine externen Datenwege erlaubt sind. Alle Daten müssen innerhalb Ihrer eigenen, überprüfbaren Infrastruktur verbleiben.
• Vorhandene DevOps-Ressourcen. Wenn Sie bereits Kubernetes nutzen, ein Monitoring-System betreiben und das Hinzufügen eines weiteren Dienstes lediglich eine geringfügige Erweiterung darstellt – ohne dass neue Fachkenntnisse erforderlich wären.
• Vollständige Kontrolle erforderlich. Individuelle Routing-Logik, ein Logging-System, das über die optionale Anfrage-Protokollierung in Tokios hinausgeht, oder die Integration mit internen Systemen, die mit einem verwalteten Service nicht möglich wäre.
• 100+ Nutzer, bei denen die Kosten pro Nutzer eine Rolle spielen. Bei großen Nutzerzahlen ist eine selbst gehostete Infrastruktur deutlich kostengünstiger als die Abrechnung nach Nutzerzahl bei verwalteten Services.

​

In welchen Fällen eignet sich Tokios?

• Das gewünschte Ergebnis ohne eigenen Aufbau der Infrastruktur. Ihr Ziel ist es, „Ihr Modell mittels eines API-Schlüssels abrufbar zu machen“ – nicht „die Konfiguration von nginx zu erlernen“.
• Small teams. 2–10 people who need model access. It’s free on the community plan, and nobody’s time goes to infrastructure maintenance.
• Hinter einem CGNAT. Ihr Internetanbieter blockiert eingehende Verbindungen. Zwar lässt sich ein eigenes Tunnel-System einrichten, doch Tokios beherrscht dies nativ ohne zusätzliche Konfiguration.
• Schnelle Einrichtung erforderlich. Sie möchten innerhalb von 5 Minuten API-Aufrufe durchführen – statt einen ganzen Nachmittag mit der Konfiguration von Proxy-Ebenen zu verbringen.