Architectural Blueprint for Browser-Native LLM Inference: Optimizing TinyRustLM

Full report

On this page

The WebAssembly Memory Architecture and Browser Constraints

The deployment of large language models and small language models within the web browser represents a fundamental shift in edge computing, circumventing cloud inference latency, recurring API costs, and data privacy vulnerabilities1. By utilizing WebAssembly and WebGPU, browsers have evolved into sandboxed execution environments capable of localized machine intelligence. However, bringing model inference natively into the browser introduces severe constraints regarding memory allocation, execution thread isolation, dynamic payload sizes, and hardware variability3. WebAssembly does not operate as a faster version of JavaScript; rather, it is a portable, stack-based virtual machine architecture with a distinctly isolated memory model6. WebAssembly memory is a single, contiguous array of raw bytes accessed via low-level pointers. Because the WebAssembly virtual instruction set architecture cannot hold JavaScript objects directly, any interaction between the host environment and the guest module requires crossing a typed boundary, an operation that traditionally incurs heavy serialization and marshaling costs6. To achieve acceptable latency in a language model runtime, the system must adhere to zero-copy data transfer principles. When a language model requires prompt text or image pixel data, copying bytes from the JavaScript heap into the WebAssembly linear memory creates unacceptable overhead. High-performance implementations utilize bindings, such as those generated by the wasm-bindgen tool in Rust, to hand JavaScript a pointer into the WebAssembly heap, allowing the host to write directly to the buffer using Uint8Array views6. This shared-view approach drops the round-trip cost to the equivalent of a single function call, bypassing the traditional allocation and memory copy penalties inherent in naive wrappers6. This architecture demands rigorous lifecycle management because JavaScript garbage collection does not reach across the boundary into WebAssembly linear memory6. If the host allocates buffer space to pass a string but fails to call the corresponding free function, the memory is permanently leaked until the browser tab is terminated. Executing inference entirely in Rust avoids the unpredictable latency spikes caused by JavaScript garbage collection pauses, allowing the deterministic ownership model of Rust to free memory immediately when variables fall out of scope, thereby eliminating tail latency spikes under load9. Current stable WebAssembly implementations primarily rely on a 32-bit addressing space, imposing a hard theoretical ceiling of 4GB on linear memory, which is allocated in chunks of 64KiB pages11. While the Memory64 proposal introduces 64-bit pointers to access vast amounts of theoretical memory, browser engines currently throttle this to a maximum of 16GB13. The lack of 32-bit pointer optimizations in 64-bit mode can result in noticeable performance degradation, meaning that modern browser inference runtimes must fit entirely within a strict 32-bit memory envelope to maintain cross-platform efficiency13. Beyond the theoretical specification, actual browser memory budgets are dictated by the operating system and the user agent, which heavily penalize large allocations.

Because mobile operating systems severely restrict per-tab memory usage, attempting to load models larger than 1B to 3B parameters routinely triggers maximum binding size exceptions or silent out-of-memory crashes16. A resilient runtime must dynamically feature-detect the available memory and strictly budget its allocations. Reserving memory upfront, statically allocating all necessary tensors and scratchpads at startup, and actively refusing to load models that exceed the host's capacity are mandatory architectural safeguards1. Standard dynamic memory allocators are poorly suited for this environment. While lightweight allocators were historically used to reduce WebAssembly binary sizes, they frequently leak memory in long-running processes, and standard allocators introduce heap fragmentation, which is a fatal flaw when operating near the browser's memory ceiling19. Language model memory access is highly predictable, characterized by massive, transient allocations for key-value states and forward scratchpads that match the lifetime of a single generation request. Consequently, the optimal pattern involves bypassing general-purpose allocators in favor of Arena or Bump allocators paired with pre-allocated buffer pools in specific size classes19. An [Figure omitted from source export] bump allocator reserves a massive contiguous block of linear memory at initialization; during the forward pass, temporary allocations increment a pointer through the arena, and upon completion of the generation step, the pointer simply resets to zero23. This guarantees zero fragmentation, eliminates allocation overhead during token generation, and ensures the runtime never requests additional memory pages from the browser mid-inference.

Inference Optimization: Quantization Tradeoffs and Kernel Execution

The most significant barrier to deploying language models in the browser is the initial network payload. A standard 7B parameter model requires approximately 14GB of video RAM in 16-bit float precision, which vastly exceeds the capabilities of any web browser16. Through aggressive quantization, the memory footprint can be compressed drastically, shrinking a 7B model to 4-5GB or a 3B model to under 2GB1. For web applications, first-load size drives user adoption, making heavy quantization a strict necessity rather than an optional optimization25.

Basic quantization formats organize weights into blocks, typically utilizing 32 weights per block, and store a single 16-bit float scaling factor for the entire block to achieve a symmetric compression without individual offsets18. Advanced formats utilize super-blocks of 256 weights, applying double quantization techniques and vector codebooks to squeeze the bit-rate closer to three bits per weight without sacrificing massive coherence18. While quantization solves the memory capacity problem, it introduces a compute bottleneck because the model must be dequantized during inference to perform matrix multiplications. If a runtime utilizes standard scalar CPU execution, the generation speed will be unacceptably slow, severely impacting the end-user experience27. Achieving acceptable latency relies entirely on WebAssembly Single Instruction, Multiple Data (SIMD) capabilities13. By compiling the Rust target with specific flags to enable 128-bit SIMD intrinsics, the runtime can process 128-bit vectors in a single clock cycle8. For 8-bit quantization, a single 128-bit WebAssembly SIMD register can hold 16 integer elements simultaneously27. The dot product of a quantized tensor against an activation can be executed efficiently using parallel multiply-accumulate operations, yielding a massive speedup over scalar execution8. For 4-bit quantization, the optimization is more complex because the values must be unpacked into eight-bit or sixteen-bit registers before mathematical operations can occur. Advanced implementations utilize fused dequantization and matrix multiplication shaders or highly optimized SIMD lookup routines to prevent the unpacking phase from destroying the cache locality benefits of the smaller payload26. Recent advancements in inference architecture have introduced asymmetric compression policies that recognize the differing mathematical sensitivities of the Keys and Values inside the attention mechanism31. The Value vectors tolerate extreme quantization remarkably well, whereas Key vectors degrade quickly due to their role in the highly sensitive softmax attention scaling. An advanced runtime implements a split policy, leaving Keys at higher precision to preserve attention accuracy while aggressively quantizing Values down to 2-4 bits using Walsh-Hadamard-rotated polar codebooks or sparse dequantization techniques32. Sparse Value dequantization skips the dequantization of tokens entirely if their corresponding attention softmax weight falls below a minimal threshold, saving substantial CPU cycles across large contexts32. This asymmetric approach compresses the total cache by multiple factors, directly addressing the strict memory ceilings of the browser environment.

Continuous Context Management and the KV Cache

In transformer architectures, the self-attention mechanism relates every token to every previous token in the sequence. To avoid reprocessing the entire conversation history during each token generation, the runtime stores the Key and Value matrices in a continuous cache33. As context lengths increase, this cache grows linearly and can rapidly dwarf the memory footprint of the model weights themselves24. The memory required for a standard cache is calculated based on the number of layers, heads, head dimension, precision bytes, sequence length, and batch size24. For a model resembling a small 16-million parameter specification utilizing a 32-bit float precision, the cache easily consumes several megabytes for a short context and balloons exponentially for large context windows35. If the context grows unchecked in a browser tab, the iOS Safari limit will be breached instantly by the cache alone. Without intelligent management, multi-turn chat applications in the browser force the model to rebuild its attention state from scratch for every new user message33. Prefilling a large token context takes orders of magnitude longer than generating a single token, introducing severe latency spikes at the start of every turn. To mitigate this, the architecture must support continuous decoding application programming interfaces. The cache must persist in WebAssembly memory between inference calls. When a user sends a new message, the runtime must use an append mechanism, computing the attention only for the new tokens while reading the cached state for the historical conversation33. Furthermore, to guarantee that the system never triggers an out-of-memory crash, the cache must operate as a ring buffer implementing sliding-window attention24. A sliding window evicts the oldest tokens from the cache as new ones are generated. To prevent the degradation of context grounding, hybrid architectures maintain high precision for a global sink of initial tokens representing the system prompt, while applying the sliding window eviction solely to the middle of the conversation36. Global cache sharing across multiple requests introduces severe privacy vulnerabilities, allowing adversaries to infer sensitive user inputs through timing side channels34. Integrating lightweight detection and isolation directly into the serving runtime eliminates cross-tenant reuse of sensitive blocks while recovering the performance benefits of global sharing, which is vital for safe multi-tenant browser deployments34.

Tokenization and Sampling Pipeline Dynamics

The tokenization phase converts raw text strings into numerical integer identifiers representing the model's vocabulary. In a browser environment, architects face a choice between executing tokenization in JavaScript or executing it within the Rust WebAssembly boundary. While JavaScript implementations are easier to integrate, they are notoriously slow for large documents and suffer from runtime engine garbage collection stutter, which delays the crucial time-to-first-token metric38. Rust-based tokenizers compile efficiently to WebAssembly, utilizing optimized Byte-Pair Encoding or Unigram algorithms backed by binary search trees for logarithmic lookups26. A native WebAssembly tokenizer can process vast amounts of text in milliseconds39. Crucially, performing tokenization inside WebAssembly prevents the need to serialize massive arrays of integer identifiers across the host-guest boundary, keeping the hot execution path entirely contained within linear memory. Once the forward pass generates a set of output logits, the sampling algorithm determines the actual token selected. The standard approach utilizes temperature scaling combined with Top-K or Top-P sampling, but these traditional methods struggle to balance coherence and creativity dynamically across varied contexts40. Top-K sampling applies a hard cutoff retaining only the highest probability tokens, discarding all others regardless of the distribution shape. This introduces static rigidity; when the model is highly uncertain, the threshold is too small, and when the model is highly certain, the threshold is too large, forcing the inclusion of unpredictable noise tokens40. Top-P sampling accumulates probabilities until a threshold is reached, but it suffers from a flat-distribution flaw. If the model is confused, the distribution flattens, and reaching a high probability mass forces the inclusion of thousands of low-quality tokens41. Min-P sampling has emerged as the computationally optimal algorithm for local language models41. The Min-P algorithm evaluates the absolute most likely token and sets a threshold relative to that peak. If the model is highly confident, the top probability is high, forcing the threshold up and strictly limiting the output to the best tokens. If the model is guessing, the top probability is low, causing the threshold to drop dynamically and allowing a wider variety of creative tokens to be considered41. Implementing Min-P in a Rust environment requires merely isolating the maximum logit, scaling it, and masking out all values below it before applying the Gumbel-max trick for selection46. By utilizing a Min-P value of 0.05 to 0.1, the runtime ensures high coherence even at elevated temperature settings, producing significantly better logic than Top-P without adding latency overhead41. Alternative experimental approaches like Top-H attempt to utilize entropy-constrained mass maximization, but Min-P remains the most efficient, battle-tested solution for constrained hardware45.

Concurrency, Streaming, and Event Loop Preservation

A severe architectural deficiency in early browser artificial intelligence implementations is the execution of synchronous inference on the main thread28. The JavaScript event loop dictates that if the main thread is occupied by a heavy central processing unit workload, all user interface rendering, scrolling, document object model updates, and network requests are completely frozen48. If a language model blocks the event loop for even half a second, the application becomes unresponsive, leading the browser to display a warning and ultimately terminating the process48. To achieve non-blocking inference, the runtime must instantiate a dedicated Web Worker to handle the execution graph5. However, simply moving computation to a worker introduces a new latency bottleneck regarding how to stream generated tokens back to the user interface efficiently. Standard message passing requires serialization and copying, creating significant overhead when performed sequentially for hundreds of tokens. The definitive solution is the SharedArrayBuffer primitive, which enables multiple Web Workers and the main thread to access a single, shared chunk of WebAssembly linear memory simultaneously51. Utilizing atomic operations to synchronize state without serialization permits the inference engine to write a generated token directly into shared memory, which the main user interface thread reads instantly, achieving a zero-copy streaming architecture52. Due to historical timing side-channel vulnerabilities, browsers disable shared memory primitives by default. To unlock these capabilities, the hosting web server must enforce strict cross-origin isolation using specific HTTP response headers, ensuring that the document is isolated from cross-origin openers and requires a secure embedder policy53. When these headers are present, WebAssembly threads can execute parallel processing and instantaneous token streaming52. If an application is embedded in a third-party frame or served from a content delivery network that cannot configure strict headers, the shared memory allocation will throw a reference error52. The architecture must feature-detect this failure and fall back gracefully to a standard Web Worker utilizing asynchronous message passing56. In this fallback mode, the runtime must implement an asynchronous generator function that yields control back to the event loop after every token calculation48. Furthermore, to avoid copying massive inputs, initialization buffers containing the model weights must be passed to the worker by transferring memory ownership exclusively, achieving zero-copy initialization even without shared arrays8. Complex implementations may also utilize a dispatcher pattern or a service worker coordinator to pool threads and manage the asynchronous instantiation overhead, preventing deadlocks when the browser limits the maximum number of concurrent workers55.

Security, Privacy, and Execution Diagnostics

A primary advantage of browser-native language models is absolute data privacy; user prompts and proprietary information never traverse an external network, providing compliance guarantees that server-side application programming interfaces cannot match1. To legally and cryptographically guarantee this local-only execution, the architecture must integrate a strict Content Security Policy61. By defining the policy to exclusively allow self-hosted scripts and connections, the application explicitly commands the browser engine to block all outbound requests, telemetry, and resource sharing exploits62. This renders data exfiltration theoretically impossible, as the browser will aggressively throw network violation errors if the client-side code attempts to transmit the user's prompt to a remote server62. Enforcing strict script sources without unsafe evaluation directives prevents prompt-injection attacks from manifesting as cross-site scripting execution, locking down the execution sandbox entirely61. Monitoring a WebAssembly module operating near the absolute limit of the browser's memory sandbox is exceptionally difficult. Traditional JavaScript memory properties provide highly inaccurate estimations of linear heaps because they cannot account for separate worker threads or the internal allocation mechanics of the virtual machine65. To diagnose slow or failing generations, the architecture should leverage user-agent specific memory measurement application programming interfaces53. Available strictly in cross-origin isolated contexts, these interfaces provide highly accurate, granular byte breakdowns of the memory footprint consumed by the instance and its associated workers66. By running this metric through a randomized exponential distribution timer, engineers can track actual cache bloat and detect linear memory leaks before they trigger an out-of-memory crash66. When a generation fails, the system must follow strict state boundaries for diagnosis to prevent the user interface from locking into a broken state35. Instead of throwing a generic exception, the runtime must emit an immutable identity block capturing the model hash, the runtime build hash, and the exact browser user agent35. It must provide a numeric error code categorizing the failure precisely, differentiating between an initial allocation failure, a tensor parsing error, a context overflow limit, or an invalid text decoding sequence35. This allows the host application to recover narrowly, resetting the context when required, and restricting complete reloads only to instances where the model identity or persistent state is suspected of corruption35.

Strategic Implementation Directives for TinyRustLM

Based on the forensic audit of the current TinyRustLM prototype, the system is presently a single-model, scalar-bound runtime executing a custom format directly on the main thread, utilizing a massive contiguous allocation strategy that scales poorly across varying hardware28. To achieve production viability as a modular edge intelligence framework, the architecture must transition across several fundamental barriers, abandoning experimental assumptions in favor of standardized, highly optimized paradigms.

The proprietary model container format currently utilized by the system validates a rigid header containing magic bytes, specific normalization epsilons, and rotary frequency bases alongside a fixed 64-byte tensor directory28. While this ensures determinism for smoke tests, it completely isolates the runtime from the broader ecosystem. The implementation must add a separate, versioned parser and architecture adapter for the standard GGUF format, which will enable the loading of robust, multi-architecture components26. To prevent crashes on memory-constrained devices, TinyRustLM must enforce a strict arithmetic resource budget before authorizing model load, preventing the system from attempting to instantiate components that will inevitably cause a browser crash35. Using the core runtime allocation formulas, a theoretical footprint for a mobile-friendly 1B to 3B parameter model must be enforced35. The resident active weights loaded into linear memory must not exceed 1.5 gigabytes. The context state allowance must be hard-capped dynamically, restricting the buffer based on the specific device profile to ensure it remains highly compact35. The forward scratchpad must also remain as a fixed transient allocation35. By adhering to a total combined envelope that respects the host's maximum practical memory budget, the system remains resilient across standard modern browsers while leaving adequate headroom for the host operating system17. Before TinyRustLM can claim stable status as a browser-native inference engine and advance past its current deterministic smoke-test phase, several rigorous falsification tests must be executed and published as evidence28. Boundary isolation tests must verify that heavy generation tasks running in the Web Worker do not drop the main user interface thread below acceptable frame rates under heavy computational load. Out-of-memory recovery simulations must force an allocation failure by artificially requesting an impossible context window on restricted mobile browsers, verifying that the runtime emits a clean contextual error code rather than causing a silent tab crash. Min-P sampling verification must perform automated qualitative coherence checks, comparing outputs at high temperature settings using traditional sampling versus the implemented Min-P algorithm, proving that the new logic dynamically prevents structural output collapse41. Finally, zero-copy streaming verification must profile the host-guest boundary to prove that the tokenization output passes pointers directly into linear memory rather than initiating deep, expensive object copies that trigger garbage collection pauses6. By migrating to standardized parsing, enforcing asynchronous workers, applying aggressive sampling, and strictly bounding the context cache through a sliding window architecture, the system can successfully bridge the gap to a robust, privacy-first edge intelligence engine.

Works cited

1. Run an LLM in Your Browser (2026): Browser-Based AI, No Server | Local AI Master, https://localaimaster.com/blog/run-llm-in-browser
2. WebLLM: A High-Performance In-Browser LLM Inference Engine \- arXiv, https://arxiv.org/html/2412.15803v2
3. I Ran a 2-Billion Parameter AI Model in a Browser Tab. No Server. \- DEV Community, https://dev.to/gautamvhavle/i-ran-a-2-billion-parameter-ai-model-in-a-browser-tab-no-server-f61
4. WebLLM: A High-Performance In-Browser LLM Inference Engine \- arXiv, https://arxiv.org/html/2412.15803v1
5. Wasm Workers API \- Emscripten 6.0.3-git (dev) documentation, https://emscripten.org/docs/api\_reference/wasm\_workers.html?highlight=web%20workers
6. What the WASM — A Polyglot Deep Dive | by FelixTheC | Jun, 2026 | Medium, https://medium.com/@fberndt87/what-the-wasm-a-polyglot-deep-dive-61c15c869229
7. Rust \+ Candle \+ Wasm: Building a serverless vector database in the browser \- Reddit, https://www.reddit.com/r/WebAssembly/comments/1qhixw8/rust\_candle\_wasm\_building\_a\_serverless\_vector/
8. 9 WebAssembly \+ Rust Tricks for Native-Speed Web Apps | by Bhagya Rana | Medium, https://medium.com/@bhagyarana80/9-webassembly-rust-tricks-for-native-speed-web-apps-95aff2f8959b
9. \[Project\] Running quantized BERT in the browser via WebAssembly (Rust \+ Candle) for local Semantic Search : r/LocalLLaMA \- Reddit, https://www.reddit.com/r/LocalLLaMA/comments/1q9j0r8/project\_running\_quantized\_bert\_in\_the\_browser\_via/
10. Building AI Agent Frameworks in Rust: Performance, Safety, and the Production Runtime Layer | Zylos Research, https://zylos.ai/research/2026-03-31-rust-ai-agent-frameworks-infrastructure/
11. WebAssembly.Memory() constructor \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/JavaScript\_interface/Memory/Memory
12. Up to 4GB of memory in WebAssembly \- V8 JavaScript engine, https://v8.dev/blog/4gb-wasm-memory
13. The State of WebAssembly – 2024 and 2025 \- Uno Platform, https://platform.uno/blog/state-of-webassembly-2024-2025/
14. The State of WebAssembly – 2025 and 2026 \- Uno Platform, https://platform.uno/blog/the-state-of-webassembly-2025-2026/
15. 2GB/4GB Memory Limit for WebAssembly Apps, Any Hope for Improvement in Future? \- Unity Discussions, https://discussions.unity.com/t/2gb-4gb-memory-limit-for-webassembly-apps-any-hope-for-improvement-in-future/1611613
16. The Era of LLMs Running in the Browser—How WebGPU Changed Local AI Inference \- note, https://note.com/snake\_dragon/n/ncbb123143bf8?hl=en
17. Safari ram limitation : r/iosdev \- Reddit, https://www.reddit.com/r/iosdev/comments/1ugywet/safari\_ram\_limitation/
18. Llamas on the Web: Memory-Efficient, Performance-Portable, and Multi-Precision LLM Inference with WebGPU \- arXiv, https://arxiv.org/html/2605.20706v1
19. Memory management \- Lib.rs, https://lib.rs/memory-management
20. wee\_alloc vs dlmalloc (wasm target) : r/rust \- Reddit, https://www.reddit.com/r/rust/comments/pyvsz3/wee\_alloc\_vs\_dlmalloc\_wasm\_target/
21. snmalloc: a message passing allocator | Request PDF \- ResearchGate, https://www.researchgate.net/publication/344740864\_snmalloc\_a\_message\_passing\_allocator
22. Hoard: A scalable memory allocator for multithreaded applications \- ResearchGate, https://www.researchgate.net/publication/299178139\_Hoard\_A\_scalable\_memory\_allocator\_for\_multithreaded\_applications
23. ruvllm\_wasm \- Rust \- Docs.rs, https://docs.rs/ruvllm-wasm
24. Scaling Multi-Turn LLM Inference with KV Cache Storage Offload and Dell RDMA-Accelerated Architecture, https://infohub.delltechnologies.com/ja-jp/p/scaling-multi-turn-llm-inference-with-kv-cache-storage-offload-and-dell-rdma-accelerated-architecture/
25. Transformers.js vs ONNX Runtime Web: Browser ML 2026 \- PkgPulse, https://www.pkgpulse.com/guides/transformersjs-vs-onnx-runtime-web-2026
26. ProbeLogits: Kernel-Level LLM Inference Primitives for AI-Native Operating Systems \- arXiv, https://arxiv.org/html/2604.11943v1
27. convert ARM NEON to WASM SIMD prompt \- GitHub Gist, https://gist.github.com/ngxson/307140d24d80748bd683b396ba13be07
28. Implementation \- MiRust, https://mirust.com/implementation/
29. llama-cpp-pydist \- PyPI, https://pypi.org/project/llama-cpp-pydist/
30. Voxtral-Mini-4B: Realtime Browser Speech (2026) | Serenities AI, https://serenitiesai.com/articles/voxtral-mini-4b-browser-speech-2026
31. ruvector/ruvllm-wasm v2.0.0 — Browser-native LLM inference is here · Issue \#242 \- GitHub, https://github.com/ruvnet/RuVector/issues/242
32. TheTom/llama-cpp-turboquant: LLM inference in C/C++ \- GitHub, https://github.com/TheTom/llama-cpp-turboquant
33. Accelerating Local LLM Conversations with KV Cache Reuse on AMD Ryzen AI, https://www.amd.com/en/developer/resources/technical-articles/2026/accelerating-local-llm-conversations-with-kv-cache-reuse-on-amd-.html
34. Selective KV-Cache Sharing to Mitigate Timing Side-Channels in LLM Inference \- arXiv, https://arxiv.org/html/2508.08438v2
35. Implementation operations \- MiRust, https://mirust.com/implementation-operations/
36. Welcome Gemma 4: Frontier multimodal intelligence on device \- Hugging Face, https://huggingface.co/blog/gemma4
37. SKVQ: Sliding-window Key and Value Cache Quantization for Large Language Models, https://openreview.net/forum?noteId=nI6JyFSnyV
38. Tokenization Offload Architecture (TOA) Reframing Client-Side Tokenization as a Foundational Layer in LLM Optimization \- OSF, https://osf.io/download/kyarq
39. huggingface/tokenizers: Fast State-of-the-Art Tokenizers optimized for Research and Production \- GitHub, https://github.com/huggingface/tokenizers
40. LLM Temperature, Top-P, and Top-K Explained — With Python Simulations, https://machinelearningplus.com/gen-ai/llm-temperature-top-p-top-k-explained/
41. LLM Sampling: Temperature, Top-K, Top-P, and Min-P Explained \- Let's Data Science, https://letsdatascience.com/blog/llm-sampling-temperature-top-k-top-p-and-min-p-explained
42. Turning Up the Heat: Min-p Sampling for Creative and Coherent LLM Outputs \- arXiv, https://arxiv.org/html/2407.01082v8
43. Learning Adaptive LLM Decoding \- arXiv, https://arxiv.org/html/2603.09065v1
44. Generation configurations: temperature, top-k, top-p, and test time compute \- Chip Huyen, https://huyenchip.com/2024/01/16/sampling.html
45. Top-H Decoding: Adapting the Creativity and Coherence with Bounded Entropy in Text Generation \- arXiv, https://arxiv.org/html/2509.02510v1
46. Embarrassingly Simple Self-Distillation Improves Code Generation \- arXiv, https://arxiv.org/html/2604.01193v1
47. How to Properly Scale Language Model Creativity : r/LocalLLaMA \- Reddit, https://www.reddit.com/r/LocalLLaMA/comments/187kpr6/how\_to\_properly\_scale\_language\_model\_creativity/
48. The Event Loop Era. Modern software does not like waiting… | by Beyond51 \- Medium, https://medium.com/@charleyjava/the-event-loop-era-13d203587bf8
49. How to Use Worker Threads in Node.js for CPU-Intensive Tasks \- OneUptime, https://oneuptime.com/blog/post/2026-01-06-nodejs-worker-threads-cpu-intensive/view
50. Detecting Event Loop Blocking in Production Node.js — Without Touching Your Code, https://dev.to/iwtxokhtd83/detecting-event-loop-blocking-in-production-nodejs-without-touching-your-code-32bo
51. Pthreads support \- Emscripten 6.0.1-git (dev) documentation, https://emscripten.org/docs/porting/pthreads.html
52. SharedArrayBuffer: The Hidden Super-Primitive That's Reshaping the Future of WebAssembly, .NET & Parallel Runtime Architecture | by Jacob Mellor | Medium, https://medium.com/@jacobscottmellor/sharedarraybuffer-the-hidden-super-primitive-thats-reshaping-the-future-of-webassembly-net-e369e667f6e9
53. Making your website "cross-origin isolated" using COOP and COEP | Articles \- web.dev, https://web.dev/articles/coop-coep
54. A Deep Dive into Cross-Origin Isolation \- The Publishing Project, https://publishing-project.rivendellweb.net/a-deep-dive-into-cross-origin-isolation/
55. JS on WASM API | TFHE-rs \- Zama Docs, https://docs.zama.org/tfhe-rs/integration/js-on-wasm-api
56. wasm-bindgen-rayon \- crates.io: Rust Package Registry, https://crates.io/crates/wasm-bindgen-rayon/1.1.3
57. WASM Thread support in WasmEdge · Issue \#1467 \- GitHub, https://github.com/WasmEdge/WasmEdge/issues/1467
58. Asyncio and concurrency best practices in Ray Serve, https://docs.ray.io/en/latest/serve/advanced-guides/asyncio-best-practices.html
59. byLLM \- Jac \- AI-Native Full-Stack Development, https://docs.jaseci.org/community/release\_notes/byllm/
60. wasm-bindgen-spawn | A Web Worker based multithreading library for Rust and Assembly, https://pistonite.github.io/wasm-bindgen-spawn/
61. Content Security Policy Compliance \- Graphwise Documentation, https://help.graphwise.ai/en/graph-modeling/graph-modeling-thesaurus-manager/linked-data-management/the-linked-data-frontend--restful-/content-security-policy-compliance.html
62. Angular Content Security Policy (CSP) Guide: What It Is and How to Enable It \- StackHawk, https://www.stackhawk.com/blog/angular-content-security-policy-guide-what-it-is-and-how-to-enable-it/
63. CSP – An Additional Layer of Security \- SecurityBoat, https://securityboat.net/csp-an-additional-layer-of-security/
64. Content Security Policy \- OWASP Cheat Sheet Series, https://cheatsheetseries.owasp.org/cheatsheets/Content\_Security\_Policy\_Cheat\_Sheet.html
65. Performance: memory property \- Web APIs \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/API/Performance/memory
66. Performance: measureUserAgentSpecificMemory() method \- Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/Performance/measureUserAgentSpecificMemory
67. GitHub \- cool-japan/oxillama: Pure Rust LLM Inference Engine — The Sovereign Alternative to llama.cpp License Rust Complete GGUF model loading, multi-format quantized inference, and an OpenAI-compatible API server — all without a single line of C, C++, or Fortran code., https://github.com/cool-japan/oxillama
68. Tiny Model Composer \- MiRust, https://mirust.com/composer/