STREAM: Multi-Tier LLM Inference Middleware with Dual-Channel HPC Token Streaming

STREAM ist eine mehrstufige Inference-Middleware, die lokale, institutionelle HPC- und Cloud-LLM-Ressourcen durch eine neuartige Dual-Channel-Architektur vereinigt, die ein Token-Streaming im Sub-Sekunden-Bereich durch Firewalls ermöglicht und somit eine kosteneffiziente, private und hochperformante Alternative zu fragmentierten Inference-Lösungen bietet.

Das Wesentliche

Stellen Sie sich vor, Sie versuchen, Antworten von einem sehr klugen, aber sehr unterschiedlichen Set an Bibliothekaren zu erhalten. Sie haben drei Optionen, aber jede hat einen Haken:

1. Der lokale Bibliothekar (Ihr Computer): Er ist kostenlos, er kennt Ihre Geheimnisse und er ist direkt in Ihrem Wohnzimmer. Aber er ist klein und kann sich nur ein paar Seiten eines Buches gleichzeitig merken. Wenn Sie ihn bitten, eine ganze Enzyklopädie zu lesen, ist er überfordert.
2. Die Universitätsbibliothek (HPC-Zentrum): Dies ist eine riesige, superstarke Bibliothek mit gewaltigen Computern. Sie ist für Studenten und Forscher kostenlos. Aber sie ist hinter einem Hochsicherheitszaun eingesperrt. Sie können nicht hineingehen und direkt mit dem Bibliothekar sprechen; Sie müssen eine Anfrage einreichen, warten, bis er das ganze Buch gelesen hat, und dann erhalten Sie die Antwort per Post. Das ist langsam und umständlich für einen kurzen Chat.
3. Die schicke Cloud-Bibliothek: Sie haben die klügsten Bibliothekare der Welt und können alles sofort beantworten. Aber sie berechnen Ihnen für jedes einzelne Wort, das sie sprechen, Geld – und sie behalten möglicherweise eine Kopie Ihres Gesprächs für immer in ihren Akten.

STREAM ist ein neuer „Smart Concierge“ (ein intelligenter digitaler Concierge), der Sie mit all diesen drei Bibliotheken gleichzeitig verbindet und sie wie einen nahtlosen Service erscheinen lässt. So funktioniert es, unter Verwendung einfacher Analogien:

1. Der smarte Verkehrspolizist (Routing)

Wenn Sie eine Frage stellen, rät der STREAM-Concierge nicht einfach nur. Er hat einen winzigen, schnellen „Richter“ (eine kleine KI), der Ihre Frage zuerst prüft.

• Wenn Sie fragen: „Was ist 2+2?“ oder „Erzähl mir einen Witz“, schickt der Richter die Frage an den lokalen Bibliothekar, weil das einfach und kostenlos ist.
• Wenn Sie eine mittelschwere Frage stellen, schickt er sie an die Universitätsbibliothek.
• Wenn Sie etwas unglaublich Komplexes fragen, das ein Genie-Niveau erfordert, schickt er es an die schicke Cloud-Bibliothek.

Das spart Ihnen Geld, da Sie die teure Cloud-Bibliothek nur dann nutzen, wenn Sie es absolut notwendig haben.

2. Der „Geheimgang“ (Dual-Channel Streaming)

Dies ist der größte magische Trick des Papers. Normalerweise ist die Universitätsbibliothek so sicher, dass Sie keinen Live-Chat in Echtzeit mit ihr führen können. Sie müssen warten, bis die ganze Antwort geschrieben wurde, bevor Sie etwas sehen können.

STREAM baut eine Zwei-Spur-Autobahn, um den Sicherheitszaun zu umgehen, ohne gegen Regeln zu verstoßen:

• Spur 1 (Die Control Plane): Dies ist wie ein sicheres Telefonat. Sie sagen der Universitätsbibliothek: „Hey, ich habe eine Frage an dich.“ Die Bibliothek bestätigt dies und beginnt mit der Arbeit.
• Spur 2 (Die Data Plane): Dies ist ein geheimer, einseitiger Tunnel. Während der Universitätsbibliothekar die Antwort schreibt, flüstert er die Wörter in einen Tunnel, der aus dem gesicherten Gebäude zu einer Relay-Station in der Cloud führt. Sie sind ebenfalls mit dieser Relay-Station verbunden und warten darauf, die Worte zu hören.

Das Ergebnis: Anstatt 11 Sekunden auf die gesamte Antwort zu warten (wie beim Warten auf einen Brief), hören Sie das erste Wort bereits nach 0,54 Sekunden. Es fühlt sich wie ein echtes Gespräch an, obwohl das „Gehirn“ innerhalb eines gesicherten Gebäudes sitzt. Der Tunnel ist so sicher, dass selbst die Person, die die Relay-Station betreibt, die geflüsterten Worte nicht lesen kann; die Wörter sind wie ein Geheimcode verschlüsselt.

3. Der „Gedächtnis-Zusammenfasser“ (Context Awareness)

Stellen Sie sich vor, Sie führen ein langes Gespräch. Irgendwann geht dem lokalen Bibliothekar der Platz in seinem Kurzzeitgedächtnis aus. Normalerweise zwingt dies das System dazu, jede neue Frage an die teure Cloud-Bibliothek zu senden, selbst wenn die neue Frage simpel ist.

STREAM hat einen speziellen Trick: Während das Gespräch länger wird, fasst das System die alten Teile des Chats im Hintergrund in einer kurzen Notiz zusammen. Es hält die jüngsten Teile des Gesprächs frisch im Gedächtnis des Bibliothekars, komprimiert aber die alten Inhalte. Dies ermöglicht es Ihnen, viel länger ein langes Gespräch mit dem kostenlosen lokalen Bibliothekar zu führen, anstatt nur deshalb in die teurere Ebene hochgestuft zu werden, weil der Chatverlauf zu lang geworden ist.

4. Der „Universaladapter“ (HPC-as-API)

Schließlich agiert STREAM wie ein universeller Stromadapter. Normalerweise müssen Sie ein Technik-Experte sein, um die Universitätsbibliothek zu nutzen, da Sie komplexe Sicherheitssysteme navigieren müssen. STREAM hüllt all diese Komplexität ein und präsentiert sie als einen einfachen, standardisierten „Stecker“, den jede reguläre App verwenden kann. Sie müssen nicht wissen, wie die Universitätsbibliothek funktioniert; Sie stecken einfach ein, und es funktioniert.

Das Fazntit

Das Paper zeigt, dass Sie durch die Nutzung dieses „Smart Concierge“ Folgendes erreichen:

• Sie können Ihre Daten, wann immer möglich, privat und lokal halten.
• Sie können die leistungsstarken Universitäts-Supercomputer kostenlos nutzen, ohne tagelang auf eine Antwort zu warten.
• Sie zahlen die teuren Cloud-Dienste nur dann, wenn die Frage wirklich zu schwer für die anderen ist.

Es verwandelt drei kaputte, isolierte Optionen in ein einziges, reibungsloses, schnelles und kosteneffizientes Erlebnis.

Technische Zusammenfassung

Technisches Resümee: STREAM – Multi-Tier LLM-Inferenz-Middleware mit Dual-Channel HPC-Token-Streaming

Problemstellung

Forscher und Praktiker stehen vor einer fragmentierten Landschaft bei der Bereitstellung von Large Language Models (LLMs) und sind gezwungen, zwischen drei unvollkommenen Optionen zu wählen:

1. Lokale Inferenz: Kostenlos und privat, aber begrenzt durch die Hardware-Ressourcen des Nutzers (kleinere Modelle, begrenzte Kontextfenster).
2. Institutionelles HPC: Bietet leistungsstarke GPU-Ressourcen ohne Grenzkosten und hält Daten innerhalb institutioneller Grenzen, operiert jedoch hinter Firewalls, die Standard-Streaming-Ansätze blockieren, und basiert auf Batch-Ausführungsmodellen, denen Mechanismen zur inkrementellen Ausgabelieferung fehlen.
3. Kommerzielle Cloud-APIs: Bieten die Qualität von Frontier-Modellen auf Abruf, verursachen jedoch erhebliche Kosten pro Token und verfolgen Datenaufbewahrungsrichtlinien, die für sensible Forschungsdaten ungeeignet sind.

Kein existierendes System vereint diese drei Ebenen, was zu unnötigen Cloud-Ausgaben, unterausgelasteten institutionellen GPU-R Ressourcen und fragmentierten Workflows führt. Darüber hinaus scheitern Standard-Streaming-Architekturen in HPC-Umgebungen, da Rechenknoten hinter institutionellen Firewalls sitzen, die alle eingehenden Verbindungen blockieren, und Client-Maschinen oft hinter NAT liegen, wodurch sie ohne VPN oder Änderungen der Firewall-Regeln nicht erreichbar sind.

Methodik und Systemarchitektur

STREAM (Smart Tiered Routing Engine for AI Models) fungiert als Middleware-Schicht, die lokale, HPC- und Cloud-Inferenz zu einem einheitlichen gestuften Dienst vereint. Das System verarbeitet jede Anfrage durch eine standardisierte Pipeline:

1. Drei-Stufen-Routing-Architektur

Anfragen werden durch einen Complexity Judge (ein lokales LLM, spezifisch Llama 3.2 3B) in drei Stufen klassifiziert:

• LOW: Wird an lokale Modelle (z. B. Llama 3.2 3B, Gemma 3 4B-VL) geroutet, die auf Benutzergeräten oder benachbarten Servern via Ollama laufen.
• MEDIUM: Wird an institutionelle HPC-Ressourcen geroutet (z. B. Qwen 2.5-VL-72B-AWQ auf H100 NVL GPUs).
• HIGH: Wird an kommerzielle Cloud-APIs geroutet (z. B. via OpenRouter).
  Das System enthält einen Fallback-Mechanismus, bei dem Anfragen je nach Verfügbarkeit oder Fehlerzuständen in den Stufen eskalieren oder deeskalieren, um Kontinuität zu gewährleisten.

2. Dual-Channel HPC Token Streaming

Um das HPC-Streaming-Problem zu lösen, führt STREAM eine neuartige Architektur ein, die die Control Plane von der Data Plane trennt:

• Control Plane (Globus Compute): Verwaltet die federierte Authentifizierung und den Job-Dispatch. Es übermittelt eine Aufgabe, die die Anfrage und Metadaten enthält, aber keine Token-Payloads trägt.
• Data Plane (WebSocket Relay): Ein Cloud-basierter Relay-Server fungiert als Treffpunkt (Rendezvous Point).
  • Producer: Der HPC-Worker (der innerhalb einer Globus Compute Aufgabe läuft) stellt eine ausgehende Verbindung zum Relay her, liest den vLLM HTTP SSE-Stream Token für Token und leitet diese weiter.
  • Consumer: Der Client (oder Proxy) stellt eine ausgehende Verbindung zum selben eindeutigen UUID-Kanal auf dem Relay her, um die Tokens zu empfangen.
• Firewall-Traversal: Da beide Endpunkte ausgehende Verbindungen initiieren (wss:// auf Port 443), durchquert die Architektur institutionelle Firewalls und NAT, ohne dass eingehende Ports, VPNs oder Änderungen der Firewall-Regeln erforderlich sind.
• Sicherheit: Das System verwendet eine durchgehende AES-256-GCM-Verschlüsselung. Verschlüsselungsschlüssel und Kanal-Secrets werden vorab in die Worker-Umgebung geladen und niemals als Task-Argumente übertragen, wodurch sichergestellt wird, dass der Relay-Betreiber die Token-Payloads nicht lesen kann.

3. Stufenbewusste Kontext-Zusammenfassung

Um zu verhindern, dass lange Gesprächshistorien einfache Anfragen aufgrund von Kontextfenster-Limits in teurere Stufen zwingen, implementiert STREAM eine differenzielle Kompression. Wenn ein Gespräch 80 % des Kontextlimits einer Stufe erreicht, werden ältere Nachrichten in eine Zusammenfassung komprimiert (unter Verwendung des kostenlosen lokalen Modells), während die jüngsten Interaktionen im Originalzustand beibehalten werden. Dies ermöglicht es, dass einfache Anfragen auch nach 40+ Turns auf der lokalen Stufe verbleiben.

4. HPC-as-API Proxy Modus

STREAM stellt die HPC-Stufe als OpenAI-kompatiblen Endpunkt (/v1/chat/completions) bereit. Dies ermöglicht es externen Anwendungen, auf die institutionelle HPC-Inferenz zuzugreifen, ohne Globus-Credentials verwalten oder das Relay-Protokoll direkt implementieren zu müssen. Dieser Modus ist nur praktikabel, weil das Dual-Channel-Streaming die Latenz auf unter eine Sekunde reduziert.

Kernergebnisse

Das System wurde anhand eines Benchmarks mit 1.200 Anfragen über zehn Domänen (HPC, Mathematik, Physik usw.) evaluiert und über die lokale, HPC- und Cloud-Stufe gemessen.

• Routing-Genauigkeit: Der Llama 3.2 3B Complexity Judge erreichte eine Gesamtgenauigkeit von 49,0 % (1,5× über dem Zufallswert) und eine Free-Tier-Retention von 85,1 %, wodurch erfolgreich 85 % der Anfragen auf den kostenlosen lokalen oder HPC-Tiers gehalten wurden. Die primäre Einschränkung war eine niedrige Recall-Rate für "LOW"-Komplexitätsanfragen, die oft fälschlicherweise in die "MEDIUM"-Stufe geroutet wurden (ein konservativer Fehler, da beide kostenlos sind).
• Latenz (TTFT):
  • Lokal: 0,26 s mediane Time-to-First-Token (TTFT).
  • HPC (Streaming): 0,54 s mediane TTFT. Dies entspricht einer 21,1-fach höheren Verbesserung gegenüber dem Batch-Fallback-Modus (11,40 s), bei dem die TTFT der gesamten Generationszeit entspricht.
  • Cloud: 1,68 s mediane TTFT.
• Durchsatz: Sowohl der HPC-Streaming- als auch der Batch-Modus erreichten einen identischen Generationsdurchsatz (26,9 tok/s), was bestätigt, dass das Relay keinen Overhead pro Token verursacht.
• Kontext-Zusammenfassung: In synthetischen Tests verhinderte die Zusammenfassung den erzwungenen Wechsel in eine höhere Stufe für einfache Anfragen ("Was ist 2+2?"), selbst wenn der Rohkontext 41K Token überschritt (Turn 40), wodurch die Anfrage auf der lokalen Stufe blieb.

Bedeutung und Ansprüche

Die Arbeit behauptet, dass STREAM das erste System ist, das lokale, institutionelle HPC- und Cloud-LLM-Inferenz mit automatischem komplexitätsbasiertem Routing vereint. Die primäre Bedeutung liegt in der Lösung des HPC-Streaming-Problems, welches die Echtzeit-Token-Lieferung aus hinter institutionellen Firewalls heraus ermöglicht, ohne VPNs oder Firewall-Modifikationen zu benötigen.

Durch die Reduzierung der HPC-TTFT von 11,40 s auf 0,54 s macht STREAM das "HPC-as-API"-Deployment-Muster für interaktive Anwendungen praktikabel, ein Anwendungsfall, der zuvor aufgrund der Batch-Latenz unmöglich war. Das System zeigt, dass institutionelle GPU-Ressourcen ebenso zugänglich wie Cloud-APIs gemacht werden können, während gleichzeitig die Datensicherheit gewahrt und Kosten gesenkt werden. Die Autoren merken an, dass STREAM derzeit ein Forschungsprototyp ist; zukünftige Arbeiten sehen vor, den LLM-basierten Judge durch einen fein abgestimmten Textklassifizierer zu ersetreiben und reale Nutzer-Routing-Traces zu sammeln. Die Kernkomponenten (Relay und Proxy) werden als domänenagnostische PyPI-Bibliotheken (streamrelay und hpc-as-api) veröffentlicht.