Architecture Portfolio, Licensing, And Build-Versus-Port Decision

Full report

On this page

1. Executive Build-Versus-Port Recommendation

The strategic imperative for the TinyRustLM project is to deliver a highly reliable, provenance-bound catalog of twenty genuinely distinct local model artifacts without accumulating an unsustainable architectural maintenance burden. Based on an exhaustive evaluation of current compact dense models, sparse mixture-of-experts (MoE) topologies, and emerging hybrid architectures—including Linear Input-Varying (LIV) convolutions and state-space models (SSMs)—the optimal path forward is the adoption of a strict external-backend boundary combined with a portfolio exclusively composed of OSI-approved open-source artifacts. The analysis indicates that attempting to natively implement and optimize every emerging architectural paradigm directly within a pure-Rust WebGPU or WebAssembly (Wasm) runtime will lead to immediate and paralyzing technical debt. The landscape of compute kernels is rapidly bifurcating. Architectures such as the Liquid Foundation Models (LFM) rely on specialized convolutional gating1, Falcon-H1 utilizes parallel Mamba-2 blocks2, and RWKV depends on custom Receptance Weighted Key Value operators3. Replicating these specialized operations in WGSL (WebGPU Shading Language) requires constant tuning to prevent precision drift and severe memory bottlenecks4. Therefore, isolating a mature, highly optimized external backend, such as a Wasm-compiled C++ execution graph like llama.cpp or Apache TVM, behind a strict Foreign Function Interface (FFI) provides the highest return on investment. This porting strategy delegates the brutal reality of multi-architecture compute optimization to broader, better-funded community projects, allowing the TinyRustLM engineering team to focus exclusively on cross-platform sandboxing, cryptographic provenance, and artifact curation. Furthermore, a rigorous audit of the licensing landscape reveals that non-standard, revenue-capped licenses introduce existential supply-chain and redistribution risks for a peer-to-peer (P2P) artifact network. Specifically, the LFM Open License v1.0 and the TII Falcon License 2.0 contain commercial revenue caps and royalty triggers that fundamentally contradict the principles of permissionless redistribution5. Consequently, LFM2.5 and Falcon-H1 must be rejected or deferred for general redistribution within the TinyRustLM catalog. The initial portfolio must be reserved exclusively for models carrying unambiguous Apache-2.0 or MIT licenses, such as the SmolLM2, Qwen2.5, and Granite 3.0 families, ensuring that network node operators are shielded from inadvertent contributory copyright infringement7.

2. Revision-Pinned Architecture and Model Matrix

To construct a robust and legally compliant portfolio, candidate models must be evaluated not only on raw parameter counts but on their active inference constraints, context caching asymptotics, and legal redistributability. The following matrix details the most viable compact models available at the retrieval date of July 2026, pinned to their specific architectural implementations.

The selection represented in this matrix deliberately separates theoretical architectures from measurable execution profiles. For instance, the Granite-3.0-1B-A400M utilizes a sparse mixture-of-experts topology, allowing it to house one billion total parameters while only activating 400 million during any single forward pass, dramatically reducing memory bandwidth pressure on constrained edge devices9. Conversely, hybrid models like the LFM2.5 and Falcon-H1 boast exceptional context windows by minimizing the growth of the traditional Key-Value cache, but their non-standard licenses trigger the "Restricted" status, demanding careful scrutiny before integration14.

3. Product-Relevant Architecture Comparison

The physical architecture of a neural network determines its viability within a highly constrained browser-based, WebAssembly, or WebGPU runtime environment. Evaluated strictly on the parameters of edge deployment—prefill latency, decode throughput, context memory scaling, and quantization maturity—the architectural landscape diverges sharply between traditional dense models and emerging hybrid structures. Dense transformer architectures, represented by the Qwen2.5 and SmolLM2 families, rely entirely on global self-attention mechanisms7. This mathematical structure exhibits a computational complexity of [Figure omitted from source export] during the prefill phase and a memory complexity of [Figure omitted from source export] for the Key-Value (KV) cache during generation. While these asymptotics appear highly unfavorable for processing vast documents, the measured reality for local browser-based chat is remarkably forgiving. For context windows ranging from 2,000 to 8,000 tokens, the browser kernel complexity for standard transformers is deeply mature. Libraries utilizing WebGPU compute shaders have heavily optimized standard matrix-vector multiplications, resulting in highly deterministic implementations across quantized precision tiers4. Hybrid architectures attempt to shatter the memory wall associated with the KV cache by integrating alternative sequence mixing mechanisms. The LFM2.5 family utilizes Linear Input-Varying (LIV) convolutions intertwined with Grouped Query Attention (GQA) blocks1. In the LFM2.5-230M and larger variants, roughly 75% of the network layers rely on convolution, which maintains an [Figure omitted from source export] recurrent state. Because these layers do not attend to past tokens, they generate no KV cache whatsoever. The remaining 25% of the layers utilize GQA to preserve long-range coherence, resulting in a hybrid cache footprint that is substantially smaller than a dense transformer of equivalent size21. At a 32,000-token context window, a pure 7-billion parameter transformer requires approximately 8.6 gigabytes of VRAM strictly for the KV cache, effectively overwhelming standard integrated graphics21. A hybrid model sidesteps this hardware limitation entirely, achieving impressive decode speeds such as 213 tokens per second on smartphone processors15. The Falcon-H1 architecture approaches the problem differently by deploying a parallel hybrid design. Rather than alternating layer types, Falcon-H1 runs a Mamba-2 State Space Model head and a standard attention head simultaneously within the same core processing block, concatenating their outputs before the feed-forward projection2. This allows the network to leverage the constant-time inference of the Mamba state while retaining the precise targeting of attention, allowing contexts up to 256,000 tokens2. Despite these operational advantages, supporting hybrid and recurrent architectures presents an extreme implementation cost for a native Rust deployment platform. A pure WebGPU and Wasm environment requires highly specialized WGSL compute shaders. While standard matrix multiplication maps cleanly to WebGPU primitives, implementing custom Mamba-2 parallel scan kernels, RWKV WKV operators, or LIV convolutions introduces profound maintenance risks3. Relying on upstream projects to provide these specialized kernels forces the platform to inherit their undiscovered bugs, numerical precision drift, and slow update cycles. Furthermore, behavioral mechanics such as multi-turn state resetting differ radically; clearing the hidden state of an RNN-like architecture requires careful memory management distinct from simply flushing a KV cache buffer. Similarly, tool-calling syntax varies wildly—LFM2.5 relies on proprietary Pythonic lists wrapped in \<|tool\_call\_start|\> tokens, while Qwen2.5 reliably outputs structured JSON8. Attempting to normalize these distinct architectural quirks natively would easily exhaust the resources of a small engineering team.

4. License and Derivative-Artifact Issue Matrix

The licensing landscape for compact language models has recently bifurcated into genuine open-source frameworks, which comply with the Open Source Initiative (OSI), and dual-use "open-weight" commercial licenses. For a product designed around peer-to-peer (P2P) model-byte redistribution, non-standard licenses introduce unacceptable operational and legal liability. The LFM Open License v1.0, governing the Liquid Foundation Models, is publicly described by its authors as being "Apache Based," but it includes a severe structural deviation: Section 5 imposes a strict "Commercial Use Limitation"5. If a user or the legal entity operating the model exceeds $10 million in annual revenue, their right to use the model for commercial purposes terminates immediately, and they are legally compelled to negotiate a paid enterprise agreement23. While the license lacks a copyleft requirement—meaning users are not forced to open-source their fine-tuned derivatives—the commercial revenue cap adheres to the artifact like a contagion23. Any derived artifact, whether it is a quantized .slm variant, a LoRA merged adaptation, or a distilled student model trained directly on the teacher's outputs, inherits this revenue limitation23. The TII Falcon License 2.0, which governs the Falcon-H1 and Falcon 3 families, is even more restrictive. Section 8 of the license imposes a 10% royalty on commercial revenue exceeding $1 million USD6. The Open Source Initiative and the Free Software Foundation strictly classify this as a non-free, proprietary license because it discriminates against specific fields of endeavor and imposes involuntary financial obligations on downstream users25. In a decentralized P2P network, a central metadata authority cannot practically enforce or audit downstream corporate revenue to ensure that the Technology Innovation Institute receives its mandated 10% royalty. This introduces a catastrophic contagion risk for P2P distribution topologies. If a compliant, low-revenue node automatically peers a restricted artifact to an enterprise node that happens to exceed the revenue threshold, the legal liability regarding contributory copyright infringement becomes highly volatile. Furthermore, the LFM license includes an aggressive patent termination clause in Section 3, which revokes all granted patent licenses if the user institutes any patent litigation against any entity regarding the model—a scope significantly broader than the defensive termination clause found in the standard Apache-2.0 text23. Therefore, genuine Apache-2.0 models, such as the Qwen, SmolLM, and Granite families, represent the only legally sound foundation for a permissionless artifact network. These licenses grant perpetual, royalty-free, and irrevocable rights for all commercial use, wholly unencumbered by revenue auditing or proprietary royalties8. Derivative artifacts, tokenizers, and model cards can be freely redistributed without complex legal tracking. Consequently, restricted licenses must be aggressively excluded from the standard catalog, distinguishing clearly between the permissive licensing of the inference code and the prohibitive licensing of the mathematical model weights.

5. Provenance, SBOM, and Revocation Design

Machine learning supply chains face unique cryptographic vulnerabilities that traditional software distribution mechanisms fail to address. Poisoned training data, compromised adapter merges, or maliciously altered quantized weights can entirely compromise the integrity and safety of local execution27. In a P2P artifact network, relying solely on a generic model name or a mutable URL is architecturally negligent. The platform must adopt a framework akin to the Model Bill of Materials with PQC-safe extensions (MBOM-PQC) to guarantee verifiable lineage and cryptographic durability27. The provenance controls must enforce strict immutability across the entire supply chain. Models must never be referenced by floating tags, such as main or latest. Every catalog entry must bind to a specific, immutable Git commit hash, preventing upstream maintainers from silently replacing model weights. When model bytes are transferred via the P2P network, Large File Storage (LFS) identities must be verified locally using SHA-256 streaming hashes. If a byte mismatch occurs during the chunked transfer, the client must terminate the connection instantly, preventing the ingestion of a potentially poisoned artifact. A cryptographically signed Software Bill of Materials (SBOM) must accompany every .slm or .gguf artifact. This manifest must exhaustively document the entire conversion pipeline, explicitly stating the converter version utilized (e.g., llama.cpp commit \#b7633), the exact tokenizer template identity, and the precise quantization parameters applied30. This ensures that if a specific quantization methodology is later found to induce severe perplexity degradation, the affected artifacts can be systematically identified and deprecated. Furthermore, the original license text must be hashed and stored within the manifest. If an upstream repository mutates its license in a subsequent commit—a common occurrence in the modern AI landscape—the existing catalog entry remains legally bound to the historical, permissive hash. To handle critical failures, the central metadata authority must possess revocation and supersession capabilities. If a model is found to contain embedded malware, severe prompt-injection vulnerabilities, or illicit material in its training data, the authority must issue a signed revocation payload. The P2P network protocol must automatically recognize this payload, tombstone the artifact's execution privileges, and prompt the user with a cryptographic "Quality Receipt" explaining the exact reason for the supersession.

6. Platform-Strategy Comparison

The core architectural decision for TinyRustLM rests on how the runtime computing environment is structured and isolated. Evaluating the platform strategy requires balancing the size of the Trusted Computing Base (TCB), cross-browser availability, API drift, and the overwhelming testing burden of maintaining edge hardware compatibility. Four distinct strategies emerge: The first strategy is Dense-Only Optimization. This involves maintaining custom WebGPU WGSL shaders in native Rust exclusively for standard dense transformers. This ensures a minimal TCB, high security sandboxing, and strict numerical determinism. However, it permanently locks the platform out of highly efficient MoE architectures (like Granite) and memory-efficient hybrid models, leaving edge users with inferior power-to-performance ratios and rapid battery drain on mobile devices. The second strategy is providing First-Class LFM2 Support natively. This requires writing bespoke WGSL code for LIV convolutions and dynamic GQA blocks. The implementation cost is extraordinarily high, and it expends core engineering capital on an architecture that is legally encumbered by a proprietary, revenue-capped license5. Investing native Rust development hours into a non-free architecture constitutes a fundamental misallocation of resources. The third strategy involves Multiple Native Architecture Plugins. This attempts to build a modular Rust interface where community contributors write custom WebGPU shaders for RWKV, Mamba, LFM, and Dense models independently. This approach results in severe sandboxing nightmares, untestable precision drift across different hardware backends, and a massive supply-chain risk as unvetted community shaders are granted direct execution access to user GPUs. The fourth strategy is establishing a Strict External-Backend Boundary. This involves compiling a mature C++ inference engine, such as llama.cpp, to WebAssembly, optionally utilizing WebGPU extensions via Emscripten or the rapidly maturing Wasm Component Model32. The Wasm sandbox strictly isolates the C++ memory space, preserving security while delegating the entire matrix of architectural support to a massive open-source community30. With the advent of Wasm 2.0, the introduction of 128-bit SIMD instructions and multi-value returns ensures that Wasm-compiled backends can achieve highly competitive latency on edge CPUs32. The analysis strongly dictates the adoption of the Strict External-Backend Boundary. While it slightly increases the initial package size and introduces a dependency on external API drift, the alternative—manually tracking and implementing every weekly architectural fad in custom Rust code—is a guaranteed path to platform stagnation and eventual abandonment.

7. Weighted Decision Model and Sensitivity Analysis

To mathematically validate the strategic recommendation, a structured decision matrix evaluates the four platform options across critical engineering and product dimensions. The scores reflect theoretical maximums out of 10 points.

Applying various weighting profiles reveals the sensitivity of the decision to differing strategic priorities: In the Base Scenario, which balances quality, memory, and implementation cost, the Strict External-Backend wins decisively with a score of 8.45, followed by Dense-Only at 7.95. Native approaches for hybrid models fail utterly due to extreme implementation costs and maintenance risks. In a License-Strict Profile, where license usability is heavily weighted at 40% to account for P2P legal liabilities, Dense-Only Native scores 8.65, narrowly beating the Strict External-Backend at 8.30. Native LFM collapses to a score of 4.70 due to the catastrophic $10M revenue cap and patent traps. In a Frugal / Low-Maintenance Profile, where implementation cost and maintenance risk are prioritized for a small engineering team, the Strict External-Backend wins with 8.55. Delegating the maintenance of highly specific SIMD instructions, MoE routing, and KV-cache optimizations to the vast llama.cpp upstream community is the only mathematically viable route for long-term survival.

8. Meaningful 1-, 5-, and 20-Model Portfolio Plan

Achieving a 20-artifact catalog through alias padding, identical weights with different metadata, or slight parameter tweaking is catalog theater. Meaningful diversity demands unique computational profiles, specific task specializations, and linguistic optimizations, ensuring users receive measurable utility from each downloaded byte. The One-Model Foundation must be the safest, most stable artifact available to test the deployment pipeline. The selection for this stage is the SmolLM2-135M-Instruct. At just 135 million parameters, it is the ultimate baseline10. Its unequivocal Apache-2.0 license, deep instruction tuning through Direct Preference Optimization (DPO), and flawless integration with existing transformer pipelines provide a highly stable testing ground for the external-backend FFI boundary and P2P streaming mechanisms. The Five-Model Utility Core expands the offering to provide genuine everyday value without overwhelming the user's storage. The selections include:

1. SmolLM2-135M-Instruct: The ultra-lightweight baseline.
2. Qwen2.5-0.5B-Instruct: A highly competent, multilingual chat model that maximizes the utility of half a billion parameters12.
3. Qwen2.5-Coder-0.5B: An independently trained behavioral variant specializing in code generation and logical reasoning19.
4. Granite-3.0-1B-A400M-Instruct: A Sparse MoE model that provides the knowledge capacity of a 1-billion parameter network while executing at the speed of a 400-million parameter model, ideal for CPU-bound devices9.
5. SmolLM2-1.7B-Instruct: A larger dense model trained on an 11-trillion token base, capable of complex reasoning and multi-turn state retention7.

To reach the 20-Artifact Genuine Portfolio, expansion must rely on quantifiable utility. This includes admitting quantized variants optimized for distinct hardware profiles (e.g., INT4 for low-memory browser environments, BF16 for high-fidelity extraction on discrete GPUs). The catalog will also incorporate task specialists, such as independently trained adapter merges for structured JSON extraction. To enter the catalog, a new variant must mathematically outperform the 5-model core on a specific, reproducible benchmark—such as IFEval for instruction following or BFCLv3 for tool calling—ensuring that every addition benefits the end user31.

9. Cheapest Uncertainty-Reduction Experiments

Before committing extensive engineering hours to integrating Wasm and WebGPU kernels, the project must execute highly targeted, low-cost experiments to resolve the largest architectural uncertainties. The first experiment is the Vertical-Slice Conversion. The team must manually compile llama.cpp to WebAssembly using Emscripten, enabling WebGPU support, and load the Qwen2.5-0.5B .gguf file in a local browser environment. The objective is to measure the initialization time, binary size, and memory overhead within a Chromium sandbox. If the memory bloat introduced by the Wasm translation layer exceeds 20% of the native binary footprint, the external-backend strategy must be heavily scrutinized before full integration. The second experiment is the Scalar Layer Parity Test. To ensure mathematical determinism, the team must execute a single forward pass of the SmolLM2-135M attention layer in native Rust, and strictly compare the resulting tensor logits against the outputs from the Wasm-compiled backend. Variations exceeding a [Figure omitted from source export] tolerance indicate critical floating-point discrepancies or precision loss within the Wasm environment, which will compound into severe hallucination during multi-turn chat generation. The third experiment requires a formal License Review. The team must submit the LFM Open License v1.0 and the TII Falcon License 2.0 to qualified intellectual property counsel. The specific question to resolve is whether the automated P2P transfer of restricted weights from a compliant sub-$10M node to a non-compliant enterprise node exposes the network protocol authors or the seeding node to contributory copyright infringement liability.

10. Go, Defer, Reject, and Reconsideration Triggers

Establishing explicit admission conditions prevents the catalog from becoming polluted by hype-driven, unmaintainable architectures. The GO condition applies to the Qwen2.5, SmolLM2, and Granite 3.0 MoE families. The admission condition is met because these artifacts are fully open under OSI-approved licenses (Apache 2.0), fall within the 0.1B to 2B active parameter range, demonstrate state-of-the-art instruction following, and execute flawlessly on standard external backends without requiring proprietary compute kernels. A DEFER decision applies to the LFM2.5 family. While the architecture is exceptionally efficient—achieving 213 tokens per second on mobile hardware14—the $10M commercial limitation and the required structural backend updates present severe friction5. The explicit reconsideration trigger for LFM2.5 is dual-fold: Liquid AI must formally re-license the weights under a genuine OSI-approved license, and the llama.cpp upstream community must merge fully stable, cross-platform Wasm/WebGPU kernels for the LIV convolution blocks that pass scalar parity tests. A DEFER decision also applies to the RWKV-6 and RWKV-7 families. Although true [Figure omitted from source export] memory state is theoretically perfect for edge deployment3, WebGPU support for the custom WKV operators remains highly experimental37. The reconsideration trigger requires a standardized, high-performance WebGPU implementation of RWKV to be merged into the primary external backend, accompanied by reproducible quality metrics that demonstrably exceed Qwen2.5 at the 0.1B to 0.5B parameter scale. A REJECT decision is issued for the Falcon-H1 and Falcon 3 families. The TII Falcon License 2.0 imposes an unavoidable 10% commercial royalty on revenue over $1 million6. This is an irreconcilable poison pill for a decentralized, permissionless deployment platform, as there is no programmatic method to ensure downstream nodes comply with continuous financial auditing.

11. Twelve-Month Technology-Watch Plan

The strategic landscape of local edge inference will mutate rapidly. To maintain platform relevance, the project must track specific, immutable observations rather than industry hype over the next twelve months. First, the team must monitor Wasm 2.0 and WebGPU Maturation. Track the exact adoption rates of Wasm 128-bit SIMD instructions (Phase 5\) and multi-value returns across major browser engines, including V8, SpiderMonkey, and JavaScriptCore32. Additionally, monitor the rollout of native FP16 support within WGSL compute shaders, which will dramatically reduce prefill latency for dense models without requiring complex integer quantization. Second, observe Quantization Standardization. Track the evolution of the .gguf specification and the emergence of sub-4-bit and micro-scaled quantization methods, such as IQ2\_XXS and MXFP838. The technology watch must evaluate whether these extreme compression formats maintain acceptable perplexity and instruction-following fidelity at the 1B parameter scale, or if they destroy the model's fundamental reasoning capabilities. Third, maintain a vigilant watch on License Attrition. Corporate entities frequently pivot their licensing strategies based on market capture. If entities like Microsoft, Alibaba, or IBM retroactively apply "Acceptable Use" commercial caps to future revisions of their models, the platform must rely on the immutable cryptographic hashes of their earlier Apache-2.0 releases. Security advisories regarding data poisoning must be tracked, but a changed artifact must never be automatically admitted without passing the rigorous MBOM-PQC hash verification process.

12. Unknowns Requiring Local Evaluation, Counsel, or Deployment Access

A fully mature deployment strategy must acknowledge existing blind spots that cannot be resolved solely through static literature review. The primary unknown involves Contributory Infringement in P2P Topologies. Qualified legal counsel must formally opine on the liability of distributing catalog metadata that links to models with revenue caps or royalty triggers. It remains legally ambiguous whether the P2P protocol inadvertently turns the host application into a distributor of commercially restricted intellectual property, thereby piercing the safe harbor provisions typically afforded to decentralized networks. Technical unknowns exist regarding WebGPU Context Memory Ceilings. Browser engines impose strict, often undocumented limits on maximum buffer sizes per compute shader invocation to prevent malicious code from locking up the host GPU. Empirical testing on target hardware—specifically comparing Apple M-series Unified Memory architectures against discrete Nvidia or AMD GPUs—is required to determine the actual failure point of the KV cache when scaling an 8,000-token context window inside a heavily sandboxed Wasm environment. Finally, there are profound unknowns regarding Deterministic State Resetting in non-transformer architectures. Hybrid models and pure RNNs maintain continuous internal convolution or hidden states across sequence generation21. Whether the WebAssembly execution environment can reliably and rapidly flush this recurrent state to absolute zero during a multi-turn chat reset—without requiring a highly latent, complete model reload in the browser—requires deep execution profiling utilizing local deployment access.

13. Annotated Primary-Source Bibliography

The following primary sources establish the foundation of this analysis, detailing architectural realities, licensing texts, and cryptographic supply chain standards. 5 Liquid AI, "LFM Open License v1.0" (April 2, 2026). This legally binding text explicitly outlines the $10 million commercial revenue threshold and aggressive patent termination clauses. The text definitively establishes that the LFM ecosystem operates under a restricted dual-use framework, rather than an OSI-approved open-source license, cementing the contagion risk for derivative works and decentralized redistribution. 14 Liquid AI / ByteIota, "LFM2.5-230M Architecture and Hardware Profiling" (June 2026). These technical specifications outline the hybrid Linear Input-Varying (LIV) convolution and Grouped Query Attention (GQA) architecture. The documentation provides critical metrics on memory footprint reduction, noting that replacing 75% of attention layers with LIV convolutions effectively neutralizes KV cache bloat, enabling speeds of 213 tokens per second on mobile hardware. 2 Technology Innovation Institute (TII), "Falcon-H1: A Family of Hybrid-Head Language Models" (July 2025). This technical report details the parallel Transformer-Mamba architecture, where Mamba-2 SSM heads and traditional attention heads operate simultaneously within the same network block. The text provides the architectural justification for the models' 256,000-token context capabilities. 6 Technology Innovation Institute (TII), "TII Falcon License 2.0" (December 2024). The primary legal text governing the Falcon ecosystem. Section 8 enforces a mandatory 10% commercial royalty on revenue exceeding $1 million USD, which directly violates the Open Source Initiative's requirement for non-discrimination against fields of endeavor, solidifying the artifact's rejection from the open portfolio. 7 Hugging Face / Alibaba, "SmolLM2 and Qwen2.5 Model Cards" (September \- November 2024). The official documentation confirming the Apache-2.0 status, exact active parameter counts, and dense transformer architectures of the foundational catalog selections. The texts confirm the deep instruction tuning regimens, utilizing up to 11 trillion tokens, ensuring their viability as highly capable local assistants. 9 IBM Granite Team, "Granite-3.0-1B-A400M-Instruct" (October 2024). This source outlines the specific implementation of IBM's Sparse Mixture-of-Experts architecture. It verifies that while the model retains one billion parameters of knowledge, it restricts active computation to 400 million parameters via Top-8 routing, making it an ideal candidate for CPU-constrained edge devices. 3 RWKV Community, "RWKV-7 Architecture and Specifications" (2025/2026). The core architectural documentation explaining the [Figure omitted from source export] memory requirements of the pure RNN design. The text details the specific Receptance Weighted Key Value operators that differentiate it from attention-based systems, highlighting the lack of native WebGPU support out-of-the-box. 27 MDPI / Systems Research, "Model Bill of Materials with PQC-safe extensions (MBOM-PQC)" (2025/2026). This academic framework establishes the absolute necessity of cryptographically securing AI supply chains. It introduces the standards for hybrid signature bundles and immutable long-term integrity anchors, forming the basis of the provenance control design recommended for the P2P network. 4 WebAssembly.org / ExplainX, "Wasm 2.0 Completed and WebGPU Mature" (2025/2026). These technological milestones detail the introduction of 128-bit SIMD processing and multi-value returns in WebAssembly, alongside the stabilization of explicit command encoding in WebGPU. These sources validate the strategic decision to rely on a Wasm-compiled external backend for cross-platform edge execution.

Works cited

1. Liquid AI Released LFM2.5-350M: A Compact 350M Parameter Model Trained on 28T Tokens with Scaled Reinforcement Learning \- MarkTechPost, https://www.marktechpost.com/2026/03/31/liquid-ai-released-lfm2-5-350m-a-compact-350m-parameter-model-trained-on-28t-tokens-with-scaled-reinforcement-learning/
2. Introducing Falcon-H1-Arabic: Pushing the Boundaries of Arabic Language AI with Hybrid Architecture \- Hugging Face, https://huggingface.co/blog/tiiuae/falcon-h1-arabic
3. RWKV Architecture History, https://wiki.rwkv.com/basic/architecture.html
4. WebGPU: The Complete Guide to Modern Graphics and Compute on the Web (2026), https://explainx.ai/blog/webgpu-complete-guide-2026
5. Model License \- Liquid Docs, https://docs.liquid.ai/lfm/help/model-license
6. xxxn3m3s1sxxx/Falcon3-1B-Instruct-1.58bit-ATLAS \- Hugging Face, https://huggingface.co/xxxn3m3s1sxxx/Falcon3-1B-Instruct-1.58bit-ATLAS
7. HuggingFaceTB/SmolLM2-1.7B · Hugging Face, https://huggingface.co/HuggingFaceTB/SmolLM2-1.7B
8. Qwen2.5-1.5B-Instruct: Efficient Open-Source LLM for Chat, Code, and Self-Hosted Deployment | DEV.co, https://dev.co/ai/llms/qwen2-5-1-5b-instruct
9. ibm-granite/granite-3.0-1b-a400m-instruct \- Hugging Face, https://huggingface.co/ibm-granite/granite-3.0-1b-a400m-instruct
10. HuggingFaceTB/SmolLM2-135M · Hugging Face, https://huggingface.co/HuggingFaceTB/SmolLM2-135M
11. HuggingFaceTB/SmolLM2-135M-Instruct · Hugging Face, https://huggingface.co/HuggingFaceTB/SmolLM2-135M-Instruct
12. Qwen/Qwen2-0.5B \- Hugging Face, https://huggingface.co/Qwen/Qwen2-0.5B
13. IBM Granite 3.0: open, state-of-the-art enterprise models, https://www.ibm.com/new/announcements/ibm-granite-3-0-open-state-of-the-art-enterprise-models
14. LiquidAI/LFM2.5-230M \- Hugging Face, https://huggingface.co/LiquidAI/LFM2.5-230M
15. 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
16. Falcon-H1 \- a tiiuae Collection \- Hugging Face, https://huggingface.co/collections/tiiuae/falcon-h1
17. Falcon-H1: A Family of Hybrid-Head Language Models Redefining Efficiency and Performance \- arXiv, https://arxiv.org/html/2507.22448v1
18. RWKV Language Model, https://wiki.rwkv.com/
19. Qwen/Qwen2.5-Coder-0.5B \- Hugging Face, https://huggingface.co/Qwen/Qwen2.5-Coder-0.5B
20. The Era of LLMs Running in the Browser—How WebGPU Changed Local AI Inference \- note, https://note.com/snake\_dragon/n/ncbb123143bf8?hl=en
21. 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/
22. Implementing Falcon-H1 Hybrid Architecture in NVIDIA Megatron Core, https://developer.nvidia.com/blog/implementing-falcon-h1-hybrid-architecture-in-nvidia-megatron-core/
23. LFM License | Liquid AI, https://www.liquid.ai/lfm-license
24. 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
25. tiiuae/Falcon3-1B-Base · Falcon LLM is proprietary license, while deceptfully advertised as "Open Source" \- Hugging Face, https://huggingface.co/tiiuae/Falcon3-1B-Base/discussions/12
26. Eagle and Finch: RWKV with Matrix-Valued States and Dynamic Recurrence \- OpenReview, https://openreview.net/pdf/9f3d829735b231725665ff226a4f732293ad4aa8.pdf
27. AI Supply Chain Security: MBOM-PQC Provenance, PQC Attestation, and a Maturity Model for Quantum-Resistant Assurance \- Preprints.org, https://www.preprints.org/manuscript/202603.1963
28. Security Risks and Mitigation Strategies for Large Language Models in Power Systems: A Review \- MDPI, https://www.mdpi.com/2673-4826/7/2/54
29. AI Supply Chain Security: MBOM-PQC Provenance, PQC Attestation, and a Maturity Model for Quantum-Resistant Assurance \- MDPI, https://www.mdpi.com/2079-8954/14/5/593
30. llama.cpp \- Liquid Docs, https://docs.liquid.ai/deployment/on-device/llama-cpp
31. Liquid AI LFM 2.5-230M: 230M Model Beats 1B Transformer on Edge | byteiota, https://byteiota.com/liquid-ai-lfm25-230m-edge-ai/
32. Wasm 2.0 Completed \- WebAssembly, https://webassembly.org/news/2025-03-20-wasm-2.0/
33. Support for WASM/WASI \+ non-browser, non-JS, non-emscripten environments · gfx-rs wgpu · Discussion \#4201 \- GitHub, https://github.com/gfx-rs/wgpu/discussions/4201
34. Liquid LFM2.5: How To Run & Fine-tune | Unsloth Documentation, https://unsloth.ai/docs/models/tutorials/lfm2.5
35. HuggingFaceTB/SmolLM2-1.7B-Instruct · Hugging Face, https://huggingface.co/HuggingFaceTB/SmolLM2-1.7B-Instruct
36. Liquid AI Ships LFM2.5-230M with llama.cpp, MLX, vLLM, SGLang, and ONNX Support for On-Device Inference \- MarkTechPost, https://www.marktechpost.com/2026/06/27/liquid-ai-ships-lfm2-5-230m-with-llama-cpp-mlx-vllm-sglang-and-onnx-support-for-on-device-inference/
37. RWKV Web, https://cryscan.github.io/web-rwkv-puzzles/
38. OsaurusAI/LFM2.5-230M-MXFP8 \- Hugging Face, https://huggingface.co/OsaurusAI/LFM2.5-230M-MXFP8
39. tiiuae/Falcon-H1-0.5B-Instruct-GGUF \- Hugging Face, https://huggingface.co/tiiuae/Falcon-H1-0.5B-Instruct-GGUF
40. RWKV Language Model, https://www.rwkv.com/
41. Falcon-H1: A Family of Hybrid-Head Language Models Redefining Efficiency and Performance \- arXiv, https://arxiv.org/pdf/2507.22448?
42. falcon-40b/LICENSE.txt at main \- GitHub, https://github.com/Decentralised-AI/falcon-40b/blob/main/LICENSE.txt
43. GitHub \- BlinkDL/RWKV-LM: RWKV (pronounced RwaKuv) is an RNN with great LLM performance, which can also be directly trained like a GPT transformer (parallelizable). We are at RWKV-7 "Goose". So it's combining the best of RNN and transformer \- great performance, linear time, constant space (no kv-cache), fast training, infinite ctx\_len, and free sentence embedding., https://github.com/blinkdl/rwkv-lm