Diagnostics and Differential Testing of Tokenization and Decoding Fidelity in TinyRustLM

Full report

On this page

The deployment of small language models (SLMs) into strictly constrained edge environments necessitates an architectural rigor that transcends standard cloud-based inference paradigms. When migrating optimized instruction-tuned models into the custom .slm v1 container format for execution within a 114 KiB WebAssembly (WASM) module and Rust-native runtime, the pipeline introduces severe risks to inference fidelity1. These vulnerabilities span the entire execution lifecycle, encompassing misalignments in the underlying tokenizer.json parser, floating-point quantization drift within handwritten scalar matrix-vector kernels, and state-machine corruption during autoregressive decoding under a global Mutex lock1. This report provides an exhaustive, principal-level engineering analysis of how the TinyRustLM architecture must preserve the exact behavior of compact models across the Python-to-Rust/WASM boundary. It establishes a rigorous differential-testing protocol, defines explicit numerical tolerances for quantized arithmetic across varying bit depths, and delivers a comprehensive suite of diagnostic matrices, sampling configurations, and production acceptance thresholds required for validating architectural fidelity.

Tokenizer and Pre-Processing Fidelity Mechanics

The translation of a reference Hugging Face tokenizer.json into the embedded BTOK or BPE1 tokenizers within the .slm v1 format represents the first critical boundary where fidelity is routinely compromised. The .slm container enforces a rigid 108-byte header and a 64-byte tensor directory, dedicating offsets 64–80 to the tokenizer offset and length1. This embedded architecture tightly couples the vocabulary to the model weights to guarantee self-containment, but it demands absolute precision in replicating the byte-level semantics of the original framework.

Normalization, Pre-Tokenization, and Added Tokens

Before byte-pair encoding (BPE) merge rules are applied, the input text undergoes a deterministic sequence of normalization and pre-tokenization steps. Normalization standardizes the string, potentially applying Unicode normalization forms (e.g., NFC, NFD, NFKC), stripping accents, or enforcing lowercase transformations3. Pre-tokenization then fractures the normalized string based on whitespace, punctuation, or specific character classes, ensuring that BPE merge rules do not incorrectly bridge distinct linguistic boundaries. The embedded BTOK/BPE1 configuration inside the .slm artifact must serialize these exact rules into a static Rust struct. A frequent point of divergence in Rust-based tokenizers occurs with the "dummy prefix space" paradigm (historically represented as Ġ in certain BPE vocabularies). If the reference tokenizer automatically prepends a space to the initial user string but the Rust parser omits this injection, the resulting sequence of token IDs shifts entirely. This misalignment forces the model into an out-of-distribution embedding space from the very first inference step. Furthermore, "added tokens"—which bypass standard BPE merging—must be registered identically. If an added token is ignored by the .slm parser, the system will incorrectly shred specialized domain vocabulary into granular subwords, destroying the semantic density the model expects.

Byte-Level BPE Behavior and Byte Fallback

Modern compact instruction models predominantly utilize byte-level Byte-Pair Encoding, operating directly on bytes rather than Unicode characters to effectively eliminate out-of-vocabulary (OOV) errors4. The Rust parser must impeccably replicate the exact sequence of merges defined in the reference framework. When a multi-byte character or symbol is absent from the primary vocabulary, the BPE algorithm must initiate byte fallback, decomposing the unmapped character into its constituent raw bytes (e.g., \<0xE2\>, \<0x98\>, \<0x83\>). The WASM runtime must execute this fallback deterministically, appending the exact byte tokens to the sequence. If the Rust implementation incorrectly substitutes an \<unk\> (unknown) token instead of performing byte fallback, the model suffers an irrecoverable loss of information, severely degrading performance in multilingual, mathematical, or code-generation contexts where non-standard characters are frequent5.

UTF-8 Boundary Handling, Token Decoding, and Whitespace Cleanup

Autoregressive decoding introduces complex challenges for UTF-8 boundary handling. Because a single multi-byte UTF-8 character can be fractured across multiple sequential tokens, the WASM runtime cannot simply flush each token ID directly into a native Rust String or a JavaScript DOM element1. Attempting to decode an incomplete byte sequence prematurely forces standard library string converters to yield Unicode replacement characters (\\) or throw fatal boundary exceptions. The implementation must maintain a raw byte-buffer stream. Token decoding must only attempt UTF-8 validation and subsequent string materialization when a valid character boundary is achieved. Concurrent with decoding, whitespace cleanup rules must precisely reverse the pre-tokenization artifacts, safely converting internal representations (like Ġ or \_) back into standard spaces without erroneously stripping intentional formatting in code blocks or structured JSON outputs.

Control Tokens: BOS, EOS, PAD, UNK, and Chat Controls

The structural integrity of the inference control plane relies entirely on the accurate mapping and enforcement of special tokens. The Beginning-of-Sequence (BOS) token anchors the positional embeddings, while the End-of-Sequence (EOS) token explicitly terminates the generation loop1. Instruction-tuned models augment this with specialized chat-control tokens (e.g., \<|system|\>, \<|user|\>, \<|assistant|\>, or \<|eot\_id|\>) to manage conversational state. The TinyRustLM tokenizer must independently manage these tokens outside the standard text-encoding path. It is imperative that the runtime explicitly injects the BOS token during the prefill phase and immediately halts the execution loop the exact moment the EOS or an equivalent turn-ending chat-control token is sampled1. Failure to halt at the correct EOS variant triggers runaway generation, causing the model to hallucinate the user's subsequent turn or emit repetitive garbage until the maximum-output budget forces a termination. Additionally, \<pad\> and \<unk\> tokens must align perfectly with the model's configuration; mismapping a chat token to \<pad\> strips the prompt of its instruction-tuning framework, reducing the model to a base text completion engine.

Prompt Structuring and Context Budgeting

The translation of user intent into the model's expected prompt structure requires exact serialization of the model's training templates. Any deviation at this stage degrades the prompt from a high-fidelity instruction into anomalous input.

Exact Chat-Template Serialization and System-Message Treatment

Instruction-tuned models are acutely sensitive to the whitespace, line breaks, and specialized control tokens codified within their Jinja2 chat templates. Translating these dynamic templates into the static TinyRustLM environment is a major vector for fidelity loss. The runtime must perfectly assemble the byte string representing the system message, the user prompt, and the generation-prompt suffix (the sequence appended to cue the model to begin generating, such as \<|start\_header\_id|\>assistant\<|end\_header\_id|\>\\n\\n). The system message often functions as an "attention sink," anchoring the model's contextual understanding and stabilizing the attention mechanism across long generations8. If the system message is improperly tokenized, or if the generation-prompt suffix lacks the exact necessary trailing spaces or line breaks, the model will output sub-optimal logits, as the sequence fails to match the highly specific distribution observed during alignment training.

Stop-Token and Stop-Sequence Handling

Termination of the generation loop is dictated by either specific stop tokens (e.g., the exact token ID for EOS) or stop sequences (byte arrays that signal completion when decoded). Relying solely on token-ID stopping is brittle; models occasionally construct a stop sequence out of multiple fragmented subword tokens. The runtime must monitor the decoded byte stream in real-time, executing a rolling buffer comparison against defined stop sequences. The observed phenomenon of a basic "test" prompt rejection highlights the complexities of these boundary conditions. If the user submits a minimal string such as "test" and generation fails, it is rarely a model-level refusal. Rather, it indicates a defect where the tokenizer strips necessary boundary whitespace, or the generation-prompt suffix incorrectly merges with the word "test", triggering a stop-sequence collision or causing the model to interpret the input as an empty string. The "test" rejection serves as a critical baseline diagnostic: verifying that the smallest possible user string successfully navigates normalization, control-token wrapping, prefill execution, and yields at least one coherent assistant token before hitting an EOS state.

Multi-Turn Transcript Inclusion and Prompt Truncation

TinyRustLM operates under a strict, unyielding resource envelope. The entire architecture is serialized by a process-global mutex, and host memory transfers are constrained by a 128 MiB raw allocation ceiling2. The Key-Value (KV) cache is sized deterministically at load time based on the equation: [Figure omitted from source export] where [Figure omitted from source export] denotes layers, [Figure omitted from source export] is the context capacity, [Figure omitted from source export] is KV heads, and [Figure omitted from source export] is the head dimension. For the TinyLM-16M architecture, this requires exactly 8,388,608 bytes of memory2. For multi-turn transcripts, the runtime appends subsequent interactions to this continuous KV cache. Re-tokenizing and re-evaluating the entire conversation at every turn is computationally prohibitive for CPU-bound WASM targets. When the conversation approaches the hard limit of context capacity [Figure omitted from source export], the runtime must execute a deterministic prompt truncation protocol2. This protocol cannot simply slice arbitrary tokens from the front of the sequence, as doing so might sever a multi-byte UTF-8 sequence, destroy a chat-control token, or evict the critical system message. Instead, the runtime must parse the transcript at structural boundaries, retaining the system message as an attention sink, evicting the oldest user-assistant message pairs in their entirety, and recalculating the KV cache from the newly truncated transcript8.

Execution Defect Isolation

Determining whether output divergence originates from acceptable mathematical drift or a structural pipeline defect is the most complex challenge in maintaining inference fidelity10. TinyRustLM's reliance on handwritten scalar Rust loops operating on the main browser thread exposes the system to specific classes of execution defects1.

GQA, Masking, and KV-Cache Defects

TinyRustLM explicitly requires that the number of attention heads equals the number of KV heads to satisfy its forward scratch memory allocation1. It currently rejects Grouped-Query Attention (GQA) and Multi-Query Attention (MQA) topologies. If a GQA model is forcefully loaded, or if the attention masking mechanism fails, the model will output mathematically valid but semantically unmoored logits. A masking defect or KV-cache misalignment is easily diagnosed via differential testing: the prefill phase will execute flawlessly, and the very first generated token will exactly match the reference framework. However, the second generated token will diverge radically. This pattern confirms that the new Query vector is improperly attending to a corrupted, unaligned, or incorrectly broadcast historical Key/Value buffer8.

RoPE and RMSNorm Calculation Failures

Rotary Positional Embeddings (RoPE) apply a complex rotation matrix to the queries and keys, scaling relative distances based on their absolute positional index in the sequence. If the position indices drift—for instance, if prompt truncation logic shifts the transcript without resetting the RoPE index mapping—the angles will misalign. A RoPE defect manifests as rapid, cascading coherence loss. The model may generate five to ten accurate tokens before suddenly devolving into repetitive, catastrophic gibberish as the positional logic interferes destructively. Conversely, a Root Mean Square Normalization (RMSNorm) defect is identifiable by the magnitude of the error. RMSNorm relies on an [Figure omitted from source export] (epsilon) constant to ensure numerical stability: [Figure omitted from source export] If the [Figure omitted from source export] constant is extracted incorrectly from the .slm header (e.g., loaded as [Figure omitted from source export] instead of [Figure omitted from source export]), or if the Root Mean Square is calculated across the incorrect tensor dimension, the resulting scale of the logits will either explode to infinity or collapse near zero12. This results in a massive Mean Absolute Error (MAE) when compared to reference logits, even if the ordinal ranking (and thus Cosine Similarity) of the top tokens temporarily survives the scaling error.

Decoding Mechanics and Sampling Mathematics

Translating the raw logit vectors into a deterministic token selection dictates the model's creativity, coherence, and resistance to degeneration. TinyRustLM manages this through a fixed transient array capped strictly at 1,024 candidates within its sampling state machine2. The mathematical pipeline must apply modifications in a rigid, non-commutative sequence: Repetition Penalties [Figure omitted from source export] Truncation Sampling (Top-K / Min-P / Typical-P / Nucleus) [Figure omitted from source export] Temperature Scaling [Figure omitted from source export] Softmax. Applying these out of order fundamentally corrupts the probability distribution13.

Frequency, Presence, and Repetition Penalties

Penalties are designed to combat the natural tendency of autoregressive models to become trapped in degenerate loops. However, they must be implemented meticulously. The traditional Repetition Penalty applies a multiplicative scalar to the logit of a previously generated token. Its primary flaw is extreme volatility; its effect scales non-linearly depending on the raw magnitude of the logit, which varies wildly across different model architectures14. Modern implementations favor subtractive penalties:

[Figure omitted from source export]

[Figure omitted from source export]

• Frequency Penalty: Reduces the logit based on the exact count of occurrences in the generated context.
• Presence Penalty: Applies a singular, flat reduction if the token has appeared at least once, regardless of frequency.

A critical architectural mandate is the prevention of premature EOS and degenerate-loop amplification. Frequency and presence penalties must never be applied to special control tokens14. If a system blindly applies a frequency penalty across the entire transcript, the logit for the EOS token will be systematically driven into the negatives during a long conversation. When the model reaches a semantic conclusion and attempts to stop generation, the penalized EOS token is suppressed, forcing the model to hallucinate continuous, runaway text until it violently strikes the maximum-output budget constraint designed to protect the browser thread.

Temperature, Top-K, Top-P, Min-P, and Typical Sampling

Following penalty application, the logits must be truncated to eliminate the "unreliable tail" of the distribution before probabilistic selection15.

[Figure omitted from source export] Applying temperature before truncation samplers (like Top-P) alters the underlying probability curve, rendering the truncation thresholds highly unstable across different temperatures13.

[Figure omitted from source export] Min-P scales natively with model confidence. If the model is highly certain (e.g., top token holds 90% probability), a min\_p of 0.1 restricts the pool to tokens with [Figure omitted from source export] probability, aggressively pruning noise. If uncertain (top token holds 15%), it considers tokens down to 1.5%, gracefully expanding the candidate pool13.

[Figure omitted from source export] This prevents the model from choosing tokens that are either highly unpredictable or overly predictable, maintaining a consistent, human-like cadence13.

• Temperature: Scales the logits prior to the softmax function to control entropy.
• Top-K: A legacy heuristic that strictly retains only the [Figure omitted from source export] highest-probability tokens. It is highly brittle, cutting too aggressively when the model is uncertain (flat distribution) and not aggressively enough when the model is highly confident (peaked distribution)13.
• Top-P (Nucleus Sampling): Retains the smallest set of tokens whose cumulative probability exceeds the threshold [Figure omitted from source export]. While superior to Top-K, it still struggles with extreme temperature variations.
• Min-P (Modern Default): Discards any token whose probability is less than a dynamically calculated fraction of the highest probability token's score.
• Typical Sampling (Typical-P): An advanced information-theoretic approach retaining tokens whose information content (negative log-probability) closely aligns with the expected entropy [Figure omitted from source export] of the overall distribution.

Deterministic Seeded Sampling and Maximum-Output Budgeting

To facilitate rigorous differential testing, the Pseudo-Random Number Generator (PRNG) must be strictly seeded. Within the TinyRustLM WASM ABI, deterministic PRNG state and replay limits are explicitly secured under the global Mutex19. Assuming identical prompt boundaries, context states, seeds, and sampler settings, the sequence of floating-point generation for the random threshold must remain bit-for-bit identical across the WebAssembly execution environment and the native Rust backend. Furthermore, to prevent the main browser thread from locking indefinitely, generation is bound by a maximum-output budget. The Mutex is configured to forcefully release and return whatever byte state has been generated the exact moment the token count intersects this predefined ceiling, protecting host memory constraints regardless of EOS state2.

Differential-Testing Protocol and Numerical Tolerances

To mathematically guarantee that the TinyRustLM .slm conversion and the Rust/WASM execution environment perfectly preserve reference behavior, a strict, six-stage differential-testing protocol is required. This protocol evaluates the model across differing execution targets and quantized bit-depths to pinpoint exactly where fidelity breaks down10.

The Six-Stage Comparison Matrix

1. Reference Framework Token IDs vs. Converted .slm Token IDs: A vast corpus of edge-case strings is passed through the Hugging Face reference tokenizer and the .slm embedded BTOK/BPE1 tokenizer. The resulting integer arrays must yield a 100% exact match. Deviations implicate the parsing of the normalization rules, added tokens, or BPE merge tables.
2. Reference First-Step Logits vs. Rust-Native First-Step Logits (f32): Utilizing the exact same token IDs, a single forward pass (prefill) is executed on the Python reference implementation and the native Rust implementation compiled for the host CPU. The raw, unpenalized logits for the next token are extracted and compared.
3. Rust-Native First-Step Logits vs. WASM First-Step Logits (f32): The identical prefill pass is executed inside the compiled WebAssembly artifact running in a headless V8 environment. The logits must match the native Rust logits with zero deviation. Variances here indicate WASM ABI serialization errors, violations of the 128 MiB boundary, or fundamental 32-bit vs. 64-bit floating-point math discrepancies inherent to the WebAssembly target1.
4. Quantized First-Step Logits (q8, q6, q5, q4): The reference f32 logits are compared against the Rust/WASM implementation executing the quantized .slm weights to isolate pure quantization drift.
5. Multi-Token Seeded Output (Reference vs. .slm): Utilizing a fixed seed and temperature, a 512-token sequence is generated. The final string outputs and the sequence of token IDs are compared to identify compounding execution errors over extended loops.
6. Multi-Turn State Validation: A three-turn simulated conversation is injected into the system. The KV-cache state and the final generated output are audited to verify that the prompt truncation and sequential KV-cache appending logic remain perfectly synchronized.

Specifying Numerical Tolerances

Floating-point arithmetic is inherently non-associative. Microscopic differences in the order of operations within a matrix-vector multiplication kernel result in expected precision drift. Quantization drastically amplifies this by truncating the numerical representation of the weights. Consequently, rigid mathematical tolerances using Cosine Similarity ([Figure omitted from source export]) and Mean Absolute Error (MAE) must be established across the entire vocabulary size [Figure omitted from source export] for the logit vectors.

Note: TinyRustLM implementation currently dictates support for f32, q8\_0, and q4\_0 execution mathematically1. The expanded q6 and q5 metrics represent the required interpolation bounds if intermediate block scaling is introduced to the architecture roadmap. Distinguishing true quantization drift from structural defects relies on these bounds. Pure quantization drift manifests as a high cosine similarity ([Figure omitted from source export]) with only minor re-ordering of the top 5 logits. Under greedy decoding ([Figure omitted from source export]), the generated sequence may diverge after 50 tokens as minor errors accumulate, but the text will remain linguistically coherent. Conversely, structural defects (such as RoPE or Masking failures) will cause Cosine Similarity to violently collapse below [Figure omitted from source export], resulting in immediate generation of gibberish.

Required Deliverables

To validate the deployment of TinyRustLM into production constraints, the following seven deliverables form the required conformance, diagnostic, and architectural suite.

1. Tokenizer and Chat-Template Conformance Suite

A rigid JSON-based test matrix mapping raw text inputs to their expected normalized text, exact byte-level token ID arrays, and Jinja-serialized byte-strings. The suite must explicitly test edge cases:

• Complex multi-byte emojis (e.g., 👨‍👩‍👧‍👦) to force and validate byte-fallback behaviors across multiple BPE tokens.
• Boundary conditions for whitespace prefixing, including leading, multiple, and trailing spaces.
• Multi-turn template structures validating the precise injection of \<|user|\>, \<|assistant|\>, and \<|system|\> roles without accidental trailing whitespace padding.
• The generalized "test" prompt rejection scenario to verify that minimal viable inputs yield standard generation rather than collapsing against stop-sequence limits.

2. Golden Token and Logits Vectors

A set of pre-calculated, immutable artifacts generated directly from the reference Python implementation to serve as ground truth for CI/CD regression testing.

• Prefill Golden Vector: An array of 32-bit floating-point numbers representing the unpenalized logits for the first predicted token of the standardized prompt "The capital of France is".
• Decode Golden Vector: A sequence of 100 token IDs generated via Greedy Decoding ([Figure omitted from source export]) from the above prompt to serve as the absolute baseline for WASM autoregressive comparisons.
• Quantization Golden Matrix: The expected top-20 logits and their exact floating-point values for q8\_0 and q4\_0, locking the baseline MAE and Cosine Similarity thresholds in place.

3. Sampler Experiment Matrix

An exhaustive testing matrix engineered to validate the internal sampling mechanics of the WASM runtime by isolating and combining specific parameters.

4. Recommended Sampling Presets

Optimized sampling presets tailored to the mathematical behavior of Small Language Models operating in edge environments. Because SLMs inherently possess flatter probability distributions and higher uncertainty than frontier models, aggressive Top-K is strictly deprecated in favor of Min-P13.

5. Ambiguous-Input Behavior and Clarification Enforcement

Compact models inherently suffer from heightened epistemic uncertainty—hallucinating plausible answers when they lack definitive knowledge rather than correctly identifying their own knowledge gaps. To counteract this, clarification must be enforced through the model using a rigid system directive injected during chat-template serialization. The runtime must inject the following directive: "You are a precise, deterministic diagnostic assistant. If a user's prompt lacks sufficient detail to provide a mathematically or factually certain answer, you must output the exact string: \[CLARIFICATION\_REQUIRED\] followed by a single sentence identifying the missing constraint." The testing protocol supplies the model with fundamentally ambiguous prompts (e.g., "Calculate the total cost." without providing any numerical inputs). The test suite evaluates whether the generated output exactly yields the \[CLARIFICATION\_REQUIRED\] token array. If the model attempts to hallucinate arbitrary numbers, the min\_p threshold is incrementally raised in the test configuration until the system prompt's authoritative weight overcomes the generative hallucination bias.

6. Diagnostics Required to Localize Failures

The global Mutex executing the WASM ABI must yield a structured, deterministic JSON diagnostic payload upon either the successful completion or fatal failure of a generation transaction. This payload is the sole mechanism for localizing failures directly to the architectural stages2.

JSON { "transaction\_id": "8f4a-uuid-string", "model\_identity": { "checksum": "uint64", "precision": "q4\_0", "vocab\_size": 32000 }, "load\_stage\_status": "KV\_ALLOCATION\_SUCCESS", "generation\_stage": { "prompt\_tokens": 42, "generated\_tokens": 128, "stop\_reason": "EOS\_TOKEN", "context\_utilization\_bytes": 1048576, "peak\_memory\_bytes": 45000000 }, "performance\_metrics": { "time\_to\_first\_token\_ms": 145, "generation\_time\_ms": 4200, "tokens\_per\_second": 30.4 }, "error\_recovery": { "stable\_message": null, "numeric\_code": 0 } }

If a model transfer exceeds the hard constraints, the load\_stage\_status will flag TRANSFER\_CEILING\_EXCEEDED and abort prior to Mutex locking2. If the model outputs nonsense, analyzing the performance\_metrics and stop\_reason will reveal if the maximum-output limit was reached prematurely, allowing engineers to correlate the failure directly to a specific pipeline defect, such as penalty corruption on the EOS token.

7. Production Acceptance Thresholds with No Answer Fabrication

Before any .slm container is promoted to production for browser-local WebAssembly execution, it must clear the following strict, non-negotiable architectural gates:

1. Immutability and Constraints: The 108-byte header's internal checksum must match the compiled binary representation exactly. Furthermore, the total artifact size must be strictly [Figure omitted from source export] MiB (reserving 3 MiB for ABI overhead) to clear the 128 MiB WASM allocation ceiling1.
2. Fidelity: The q8\_0 converted model must achieve a Cosine Similarity [Figure omitted from source export] on the prefill logits against the f32 Python reference, proving quantization drift is contained.
3. No Answer Fabrication: On a suite of 50 adversarial, highly ambiguous prompts, the model must return the \[CLARIFICATION\_REQUIRED\] directive 100% of the time under Temperature \= 0.0. Any hallucination results in immediate promotion failure.
4. State Safety and Recovery: A simulated critical crash (e.g., injecting an invalid UTF-8 byte array mid-generation to trigger a boundary failure) must successfully trigger the WASM error-code contract, safely release the global Mutex, clear the generation transcript, and preserve the underlying model weights in host memory without requiring a full 128 MiB artifact reload from the network1.

Works cited

1. Implementation \- MiRust, https://mirust.com/implementation/
2. Implementation operations \- MiRust, https://mirust.com/implementation-operations/
3. Building a tokenizer, block by block \- Hugging Face, https://huggingface.co/learn/llm-course/chapter6/8
4. tokenizers \- PyPI, https://pypi.org/project/tokenizers/
5. Byte Pair Encoding \- HF \- Kaggle, https://www.kaggle.com/code/utkarshsaxenadn/byte-pair-encoding-hf
6. The African Language Tax \- arXiv, https://arxiv.org/html/2606.24460v1
7. Model lifecycle – MiRust, https://mirust.com/docs/model-lifecycle/
8. KV Cache Compression and Its Infra Problems \- Research at NVIDIA, https://research.nvidia.com/labs/eai/blogs/kv-cache-compression-and-its-infra-problems/
9. What is a KV cache, and why does it make LLM inference faster? \- Sebastian Raschka, https://sebastianraschka.com/faq/docs/kv-cache.html
10. Hidden Reliability Risks in Large Language Models: Systematic Identification of Precision-Induced Output Disagreements \- arXiv, https://arxiv.org/html/2604.19790v1
11. MetaSel: A Test Selection Approach for Fine-Tuned DNN Models \- IEEE Computer Society, https://www.computer.org/csdl/journal/ts/2025/11/11175088/2adNMni8zNm
12. RMSNorm — PyTorch 2.13 documentation, https://docs.pytorch.org/docs/stable/generated/torch.nn.modules.normalization.RMSNorm.html
13. LLM Sampling Parameters: Temperature, top-p, DRY, XTC (2026) | Local AI Master, https://localaimaster.com/blog/llm-sampling-parameters-explained
14. Repetition penalties are terribly implemented \- A short explanation and solution \- Reddit, https://www.reddit.com/r/LocalLLaMA/comments/1g383mq/repetition\_penalties\_are\_terribly\_implemented\_a/
15. Foundations of Top-k Decoding for Language Models \- OPT 2025: Optimization for Machine Learning, https://opt-ml.org/papers/2025/paper160.pdf
16. LLM Settings & Parameters Guide | PromptOps Ecosystem, https://justprompting.in/settings
17. Impact of decoding strategies on GPU energy usage in large language model text generation \- PMC, https://pmc.ncbi.nlm.nih.gov/articles/PMC12808663/
18. DiffSampling: Enhancing Diversity and Accuracy in Neural Text Generation \- Mirco Musolesi, https://www.mircomusolesi.org/papers/tmlr25\_diffsampling.pdf
19. Documentation \- MiRust, https://mirust.com/docs/
20. Code Generation by Differential Test Time Scaling \- arXiv, https://arxiv.org/pdf/2605.20473