A 3-billion-parameter
OCR model. In this tab.

One forward pass, left to right

1. The page image

   Decoded in-tab, resized and normalized by the same preprocessing code the native CLI runs — certified exact against the Python reference before any kernel work was allowed to start. Nothing is uploaded; the bytes go from your file picker into a worker.

2. SAM-ViT-B — the layout reader

   A 16×16 patch embedding turns the page into a 64×64 grid of 4,096 tokens at width 768, then twelve transformer blocks run windowed attention (window 14) with global attention at blocks 2, 5, 8 and 11, plus decomposed relative-position bias. This is the stage that understands where things are on the page: columns, tables, margins.

3. The 16× token compressor

   A convolutional neck — 1×1, layernorm, 3×3, layernorm, then two stride-2 convolutions — collapses 4,096 tokens into 256 at width 1024. Sixteen times fewer tokens reach the decoder, and the decoder's attention cost is what dominates a long page. This single block is the reason a whole scanned page fits in one pass.

4. CLIP-L/14 — the semantic reader

   Twenty-four layers at width 1024 with sixteen heads, fused directly onto the SAM output: CLIP's embedding layer takes SAM's feature map as its patch embeddings instead of re-reading the image. SAM contributes where, CLIP contributes what.

5. Concatenate, then project

   The two towers are concatenated channel-wise into 2,048 dimensions and a single linear layer maps them to the decoder's 1,280-wide residual stream. One matrix — and the exact concatenation order was resolved from the reference implementation rather than guessed, because getting it backwards produces plausible-looking garbage.

6. The DeepSeek-V2 mixture-of-experts decoder

   Twelve layers, hidden size 1,280, ten attention heads of dimension 128. Layer 0 is a dense SwiGLU MLP; layers 1 through 11 are mixture-of-experts: 64 routed experts plus 2 fused shared experts, with a softmax router picking the top 6 greedily and no renormalization. Attention is R-SWA — a read-only reference block holding the whole visual prefill, plus a 128-slot ring that slides. Memory stays flat while the page grows.

7. Out comes Markdown

   The final RMSNorm feeds an lm_head GEMV from 1,280 to 129,280 logits, and greedy decoding writes the page: headings, paragraphs, tables, LaTeX, layout boxes. The browser writes exactly what the CLI writes, from exactly the same artifact — that equality is measured, not assumed.

Four bits, one shared scale

A bf16 weight spends 16 bits on itself. An int4 weight spends 4 bits, as a two's-complement nibble, and shares one f32 scale with the rest of its group. The group size is the whole trade: small groups follow local outliers closely and pay more metadata; large groups are cheap and blur very differently-sized weights together. Drag it and watch the cost.

1. The artifact did not fit the address space

   The CLI's Unlimited-OCR artifact is 4,157,448,783 bytes. wasm32 addresses at most 4 GiB — 4,294,967,296 bytes — of linear memory, total, for everything.

   That leaves about 137 MB for the engine, the activations, the KV ring and the vision scratch buffers. It is not a tight fit; it is not a fit.

   A wasm-only quantization recipe: int4 on the expert bulk, int8 on attention, lm_head and embeddings, bf16 on the vision tower and the router. 6.67 GB of bf16 source becomes a 3.00 GB artifact that the native resolver refuses to serve as a default — this file exists for one lane only.

2. Fitting on disk is not fitting in memory

   Even with the smaller artifact, peak resident memory during a page measured 5.7 GB. Browsers do not hand you that.

   Hydration widened the whole vision tower at once, kept the embedding table in f32, and copied weight bytes into owned buffers on the way in.

   Vision weights hydrate per block and stream; the embedding table stays int8-resident and dequantizes per row on access; the hot paths borrow the staged bytes zero-copy instead of owning copies. Peak fell to 3.6 GB, which is why the playground gates the model to desktop.

3. One allocation cannot exceed 2 GiB

   wasm32 caps a single allocation at 2 GiB. A 3.00 GB blob has nowhere to land as one object, however much total memory is free.

   The obvious workaround — chop it every 1 GiB — cuts tensors in half, and a tensor that spans two allocations cannot be borrowed as one slice by a kernel.

   The staging planner reads the artifact's own header out of the first 4 MiB of the stream, then cuts the blob into ≤1 GiB segments at tensor boundaries. Every tensor stays contiguous inside exactly one segment, so every kernel still sees one slice.

4. Chrome refuses a 3 GB ArrayBuffer

   Buffering the download to hash it before handing it over fails outright: Array buffer allocation failed, measured at 3.0 GB.

   Verification appears to need the whole file at once — you cannot check a SHA-256 you have not finished reading — and WebCrypto's digest API cannot be streamed.

   The weight bytes are never materialized JavaScript-side. Each fetch chunk is fed to an incremental SHA-256, pushed into the wasm staging sink, and teed into the Cache API in the same pass. Peak JS residency is one chunk plus a 4 MiB header prefix. The digest is checked per part and across the whole stream; a failure deletes the cache entry rather than hydrating unverified bytes.

5. Threads are a link-time decision

   wasm threads need a shared memory and TLS exports chosen when the module is linked, not a flag you pass at runtime.

   And feature detection is not enough: SharedArrayBuffer also exists on iOS under COOP/COEP, where growing a shared memory toward 2 GB reclaims the tab.

   Two modules ship — serial, and shared-memory with atomics — chosen by an allow-list: cross-origin-isolated Blink only. A byte-sized blob worker proves the CSP permits the rayon pool's spawn path before a single weight byte downloads, the instantiated memory is checked to be genuinely shared, and the pool is armed only after hydration, because a worker parked in Atomics.wait blocks the memory growth that hydration is made of.