arXiv:2604.21361: Open Compute Project kartiert Zeit-/Kausalitätsfehler in verteilten KI-Inferenzsystemen — 5 ms Clock-Skew bricht Observability

Ein Team bestehend aus Ankur Sharma, Deepa Shah, David Lariviere und Hesham ElBakoury veröffentlichte am 23. April 2026 das Paper „Time, Causality, and Observability Failures in Distributed AI Inference Systems” (arXiv:2604.21361). Die Arbeit entstand im Rahmen des Open Compute Project (OCP) Unified Intelligent Infrastructure Workstreams — was den Befunden Gewicht verleiht, da OCP Standards setzt, die praktisch alle Hyperscaler (Meta, Microsoft, Google, AWS) verwenden.

Was ist verteiltes KI-Inferenz?

Das moderne Serving großer LLM-Anfragen erfolgt selten auf einem einzelnen Server. Verteiltes Inferenz teilt die Arbeit auf mehrere Knoten auf: Tokenizer, KV-Cache, Transformer-Attention-Schichten (oft tensor parallel über mehrere GPUs), Embedding-Speicher, Postprocessing und Orchestrator. Jeder dieser Knoten hat seine eigene lokale Uhr, und die Koordination zwischen ihnen hängt vollständig von der zeitstempelbasierten Observability-Infrastruktur ab — Distributed-Tracing-Werkzeuge wie OpenTelemetry, Jaeger oder Zipkin.

Was hat das Paper gezeigt?

Die Autoren führen kontrollierte Experimente an einer Multi-Knoten-KI-Inferenz-Pipeline durch und führen absichtlich Clock-Skew (Uhrenversatz) an einer Stufe ein. Wichtige Befunde:

• Bis zu 3 ms Skew: keine Observability-Verletzung
• 5 ms Skew: „clear causality violations emerge”
• Funktionaler Output: bleibt „largely unaffected” — das System liefert korrekte Ergebnisse
• Durchsatz: ebenfalls unbeeinflusst

Mit anderen Worten: Das System funktioniert korrekt, aber die Observability wird kausal inkorrekt — Traces zeigen unmögliche Sequenzen (z. B. eine Antwort „vor” der Anfrage), was Debugging und Performance-Analyse unzuverlässig macht.

Drei Kategorien von Fehlern

Aus den Befunden ergibt sich eine Taxonomie von Grenzfehlern:

1. Zeitliche Ordnungsverletzungen — Ereignisse erscheinen in Traces in falscher chronologischer Reihenfolge
2. Kausalitätsverletzungen — Ursache-Wirkungs-Beziehungen werden aus Logs rekonstruierbar unmöglich
3. Observability-Degradation unabhängig von der Systemleistung — die gefährlichste Kategorie, da es keine Warnung gibt, dass etwas nicht stimmt (Output ist korrekt, Durchsatz ist in Ordnung — nur die Logs lügen)

Die Autoren stellen außerdem fest, dass das Verhalten nicht-statisch ist: Bei längeren Läufen können sich negative Span-Raten aufgrund von Clock-Drift zwischen Knoten stabilisieren oder verringern. Die Experimente wurden auf Kafka- und ZeroMQ-Transporten mit konsistenten Ergebnissen durchgeführt; Aeron wird untersucht, ist aber nicht in der bestätigten Validierung enthalten.

Was müssen Teams tun?

Die Hauptempfehlung des Papers: „timing must be treated as a first-class concern in distributed AI systems”. Praktische Implikationen:

• PTP (Precision Time Protocol) statt klassischem NTP — Sub-Millisekunden-Präzision über das Netzwerk
• Observability-Tooling, das Clock-Drift aktiv erkennt und warnt, bevor Traces korrumpiert werden
• Tests mit simuliertem Skew als Teil von CI/CD für Inferenzserver
• Single-Node-Fallback-Strategien für kritische Low-Latency-Pfade, bei denen Timing entscheidend ist

Für Teams, die LLM-Serving auf Dutzende oder Hunderte von Knoten skalieren — ob Hyperscaler oder mittelgroße Unternehmen — ist das Paper Pflichtlektüre vor dem nächsten Architekturschritt.