Vigilant Inference Governor

01 — Quellenprüfung und Forschungsbewertung

Stand: 2026-09-09. Aussagen über fremde Systeme sind keine Messungen von Vigilant. Zielentwurf und technische Folgerungen sind unsere eigene Bewertung.

1. Zentrales Paper: relevanter Befund, begrenzte Garantie

S01: Kang, Edge-Inference Governors Need Memory-Clock State, v3 vom 08.07.2026. Geprüft: Haupttext einschließlich Methodik, Zulassung, End-to-End-Auswertung, Limitations und Messfallen; nicht sämtliche Rohdaten unabhängig reproduziert.

Kompakter Quellenbefund:

Unsere Schlussfolgerung: Zustandsabdeckung und unabhängige Validierung haben Vorrang vor einem komplexeren Optimierer. Das Paper ist ein guter Versuchsplan-Impuls, keine übernehmbare Sicherheitsbegründung.

2. Bewertung der vorgeschlagenen Änderungen

Die Prioritäten unten sind unsere Produktentscheidungen, keine Empfehlung der jeweiligen Autoren. Abnahmen stehen in Dokument 05/06.

Vorschlag aus der Diskussion Bewertung am aktuellen Code Konsequenz
Hardwarezustand als zusätzliche Eingabe Sinnvoll; bisherige Metadaten reichen nicht für frühe Zustandswechsel-Erkennung Erst beobachten und Profile invalidieren; später aktiv steuern
Backend-spezifische Profile Richtig, aber Triton ist eine Serverebene, nicht derselbe Typ wie TensorRT Gesamten Ausführungspfad samt Messgrenze identifizieren
p95/p99 statt Mittelwert Bereits vorhanden Stichprobenqualität, Kontext und unabhängige Validierung ergänzen
InferenceContract einführen Wesentliche Verträge existieren schon Versionierte Zusatzbedingungen statt paralleles Vertragsmodell
Miss-Bursts Hoher Nutzen, aber Nenner und Zeittakt müssen zuerst definiert sein Zunächst beobachten; Durchsetzung getrennt qualifizieren
Vollständige Interferenzmatrix Nicht als erster Schritt; teuer, asymmetrisch, nicht generell komponierbar Sparse-Messungen bekannter Kombinationen und konservative Rückfälle
Vorausschauende Taktwahl Separates Risiko: globale Stellgröße und langsame Wirkung Optionaler Aktuator mit exklusivem Besitzer und Readback
CUDA Graphs / warme Profile Nach korrektem nativen Lebenszyklus Beschleunigungsoption; Messzustand und Speicherbudget berücksichtigen
Semantic Freshness Forschungs- und kundenspezifische Erweiterung Autorisierte Anwendung liefert begrenzte Gültigkeitshinweise
Green-Context-Garantien In dieser Form zu stark Partitionierungsfähigkeit, keine pauschale Deadline-Garantie

Eine Zahl wie „99,5 % Wahrscheinlichkeit“ wird nicht dadurch belastbar, dass die API eine Verteilung zurückliefert. Ebenso macht ein Feld für erlaubte Miss-Bursts deren Einhaltung nicht automatisch beweisbar.

3. XSched: prüfen, nicht voraussetzen

S02: OSDI 2025 trennt Policy und Ausführung über präemptierbare XQueues. Das aktuelle Projekt nennt CUDA-Graph-Support, weist aber unterschiedliche Implementierungsstände je Hardware und Ebene aus; bei sm86 sind Level 2/3 in der Tabelle noch als in Arbeit markiert.

Die Triton-Integration ist ein konkretes Beispiel mit Patch für tensorrt_backend r22.06, keine nachgewiesene Drop-in-Kompatibilität mit unserem Triton 2.70.

Unsere Entscheidung: begrenzter Kompatibilitätsversuch NV-15. Er muss Treiber-/GPU-/Graph-Kombination, tatsächlich erreichbare Unterbrechungsgrenze, Fortsetzungssemantik und Wartungskosten belegen. Scheitert das, bleibt der Standardpfad vollständig benutzbar. Ein boolesches supports_preemption wäre als Schnittstelle zu ungenau; siehe Dokument 03.

4. REEF: Konzeptquelle, kein vorhandenes Jetson-Backend

S03: OSDI 2022 und das öffentliche Artefakt zeigen resetbasierte Präemption und gesteuerte Kernel-Nebenläufigkeit. Das Artefakt nennt AMD MI50 als unterstützte Hardware und verwendet transformierte Kernel. Das ist nicht mit unveränderten TensorRT-Engines auf Jetson gleichzusetzen.

Der zusätzlich genannte TOCS-DOI war in dieser Prüfung nicht abrufbar. Dessen konkrete Leistungszahlen und die behauptete spezielle Speicherbandbreiten-Limitation werden hier deshalb nicht als überprüfte Befunde übernommen.

Unsere Entscheidung: von den Trennlinien zwischen Policy, Unterbrechung und Ko-Ausführung lernen. Kein REEF-Port im verbindlichen Pilotpfad.

5. Robotikarbeiten: Kontext ernst nehmen, Grenzen bewahren

Die folgenden Quellen wurden auf Titel-/Versions-/Abstract-Ebene geprüft. Das ist eine belastbare thematische Einordnung, kein vollständiger Methoden- oder Artefaktaudit dieser drei Arbeiten.

Quelle Tatsächlicher Gegenstand Unsere mögliche Verwendung
S04: Jetson-PI v5 VLA-Ausführung mit gelernter Zukunftskorrektur, asynchronen Aktionen und confidence-basiertem Scheduling Anwendungsseitige Gültigkeit und Aktionshorizont als optionale Metadaten; kein Austausch unseres Cores durch ein VLA-Verfahren
S05: Armory Remote-Policy-Serving mehrerer Roboter mit unterschiedlich schnell verbrauchten Aktionsblöcken Verbraucherbedarf statt bloßer Ankunftsreihenfolge modellieren; späterer Mehrgerätefall
S06: Speedup Paradox v2 Unterschied zwischen Inferenzbeschleunigung und Gesamtaufgabenerfolg Varianten an Aufgabenqualität und Zeitverhalten messen, nicht allein an Latenz

Datierung: Jetson-PI wurde im Juli eingereicht und im September überarbeitet. Die Aussage „neues September-Paper“ verdeckt diese Versionsgeschichte.

Wir übernehmen weder deren Modellgewichte noch Methoden als schon implementiert. Ein allgemeiner Governor kennt die Welt nicht: Die Anwendung muss erklären, welches Ergebnis noch nutzbar ist. Selbsteingeschätzte Modell-Confidence darf nicht allein eine harte Frischegrenze lockern.

6. NVIDIA-Funktionen: Werkzeuge und Konkurrenz

S07: Green Contexts partitionieren bestimmte SM- und Work-Queue-Ressourcen. NVIDIA schließt eine allgemeine Zusage gleichzeitiger Ausführung ausdrücklich aus. Ein freier SM-Anteil beweist daher keine End-to-End-Deadline und keine Isolation aller Ressourcen. Die Runtime-API-Darstellung ab CUDA 13.1 ist von älteren Driver-API-Pfaden zu unterscheiden.

S08: TensorRT-Optimierung beschreibt konkurrierende Execution Contexts, steuerbare Auxiliary Streams und Kosten des ersten Enqueue nach Shape-/Profilwechsel. Unsere Folgerung: solche Pfade brauchen eigene Messbedingungen und explizite Besitzer.

Holoscan besitzt bereits S09a: Green-Context-Pools und S09b: Latest-Frame-Semantik. TensorRT, Latest und Partitionierung zusammen sind damit kein gesicherter Alleinstellungsanspruch. Die zusätzliche Wirkung der Vigilant-Policy muss gegen einen passenden Kundenstack sichtbar werden.

7. Messharness wiederverwenden?

S10: jetson-latency-lab enthält Harness, Mess-/Reproduktionsdateien und verweist für große Traces auf Zenodo. LICENSE und NOTICE wurden eingesehen: Apache-2.0 mit Urheberhinweisen; Modelle sind gesondert zu beziehen. Das Repository warnt unter anderem vor falsch bestätigten EMC-Locks und vor einem blockierenden Board bei ungünstiger Taktfixierung.

Unsere Entscheidung: zuerst offline Messformate und Versuchsstruktur nutzen. Vor einer Codeübernahme: Commit pinnen, Datei-/Abhängigkeitslizenzen und Privilegien prüfen, Attribution erhalten, Änderungen markieren. Keine Benchmarkscripte ungeprüft mit Rootrechten auf Kundenhardware ausführen. Es wurde in diesem Schritt nichts importiert oder geforkt.

8. Weitere Lernfelder ohne zusätzlichen Produktballast

Gesamturteil

Übernehmen: bessere Beobachtung, eindeutige Profile, Verbrauchermetriken, strengere Trennung von Wissen und Schätzung. Erproben: native Ausführung, gezielte Interferenzplanung und echte Unterbrechungsmechanismen. Zurückstellen: globale Optimierung über alle Hardware- und Weltzustände. Die Liste von Forschungsrichtungen ist keine Liste bereits gelöster Probleme.