VR Tech Lead @ Meta. 20yrs AAA game engines (PS1+). Created Meta XR Sim & Operator. Leading OpenXR Agentic AI TSG to build the AI/XR frontier. Views my own.
Palo Alto, CA
Joined March 2009
- Tweets387
- Following529
- Followers1.6K
- Likes848
Pinned Tweet
The Bay Area digital twin runs in a browser now.
Same C++ as the desktop build, compiled to WebAssembly and drawn through WebGPU. Real terrain, procedural buildings, the landmarks, replayed traffic, a sun and moon on the real ephemeris, and a car you can drive. Desktop Chrome for now.
bayarea-web.pages.dev
Getting it there was a data problem, not a graphics problem.
My first measurement, three weeks ago: one view of the Bay meant fetching 1.7 GB and holding 4.2 GB in memory. A browser caps WebAssembly at 4 GB. The port downloaded for five minutes, then crashed before it drew a pixel.
The stack was the easy part. The world logic moved into a GPU-free C++ library both builds share. Shaders are written once in GLSL and translated to WGSL with naga; every one compiles in Chrome, none ported by hand. Loader threads fetch tiles with HTTP Range requests from Cloudflare R2.
The fix was loading by distance, not by region: full detail within a kilometer, major roads out to three, the traffic graph tiled by radius instead of loaded whole. Then zstd on what was left.
Bytes to a settled view: 1.7 GB down to about 170 MB. Memory: 4.2 GB down to about 2 GB.
Then batching: nearly 4,800 requests cut to a third, and the first view on an 80 ms link went from 181 s to 31 s.
And the frame rate: street level went from 4 to 17 fps to 60, standing and driving, on my desktop.
Every release renders 58 golden scenes in Chrome and scores them against the desktop build. The arrival view scores 0.99 on SSIM, an image-similarity measure where 1.0 is identical.
I directed the work. Claude Opus 5.5 did the heavy lifting, from the port to this video.
Map data © OpenStreetMap contributors (ODbL). Land cover: ESA WorldCover 2021 (CC BY 4.0). Terrain: USGS 3DEP and NOAA.
#WebGPU #WebAssembly #cpp #gamedev #OpenStreetMap
A rare chance to watch the real engineering work behind training a 500+B MoE model. By my rough estimate, that is around 6 to 12 million dollars in just compute cost. I am curious to see how they tune it as it progresses, how often human intervention is needed mid run, and how hardware hiccups get handled on a cluster of this size.
🚢 Marin 535B-A23B started training this week! As usual, the whole process is open.
Voyage plan: pretraining (80%) + midtraining (20%) on 18.75T tokens on 11 x GB200 NVL72 for ~3 months (2.7e24 FLOPs). Post-training will follow.
Before kicking off the run, we trained a 4-rung scaling ladder from 1.6B-A61M (48B tokens) to 27.7B-A1.2B (926B tokens) to debug issues, and to make a forecast of our hero run. This is by far our biggest run, so definitely expecting the unexpected.
Marin's 535B run got faster again on Oct 9. It now uses 29.4% of its GPUs' peak math, up from 26.3% the day before and 21.2% at launch. Same 704 GPUs the whole time. That's 39% more training per hour than at launch, all from code swapped in while the run kept going.
This time there was no single big change. It was six smaller fixes to the expert layers, each tested on one rack first. Most shaved about 1% or less off each step. The biggest saved 4.1%. To save memory, the run throws away some results during the forward pass and redoes that work during the backward pass. Part of that redo, including a second round of sending tokens between GPUs, existed only to compute one gradient. They found that number could be built from values the backward pass already had, so the redo is gone.
Before keeping it they did what they've done at every swap: ran the new and old code on the same 200 batches. Time per step went from 14.91 to 13.33 seconds. Loss differed by 0.000085 on average, and the router's behavior by under 0.5%. The cost is memory. Keeping results instead of redoing them raised peak use from 120.8 to 123.4 GiB per GPU.
The dashboard rate isn't the same as what actually gets trained, because restarts eat time. So I divided the tokens trained by the time that passed. In the 30 hours since the switch it's been 3.30M tokens a second, with no restarts. In the run's first full week it was 2.34M.
The swap and the side by side numbers: github.com/marin-community/m…
The six fixes and their single rack measurements: github.com/marin-community/m…
Not affiliated with the project. Data collected and analyzed by AI. Data cut 2026-10-10 22:53 UTC (15:53 PDT).
On Oct 14, Marin's 535B run started reading text in 16K token chunks instead of 4K. The published plan had a first step to 8K around the halfway point. They went straight to 16K instead, at 66% of the way through.
The worry with longer chunks is the experts. Each token goes to 8 of 384 experts, and an expert that gets more tokens than it has room for turns the extras away. Longer chunks make that pileup worse. In earlier tests with older code, the share turned away went from about 7% at 4K to about 40% at 65K. Before the switch this run was turning away 0.007%. After it, 0.14%. That's 19 times more, but it's still about 1 token in 700. It's held flat for a week, and it's half of what a one rack test at 16K measured.
Two numbers moved in opposite directions, and both are right. The share of the GPUs' peak math being used went up, from 29.2% to 30.5%. Tokens trained per second went down, from 3.43M to 3.34M. Every fourth layer's attention now looks back over 16K tokens instead of 4K. So each token costs more math, and that extra math runs efficiently.
There was no side by side run this time, because the old setup stopped at the handoff. They wrote down seven checks before launch: loss in range, at least 29% utilization, drops under 0.2%, memory, no errors, first eval completes. All seven passed. Before that they tested three settings for how sharply attention focuses at the new length on 100 step runs. The value their own rule predicted, 1.48, scored best.
One trap if you're watching the dashboard: loss stepped down at the switch, from 1.152 to about 1.10 in training. Don't read that as a jump in learning. Each token now has more text before it to predict from, which makes the guessing easier. The team says the eval drop is mainly because evals now pack text into 16K chunks too. So the numbers before and after aren't comparable.
The switch and the seven checks: github.com/marin-community/m…
The one rack tests at 8K and 16K: github.com/marin-community/m…
The original plan, and the 7% to 40% figure: github.com/marin-community/m…
Not affiliated with the project. Data collected and analyzed by AI. Data cut 2026-10-21 03:53 UTC (2026-10-20 20:53 PDT).
Xiang Wei retweeted
The fact that Tesla was able to keep the development of the Roadster a secret for so long is pretty impressive.
Xiang Wei retweeted
That demo involved a non trivial chance of embarrassing failure! 🫡
I’m only going for the baseline model. At this point in my life, rocket bunny hops are out of my comfort zone.
Xiang Wei retweeted
📣 NEW VR Developer Showcase!
Table Troopers combines turn-based tabletop battles with hand tracking and physics-driven destruction. For developers, it offers a look at how gesture controls, reactive environments and Meta SDK integration can work together in one experience.
- Hand interactions: Pinch to place troops and aim attacks, mapping familiar gestures directly to tactical actions.
- Destruction: Physics-driven terrain damage makes the consequences of each attack visible.
- Interaction SDK: Meta's hand-input tools power the game's gesture controls.
- Platform SDK: Friend invites, leaderboards and DLC purchases connect gameplay to platform services.
- Content design: The optional paid Halloween Pack extends the core game with themed maps, troops and weapons.
Xiang Wei retweeted
MUSE WONDER
this is the culmination of over a year of research and infrastructure work in msl
since we originally shipped muse spark in april, we have continued to scale our models across pre-training and RL, now reaching the frontier 🏆
see our model's improvements on the artificial analysis index:
Xiang Wei retweeted
Introducing Muse Wonder, our new family of frontier models with state of the art performance for personal and professional agentic work.
Xiang Wei retweeted
Which one of you guys did this? lol
Well, it didn’t take long for Soccer Pinball to “inspire” another game. I mean, the field, the players… they even copied the messed up arms from my game.
I guess this is something we’ll have to get used to as game developers. The moment you share what you’re working on, someone can use these new tools to build their “own” version and potentially get it out before you.
But being the first to copy something doesn’t make it a good game. I’ll keep working on mine.
Xiang Wei retweeted
After co-inventing ChatGPT, I kept asking myself: why have superhuman chat models not led to AGI?
I’ve spent the last 2 years in stealth building a new way to train models (RLCD), and a new type of frontier AI model that we are releasing today: Jev
• 20-200x faster
• 40-400x cheaper (w/ output tokens free)
• Frontier composable intelligence optimized for decisions
AFAICT the shortest path to AI-based economic revolution