A 32-bit WebAssembly heap put the browser playground near a 4 GB ceiling. With weights and AdamW state, that limited the fp32 model size to roughly 250 million parameters.
Compiling the same C++ source with Memory64 and BigInt support changed the pointer width. One measured run allocated 473,244,160 parameters in 3.7 seconds, completed a training step in 82.2 seconds, and freed the allocation cleanly. The 32-bit module could not make the same allocation.
That was a real allocation result, but it was not the end of the story. The browser's JavaScript-to-WebAssembly bridge was not covered by the Node benchmark. Pointer values crossed the boundary as Number in one place and BigInt in another. Larger in-browser presets therefore fell back to the 32-bit path.
The honest result has two parts: Memory64 moved the theoretical allocation ceiling, and the product path still had an ABI integration blocker. A one-off success did not prove the browser workflow.
The measurements and current limitation are recorded at https://posttrainllm.com/devlog.
