🤖 AI

Not Every Sync Is Safe: Calibrated DiLoCo Scheduling for Shared AI Infrastructure

Dieses Paper führt Workload-Aware DiLoCo (WA-DiLoCo) ein, ein kalibriertes Scheduling-Framework, das zeigt, wie die Einbeziehung von Burst-Prognosen und strengen gematchten-random Baselines die SLO-Verletzungen in gemeinsam genutzter KI-Infrastruktur im Vergleich zu bestehenden prognosefreien Policies signifikant reduzieren kann.

Ursprüngliche Autoren: Maxwell Twelftree, David Lemphers, An-chi He, Yue Yang

Veröffentlicht 2026-07-07

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Maxwell Twelftree, David Lemphers, An-chi He, Yue Yang

Originalarbeit lizenziert unter CC BY 4.0 (http://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 leiten eine geschäftige Restaurantküche (die KI-Flotte), in der zwei sehr unterschiedliche Aktivitäten gleichzeitig stattfinden:

Das Vorbereitungsteam (Training): Eine Gruppe von Köchen arbeitet an einem massiven, komplexen Rezept. Sie müssen das Gericht probieren, die Gewürze anpassen und dann ihre Änderungen dem Chefkoch mitteilen, damit alle ihre Rezeptkarten aktualisieren können. Dieses Rufen geschieht in „Synchronisationsmomenten“.
Die Kellner (Servieren): Gleichzeitig stürzen sich Kellner in die Küche, um fertige Mahlzeiten für Kunden abzuholen. Diese Kunden sind sehr ungeduldig; wenn das Essen zu lange dauert, werden sie wütend (dies ist eine SLO-Verletzung).

Das Problem: Das „Rufen“ unterbricht das „Bestellen“

Auf die alte Art der Dinge hätten die Köche ihre Updates in festen Zeitintervallen (z. B. alle 5 Minuten) an den Chefkoch gerufen, ungeachtet dessen, was gerade in der Küche los war.

Das Papier stellt eine neue Methode namens DiLoCo vor. Anstatt alle 5 Minuten zu rufen, arbeiten die Köche eine Weile leise für sich selbst und rufen dann alle auf einmal. Das spart Zeit.

Aber hier ist der Haken: Wenn die Köche schließlich rufen (der „Outer Merge“), dauert das etwa 8 Sekunden. Während dieser 8 Sekunden herrscht Chaos in der Küche. Die Kellner können ihre Speisen nicht abholen, die Telefone klingeln ununterbrochen und die Kunden werden wütend.

Die große Frage, die das Papier stellt, lautet: Wann ist es sicher zu rufen?

Wenn Sie rufen, während ein Ansturm von Bestellungen eingeht, ruinieren Sie den Service.
Wenn Sie rufen, wenn es in der Küche ruhig ist, bemerkt es niemand.

Der Fehler in der bisherigen Forschung

Frühere Studien versuchten herauszufinden, wann der beste Zeitpunkt zum Rufen ist. Sie verglichen ihre „smarten“ Zeitpläne mit einem „dummen“ Zeitplan, der zu festen Zeiten rief. Sie behaupteten: „Unser smarter Zeitplan ist 20 % besser!“

Die Autoren sagen: „Moment mal. Das ist kein fairer Test.“

Stellen Sie sich vor, Sie haben ein Budget von drei Rufen für den gesamten Tag.

Der dumme Zeitplan: Ruft um 9:00, 13:00 und 17:00 Uhr. (Er könnte genau in eine Stoßzeit fallen).
Der „smarte“ Zeitplan: Versucht, Stoßzeiten zu vermeiden.
Das „Matched Random“ (das neue Kontrollinstrument des Papiers): Dies ist die Geheimwaffe des Papers. Es nimmt exakt dasselbe Budget von drei Rufen, platziert diese aber zu zufälligen Zeiten.

Das Papier argumentiert, dass wenn Ihr „smarter“ Zeitplan nicht einen zufälligen Zeitplan schlagen kann, der die gleiche Anzahl an Rufen hat, dann bewirkt Ihre „Intelligenz“ eigentlich gar nichts. Sie könnten einfach nur Glück gehabt haben, oder der zufällige Zeitplan hat die Stoßzeiten versehentlich ebenfalls vermieden.

Die Lösung: „Kalibrierte“ Zeitplanung

Die Autoren entwickelten ein System namens WA-DiLoCo (Workload-Aware DiLoCo). Denken Sie an einen Küchenmanager, der zwei Dinge betrachtet, bevor er entscheidet, wann gerufen wird:

Wie viel Fortschritt die Köche gemacht haben (Haben sie genug neue Gewürze, um sie zu teilen?).
Wie beschäftigt die Kellner sind (Ist es in der Küche gerade hektisch?).

Der Manager verwendet einen Score. Wenn die Küche beschäftigt ist, sinkt der Score, und der Manager sagt: „Warte, ruf noch nicht!“ Wenn die Küche ruhig ist, steigt der Score, und der Manager sagt: „Nur zu, ruf jetzt!“

Das „Kalibrierungs“-Protokoll (Der Realitätscheck)

Das Papier führt ein strenges Regelwerk (ein Protokoll) ein, um zu beweisen, dass dieser Manager tatsächlich funktioniert. Sie sagen nicht einfach nur „es funktioniert“. Sie beweisen es in drei Schritten:

Der Stresstest: Sie simulieren eine Küche mit künstlichem, vorhersehbarem Chaos. Der Manager schneidet hier gut ab.
Das Replay einer echten Küche: Sie nehmen den Zeitplan des Managers und spielen ihn gegen echte Kundendaten aus einem echten KI-System (vLLM) ab.
- Ergebnis: In einer stetigen, geschäftigen Küche schneidet der Manager besser ab als ein fester Timer, aber ein zufälliger Zeitplan macht fast das Gleiche. Der Manager hat noch nicht bewiesen, dass er etwas Besonderes ist.
- Ergebnis: In einer „bursty“ Küche (in der Bestellungen in plötzlichen, unvorhersehbaren Wellen eingehen) glänzt der Manager. Indem der Manager das Muster der Wellen analysiert, kann er das „Rufen“ in die ruhigen Lücken zwischen den Wellen verstecken.
Die Vorhersage: Der Manager erhält ein Kristallornament (EWMA-Prognose), das die nächste Welle von Bestellungen vorhersagt. Mit diesem Kristallornament kann der Manager dem Chaos noch besser ausweichen.

Die Ergebnisse (In einfachen Worten)

Ohne das Kristallornament: Der Manager ist gut, aber manchmal erreicht ein zufälliger Zeitplan durch Glück das gleiche Ergebnis.
Mit dem Kristallornament: Der Manager schlägt den Zufalls-Zeitplan signifikant.
- In ihren Tests sank die Rate der „wütenden Kunden“ (SLO-Verletzungen) von 6,54 % auf 5,09 %.
- Das bedeutet, dass weniger Kunden wütend wurden, weil die Küche nicht während der geschäftigsten Momente unterbrochen wurde.

Die große Lektion

Die Hauptbotschaft des Papiers ist nicht nur „wir haben einen besseren Scheduler gebaut“. Es geht darum, wie wir beweisen, dass er funktioniert.

Bevor Sie behaupten, dass Ihr neues KI-System schneller oder besser für die Kunden ist, müssen Sie:

Es mit einem zufälligen Zeitplan vergleichen, der über die gleichen Ressourcen verfügt (nicht nur mit einem festen Timer).
Es mit echten Kundendaten testen, nicht nur mit fiktiven Simulationen.
Zeigen, dass Ihr System die „geschäftigen Fenster“ tatsächlich besser vermeidet als das bloße Glück.

Wenn Sie den Zufalls-Zeitplan in einem realen Test nicht schlagen können, haben Sie das Problem nicht wirklich gelöst, sondern hatten nur Glück. Das Papier beweist, dass man mit der richtigen „Kalibrierung“ und ein wenig Vorhersage die Küche reibungsloser laufen lassen kann, ohne die Köche auszubremsen.

Technisches Resümee: Nicht jeder Sync ist sicher: Kalibriertes DiLoCo-Scheduling für geteilte KI-Infrastrukturen

Problemstellung

In fragmentierten industriellen KI-Flotten, in denen das Training Hardware mit latenzsensibler Inferenz teilt (z. B. vLLM-Sidecars), steht das konventionelle DiLoCo-ähnliche Training vor einer kritischen Herauschen in der Produktion: Wann ist ein Synchronisationsvorgang sicher?

Während DiLoCo die Kommunikation reduziert, indem es „Learner Islands“ erlaubt, lokale Optimierungsschritte vor gelegentlichen äußeren Synchronisationen durchzuführen, versäumen es bestehende Scheduling-Studien oft, den Wert des Timings vom Wert des Budgets zu isolieren. Die meisten Evaluierungen vergleichen workload-bewusste Policies gegen Festintervall-Baselines (z. B. alle 256 oder 512 Schritte). Eine Festintervall-Baseline kann jedoch lediglich seltener oder zu anderen Zeiten synchronisieren als die Alternative, anstatt echte Workload-Bewusstsein (Workload Awareness) zu demonstrieren.

Das Kernproblem besteht darin, dass ein äußerer Merge Host-, Netzwerk- und Checkpoint-Ressourcen für eine feste Dauer (z. B. 8 Sekunden) beansprucht. Wenn dieses Zeitfenster mit latenzsensitiven Anfragen überlappt, führt dies zu Verletzungen der Service Level Objectives (SLOs). Die Frage ist nicht nur, wie oft synchronisiert werden soll, sondern welche spezifischen Fenster zu wählen sind, um Hochlastphasen zu vermeiden, und ob eine Policy zuverlässig besser abschneiden kann als eine zufällige Platzierung desselben Synchronisationsbudgets.

Methodik

1. Das Kalibrierungsprotokoll

Die Autoren schlagen ein rigoroses Evaluierungsprotokoll vor, um zu bestimmen, ob eine Synchronisations-Policy den Anspruch auf Verbesserung der Serving-SLOs verdient. Das Protokoll führt eine Matched Random Deferral (Gleichgerichtete Zufallsverzögerung) als Kontrollinstanz ein:

Konzept: Eine nicht-einsetzbare Kontrollinstanz, die exakt das Synchronisationsbudget (Anzahl der Merges) der evaluierten Policy erbt, aber die Platzierung dieser Merges innerhalb des zulässigen Zeitkorridors randomisiert.
Zweck: Dies trennt die Synchronisationsfrequenz von der Fensterplatzierung. Wenn eine workload-bewusste Policy nicht besser als eine zufällige Platzierung desselben Budgets abschneidet, hat sie keinen „Placement Gain“ (Platzierungsgewinn) demonstriert.
Gate: Ein Anspruch auf SLO-Verbesserung ist nur gültig, wenn die Policy die Matched-Random-Envelope in einem kalibrierten Regime schlägt.

2. Workload-Aware DiLoCo (WA-DiLoCo)

Das Paper instanziiert dieses Protokoll mit WA-DiLoCo, einem leichtgewichtigen, score-basierten Controller:

Inputs: Lernfortschritt (Loss-Reduktion, Token-Beitrag, Staleness) und Flottenbelastung (Netzwerk, Serving, Checkpoint).
Scoring: Ein linearer Score $s_i$ wird für jeden Lerner berechnet, der Fortschritt positiv und Belastung negativ gewichtet. In der Zielkonfiguration trägt die Serving-Belastung das höchste Gewicht.
Entscheidungslogik: Der Koordinator synchronisiert, wenn die Differenz seit dem letzten Merge $H_{min}$ (128 Schritte) überschreitet und der durchschnittliche Score über einem Schwellenwert liegt, oder wenn die Differenz $H_{max}$ (512 Schritte) erreicht. Dies stellt sicher, dass Merges innerhalb eines begrenzten Korridors bleiben.

3. Kalibrierte Überlappung und Prognose

Für burstartige Workloads identifizieren die Autoren, dass eine direkte Überlappung mit Sidecar-Anfragen ein präziseres Kostensignal ist als allgemeine Druckmetriken.

Offline Calibrated-WA: Ein Oracle, das den vollständigen Burst-Trace beobachtet und die Fenster mit der geringsten Überlappung im zulässigen Bereich neu auswählt. Dies etabliert die theoretische Obergrenze dessen, was möglich ist.
Online Forecasting: Um dies einsatzbereit zu machen, erweitern die Autoren den Controller um eine einstufige EWMA-Prognose (Exponential Weighted Moving Average) der Anfrageraten. Dies ermöglicht es dem Controller, Kandidatenfenster basierend auf der erwarteten Überlappung zu bewerten, bevor der Merge gestartet wird.

Zentrale Beiträge

Kalibriertes Evaluierungsprotokoll: Das Paper identifiziert eine Lücke in der bestehenden Literatur, in der Festintervall-Baselines Budget und Platzierung vermengen. Das Protokoll schreibt vor, den Real-Sidecar Effect-Size Transfer, einen No-Sync Load Match und eine Matched-Random-Envelope zu melden, bevor Verbesserungen der Serving-SLOs beansprucht werden können.
Matched Random Deferral Control: Führt eine nicht-einsetzbare Kontrollinstanz ein, die das Budget des Schedulers erbt, aber die Platzierung randomisiert. Dies dient als strikte Baseline; ein Scheduler, der diese zufällige Platzierung nicht schlägt, hat lediglich das Budget kontrolliert, nicht aber die Workload.
Bounded Calibrated Scheduling Formulation: Die Autoren formalisieren die Synchronisation als zulässige Platzierung innerhalb eines Min/Max-H-Korridors. Sie beweisen, dass unter einem kalibrierten Überlappungsmodell das Offline-kalibrierte Scheduling innerhalb der Matched-Budget-Klasse nahezu optimal ist, während die Online-Variante bei Prognosefehlern kontrolliert degradiert.
Umfassende Real-Sidecar-Regime-Studie: Die Studie evaluiert Policies über gewöhnliche, druckintensive, stetig synchronisationsintensive sowie burstartige und nicht-periodische Serving-Regime unter Verwendung realer vLLM-Sidecar-Replays.

Ergebnisse

Die Experimente zeigen, dass die Wirksamkeit des Schedulings stark vom Workload-Regime abhängt:

Gewöhnliche/Druckintensive Regime: In gewöhnlichen Sidecar-Traces übertrugen sich synthetische Druckeffekte nicht auf die reale Latenz (p95-Verhältnisse $\approx$ 1,0). In druckintensiven Regimen waren alle Policies gesättigt, und keine Policy dominierte.
Stetige Sync-intensive Regime: WA-DiLoCo übertraf die Fixed-Interval- und Pressure-Gate-Baselines. Es tat jedoch mit der Matched-Random-Deferral-Kontrolle statistisch gleich ( $p=0,56$ ), was darauf hindeutet, dass bei stetigen Lasten eine einfache zufällige Platzierung oft ausreichend ist und kein starker Dominanzanspruch erhoben werden kann.
Burst-Regime: Hier liefert die Kalibrierung den Wert.
- Offline Calibrated-WA: Reduzierte die Sync-Excess-SLO-Verletzungen auf 4,45 % und schlug damit signifikant die Matched-Random-Envelope (6,26 %) und WA-DiLoCo (6,92 %).
- Online Forecaster: Der EWMA-erweiterte Online-Controller reduzierte die SLO-Verletzungen von 6,54 % (Matched Random) auf 5,09 % in realen vLLM-Sidecar-Replays ( $p=0,021$ ). Dies entspricht einem Platzierungsgewinn von 1,46 Prozentpunkten, was die SLO-Verletzungen um etwa 60 Anfragen pro Sidecar pro zehn Minuten bei dem getesteten Durchsatz reduziert.

Bedeutung und Ansprüche

Die primäre Bedeutung des Papers ist methodischer Natur und nicht rein algorithmisch. Es argumentiert, dass nicht jeder Sync sicher ist und dass die Behauptung von SLO-Verbesserungen eine höhere Evidenzstufe erfordert.

Das Protokoll zuerst: Die Autoren behaupten, dass die „einsatzfähige Lehre“ das Protokoll selbst ist: Forscher müssen den Real-Sidecar Effect-Size Transfer, einen No-Sync Load Match und eine Matched-Random-Envelope melden, bevor sie Serving-SLO-Verbesserungen beanspruchen.
Bescheidene Ansprüche zur Einsatzfähigkeit: Das Paper ist bescheiden hinsichtlich des aktuellen Zustands des Online-Controllers. Während das Offline-Oracle eine ausnutzbare Struktur in Burst-Traces beweist, konnte der Online-Controller (ohsten ohne Prognose) die Matched-Random-Baseline nicht signifikant schlagen. Der erfolgreiche Einsatz-Claim stützt sich spezifisch auf die prognose-erweiterte Variante in einer spezifischen nicht-periodischen Trace-Familie.
Limitierungen: Die Autoren betonen explizit, dass es sich um Stress-Test-Replay-Studien handelt, nicht um Live-Produktionseinsätze. Die 8-sekündige Merge-Dauer ist konfigurationsspezifisch, und der Online-Controller bleibt eine „unvollständige Implementierung“ der kalibrierten Scheduling-Idee, die in zukünftigen Einsätzen eine weitere Abstimmung von Gewichten und Schutzmechanismen für Fairness und Starvation erfordert.

Zusammenfassend zeigt das Paper, dass DiLoCo zwar die Kommunikation reduziert, das Scheduling der verbleibenden Synchronisationsevents jedoch ein kritisches Kontrollproblem in geteilten Flotten darstellt. Durch die Einführung einer Matched-Random-Baseline und eines Kalibrierungsprotokolls zeigen die Autoren, dass workload-bewusstes Scheduling nur dann messbare SLO-Gewinne bringt, wenn die Workload eine ausnutzbare Struktur (wie Bursts) aufweist und wenn der Controller diese Struktur präzise prognostizieren oder beobachten kann.