Architecture and Inference Efficiency of Compact Language Models: Identifying Optimal Frontiers for In-Browser Edge Execution

Full report

On this page

The deployment of Large Language Models (LLMs) directly within client-side browser environments represents a fundamental shift in distributed artificial intelligence. By executing models purely via WebAssembly (WASM), systems can guarantee zero-latency network transmission, absolute data privacy, and offline functionality. However, the operational constraints of browser-based execution are severe. Abstract metrics such as parameter count or theoretical floating-point operations per second (FLOPs) provide an incomplete picture of a model's viability. True feasibility requires a holistic understanding of tensor architecture, embedding structures, tokenizer footprints, quantization metadata overhead, and the memory allocation mechanics of the host runtime. This research report evaluates the landscape of compact language models—ranging from approximately 50 million to 1.2 billion parameters—to identify the smallest openly distributable models capable of executing genuinely useful tasks. These tasks encompass conversational chat, text rewriting, summarization, code explanation, structured JSON generation, and bounded logical reasoning. The evaluation is strictly anchored to the observed architectural constraints of the TinyRustLM.com scalar runtime and its bespoke SLM1 container format1. By normalizing candidate architectures, projecting latency within single-threaded scalar execution environments, and constructing rigorous Pareto frontiers based on download payload and peak memory capacity, this analysis provides an exhaustive framework for deploying local machine intelligence at the edge.

1. Operational Constraints of the Target Execution Environment

To appropriately select and optimize models for the TinyRustLM ecosystem, one must first dissect the hard limits established by its runtime architecture. The system currently executes a raw C-style Application Binary Interface (ABI) compiled to a 114 KiB WebAssembly module2. It lacks modern accelerator abstractions such as WebGPU, SIMD-specific kernel dispatch, or multi-threaded worker pools2. Inference relies entirely on the main JavaScript thread utilizing handwritten scalar Rust loops, fundamentally altering the optimal architectural profile for candidate models.

1.1 The 128 MiB Transfer Ceiling and Peak Load Duplication

The most restrictive bottleneck in the current TinyRustLM architecture occurs during the model admission and loading phase. The runtime operates under a strict, non-negotiable 128 MiB transfer ceiling for a single continuous allocation2. When a model is initiated, the host JavaScript environment fetches the target artifact into a local response buffer. Because WASM executes within an isolated, pre-allocated linear memory space, the JavaScript host must dynamically expand the WASM heap and orchestrate a byte-for-byte memory copy of the artifact into a transient transfer buffer. Finally, the WASM runtime parses this buffer and materializes the persistent tensor storage. This process results in a massive, temporary spike in physical memory utilization known as "peak-load duplication." During the load\_model transaction3, the browser must simultaneously hold:

1. The original JavaScript ArrayBuffer containing the fetched weights.
2. The linear WASM memory transfer allocation.
3. The newly instantiated tensor directory and persistent storage within the runtime's global mutex lock2.

Consequently, an artifact's peak memory footprint during initialization is approximately three times its disk size, exclusive of contextual generation buffers. An artifact weighing 100 MB will routinely cause a 300 MB allocation spike. Any artifact whose quantized byte size exceeds the 128 MiB ABI ceiling will trigger an immediate, unrecoverable out-of-memory exception or structural rejection prior to parser admission2. Without migrating to a chunked, streaming file admission protocol—identified internally as the "Gate B" architectural transition2—the 128 MiB hardcap remains the definitive boundary for out-of-the-box compatibility.

1.2 The Grouped-Query Attention (GQA) Memory Penalty

To reduce the memory overhead of the Key-Value (KV) cache during autoregressive generation, modern language models frequently employ Grouped-Query Attention (GQA) or Multi-Query Attention (MQA), wherein multiple Query (Q) heads share a single KV head4. However, the SLM1 container parser and the TinyRustLM forward-pass logic explicitly reject models where the number of attention heads does not equal the number of KV heads2. To deploy a GQA-optimized model into this runtime, engineers must artificially replicate the k\_proj and v\_proj weights during the conversion process so that the KV head count matches the Q head count, effectively spoofing standard Multi-Head Attention (MHA)6. Because the TinyRustLM runtime maintains its KV cache strictly in unquantized 32-bit floating-point (f32) arrays5, this required replication entirely negates the contextual memory savings originally intended by the model authors. As context lengths grow, the replication penalty forces models with high head counts to consume exorbitant amounts of linear WASM memory, limiting their practical deployment on memory-constrained mobile hardware.

1.3 The Vocabulary Imbalance and Tied Embeddings

In ultra-compact models (sub-500M parameters), the vocabulary projection layers absorb a disproportionate percentage of the total parameter budget. For example, a model configured with a vocabulary of 150,000 tokens and a hidden dimension of 896 requires over 134 million parameters solely for the token embedding matrix6. If the output logit projection matrix is kept distinct (untied), the model duplicates this cost, wasting hundreds of megabytes on redundant semantic mappings. Therefore, models implementing tied embeddings—where the input embedding matrix and the final output projection matrix share the exact same underlying memory pointer (tie\_word\_embeddings: true)—are practically mandatory for highly constrained environments7. Untied architectures yield severely diminishing returns for general edge reasoning, as the added parameter mass inevitably breaches the transfer ceiling without providing a commensurate increase in logical depth or syntax adherence.

2. Normalized Candidate Profiling and Tensor Architecture

To isolate the optimal candidates for deployment, leading open-weight architectures spanning the 50M to 1.2B parameter regimes were analyzed. Evaluating these candidates requires dissecting their structural dimensions: Hidden size ([Figure omitted from source export]), Number of Layers ([Figure omitted from source export]), Query Heads ([Figure omitted from source export]), KV Heads ([Figure omitted from source export]), Feed-Forward Network dimension ([Figure omitted from source export]), and Vocabulary size ([Figure omitted from source export]). We evaluate the following prominent families: SmolLM2, Qwen2.5, OLMo, TinyLlama, OpenELM, and MobileLLM. Note that while MobileLLM configurations are included to benchmark architectural efficiency, models distributed under the FAIR Noncommercial Research License strictly prohibit commercial redistribution or use in integrated end-user products targeting commercial advantage9. Consequently, MobileLLM models are excluded from the final deployment recommendations.

Note: The OpenELM architecture uniquely employs varying FFN dimensions across different layers (ranging from 0.5x to 4.0x scaling) and utilizes untied embeddings, significantly bloating its disk footprint relative to its representational capacity4. MobileLLM-125M and MobileLLM-350M achieve remarkable structural depth via aggressive layer sharing (where physical weights are iteratively reused across multiple transformer blocks), effectively decoupling logical depth from parameter mass11.

3. Detailed Footprint Equations and Quantization Projections

Converting baseline parameters into physical browser constraints requires meticulous modeling of quantization overhead, metadata scaling, and contextual memory allocations. The TinyRustLM SLM1 format stores models using a 108-byte fixed file header, followed by a 64-byte tensor directory entry per tensor, and strictly enforces 64-byte payload alignment2.

3.1 Quantization Overhead and Block Scales

Simplistic parameter-count multiplication fails to capture the true size of a quantized artifact. Modern quantization operates on block scales—grouping weights (typically into blocks of 32\) and assigning a 16-bit or 32-bit floating-point scale and minimum value to each block2. This metadata inflates the theoretical byte-per-parameter ratio. The SLM1 format currently specifies support for f32 (dtype 1), q8\_0 (dtype 2), and q4\_0 (dtype 3\)2. Using standard block size 32 conventions, the memory multipliers are as follows:

• F32 (Unquantized): [Figure omitted from source export] bytes.
• Q8\_0: A block of 32 8-bit integers requires 32 bytes, plus a 16-bit (f16) scale (2 bytes). This yields 34 bytes per 32 weights, or approximately [Figure omitted from source export] bytes per parameter. In some highly optimized implementations, metadata packing reduces this slightly, but we apply a conservative [Figure omitted from source export] to [Figure omitted from source export] multiplier6.
• Q6\_K / Q5\_K Estimates: For comprehensive planning, if [Figure omitted from source export]\-quants are introduced, Q6\_K averages [Figure omitted from source export] bytes per parameter, and Q5\_K averages [Figure omitted from source export] bytes per parameter.
• Q4\_0: A block of 32 4-bit integers requires 16 bytes, plus a 2-byte scale, resulting in 18 bytes per 32 weights. This yields exactly [Figure omitted from source export] bytes per parameter (or 5 bits per weight)6.
• Q3\_K / Q2\_K Estimates: Aggressive sub-4-bit quantization reduces footprints to [Figure omitted from source export] and [Figure omitted from source export] bytes per parameter, respectively, albeit at severe perplexity costs for models under 1 Billion parameters.

3.2 Projected Artifact Sizes Across Quantization Profiles

Applying these overhead multipliers, we can project the exact download payloads for each candidate architecture.

Analysis: Only the SmolLM2-135M at Q4\_0 and TinyLlama-50M definitively clear the 128 MiB transfer ceiling imposed by the current TinyRustLM instantiation. The 135M Q8\_0 artifact marginally exceeds the threshold, requiring truncation, vocabulary clipping, or immediate runtime upgrades.

3.3 Context State and Execution Workspace Memory

To calculate the expected WASM linear-memory utilization during active inference, the static weights must be combined with the transient forward scratch pad, the vocabulary logits array, and the persistent KV cache3.

1. Forward Scratch Pad: Evaluated using the formula [Figure omitted from source export] bytes3. For the heaviest sub-billion candidate, Qwen2.5-0.5B, where [Figure omitted from source export], [Figure omitted from source export], and context [Figure omitted from source export], the scratch pad demands only [Figure omitted from source export] bytes ([Figure omitted from source export] MB).
2. Logits Allocation: Evaluated using the formula [Figure omitted from source export] bytes3. Qwen2.5-0.5B's massive 151,936 vocabulary requires roughly [Figure omitted from source export] bytes ([Figure omitted from source export] MB).
3. KV Cache Formulation: The persistent KV cache operates in standard f32 precision. As established, TinyRustLM requires replicating KV heads ([Figure omitted from source export]) to match Q heads ([Figure omitted from source export])2. The original storage requirement natively is [Figure omitted from source export] bytes per token (where [Figure omitted from source export]). Under replication, this becomes [Figure omitted from source export] bytes. Since [Figure omitted from source export], the simplified forced memory formula is [Figure omitted from source export] bytes per token6.

The forced MHA replication imposes catastrophic memory burdens on deeper models. For example, Qwen2.5-0.5B's theoretical 24 KB/token footprint explodes to 172 KB/token, consuming over 350 MB of linear WASM memory just to hold a 2048-token conversation. This reveals that structural KV optimization is the most urgent necessary patch for the TinyRustLM execution engine.

4. Tokenizer Storage and Chat-Template Mechanics

An often-overlooked source of WASM binary bloat and latency overhead is the tokenizer logic and its associated string representations. Unlike Python environments where tokenizers are dynamically loaded by the transformers library, client-side inference requires compiling the byte-pair encoding (BPE) merge rules and vocabulary dictionaries directly into the client framework.

Vocabulary Size Impact

Models utilizing extensive multilingual vocabularies incur distinct storage penalties. Qwen2.5-0.5B utilizes a massive 151,936-token Tiktoken-based BPE vocabulary13. Translating this dictionary into a contiguous byte-tokenizer (BTOK) format requires storing raw string bytes, token ID mappings, and associated merge scores. A 150k vocabulary typically inflates the underlying WASM memory requirement by an additional 6 to 10 MB entirely dedicated to string tries and search structures. In contrast, TinyLlama-1.1B and OpenELM-270M employ a lean 32,000-token vocabulary, drastically reducing initialization times and the memory footprint of the tokenizer instance6.

Chat Templates and Special Tokens

Generating structured instruction outputs requires strict adherence to the special tokens and injection templates prescribed during the model's fine-tuning phase.

• SmolLM2 Series: Utilizes a standard ChatML format (\<|im\_start|\>user\\n...\<|im\_end|\>). The runtime must cleanly intercept the \<|im\_end|\> token ID to halt generation and return bounded state14.
• Qwen2.5-0.5B: Also adheres to ChatML formatting but requires meticulous handling of multilingual byte fallbacks.
• Llama-3.2-1B: Employs a complex tag-based template (\<|start\_header\_id|\>user\<|end\_header\_id|\>...\<|eot\_id|\>)15. The SLM1 generation loop must be verified to correctly buffer and decode these extended multi-token control sequences without leaking raw XML-style strings to the client presentation layer.

5. Desktop and Mobile Latency Projections

Predicting actual token-generation throughput within a deterministic scalar environment requires modeling memory bandwidth, as matrix-vector multiplication in autoregressive decoding is almost entirely memory-bound. The TinyRustLM implementation executes via single-threaded JavaScript/WASM loops without the aid of WebGPU or WebNN API offloading2. Therefore, latency is a direct function of reading the entire quantized model from memory for every single token generated.

• Desktop Projections: Modern desktop DDR5 memory offers an aggregate bandwidth of roughly 50 to 80 GB/s. However, scalar WASM bounds-checking and cache-miss overheads typically constrain effective throughput to \~10-15 GB/s. For a Q4\_0 model weighing 100 MB, reading the model once per token yields a theoretical ceiling of \~100 to 150 tokens per second (tok/s).
• SmolLM2-135M (Q4\_0, 84 MB): Expected desktop latency of 120-160 tok/s.
• Qwen2.5-0.5B (Q4\_0, 308 MB): Expected desktop latency of 30-45 tok/s.
• Mobile Projections: Mobile LPDDR4x/LPDDR5 frameworks exhibit higher latency and stricter thermal throttling, typically realizing only 3 to 6 GB/s of effective scalar memory bandwidth within browser environments.
• SmolLM2-135M (Q4\_0, 84 MB): Expected mobile latency of 35-50 tok/s.
• Qwen2.5-0.5B (Q4\_0, 308 MB): Expected mobile latency of 8-12 tok/s.

While Qwen2.5-0.5B yields highly intelligent responses, its mobile WASM latency approaches the threshold of poor user experience, reaffirming the unique utility of the 135M parameter class for immediate real-time interactions on constrained devices.

6. Quality Ceilings and Licensing Evidence

Selecting a model requires proving that it is legally clear for unrestricted distribution and possesses the requisite intelligence to be "genuinely useful."

6.1 Licensing and Redistribution Constraints

• MobileLLM Family: Licensed under the Meta FAIR Noncommercial Research License. Clause 1.b.i explicitly prohibits commercial use or integrated end-user product distribution9. This model is disqualified from open redistribution recommendations.
• OpenELM Family: Released under the Apple Sample Code License. It permits commercial modification and distribution provided specific Apple copyright notices and disclaimers are preserved16.
• SmolLM2, Qwen2.5, OLMo, and TinyLlama: Released universally under the permissive Apache 2.0 license, permitting seamless commercial redistribution and adaptation without usage restrictions18.
• Llama-3.2-1B: Distributed under the bespoke Llama 3.2 Community License. It permits broad commercial redistribution for entities with fewer than 700 million monthly active users21, which completely covers the vast majority of local-edge deployment scenarios.

6.2 Task-Specific Quality Ceilings

Published benchmarks frequently fail to translate into qualitative edge utility. By synthesizing observed test data, we can define precise execution boundaries:

• TinyLlama-50M / Maracatu-80M: Genuinely incapable of zero-shot logic, structured JSON, or complex chat templates23. They serve only as experimental syntax autocomplete engines.
• SmolLM2-135M-Instruct: The absolute inflection point for utility18. It demonstrates excellent syntax rewriting, concise summarization, and reliable adherence to basic JSON schemas. However, it fails at deep logical abstraction, mathematical reasoning, or complex code generation. Its quality ceiling is strictly bounded to linguistic transformation.
• OpenELM-270M-Instruct: Highly controversial quality metrics. Despite theoretical advances in layer-wise scaling, widespread evaluation indicates it scores poorly on structured reasoning (MMLU performance hovering near random chance) and exhibits brittle prompt adherence17.
• Qwen2.5-0.5B-Instruct: The undisputed champion of the sub-billion regime. Due to an aggressive pre-training lineage, it seamlessly executes multi-turn conversational chat, robust code explanation, structured data extraction, and short-form logical deductions26. It bridges the gap between toy models and server-grade intelligence.
• Llama-3.2-1B: A Tier-1 local intelligence model. Through distillation from its 8B and 70B siblings over 9 trillion tokens, it exhibits near-GPT-3.5 caliber reasoning and flawless tool-use adherence15. However, its massive scale renders it cumbersome for environments without chunked loading.

7. Constructed Pareto Frontiers

Applying the constraints of size, memory duplication, and KV caching, we define five optimal frontiers for deployment planning. (Note: External estimates and published metrics are clearly distinguished from our own calculated WASM memory bounds).

8. Recommended Deployment Tiers and Finalists

Based on the intersection of licensing freedom, cognitive utility, and stringent memory constraints, we establish three definitive deployment tiers:

Tier 1: Maximum Viability at Minimum Footprint

Selected Model: SmolLM2-135M-Instruct The only candidate that delivers reliable, grammar-perfect structural routing and summarization while remaining comfortably beneath the 128 MiB single-transfer allocation limit of the unmodified runtime.

Tier 2: The Optimal Desktop-Class Edge Model

Selected Model: Qwen2.5-0.5B-Instruct Offering an immaculate balance of intelligence and scale, this model provides legitimate coding explanations and JSON mapping. However, its 308 MB Q4\_0 footprint mandates immediate architectural patching (the Gate B Worker-owned incremental runtime upgrade) to bypass the host transfer ceiling.

Tier 3: The Premium Local Intelligence Backbone

Selected Model: Llama-3.2-1B While computationally demanding and requiring extensive gigabyte-class WASM allocations, it delivers enterprise-grade logic directly to the browser. Its deployment forces an upgrade to native GQA KV-cache management, as its baseline MHA replication demands a ruinous 262 KB per token6.

Finalist Summary

• The Smallest Candidate Likely to be Genuinely Useful: SmolLM2-135M-Instruct. At 84 MB in Q4\_0, it establishes the minimum viable floor for semantic understanding, fully eclipsing the unstable syntax generated by 50M parameter experiments.
• The Best Quality Candidate with a Reasonable Local Footprint: Qwen2.5-0.5B-Instruct. At \~300 MB, it avoids the crushing gigabyte payloads of the 1B+ tier while executing complex logical parsing unseen in the 300M tier.

9. Concrete .slm Conversion and Verification Plan

To bridge the gap between Hugging Face's canonical weights and the bespoke TinyRustLM ecosystem, a concrete conversion methodology is required for the finalized candidates. The tinyrustlm-slm-pack utility must execute the following operations precisely2.

Phase 1: Tensor Extraction and Architectural Patching

1. Parse and Normalize: Load the target model's model.safetensors via standard Python runtimes. Extract the configuration JSON to identify hidden dimensions ([Figure omitted from source export]), layer counts ([Figure omitted from source export]), and the specific activation functions (e.g., SwiGLU)25.
2. MHA Replication for GQA Compliance: Because the SLM1 format header dictates parity between Q and K dimensions, intercept the k\_proj and v\_proj matrices. For Qwen2.5-0.5B, programmatically duplicate the 2 KV heads 7 times along the head dimension so they artificially equal the 14 Q heads. This fulfills the parser contract at the expense of memory bloat.

Phase 2: Tokenizer Translation

1. Extract BPE Dictionaries: Identify the tokenizer.json and export the byte-pair merge sequence28.
2. BTOK / BPE1 Injection: Flatten the vocabulary mapping into the explicit BTOK binary byte format expected by the runtime. Securely encode the specific ChatML or Llama-3 special end-of-turn tokens, binding them to the internal stop-generation identifiers14.

Phase 3: Quantization and Data Alignment

1. F32 Baseline Validation: To isolate quantization errors, initially pack the unmodified f32 (dtype 1\) weights into an SLM1 container. Populate the 64-byte tensor directory, calculate the FNV-1a hashes for tensor names, and strictly enforce the 64-byte payload padding boundaries2. Run a deterministic prompt on the browser to verify graph integrity.
2. Q4\_0 Block Execution: Apply 4-bit asymmetric block quantization. Partition weights into blocks of 32, derive the optimal f16 scale, and bit-pack the values. Serialize the data sequentially, mark the tensor directory as dtype 3 (q4\_0), and confirm that the overall file size aligns with the [Figure omitted from source export] parameter multiplier projection2.

Phase 4: Container Sealing and Deployment

1. Header Generation: Construct the exact 108-byte file header. Ensure the magic bytes are valid, the version integer is set to 1, and the expanded replicated MHA dimension matrices are encoded correctly1. Calculate the requisite non-cryptographic checksum and append it to the manifest2.
2. Runtime Observability Test: Instantiate the module through the JavaScript static server loopback2. Monitor the WASM console for the load\_model transaction latency, explicitly log the allocated forward scratch size and KV cache commit, and verify that the generated logits precisely match the original Hugging Face implementation.

Works cited

1. MiRust: Home, https://mirust.com/
2. Implementation \- MiRust, https://mirust.com/implementation/
3. Implementation operations \- MiRust, https://mirust.com/implementation-operations/
4. Fine-tune OpenELM(270M) with ORPO \- Kaggle, https://www.kaggle.com/code/aisuko/fine-tune-openelm-270m-with-orpo
5. Current implementation limitations – MiRust, https://mirust.com/docs/gguf-implementation/current-implementation-limitations/
6. unknown\_url
7. config.json · bkhmsi/micro-smollm2-135m at 1ebfb28c382f9176647bbbb9f63cdb7ed0a62e57 \- Hugging Face, https://huggingface.co/bkhmsi/micro-smollm2-135m/blob/1ebfb28c382f9176647bbbb9f63cdb7ed0a62e57/config.json
8. config.json · vikashkr117/smollm2-135m-raw-trained at main \- Hugging Face, https://huggingface.co/vikashkr117/smollm2-135m-raw-trained/blob/main/config.json
9. facebook/MobileLLM-R1-360M-base \- Hugging Face, https://huggingface.co/facebook/MobileLLM-R1-360M-base
10. License \- facebookresearch/MobileLLM \- GitHub, https://github.com/facebookresearch/MobileLLM/blob/main/LICENSE
11. config.json · YusufBayram-Personal/facebook-MobileLLM-125M\_ag\_news\_round\_13 at 07e0c0fa7b3bc65c849838dac77bc372bca9d1fe \- Hugging Face, https://huggingface.co/YusufBayram-Personal/facebook-MobileLLM-125M\_ag\_news\_round\_13/blob/07e0c0fa7b3bc65c849838dac77bc372bca9d1fe/config.json
12. config.json · Jobfromearth/MobileLLM-80M-Finetuned at main \- Hugging Face, https://huggingface.co/Jobfromearth/MobileLLM-80M-Finetuned/blob/main/config.json
13. config.json · Qwen/Qwen2-0.5B-Instruct at 2a5861f0e6356d7f42700c80f98dd51615515b2c, https://huggingface.co/Qwen/Qwen2-0.5B-Instruct/blob/2a5861f0e6356d7f42700c80f98dd51615515b2c/config.json
14. Documentation \- MiRust, https://mirust.com/docs/
15. Llama 3.2 1B: Specifications and GPU VRAM Requirements \- ApX Machine Learning, https://apxml.com/models/llama-3-2-1b
16. Apple releases OpenELM: small, open source AI models designed to run on-device, https://venturebeat.com/ai/apple-releases-openelm-small-open-source-ai-models-designed-to-run-on-device
17. Apple OpenELM : r/LocalLLaMA \- Reddit, https://www.reddit.com/r/LocalLLaMA/comments/1cbmb0x/apple\_openelm/
18. config.json · puettmann/SmolLM2-135M-Instruct-Smol-Course at main \- Hugging Face, https://huggingface.co/puettmann/SmolLM2-135M-Instruct-Smol-Course/blame/main/config.json
19. config.json · Qwen/Qwen2-0.5B at main \- Hugging Face, https://huggingface.co/Qwen/Qwen2-0.5B/blob/main/config.json
20. config.json · allenai/OLMo-1B-hf at 428e85c69e1ffbddeba51fc4faefd96876ddcbc9 \- Hugging Face, https://huggingface.co/allenai/OLMo-1B-hf/blob/428e85c69e1ffbddeba51fc4faefd96876ddcbc9/config.json
21. meta-llama/Llama-3.2-1B at main \- Hugging Face, https://huggingface.co/meta-llama/Llama-3.2-1B/tree/main
22. LICENSE.txt · meta-llama/Llama-3.2-1B at main \- Hugging Face, https://huggingface.co/meta-llama/Llama-3.2-1B/blob/main/LICENSE.txt
23. config.json · axolotl-ai-co/tiny-llama-50m at main \- Hugging Face, https://huggingface.co/axolotl-ai-co/tiny-llama-50m/blob/main/config.json
24. config.json · maracatu-labs/maracatu-80m at main \- Hugging Face, https://huggingface.co/maracatu-labs/maracatu-80m/blob/main/config.json
25. PEFT\_tutorial.ipynb \- Colab \- Google, https://colab.research.google.com/drive/1kYa-iv6lBF4f4iwJUOZkyD75wiOjw7Fn?usp=sharing
26. config.json · Qwen/Qwen2.5-0.5B-Instruct at refs/pr/14 \- Hugging Face, https://huggingface.co/Qwen/Qwen2.5-0.5B-Instruct/blame/refs%2Fpr%2F14/config.json
27. Injecting skills into the KV cache (not as stupid as it sounds, but still pretty dumb) \- Reddit, https://www.reddit.com/r/LocalLLaMA/comments/1rif789/injecting\_skills\_into\_the\_kv\_cache\_not\_as\_stupid/?tl=en
28. FT SmolLM-135M-instruct on hf-ultrafeedback \- Kaggle, https://www.kaggle.com/code/aisuko/ft-smollm-135m-instruct-on-hf-ultrafeedback