Skip to main content

Posts

Racecraft: Fine-Tuning Gemma 4 with DPO for Sub-150ms On-Device Coaching at 130 MPH

Project Koru • Deep Dive Racecraft: Fine-Tuning Gemma 4 with DPO for Sub-150ms On-Device Coaching at 130 MPH How we distilled expert human motorsport coaching into a 12MB Gemma 4 LoRA adapter using Direct Preference Optimization (DPO)—cutting NPU TTFT to 149ms and locking sub-5-word root-cause cues at high speed. By Rabimba Karanjai • August 2026 • 10 min read Figure 1: Empirical DPO Fine-Tuning Loss convergence curve (0.693 down to 0.141), reward margin expansion (+1.768), and NPU performance benchmarks on Google Tensor G5 / NVIDIA GB10. P icturing a car barreling into Turn 3 at Sonoma Raceway at 130 MPH gives you an immediate sense of scale. At that speed, you are traveling 190.6 feet every single second (58.1 meters/sec). Your brain is processing visual apex marks, tire slip audio, steering effort, and lateral G-forces in split-second 200–300ms reaction windows. If an AI coach speaks a typical convers...
Post a Comment
Read more
Recent posts

Racecraft: Tale of Car Sensors

Racecraft · Technical Deep Dive · Sensor Fusion & Gemma Generalization Fusing 100+ On-Device Sensors at 130 MPH , And Why Gemma Didn't Need Fine-Tuning Inside Racecraft's real-time telemetry engine: multiplexing AiM CAN bus, RaceBox BLE, OBDLink, and 6-DOF IMU streams on Android, zero-shot corner doctrine generalization, and benchmarking Gemma 4 E2B on Tensor G5 silicon. A few days ago after sharing early results from Racecraft (Project Koru) , a question popped up in one of the comments that immediately caught my attention: "Curious how your team handled real-time fusion of 100+ sensors on-device. Did Gemma need race-specific fine-tuning, or did general coaching logic generalize?" It's the exact right question to ask. When people hear "AI race coach running on a phone in real time at Sonoma Raceway," they usually picture one of two extremes: either a brittle set of hardcoded if (speed < 40) statements, o...
Post a Comment
Read more

AEGIS-CHAOS: From 'Vibe Coding' to Closed-Loop SRE

Aegis-Chaos · Post 1 of 1 · → View on GitHub From “Vibe Coding” to Closed-Loop SRE How zero-trust policies, Git isolation, and math-based budget guardrails let an autonomous agent say “no” — and mean it. Aegis-Chaos: An autonomous SRE control plane with real-time zero-trust guardrails. Most AI coding assistants today operate on trust. You prompt, they generate, and you ship. That works—until it doesn’t. A single destructive command, an uncaught runaway loop, or a stale approval can turn an autonomous agent into a production incident. Project Aegis-Chaos was built to answer a simple question: what happens when the AI says “no”? This post walks through the zero-trust architecture, parallel isolation strategy, math-based budget guardrails, and end-to-end visual verification pipeline that make up our closed-loop SRE control plane—designed for the Google Developer Expert Sprint and built on the Antigravity SDK. The Decla...
Post a Comment
Read more

The Throughput Trap: Benchmarking vLLM on OpenXLA and the Reality of Production LLM Serving

vLLM Systems · DevLab 2026, Deep Dive I was recently invited by the Google TPU team to speak at the OpenXLA Summer DevLab 2026 . This post breaks down our deep-dive evaluation of the matured vLLM + OpenXLA stack, the fundamental engineering mismatches between CUDA and XLA serving paths, and why traditional capacity metrics are lying to you. If you are operating large language models at enterprise scale right now, your platform architecture team is likely staring at a massive infrastructure crossroads: Should we migrate our core serving workloads from GPUs to TPUs? Historically, NVIDIA's CUDA ecosystem was the only serious option for user-facing, low-latency LLM generation. But here in 2026, the economics and infrastructure options have transformed. Google TPUs are highly available, cheaper per chip, and the open-source serving stack built around vLLM and OpenXLA has officially achieved absolute production readiness. Yet, when our infrast...
Post a Comment
Read more