Den tatsächlichen Snake-Workload optimieren

Der übernommene opt-in Pfad kombiniert MLX-Kompilierung, 16-Token-Längen-Buckets und einen begrenzten Cache tokenisierter Frage-Prefixe. Er ändert keine Gewichte, quantisiert das Modell nicht, cached keine Vorhersagen und verwendet keine bidirektionalen Encoder-Hidden-States über Fragen hinweg wieder.

In einem gepaarten Complete-Loop-Test erreichte der ausgelieferte optimierte Pfad 75.40 Züge/Sekunde über 2,400 Züge, gegenüber 70.82 Züge/Sekunde für Eager-Inferenz im selben Test: 1.065×, oder etwa 6.5%. Beide hatten null Tode, 2 Sicherheitseingriffe und identische ausgeführte Aktionen bei 2,400/2,400 Schritten. Das kombinierte Wachstum des aktiven MLX-Speichers nach Warmup und Cache-Bereinigung betrug 0 Bytes.

Aktivieren

laya-snake --optimize
laya-snake --optimize --max-speed

Die allgemeine API exponiert dieselben opt-in Steuerungen:

import laya_mlx as laya

agent = laya.load(
    "aac6fef/laya-multilingual-mlx",
    compile=True,
    pad_to_multiple=16,
    cache_prompts=True,
)

Alle drei Optionen sind standardmäßig deaktiviert, wodurch das bestehende Eager-Verhalten und die Benchmark-Konfiguration bewahrt bleiben. Die Kompilierung spezialisiert auf die Eingabe-Shape; Erstnutzung und neue Shapes können Kompilierungskosten verursachen. Konstruiere einen neuen Agent nach Änderung von Gewichten oder Modulstruktur. Padding rundet die Sequenzlänge auf das angeforderte Vielfache auf, ohne das konfigurierte Kontextlimit zu überschreiten. Masken schließen gepaddete Tokens aus.

cache_prompts=True behält höchstens 128 unveränderliche PreparedQuestion-Prefixe pro Agent, einschließlich Marker-Positionen. Cache-Schlüssel umfassen Tokenizer-Identität, Special-Tokens, Fragetyp, geordnete gerenderte Optionen, Instruktionen und das Prefix-Budget. Der Zustand wird einmal pro prepare-Aufruf bereinigt und tokenisiert und dann unabhängig mit jedem Frage-Prefix verkettet. Frageänderungen erzeugen oder wählen den passenden Prefix. Jede Frage erhält weiterhin einen vollständigen Modell-Forward.

Shape- und Vorbereitungs-Ablation

Diese Demo stellt drei Fragen pro Zug: Richtung, Schätzung der sicheren Route und Schätzung der Futter-Erreichbarkeit. Ihre Batch-Größe ist daher 3, nicht 1. Über 32 beprobte echte aufgezeichnete Boards:

• Die mehrsprachigen Sequenzlängen waren 59, 61, 63 und 64. Ein 16-Token-Vielfaches bringt sie alle in einen 64-Token-Bucket.
• Die englischen Sequenzlängen waren 66, 68, 69 und 70, die auf einen 80-Token-Bucket abbilden.
• Das Padding der mehrsprachigen Eingabe von 64 auf 96 fügt 50% Token-Arbeit hinzu; es ist nicht die kleine 93-auf-96-Anpassung, die das separate Kurztext-API-Fixture nahelegt.

Die Kandidaten liefen in rotierender Reihenfolge innerhalb jedes identischen Zustands, nachdem jede gemessene Shape einmal besucht wurde. Die Tabelle enthält die synchronisierte Agent.predict-Latenz einschließlich Tokenisierung und Ausgabekonvertierung und schließt Planner-/UI-Arbeit und anfängliches Shape-Warmup aus.

Alle sieben Kandidaten stimmten bei den vorgeschlagenen und ausgeführten Richtungen des Eager-Modus auf 32/32 Boards pro Checkpoint überein. Die maximale Abweichung bei den angezeigten, auf vier Dezimalstellen gerundeten Wahrscheinlichkeiten und Schätzungen war in diesen Stichproben 0. Dies ist eine Übereinstimmung gerundeter Ausgaben in endlichen Stichproben, keine Behauptung bitweise identischer interner Fließkomma-Tensoren.

Die Ablation verwendete begrenzte Prefix-Vorbereitungs-Wrapper, um Designs zu screenen. Der Complete-Loop-Test unten verwendet die tatsächlich ausgelieferte API-Implementierung von compile, pad_to_multiple und cache_prompts. Seine Korrektheitstests vergleichen zusätzlich vorbereitete IDs und Marker unter Zustands-Trunkierung, wechselnden Kriterien, Maskenbereinigung und Cache-Eviction.

Der ausgelieferte optimierte Pfad bestand außerdem die vollständige Real-Checkpoint-Validierungsmatrix: 63/63 Übereinstimmung der ausgewählten Antworten für jeden von drei Checkpoints in FP32 und FP16 (378/378 insgesamt). Die Fehler der kalibrierten Wahrscheinlichkeit blieben innerhalb der bestehenden Toleranzen. Jede Konfiguration bestand 10 zusätzliche endliche, deterministische Wiederholungsaufrufe mit 0 Bytes gemessenem Wachstum des aktiven Speichers. Optimierte Validierungsdaten. Die Ergebnisse des ursprünglichen Eager-Pfads mit 100 Wiederholungen pro Konfiguration bleiben im ursprünglichen Benchmark-Bericht.

Für Englisch war die Kompilierung mit der tatsächlichen Sequenzlänge in dieser Stichprobe besser als das Erzwingen des größeren Buckets. Die Demo verwendet standardmäßig Mehrsprachig; allgemeine API-Nutzer können pad_to_multiple=None belassen, während sie Kompilierung und Prefix-Wiederverwendung aktivieren.

Gepaarter Complete-Loop-Test

Vier Seeds, je 600 Züge, mit pro Seed alternierender Kandidatenreihenfolge. Das Rendering umfasst Truecolor-Rich-Komposition und ANSI-Serialisierung und schließt das Zeichnen des Terminal-Emulators aus. Jeder Zug führt eine frische Vorhersage aus. Die Ergebnisse stammen aus einem lokalen gepaarten Lauf.

Der optimierte Pfad war bei einem Seed langsamer. Folglich ist 6.5% die kombinierte Verbesserung in diesem gemessenen Lauf, keine garantierte Verbesserung für jede Episode oder Maschine. Der frühere breite Geschwindigkeits-Sweep und dieser spätere gepaarte Test sind verschiedene Läufe; ihre absoluten Raten dürfen nicht subtrahiert werden, um eine Beschleunigung zu behaupten. Vollständige Loop-Daten.

Das Modell anhand von Spielverlauf und Latenz wählen

Beide Checkpoints liefen 20 gepaarte Seeds × 300 Züge, mit pro Seed alternierender Checkpoint-Reihenfolge. Jede Episode verwendete denselben Anfangszustand, Futter-RNG-Seed, kompakte Feature-Beschreibungen und das Zyklus-Schild. Der Horizont ist fest; dies sind Punktzahlen nach 300 Zügen, keine vollständigen Spiele, die mit Tod oder einem gefüllten Board enden. In diesem Modellvergleich war kein Terminal-Rendering enthalten.

Mehrsprachig machte mehr Futter-Fortschritt und war bei diesem Workload schneller, daher bleibt es der Standard-Demo-Checkpoint. Das Ergebnis bewertet diese merkmalgestützte Policy, nicht allgemeine Reasoning-Qualität oder ein ungestütztes Snake-Modell. Jede Episode und Inferenz.

Reproduzieren

uv run --extra demo python -m experiments.snake_runtime \
  --output artifacts/snake/runtime-multilingual.json
uv run --extra demo python -m experiments.snake_runtime \
  --model models/hub/laya-mlx --bucket 80 \
  --output artifacts/snake/runtime-english.json
uv run --extra demo python -m benchmarks.snake_optimized \
  --output artifacts/snake/optimized-paired.json
uv run --extra demo python -m benchmarks.snake_models \
  --episodes 20 --steps 300 --output artifacts/snake/models.json

Führe GPU-Messungen sequenziell aus. Lade zuerst die beiden lokalen Modellverzeichnisse herunter. Die eingecheckte Quellaufzeichnung liefert die exakten beprobten Board-Zustände. Rohe Ablationen: Mehrsprachig, Englisch, anfänglicher 96-Token-Pilot.

Der frühere Vergleich von kompaktem und detailliertem Prompt alternierte die Prompt-Reihenfolge auf 64 Zuständen und fand einen Median von 11.80 → 9.29 ms nach Verwerfen der ersten 8 Warmup-Iterationen. Seine ursprüngliche Ad-hoc-Aufzeichnung speicherte keine Board-Snapshots, sodass er unterstützender Beleg statt der primären reproduzierbaren Ablation ist. python -m benchmarks.snake_prompt liefert eine reproduzierbare Version, die Zustände, Seed, vollständige Entscheidungen und Methode speichert.

Die Implementierung folgt MLXs offiziellem Compilation-Leitfaden: Verwende ein langlebiges kompiliertes Callable und normale Shape-Spezialisierung. Sie verwendet kein shapeless=True auf shape-abhängigem Python-Modellcode. Die aktuelle Dokumentation wurde über die offizielle Site geprüft, nachdem Context7-CLI-Anfragen mit Netzwerkfehlern fehlschlugen.