Source-To-Native-To-Browser Numerical And Tokenization Conformance

Full report

On this page

1. Executive Conformance Philosophy and Assumptions

The fundamental premise of trustworthy artificial intelligence inference is platform-deterministic execution, an architectural requirement that ensures identical models yield mathematically predictable outcomes regardless of the underlying computational hardware. The machine learning reproducibility crisis is deeply intertwined with the assumption that floating-point math operates uniformly across platforms, an assumption that hardware acceleration and browser-based sandboxes continuously violate1. For the TinyRustLM ecosystem, which uniquely spans native Rust binaries, browser-based WebAssembly (WASM), and WebGPU environments, structural artifact validity or successful model loading does not constitute evidence of model fidelity. Therefore, conformance within the TinyRustLM framework is defined as a mathematically bounded, verifiable, and immutable relationship between a heavily audited source oracle and the specific execution path of a declared .slm runtime artifact. The architecture must explicitly reject the notion of a generalized parity boolean. Cross-runtime equality operates on a spectrum ranging from byte-exact tokenization and integer exactness in quantization unpacks, to mathematically bounded tolerances in parallel attention reductions, and finally to statistically verified stochastic sampling validity. The underlying philosophy mandates total source discipline. Legacy undocumented behaviors, silent conflict resolutions, and heuristic post-generation repairs are strictly prohibited from the validation pipeline. End-to-end mechanical conformance must be evaluated on synthetic vectors isolated entirely from behavioral evaluation benchmarks to prevent the contamination of training and calibration data. Every layer of the execution stack—from the Unicode extended grapheme cluster boundaries of the tokenizer to the pseudo-random state transitions of the sampler—must be pinned, hashed, and deterministically auditable. The resulting framework guarantees that TinyRustLM can definitively prove that a promoted model implements the exact semantics declared by its source.

2. Identity Graph and Immutable Source-Acquisition Protocol

An inference runtime cannot claim behavioral fidelity to a model without a cryptographically sealed identity graph that binds every upstream artifact and transformation parameters to the final binary execution. The conformance identity graph for TinyRustLM establishes a rigorous bijection between the source repository and the .slm runtime artifact, utilizing a Merkle-directed acyclic graph (Merkle DAG) where every node is content-addressed2. The root node of this identity graph binds a vast array of discrete components. First, it requires the exact Git commit hash of the source repository, strictly prohibiting the use of floating tags or mutable references. Second, it incorporates the cryptographic hashes of all configuration oracles, including config.json, generation\_config.json, tokenizer\_config.json, and tokenizer.json. Third, the graph anchors the exact hashes of the source .safetensors weight files. Fourth, it integrates the transformation parameters, which encapsulate the precise converter version, the target quantization profile, the added-token map, the normalizer, the pre-tokenizer, and the post-processor. Finally, the graph captures the runtime profile, logging the specific backend (native, WASM, or WebGPU), thread counts, SIMD enablement flags, and the pseudo-random number generator (PRNG) seed states. Source acquisition during the generation of this graph must adhere to strict immutability protocols. Downstream processing requires the streamed cryptographic hashing of all artifacts to avoid exhausting system memory on excessively large weight files. If the upstream repository employs Large File Storage (LFS), the acquisition protocol must resolve the LFS pointers and hash the underlying binary blobs rather than the text pointers themselves. Furthermore, the acquisition pipeline must perform rigorous safety and bounds checking on the source .safetensors files. The SafeTensors format utilizes an 8-byte unsigned integer prefix to declare the length of its JSON metadata header3. If a malicious or malformed file declares an astronomically large header size, naive parsers may attempt to allocate excessive memory, leading to denial-of-service vulnerabilities4. Consequently, the acquisition pipeline must enforce a strict header size bound (e.g., 100 megabytes) and validate that no tensor data offsets overlap within the file buffer, which is a known vector for memory corruption and polyglot malware embedding4. Crucially, the protocol enforces a strict stop-on-conflict rule. If contradictory parameters are detected across the configuration files—such as a tokenizer\_config.json declaring an End-of-Sequence (EOS) token ID of 2 while the generation\_config.json declares an EOS token ID of 128001—the system must halt execution and emit a fatal conflict error. TinyRustLM must never silently arbitrate between conflicting configurations. The normative contract dictates that a single authoritative declaration must be chosen through explicit manual override in the conformance configuration, ensuring that the runtime never guesses the intended behavior of the model architect.

3. Normative Tokenizer and Unicode Specification

The tokenizer serves as the critical translation layer between human-readable Unicode text and the high-dimensional numerical latent space of the language model. TinyRustLM must implement a normative tokenizer contract that behaves mechanically identically across native Rust, WASM, and Python reference implementations. Divergence in tokenization fundamentally alters the input tensor, instantly invalidating downstream numerical conformance. The normative specification for tokenization dictates a sequence of exact mechanical steps. First, the input decoding phase must strictly parse valid UTF-8 sequences. When encountering invalid byte sequences, the API must enforce a declared byte fallback policy. If the source model utilizes a byte-level fallback mechanism (such as SentencePiece's \<0xXX\> hexadecimal byte mapping), it must be applied7. In the absence of such a declared mechanism, the tokenizer must deterministically inject the Unicode Replacement Character (U+FFFD). Second, Unicode normalization forms (NFC, NFD, NFKC, NFKD) must be executed precisely as dictated by the model card before any pre-tokenization or text segmentation occurs. Text segmentation itself must strictly obey Unicode Standard Annex \#29 (UAX \#29) guidelines for extended grapheme cluster boundaries8. Grapheme clusters, which represent user-perceived characters, must never be arbitrarily split by byte-level algorithms unless explicitly mandated by regular expression splitting boundaries defined in the tokenizer configuration. The algorithm must flawlessly process combining marks, complex emoji sequences utilizing Zero Width Joiners (ZWJ), and conjoining Korean Jamo without fracturing the intended semantic units10. During the Byte-Pair Encoding (BPE) or unigram tokenization phases, merge ties must be resolved by examining the declared merge ranks. If multiple candidate merges share an identical rank, the conflict must be resolved deterministically, generally favoring left-to-right precedence. Special tokens must be matched exactly against the added-tokens map. If a special token lookalike string is present in the input and explicit template escaping is disabled, the normative contract dictates that it must be parsed as standard text unless it was programmatically injected by the chat template processor. To mechanically verify this complex contract, TinyRustLM must execute against a comprehensive suite of tokenizer golden vectors. This suite must test ASCII boundaries, every Unicode whitespace class (including U+0020, U+3000, and U+200B), combining marks, composed versus decomposed equivalents, variation selectors, right-to-left text sequences, and CJK ideographs. It must also include inputs designed to stress-test encode/decode non-invertibility cases, strings featuring embedded NUL bytes, and long repeated input sequences designed to verify algorithmic complexity bounds and prevent regular-expression denial-of-service vulnerabilities.

4. Chat-Template and Special-Token Specification

Instruction-tuned models rely on chat templates to semantically frame user inputs, system instructions, and tool outputs. Because TinyRustLM operates in both native and browser environments, it cannot rely on Python's Jinja2 templating engine. Instead, a Rust-native, WebAssembly-compatible engine, such as MiniJinja, must be employed to guarantee identical parsing and rendering logic12. The template rendering semantics require precise, bit-exact outputs. Role names must be mapped accurately, and the handling of empty messages or multi-turn conversational histories must perfectly align with the source model's intended syntax. The insertion of Beginning-of-Sequence (BOS) and EOS tokens is strictly regulated; they must only be injected where explicitly defined by the configuration graph, preventing double-insertion bugs that severely degrade generation quality. Whitespace handling within templates is a frequent source of cross-platform divergence. Trailing spaces, the distinction between carriage return line feeds (\\r\\n) and standard line feeds (\\n), and the exact byte sequences preceding the assistant generation prefix must be perfectly preserved prior to tokenization. Furthermore, the template engine must enforce strict escaping protocols. Untrusted user data must be sanitized, and arbitrary template execution within untrusted conversational payloads is strictly forbidden to prevent context corruption or template injection vulnerabilities. The generated string must naturally terminate with the assistant's generation prefix (e.g., \<|im\_start|\>assistant\\n), leaving the LLM's sequence perfectly positioned to generate the next conversational token.

5. Configuration and Source-Tensor Mapping Rules

The translation of source weight formats into TinyRustLM's .slm binary format requires a rigid, mathematically proven bijection. Any source tensor that is discarded, duplicated, or reshaped must be explicitly documented and architecturally justified within the conformance graph. The runtime must strictly interpret the architectural family parameters, ensuring exact dimensional matching for layer counts, attention heads, context limits, vocabulary sizes, and Grouped Query Attention (GQA) key/value head ratios. Normalization epsilon values, bias presence flags, and tensor parallel remnants must be ingested identically. If a source configuration specifies conflicting fields—such as defining both a max\_position\_embeddings limit and a contradictory sliding\_window parameter without explicit override logic—the conversion oracle must halt. Mapping source tensor names and shapes to normative semantic roles frequently requires complex transformations. For example, if the source model supplies a fused qkv\_proj tensor, but the .slm runtime architecture requires separated q\_proj, k\_proj, and v\_proj blocks, the exact slicing dimensions must be recorded and mathematically verified. Similarly, SwiGLU gated Feed-Forward Networks (FFNs) often interleave or concatenate the gate and up-projections; the separation of these tensors must be bit-exact. Rotary Positional Embeddings (RoPE) represent one of the most critical tensor mapping challenges. Implementations vary significantly between "interleaved" tensor layouts and "rotated" split-halves layouts. Some architectures organize frequencies in a chunked manner (e.g., separating dimensions into halves), while others interleave them sequentially to preserve frequency continuity14. Transforming between these layouts during conversion requires an explicit, bit-exact permutation matrix that must be validated against high-precision golden vectors to ensure positional frequencies are identically applied during inference16.

6. Operator and Floating-Point Semantics

Achieving true cross-runtime equality necessitates an exhaustive definition of floating-point arithmetic semantics. While IEEE 754-2019 provides the mathematical foundation17, TinyRustLM's deployment targets—specifically WebAssembly and WebGPU—introduce platform-specific hardware divergences that make bitwise equality across all environments impossible1. The most prominent barrier to determinism is the non-associativity of floating-point addition21. Because [Figure omitted from source export], matrix multiplications and parallel reductions executed in WebGPU WGSL compute shaders will accumulate in non-deterministic orders depending on how the hardware scheduler dispatches workgroups. Furthermore, hardware implementations of Fused Multiply-Add (FMA) compute equations with a single rounding step, whereas scalar WASM execution may separate the multiplication and addition into two distinct rounding steps, causing immediate numerical divergence17. WebAssembly's Relaxed SIMD proposal further complicates conformance. Certain instructions, such as f32x4.min and f32x4.max, exhibit implementation-defined behaviors when processing NaN values or signed zeros, differing based on whether the host processor utilizes x86 AVX or AArch64 NEON instructions22. The WebGPU shading language (WGSL) specification also explicitly permits flush-to-zero (FTZ) behaviors for denormalized numbers and does not strictly mandate IEEE-754 adherence for infinity handling or NaN payload preservation20. Consequently, the normative choice for TinyRustLM is to abandon the pursuit of universal bitwise equality in floating-point operations. Instead, the framework must enforce mathematically bounded equivalence, relying on strict Units in the Last Place (ULP) tolerances for scalar and SIMD execution, and high cosine similarity thresholds for WebGPU parallel reductions. Operations prone to divergence, such as Softmax denominators and RMSNorm variance accumulations, must be profiled to ensure that exponent approximations and negative zero handling do not cascade into semantic errors.

7. Quantization Packing and Numerical Fidelity

Quantization introduces the highest risk of mechanical regression within the inference pipeline. The conversion of high-precision floating-point oracles to packed integer .slm blocks must be audited at the byte level to guarantee structural integrity and numerical fidelity. TinyRustLM must standardize its interpretation of block-based quantization formats, mirroring the structural efficiencies of formats like GGUF26.

Conformance requires the direct mathematical comparison of source float tensors against these dequantized .slm blocks. The scalar dot product computed using dequantized weights must be validated against the heavily optimized kernels (such as SIMD or WebGPU dot-product accumulators) executing the same operation. Error bounds must carefully account for the accumulation of quantization noise across deep transformer layers, which can lead to severe perplexity degradation if rounding behaviors, tie-breaking logic, and clipping tails are not deterministically aligned with the calibration corpus lineage29.

8. Sampling and Stop-Condition Semantics

Even when logits are mathematically bounded and exact, stochastic sampling can diverge wildly if the underlying random number generation and thresholding logic vary across platforms. TinyRustLM must implement a rigidly deterministic sampling pipeline to ensure reproducibility. The Pseudo-Random Number Generator (PRNG) algorithm must be explicitly pinned. The normative specification mandates the use of the PCG32 (Permuted Congruential Generator) algorithm, recognized for its exceptional statistical quality, compact 128-bit state, and 32-bit output31. The 64-bit state advancement is defined mathematically by the exact multiplier and sequence increment: [Figure omitted from source export] To guarantee identical random floating-point values across native Rust, WASM, and Python, the integer-to-float conversion must be strictly standardized, typically by extracting the upper 32 bits and multiplying by [Figure omitted from source export] to ensure uniform distribution mapping32. The application of sampling algorithms must follow a rigidly fixed deterministic sequence (e.g., Repetition Penalty, followed by Temperature scaling, Top-K truncation, Top-P nucleus sampling, and finally Min-P). Min-P sampling, a critical methodology for balancing creativity and coherence at higher temperatures, operates by dynamically scaling a base probability threshold against the probability of the most likely token34. The truncation threshold is defined precisely as [Figure omitted from source export]35. All tokens where the probability falls below [Figure omitted from source export] are deterministically masked. Furthermore, operations requiring the sorting of logits, such as Top-K and Top-P, must utilize stable sorting algorithms. In the event of exact probability ties, the token ID must be utilized as the secondary sort key to prevent PRNG drift. Finally, the system must dictate exact behavior for edge cases: if all tokens are masked via token bans, or if logits collapse entirely to NaN, the framework must deterministically force the selection of an EOS token rather than crashing or emitting hallucinated byte sequences.

9. Golden-Vector Schema and Generation Procedure

Conformance verification relies heavily on versioned, public-safe golden vectors. These vectors must explicitly avoid utilizing sealed behavioral evaluation prompts to prevent accidental contamination of training pipelines or public reporting bias37. The golden-vector container must utilize a high-performance, language-agnostic schema, such as a CBOR or FlatBuffers payload, to ensure zero-copy deserialization capabilities and strict schema enforcement38. The schema must include:

1. Identity Hashes: The precise source commit, generator identity, converter version, and configuration hash.

2. Synthetic Inputs: Mechanically rigorous token sequences, including Fibonacci series, mathematical equations, and randomized Unicode byte streams.

3. Expected Intermediate States: Bounded numerical arrays representing selected embeddings, pre-normalization outputs, RoPE-rotated queries and keys, raw attention scores, post-Softmax probabilities, and the final top-k logit results prior to quantization.

4. Tolerance Definitions: Explicitly declared tolerances for each layer and operator, utilizing metrics such as maximum absolute error, relative error, or cosine similarity.

These vectors must be materialized via a high-precision conversion oracle. The oracle must run in Python using PyTorch configured with torch.use\_deterministic\_algorithms(True), executed entirely on the CPU utilizing float64 or float32 data types to prevent GPU-specific non-determinism from polluting the baseline truth.

10. Native, WASM, SIMD, Threaded, and WebGPU Comparison Matrix

Given the vast differences in hardware capabilities and browser sandbox restrictions, TinyRustLM requires a comprehensive comparison matrix to validate execution across all targeted runtimes.

To navigate these divergent environments, the conformance suite must implement an operator-level diagnostic API. This API facilitates a bisection sequence designed to locate the exact layer and operator where divergence first occurs. If, for instance, WASM SIMD diverges from WASM Scalar, the bisection tool automatically isolates the input embeddings, QKV projections, attention scores, and FFN outputs layer by layer, halting at the precise matrix multiplication kernel responsible for breaching the established ULP limits.

11. End-to-End and Multi-Turn Conformance Protocol

Validating mechanical conformance on single-turn generation is insufficient for modern conversational language models. The pervasive use of Key-Value (KV) caching, prefix-sharing, and sliding window attention mechanisms introduces complex state management complexities that single-turn tests cannot expose39. The multi-turn conformance protocol must bind and verify the exact rendered prompt, the corresponding prompt token IDs, and the prefix-cache identity. When a multi-turn prompt perfectly matches the prefix of a previously evaluated prompt, the inference engine must reuse the KV state without recalculating the prefill. The output logits of the first generated token in this cached scenario must exactly match the logits generated during a cold-start scenario to verify cache integrity. Furthermore, positional ID continuity must be validated. As conversations extend across multiple turns, the sequential accumulation of positional IDs fed into the RoPE operators must be verified against the expected multi-turn state. The protocol must also simulate extreme context lengths to verify KV cache eviction mechanisms, ensuring that stale memory is pruned deterministically according to the model's configured sliding window or truncation logic. All multi-turn behavioral checks—such as ensuring the model remembers a constraint from turn one during turn five—must be evaluated using sealed, private datasets whose raw text is never published to the receipt graph.

12. Stochastic Statistics and Behavioral Separation

Inference validation must clearly distinguish between deterministic implementation drift (which indicates a mechanical kernel or operator bug) and allowed sampling variation (which indicates intended stochastic exploration). Even when the underlying mechanical implementation is flawless, executing the model repeatedly with a non-zero temperature will produce a distribution of differing answers. To validate that the sampling pipeline—including Temperature scaling, Top-K, Top-P, and Min-P logic—operates correctly across heterogeneous backends, TinyRustLM must apply rigorous statistical distributional tests. The Kolmogorov-Smirnov (K-S) test serves as the normative standard for this validation40. By generating statistically significant sample sizes (e.g., [Figure omitted from source export] or [Figure omitted from source export]) from fixed sets of PRNG seeds across highly correlated synthetic prompts, the framework computes the maximum deviation between the empirical cumulative distribution functions of the runtime output and the baseline oracle. If the calculated K-S p-value falls below a strict significance threshold (e.g., [Figure omitted from source export]), the null hypothesis is rejected. This rejection provides strong statistical evidence that the runtime is not sampling from the identical probability distribution as the oracle, signaling a critical failure in the integer-to-float conversion, PRNG advancement, or sampling logic43. The selection of "easiest-seed" outputs to bypass these tests is strictly forbidden; multiple comparisons must be accounted for to ensure robust statistical confidence.

13. Receipt Graph and Change-Invalidation Rules

Because end-to-end conformance testing and golden-vector generation are computationally intensive, TinyRustLM must implement a content-addressed receipt graph. This graph tracks the cryptographic provenance of all test outcomes, preserving obsolete and failed evidence while systematically reusing unaffected data during continuous integration cycles. Change-invalidation rules must be precisely defined based on the component modified:

• Tokenizer Modifications: A change to the tokenizer source, normalizer, or BPE ranking rules invalidates all pre-tokenization, byte-fallback, and prompt-to-ID golden tests. However, it does not invalidate quantization numerical tests or isolated kernel operator validations.
• Kernel or Backend Operator Changes: Modifying a WebGPU WGSL matrix multiplication kernel invalidates the operator-level numerical tolerances and the end-to-end raw outputs specifically for the WebGPU backend. It leaves the tokenization receipts and the native Rust scalar outputs intact.
• Converter or Quantization Profile Changes: Altering the logic within the .slm converter or adjusting a quantization scale strategy forces a total invalidation of all downstream .slm hashes, requiring a full regeneration of quantization tests, end-to-end outputs, and stochastic K-S distributions.

14. TDD Tooling Backlog and Clean Cutover Plan

To elevate TinyRustLM from its pre-publication state to a fully conformant, production-grade architecture, a strict Test-Driven Development (TDD) tooling backlog and implementation plan is required. Phase 1: Deterministic Fundamentals The initial phase demands the construction of the source-oracle exporter utilizing PyTorch to generate the public-safe FlatBuffers golden vectors. Concurrently, the byte-exact tokenizer verification suite must be finalized, ensuring UAX \#29 normalizations are perfect. Pack/unpack exactness tests for all targeted integer quantization formats (Q4\_K, Q8\_0) must achieve zero bit-level discrepancies. Phase 2: Layer-by-Layer Scalars Development must proceed to the creation of the .slm inspector API. The native Rust scalar operators must be implemented and mathematically proven to achieve 0-ULP parity against the CPU oracle for a single complete transformer layer, validating the RMSNorm, RoPE rotations, Attention reductions, and SwiGLU activations in isolation. Phase 3: Accelerated Backends and Multi-Turn The final phase introduces the highly optimized WASM SIMD, Threaded WASM, and WebGPU backends. The mismatch reducer and bisection tooling must be deployed to automatically compare these accelerated outputs against the scalar baseline, outputting automated cosine similarity matrices. Finally, deterministic multi-turn behavior and K-S stochastic validations must be integrated. Promotion Gates: No runtime branch or .slm model conversion may be promoted to publication status until it passes the comprehensive suite of mechanical golden vectors and the stochastic K-S test suite. Prior to the v1.0 release, a clean cutover must be executed, permanently deleting all contradictory unpublished semantics, legacy tokenizers, and heuristic prompt templates from the TinyRustLM codebase.

15. Unknowns Requiring Private Artifacts or Local Execution

Because this report is constructed entirely from publicly verifiable specifications and independent research, several critical facets of the TinyRustLM architecture necessitate local, authorized verification by the internal engineering teams. First, the proprietary aspects of the .slm binary structure must be internally audited. While the architecture is presumed to leverage memory-mapping techniques akin to GGUF, the specific header bounds, byte alignments, and zero-copy offset validations must be explicitly tested against overlapping offset vulnerabilities and out-of-bounds memory accesses4. Second, the targeted WebGPU environments are assumed to operate within modern, standard-compliant browser engines. However, the rapidly evolving nature of the WGSL specification means that differing browser implementations (e.g., Chrome's Dawn engine versus Firefox's wgpu) frequently introduce varying, un-trapped undefined behaviors (UB)20. Local, cross-browser execution matrices must be maintained to identify vendor-specific non-determinism. Finally, the exact mechanisms governing prefix-caching memory limits within WebAssembly linear memory allocations require local verification. The distinction between graceful out-of-bounds trapping versus dynamic memory growth must be tested against the host runtime to ensure memory exhaustion does not result in silent state corruption.

16. Primary-Source Literature Review

The architectural constraints and normative recommendations outlined in this report are deeply anchored in published computational research and standard specifications. The necessity of platform-deterministic inference is established by research into the trustworthiness of AI, which proves that the IEEE 754 floating-point arithmetic standard fundamentally violates deterministic state requirements, making exact hash-based verification across heterogeneous hardware mathematically intractable1. The non-associativity of floating-point accumulation, alongside differing implementations of Fused Multiply-Add (FMA), further necessitates the abandonment of bitwise equality in favor of bounded tolerances for accelerated backends17. Within the browser environment, the WebGPU shading language (WGSL) specification introduces explicit allowances for flush-to-zero (FTZ) behaviors on denormalized numbers and permits implementation-defined handling of NaNs, requiring robust cosine similarity checks rather than exact integer comparisons20. Concurrently, the WebAssembly Relaxed SIMD proposal documents non-deterministic behaviors for critical instructions like f32x4.min and f32x4.max when processing NaNs, differing wildly based on whether the underlying host processor utilizes x86 AVX or AArch64 NEON instructions22. The structural integrity of model serialization formats is governed by insights into GGUF and SafeTensors. The quantization blocks—specifically the symmetric Q8\_0 structure and the complex, asymmetric Q4\_K super-block architecture—dictate the necessary unpack math and byte-alignment requirements26. The security architecture of SafeTensors highlights severe vulnerabilities, such as 100MB JSON header DoS attacks and memory corruption via overlapping byte offsets, demanding strict bounds-checking during the source acquisition phase3. To ensure exact text segmentation, the Unicode Standard Annex \#29 (UAX \#29) provides the indispensable, normative rules for extended grapheme cluster boundaries, which are paramount for accurate tokenizer conformance8. Finally, the stochastic validation of LLM outputs relies on the mathematical formulations of Min-P dynamic truncation34 and the application of Kolmogorov-Smirnov (K-S) statistical tests to measure the divergence of empirical cumulative distribution functions, ensuring that sampling variation does not mask underlying mechanical bugs40.

Works cited

1. (PDF) On the Foundations of Trustworthy Artificial Intelligence \- ResearchGate, https://www.researchgate.net/publication/403194378\_On\_the\_Foundations\_of\_Trustworthy\_Artificial\_Intelligence

2. Adaptive Accountability in Networked MAS: Tracing and Mitigating Emergent Norms at Scale An early version of this paper was published in AAAI/ACM AIES 2025 \[3\]: https://doi.org/10.1609/aies.v8i1.36536 \- arXiv, https://arxiv.org/html/2512.18561v3

3. Machine learning — list of Rust libraries/crates // Lib.rs, https://lib.rs/science/ml

4. Securing LLM Supply Chains: Model Serialization Attacks and Safe Formats (Safetensors), https://www.shyankdev.us/blogs/securing-llm-supply-chains-safetensors

5. Gradient-Based Model Fingerprinting for LLM Similarity Detection and Family Classification, https://arxiv.org/html/2506.01631v2

6. Safetensors Forensics: It's “Safe”… Right? \- Emanuele De Lucia, https://www.emanueledelucia.net/safetensors-forensics-its-safe-right/

7. mistral-7b-instruct-v0.2 vs Mistral-7B-v0.3 — comparison, examples, https://www.aimodels.fyi/models/compare/mistral-7b-instruct-v02-mistralai-vs-mistral-7b-v0.3-mistralai

8. UAX \#29: Unicode Text Segmentation, http://www.unicode.org/reports/tr29/tr29-22.html

9. UAX \#29: Unicode Text Segmentation, https://www.unicode.org/reports/tr29/tr29-13.html

10. uniseg package \- github.com/Code-Hex/uniseg \- Go Packages, https://pkg.go.dev/github.com/Code-Hex/uniseg

11. Working with grapheme clusters \- ESDiscuss.org, https://esdiscuss.org/topic/working-with-grapheme-clusters

12. axominijinja — Rust template engine // Lib.rs, https://lib.rs/crates/axominijinja

13. minijinja \- crates.io: Rust Package Registry, https://crates.io/crates/minijinja/2.7.0

14. modeling\_qwen3\_asr.py · capacit-ai/saga at main \- Hugging Face, https://huggingface.co/capacit-ai/saga/blob/main/modeling\_qwen3\_asr.py

15. transformers/src/transformers/models/qwen3\_5\_moe/modeling\_qwen3\_5\_moe.py at main \- GitHub, https://github.com/huggingface/transformers/blob/main/src/transformers/models/qwen3\_5\_moe/modeling\_qwen3\_5\_moe.py

16. LLMs-from-scratch/ch05/07\_gpt\_to\_llama/converting-gpt-to-llama2.ipynb at main \- GitHub, https://github.com/rasbt/LLMs-from-scratch/blob/main/ch05/07\_gpt\_to\_llama/converting-gpt-to-llama2.ipynb

17. Valori: A Deterministic Memory Substrate for AI Systems \- arXiv, https://arxiv.org/html/2512.22280v1

18. P3375R3: Reproducible floating-point results \- Open-std.org, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3375r3.html

19. From Floating-Point Precision to Human Perception: Reimagining Approximation as Nature's Algorithm of Mathematical-Politics and Human—Computing Symbiosis \- Preprints.org, https://www.preprints.org/manuscript/202510.2288

20. A WebGPU backend for Futhark, https://futhark-lang.org/student-projects/sebastian-msc-thesis.pdf

21. P3375R2: Reproducible floating-point results \- Open-std.org, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3375r2.html

22. Config in wasmtime \- Rust, https://docs.wasmtime.dev/api/wasmtime/struct.Config.html

23. Relaxed SIMD · Issue \#1401 · WebAssembly/design \- GitHub, https://github.com/WebAssembly/design/issues/1401

24. Add new instructions: min / max · Issue \#33 · WebAssembly/relaxed-simd \- GitHub, https://github.com/WebAssembly/relaxed-simd/issues/33

25. IEEE-754 Floating Point · Mighty Professional Tutorials, https://mightyprofessionalgaming.com/tutorials/floating-point-from-scratch

26. GGUF \- Wikipedia, https://en.wikipedia.org/wiki/GGUF

27. The Complete Guide to LLM Quantization with vLLM: Benchmarks & Best Practices, https://jarvislabs.ai/blog/vllm-quantization-complete-guide-benchmarks

28. A system programmer's guide to LLM inference \- Xiangpeng's blog, https://blog.xiangpeng.systems/posts/how-to-llm-inference/

29. apex-quant/paper/APEX\_Technical\_Report.md at main \- GitHub, https://github.com/mudler/apex-quant/blob/main/paper/APEX\_Technical\_Report.md

30. Cross-Layer Error Compensation and Finite-Sample Feature-Statistics Matching for Extreme Low-Bit Quantization of Large Language Models \- arXiv, https://arxiv.org/html/2607.14630v1

31. API reference \- Mitsuba 3, https://mitsuba.readthedocs.io/en/stable/src/api\_reference.html

32. Pseudo-random numbers/PCG32 \- Rosetta Code, https://rosettacode.org/wiki/Pseudo-random\_numbers/PCG32

33. C Notes for Professionals, https://nvkarta.com/project/library/uploads/engineering/programming/CNotesForProfessionals.pdf

34. Turning Up the Heat: Min-p Sampling for Creative and Coherent LLM Outputs \- arXiv, https://arxiv.org/pdf/2407.1082

35. Top-H Decoding: Adapting the Creativity and Coherence with Bounded Entropy in Text Generation \- NIPS, https://papers.neurips.cc/paper\_files/paper/2025/file/294de0fa7149adcb88aa3119c239c63e-Paper-Conference.pdf

36. Time-Annealed Perturbation Sampling: Diverse Generation for Diffusion Language Models \- arXiv, https://arxiv.org/pdf/2601.22629

37. A Missing Testbed for LLM Pre-Training Membership Inference Attacks | OpenReview, https://openreview.net/forum?id=kFpbxWy1p8

38. Flatbuffers vs CBOR \- json \- Stack Overflow, https://stackoverflow.com/questions/47799396/flatbuffers-vs-cbor

39. Asynchronous Reasoning: Training-Free Interactive Thinking LLMs \- OpenReview, https://openreview.net/pdf?id=nRqH1Qfbp5

40. (PDF) UnpredictaBench: A Benchmark for Evaluating Distributional Randomness in LLMs, https://www.researchgate.net/publication/406352772\_UnpredictaBench\_A\_Benchmark\_for\_Evaluating\_Distributional\_Randomness\_in\_LLMs

41. Master Synthetic Data Validation to Avoid AI Failure | Galileo, https://galileo.ai/blog/validating-synthetic-data-ai

42. UnpredictaBench: A Benchmark for Evaluating Distributional Randomness in LLMs \- arXiv, https://arxiv.org/html/2606.06622v3

43. Which test is the best? We compared 5 methods to detect data drift on large datasets, https://www.evidentlyai.com/blog/data-drift-detection-large-datasets

44. awesome-production-machine-learning \- GitHub Pages, https://ethicalml.github.io/awesome-production-machine-learning/

45. Understanding SafeTensors: A Secure Alternative to Pickle for ML Models \- DEV Community, https://dev.to/lukehinds/understanding-safetensors-a-secure-alternative-to-pickle-for-ml-models-o71

46. Program Reconditioning: Avoiding Undefined Behaviour When Finding and Reducing Compiler Bugs \- Department of Computing, https://www.doc.ic.ac.uk/\~afd/papers/2023/PLDI.pdf

47. LLVM Language Reference Manual, https://llvm.org/docs/LangRef.html