Engineering Analysis of TinyRustLM Quantization and Execution Environments

Full report

On this page

Executive Summary and Strategic Recommendations

The following engineering and research analysis evaluates the prerelease architecture of TinyRustLM. The objective is to determine whether the current numerical execution model—specifically the single model.slm2 payload comprising a row-wise symmetric Q8 quantization profile—is a viable first-product compromise for a browser-local small-language-model assistant. The platform target encompasses WebAssembly (WASM) execution within standard web browsers and native execution via a Windows .NET companion, with strict mandates for local inference and automated initialization via MiniModel.org.

The recommended decision is that the current row-wise symmetric Q8 profile with binary32 (F32) scales must be rejected as the production release format. While it serves as an adequate structural baseline for debugging the WASM memory boundary and Rust scalar execution paths, it is fundamentally inappropriate for deployment. The format induces catastrophic outlier collapse in sub-1B parameter models, exceeds the safe memory working-set limits of mobile browser environments, and artificially bottlenecks inference by prohibiting parallel tree-reduction instructions. The architecture must transition to a block-wise, mixed-precision quantization scheme (equivalent to Q4\_K\_M) governed by an updated, immutable slm3 format prior to user release.

The strongest reason this recommendation could be wrong centers on the JavaScript-to-WASM serialization overhead and the current lack of SharedArrayBuffer support in environments without cross-origin isolation headers. If the target browser environments cannot utilize multi-threading or 128-bit SIMD instructions reliably, the computational overhead of unpacking block-wise 4-bit representations via single-threaded, strictly scalar WebAssembly could result in slower inference than a memory-heavy Q8 model. In such a severely constrained, compute-bound scenario, prioritizing raw decompression simplicity over memory footprint via Q8 could yield the only interactive token-generation rate achievable, despite the severe perplexity degradation.

Fact and Condition Categorization

Project-Supplied Facts: The implementation relies on Rust/WebAssembly with a Windows .NET companion. The current format configuration consists exclusively of six files: model.slm2, tokenizer.tokenizer2, template.template2, sampling.sampling2, prompt.prompt2, and composition.acg2. The model.slm2 weight profile stores admitted rank-2 embedding and projection matrices as row-wise symmetric Q8 with F32 scales, utilizing codes in the range [Figure omitted from source export] where [Figure omitted from source export] is explicitly forbidden. Norm weights and biases remain F32, and a zero row dictates a scale of 1.0. Execution mandates binary32 dequantization and strictly left-to-right scalar accumulation without a Fused Multiply-Add (FMA) contract. The test artifact is a Qwen3-0.6B equivalent model occupying approximately 598 MB. MiniModel.org is explicitly authorized to supply initial server seeds, superseding any historical project prose prohibiting external network requests for model acquisition. There is no requirement to preserve backward compatibility with retired SLM1 structures.

Externally Verified Facts: WebAssembly linear memory for the wasm32-unknown-unknown target is bounded by 32-bit pointers, capping theoretical memory at 4GB, though practical limits in browser tabs—particularly on mobile devices—are frequently restricted to 1GB to 2GB before the operating system evicts the process1. WebAssembly SIMD requires explicit 16-byte memory alignment to prevent hardware-level traps during execution3. Sub-1B language models, such as the Qwen2.5-0.5B architecture, suffer disproportionate and catastrophic perplexity degradation under uniform, row-wise quantization compared to larger multi-billion parameter models5. The Qwen architectural family utilizes Grouped-Query Attention (GQA) and tied word embeddings (tie\_word\_embeddings: true)8.

Hypotheses: The left-to-right scalar F32 accumulation over large hidden dimensions (e.g., 896\) induces significant representation drift through catastrophic cancellation compared to high-precision or tree-based accumulation. Furthermore, row-wise scaling in the current Q8 format allows highly localized, massive activation outliers in the transformer's residual stream to compress the dynamic range of entire channels, leading directly to attention softmax collapse and repetitive, nonsensical text generation.

Recommendations: Transition the canonical storage artifact to a new slm3 format utilizing block-wise 4-bit weights with FP16 or FP32 block scales. Implement zero-copy Uint8Array aliasing to prevent V8 heap duplication during file loading. Define a strict numerical contract allowing for execution divergence up to [Figure omitted from source export] relative error to explicitly permit SIMD tree-reduction and hardware FMA utilization.

Locally Unverified Conditions: The exact baseline generation throughput (measured in tokens per second) within the current TinyRustLM WASM runtime remains unknown due to restricted access to the engineering checkout. The behavior of the file loader—specifically whether it currently allocates memory on the JavaScript heap and passes it to WASM by value rather than by reference—is unverified. The tier-up latency of the V8 Turboshaft JIT compiler compiling the TinyRustLM WASM binary on initial load is similarly unmeasured11.

Project Context and Immutable Engineering Directives

The TinyRustLM project aims to deliver a frictionless, browser-local assistant. A critical friction point identified in user feedback is the complexity of setup. To resolve this, the application must automatically restore a usable installed model or obtain a small, working default directly through MiniModel.org upon the first launch. Advanced configuration parameters—such as Hugging Face imports, custom peers, and local-file conversions—must be sequestered behind advanced configuration menus.

The canonical source repository is strictly located at E:\\Source\\Rust\\TinyRustLM.com, and all model payloads must reside exclusively in D:\\LLMs\\TinyRustLM. External or legacy directories, such as X:\\LLMS, are to be ignored. The development lifecycle mandates the use of Git for source history and bounded canonical artifacts for experiment output. Scattered scripts and backup trees are prohibited. When a new format (e.g., slm3) is validated and active, the superseded slm2 payload must be retired entirely to prevent the accumulation of historical model copies and compatibility branching.

Analysis of Error Sources in the Exact SLM2 Profile

The current SLM2 numerical contract introduces multiple compounding sources of numerical degradation. Evaluating these specific error vectors is a strict prerequisite before exploring aggressive 4-bit (Q4) compression, as failing to isolate these variables will conflate baseline format mathematical errors with intentional compression degradation.

The row-wise quantization mechanism relies on computing a single binary32 maximum magnitude per row of the weight matrix. The scaling factor is calculated by dividing this maximum absolute value by 127\. Large Language Models, particularly those utilizing transformer architectures with residual connections, exhibit a phenomenon known as "massive activations." These are highly localized outlier values that emerge in deep layers, often exceeding typical activation scales by orders of magnitude7. When a single weight in a row is exceptionally large, the resulting row scale becomes massive. Consequently, the remaining ordinary weights in that row are divided by this massive scale and subsequently rounded to zero. This effectively deletes the non-outlier features of that dimension. In Qwen-family models, which utilize Grouped-Query Attention (GQA), this destructive interaction is magnified. The Qwen2.5-0.5B architecture employs 14 query heads but only 2 key/value heads9. An outlier in a single k\_proj channel is therefore broadcast to seven separate query heads. This forces the query-key dot product to produce extreme logit spikes, pushing the softmax function to collapse into a one-hot distribution and destroying the model's generative diversity14.

The contract's specification of half-away-from-zero rounding introduces a secondary, systemic error. While mathematically deterministic, rounding values like [Figure omitted from source export] to [Figure omitted from source export] and [Figure omitted from source export] to [Figure omitted from source export] introduces a systematic positive mean shift in the presence of uniform or symmetrically distributed noise16. Over successive layers in a deep neural network, this directional bias acts as a compounding DC offset to the activations, shifting the mean of the feature space and reducing cosine similarity with the full-precision network.

The Qwen2.5-0.5B architecture employs tied word embeddings, meaning the initial embed\_tokens matrix and the final lm\_head projection matrix map to the identical underlying tensor in memory8. The vocabulary size for this model is exceptionally large at 151,936 tokens. Consequently, the tied embedding matrix is dimensionally vast, containing approximately 136 million parameters ([Figure omitted from source export])17. Applying coarse row-wise Q8 quantization to this matrix severely degrades its fidelity. Quantization noise introduced at the embedding layer cascades through the entire forward pass, while noise in the output projection scrambles the final vocabulary logit distribution, leading to severe perplexity spikes. The exact impact of quantizing this specific tied tensor must be diagnosed independently of the transformer blocks.

Finally, the SLM2 contract specifies strict left-to-right F32 scalar accumulation without a Fused Multiply-Add (FMA) contract. Given a dot product of two vectors of size 896, a naive loop performs 896 sequential floating-point additions. As the scalar accumulator grows, its binary32 exponent increases, which effectively truncates the mantissa precision for subsequent, smaller additions. Because the order is strictly left-to-right, features at higher indices contribute less exact precision to the final sum than features at lower indices. This induces representation drift and violates mathematical exchangeability, creating a non-deterministic sensitivity to index ordering.

Comparative Quantization Strategies

To determine whether the row-wise Q8 format should be retained or replaced, it must be evaluated against alternative compression regimes suitable for highly constrained local browser execution.

Quantitative Options Table

Evaluation of Alternatives

Block-wise (or group-wise) quantization divides each row into sub-blocks—typically 64 or 128 elements—and assigns an independent scaling factor to each group19. This mathematical isolation guarantees that an extreme outlier at a specific index only compresses the dynamic range of the other elements within its immediate block, rather than devastating the entire 896-element row. This granular scaling provides significantly superior accuracy retention compared to row-wise Q8, even when the bit depth is reduced to 4 bits21. In a memory-bandwidth-bound environment like a browser, reading 4-bit weights drastically reduces memory bus pressure. The engineering cost is the complexity of unpacking 4-bit integers and managing FP16 scales. WebAssembly currently lacks a native 4-bit type, necessitating explicit shift and mask operations during execution, which consume CPU cycles.

Calibration-based methods, such as Activation-Aware Weight Quantization (AWQ) or GPTQ, require passing a calibration dataset through the full-precision model to compute activation distributions and Hessian matrices, subsequently scaling weights to protect salient features5. While offering the highest accuracy retention for small models, implementing an AWQ calibration pipeline within the TinyRustLM exporter adds severe architectural complexity. Because the project prohibits scattered scripts and demands bounded canonical artifacts under E:\\Source\\Rust, importing an external Python dependency for complex matrix optimization violates the simplicity mandate of the current engineering checkpoint.

Utilizing a 1.5B parameter model quantized at 4-bits yields a disk footprint of approximately 1 GB. While larger models are mathematically far more resilient to quantization degradation, a 1 GB payload severely stretches the upper limit of acceptable download times for a frictionless web application and heavily pressures the 4GB WASM linear memory limit. Conversely, utilizing a model smaller than 0.5B results in severe representational fragility, failing to hold basic conversational logic regardless of the precision used.

The comparative analysis heavily favors transitioning the canonical format to a block-wise 4-bit schema (or hybrid 4-bit/5-bit) with FP32 block scales. This must be defined strictly under a new slm3 format, with slm2 slated for retirement upon validation.

Architectural Memory Estimates and Browser Constraints

Accurate memory calculation is critical for WebAssembly deployment. A precise distinction must be made between the immutable disk footprint, the committed WASM linear memory, the peak memory during generation, and the steady-state working set. Furthermore, a browser environment requires strict isolation of the JavaScript heap from the WASM linear memory (ArrayBuffer). If data crosses this boundary improperly via standard postMessage calls or naive array copying, memory usage doubles due to serialization overhead24.

The Qwen2.5-0.5B mathematical baseline provides the foundational parameters for calculation: a vocabulary ([Figure omitted from source export]) of 151,936, a hidden dimension ([Figure omitted from source export]) of 896, 24 transformer layers ([Figure omitted from source export]), 14 query heads, 2 KV heads, and an intermediate MLP size of 4,8649.

Under the current slm2 row-wise Q8 format, the tied embedding matrix ([Figure omitted from source export]) consumes 136.13 MB of Q8 weights and 0.6 MB of F32 row scales. The attention matrices per layer ([Figure omitted from source export]) encompass 1.83 million parameters, equating to approximately 44 MB across all 24 layers. The MLP matrices (gate\_proj, up\_proj, down\_proj) contain 13.07 million parameters per layer, totaling roughly 313 MB. The pure mathematical disk footprint of the weights is approximately 493 MB. The project-supplied 598 MB figure for the test artifact suggests the inclusion of vocabulary padding, RoPE complex caches, or redundant, untied lm\_head structures within the binary layout.

Scenario 1: Desktop Browser Execution (WASM 32-bit, Single Tab)

For a standard desktop browser utilizing the wasm32-unknown-unknown target, the 598 MB payload is cached locally in IndexedDB. The V8 engine allocates WASM linear memory in 64KB pages26. To hold 598 MB of weights, the engine must commit approximately 9,568 pages. The KV cache scales linearly with sequence length. Assuming a maximum context length of 8,192 tokens, the KV shape per layer is [Figure omitted from source export] elements. Assuming the cache is stored in FP32 (as cache quantization is absent from the SLM2 specification), this requires 201 MB of committed memory27. Adding approximately 50 MB for WASM scratch and activation buffers, the peak memory reaches 849 MB strictly inside the WASM ArrayBuffer. Assuming the integration utilizes zero-copy Uint8Array views to alias the memory rather than cloning it to the JS heap, this scenario is safely within the 4GB WASM limit and will yield stable performance.

Scenario 2: Mobile Browser (2GB Device Limits)

Mobile operating system architectures, such as iOS WebKit and Android Chrome, aggressively monitor memory and will abruptly kill browser tabs that exceed approximately 1 GB to 1.2 GB of RAM to protect the host system2. With an 849 MB WASM buffer, combined with approximately 200 MB of standard browser UI overhead, DOM structures, and JavaScript engine baseline memory, the application leaves almost zero headroom. In a steady-state working environment, a simple garbage collection sweep or a background tab transition will likely trigger an Out-Of-Memory (OOM) crash. The current 598 MB Q8 model is mathematically not viable for mobile browser deployment. A block-wise 4-bit quantization, which halves the weight memory to approximately 300 MB, is an architectural requirement for a resilient mobile experience.

Scenario 3: Windows .NET Companion (Native Execution)

For the standalone Windows .NET companion, the executable maps the 598 MB artifact directly via operating system virtual memory (mmap). The OS memory manager only pages in the specific weights currently required by the CPU. Because transformer execution is strictly sequential layer-by-layer, the physical memory working set comprises only the active layer (approximately 15 MB) plus the full 201 MB KV cache. This environment is completely unconstrained, and the .NET companion will run the 598 MB Q8 model with trivial physical RAM usage.

Controlled Isolation Matrix: Separating Compression Loss from Runtime Defects

To prevent conflating model structural instability, prompt template mismatches, sampling logic errors, and numerical degradation, a rigorous ablation framework must be established under the E:\\Source\\Rust\\TinyRustLM.com\\tests directory. Structural conversion passing does not equal numerical correctness.

The underlying hypothesis is that the severe output degradation observed in the Qwen3-0.6B test artifact is a direct result of the SLM2 F32 scalar accumulation and row-wise scaling formats, rather than a defect in the base Hugging Face checkpoint, the prompt formatting, or the WASM engine's compilation target.

To test this, the following variables must be strictly controlled: The model checkpoint must be the base Qwen2.5-0.5B; tokenization must rely on identical, hardcoded token ID integer arrays to completely bypass the Rust string parsing logic; the prompt must consist of fixed synthetic diagnostic strings; and the temperature must be set to 0.0 (Argmax) to entirely disable the sampling.sampling2 routines.

The Four-Arm Ablation Procedure:

1. Arm A (Control \- Source Framework): Execute the base model in native PyTorch (FP16). Ingest the exact input token IDs, and extract the intermediate pre-softmax logits for the first predicted token, alongside the output sequence of 20 tokens.

2. Arm B (Reconstruction \- Theoretical Quantization): Author a Python script to natively ingest model.slm2. Dequantize the Q8 weights back to FP32 in PyTorch. Execute the exact input token IDs and extract the logits. This isolates the pure mathematical loss of the Q8 format from any Rust or C++ execution bugs.

3. Arm C (Native Execution \- Host OS): Execute TinyRustLM compiled to native Windows/Linux (x86\_64). Execute with model.slm2 and extract the logits. This isolates Rust inference logic errors from WASM or Browser sandbox errors.

4. Arm D (Browser Execution \- WASM): Execute TinyRustLM within the Chrome/V8 environment. Extract logits via JavaScript console.log. This validates the final compilation platform.

If the Logit Cosine Similarity between Arm A and Arm B drops below 0.995, it indicates that the Q8 format itself destroys the representational geometry of the model, confirming that outlier collapse is occurring. The required action is to abandon row-wise Q8 and move to a block-wise format. If the Logit L2 Distance between Arm B and Arm C exceeds [Figure omitted from source export], it indicates that the Rust native inference logic (e.g., matrix multiplication or RoPE application) is mathematically flawed. If Arm C and Arm D do not produce 100% bit-identical output, the WASM compilation target is violating IEEE-754 semantics, requiring an audit of the wasm32-unknown-unknown Rust compilation flags.

Calibration and Evaluation Data Selection

Relying exclusively on Wikitext-2 perplexity is a documented anti-pattern for evaluating quantized LLMs. Low-bit quantized models frequently score adequately on simple next-token prediction tasks but suffer catastrophic structural collapse in multi-turn reasoning, context tracking, and JSON structural output14. Calibration and evaluation datasets must reflect practical usage constraints and strictly avoid contaminating the final holdout set.

To assess KV cache stability, the evaluation must include factual extraction (the "Needle in a Haystack" paradigm). Sub-1B models undergo severe attention diffusion when the context exceeds 2048 tokens. The testing method should insert a generated UUID into a 4,000-token context of filler text and prompt the model to extract it. A single character hallucination constitutes a failure.

To evaluate state tracking, the evaluation must include conversational corrections. For example, feeding the model the sequence: "My name is John." followed by "I live in Paris." followed by "Actually, my name is Mark." and querying "What is my name?" The threshold for success is the exact output "Mark", proving the model's attention heads have not collapsed under quantization noise.

Small models are highly susceptible to losing syntactic grounding under quantization. The evaluation must include a prompt forcing a strictly formatted {"key": "value"} response. The threshold for success is that the output must parse successfully in standard JSON.parse() without syntax errors.

To avoid contamination, generalized web-scrape data (e.g., C4) must not be used for the test set, as the Qwen architectural family is heavily pre-trained on it. The engineering team must generate highly specific, deterministic synthetic prompts strictly bounded in the E:\\Source\\Rust\\TinyRustLM.com\\tests directory to serve as the immutable holdout.

Optimized Kernels vs Strict Scalar Semantics

The supplied slm2 profile relies on strictly ordered, scalar left-to-right F32 accumulation. This introduces a severe tension between numerical contract strictness and hardware execution efficiency, fundamentally bottlenecking the browser experience.

In a browser, WebAssembly executes on engines like V8. Standard scalar execution is exceptionally slow, likely generating only 2 to 4 tokens per second for a 0.5B parameter model. Utilizing 128-bit WASM SIMD allows the engine to pack four 32-bit floats per instruction, drastically increasing throughput30. However, WASM SIMD instructions require strict 16-byte memory alignment. Unaligned memory access causes immediate hardware-level traps, crashing the WASM instance3. Furthermore, SIMD accumulation relies on parallel reductions (tree-summation) rather than left-to-right summation. Because floating-point arithmetic is not associative—meaning [Figure omitted from source export]—SIMD execution will strictly violate the current slm2 left-to-right accumulation contract.

Modern hardware CPUs utilize Fused Multiply-Add (FMA) instructions to calculate [Figure omitted from source export] with a single rounding step, reducing precision loss. The "Relaxed SIMD" proposal in WebAssembly is designed to expose this capability to the browser32. However, the slm2 contract explicitly specifies no FMA.

A deliberate numerical contract change is warranted—and must be requalified—when the baseline execution speed renders the product unusable. A browser-based assistant generating 2 tokens per second is a failed product. Therefore, the slm2 format must be strictly deprecated.

The replacement slm3 format must explicitly require SIMD tree-reduction semantics for accumulation. It must permit execution divergence up to [Figure omitted from source export] relative error to safely accommodate differences between FMA and non-FMA hardware execution across different user devices. Finally, the exporter must pack weights to mathematically guarantee 16-byte boundary alignment in linear memory to prevent V8 alignment traps.

Specification of Pathological Tensors and Vectors

To guarantee stability in arbitrary browser environments, the inference engine must explicitly specify the handling of pathological numerical states. Because WASM executes in a host sandbox, a Rust panic translates to an uncatchable WebAssembly trap, permanently leaking the Web Worker's memory and requiring a full page reload by the user34. The execution engine must never panic.

 

Strategic Execution and Decision Artifacts

Decision Tree for Keeping Q8 vs. Replacing

START │ ├── 1\. Does the Q8 model generate coherent, non-repetitive responses on the │ Conversational Corrections benchmark? │ ├── NO: Reject Q8. Outliers cause softmax collapse. Move to block-wise Q4. │ └── YES: Proceed to 2\. │ ├── 2\. Is the browser memory peak under 1.2 GB during context filling? │ ├── NO: Reject Q8. Mobile Safari/Chrome will crash. Move to block-wise Q4. │ └── YES: Proceed to 3\. │ ├── 3\. Does WASM execution maintain \> 15 tokens/sec without FMA/SIMD? │ ├── NO: Reject strict scalar contract. Bump to SLM3 (SIMD/FMA permitted). │ └── YES: Retain Q8 SLM2 profile for production.

The suggested acceptance threshold requires the model to reach a minimum of 10 tokens per second on an average desktop browser to be considered an improvement over relying on a traditional server-API call. If the Q8 profile cannot achieve this speed without crashing the browser tab due to memory limits, it unequivocally fails product acceptance.

Implementation Sequence and Ship Criteria

1. Stop Doing: Cease all attempts to validate the quality of model.slm2 by checking if structural conversions pass or by using one-token synthetic probes. Immediately deprecate the strict left-to-right scalar F32 requirement, as it prevents critical SIMD optimization.

2. Phase 1 (Isolate & Measure): Implement the four-arm Isolation Matrix in E:\\Source\\Rust\\TinyRustLM.com\\tests. Execute the Arm B versus Arm C test to ensure the Rust mathematics identically match the Python baseline.

3. Phase 2 (Format Migration): Given that Q8 mathematically fails the mobile memory constraints, design the model.slm3 format. Specify block-wise Q4 (group size 64), 16-byte alignment padding, and FP32 block scales.

4. Phase 3 (Browser Integration): Compile the WASM target with the target-feature=+simd128 flag. Load model.slm3 via zero-copy Uint8Array aliasing to prevent V8 heap duplication.

5. Phase 4 (Deployment): Authorize MiniModel.org to host the final slm3 artifact as the initial server seed. Ensure HTTP headers Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp are enabled on the host server to allow future SharedArrayBuffer multi-threading capabilities.

Ship / No-Ship Criteria: The product is authorized to SHIP when native Rust versus WASM execution yields [Figure omitted from source export] bit-identical logits, the model parses the JSON extraction prompt flawlessly, the working set memory stays strictly under 800 MB, and token generation exceeds 15 tokens per second. The product results in a NO-SHIP decision if the application crashes silently on load due to WASM panics, if the output devolves into repetition loops due to row-wise outlier scaling, or if memory exceeds 1.2 GB.

Falsification and Experimentation

The smallest experiment capable of falsifying the recommendation to abandon the Q8 profile is to run the current 598 MB model in a mobile Chrome browser on a device with 2GB of physical RAM. If the Q8 model can successfully load, process a 2048-token context, and generate 10 tokens per second without the browser operating system forcefully evicting the tab for OOM violations, the memory-bound argument against Q8 is effectively falsified.

Compact Experiment-Lesson Template:

• Question: Does left-to-right F32 scalar accumulation introduce unacceptable numerical drift compared to SIMD tree-reduction on an 896-dimension vector?
• Exact Inputs: A single synthetic vector array [Figure omitted from source export] ([Figure omitted from source export]) populated with floating-point values alternating in magnitude by factors of [Figure omitted from source export].
• Method: Compute scalar\_sum(V) strictly left-to-right. Compute simd\_sum(V) utilizing 128-bit lane additions.
• Result: \[To be populated locally by engineers upon execution\]
• Uncertainty: Minimal; strictly bound by IEEE-754 arithmetic determinism.
• Decision: Abandon the scalar requirement if the drift exceeds [Figure omitted from source export].
• Reusable Lesson: LLM dimensions are too large for uncompensated sequential F32 additions; hierarchical reduction is both mathematically and computationally superior.
• Evidence Identity: E:\\Source\\Rust\\TinyRustLM.com\\tests\\numerical\_drift\_001.rs (Git commit hash required).

Works cited

1. State of WebAssembly 2026 | The Dev Newsletter, https://devnewsletter.com/p/state-of-webassembly-2026/

2. I Tried Running File Conversion Fully in the Browser (WASM, https://dev.to/digitalofen/i-tried-running-file-conversion-fully-in-the-browser-wasm-libreoffice-ffmpeg-57mh

3. SIMD and Memory Alignment \- StudyPlan.dev, https://www.studyplan.dev/sdl2/sdl2-padding/q/simd-alignment

4. Alignment hints and memory offsets · Issue \#1319 \- GitHub, https://github.com/WebAssembly/design/issues/1319

5. CKA-Guided Modular Quantization: Beyond Bit-Width to Algorithmic, https://arxiv.org/html/2512.16282v1

6. CALM: A CKA-Guided Adaptive Layer-Wise Modularization ... \- arXiv, https://arxiv.org/html/2512.16282v2

7. \[2603.04308\] Activation Outliers in Transformer Quantization \- arXiv, https://arxiv.org/abs/2603.04308

8. Jamba \- Hugging Face, https://huggingface.co/docs/transformers/model\_doc/jamba

9. 初始化项目，由ModelHub XC社区提供模型 · f004cf12cd \- Qwen2.5, https://dev.modelhub.org.cn/hazentr/Qwen2.5-0.5B-Instruct-Gensyn-Swarm-slender\_grunting\_koala/commit/f004cf12cd29569a545c10df8634648ded754403

10. A Method for Layer Bit-Width Allocation in LLM Quantization ... \- arXiv, https://arxiv.org/pdf/2608.28003

11. Intent to Experiment: WebAssembly Dynamic Tiering \- Google Groups, https://groups.google.com/a/chromium.org/g/blink-dev/c/Xzr6PQflTFA

12. (PDF) Activation Outliers in Transformer Quantization \- ResearchGate, https://www.researchgate.net/publication/401564990\_Activation\_Outliers\_in\_Transformer\_Quantization\_Reproduction\_Statistical\_Analysis\_and\_Deployment\_Tradeoffs

13. config.json · Qwen/Qwen2.5-0.5B at, https://huggingface.co/Qwen/Qwen2.5-0.5B/blob/060db6499f32faf8b98477b0a26969ef7d8b9987/config.json

14. A Huge Flaw inside Qwen2.5. Bad robustness from logits spikes, https://medium.com/@crclq2018/a-huge-flaw-inside-qwen2-5-14940178833f

15. Outlier-Free SpeechLM for Fast Adaptation and Robust Quantization, https://openreview.net/forum?id=2gDSRwfQTN

16. Bridging Activation Sparsity and FP4 Quantization for LLM Inference, https://arxiv.org/html/2606.26587v1

17. Qwen2.5-0.5B q0f16 — full precision, fine-tuning preserved, https://huggingface.co/graafhenk/ZetAI-small/commit/e0ffe357e02980975a9422dd7bd80cbe93eb4967

18. 以Qwen 为例，学习大模型的结构 \- 陈少文的网站, https://www.chenshaowen.com/blog/structure-of-large-models-with-qwen.html

19. FlexPosit: Tunable Fractional Precision for LLM Inference Accelerators, https://arxiv.org/html/2609.04724v1

20. The Complete Guide to LLM Quantization with vLLM \- Jarvislabs.ai, https://jarvislabs.ai/blog/vllm-quantization-complete-guide-benchmarks

21. There Was Almost No Q4 Inside Q4\_K\_M: Dissecting GGUF, https://thakicloud.com/tech-blog/en/llmops/gguf-quantization-internals/

22. dotLLM/docs/ROADMAP.md at main \- GitHub, https://github.com/kkokosa/dotLLM/blob/main/docs/ROADMAP.md

23. LLM Compression \- arXiv, https://arxiv.org/pdf/2508.11318

24. Zero-Copy Data Transfer Patterns \- WebAssembly (Wasm), https://www.webassembly-wasm.com/js-wasm-interop-memory-management/zero-copy-data-transfer-patterns/

25. Zero-copy pass ArrayBuffer from JS-land to WebAssembly-land \#1162, https://github.com/WebAssembly/design/issues/1162

26. Can either wasmer or wasmtime handle 1M concurrent wasm, https://users.rust-lang.org/t/can-either-wasmer-or-wasmtime-handle-1m-concurrent-wasm-modules-switching-every-1-microsecond/100017

27. merge: upload transformers implementation (\#14) \- Hugging Face, https://huggingface.co/stabilityai/stablelm-2-zephyr-1\_6b/commit/fc2fe0a02dda918d3e408ae88a329b680f59dbc2

28. Can You Run This LLM? VRAM Calculator (Nvidia GPU and Apple, https://apxml.com/tools/vram-calculator

29. Squeezing Every Drop: Running a real LLM and Hermes Agent on, https://medium.com/@mlokhandwalas/squeezing-every-drop-running-a-real-llm-and-hermes-agent-on-your-own-local-8gb-machine-31f6cd919e71

30. Using SIMD with WebAssembly \- Emscripten, https://emscripten.org/docs/porting/simd.html

31. Fast, parallel applications with WebAssembly SIMD, https://v8.dev/features/simd

32. OpenBLAS/docs/install.md at develop \- GitHub, https://github.com/OpenMathLib/OpenBLAS/blob/develop/docs/install.md

33. Add a deterministic FMA · Issue \#44 · WebAssembly/relaxed-simd, https://github.com/WebAssembly/relaxed-simd/issues/44

34. GitHub \- cunarist/tokio-with-wasm, https://github.com/cunarist/tokio-with-wasm