Lab · the cyclone transformer in the browser, reproduced

Does the cyclone transformer give the same forecast in a browser as in Python?

A reproduction in the analysis request format (docs/analysis-request-format.md, v0.1), answering lab/wind-transformer.md and the live forecaster lab/live.py. Model weights of 2026-09-15 (tf2_weights.npz, sha256 dfcc8ce5f9cc…), tracks pulled 2026-09-23 06:35 UTC. Run 2026-09-23. Model output throughout: nothing here is a measurement.

Verdict: reproduced. The v2 transformer, exported from tinygrad to WebGPU and run in Chrome, gives the same 184 forecasts for one storm as the Python model on the CPU: expected wind within 0.00003 kt, every percentile bin identical, rapid-intensification probability within 0.0000002. The page reports whole knots.

1. Question

2. Data

The 09-15 log holds all 46 issues for this storm. Against that log, today's CPU rerun differs on 134 of 184 expected winds by at most 0.000013 kt, which is float32 summation order between tinygrad kernels; the tracks are unchanged.

3. Label

No label: this is inference. The rerun compares outputs, not scores. The quantities compared are the ones the live page shows: expected wind per horizon, the 10th, 50th and 90th percentile bins, the modal bin, and the probability of a 30 kt rise in 24 hours.

4. Features (the tokeniser)

The model check tokenised in Python on both sides. The browser port of the tokeniser (tinychase src/lib/tf2.ts, with numpy's half-to-even rounding and np.digitize written out) was then checked on the same 91 fixes: 46 of 46 windows identical to Python's, token for token, and the same 46-step grid.

5. Split

None. Inference on one storm from 2026, inside the note's test years (2020 to 2026) and never in training (1980 to 2014).

6. Method

Three things were wrong before it matched, all in the export, none in the model:

1. the exporter walked the captured program by topological sort, which de-duplicates identical calls. The second block's LayerNorm mean and variance kernels are the same program on the same scratch buffers as the first block's, so they were one UOp and ran once. Embeddings and block 0 matched to 0.0000011; block 1 was off by 4.07. The fix walks the call list in execution order, as the runtime does (9 kernels became 23, 23 calls became 33);
2. kernel names are shape signatures and collided (r_16_16_4 was two different kernels); the later one overwrote the earlier in the JS. Kernels are now keyed by source;
3. the embedding kernel binds 9 storage buffers and WebGPU's default limit is 8. The page requests the adapter's limits (SwiftShader offers 10).

7. Results

Two forecasts, as the page prints them (whole knots, then the 10th to 90th percentile bins):

Wall time in the browser on the software adapter: 415 ms to compile 23 pipelines and load 485 KB of weights, 794 ms for 46 windows run one at a time (17 ms each). A hardware adapter will be faster; a batch-of-N export would be faster still and is not needed for one storm.

8. Caveats and next

• The proof used the software adapter. The kernels are plain WGSL with no extension, so a hardware adapter runs the same code; the numbers may differ in the last float32 digit.
• The tc snapshot on the lake had no fixes (slot_id, name, start, end, lat, lon, n_obs). Resolved the same day, both ways at Mike's call: the nightly builder now writes a track file beside tc (latest.track.parquet, 723,515 fixes from 13,553 dossiers, 5.4 MB, one row group per year, described under track in tc's manifest; Narelle's 91 fixes identical to the kiosks' cache), and tinychase.com is in the API's allowed origins for the per-slot dossier. The model page reads the lake file.
• The one check that would most change the conclusion: a second storm from another basin through the same harness. Done: GEZANI, South Indian basin, in the results table; the same agreement.

Where the note was silent

• Which device the daily run uses: the kiosks environment defaults to the NV backend on this box. The CPU and NV baselines agree with each other and with the log to 0.000016 kt, so it did not matter.
• The reported precision: the live page prints expected wind with toFixed(0), bins as their 5 kt centres, RI as a whole percent. Taken as the bar; the rerun clears it by four orders.

Worth a second look

• live.py runs the model in batches of 128 windows; the export is a batch of one. Same numbers, so batching is not changing the arithmetic.
• The exporter's toposort defect would affect any model that reuses a kernel on the same scratch buffers, which after tinygrad's memory planner is most models with repeated blocks. Worth an upstream issue.

Environment

tinygrad 0.14.0 in the kiosks uv environment (Python 3.14); export via DEV=NULL:WGSL; Google Chrome 153.0.8010.36 headless via puppeteer-core, WebGPU on google/swiftshader (Vulkan on the NVIDIA cards is not reachable headless); Bun 1.3.14 for the page server and driver; CPU baseline on tinygrad's CPU backend, second baseline on NV. About three hours from first export to match, two of them on the three defects above.