Liquid AI LFM2-modellen ophalen en testen op Thor + Blackwell hoogste waarde

Download & test Liquid AI's LFM2 models on Thor + Blackwell highest value

Liquid's hele product zijn kleine modellen die "het niveau halen van modellen die 10 tot 1000× groter zijn" en draaien op een CPU, NPU of een chip van $60 met 2–8 GB RAM. Hun multimodale model in Mercedes-auto's is onder 1 GB, met een over-the-air update van 600 MB en LoRA-adapters van 20 MB per gebruiker. Open-weight, nu op Hugging Face:

Liquid's whole product is small models that hit "the level of models 10 to 1000× larger" and run on a CPU, NPU, or a $60 chip with 2–8 GB RAM. Their multimodal model shipping in Mercedes cars is under 1 GB, with a 600 MB over-the-air update and 20 MB per-user LoRA adapters. Open-weight, on Hugging Face now:

• LFM2-familie — dense 350M / 700M / 1.2B / 2.6B + MoE (8.3B totaal, 1.5B actief), 32K context.
• LFM2 family — dense 350M / 700M / 1.2B / 2.6B + MoE (8.3B total, 1.5B active), 32K context.
• LFM2.5-230M (juni 2026) — met llama.cpp, MLX, vLLM, SGLang en ONNX.
• LFM2.5-230M (June 2026) — ships with llama.cpp, MLX, vLLM, SGLang and ONNX.
• LFM2.5-VL-1.6B — vision-language, direct interessant voor de Orbbec + on-device vision.
• LFM2.5-VL-1.6B — vision-language, directly interesting for Orbbec + on-device vision.
• LFM2-24B-A2B — 24B MoE, 2B actief. Technisch rapport: arXiv:2511.23404.
• LFM2-24B-A2B — 24B MoE, 2B active. Technical report: arXiv:2511.23404.

Eerste stap: haal LFM2.5-VL-1.6B en een LFM2-1.2B/2.6B, draai ze door dezelfde bake-off-harnas als de Thor macro-writer en de GLM-test. Vraag: kan een LFM2-model een nuttige edge-taak doen (camera-captioning, kleine on-device assistent, snelle STAR-CCM+ macro-helper) op een fractie van het VRAM van de Qwen-op-Thor-stack? ONNX + vLLM = het valt zo op Jetson Thor en de Blackwell.

First step: pull LFM2.5-VL-1.6B and an LFM2-1.2B/2.6B, run them through the same bake-off harness we used for the Thor macro-writer and the GLM tier test. Question: can an LFM2 model do a useful edge job (camera captioning, a small on-device assistant, a fast STAR-CCM+ macro helper) at a fraction of the Qwen-on-Thor VRAM? ONNX + vLLM means it drops straight onto Jetson Thor and the Blackwell card.

Hardware-bewuste architectuurzoektocht (STAR / AFMD) → voor de wind-surrogaat

Hardware-aware architecture search (STAR / AFMD) → for the wind surrogate

Liquid kiest geen architectuur met de hand. Ze bouwden STAR (Automated Design of Tailored Architectures) en intern AFMD (Automated Foundation Model Design): een zoektocht die scaling-laws draait over ~100 operator-varianten en optimaliseert op vier doelen per hardware: geheugen, rekenefficiëntie, latency, accuraatheid. Zonder menselijke bias kwam er double-gated convolutie uit als ~80% van het netwerk.

Liquid doesn't hand-pick an architecture. They built STAR (Automated Design of Tailored Architectures) and in-house AFMD (Automated Foundation Model Design): a search that runs scaling laws over ~100 operator variants, optimizing four objectives per hardware: memory, compute efficiency, latency, accuracy. Unbiased, it rediscovered double-gated convolutions as ~80% of the network.

Wij hebben al zeven FNO-generaties met de hand geëvolueerd voor de wind-surrogaat. De logische volgende zet: definieer de vier-doelen-zoektocht (VRAM, throughput, latency, veld-accuraatheid) tegen de Blackwell en laat een search de operator-mix kiezen in plaats van de volgende FNO-variant te gokken.

We've hand-evolved seven FNO generations for the wind surrogate. The natural next move: define the four-objective search (VRAM, throughput, latency, field accuracy) against the Blackwell card and let a search pick the operator mix instead of guessing the next FNO variant.

Liquid / continue-tijd / neural-ODE priors voor CFD-surrogaten en sensorfusie

Liquid / continuous-time / neural-ODE priors for CFD surrogates and sensor fusion

Liquid-netwerken zijn continue-tijd recurrente netten op basis van neural ODEs, fysica-geïnspireerd, en verwerken onregelmatig gesamplede data van nature. Dat is een echt andere prior dan transformers of onze FNO. Twee van onze problemen passen: tijdsafhankelijke stroming (transiënte wind, binnenlucht) en sensorfusie van de Orbbec/seriële apparaten (die op onregelmatige tijden binnenkomen — precies waar liquid nets voor gemaakt zijn). Eerst een literatuurronde, volgens onze research-first regel.

Liquid networks are continuous-time recurrent nets built on neural ODEs, physics-inspired, and handle irregularly-sampled data natively. That's a genuinely different prior from transformers or our FNO. Two of our problems fit: time-dependent flow (transient wind, indoor air) and sensor fusion from the Orbbec/serial devices (irregular arrival — exactly what liquid nets were built for). Do a literature pass first, per our research-grounded rule.

State-space-modellen (Mamba) — het kennisgat dichten

State-space models (Mamba) — close the knowledge gap

Hasani kadert Mamba/SSM als "gelineariseerde continue-tijd neurale netten — vereenvoudigd tot lineaire dynamische systemen zodat je ze kunt opschalen". De bibliothecaris zegt: nul notities over SSMs. Gezien onze hoeveelheid lange-sequentie- en veldwerk is een korte scan (waar SSM attention verslaat: lange context, streaming) overdue.

Hasani frames Mamba/SSM as "linearized continuous-time neural nets — dumbed down to linear dynamical systems so you can scale them." The librarian says: zero notes on SSMs. Given our volume of long-sequence and field work, a short scan (where SSM beats attention: long context, streaming) is overdue.

Ternary / 1-bit / 1.58-bit kwantisatie — onze richting bevestigd, het Thor-gat dichten

Ternary / 1-bit / 1.58-bit quantization — validate our direction, fix the Thor gap

Blundin: "China is er met ternary en 1-bit kwantisatie vandoor gegaan." Onze bibliothecaris meldt al dat onze GpuPipeline voor ternary/binary hot-swap alleen op de desktop draait — niet op Thor (aarch64), door een ongedocumenteerd gemlite-pad. We wijzen dus goed; dit is de duw om dat aarch64-gat écht te dichten zodat de low-bit pipeline op Jetson werkt.

Blundin: "China ran away with ternary and 1-bit quantization." Our librarian already flags that our GpuPipeline for ternary/binary hot-swap runs desktop-only — not on Thor (aarch64), blocked by an undocumented gemlite path. So we're pointed right; this is the nudge to actually close that aarch64 gap so the low-bit pipeline works on Jetson.

Kleine modellen per vertical fine-tunen, met data-flywheel — voor de macro-writer

Fine-tune small models per vertical, with a data flywheel — for the macro-writer

Het sterkste zakelijke punt van het panel: de basismodel-laag is niet meer waar de waarde zit; customization wel. Twee bruikbare details: LoRA ≈ style transfer (voegt geen capaciteit toe), RFT (reinforcement fine-tuning) wél. En Liquid houdt modellen vers met een data-flywheel die drift opvangt. Voor onze STAR-CCM+ macro-writer: overweeg een klein lokaal model fine-tunen op onze eigen geverifieerde 21.02-macro-corpus in plaats van elke call prompt-stuffing, plus een drift-loop die nieuw-geverifieerde macro's terugvoert. Dat is "model + X" op labschaal.

The panel's strongest business point: the base-model layer is no longer where value lives; customization is. Two useful specifics: LoRA ≈ style transfer (adds no capability), RFT (reinforcement fine-tuning) does. And Liquid keeps models fresh with a data flywheel that catches drift. For our STAR-CCM+ macro-writer: consider fine-tuning a small local model on our own verified 21.02 macro corpus instead of prompt-stuffing every call, plus a drift loop that folds newly-verified macros back in. That's "model + X" at lab scale.

Roster-watch voor de multi-entity stack

Roster watch for the multi-entity stack

• Thinking Machines "Inkling" (Mira Murati): 975B MoE, 41B actief, 45T tokens, multimodaal, ~1M context, open-weight, on-prem, fine-tuning-as-a-service. Te groot om lokaal te draaien, maar de richting die onze routing al kiest.
• Thinking Machines "Inkling" (Mira Murati): 975B MoE, 41B active, 45T tokens, multimodal, ~1M context, open-weight, on-prem, fine-tuning-as-a-service. Too big to run locally, but the direction our routing already bets on.
• GLM-5.2 werd on-air "wel zo'n beetje het sterkste open-weight model" genoemd — precies het model dat wij al als externe workhorse/verifier gebruiken. Mooie onafhankelijke bevestiging.
• GLM-5.2 was named on-air "arguably the strongest open-weight model overall" — exactly the model we already use as external workhorse/verifier. Nice independent validation.
• Karpathy bij Anthropic werkt aan pre-training-automatisering ("automatisering van automatisering"); Anthropic's Fable 5 doet kernel-niveau zelfoptimalisatie. Frontier-referenties voor onze self-evolving loop.
• Karpathy at Anthropic works on pre-training automation ("automation of automation"); Anthropic's Fable 5 does kernel-level self-optimization. Frontier reference points for our self-evolving loop.

WeCo's schaal voor recursieve zelfverbetering — een meetlat voor onze loop

WeCo's recursive-self-improvement scale — a yardstick for our loop

Startup WeCo ("AID²") publiceerde een 0–3-schaal van recursieve zelfverbetering (0 delegatie → 1 net-positief → 2 ignition → 3 zelfversnelling). Onze Opus-schrijft / Qwen-voert-uit / Opus-oordeelt loop is een klein level-0/1-geval. Hasani's koudwaterpunt is het onthouden waard: met de huidige vaste-gewichten modellen is échte gewicht-niveau RSI "rekenkundig onhaalbaar" (zijn voorbeeld: ~350 jaar om een 2B-model te fine-tunen met WeCo's framework).

Startup WeCo ("AID²") published a 0–3 scale of recursive self-improvement (0 delegation → 1 net-positive → 2 ignition → 3 self-acceleration). Our Opus-authors / Qwen-executes / Opus-judges loop is a small level-0/1 instance. Hasani's cold-water point is worth remembering: with today's fixed-weight models, true weight-level RSI is "computationally intractable" (his example: ~350 years to fine-tune a 2B model with WeCo's framework).