Ein dreischichtiger Prioritäts-Scheduler reduziert die Latenz von On-Device-Sprachmodellen von über einer Sekunde auf unter zwei Zehntel einer Sekunde und hält Chat-Apps reaktionsschnell, selbst wenn das Telefon mit Hintergrundaufgaben beschäftigt ist. Entwickelt für einen Tensor G3-Chip, der ein Modell mit 3 Milliarden Parametern ausführt, senkt er die Latenz von 1.420 ms auf 161 ms, ohne Hintergrundprozesse zu unterbrechen.

Warum On-Device-LLMs Schwierigkeiten haben

Das Ausführen eines Large Language Models auf einem mobilen Prozessor ist ein Ressourcenengpass. Auf dem Tensor G3 beansprucht das 3-B-Modell bereits etwa 85 % der Neural Processing Unit (NPU). Wenn eine niedrigpriorisierte Aufgabe – wie etwa ein Offline-Indexer – gleichzeitig läuft, während ein Benutzer ein Chat-Fenster öffnet, springt die wahrgenommene Antwortzeit von etwa 140 ms auf 1.400 ms, eine zehnfache Verlangsamung, die Nutzer sofort bemerken.

Das Problem ist nicht nur die Geschwindigkeit. Mobile Geräte müssen zwischen UI-Flüssigkeit, Akkulaufzeit und mehreren Apps jonglieren, die alle Rechenleistung anfordern. Eine naiv implementierte Warteschlange, die Aufgaben der Reihe nach abarbeitet, zwingt den UI-Thread, auf Hintergrundarbeiten zu warten, was einen konversationellen Assistenten in eine träge Erfahrung verwandelt.

Wie der dreischichtige Scheduler funktioniert

Der neue Scheduler fügt der Inferenz-Pipeline drei koordinierte Komponenten hinzu:

  1. Priority Queue – ein Min-Heap, der eingehende Aufgaben nach einem statischen Wichtigkeitslevel sortiert.
  2. Preemption Controller – wenn eine höherpriorisierte Anfrage eintrifft, pausiert er niedrigpriorisierte Aufgaben, anstatt sie zu verwerfen.
  3. Token-Budget-Governor – begrenzt die Anzahl der Token, die eine Aufgabe generieren darf, basierend auf dem Lifecycle-Status der App.

Zusammen ermöglichen sie es einer Chat-Anfrage im Vordergrund, an die Spitze der Warteschlange zu springen, während Hintergrundaufgaben in einem pausierten Zustand verharren, bereit, fortgesetzt zu werden, sobald Ressourcen frei werden.

Prioritätsebenen und Preemption

Vier Ebenen definieren, was unterbrochen werden kann:

Ebene Beschreibung
Chat im Vordergrund Kritische UI-Interaktion
Inline-Vorschlag Autocomplete-ähnliche Hinweise
Zusammenfassung im Hintergrund Periodische Inhaltszusammenfassung
Offline-Indizierung Massendatenverarbeitung

Der Scheduler bricht eine niedrigpriorisierte Aufgabe niemals ab. Stattdessen erstellt er einen Snapshot des Key-Value (KV)-Caches des Modells – eine Struktur, die Zwischenergebnisse der Attention speichert – und parkt die Aufgabe. Wenn die hochpriorisierte Anfrage abgeschlossen ist, stellt der Controller den Snapshot wieder her und lässt die Hintergrundaufgabe dort weitermachen, wo sie aufgehört hat. Dieser „Pause-and-Resume“-Ansatz vermeidet die kostspielige Neuberechnung, die auftreten würde, wenn die Aufgabe von vorne gestartet werden müsste.

Ein teilweises Verwerfen (Eviction) des KV-Caches reduziert den Overhead weiter. Der statische System-Prompt bleibt im Cache, während nur dynamische Konversationsschritte verworfen werden. Das Ergebnis ist eine Reduzierung der Kosten für das erneute Prefilling des Modells nach einer Pause um 40 %–60 %.

Verwaltung von Token-Budgets ohne Timer

Viele Implementierungen verlassen sich auf Timer, um zu schätzen, wann eine Aufgabe CPU- oder NPU-Zeit freigeben sollte. Timer sind unpräzise; sie können entweder die UI ausbremsen oder den Chip unterauslasten. Der Scheduler ersetzt Timer durch Androids ProcessLifecycleOwner, der Lifecycle-Events ausgibt, die zuverlässig anzeigen, ob sich die App im Vordergrund oder im Hintergrund befindet.

  • ON_RESUME – die App erhält das volle Rechenbudget zurück, sodass ausstehende Aufgaben im Vordergrund ungehindert ausgeführt werden können.
  • ON_STOP – die App drosselt Hintergrundaufgaben auf etwa 25 % ihres normalen Token-Budgets, um Spielraum für plötzliche UI-Anfragen zu bewahren.

Durch die Kopplung der Ressourcenallokation an Lifecycle-Events reagiert das System auf das tatsächliche Nutzerverhalten anstatt auf willkürliche Zeitschlitze.

Leistungssteigerungen und Kompromisse

Unter einer naiven First-Come-First-Served-Warteschlange treibt eine Hintergrundaufgabe die Latenz des Chats im Vordergrund auf etwa 1.420 ms. Mit aktivem Prioritäts-Scheduler schließt dieselbe Chat-Anfrage in etwa 161 ms ab – eine zehnfache Verbesserung, die ein flüssiges Nutzererlebnis wiederherstellt.

Das Fortsetzen einer pausierten Aufgabe erhöht die Gesamtausführungszeit um etwa 22 %. Da Hintergrundarbeiten nicht kritisch sind, bleibt dieser Kompromiss akzeptabel, insbesondere wenn die UI reaktionsschnell bleibt.