Gate M3 — OneTimer gegen Triton

Stand: 2026-09-01 · erster Vergleich gegen ein konkurrierendes Produkt

Aufbau

Gemessene Laufzeitprofile (onetimer profile, 120 Messläufe):

Daraus: geschützte serialisierte Auslastung 92 %, mit dem VLM zusammen rund 116 % — echte Überlast auf einem Slot.

Was gleich gehalten wird

Dieselbe GPU, dasselbe Triton, dieselben Modelle, dieselbe Instance-Group-Konfiguration, derselbe Shared-Memory-Datenpfad, derselbe Client, dieselben Frames. Dynamisches Batching ist auf beiden Seiten aus — bei periodischer Einzelbildlast macht ein Batcher die Baseline nicht schneller, sondern nur träger, und er würde hinter dem Governor eine zweite Warteschlange erzeugen (ADR-0002).

Beide Seiten werden mit den Client-Puffertiefen 1 und 8 gefahren; je Strom zählt das bessere Ergebnis.

Ergebnis: Triton ohne Rate Limiter

Governor: 3707 angenommen, 3627 weitergereicht, 78 wegen Überalterung verworfen, 3848 Veto-Ereignisse des Look-ahead, 78 Best-Effort-Requests nie ausgeführt.

Ergebnis: Triton mit Rate Limiter und Prioritäten

Triton gestartet mit --rate-limit=execution_count, je Instance-Group rate_limiter { priority: N } — RF-DETR auf 1 (höchste), Pose und Tiefe auf 2, der lange Block auf 5. Das ist das Werkzeug, das Triton für dieses Problem anbietet (Spec 3.1).

Governor: 3720 angenommen, 3640 weitergereicht, 78 wegen Überalterung verworfen, 3506 Veto-Ereignisse, 78 Best-Effort-Requests nie ausgeführt.

Nachtrag 2026-09-08: Zusätzlich mit rate_limiter { resources [ { name: "gpu" count: 1 global: true } ] } gemessen — echter wechselseitiger Ausschluss statt nur Priorität. Der Detektor steigt damit auf 89–91 %, die Pose fällt auf 78–79 %. Der stärkste Triton-Aufbau verteilt den Verlust um, statt ihn zu beseitigen; keine Konfiguration bringt alle drei geschützten Ströme gleichzeitig nahe 99 %. Zahlen: ../reviews/2026-09-07/gpu/ERGEBNIS.md.

Der Rate Limiter hilft der Baseline kaum — 83 % auf 84 % beim Detektor. Das war zu erwarten und bestätigt die Analyse aus Spec 3.1: der Rate Limiter ordnet wartende Arbeit, kann aber eine bereits laufende 95-ms-Inferenz nicht zurückholen. Und er kennt weder Frische noch Deadlines, entscheidet also nicht darüber, ob ein Request überhaupt noch ausgeführt werden sollte.

Bewertung

Ziel A′ (ADR-0005): erreicht. Gefordert waren mindestens 2x weniger unabgedeckte Perioden für geschützte Ströme unter Überlast. Gemessen gegen die getunte Baseline:

Alle drei geschützten Ströme übertreffen die Schwelle. Die Age of Information des Detektors halbiert sich von 77 ms auf 33 ms — also von rund zweieinhalb Kameraperioden auf genau eine.

Der Preis ist real und war vorhergesagt. Der lange Block läuft unter OneTimer nicht: 78 Best-Effort-Requests erreichten einen terminalen Zustand, ohne je ausgeführt zu werden. onetimer doctor meldet das vor dem Start:

WARN vlm: konservative Laufzeit 120.770ms uebersteigt die kuerzeste geschuetzte
     Periode 33.000ms (detector). Auf einem Slot wird das Modell unter Last nie
     starten. Abhilfe: mehr Slots, kuerzere Quanten oder eine hoehere Klasse.

Das ist keine Überraschung, sondern ADR-0012 auf echter Hardware. Ein nicht unterbrechbarer 95-ms-Block und eine 33-ms-Periode passen auf einer Ausführungseinheit nicht zusammen — mit oder ohne Governor. Der Unterschied ist, dass OneTimer entscheidet, welche Seite verliert, und es sagt.

Was dieses Ergebnis nicht zeigt

• Nur eine GPU, nur ein Betriebspunkt. Eine RTX 3070 Laptop ist keine Jetson und kein Serverbeschleuniger. Spec WP22 fordert den Jetson-Port gesondert.
• Nur ein Lastprofil. Die Bursts und die Lastrampe aus Spec 19.4 fehlen.
• Kein Vergleich gegen Holoscan. Dessen Async-Buffer-Semantik ist der nächstliegende Wettbewerber für die Frische-Frage.
• Keine Variantenwahl im Spiel. Für den Detektor liegt nur eine Variante vor; die Qualitäts-Deadline-Frontier aus Spec 19.7 ist unbelegt.
• Der Best-Effort-Fall ist ungelöst, nicht nur ungemessen (ADR-0012). Nachtrag 2026-09-08: für ein zerlegbares Modell ist er inzwischen gelöst — siehe den Nachtrag in wp26.md. Für einen nicht unterbrechbaren Block wie das VLM hier gilt die Aussage unverändert.

Reproduzieren

# Umgebung: deploy/triton/README.md
onetimer doctor  -c examples/gate_m3/onetimer.yaml
onetimer profile -c examples/gate_m3/onetimer.yaml
taskset -c 8-15 target/release/gate-m3 examples/gate_m3/onetimer.yaml

Nachmessung am 2026-09-10

Dieselben Modelle, dieselbe Karte, 200 Laeufe je Modell:

Alle vier Stroeme sind heute langsamer, die geschuetzte serialisierte Auslastung steigt damit von 92 % auf 103 %. Dieselben Gewichte, dieselbe GPU — gewechselt hat der Zustand der Karte, nicht das Modell. vig doctor lehnt die Beispielkonfiguration mit den neuen Zahlen ab, weil ein Slot 103 % nicht traegt; das ist die richtige Auskunft und der Grund, warum ein Profil ohne Angabe seiner Umgebung wenig wert ist (ADR-0019).

Der A/B-Lauf mit den neuen Zahlen bestaetigt das veroeffentlichte Ergebnis eher, als es zu schwaechen: Detektor 82 → 99 % (24,7x) und 83 → 99 % (23,9x) in zwei Laeufen, gegenueber 22,4x am 2026-09-01. Die Vergleichszahlen fuer TensorRT stehen in tensorrt.md.