💻 computer science

Multi-Tenant Edge-Cloud Hybrid LLM Serving using Speculative Decoding and Quantization

Dieses Paper schlägt eine Multi-Tenant-Edge-Cloud-Hybrid-LLM-Serving-Architektur vor, die W4A16-quantisiertes spekulatives Dekodieren mit asynchroner Kommunikation und einem Multi-Tenant-Verifikations-Orchestrator kombiniert, um gleichzeitig die Herausforderungen in Bezug auf Datenschutz, Latenz und Ressourcenauslastung zu adressieren.

Ursprüngliche Autoren: Jui-Yu Lin

Veröffentlicht 2026-07-13

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Jui-Yu Lin

Originalarbeit lizenziert unter CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie hätten ein superintelligentes Robotergehirn (ein Large Language Model), das Geschichten schreiben, Mathe lösen und wie ein Mensch chatten kann. Aber es gibt einen Haken: Dieses Gehirn ist so riesig, dass es nicht in Ihre Tasche passt, und wenn Sie versuchen, es überallhin mitzunehmen, stirbt der Akku Ihres Telefons sofort.

Wir haben also zwei schlechte Optionen:

Die Cloud: Sie senden Ihre Fragen an einen riesigen Supercomputer in der Ferne. Er ist klug, aber die Nachricht braucht lange, um dorthin und wieder zurück zu reisen (wie eine Nachricht per Brieftaube), was den Chat langsam und klobig wirken lässt. Zudem müssen Sie der Brieftaube Ihre privaten Geheimnisse anvertrauen.
Der Edge (Die lokale Kante): Sie versuchen, das ganze Gehirn auf Ihrem Telefon laufen zu lassen. Es ist schnell und privat, aber Ihr Telefon ist nicht stark genug, und die Antworten könnten etwas albern sein, weil das Modell zu sehr geschrumpft werden musste.

Dieses Paper schlägt einen cleveren Mittelweg vor: ein Zusammenspiel zwischen Ihrem Telefon und der Cloud, das wie ein Hochgeschwindigkeits-Staffellauf mit einer Besonderheit funktioniert.

Das Teamwork: Der „Entwurfs“-Gehilfe und der „Verifizierungs“-Chef

So funktioniert das neue System laut den Autoren:

1. Der Edge-Gehilfe (Ihr Telefon)
Anstatt darauf zu warten, dass die Cloud antwortet, lässt Ihr Telefon eine winzige, superkompakte Version des Robotergehirns laufen. Die Autoren schlagen eine spezifische „Schrumpf-Technik“ namens W4A16-Quantisierung vor. Stellen Sie sich das wie das Komprimieren eines hochauflösenden Films in eine winzige Datei vor, die aber immer noch gut genug aussieht, um die Handlung zu verstehen.

Die Magie: Diese winzige Version ist klug genug, um die nächsten paar Wörter (Tokens) eines Satzes sehr schnell zu erraten. Das Paper stellt fest, dass das Schrumpfen des Modells es zwar etwas weniger genau macht (der „Perplexity“-Wert steigt von 5,47 auf etwa 5,74 oder 5,83), aber es ist immer noch gut genug, um eine solide Vermutung anzustellen.
Die Regel: Die Autoren argumentieren ausdrücklich gegen eine noch stärkere Schrumpfung (wie W4A4). Sie sagen, wenn man es zu sehr komprimiert, werden die Vermutungen so schlecht, dass das System Zeit mit der Korrektur verschwendet, was alles verlangsamt. Daher bleiben sie bei der „genau richtigen“ W4A16-Größe.

2. Der Cloud-Chef (Der Supercomputer)
Während Ihr Telefon damit beschäftigt ist, die nächsten Wörter zu erraten, leistet die Cloud die schwere Arbeit. Sie besitzt das vollumfängliche, perfekte Robotergehirn. Ihre Aufgabe ist es nicht, bei Null anzufangen, sondern lediglich zu verifizieren, was das Telefon erraten hat.

Die Besonderheit: In alten Systemen würde das Telefon raten, dann stoppen und warten, bis die Cloud „Ja“ oder „Nein“ sagt. Das nennt sich „Mutual Waiting“ (gegenseitiges Warten), und es ist wie ein Tennisspiel, bei dem man wartet, bis der Ball zurückkommt, bevor man überhaupt den Schläger schwingt.
Der neue Schachzug: Dieses Paper schlägt ein asynchrones (nicht-blockierendes) Protokoll vor. Das Telefon rät die nächsten Wörter weiter, während die Cloud noch die vorherigen überprüft. Es ist wie ein Förderband, auf dem das Telefon weiterhin Kartons verpackt, während die Cloud die bereits auf dem Band liegenden Kartons stempelt. Dies verbirgt die Reisezeit (Netzwerklatenz), sodass man die Verzögerung nicht spürt.

3. Das Multi-Tenant-Orchester
Hier kommt der zweite große Trick. Normalerweise, wenn 100 Leute die Cloud nutzen, gibt der Computer jedem Menschen sein eigenes kleines, leeres Zimmer. Das ist verschwenderisch.
Die Autoren schlagen einen Multi-Tenant-Orchestrator vor. Stellen Sie sich eine belebte Restaurantküche vor. Anstatt jedem Kunden einen eigenen privaten Koch zur Seite zu stellen (der nur herumsitzt und auf eine Bestellung wartet), hat die Küche ein super effizientes Team, das Bestellungen von allen gleichzeitig entgegennimmt.

Die Cloud gruppiert die Anfragen vieler verschiedener Telefone zu einem großen „Batch“ (Paket), um alle gleichzeitig zu prüfen.
Dies hält die leistungsstarken Grafikkarten (GPUs) der Cloud bei 100 % Kapazität, anstatt leer zu laufen, während sie auf den einen Nutzer warten, der gerade tippt.

Was die Mathematik sagt (Aber halten Sie es einfach)

Die Autoren haben ein mathematisches Modell erstellt, um zu sehen, ob diese Idee standhält. Sie haben noch keinen massiven Praxistest mit tausenden Nutzern durchgeführt; stattd allgebrauch haben sie Formeln verwendet, um zu simulieren, wie das System sich verhalten sollte.

Das Tempolimit: Sie haben berechnet, dass die Internetverzögerung aus der Gleichung verschwindet, wenn die Cloud schnell genug ist, um einen Batch an Vermutungen zu prüfen, während das Telefon den nächsten Batch erstellt.
Der Flaschenhals: Das System funktioniert am besten, wenn die Cloud nicht überfordert ist. Wenn zu viele Leute zur Party kommen, gerät die Cloud in eine „Warteschlangenverzögerung“ (Queuing Delay). Das Modell legt nahe, dass man durch eine sorgfältige Abstimmung der Anzahl der Nutzer im System die Geschwindigkeit hoch halten kann.
Das Ergebnis: In ihren Simulationen deutet dieses Setup darauf hin, dass das System Geschwindigkeiten erreichen kann, die nahe an dem liegen, was man beim rein lokalen Betrieb auf dem Telefon erreicht – allerdings mit der Genauigkeit des riesigen Cloud-Gehirns, während die privaten Daten weitgehend auf dem eigenen Gerät bleiben.

Was dieses Paper nicht sagt

Es ist wichtig zu wissen, was dieses Paper nicht behauptet:

Es wurde noch nicht durch einen echten Einsatz mit tausenden Nutzern in der Praxis bewiesen. Die Autoren schlagen diese Architektur basierend auf theoretischen Modellen und bestehenden Werkzeugen (wie llama.cpp für Telefone und vLLM für die Cloud) vor.
Es behauptet nicht, alle Datenschutzprobleme zu lösen. Obwohl die Rohdaten der Prompts lokal bleiben, werden dennoch einige spekulative Daten an die Cloud gesendet.
Es sagt nicht, dass dies für jede Modellgröße funktioniert. Die Mathematik beruht auf spezifischen Bedingungen, bei denen die Cloud schnell genug ist, um mit der Rate der Vermutungen des Telefons Schritt zu halten.

Das Fazit

Die Autoren schlagen einen Weg vor, KI-Chats sofort und privat erscheinen zu lassen, ohne einen Supercomputer in der Hosentasche zu benötigen. Indem sie das Telefon die schnellen, „gut genug“ Entscheidungen treffen lassen und die Cloud die Aufgaben in einer geschäftigen, effizienten Gruppe prüfen lässt, schlagen sie vor, dass wir die langsamen Internetverzögerungen umgehen können, die normalerweise das Erlebnis ruinieren. Es ist ein vielversprechender Entwurf für die Zukunft und legt nahe, dass wir, wenn wir das richtige „Staffellauf“-Team aufbauen, das Beste aus beiden Welten erhalten können.

Technisches Resümee: Multi-Tenant Edge-Cloud-Hybride LLM-Bereitstellung mittels Spekulativer Dekodierung und Quantisierung

1. Problemstellung

Die Bereitstellung von Large Language Models (LLMs) steht vor einem grundlegenden Zielkonflikt zwischen Edge-Inferenz und Cloud-Inferenz.

Edge-Inferenz: Bewahrt die Privatsphäre der Nutzer und reduziert die Infrastrukturkosten, ist jedoch durch die Speicher- und Rechenkapazitäten der Edge-Hardware stark eingeschränkt.
Cloud-Inferenz: Bietet hohe Rechenleistung, führt jedoch zu erheblicher Netzwerk-Latenz, Risiken des Datenabflusses während der Übertragung und einer ineffizienten Ressourcennutzung aufgrund der intermittierenden Natur der Nutzeranfragen.

Bestehende hybride Architekturen versuchen, diese Lücke zu schließen, leiden jedoch oft unter einem „Mutual Waiting“-Engpass (gegenseitiges Warten). In der traditionellen verteilten spekulativen Dekodierung muss der Edge-Client die Ausführung blockieren, während er auf die Verifizierung der generierten Token durch den Cloud-Server wartet. Wenn die Round-Trip-Time (RTT) im Wide-Area Network (WAN) die Ausführungszeit der Cloud übersteigt, verharrt das System im Leerlauf, was die Vorteile der Latenzminderung zunichtemacht. Darüber hinaus führt die Dedizierung von Cloud-Instanzen für einzelne Edge-Nutzer zu einer systemischen Ressourcenfragmentierung und einer geringen GPU-Auslastung.

2. Methodik

Das Paper schlägt ein Multi-Tenant-Hybrid-Inferenz-Framework vor, das drei Kerntechniken integriert: Quantisierte Spekulative Dekodierung, Asynchrone Kommunikation und Multi-Tenant-Verifizierungs-Orchestrierung.

2.1 Quantisierte Entwurfserstellung auf der Edge-Seite

Um die Speicherbeschränkungen der Edge zu adressen, verwendet das System ein W4A16-quantisiertes Draft-Modell (4-Bit-Gewichte, 16-Bit-Aktivierungen), das lokal auf dem Edge-Gerät läuft.

Begründung: Während extreme Quantisierung (z. B. W4A4) den Speicher weiter reduziert, verursacht sie eine signifikante Verschlechterung der Perplexität (PPL), was die Token-Akzeptanzrate senkt.
Auswahl: Die Autoren analysieren LLaMA-2 7B auf WikiText-2 und zeigen, dass W4A16 (via OmniQuant oder GPTQ) im Vergleich zum Baseline-Modell nur einen Genauigkeitsverlust von 5–7 % (PPL ~5,74–5,83 gegenüber 5,47 Baseline) aufweist. Diese Konfiguration bewahrt eine ausreichende Übereinstimmung mit dem Cloud-Zielmodell, um eine hohe Akzeptanzrate zu gewährleisten, während sie gleichzeitig den Speicherbedarf drastisch reduziert.

2.2 Asynchrones Kommunikationsprotokoll

Um den „Mutual Waiting“-Engpass zu eliminieren, ersetzt das Framework die synchrone Blockierung durch ein nicht-blockierendes, asynchrones Protokoll, das von PicoSpec inspiriert ist.

Mechanismus: Das Edge-Gerät entwirft kontinuierlich Token-Sequenzen basierend auf lokalen Top-1-Vorhersagen, ohne auf die Cloud-Verifizierung zu warten.
Pipeline-Entkopplung: Die Edge generiert den nächsten Block von Tokenen ( $k+1$ ), während die Cloud den vorherigen Block ( $k$ ) verifiziert. Dies überlappt die Zeit für das Edge-Drafting ( $T_{draft}$ ) und den Netzwerktransit ( $T_{network}$ ) mit der Zeit für die Cloud-Verifizierung ( $T_{verify}$ ) und maskiert so effektiv die WAN-Latenz.

2.3 Multi-Tenant Cloud-Verifizierungs-Orchestrator

Um die Ressourcen-Leerlaufzeiten auf der Cloud-Seite anzugehen, führt das System einen Multi-Tenant-Orchestrator ein, der Verifizierungsanfragen von heterogenen Edge-Geräten aggregiert.

Architektur: Anstatt dedizierter Sitzungen behandelt die Cloud das Zielmodell als global geteilte Ressource.
Scheduling: Unter Anwendung von Prinzipien dezentraler Datenflüsse (z. B. Pathways) und LLM-nativer Bereitstellung (z. B. Orca, Chunked Prefill) multipliziert der Orchestrator konkurrierende Anfragen in einzelne Hardware-Batches.
Vorteil: Dies gewährleistet die GPU-Sättigung, selbst wenn einzelne Tenants zeitweilige Netzwerkverzögerungen erleben, wodurch verhindert wird, dass lokalisierte Störungen die Latenzstrafen auf das gesamte System übertragen.

3. Theoretische Modellierung

Das Paper formuliert die Leistungs-Trade-offs mathematisch, um die Effizienz des Systems zu demonstrieren.

Spekulative Akzeptanz: Die erwartete Anzahl der akzeptierten Token $E[A]$ wird aus der Akzeptanzwahrscheinlichkeit $\alpha$ abgeleitet. Die Autoren argumentieren, dass W4A16 entscheidend ist, um $\alpha$ hoch zu halten, da eine aggressivere Quantisierung $E[A]$ exponentiell reduzieren würde.
Latenzanalyse:
- Synchrone Latenz: $T_{sync} = \gamma \cdot T_{draft} + T_{network} + T_{verify}$ (strikt additiv).
- Asynchrone Latenz: $T_{async}$ ist durch das Maximum der parallelen Phasen begrenzt. Das System erreicht eine optimale Leistung, wenn $T_{verify} \approx \gamma \cdot T_{draft} + T_{network}$ gilt, was eine ausgewogene Pipeline schafft, in der der Netzwerk-Overhead verborgen wird.
Durchsatz-Grenzen: Die Cloud-Verifizierungs-Latenz wird mithilfe des Roofline-Modells modelliert, begrenzt entweder durch die Speicherbandbreite oder den Rechen-Durchsatz. Der Orchestrator zielt darauf ab, die Batch-Größe $B$ optimal zu halten, um die GPU zu sättigen, ohne übermäßige Warteschlangen-Verzögerungen ( $T_{queue}$ ) zu verursachen.

4. Zentrale Beiträge

Das Paper beansprucht drei primäre Beiträge:

WAN-Latenzmaskierung: Die Einführung eines nicht-blockierenden Kommunikationsprotokolls, das das Edge-Drafting von der Cloud-Verifizierung entkoppelt und somit das Problem des gegenseitigen Wartens überwindet, das bei der verteilten spekulativen Dekodierung inhärent ist.
Durchsatzmaximierung: Ein Multi-Tenant-Cloud-Orchestrator, der Verifizierungsanfragen von mehreren Edge-Geräten aggregiert, die GPU-Auslastung maximiert und Ressourcenfragmentierung verhindert.
Privatsphäre-schützende Inferenz: Ein Design, das die Preisgabe der Privatsphäre minimiert, indem es nur partielle spekulative Daten (Draft-Token) statt roher Nutzer-Prompts an die Cloud übermittelt.

5. Ergebnisse und Evaluationsstrategie

Das Paper ist primär ein architektonischer Vorschlag und eine theoretische Analyse und kein Bericht über empirische experimentelle Ergebnisse.

Theoretische Grenzen: Die Analyse zeigt, dass das System unter optimalen Bedingungen (in denen die Pipeline lokal durch die Edge-Leistung begrenzt ist) die Netzwerk-Transit-Verzögerungen eliminieren und die Edge-Drafting-Geschwindigkeit als Inter-Token-Latenz (ITL) erreichen kann.
Vorgeschlagene Evaluierung: Die Autoren skizzieren eine zukünftige Evaluierungsstrategie, um das System gegen Cloud-only-Pipelines und synchrone verteilte Spekulation zu benchmarken. Zu den Schlüsselmetriken gehören:
- Inter-Token-Latenz (ITL): Zur Validierung der Latenzmaskierung.
- Token-Akzeptanzrate ( $\alpha$ ): Um die Übereinstimmung zwischen W4A16-Drafts und FP16-Targets zu bestätigen.
- Cloud-Durchsatz: Um die aggregierten Generierungsraten unter hoher Konkurrenz zu messen.
Implementierungs-Blueprint: Das Paper schlägt einen praktischen Stack vor, der llama.cpp/MLC-LLM für das Edge-Drafting, vLLM (mit PagedAttention) für die Cloud-Verifizierung und Ray für die asynchrone Orchestrierung nutzt.

6. Bedeutung und Ansprüche

Das Paper positioniert dieses Framework als einen skalierbaren und privatsphäre-schützenden Pfad für die kollaborative Edge-Cloud-LLM-Bereitstellung.

Entkopplung: Es entkoppelt die Edge-Ausführung effektiv von den Cloud-Handshake-Schleifen und eliminiert damit den „Mutual Waiting“-Engpass, der bisherige hybride Ansätze behindert hat.
Skalierbarkeit: Die theoretische Analyse deutet darauf hin, dass das System unter Multi-Tenant-Workloads effizient skaliert, indem es das Cloud-Zielmodell als geteilte Ressourcen-Graph statt als eine Reihe von blockierenden Sitzungen behandelt.
Balance: Es bietet eine Lösung, die Bereitstellungseffizienz, Privatsphäre und Inferenz-Durchsatz harmonisiert und den traditionellen Zielkonflikt aufbricht, bei dem die Verbesserung einer Metrik die anderen verschlechtert.

Die Autoren kommen zu dem Schluss, dass das Framework zwar theoretisch die Netzwerkverzögerungen eliminiert und die Edge-Generierungsgeschwindigkeiten erreicht, jedoch zukünftige Arbeiten erforderlich sind, um diese Leistungsresultate durch eine End-to-End-praktische Implementierung unter Verwendung verteilter Serving-Infrastrukturen zu validieren.