Allocated params
473M browser tab, Memory64 buildMemory64 Browser Behemoth Allocation
The Memory64 work is a useful public artifact because it has a crisp blocker, a measurable unlock, and a compatibility lesson: browsers can train larger local models, but feature detection matters.
Headline Numbers
Allocation time
3.7s measured Behemoth allocationTrain step
82.2s single sanity step after allocationCompetitive Context
| System | Metric | Score | Size / Class | Comparable? | Readout |
|---|---|---|---|---|---|
| TinyGPT Memory64 build | browser allocation ceiling | 473M params | >4GB heap path | Direct | Shows the browser can allocate beyond the old wasm32 limit on supported runtimes. |
| TinyGPT wasm32 build | browser allocation ceiling | OOM around 4GB | 32-bit heap path | Direct | Baseline failure mode that Memory64 fixes. |
Direct rows share this artifact's eval setup. Directional rows are useful market context but should not be read as leaderboard claims.
Memory ceiling
| Build | Outcome | Why |
|---|---|---|
| WASM32 | OOM around 4GB heap | 32-bit pointer ceiling |
| WASM Memory64 | 473M params allocated | 64-bit memory address path |
Release Blockers
Browser support variability
Memory64 descriptor spelling and support differ across browser versions.
Unblock: Keep runtime feature detection and clear fallback copy.