Deterministic Rust/WebAssembly Browser Inference Runtime Architecture

Full report

On this page

1. Operating Context and UAIX Framework Parameters

As of July 11, 2026, the deployment of local machine intelligence relies extensively on the browser as a universal, cross-platform edge application runtime. The demand for offline-first, deterministic, and highly secure Rust-based inference runtimes executed via WebAssembly (WASM) and WebGPU stems from the requirement to run Small Language Models (SLMs) and specialist models without relying on cloud infrastructure. This technical architecture report specifies the normative design for a production-grade WebAssembly inference engine. The analysis is conducted using public-web observations of the "TinyRustLM" and "MiniModel" experimental baselines, treated strictly as black-box systems without access to proprietary source code or private performance data1. The existing TinyRustLM implementation provides a 114 KiB WebAssembly module executing a scalar-only, main-thread-blocking application that operates under a rigid 128 MiB transfer ceiling using a custom SLM1 binary container1. To transition from this experimental baseline to a modular, teleodynamic system capable of executing modern architectural topologies, the runtime requires a fundamental overhaul of its memory management, concurrency model, compute dispatch, and deterministic guarantees. The UAIX Cognitive Liberty Charter mandates explicit transparency regarding resource consumption, deterministic execution to prevent covert behavioral drift, and the preservation of strict local-only execution boundaries3. Consequently, this report focuses extensively on runtime correctness, precise memory budgeting, verifiable performance measurement, and the ergonomic constraints of deploying complex AI systems within sandboxed browser environments.

2. Loader and Execution Design: Storage, Mapping, and Concurrency

The efficient loading and execution of multi-gigabyte neural network weights inside a web browser demand storage and memory architectures that entirely avoid the main thread and eliminate duplicate data copies.

2.1 Storage Primitives: IndexedDB, Cache Storage, and OPFS

Legacy web applications rely on IndexedDB or the Cache Storage API to persist large assets. However, IndexedDB incurs prohibitive serialization and transaction overhead for large ArrayBuffer objects, severely degrading model loading performance4. While the Cache Storage API operates efficiently for network-mapped Request/Response pairs, it does not support partial, in-place byte manipulation5. The target architecture mandates the use of the Origin Private File System (OPFS). OPFS provides a specialized, origin-partitioned storage endpoint that grants low-level, byte-by-byte file access bypassing the user-visible file system6. Crucially, when OPFS is accessed from a dedicated Web Worker, the runtime can utilize FileSystemFileHandle.createSyncAccessHandle()6. This method returns a synchronous access handle, allowing the WASM runtime to execute synchronous read() and write() operations directly against the sandboxed disk file. This mechanism effectively serves as a memory mapping substitute in the browser, entirely bypassing the need to load full model artifacts into JavaScript memory before copying them into the WebAssembly heap6.

2.2 Range Requests, Chunked P2P Import, and Layer Streaming

To mitigate initial payload spikes, the model acquisition layer must employ HTTP Range requests or chunked WebRTC P2P streams to download artifacts in discrete, aligned blocks. These blocks are synchronously written to the OPFS handle as they arrive, maintaining a minimal active memory footprint. During inference, full materialization of the model into the WASM heap is often impossible due to memory constraints. The architecture must implement paged weight access and layer streaming. By maintaining an open FileSystemSyncAccessHandle inside the Web Worker, the runtime synchronously reads only the specific tensor bytes required for the current transformer layer, executes the forward pass, and immediately reuses that memory region for the next layer's weights. Hybrid caching can be employed where the most frequently accessed layers (e.g., embedding tables and final projection layers) remain pinned in the WASM heap, while intermediate feed-forward layers stream from OPFS.

2.3 WASM32 Limits, Memory64 Readiness, and ArrayBuffer Duplication

Standard WebAssembly utilizes a 32-bit linear memory space, imposing a hard limit of 4 GiB (and realistically much less due to browser tab memory quotas)10. The legacy TinyRustLM implementation restricts single allocations to 128 MiB1. Fetching an entire model as a Blob, converting it to an ArrayBuffer, and then passing it to WASM results in ArrayBuffer duplication, instantly doubling the memory requirement and frequently crashing mobile browsers. The WebAssembly 3.0 specification introduced the Memory64 proposal, allowing 64-bit indices for memories and removing the 4 GiB addressing limitation12. As of mid-2026, Memory64 is broadly supported across Chrome, Edge, and Firefox, with Safari reaching parity in recent updates14. The runtime loader must dynamically detect Memory64 support. If present, the runtime maps the entire OPFS file into a 64-bit WASM memory space using chunked reads. If restricted to WASM32, the runtime strictly enforces layer streaming.

2.4 Cross-Origin Isolation and SharedArrayBuffer

To prevent UI blocking during extensive matrix multiplications, execution must be isolated within Web Workers. True multithreaded WASM requires SharedArrayBuffer (SAB) to allow multiple worker threads to access the identical linear memory space simultaneously, enabling parallel reduction algorithms16. However, SAB is restricted by strict browser security policies designed to mitigate Spectre-class vulnerabilities. The host document must be served with Cross-Origin Isolation headers16:

• Cross-Origin-Opener-Policy: same-origin (COOP)
• Cross-Origin-Embedder-Policy: require-corp (COEP)

Deploying these headers carries severe architectural consequences. Any cross-origin subresources (such as external images, analytics scripts, or CDN-hosted fonts) will be silently blocked by the browser unless they explicitly respond with Cross-Origin-Resource-Policy (CORP) headers17. The inference runtime must provide a graceful, single-threaded fallback utilizing standard ArrayBuffer message passing via postMessage if the host environment fails to achieve an isolated security context16.

2.5 Multi-Tab Contention and Worker Isolation

When multiple tabs attempt to instantiate the inference runtime, contention over OPFS file locks and GPU resources occurs. createSyncAccessHandle in "readwrite" mode takes an exclusive lock on the file, throwing a NoModificationAllowedError if another tab holds the lock7. The architecture must open handles in "read-only" mode for inference, permitting concurrent reads across tabs8. To manage GPU context limits and CPU thread saturation, the runtime utilizes the Web Locks API (navigator.locks.request) to coordinate a single primary background worker responsible for inference, passing message channels from secondary tabs to the primary active worker5.

3. WebGPU Evaluation and Compute Backend Topologies

The runtime must support a flexible compute dispatch system, treating WebGPU as an optional but highly preferred acceleration layer, with deterministic WebAssembly serving as the universal fallback.

3.1 Scalar Kernels vs. Portable SIMD vs. WebGPU

Scalar reference kernels, as observed in the TinyRustLM baseline1, process one floating-point operation at a time. While universally compatible and strictly deterministic, they yield unacceptable latency for auto-regressive generation. WASM SIMD128 allows 128-bit vectorization, processing four 32-bit floats per instruction, drastically improving CPU inference13. However, the highest performance is unlocked via WebGPU compute shaders, which parallelize matrix multiplications across thousands of GPU arithmetic logic units (ALUs). The decision to use WebGPU must not rely on synthetic matmul benchmarks alone; the overhead of encoding command buffers, binding resources, and executing memory barriers can exceed the compute time for small tensor dimensions, particularly at batch size 120.

3.2 Precision Support, Shader-f16, and Buffer Alignment

Memory bandwidth, rather than pure compute, constitutes the primary bottleneck in LLM inference21. The WebGPU shader-f16 extension enables the use of half-precision (f16) floating-point types natively within WGSL22. This effectively halves the memory bandwidth requirement and footprint, while doubling ALU throughput on compatible hardware. The preflight system must query adapter.features.has('shader-f16') and, if available, dispatch optimized FP16 shaders22. WebGPU mandates strict buffer alignment rules. Uniform buffers typically require 256-byte alignment, and storage buffers must align to 4 bytes. The Rust runtime allocator must guarantee these specific padding requirements during tensor materialization to prevent fatal validation errors from the browser's WebGPU implementation.

3.3 Shader Compilation and Device Loss

Synchronous compilation of complex WGSL shaders on the main thread causes severe blocking and degrades UI responsiveness20. The runtime must employ asynchronous pipeline creation (createComputePipelineAsync). Furthermore, the architecture must proactively handle WebGPU device loss, which occurs when the OS reclaims GPU resources, suspends the browser tab, or updates drivers25. The state machine must trap the adapter.requestDevice().lost promise, freeze the active generation context in main memory, and silently transition the runtime back to the Allocate phase to request a new adapter and recompile pipelines25.

3.4 Deterministic Execution and IEEE-754 Nuances

While WebGPU provides superior performance, it compromises strict determinism. The reduction order in GPU compute shaders varies depending on the hardware architecture, workgroup sizing, and dynamic thread scheduling27. Because floating-point addition is non-associative, these varied reduction paths yield divergent rounding errors. When accumulated across dozens of transformer layers, this entropy causes different GPUs to select entirely different tokens, resulting in macroscopic non-determinism27. If the UAIX context demands bit-for-bit cryptographic reproducibility (e.g., consensus-based verification), WebGPU must be deferred in favor of WASM execution3. To guarantee determinism in WASM, the runtime must:

1. Enable IEEE-754 NaN Canonicalization: Wasmtime and browser engines may produce different Not-a-Number (NaN) payloads28. The compiler must canonicalize all NaN values to a single, predictable bit pattern to prevent programs from branching non-deterministically based on arbitrary NaN bits28.
2. Control Relaxed SIMD: WebAssembly 3.0 formalized Relaxed SIMD, which allows native hardware Fused Multiply-Add (FMA) instructions to dictate precision rounding for maximum performance13. For strict determinism, the runtime must configure the execution environment (e.g., wasmtime::Config::relaxed\_simd\_deterministic) to emulate these instructions deterministically, accepting a minor performance penalty to preserve bit-exact outputs across differing CPU architectures13.

4. Operator Support Matrix and Architectural Admittance

The preflight validation phase must rigorously cross-reference the model's structural metadata against an explicit Operator Support Matrix. If a model relies on an unsupported operator or topology, the converter and runtime must refuse the allocation immediately, returning a specific diagnostic error rather than attempting execution and encountering undefined behavior.

4.1 Conventional Transformers and Attention Variants

Grouped-Query (GQA) and Multi-Query Attention (MQA) Unlike standard Multi-Head Attention (MHA), GQA and MQA optimize memory by sharing Key and Value heads across multiple Query heads33. The legacy TinyRustLM forward scratchpad rejects configurations where query and KV head counts differ1. The updated runtime must natively support GQA/MQA by implementing broadcasting logic within the scaled dot-product attention kernels, calculating the proper head ratio during the Validate phase. Sliding-Window Attention (SWA) SWA restricts the attention matrix to a localized, diagonal window, capping the maximum size of the KV cache and ensuring constant memory usage during long-context generation33. If a model specifies SWA, the runtime must enforce an evicting ring-buffer KV cache. Executing an SWA-trained model using unbounded full attention results in catastrophic memory waste and severe degradation of output quality. Partial RoPE and Q/K Normalization Rotary Position Embeddings (RoPE) are frequently applied to only a fraction of the embedding dimension to retain exact positional frequencies while allowing the remaining dimensions to encode position-agnostic semantic features34. The runtime must read the partial RoPE percentage from the model header and slice the tensor dimensions before applying the rotation. Additionally, Q/K Normalization applies RMSNorm independently to Query and Key projections prior to the dot product, mitigating "attention sinks" and stabilizing training dynamics35. The runtime must feature specific fused kernels to support per-head Q/K norm efficiently34. Gated Output Projections Certain architectures, such as Qwen3-Next, enhance stability by multiplying the final attention output by a sigmoid gate prior to the output projection34. The runtime must support this GatedAttention pattern, ensuring the sigmoid activation is applied correctly (distinguishing it from the SiLU activations used in the MLP blocks)34.

4.2 Linear Attention, Recurrent States, and SSMs

DeltaNet and Linear Attention DeltaNet, Gated DeltaNet, and Kimi Delta Attention replace the [Figure omitted from source export] softmax attention matrix with a fixed-size recurrent state, reducing sequence mixing to linear time and decoding to constant [Figure omitted from source export] memory39. Gated DeltaNet-2 further refines this by decoupling the write and erase phases using channel-wise decay and update gates39. The runtime must support maintaining a recurrent state tensor [Figure omitted from source export] that persists across decoding steps34. Furthermore, because optimal linear models often employ a hybrid architecture (e.g., interleaving three DeltaNet layers with one standard attention layer), the runtime scheduler must support dispatching heterogeneous layer types within a single forward pass40. Mamba and State Space Models (SSM) Mamba architectures replace standard attention with parallel associative scans during prefill and sequential recurrent steps during decoding44. Exporting SSMs through standard intermediate representations like ONNX often results in prohibitive loop-unrolling overhead or severe per-iteration kernel launch latencies (e.g., slowing execution by 17x)46. The Rust runtime must implement a native, highly fused selective scan operator that avoids these graph-tracing bottlenecks, executing the recurrence directly within contiguous memory46. Mixture of Experts (MoE) Sparse MoE architectures route tokens to a specific subset of available feed-forward networks (experts) via a routing linear layer. Due to strict WASM memory constraints, dynamic memory loading of experts during the forward pass is highly inefficient. The runtime must enforce that all potential expert weights are securely mapped into memory prior to execution, applying the appropriate top-k routing algorithm and normalizing the expert weights before the weighted sum.

4.3 Adapters and Explicit Rejection Rules

The architecture must support dynamic Low-Rank Adaptation (LoRA) modules. Adapters must be merged into the base weights during the Load/Map stage or computed dynamically as parallel branches if memory permits. The runtime converter must enforce strict rejection protocols:

1. Adapter/Base Mismatch: The adapter manifest must contain the exact cryptographic hash of the intended base model. If the hashes diverge, the adapter is refused to prevent dimensional collapse and undefined output.
2. Multimodal Checkpoints: Visual encoders, audio projections, and cross-attention blocks must be strictly refused until the runtime implements specific multimodal operator support and image-patch tokenization logic.
3. Unsupported Architecture Features: Unknown tensor suffixes, arbitrary non-byte-aligned quantization (e.g., 3-bit packs lacking specific dequantization kernels), and mismatched dimensional contracts (e.g., a header declaring [Figure omitted from source export] but providing payloads for [Figure omitted from source export]) must trigger immediate quarantine1.

OPEN QUESTION (Requires Local Code Inspection): Does the current SLM1 binary header specification reserve bit flags for MoE routing metadata, or must the format be versioned to SLM2 to support sparse expert mapping?

5. Tokenization and Vocabulary Management

Tokenization must be executed natively within the Rust/WASM boundary to eliminate the latency of serializing large token arrays across the JavaScript-WASM bridge. A high-performance implementation utilizing the tokenizers crate structure provides access to BPE and Unigram models47.

5.1 Unicode Normalization and Tokenizer Drift

To maintain deterministic generation across diverse operating systems and browsers, text inputs must undergo strict Unicode normalization (e.g., NFC or NFKC) prior to tokenization48. Without this, a composed character on macOS might yield a different token sequence than its decomposed equivalent on Windows, causing the model's output to diverge wildly50. The loader must also verify tokenizer drift. The cryptographic hash of the embedded tokenizer configuration must match the model's expected manifest; otherwise, the Validate stage aborts, preventing the model from generating gibberish due to misaligned vocabulary indices.

5.2 Special Tokens and Vocabulary Row Suppression

The runtime must rigidly separate standard vocabulary from control tokens (e.g., \<|im\_start|\>, \<|endoftext|\>). If a quantized model includes padded vocabulary rows for memory alignment (e.g., padding a vocabulary of 32,000 to 32,064 to satisfy 64-byte blocking), the runtime's sampler must aggressively suppress the undefined indices. The logits for these trailing rows must be overwritten with [Figure omitted from source export] prior to the softmax transformation, mathematically eliminating the possibility of the model sampling an undefined token and causing an out-of-bounds index panic during decoding.

6. KV-Cache, Recurrent States, and Prefix Reuse

Autoregressive decoding is inherently memory-bound, as the model must attend to the Key and Value tensors of all preceding tokens. The runtime requires sophisticated caching mechanisms to prevent memory exhaustion and fragmentation21.

6.1 Layout and Paged Attention

The legacy methodology of pre-allocating contiguous memory blocks equal to the maximum theoretical context window results in catastrophic memory waste and fragmentation21. The runtime must implement a Paged Attention architecture, analogous to virtual memory paging in operating systems21. The KV cache is divided into fixed-size blocks (e.g., 16 or 32 tokens per block), dynamically mapped through a virtual block table21. This layout natively supports complex decoding strategies like beam search by allowing multiple sequences to share underlying physical memory blocks safely21. For DeltaNet and linear attention architectures, the KV cache is replaced (or heavily supplemented) by a fixed-size recurrent state. The memory layout for these states requires contiguous allocations of [Figure omitted from source export] matrices, which update continuously via the delta rule rather than expanding linearly with sequence length39.

6.2 Prefix Reuse and Cache Quantization

Paged Attention enables exact Prefix Caching (e.g., via Radix Attention trees)21. When a new prompt is submitted, the runtime hashes the prompt's tokens and checks the block table for existing matches (such as a shared system prompt or persistent RAG context). If a match is found, the runtime reuses the existing KV state, completely bypassing the prefill compute phase for that specific prefix, driving Time To First Token (TTFT) down dramatically33. To further compress the memory footprint, the architecture mandates KV Cache Quantization33. Keys and values are dynamically quantized to INT8 or FP8 formats upon insertion into the cache, accompanied by highly granular, per-channel FP16 or FP32 scaling factors33. This reduces the KV memory requirement by 50% while preserving near-exact attention distributions, fundamentally extending the context limits possible within constrained WASM memory boundaries.

7. Deterministic Sampling and Generation State

The generation loop is responsible for transforming raw logits into token selections. To achieve cryptographic reproducibility, the generation mechanics must be hermetically sealed against external entropy.

7.1 Deterministic Seeds and Penalty Mechanics

The runtime must rely on a cryptographically sound, deterministic Pseudo-Random Number Generator (PRNG), such as PCG32 or ChaCha8, initialized strictly by a seed passed in the API request payload1. The host browser's Math.random() is strictly prohibited. Repetition penalties and presence penalties must be applied directly to the logits array prior to sampling. For Top-K and Top-P (nucleus) bounding, the logits array is sorted using a fixed-size heap allocation to avoid dynamic memory resizing and associated garbage collection pauses during the high-frequency generation loop.

7.2 Malformed-Logit Handling

Floating-point underflow or extreme activation values can occasionally result in NaN (Not-a-Number) or [Figure omitted from source export] values appearing in the logits vector. If fed into a standard softmax function, a single NaN will propagate, corrupting the entire probability distribution and causing the sampler to panic. The runtime must implement strict malformed-logit handling: any invalid float is intercepted, masked to [Figure omitted from source export], and if the entire distribution collapses, the sampler defaults to a deterministic safety stop token (e.g., \<|endoftext|\>), gracefully halting generation without crashing the underlying Web Worker.

8. Normative Runtime Lifecycle and State Machine

To enforce strict memory safety and predictable resource consumption, the architecture implements a highly regimented, unidirectional lifecycle state machine.

OPEN QUESTION (Requires Local Code Inspection): Does the current implementation's Allocate phase create separate memory arenas for KV blocks and transient forward-pass scratchpads, or are they interleaved in a manner that requires a unified garbage collection pass?

9. Memory Formulas and Bounded Resource Budgets

Predictable execution requires deterministic memory budgeting. The preflight algorithm evaluates these formulas before any allocation occurs, preventing the runtime from triggering the browser's Out-Of-Memory (OOM) killer.

9.1 Mathematical Memory Formulations

For a conventional dense decoder-only transformer, the memory requirements are defined by the following variables:

• [Figure omitted from source export]: Layer count
• [Figure omitted from source export]: Query heads
• [Figure omitted from source export]: Key/Value heads
• [Figure omitted from source export]: Head dimension
• [Figure omitted from source export]: Vocabulary size
• [Figure omitted from source export]: Context length (tokens)
• [Figure omitted from source export]: Feed-forward hidden dimension

KV Cache Allocation: Assuming an FP16 KV cache configuration: [Figure omitted from source export] (Note: If INT8 KV Cache Quantization is enabled, the trailing multiplier becomes [Figure omitted from source export], plus the overhead for FP32 channel scales33) Forward Scratchpad: Derived from TinyRustLM constraints, holding intermediate activations requires: [Figure omitted from source export] \[cite: 2\] Logits: Processed in standard FP32 for numerical stability prior to softmax: [Figure omitted from source export] \[cite: 2\]

9.2 Preflight Algorithm

The preflight algorithm operates precisely as follows:

1. Parse metadata ([Figure omitted from source export]) from the validated header1.
2. Calculate the exact byte requirement for static weights using payload datatypes.
3. Calculate active KV cache size based on user-requested context bounds.
4. Calculate forward scratchpad size based on the maximum parallel prefill chunk size.
5. Sum values. If the sum exceeds the available WASM memory limit or WebGPU VRAM buffer limits, abort immediately and return a ResourceExhausted JSON diagnostic indicating the specific byte overrun.

9.3 Bounded Example Budgets

Budget 1: Compact Specialist Model (TinyLM-16M) Parameters: [Figure omitted from source export]. Precision: FP16 Weights / FP16 KV.

Budget 2: Quality Assistant Model (1.5B Parameter Class) Parameters: [Figure omitted from source export]. Precision: INT4 Weights / INT8 KV (GQA enabled).

Crucial Architecture Note: By utilizing OPFS file handles and strict Web Worker boundaries, the JavaScript Main-Thread wrapper maintains a footprint of essentially 0 bytes concerning tensor data. This eliminates the catastrophic ArrayBuffer memory duplication inherent in legacy fetch()-based loaders4.

10. Performance Measurement and Benchmark Protocol

Benchmarking in a browser environment is notoriously susceptible to garbage collection pauses, JIT compilation warmup illusions, and aggressive background tab throttling. To ensure performance metrics cannot report a "fake success," the architecture enforces a strict 10-point measurement protocol:

1. Source First-Token Parity: The generated sequence must be bit-for-bit identical to the output of a native Python/PyTorch reference implementation utilizing the identical quantized weights and seed. Any divergence indicates a mathematical fault in the WASM/WGSL kernels.
2. Deterministic Known-Tensor Tests: Automated tests must execute against a predefined tiny model (e.g., the 4.8K parameter fixture1) to definitively verify that SIMD reductions do not diverge mathematically across different host architectures (e.g., ARM64 vs. x86-64).
3. Phase Separation: Prefill metrics (prompt processing) must be strictly isolated from Autoregressive Decode (tokens/second) metrics. Blending the two masks slow generation speeds and misrepresents sustained throughput.
4. Latency Tracking: Time To First Token (TTFT) must be measured from the exact millisecond the DOM click event fires—not from when the WASM module starts executing. This ensures the measurement accurately captures Web Worker spin-up and OPFS lock-acquisition latency.
5. Memory Auditing: Peak committed memory must be actively measured via navigator.storage.estimate() and performance.memory. A test fails automatically if duplicate ArrayBuffer host copies are detected in the JavaScript heap.
6. Cancellation Responsiveness: A cancellation signal injected via SharedArrayBuffer atomics must halt the WASM execution loop in under 16ms (roughly one UI frame). Failure to yield indicates a thread deadlock that compromises UI responsiveness54.
7. Browser Matrix Enforcement: Automated benchmark suites must run cross-browser (Chrome V8, Firefox SpiderMonkey, Safari JavaScriptCore) on both Desktop and Mobile hardware matrices to identify WebGPU or WASM engine regressions14.
8. Contention & Recovery: The test harness must spawn multiple competing tabs and intentionally simulate a WebGL/WebGPU context crash (device loss), measuring the engine's ability to gracefully release navigator.locks and reset5.
9. Visual Pixel Checks: Where output directly dictates UI state (e.g., canvas rendering of syntax highlighting or structured JSON forms), headless browser DOM snapshots are compared against verifiable baselines to detect rendering corruption.
10. Overflow Safety: Long-running generation must intentionally exceed the context window bound [Figure omitted from source export] to verify that the ring-buffer eviction policy safely rotates without causing memory corruption, index out-of-bounds panics, or halting execution.

11. Security Boundaries and Deterministic Diagnostics Schema

The runtime operates strictly inside a sandboxed Web Worker, possessing zero network access and zero broad filesystem access, mitigating remote code execution vulnerabilities inherent in native Python deployments. When a failure occurs, the runtime yields a deterministic JSON diagnostic schema summarizing the fault without leaking memory pointers or proprietary prompts. The schema captures:

• timestamp\_utc: ISO 8601 string.
• stage\_classification: The exact lifecycle state (e.g., Load/Map, Generate)2.
• error\_class: Stable enum identifier (e.g., ChecksumMismatch, NaN/InfDetected).
• model\_manifest\_hash: SHA-256 identity of the artifact1.
• runtime\_environment: Feature toggles (e.g., Memory64: true, WebGPU: false, SAB: true).
• resource\_ledger: Peak memory requested versus WASM maximum boundary.

This structured evidence enables reliable telemetry and remote debugging while honoring the UAIX constraint regarding user data privacy.

12. Browser Compatibility Matrix

To support the proposed architecture, the following baseline compatibilities define the deployment boundary for 2026:

13. TDD Backlog, Phased Acceptance Criteria, and Rollback Strategy

The transition from the legacy TinyRustLM scalar implementation to the target architecture follows a Phased Test-Driven Development (TDD) backlog:

• Phase 1: Concurrency and OPFS (The Memory Foundation)
• Criteria: Move existing scalar execution off the main thread into a Web Worker. Implement OPFS createSyncAccessHandle for model loading.
• Success: Eradication of the 128MB transfer bottleneck and verifiable zero-copy mapping.
• Phase 2: Architectural Parity (The Model Expansion)
• Criteria: Implement GQA, SWA, partial RoPE, and per-head Q/K RMSNorm kernels.
• Success: Capability to ingest and deterministically execute modern open-weight architectures beyond the legacy TinyLM topology.
• Phase 3: Caching & Optimization (The Speed Multiplier)
• Criteria: Build the Paged Attention virtual block table and implement radix-based prefix caching21.
• Success: 80%+ TTFT latency reduction for multi-turn conversations.
• Phase 4: WebGPU & SIMD Acceleration (The Compute Scaling)
• Criteria: Introduce the shader-f16 WGSL compute pipelines alongside deterministic Relaxed SIMD WASM fallbacks13.
• Success: Sub-50ms token generation latency on 1.5B parameter models.

Rollback Strategy

Revisions to the WASM binary runtime or the underlying WebGPU shaders must be strictly isolated from the host site utilizing immutable, versioned CDN assets. If a newly deployed tinyrustlm-runtime.wasm violates the First-Token Parity check or triggers an unrecoverable NaN fault during client-side execution, the JavaScript host wrapper must automatically intercept the error\_class, evict the versioned WASM artifact from the browser's Cache Storage, and gracefully roll back to the prior stable WASM hash without requiring a page refresh or user intervention.

Works cited

1. https://mirust.com/implementation/
2. https://mirust.com/implementation-operations/
3. Talisman Talkback \- Teleodynamic AI, https://teleodynamic.com/talisman-talkback/
4. WebLLM Cache Usage \- GitHub, https://github.com/mlc-ai/web-llm/blob/main/examples/cache-usage/README.md
5. 3x faster project loads with the origin private file system \- Between the Barndoors, https://barndoors.lumafield.com/3x-faster-project-loads-with-the-origin-private-file-system/
6. Origin private file system \- Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/File\_System\_API/Origin\_private\_file\_system
7. The Current State Of SQLite Persistence On The Web: May 2026 Update \- PowerSync, https://powersync.com/blog/sqlite-persistence-on-the-web
8. FileSystemFileHandle: createSyncAccessHandle() method \- Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/FileSystemFileHandle/createSyncAccessHandle
9. Origin Private File System (OPFS) Database with the RxDB OPFS-RxStorage, https://rxdb.info/rx-storage-opfs.html
10. Ported my C game to WASM, here's every bug that I hit | Hacker News, https://news.ycombinator.com/item?id=48506980
11. Memory limits in Pyodide \- webassembly \- Stack Overflow, https://stackoverflow.com/questions/75559641/memory-limits-in-pyodide
12. WebAssembly Memory64 \- Chrome Platform Status, https://chromestatus.com/feature/5070065734516736
13. WebAssembly 3.0 Is Official: Nine Features That Change What Wasm Can Do | byteiota, https://byteiota.com/webassembly-30-spec-release/
14. Memory64 (WebAssembly) | Can I use... Support tables for HTML5, CSS3, etc \- CanIUse, https://caniuse.com/wf-wasm-memory64
15. Spring 2025 Web Dev Highlights: 12 Months Later, What Aged Well in 2026 \- Fora Soft, https://www.forasoft.com/blog/article/spring-2025-web-dev-highlights
16. SharedArrayBuffer \- JavaScript \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global\_Objects/SharedArrayBuffer
17. WASM Threads: Browser Support, Atomics, COOP/COEP \- TestMu AI, https://www.testmuai.com/learning-hub/wasm-threads-browser-support/
18. Enable Wasm threads (SharedArrayBuffer) with COOP/COEP \- Cinevva, https://app.cinevva.com/tutorials/coop-coep-sharedarraybuffer
19. Wasmi 1.0 — WebAssembly Interpreter Stable At Last, https://wasmi-labs.github.io/blog/posts/wasmi-v1.0/
20. Characterizing WebGPU Dispatch Overhead for LLM Inference Across Four GPU Vendors, Three Backends, and Three Browsers \- arXiv, https://arxiv.org/pdf/2604.02344
21. The Complete Guide to KV Cache in LLM Inference \- Medium, https://luv-bansal.medium.com/the-evolution-of-kv-cache-from-simple-buffers-to-distributed-memory-systems-df51cb8ce26f
22. GPUSupportedFeatures \- Web APIs \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/API/GPUSupportedFeatures
23. FP16 support · Issue \#658 \- GitHub, https://github.com/gpuweb/gpuweb/issues/658
24. Graphics Programming Weekly \- Database \- Jendrik Illner, https://www.jendrikillner.com/article\_database/
25. Open Metaverse Browser Architecture \- RP1, https://cdn.rp1.com/product/Open-Metaverse-Browser-Architecture.pdf
26. babylonjs-loaders \- Yarn Classic, https://classic.yarnpkg.com/en/package/babylonjs-loaders
27. LLM-42: Enabling Determinism in LLM Inference with Verified Speculation \- arXiv, https://arxiv.org/html/2601.17768v1
28. Deterministic Wasm Execution \- Wasmtime, https://docs.wasmtime.dev/examples-deterministic-wasm-execution.html
29. Floating-point min and max that prefer numbers · Issue \#1548 · WebAssembly/design, https://github.com/WebAssembly/design/issues/1548
30. Numerics — WebAssembly 3.0 (2026-06-19), https://webassembly.github.io/spec/core/exec/numerics.html
31. WebAssembly/relaxed-simd: Relax the strict determinism requirements of SIMD operations. \- GitHub, https://github.com/webassembly/relaxed-simd
32. Intent to Ship: WebAssembly Relaxed SIMD \- Google Groups, https://groups.google.com/a/chromium.org/g/blink-dev/c/HzLlEGLSx7E
33. KV Cache Optimization for LLMs 2026: Engineering Guide \- Digital Applied, https://www.digitalapplied.com/blog/kv-cache-optimization-techniques-2026-engineering-guide
34. speech-swift/docs/models/qwen35-chat.md at main \- GitHub, https://github.com/soniqo/speech-swift/blob/main/docs/models/qwen35-chat.md
35. AFMoE \- Hugging Face, https://huggingface.co/docs/transformers/model\_doc/afmoe
36. QG-MIL: A Gated Transformer Aggregator for Domain-Agnostic Multiple Instance Learning in Medical Imaging \- arXiv, https://arxiv.org/html/2606.20027v1
37. QG-MIL: A Gated Transformer Aggregator for Domain-Agnostic Multiple Instance Learning in Medical Imaging \- arXiv, https://arxiv.org/pdf/2606.20027v1.pdf?utm\_source=xrayinterpreter.com
38. Gated DeltaNet for Linear Attention \- rasbt/LLMs-from-scratch \- GitHub, https://github.com/rasbt/LLMs-from-scratch/blob/main/ch04/08\_deltanet/README.md
39. Gated DeltaNet-2: Decoupling Erase and Write in Linear Attention \- arXiv, https://arxiv.org/html/2605.22791v1
40. Gated DeltaNet: The “Surgical Eraser” Solving Linear Attention's Memory Problem | by Revanth Madamala | Towards AI, https://pub.towardsai.net/gated-deltanet-the-surgical-eraser-solving-linear-attentions-memory-problem-1e50ca3e42ab
41. Why is Linear Attention more efficient than Softmax? What's the tradeoff? \- Medium, https://medium.com/kairi-ai/why-is-linear-attention-more-efficient-than-softmax-whats-the-tradeoff-0ed1a2999267
42. Gated DeltaNet-2: Decoupling Erase and Write in Linear Attention \- Research at NVIDIA, https://research.nvidia.com/publication/2026-05\_gated-deltanet-2-decoupling-erase-and-write-linear-attention
43. Gated DeltaNet | Sebastian Raschka, PhD, https://sebastianraschka.com/llms-from-scratch/ch04/08\_deltanet/
44. Hangrui Cao — Machine Learning Engineer · Zoom, https://diegocao.github.io/
45. Why aren't we freaking out more about Mamba/RWKV/XLSTM? \- Reddit, https://www.reddit.com/r/LocalLLaMA/comments/1al5wrf/why\_arent\_we\_freaking\_out\_more\_about/
46. \[Feature Request\] ONNX Loop op makes Mamba (SSM) models unusable on CPU and WebGPU · Issue \#27796 · microsoft/onnxruntime \- GitHub, https://github.com/microsoft/onnxruntime/issues/27796
47. tokenizers::tokenizer \- Rust \- Docs.rs, https://docs.rs/tokenizers/latest/tokenizers/tokenizer/index.html
48. tokenizers \- Rust \- Docs.rs, https://docs.rs/tokenizers/
49. tokenizers \- crates.io: Rust Package Registry, https://crates.io/crates/tokenizers/0.21.0
50. Components \- Hugging Face, https://huggingface.co/docs/tokenizers/components
51. Unicode Normalization at GB/s : r/rust \- Reddit, https://www.reddit.com/r/rust/comments/1u7r8m7/unicode\_normalization\_at\_gbs/
52. KV cache reuse — TensorRT-LLM \- GitHub Pages, https://nvidia.github.io/TensorRT-LLM/advanced/kv-cache-reuse.html
53. KV Cache Reuse (a.k.a. prefix caching) — NVIDIA NIM for Large Language Models (LLMs), https://docs.nvidia.com/nim/large-language-models/1.7.0/kv-cache-reuse.html
54. WebAssembly Multi-threading Cheat Sheet: WASM & SharedArrayBuffer \- Tech Bytes, https://techbytes.app/posts/wasm-multithreading-sharedarraybuffer-cheat-sheet/
55. WebGL & WebGPU Checker: Test Your Browser's GPU | Cinevva, https://app.cinevva.com/tools/webgl-webgpu-checker