Implementation Architecture for a WebGPU Quantized Transformer Backend: Memory Planning and Device-Loss Recovery

Full report

On this page

1. Executive WebGPU Adoption Recommendation and Assumptions

The integration of a WebGPU execution backend into the TinyRustLM ecosystem presents a substantial opportunity to accelerate local inference by shifting heavy matrix operations from CPU and WebAssembly (WASM) constraints to highly parallel GPU hardware. Operating under the strict constraints of a purely browser-local architecture, this report outlines the foundational requirements and detailed technical specifications for an optional, high-performance WebGPU backend. The fundamental premise of this architecture is that model bytes and user prompts must remain strictly local, preserving privacy by ensuring no data flows outside of consenting peer connections. Based on an exhaustive analysis of the World Wide Web Consortium (W3C) WebGPU and WebGPU Shading Language (WGSL) specifications, alongside current browser shipping documentation and observed vendor implementations, the engineering recommendation is to proceed with the WebGPU backend adoption under strict deterministic constraints1. WebGPU must be treated as an unreliable but highly performant accelerator rather than a persistent, infallible state machine. The architectural baseline assumes that the browser-local environment cannot guarantee GPU memory availability, execution stability, or immediate feature parity with native APIs such as CUDA or Metal. Consequently, the backend must be built upon the principle of fallback-driven design. The native WASM CPU path remains the ultimate source of truth and the fallback execution environment. The WebGPU backend must act strictly as a transparent delegate for the prefill and decode transformer graph, preserving exact semantic identity, tokenizer behaviors, Key-Value (KV) cache structures, and the behavioral contract of the baseline CPU path. Arbitrary shader generation is strictly prohibited to prevent injection vulnerabilities and state corruption; the system must rely on bounded, trusted, and static WGSL modules specialized only via pipeline constants. The browser tab lifecycle dictates GPU resource limits, requiring explicit destruction protocols, rigid static memory planning, and highly robust device-loss state machines to ensure continuous product availability.

2. Standards, Browser, OS, and Feature-Support Matrix

As of mid-2026, WebGPU has achieved critical mass, shipping by default in stable builds of Google Chrome, Mozilla Firefox, Microsoft Edge, and Apple Safari across major operating systems3. The specification is currently operating as a Candidate Recommendation Draft, with the W3C actively integrating advanced compute capabilities1. The deployment landscape is heterogeneous, relying on underlying native graphics APIs that vary by operating system and hardware architecture.

The TinyRustLM backend relies on specific optional WebGPU features for performant inference, which must be negotiated during adapter acquisition. The shader-f16 feature allows the use of half-precision floating-point types natively within WGSL7. This effectively doubles theoretical throughput and halves register pressure, which is vital for bandwidth-bound transformer decode phases. The subgroups feature unlocks SIMD-level parallelism, allowing threads within a wave to share data directly without round-tripping through shared workgroup memory9. This is absolutely critical for highly efficient block-tiled GEMV (General Matrix-Vector) reductions via built-in functions like subgroupAdd and subgroupBroadcast10. Crucially, not all devices supporting shader-f16 support subgroups-f169. The admission algorithm must explicitly probe these combinations and seamlessly degrade to standard shared-memory reductions or f32 accumulation if specific subgroup extensions are absent. Furthermore, high-precision timing attacks are mitigated by browsers restricting the timestamp-query feature; thus, telemetry must gracefully degrade to performance.now() wrapped around queue submissions when hardware timestamps are unavailable11.

3. Backend Admission and Privacy-Minimized Capability Receipt

WebGPU implementations are strictly required by the W3C specification to mitigate fingerprinting by restricting the exposure of actual hardware limits, binning them into a maximum of 32 distinguishable configurations1. Therefore, the mere existence of navigator.gpu on the window object does not guarantee that the adapter is capable of running TinyRustLM. The backend-admission algorithm must be implemented as a sequential state machine that requests only the minimal necessary features, tests the bounds via bounded numerical self-tests, and establishes a privacy-minimized capability receipt. The versioned admission algorithm begins by requesting an adapter with a high-performance power preference. If the adapter is a fallback adapter (e.g., a software rasterizer), admission is immediately rejected to prevent catastrophic performance degradation1. The algorithm then conditionally bundles requested features, prioritizing shader-f16, subgroups, and subgroups-f16 if the adapter reports their availability. Instead of querying raw VRAM, which is obscured, the algorithm constructs a requiredLimits dictionary reflecting the exact byte requirements of the target model's topology. This includes setting maxStorageBufferBindingSize (defaulting to 128MB) and maxBufferSize (defaulting to 256MB) to the maximum tensor sizes required by the network13. If the adapter's binned limits are strictly less than these requirements, the admission fails deterministically without exposing the user's actual physical VRAM capacity1. Upon successfully requesting the device, the algorithm utilizes pushErrorScope("out-of-memory") to perform an empirical memory probe14. A staging buffer equivalent to the model's footprint is allocated. If popErrorScope() yields a GPUOutOfMemoryError, the allocation is destroyed, and the system falls back to WASM15. Finally, a bounded numerical self-test is executed. A deterministic golden vector is passed through a minimal WGSL compute shader utilizing the requested features. If the output deviates from the expected IEEE-754 tolerance, it indicates a vendor-specific driver artifact or non-compliant floating-point contraction, prompting immediate rejection. The output of this pipeline is a sealed capability receipt, dictating exactly which kernels and memory limits the application may utilize.

4. Typed CPU/WASM/WebGPU Ownership and Command Boundary

The architectural boundary between the host runtime (JavaScript/WASM) and the backend execution engine (WebGPU) must be strictly defined to prevent security boundaries from blurring. JavaScript execution environments cannot be permitted to reinterpret untrusted tensor offsets or dynamically construct WGSL strings, as this introduces severe injection and memory validation vulnerabilities. The ownership model delegates distinct responsibilities. The Host (JS/WASM) exclusively owns model validation, the tokenizer, prompt parsing, sampling logic (including temperature, top-k, and top-p calculations), KV sequence metadata, and overall cancellation logic. The WebGPU Backend exclusively owns the quantized static weight buffers, the physical KV-cache VRAM allocation, activation scratch arenas, compiled pipeline objects, and raw logits extraction. To enforce this separation, the boundary utilizes a typed message-passing architecture consisting of specific, rigid commands. The CMD\_INIT command accepts the capability receipt and transfers immutable buffers to the GPU. The CMD\_PREFILL command accepts a batched array of prompt tokens and their corresponding KV sequence offsets, dispatching the prefill graph without returning intermediate data to the host. The CMD\_DECODE command operates similarly for single-token autoregressive generation. The CMD\_EXTRACT\_LOGITS command explicitly maps the final output layer's buffer to the CPU, allowing the WASM runtime to perform token sampling. By keeping the sampler on the CPU, the architecture ensures the behavioral contract remains identical between the WebGPU and WASM paths; GPU shaders do not generate random numbers or manipulate the token vocabulary directly. Finally, a CMD\_EVICT command explicitly invokes destroy() on all WebGPU objects, preventing zombie buffers from leaking across page unloads or worker terminations15.

5. Transformer Graph and Prefill/Decode Execution Plan

Mapping a complete decoder-only transformer graph to WebGPU requires separating the execution strategy into two distinct paradigms due to the fundamental differences in memory access patterns: Prefill (prompt processing) and Decode (autoregressive generation). During the prefill phase, the system processes a large batch of tokens simultaneously. The dominant operation is General Matrix-Matrix Multiplication (GEMM). Computations are heavily bound by compute hardware (ALUs) rather than memory bandwidth. The WGSL execution plan mandates that workgroups load distinct tiles of the static weight matrix and the activation matrix into workgroup shared memory. Synchronization via workgroupBarrier() ensures all threads have coalesced their memory reads before the dot products are calculated17. In this phase, operator fusion is less critical, as the computational density of the GEMM effectively hides the latency of writing intermediate activations to VRAM. Conversely, during the decode phase, the system processes exactly one token per iteration. The dominant operation degrades to General Matrix-Vector Multiplication (GEMV). Computations are strictly bound by memory bandwidth, meaning the GPU execution units are starved for data. Here, the execution plan pivots to leverage subgroups. Threads load vectors of quantized weights, multiply them by the broadcasted single-token activation, and reduce the results intra-wave using subgroupAdd and subgroupBroadcast10. Maximum operator fusion is absolutely critical during decode. Operations such as RMSNorm, QKV projections, and Rotary Position Embeddings (RoPE) must be fused into single WGSL dispatch calls to prevent round-tripping intermediate tensors to VRAM. A kernel perfectly optimized for prefill will yield catastrophic performance for single-token decode due to dispatch overhead and memory latency19.

6. q8, q4, Floating-Point, Attention, and FFN Kernel Specifications

WebGPU does not currently support hardware-accelerated tensor cores or matrix-multiply-accumulate (MMA) instructions universally across all target adapters. Consequently, kernels must be meticulously handwritten and optimized in WGSL, accommodating specific quantized tensor layouts directly rather than relying on driver-level abstractions. To avoid inventing a universal .slm encoding, the backend maps validated artifact descriptors directly to fixed WebGPU storage buffers. For 8-bit quantization (q8), weights are packed into u32 blocks. A standard block contains 32 weights and a single f16 scale. The WGSL kernel utilizes the built-in unpack4x8snorm(e: u32) \-\> vec4\<f32\> function to efficiently dequantize four weights simultaneously directly into a floating-point vector20. The resulting values are then multiplied by the broadcasted block scale. For 4-bit quantization (q4), weights are packed tightly, with eight weights per u32 container. Because WGSL lacks a native unpack8x4 intrinsic, the kernel must perform explicit bitwise shifts and logical masks (e.g., (e \>\> 4u) & 0xFu) to extract the individual nibbles. Scales and zero-points are stored at the block level, typically utilizing block sizes of 32 or 64\. Crucially, dequantization occurs directly in the thread registers immediately prior to the fused multiply-add (FMA) operation. Placing dequantized f32 values into shared workgroup memory drastically increases register pressure and cache thrashing, leading to suboptimal occupancy. The Feed-Forward Network (FFN) utilizes gated structures, such as SwiGLU. The WGSL kernel dispatches a fused GEMV that computes both the gate and the up-projection simultaneously. It applies the SiLU activation inline and immediately performs the element-wise multiplication before writing the final output to the scratch arena. This eliminates an entire read-write cycle to global VRAM, which is essential for preserving bandwidth during decode.

7. KV-Cache and Long-Context GPU Design

The Key-Value (KV) Cache must be architected separately from static model weights to facilitate mutability, rolling context windows, and efficient memory reuse. The design avoids allocating separate buffers per layer, which would exceed the maxBindingsPerBindGroup or maxStorageBuffersPerShaderStage limits on constrained devices13. The GPU layout utilizes a single contiguous VRAM allocation for the entire KV cache, partitioned logically by layer, attention head, and sequence index. Keys and Values are interleaved (\[K, V, K, V...\]) in memory, optimizing cache-line utilization during the attention reduction phase. This layout explicitly supports Grouped-Query Attention (GQA) by allowing multiple query heads to mathematically map to a single KV head index via modulo arithmetic within the shader. While complex PageAttention mechanisms are popular in native inference servers, they require extensive pointer-chasing through index buffers. WebGPU strictly limits the number of dynamically offset storage buffers (defaulting to 4 via maxDynamicStorageBuffersPerPipelineLayout), rendering deep pointer-chasing highly inefficient13. Therefore, the optimal design uses statically bound, contiguous ring buffers. Context truncation is managed exclusively by the CPU, which overrides the logical sequence length and directs the GPU to overwrite old token indices via circular buffer arithmetic in the WGSL kernel. This completely eliminates the need to perform costly readbacks of the KV state to the CPU.

8. Deterministic Memory Planner and Resource Formulas

Because WebGPU lacks a standardized API to query instantaneous free VRAM, relying on garbage collection for large tensor allocations leads to unpredictable out-of-memory crashes14. TinyRustLM must utilize a fully deterministic, static memory planner that pre-calculates the exact byte footprint of the model prior to device admission. The memory formulas dictate the exact layout. For a model with [Figure omitted from source export] layers, [Figure omitted from source export] heads, dimension [Figure omitted from source export], and a maximum context sequence length of [Figure omitted from source export]:

• Static Weights ([Figure omitted from source export]): Derived precisely from the total bytes of the Q4/Q8 packed weights, block scales, and zero points.
• KV Cache ([Figure omitted from source export]): Calculated as [Figure omitted from source export] bytes (assuming f16 storage).
• Activation Arena ([Figure omitted from source export]): Calculated as [Figure omitted from source export] bytes. This memory is mathematically aliased across all transformer layers using a ping-pong buffer binding strategy, ensuring that intermediate activations do not consume linear space.
• Logits ([Figure omitted from source export]): Calculated as [Figure omitted from source export] bytes (assuming f32 precision for the vocabulary size [Figure omitted from source export]).

The memory planner explicitly enforces alignment constraints. WebGPU mandates that the offset parameter within any buffer binding must be a multiple of minStorageBufferOffsetAlignment, which is strictly enforced at 256 bytes across all compliant browsers1. The planner pads all tensor dimensions and scratch spaces to 256-byte boundaries. Furthermore, if any single logical buffer exceeds the maxStorageBufferBindingSize (default 128MB) or maxBufferSize (default 256MB), the tensors must be deterministically sharded across multiple GPUBindGroup objects13. Non-overlap proofs for aliased arenas are statically verified by the planner, completely bypassing the browser's internal garbage collection heuristics.

9. Pipeline, Bind-Group, Shader, and Cache Identity

Compiling large WGSL modules blocks the main thread if executed synchronously. All pipeline creation must utilize createComputePipelineAsync to ensure the browser UI remains responsive23. However, managing the lifecycle of these pipelines requires a rigorous caching identity mechanism to prevent the accidental execution of stale code. Cache keys are mathematically bound to the exact execution parameters. A unique key is generated by hashing the source WGSL module string, the applied specialization constants (e.g., workgroup dimensions, block sizes), the specific tensor layout identifier, the negotiated feature set (shader-f16, subgroups), and the browser/GPU vendor identity string. This prevents a cache collision where a pipeline optimized for a desktop discrete GPU is erroneously loaded on a fallback integrated GPU. Because WebGPU implementations aggressively sandbox compilation caches to prevent cross-origin tracking and fingerprinting, the application cannot manually clear the driver-level cache1. Therefore, TinyRustLM manages an application-level identity map. If a pipeline fails to compile asynchronously due to a backend validation error, the cache explicitly rejects partial model activation, halts the WebGPU initialization, and safely routes the request back to the WASM CPU path.

10. Cancellation, Device Loss, Explicit Destruction, and Fallback State Machine

The GPU ecosystem within a browser context is highly volatile. The underlying GPU process may crash, the operating system may reclaim the adapter during power-state changes, or a mobile browser may quietly evict WebGPU contexts when a tab is backgrounded15. A robust state machine governs device-loss recovery and fallback execution. The state machine initializes in the ACTIVE state, facilitating normal command submission. If the GPUDevice.lost promise resolves, the system transitions to DEVICE\_LOST11. The state machine analyzes the reason attribute of the GPUDeviceLostInfo object. If the reason is "destroyed", it indicates an intentional teardown by the application (e.g., a deliberate model swap), and the system transitions to IDLE14. If the reason is "unknown", a fatal driver error, timeout detection and recovery (TDR) event, or unhandled out-of-memory exception has occurred14. The system immediately transitions to FALLBACK. In the FALLBACK state, the GPU context is deemed irrevocably dead. All WebGPU handles, buffers, and command encoders are considered invalid. The JavaScript host controller immediately serializes the current token sequence. Because the host exclusively owns the conversational state, duplicate output is structurally prevented. The controller passes the exact token sequence to the WASM CPU path, allowing the generation to continue seamlessly. If the user initiates a cancellation mid-generation, the machine enters the CANCEL state. Because an encoded command buffer submitted via queue.submit() cannot be preempted25, the controller ignores any asynchronous readbacks, calls .destroy() on the mapped output buffers, and terminates the worker.

11. Security and Malicious-Artifact Threat Model

Running untrusted tensor architectures on client GPUs presents severe security risks. While WebGPU is designed with memory safety at its core, application-level vigilance is paramount to prevent resource exhaustion and data leakage. The generation of arbitrary WGSL based on untrusted model metadata is strictly prohibited. Relying on string concatenation to build shaders opens the door to WGSL injection attacks, potentially allowing a malicious model to write arbitrary code loops that hang the GPU process. The backend relies solely on statically bundled, trusted WGSL modules that are specialized via heavily validated numeric pipeline constants. Robust buffer access is inherently guaranteed by the WebGPU specification; if a maliciously crafted tensor dictates dimensions that cause a shader to read out of bounds, the implementation must either clamp the index, return zero, or discard the write1. However, to prevent unintended behavioral drift, the WGSL kernels contain explicit geometric bounds checks (e.g., if (global\_id.x \>= uniform.tensor\_size) { return; }). Timing and fingerprinting attacks are mitigated by the application relying on coarse performance.now() metrics rather than insisting on timestamp-query extensions, minimizing the surveillance surface11. Furthermore, to support robust WASM thread fallbacks, the hosting environment must enforce strict cross-origin isolation via Cross-Origin-Opener-Policy (COOP) and Cross-Origin-Embedder-Policy (COEP) headers, which simultaneously hardens the application against cross-site data leaks6.

12. Numerical and Behavioral Conformance Matrix

Numerical divergence between the CPU reference implementation and the GPU backend is the primary cause of hallucination, repetitive loops, or behavioral drift in local large language models. An explicit, staged conformance matrix validates the GPU backend against the WASM CPU oracle.

Complete bit-exact reproducibility across different GPU vendors is scientifically impossible due to non-standardized hardware handling of fused multiply-add operations, variations in denormal flushing (subnormal numbers flushed to zero), and differing precision limits in WGSL trigonometric built-ins11. Therefore, conformance relies on bounded Units in the Last Place (ULP) tolerances. The causal attention softmax must subtract the maximum value of the row to ensure numerical stability; this subtraction and the subsequent exponentiation must be accumulated in f32 to prevent catastrophic overflow. NaN propagation must be aggressively guarded against, particularly in attention scaling where division by zero is prevented by clamping sequence lengths dynamically.

13. Benchmark, Hardware, Browser, and Fault-Injection Protocol

Performance claims require a rigorous, reproducible benchmarking protocol that accurately isolates latency components across a diverse hardware matrix. The benchmark protocol strictly measures Time to First Token (TTFT) and steady-state Decode Rate (Tokens/sec). TTFT encompasses adapter acquisition, pipeline compilation, VRAM allocation, weight upload (queue.writeBuffer), and the compute-heavy prefill phase. Telemetry must explicitly report all CPU, GPU, and staging buffer bytes transferred. To ensure resilience, a fault-injection protocol is mandated. The test suite artificially injects an OOM state by forcing a massive 2GB allocation to trigger a pushErrorScope rejection15. It simulates stale commands by attempting to submit a command buffer immediately after calling device.destroy(), ensuring the application handles the resulting GPUValidationError gracefully without crashing the UI. Finally, worker death is simulated by terminating the Web Worker hosting the WebGPU device, validating that the state machine successfully transitions to the CPU fallback without duplicating user prompts.

14. TDD Backlog, Promotion Gates, and Stop Rules

The WebGPU backend development proceeds strictly via Test-Driven Development (TDD), utilizing a shadow-oracle pattern where the WASM CPU path generates the ground truth. The staged implementation plan begins with single-operator tests. WGSL kernels for RMSNorm, RoPE, and Softmax are written and validated against CPU outputs using highly constrained golden vectors. The second phase integrates complete layers, implementing GEMV and GEMM for q4 tensors, passing a single Transformer block through the pipeline. The third phase scales to an end-to-end tiny fixture (e.g., a 15M parameter model) before finally admitting a full-scale real model across multiple hardware vendors. Crucially, the architecture dictates strict stop rules and clean deletion criteria. If, after successfully implementing subgroups and shader-f16, the WebGPU decode token generation rate fails to exceed the highly optimized WASM SIMD implementation by a minimum of 20% on median target hardware (e.g., integrated Intel or AMD GPUs), the WebGPU backend will be cleanly deprecated and deleted. Maintaining a complex, asynchronous WebGPU stack is economically and technically unjustifiable if the CPU path is mathematically superior and sufficiently performant for the end-user experience.

15. Unknowns Requiring Private Model, Browser, or Physical GPU Execution

Certain behavioral aspects of the architecture cannot be entirely resolved via specification analysis and require empirical execution against the private TinyRustLM artifacts on physical hardware. First, subgroup uniformity constraints remain highly hardware-dependent. It is unknown whether older Android Vulkan drivers properly support subgroup uniformity in complex WGSL control flows without triggering severe validation errors or silent deadlocks18. Second, the exact hardware emulation mechanics for unpack4x8snorm on specific low-end integrated GPUs is unknown; relying on this built-in may introduce unexpected register pressure latency that offsets the bandwidth savings of q8 quantization20. Finally, browser cache eviction policies are undocumented. The precise memory threshold at which Safari/WebKit silently evicts compiled WebGPU pipelines from the cache, causing severe frame-drops during extended long-context decode sessions, requires direct empirical profiling on physical Apple Silicon devices.

16. Annotated Primary-Source Bibliography

The architectural constraints and engineering protocols defined in this report are strictly derived from foundational specifications and observed vendor deployments. The W3C WebGPU Working Draft Specification forms the basis of the memory and security architecture, specifically detailing the aggressive fingerprinting mitigations, the binned limitation system utilizing 32 distinct hardware configurations, and the robust out-of-bounds buffer behavior that guarantees memory safety even under malicious tensor loads1. The W3C WGSL Specification governs the strict alignment rules, memory typing, and data structures utilized in the kernel design. It explicitly details the behaviors of built-ins such as unpack4x8snorm, which is instrumental for high-speed q8 dequantization2. Complementing the base language, the Chromium and W3C WGSL Subgroups Proposal documentation details the evolving implementation of subgroup\_size, subgroup\_invocation\_id, subgroupAdd, and subgroupBroadcast. These primitives are the theoretical foundation for the optimized GEMV reductions necessary for high-speed token decoding9. Memory planning parameters are governed by browser-specific limit defaults documented extensively in MDN Web Docs, particularly the GPUSupportedLimits interface, which establishes the baseline 128MB maxStorageBufferBindingSize and 256MB maxBufferSize constraints13. The alignment padding algorithms are derived directly from the WebGPU Binding Alignment Specification, which mandates the strict 256-byte alignment requirement for minStorageBufferOffsetAlignment1. The state machine for fault tolerance relies on the W3C WebGPU Error Handling and Device Loss documentation, which establishes the asynchronous validation mechanisms using pushErrorScope and popErrorScope, as well as the lifecycle of the GPUDeviceLostInfo objects11. Contextual strategies for large language model adaptation to WebGPU—specifically regarding static memory planning, VRAM allocation avoidance, and templated WGSL generation—were heavily informed by recent academic evaluations, notably "Llamas on the Web" (Levine et al., 2026\)19. Finally, the overarching security constraints for fallback threading environments rely on modern web security standards requiring Cross-Origin-Opener-Policy (COOP) and Cross-Origin-Embedder-Policy (COEP) headers to securely unlock SharedArrayBuffer memory boundaries6.

Works cited

1. WebGPU \- W3C, https://www.w3.org/TR/webgpu/

2. WebGPU Shading Language \- W3C, https://www.w3.org/TR/WGSL/

3. The Era of LLMs Running in the Browser—How WebGPU Changed Local AI Inference \- note, https://note.com/snake\_dragon/n/ncbb123143bf8?hl=en

4. WebGPU Hits Critical Mass: All Major Browsers Now Ship It, https://www.webgpu.com/news/webgpu-hits-critical-mass-all-major-browsers/

5. Eight translations of one dispatch — A WebGPU stack source-level walkthrough \- Airing, https://ursb.me/immersive/webgpu/

6. SharedArrayBuffer: Browser Support, Isolation, Use Cases \- TestMu AI, https://www.testmuai.com/learning-hub/sharedarraybuffer-browser-support/

7. WebGPU f16 support \- Chrome Platform Status, https://chromestatus.com/feature/5180552617656320

8. Proposal of FP16 WGSL extension · Issue \#2512 \- GitHub, https://github.com/gpuweb/gpuweb/issues/2512

9. What's New in WebGPU (Chrome 128\) | Blog, https://developer.chrome.com/blog/new-in-webgpu-128

10. gpuweb/proposals/subgroups.md at main \- GitHub, https://github.com/gpuweb/gpuweb/blob/main/proposals/subgroups.md

11. WebGPU \- W3C, https://www.w3.org/TR/2021/WD-webgpu-20210706/

12. Multi-Account-Containers \- Microsoft Azure, Entra Portal Login Error \- unknown\_msal\_error · Issue \#2887 \- GitHub, https://github.com/mozilla/multi-account-containers/issues/2887

13. GPUSupportedLimits \- Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/GPUSupportedLimits

14. WebGPU \- W3C, https://www.w3.org/TR/2023/WD-webgpu-20230228/

15. gpuweb/design/ErrorHandling.md at main \- GitHub, https://github.com/gpuweb/gpuweb/blob/main/design/ErrorHandling.md

16. Potential memory leak in \WebGPUCacheBindGroups\? \- Questions \- Babylon.js Forum, https://forum.babylonjs.com/t/potential-memory-leak-in-webgpucachebindgroups/62697

17. Could you help me understand memory barriers? \#4401 \- GitHub, https://github.com/gpuweb/gpuweb/discussions/4401

18. Add subgroup barrier to subgroups proposal · Issue \#4437 \- GitHub, https://github.com/gpuweb/gpuweb/issues/4437

19. Llamas on the Web: Memory-Efficient, Performance-Portable, and Multi-Precision LLM Inference with WebGPU \- arXiv, https://arxiv.org/html/2605.20706v1

20. WebGPU Shading Language \- W3C, https://www.w3.org/TR/2022/WD-WGSL-20220719/

21. WebGPU Shading Language \- W3C, https://www.w3.org/TR/2021/WD-WGSL-20211029/

22. constrain attribute alignment value to divide device alignment limits · Issue \#2505 \- GitHub, https://github.com/gpuweb/gpuweb/issues/2505

23. Edge LLM Browser Agents with WebGPU/WASM: On ... \- surfs.dev, https://surfs.dev/resources/edge-llm-browser-agents-webgpu-wasm-planning-streaming-tools-privacy

24. WebGPU \- W3C, https://www.w3.org/TR/2021/WD-webgpu-20211029/

25. WebGPU API \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/API/WebGPU\_API

26. WebGPU \- W3C, https://www.w3.org/TR/2022/WD-webgpu-20220831/

27. Using WebAssembly threads from C, C++ and Rust | Hacker News, https://news.ycombinator.com/item?id=27905555

28. add subgroups, and make them portable if possible · Issue \#4306 \- GitHub, https://github.com/gpuweb/gpuweb/issues/4306