Serie: Programmieren lernen mit KI

Das Wochenende, an dem die Engine erwachsen wurde

Das 276-Commit-Wochenende: fünf Subsysteme, die die Engine erwachsen machten.

Das Wochenende, an dem die Engine erwachsen wurde Ein Forschungsprojekt gewinnt die Fläche einer Plattform 276 Commits / ein Wochenende TFLite On-Device-SLM Spatial Anchors AES-256-GCM-Sync OpenXR-Kompositierung Kalman-Anker-Filter HAL für optischen Kanal ~150 von 342 erfassten TODOs abgeschlossen
276 Commits, zehn plattformreife Subsysteme, eine Engine, die die Kategorie gewechselt hat.

Es gibt einen Moment, in dem eine Codebasis aufhört, etwas zu sein, das man baut, und zu etwas wird, auf dem andere aufbauen können. Für RakuAI war dieser Moment ein Wochenende zwischen Weihnachten und Neujahr mit 276 Commits.

Es gibt Wochenenden, an denen eine Codebasis vorankommt, und es gibt Wochenenden, an denen eine Codebasis die Kategorie wechselt. Das Wochenende zwischen Weihnachten und Neujahr war von der zweiten Sorte.

Zweihundertsechsundsiebzig Commits landeten über die Repositories verteilt. Die Runtime gewann genau die Art von Fläche, die aus einem Forschungsprojekt eine Plattform macht. Räumliche Anker (Spatial Anchors). OpenXR-Kompositierung. SLM-Inferenz auf dem Gerät. Federated Sync mit echter Kryptografie. Hardware-Abstraktion für den optischen Kommunikationskanal. Das meiste davon landete in parallelen, von Agenten verfassten PRs, die über den Multi-Vendor-Workflow reviewt und gemerged wurden, der seit zwei Monaten läuft.

Samstagmorgen setzte ich mich mit Kaffee und einer Warteschlange voller hochpriorisierter TODOs hin. Sonntagabend klappte ich den Laptop zu einer anderen Engine zu, als die, mit der ich am Samstag begonnen hatte. Dies ist der Beitrag darüber, was ausgeliefert wurde, was es bedeutet, und warum ich glaube, dass 2026 das Jahr ist, in dem andere anfangen, diese Engine ernst zu nehmen.

Die großen Landungen

TensorFlow Lite C-API für SLM-Inferenz. Das ist die, über die ich mich am meisten freue. Die Runtime kann jetzt kleine Sprachmodelle im TFLite-Format laden und Inferenz gegen sie als erstklassige Runtime-Operation ausführen. Die Motivation ist einfach: Nicht jedes Modell braucht einen Cloud-Roundtrip. Manche der KI-Verhaltensweisen, die eine AR-Erfahrung antreiben, sind eng, fokussiert und klein genug, um auf dem Gerät zu laufen. Der TFLite-Pfad gibt uns das. Der Cloud-LLM-Pfad über den XRAssistantService gibt uns das andere Ende. Die Engine deckt jetzt beides ab.

Spatial Anchors abgeschlossen (Epic Nr. 555). Vollständiger Lebenszyklus für räumliche Anker: erstellen, persistieren, geräteübergreifend teilen, in einer anderen Sitzung wiederherstellen, ablaufen lassen. Die Persistenzschicht ist Cloud-gestützt über libcurl-HTTP, wobei die Verschlüsselungsschicht (AES-256-GCM, PBKDF2-Schlüsselableitung) im selben Wochenende landete. Anker sind jetzt erstklassige Runtime-Objekte. Eine AR-Erfahrung, die ein virtuelles Objekt heute, morgen und einen Monat später auf derselben Küchentheke platzieren muss, geräteübergreifend bei zwei verschiedenen Brillen zweier verschiedener Personen, funktioniert.

Kalman-gefilterte Anker-Pose-Stabilisierung. Eine kleine Sache, die viel ausmacht. Anker-Posen ohne Filterung zittern gerade genug, um sich falsch anzufühlen. Anker-Posen mit Kalman-Zustandsvorhersage-Filterung fühlen sich solide an. Die Runtime wendet den Filter jetzt automatisch an; Anwendungen darüber müssen es nicht wissen.

OpenXR-Kompositionsebenen-Manager und Aktionsräume. Fortsetzung der OpenXR-Grundlagenarbeit vom November. Der Kompositionsebenen-Manager ist das, was einem einzelnen Frame erlaubt, den Kamera-Passthrough, die virtuellen Inhalte des Nutzers und etwaige System-Overlays in der richtigen Reihenfolge mit den richtigen Blend-Modi zu kombinieren. Grundlegend und leicht zu unterschätzen.

Produktionsreife AES-256-GCM-Verschlüsselung und UDP-Peer-Discovery für geteilte Anker. Das ist es, was „einen Anker mit einem Freund im selben Raum teilen” tatsächlich sicher genug macht, um es auszuliefern. Das Protokoll für geteilte Anker verwendet Ende-zu-Ende authentifizierte Verschlüsselung. Peer-Discovery läuft lokal über UDP, ohne einen Cloud-Roundtrip. Die Privatsphäre- und Latenz-Geschichte für geteiltes AR ist real.

Hardware-Abstraktionsschicht für den optischen Kanal (33 Sensor-TODOs gelöst). Die optische Verbindung ist, wenn auf einem Gerät vorhanden, jetzt ein Peer zur RF-Verbindung. Beide sind hinter demselben Dual-Mode-Link-Manager abstrahiert, der im November landete. Die Runtime darüber kümmert sich nicht darum, welche Funkstrecke auf der Leitung liegt.

Federated Sync bis zur echten Kryptografie verdrahtet. Das Federated-Sync-Subsystem war den größten Teil des Herbsts stub-getrieben. Dieses Wochenende wuchsen echte Implementierungen: HTTP-Transport, JSON-Umschlag, Verifikation kryptografischer Signaturen. KI/ML-Modell-Updates können jetzt sicher über den föderierten Pfad an Geräte verteilt werden.

Vendor-Eye-SDK-Integration und Token-Verifikation. Eine Handvoll herstellerspezifischer Eye-Tracking-SDKs sind jetzt hinter der OpenXR-Provider-Schnittstelle angebunden, mit ordentlicher tokenbasierter Authentifizierung für die Lizenzierungsschicht des Herstellers.

GPU-Profiling-Instrumentierung im gesamten Renderer (15 TODOs gelöst). Zeitmessung pro Pass, Speicherbudgets und Pipeline-Stall-Erkennung sind jetzt live. Wenn ein Frame zu lange dauert, können wir genau sehen, welcher Pass das Budget gekostet hat.

Runtime-Updater-Funktionalität (10 TODOs gelöst). Die Runtime kann sich jetzt im Feld selbst aktualisieren. Versioniert, signiert, mit Rollback. Das ist die Art von Grundlagenarbeit, die niemand bemerkt, bis man sie braucht – und dann ist es der Unterschied zwischen einer Plattform und einem Kunstprojekt.

Was ich aus dem Tempo gelernt habe

Zweihundertsechsundsiebzig Commits über ein langes Feiertagswochenende sind ein Tempo, das in einem traditionellen Entwicklungsworkflow nicht funktioniert. Es funktioniert in diesem hier, weil der Workflow darauf ausgelegt ist, dass Agenten parallel gegen eine Warteschlange ausliefern, die ich gefüllt halte. Ein paar Beobachtungen zum Fahren dieses Tempos über die Zeit von Weihnachten bis Neujahr:

Die Epic-Struktur hat sich bewährt. Etwa Mitte des Monats habe ich den Issue-Tracker auf ein Epic-mit-Sub-Issues-Muster umgestellt (Epic Nr. 506 für Runtime Core Phase 1, Epic Nr. 555 für Spatial Anchors, Epic Nr. 508 für OpenXR Extensions). Jedes Epic bekommt einen PR, der einen zusammenhängenden Arbeitskomplex abschließt. Die Agenten implementieren die Sub-Issues parallel, aber der Merge passiert als ein atomarer PR auf Epic-Ebene. Das gab der Codebasis eine viel sauberere Historie und machte das Review handhabbar.

Das TODO-Tracking-System war der richtige Schritt. Früher im Monat habe ich ein automatisiertes System hinzugefügt, das die Codebasis nach TODO-Kommentaren durchsucht und für jeden davon ein GitHub-Issue mit Priorisierung erstellt. Als der Weihnachts-Sprint begann, gab es 342 erfasste Runtime-TODOs. Die Agenten haben sich zuerst die höchstpriorisierten vorgenommen. Wir haben an diesem Wochenende ungefähr 150 davon abgeschlossen. Die Codebasis ist spürbar sauberer als zu Beginn des Dezembers.

Repo-übergreifendes Merge-Timing ist wichtig. Die Runtime und das SDK mussten ihre Änderungen für mehrere Epics dieses Wochenende innerhalb von Stunden zueinander landen. Wenn die Runtime eine neue C-API veröffentlicht, muss das SDK seine Bindings am selben Tag aktualisieren. Ich habe ein paar SDK-PRs zurückgehalten und ein paar Runtime-PRs in derselben Stunde gemerged, um die Integration ehrlich zu halten.

Die Agenten werden besser in ihren Rollen. Die PRs, die dieses Wochenende landen, sind merklich sauberer als die PRs, die im September landeten. Ein Teil davon liegt daran, dass die Codebasis reifer ist. Ein Teil davon liegt daran, dass der Workflow diszipliniert ist. Ein Teil davon liegt daran, dass die Modelle selbst besser werden in der Art von Arbeit, die diese Codebasis hervorbringt. Alle drei sind real.

Wo die Engine steht, mit Blick auf 2026

Die Checklisten-Version:

  • AR1+-zu-AR2-Gen1-Pivot: erledigt
  • OpenXR-Grundgerüst: erledigt
  • Cloud-LLM-Intent-Integration über den XRAssistantService: erledigt
  • SLM-Inferenz auf dem Gerät über TFLite: erledigt
  • Sub-Millimeter-Ankerung für hochpräzise Overlays: erledigt
  • Räumliche Anker mit Persistenz, Teilen und richtiger Kryptografie: erledigt
  • Wi-Fi-7-ausgelagerte Rendering-Pipeline: erledigt
  • Dual-Mode-RF-/Optik-Link-Manager: erledigt
  • Eye-Tracking, Hand-Tracking, Ganzkörper-Tracking: erledigt
  • Foveated Rendering mit Multi-Profil-Optimierung: erledigt
  • Hardware-Abstraktion für Sensoren und optischen Kanal: erledigt
  • Federated Sync für Modell- und Content-Verteilung: erledigt
  • Runtime-Updater mit Versionierung und Rollback: erledigt
  • Multi-Plattform-Builds (Linux, macOS, Windows MSVC 2026): erledigt
  • Telemetrie- und OpenTelemetry-Pipeline: erledigt
  • 342 TODOs erfasst, ~150 diesen Monat abgeschlossen: in Arbeit, aber auf gutem Weg

Was nicht erledigt ist: die KI-Subsysteme, die die Modellschicht an den Simulationsschritt binden. Verhaltensbäume. Navigationsnetze. Crowd-Simulation. Sensorische Systeme. Entscheidungsbäume. Das ist die Arbeit, die ich erwarte, in der ersten Januarwoche zu landen. Die Runtime ist bereit, sie aufzunehmen. Heute hat die Engine das Skelett. Nächstes Wochenende bekommt sie die Nerven.

Was ich Partnern, Entwicklern und Laboren mitgeben möchte

Wenn Sie ein Hardware-Partner sind, der abschätzt, ob diese Engine 2026 auf Ihrem Gerät ausgeliefert werden kann: Die Antwort ist ja, und die Arbeit, das real zu machen, ist inzwischen größtenteils herstellerspezifischer Klebstoff. Die Engine selbst ist bereit.

Wenn Sie ein KI-Labor sind, das überlegt, wo das Inferenzbudget Ihres Modells in einer AR-Runtime am besten investiert wäre: Sowohl der TFLite-On-Device-Pfad als auch der Cloud-LLM-Pfad über den XRAssistantService sind jetzt produktionsreif. Wenn Ihr Modell in das On-Device-Budget passt, kann es auf dem Simulationsschritt laufen. Wenn nicht, steht der Cloud-Pfad offen. So oder so ist die Integration modellagnostisch, und ich möchte, dass Ihr Modell das beste Modell dahinter ist.

Wenn Sie ein Entwickler sind, der 2026 auf dieser Engine aufbauen möchte: Die Fläche ist real. Die C-API ist stabil. Die SDK-Bindings (Unity und Unreal) sind real. Das OpenXR-Grundgerüst bedeutet, dass die Engine mehrere Geräte adressiert. Der Blog unter dieser URL war ein öffentliches Protokoll davon, wie die Engine hierher gekommen ist. Lesen Sie ihn nach, wenn Sie wissen wollen, wie die Engineering-Kultur sein wird, wenn Sie eine Erfahrung auf diese Plattform bringen.

276 Commits, ein Jahr geht zu Ende, eine erwachsen gewordene Engine. Anderes Wochenende, derselbe Workflow. Nächsten Samstag geht es weiter mit dem Bauen.

Bringen Sie Ihr Modell auf den Simulationsschritt

RakuAI liefert sowohl On-Device-SLM-Inferenz über TFLite als auch einen Cloud-LLM-Pfad – modellagnostisch, produktionsreif, bereit für Ihre Gewichte. Sehen Sie, wo Ihr Inferenzbudget in einer räumlichen Runtime am weitesten reicht.

← Alle Beiträge