Browser And Edge Benchmarking For Hybrid Models Without Benchmark Theater

Full report

On this page

1. Executive Benchmark Recommendation

The deployment of small language models (SLMs) to edge devices and browser environments requires rigorous, hardware-aware benchmarking that transcends raw kernel throughput. While native C++ frameworks and proprietary inference engines frequently report maximum hardware capabilities, these figures represent benchmark theater when directly extrapolated to browser-based, WebAssembly (WASM), or WebGPU runtimes. The specific operational constraints of a Rust/WASM-oriented runtime—such as the 128 MiB transfer ceiling, isolated Web Worker heaps, memory-copy overhead, and single-threaded garbage collection pauses—demand an evaluation architecture that measures the actual product experience1. This report defines a reproducible benchmark protocol designed to determine whether hybrid architectures, specifically the Liquid Foundation Models (LFM2 and LFM2.5), IBM Granite 4.0 Nano (Mamba-2 hybrids), and Gated DeltaNet variants, offer genuine, user-visible advantages over dense transformer models like Qwen2.5 within the TinyRustLM execution environment. Hybrid architectures substitute conventional self-attention in a majority of their layers with state-space models (SSMs), linear input variant (LIV) convolutions, or recurrent delta rules3. These mechanisms theoretically reduce the Key-Value (KV) cache footprint and accelerate the prefill stage by processing sequences as linear recurrences rather than quadratic attention matrices. However, algorithmic complexity reductions do not automatically yield browser-level efficiency. The proposed benchmarking protocol isolates architectural benefits from implementation artifacts by evaluating candidate models across identical runtime constraints, strictly matched quantizations, and realistic conversational context lengths. By synchronously measuring time-to-first-token (TTFT), sustained decode throughput, user interface (UI) frame-time latency, peak working set memory, and hardware energy consumption via platform counters, this protocol provides a falsifiable framework. The resulting empirical data dictates the criteria for adopting, optimizing, or rejecting specific hybrid model backends for local, privacy-preserving browser execution.

2. Candidate/Comparator and License Matrix

The evaluation targets models engineered for strict sub-2-billion parameter memory constraints. Cohorts are defined by architectural topology and active parameter memory during inference rather than superficial marketing labels, ensuring that the benchmark accurately reflects the hardware burden. The candidate cohort centers on the Liquid Foundation Models (LFM), which rely on a hybrid backbone interleaving short-range gated convolutions (LIV blocks) with a minority of Grouped Query Attention (GQA) blocks. Because LIV layers maintain a fixed-size recurrent state without a growing KV cache, the context-dependent memory footprint is substantially compressed compared to pure transformers3. The target models within this family include the LFM2.5-230M and LFM2.5-350M, specifically designed for lightweight agentic tasks, alongside the LFM2.5-1.2B-Instruct, which features 16 total layers comprising 10 double-gated LIV convolution blocks and 6 GQA blocks7. For scaling comparisons, the larger LFM2-8B-A1B is included as a Mixture-of-Experts (MoE) model possessing 8.3 billion total parameters but only 1.5 billion active parameters per token, utilizing an 18:6 ratio of LIV to GQA layers3. The LFM family operates under the LFM Open License v1.0, a dual-use commercial license based on Apache 2.0 that permits unrestricted commercial use up to a corporate revenue threshold of $10 million USD, above which a negotiated enterprise license is mandated12. Comparator Cohort A evaluates hybrid state-space models, utilizing the IBM Granite 4.0 Nano family. These models implement a 9:1 ratio of Mamba-2 layers to conventional transformer blocks, aiming to reduce long-context memory utilization by up to 70% during concurrent batching15. The benchmarking suite includes the Granite-4.0-H-350M and Granite-4.0-H-1B, both of which omit standard positional embeddings (NoPE) in favor of the implicit positioning of the Mamba-2 scan operation18. These models are licensed under the standard Apache 2.0 license. Comparator Cohort B establishes the dense transformer baseline, quantifying the computational and memory overhead of standard multi-head and grouped-query attention. This cohort includes the Qwen2.5-0.5B and Qwen2.5-1.5B architectures, which utilize Rotary Position Embeddings (RoPE) and SwiGLU activations, alongside the SmolLM2-1.7B, which employs tied embeddings across its 24 transformer layers21. Both families are licensed under Apache 2.0. Comparator Cohort C introduces experimental recurrent architectures to evaluate linear-time sequence mixing. Gated DeltaNet-2, an architecture that decouples memory erase and write operations using channel-wise gates, provides a highly precise linear recurrence without unbounded KV cache growth4. Additionally, Web-RWKV (representing the RWKV-6 architecture) provides a pure linear RNN baseline explicitly engineered for WebGPU execution27. These models operate under MIT and Apache licenses.

3. Audit of Available Public Measurements

A systematic audit of existing performance claims reveals pervasive methodological flaws that obscure the true viability of small language models in browser environments. Public benchmarks routinely suffer from a conflation of hardware capabilities, precision mismatches, and the omission of severe browser-specific bottlenecks. The primary distortion arises from conflating native execution with browser virtualization. Documentation for models like LFM2.5-230M cites decode speeds of 42 tokens per second on a Raspberry Pi 5 and 213 tokens per second on a Snapdragon 8 Elite5. However, these results rely on highly optimized native C++ binaries, such as llama.cpp, executing bare-metal SIMD instructions and accessing unified memory architecture (UMA) without inter-process communication overhead30. Projecting these figures onto a Rust/WASM implementation running inside a browser's V8 engine fundamentally ignores WebAssembly boundaries, the cost of JavaScript memory copies, and the absence of advanced vector instructions in standard WASM environments32. Furthermore, memory allocations and parsing bottlenecks are entirely ignored in native throughput tests. Native benchmarks evaluate generation speed only after the model is fully materialized in RAM and the execution context is pre-allocated. In browser ecosystems, the initialization pipeline represents a critical user experience bottleneck. Frameworks relying on ONNX Runtime Web, such as Transformers.js, exhibit initialization times exceeding 2,500 milliseconds for small models, whereas WASM bindings for llama.cpp initialize in roughly 800 milliseconds due to differing tensor mapping strategies34. Benchmarks that omit the latency of cryptographic hashing (required for verifiable execution in TinyRustLM), Web Worker heap allocation, and tokenizer deserialization fail to represent the actual product experience1. Comparative benchmarks also frequently mix unmatched quantization formats and calibration methodologies. Claiming that a hybrid architecture outperforms a dense model in throughput is scientifically invalid if the hybrid executes in an aggressive Q4\_0 (symmetric 4-bit) format while the dense model runs in unaligned 8-bit precision or utilizes differing block sizes33. Dynamic quantization applied unevenly across layer types shifts the computational bottleneck from memory bandwidth to ALU saturation unpredictably, corrupting comparative analysis. Finally, marketing materials heavily propagate context state growth fallacies. Hybrid models are frequently advertised as possessing "constant memory" due to the recurrent nature of LIV convolutions or Mamba-2 state spaces3. This assertion is demonstrably false for hybrid topologies. The LFM2-8B-A1B, for instance, retains 6 GQA layers; while its 18 LIV layers generate zero KV cache, the remaining 6 attention layers experience linear memory growth relative to context length3. Asserting absolute constant memory masks the reality of long-context exhaustion in constrained browser heaps, necessitating explicit calculations to project true peak residency and rejecting any claim of constant memory if any required component grows materially.

4. Native and Browser Workload Specification

To accurately reflect the TinyRustLM operational contract, the benchmarking suite must replicate the exact lifecycle of a model serving request, establishing both a diagnostic native ceiling and an end-to-end browser gate. The native reference benchmark serves exclusively as a diagnostic ceiling to evaluate kernel efficiency and instruction-set utilization without browser virtualization. This native executable measures tensor materialization, quantifying the speed of mapping .slm or GGUF files directly into memory from the local filesystem. It executes micro-benchmarks on specific operators—including SwiGLU activations, RoPE injections, LIV convolutions, and Mamba-2 scans—isolating cache misses and branch mispredictions. Finally, it measures the peak forward scratch utilization, determining the exact transient memory allocation required per generation step prior to any garbage collection interference1. The browser gate benchmark encompasses the complete product flow, utilizing isolated Web Workers to simulate realistic integration within a web application. The workload sequence initiates with the download or import phase, measuring the retrieval of model weights via the Fetch API or IndexedDB extraction, strictly adhering to the 128 MiB transfer ceiling constraints dictated by the TinyRustLM ABI1. Following extraction, the validation phase executes cryptographic hashing and checksum verification of the artifact. The parse and allocation phase measures the instantiation of the WebAssembly memory environment, encompassing tokenizer initialization, static tensor allocation, and the reservation of KV-cache memory blocks. Once initialized, the generation transaction begins. The first-token latency (TTFT) captures the duration from prompt submission to the rendering of the initial output token, encompassing prompt encoding and the chunked prefill pass. Steady decode evaluates the sustained autoregressive generation speed in tokens per second across multiple context depths. Long-context decode measures the performance degradation and memory spikes encountered when approaching the 8K or 32K context boundaries. The workload concludes with state teardown and cancellation, measuring the latency of safely halting the generation transaction via shared memory flags, resetting the context transcript, and entirely freeing the model from the WASM heap to return to a baseline state1.

5. Hardware, Browser, and Execution-Mode Matrix

The evaluation spans a highly constrained matrix of physical hardware, relying strictly on authorized, existing implementations. Theoretical emulations, cross-compiled QEMU runs, and datacenter hardware are strictly excluded, as they do not represent edge deployment realities. The hardware strata target specific user profiles. The low-power x64 laptop stratum, represented by hardware such as an Intel Core i5 (12th Gen) or AMD Ryzen 5 with integrated graphics and 8GB of RAM, establishes the baseline for enterprise web users. The mainstream x64 desktop stratum utilizes processors such as the AMD Ryzen 7 or Intel Core i7 with 32GB of RAM and a discrete GPU, representing the developer and power-user baseline. The physical Linux ARM64 stratum, executed on devices like the Raspberry Pi 5 or Rockchip RK3588 with 8GB of RAM, represents constrained IoT and edge computing nodes5. Mobile platforms, specifically Android environments utilizing Snapdragon 8 Gen series SoCs, are evaluated solely through native browser shells with explicit WebGPU or WASM API support5. Browser engine testing focuses primarily on Chromium/V8 (Chrome, Edge), as it dictates the dominant execution environment. The V8 engine enforces a strict 4GB memory cage limit for WebAssembly due to pointer compression constraints, heavily restricting the deployment of models larger than 2 billion parameters2. WebKit/SpiderMonkey engines are utilized solely for fallback testing to identify non-standard WebGPU shader compilation issues or varying ArrayBuffer size restrictions. Execution modes are strictly defined by existing capabilities. WebAssembly SIMD128 serves as the baseline browser execution path, requiring careful optimization of dot-product loops (e.g., q4\_0 by q8\_0 dot products) utilizing 128-bit vector registers31. WebGPU is evaluated exclusively where compute shaders for the specific hybrid architectures—such as LIV convolutions or Mamba-2 scans—are explicitly implemented and functionally stable in the browser environment37. Native CPU paths utilizing pure scalar or native SIMD (AVX2/AVX-512/NEON) establish the theoretical performance ceiling40. The runtime must define explicit feature-detection behavior, attempting WebGPU initialization and gracefully falling back to WASM SIMD128, and finally to scalar execution if advanced features are unavailable. Proprietary optimized runtimes, such as Apple MLX or NVIDIA TensorRT, serve only as external comparators and are categorically rejected as evidence for an unimplemented TinyRustLM backend.

6. Memory and Context-Growth Formulas

Browser-based AI is bounded by absolute memory ceilings, most notably the V8 engine's 4GB limit for WebAssembly heaps2. Peak resident memory must be calculated mathematically and verified empirically to prevent tab crashes. Static allocations constitute the base memory footprint. The weight memory is calculated as [Figure omitted from source export], where [Figure omitted from source export] represents the parameter count and [Figure omitted from source export] denotes the quantization bit-depth. Consequently, a 1.2 billion parameter model in a Q4\_0 format requires approximately 600 MB of committed heap space. Tokenizer initialization requires memory relative to the vocabulary size [Figure omitted from source export]; for a vocabulary of 65,536 tokens, memory encompassing Byte Pair Encoding (BPE) merges, string mappings, and trie structures typically bounds to 20-50 MB depending on the implementation1. Dynamic allocations dictate the operational stability of the model during sequence generation. Forward scratch memory accommodates intermediate tensor activations during a forward pass. In a standard TinyLM architecture, the scratch space is calculated as [Figure omitted from source export] bytes, where [Figure omitted from source export] is the hidden dimension, [Figure omitted from source export] is the feed-forward dimension, and [Figure omitted from source export] is the sequence length1. The KV cache memory ([Figure omitted from source export]) varies dramatically by architecture. For dense transformers like Qwen2.5, [Figure omitted from source export], where [Figure omitted from source export] is the number of attention layers, [Figure omitted from source export] represents the number of KV heads, and [Figure omitted from source export] represents the head dimension1. For hybrid architectures like LFM2.5, the cache is calculated solely for the GQA layers. In a 16-layer model containing 6 GQA layers, [Figure omitted from source export], substantially reducing but not eliminating context growth3. Linear recurrent layers, such as LIV or Mamba-2, require a fixed convolution/state cache independent of sequence length [Figure omitted from source export], fundamentally altering the scaling curve but still requiring persistent allocation. Browser-specific memory overhead must account for JavaScript object duplication. Buffers transferring data between the JavaScript main thread and the WASM worker duplicate memory transiently. If a 128 MiB buffer is passed, it exists in both the JavaScript heap and the WASM heap simultaneously until zero-copy transfers via SharedArrayBuffer are safely validated1. Measurement of process and browser memory relies on the performance.measureUserAgentSpecificMemory() API. This requires cross-origin isolation (COOP+COEP) and must account for the required garbage collection delay, which can pause execution for up to 20 seconds, to accurately separate committed WASM heap space from active resident memory and peak transient spikes42.

7. Context Workloads and Validation

Context workloads evaluate the model across a spectrum of real-world usage patterns, rejecting artificial benchmarks that rely solely on minimal context depths. The evaluation suite designs workloads at four distinct tiers. The short chat workload evaluates rapid generation using 128 input tokens and 64 output tokens. The moderate conversation workload simulates typical assistant usage with 1,024 input tokens and 256 output tokens. The long document workload, utilizing 8,192 input tokens and 512 output tokens, specifically tests KV cache pressure and the efficiency of chunked prefill passes. Finally, the maximum advertised length workload evaluates the model at 32,768 input tokens (where browser memory permits), testing the absolute limits of the recurrent state and attention cache3. Chunked prefill is measured across multiple context positions to determine if the architecture degrades linearly or exponentially as the context window fills. Crucially, the benchmark must verify cache/no-cache equivalence, ensuring that a generation sequence produced with an intact KV cache matches the mathematical output of a sequence generated from scratch. State reset between conversations is strictly validated; the runtime must demonstrably clear LIV state vectors, Mamba-2 hidden states, and GQA caches to prevent context contamination1. The benchmark protocol automatically rejects any claim of "constant memory" if the empirical measurements indicate that any required component, such as the GQA subset of a hybrid model, grows materially with context length3.

8. Quantization and Numerical-Fidelity Plan

Aggressive quantization allows multi-billion parameter models to execute within the strict V8 memory cage, but risks severe quality degradation. This degradation is particularly acute in hybrid architectures that rely on precise gating mechanisms, such as the multiplicative gates in LFM2.5 or the channel-wise erase/write gates in Gated DeltaNet-24. Quantization experiments are strictly limited to formats explicitly implemented within the target runtime. The benchmark mandates testing across Q8\_0, Q6\_0, Q5\_0, Q4\_0, and mixed-precision configurations. The calibration corpus and converter identity must be bound to the receipt to ensure reproducibility. The evaluation strictly prohibits selecting a precision format based solely on throughput. Quality must be measured simultaneously through multiple vectors. Artifact size and load memory evaluate the byte size on disk versus the committed WASM heap. Latency and energy establish the physical cost of generation. Numerical fidelity is quantified via logit drift, calculating the Kullback-Leibler (KL) divergence of the next-token probability distribution between the quantized output and the F32 reference output across 1,000 diverse prompts. Furthermore, a perplexity surrogate is evaluated over a fixed corpus to measure statistical degradation. Finally, product-semantic regressions are identified utilizing exact-match parsing to determine if the quantized model fails standard assistant gates—such as strict JSON formatting or precise entity extraction—that the unquantized model successfully navigates. If a hybrid model's unique activation states exhibit high sensitivity to Q4\_0 block scaling, leading to semantic failure, the architecture must be evaluated at higher precisions like Q8\_0, directly altering its comparative speed and memory footprint against more robust dense transformers1.

9. UI Responsiveness and Latency Profiling

User experience in a browser encompasses the entirety of the application, not just the background Web Worker executing the LLM. High tokens-per-second throughput is useless if the main thread is blocked, resulting in a frozen user interface. The UI responsiveness budget dictates that model execution must not interfere with a 16.6-millisecond frame time, necessary to maintain 60 frames per second. The benchmark monitors the Performance Timeline API for longtask entries, flagging any task exceeding 50 milliseconds on the main thread. Responsiveness is measured under realistic UI workloads running concurrently with the model inference. This includes streaming tokens into the Document Object Model (DOM), continuous Markdown rendering, scrolling a DOM containing over 1,000 nodes, narrow viewport reflow calculations, and background tab throttling. The benchmark also measures the impact of concurrent Service Worker activity and local-memory retrieval operations37. A critical metric is the cancellation latency: the time required for a user interruption signal to propagate to the WASM worker, halt the active generation loop, and return the thread to an idle state1. The total count of long tasks and the frame-time variance are reported alongside raw model throughput to provide a holistic view of the application's responsiveness.

10. Energy and Thermal Methodology

Mobile and laptop users operating browser-based AI are highly sensitive to battery drain and thermal throttling. The physical cost of inference must be quantified reliably. Energy telemetry utilizes the Running Average Power Limit (RAPL) interface on supported x64 hardware, reading the MSR\_PKG\_Energy\_Status and MSR\_PP0\_Energy\_Status registers48. To avoid software measurement overhead, polling is conducted at 10-millisecond intervals via a lightweight, root-privileged native daemon, rather than attempting higher-frequency reads that perturb the CPU state. Accurate measurement requires strict isolation protocols. An idle baseline is recorded for 60 seconds prior to execution. This idle baseline is mathematically subtracted from the active execution power to isolate the specific energy cost of the LLM workload. Tests are executed in both a "cold state" (capturing initial burst performance) and a "thermal steady state" (measured after 5 minutes of continuous token generation) to identify hardware throttling profiles. Battery mode is strictly enforced during mobile and laptop evaluations. The primary metric reported is the Total Joules per Completed Answer for specific context workloads, accompanied by 95% confidence intervals across multiple iterations. The protocol strictly forbids converting vendor sustainability language into measured claims; only empirical silicon measurements are accepted.

11. Statistical Design and Reproducible Receipt Schema

To prevent cherry-picking and ensure verifiable reproducibility across the open-source and enterprise ecosystem, every benchmark run must automatically generate a cryptographic receipt. The execution protocol mandates that each workload is repeated a minimum of five times. The initial run is strictly categorized as a "warmup" and excluded from latency and throughput averages to account for browser Just-In-Time (JIT) compilation, WebGPU shader compilation jitter, and initial memory page-faulting33. To effectively filter out unpredictable system noise—such as V8 garbage collection pauses or operating system background tasks—the benchmark applies a Hampel filter to the latency stream. By calculating the Median Absolute Deviation (MAD), the filter identifies and removes latency outliers that deviate significantly from the median generation time. To ensure this filtering does not introduce excessive processing overhead during real-time benchmarking, a modified Hampel filter utilizing an [Figure omitted from source export] complexity estimator (mMAD) is employed, preserving statistical robustness while minimizing computational latency53. The resulting JSON receipt must capture the immutable identity of the entire execution stack:

JSON { "timestamp\_utc": "2026-07-15T11:47:48Z", "hardware": { "cpu": "AMD Ryzen 7 7840U", "ram\_gb": 32, "os": "Linux x64", "power\_mode": "battery" }, "browser": { "engine": "V8", "version": "Chrome 126", "flags": \["--enable-features=WebAssemblySimd"\] }, "runtime": { "commit\_hash": "a1b2c3d4", "execution\_path": "WASM\_SIMD128", "thread\_count": 4 }, "model": { "name": "LFM2.5-350M", "architecture": "hybrid\_liv\_gqa", "quantization": "Q4\_0", "artifact\_hash": "sha256:8f3a..." }, "workload": { "type": "moderate\_conversation", "input\_tokens": 1024, "output\_tokens": 256 }, "results": { "load\_allocation\_ms": 845, "ttft\_ms": 412, "decode\_tok\_sec": 22.4, "peak\_wasm\_heap\_mb": 415, "energy\_joules\_per\_token": 0.45, "ui\_long\_tasks": 2, "outliers\_removed\_hampel": 1 }, "status\_code": "SUCCESS" }

Failed runs, such as out-of-memory crashes or the generation of degenerate text loops, must be preserved in the dataset with their corresponding failure codes. Superseded runs must remain in the historical archive to map the boundaries of the execution envelope1.

12. Predeclared Decision Thresholds and Stop Rules

To eliminate confirmation bias, strict numerical thresholds for implementing, heavily optimizing, or outright rejecting an architecture must be established before observing the benchmark results. A candidate architecture will be categorically rejected from TinyRustLM production integration if it violates any of the following stop rules during browser execution on the target low-power hardware stratum:

1. First-Token Latency: TTFT exceeds 1,500 milliseconds for a 1,024-token input prompt.
2. Sustained Decode: Generation throughput drops below 12 tokens per second (the functional minimum for average reading speeds).
3. Peak Memory: The committed WASM heap exceeds 2.5 GB for a 350M–1B parameter model at 8K context, introducing a severe risk of browser tab eviction.
4. UI Interference: The main thread registers more than three longtasks (\>50ms) during a 256-token generation sequence.
5. Numerical Parity: Logit drift in Q4\_0 format results in a semantic failure rate \>10% on internal reasoning gates compared to the F32 baseline.

Conversely, an architecture justifies the implementation-maintenance cost of building custom WASM or WebGPU kernels (e.g., custom LIV convolution operators or Mamba-2 parallel scans) if it demonstrates a [Figure omitted from source export] reduction in peak memory at 8K context compared to a dense transformer of identical active parameter count, paired with a [Figure omitted from source export] reduction in energy consumption ([Figure omitted from source export]) under sustained decode, while maintaining numerical parity.

13. Annotated Primary-Source Bibliography

The architectural definitions, memory constraints, and performance baselines utilized to construct this benchmark protocol are synthesized from a precise review of primary technical literature and system documentation. The evaluation of hybrid topologies is heavily informed by the LFM2 Technical Report and associated release documentation. These sources explicitly define the Liquid Foundation Models as hybrid structures, specifically outlining the 10:6 or 18:6 ratio of Linear Input Variant (LIV) convolution blocks to Grouped Query Attention (GQA) blocks7. This architectural detail is critical for memory planning, confirming that LFMs are not strictly "zero-cache" models, but rather possess a highly compressed KV cache that scales with context length3. Similarly, technical releases for the IBM Granite 4.0 Nano family confirm the integration of Mamba-2 SSM layers alongside transformer blocks, establishing a 9:1 SSM-to-Attention ratio designed to mitigate memory usage for edge deployments16. The inclusion of linear-attention comparators is grounded in the Gated DeltaNet-2 research literature. This documentation outlines the mechanism of decoupling erase and write operations through channel-wise gates, replacing softmax attention with linear-time recurrence, thereby providing the mathematical foundation for evaluating alternative recurrent state models4. The strict constraints placed on the browser execution environment are derived from W3C specifications and Chromium engine documentation. These sources dictate the 4GB WebAssembly heap cage caused by V8 pointer compression, and define the asynchronous, garbage-collection-dependent nature of the performance.measureUserAgentSpecificMemory() API2. Furthermore, TinyRustLM operational handbooks define the strict 128 MiB boundary for memory transfers, the necessity of single-global runtime mutexes, and the exact staging of the model-load transaction, which directly shape the browser workload specification1. Finally, the statistical and physical measurement methodologies rely on validation studies of Intel's Running Average Power Limit (RAPL) interface, which establish it as a highly accurate tool for software-based energy estimation provided that idle subtraction is rigorously applied to isolate workload consumption48. To ensure the integrity of latency measurements against system noise, the protocol incorporates the Hampel filter for outlier detection, specifically utilizing the modified mMAD estimator to achieve [Figure omitted from source export] computational complexity, as detailed in recent time-series analysis literature53.

Works cited

1. Implementation operations \- MiRust, https://mirust.com/implementation-operations/
2. Electron and the V8 Memory Cage, https://electronjs.org/blog/v8-memory-cage
3. Deploy Liquid AI LFM2 Models (LFM2-8B-A1B, LFM2-2.6B) on GPU Cloud: Hybrid Architecture Guide (2026) | Spheron Blog, https://www.spheron.network/blog/liquid-foundation-models-lfm-deployment-gpu-cloud-2026/
4. Gated DeltaNet-2: Decoupling Erase and Write in Linear Attention \- arXiv, https://arxiv.org/html/2605.22791v1
5. LFM2.5-230M: Built to Run Anywhere — Blog \- Liquid AI, https://www.liquid.ai/blog/lfm2-5-230m
6. Liquid AI LFM2.5-1.2B-Thinking: Compact Power \- HowAIWorks.ai, https://howaiworks.ai/blog/liquidai-lfm2-5-1-2b-thinking-release
7. Liquid Foundation Models, https://www.liquid.ai/models
8. lfm2.5-thinking \- Ollama, https://ollama.com/library/lfm2.5-thinking
9. Fine-Tuning Liquid's LFM2.5: Accurate Tool Calling at 350M Parameters \- distil labs, https://www.distillabs.ai/blog/fine-tuning-liquids-lfm25-accurate-tool-calling-at-350m-parameters/
10. LiquidAI/LFM2.5-230M \- Hugging Face, https://huggingface.co/LiquidAI/LFM2.5-230M
11. Liquid API and Models \- OpenRouter, https://openrouter.ai/liquid
12. LFM License | Liquid AI, https://www.liquid.ai/lfm-license
13. Model License \- Liquid Docs, https://docs.liquid.ai/lfm/help/model-license
14. Liquid AI's smallest model yet LFM2.5-230M beats models 4X its size at data extraction, can run 'anywhere' | VentureBeat, https://venturebeat.com/technology/liquid-ais-smallest-model-yet-lfm2-5-230m-beats-models-4x-its-size-at-data-extraction-can-run-anywhere
15. Running Granite 4 Language Models with Ollama \- Niklas Heidloff, https://heidloff.net/article/granite-ollama/
16. Deploy IBM Granite 4.0 models on Amazon SageMaker AI | IBM & Red Hat on AWS, https://aws.amazon.com/blogs/ibm-redhat/deploy-ibm-granite-4-0-models-on-amazon-sagemaker-ai/
17. Granite 4.0 \- IBM, https://www.ibm.com/granite/docs/models/granite
18. ibm-granite/granite-4.0-h-350m-base \- Hugging Face, https://huggingface.co/ibm-granite/granite-4.0-h-350m-base
19. ibm-granite/granite-4.0-h-350m \- Hugging Face, https://huggingface.co/ibm-granite/granite-4.0-h-350m
20. IBM AI Team Releases Granite 4.0 Nano Series: Compact and Open-Source Small Models Built for AI at the Edge \- MarkTechPost, https://www.marktechpost.com/2025/10/29/ibm-ai-team-releases-granite-4-0-nano-series-compact-and-open-source-small-models-built-for-ai-at-the-edge/
21. Qwen2.5-1.5B: Specifications and GPU VRAM Requirements \- ApX Machine Learning, https://apxml.com/models/qwen2-5-1-5b
22. Qwen2.5-0.5B: Specifications and GPU VRAM Requirements \- ApX Machine Learning, https://apxml.com/models/qwen2-5-0-5b
23. SmolLM2 Family: High-Performance Compact LMs \- Emergent Mind, https://www.emergentmind.com/topics/smollm2-family
24. Qwen/Qwen2.5-1.5B-Instruct \- Hugging Face, https://huggingface.co/Qwen/Qwen2.5-1.5B-Instruct
25. Gated DeltaNet: The “Surgical Eraser” Solving Linear Attention's Memory Problem | by Revanth Madamala | Towards AI, https://pub.towardsai.net/gated-deltanet-the-surgical-eraser-solving-linear-attentions-memory-problem-1e50ca3e42ab
26. Gated DeltaNet-2: Decoupling Erase and Write in Linear Attention \- arXiv, https://arxiv.org/pdf/2605.22791
27. GitHub \- cryscan/web-rwkv: Implementation of the RWKV language model in pure WebGPU/Rust., https://github.com/cryscan/web-rwkv
28. Ai00 Inference \- RWKV Language Model, https://wiki.rwkv.com/inference/ai00.html
29. A Survey of RWKV \- arXiv, https://arxiv.org/html/2412.14847v1
30. LFM-2.5 230M : Best Small LLM for Mobile Phones | by Mehul Gupta | Data Science in Your Pocket | Jun, 2026 | Medium, https://medium.com/data-science-in-your-pocket/lfm-2-5-230m-best-small-llm-for-mobile-phones-8924cbb4d691
31. Simon Willison on llama-cpp, https://simonwillison.net/tags/llama-cpp/
32. Overall performance limits · huggingface ratchet · Discussion \#200 \- GitHub, https://github.com/huggingface/ratchet/discussions/200
33. Llamas on the Web: Memory-Efficient, Performance-Portable, and Multi-Precision LLM Inference with WebGPU \- arXiv, https://arxiv.org/html/2605.20706v1
34. Wllama, https://mikeesto.com/posts/wllama/
35. Liquid Foundation Models: Our First Series of Generative AI Models — Blog, https://www.liquid.ai/blog/liquid-foundation-models-our-first-series-of-generative-ai-models
36. ngxson/wllama: WebAssembly binding for llama.cpp \- Enabling on-browser LLM inference · GitHub, https://github.com/ngxson/wllama
37. WebLLM: Run LLMs in Your Browser at 80% Native Speed (2026) | Local AI Master, https://localaimaster.com/blog/webllm-browser-ai-guide
38. WebGPU: Run AI Models in the Browser With No Backend \- Noqta – AI Agents from $5, https://noqta.tn/en/blog/webgpu-ia-navigateur-inference-locale-sans-serveur-2026
39. Llamas on the Web \- Reese Levine, https://reeselevine.github.io/llamas-on-the-web/
40. LLama.cpp smillar speed but in pure Rust, local LLM inference alternatives. \- Reddit, https://www.reddit.com/r/LocalLLaMA/comments/1jh4s2h/llamacpp\_smillar\_speed\_but\_in\_pure\_rust\_local\_llm/
41. unsloth/LFM2-1.2B \- Hugging Face, https://huggingface.co/unsloth/LFM2-1.2B
42. performance.measureUserAgentSpecificMemory() \- Chrome Platform Status, https://www.chromestatus.com/feature/5685965186138112
43. Performance: measureUserAgentSpecificMemory() method \- Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/Performance/measureUserAgentSpecificMemory
44. Monitor your web page's total memory usage with measureUserAgentSpecificMemory() | Articles, https://web.dev/articles/monitor-total-page-memory-usage
45. Liquid LFM2.5: How To Run & Fine-tune | Unsloth Documentation, https://unsloth.ai/docs/models/tutorials/lfm2.5
46. Gated DeltaNet for Linear Attention \- rasbt/LLMs-from-scratch \- GitHub, https://github.com/rasbt/LLMs-from-scratch/blob/main/ch04/08\_deltanet/README.md
47. The Complete Guide to Local-First AI: WebGPU, Wasm, and Chrome's Built-in Model, https://daily.dev/posts/the-complete-guide-to-local-first-ai-webgpu-wasm-and-chrome-s-built-in-model-hucbit41f
48. A Validation of DRAM RAPL Power Measurements \- ResearchGate, https://www.researchgate.net/publication/310823713\_A\_Validation\_of\_DRAM\_RAPL\_Power\_Measurements
49. Red Alert for Power Leakage: Exploiting Intel RAPL-Induced Side Channels \- of Zhenkai Zhang, https://zhenkai-zhang.github.io/papers/rapl.pdf
50. Running Average Power Limit Energy Reporting CVE-2020-8694,... \- Intel, https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/running-average-power-limit-energy-reporting.html
51. Dissecting the software-based measurement of CPU energy consumption: a comparative analysis \- arXiv, https://arxiv.org/pdf/2401.15985
52. Inconsistent / Non-linear GPU performance scaling across different hardware (tokens/sec benchmark) · Issue \#773 · mlc-ai/web-llm \- GitHub, https://github.com/mlc-ai/web-llm/issues/773
53. A Novel Approach to Speed Up Hampel Filter for Outlier Detection \- ResearchGate, https://www.researchgate.net/publication/392091992\_A\_Novel\_Approach\_to\_Speed\_Up\_Hampel\_Filter\_for\_Outlier\_Detection
54. A Novel Approach to Speed Up Hampel Filter for Outlier Detection \- PMC \- NIH, https://pmc.ncbi.nlm.nih.gov/articles/PMC12157161/
55. A Novel Approach to Speed Up Hampel Filter for Outlier Detection \- PubMed, https://pubmed.ncbi.nlm.nih.gov/40968853/
56. LFM2-24B-A2B: Scaling Up the LFM2 Architecture — Blog \- Liquid AI, https://www.liquid.ai/blog/lfm2-24b-a2b
57. \[2511.23404\] LFM2 Technical Report \- arXiv, https://arxiv.org/abs/2511.23404
58. LFM2 Technical Report \- arXiv, https://arxiv.org/html/2511.23404v1
59. WICG/performance-measure-memory: performance.measureMemory API \- GitHub, https://github.com/WICG/performance-measure-memory