LFM3-Omni-2B vs Ming-3.0-audio-tiny: een stackvervanging tegenover een specialist

Twee modellen, allebei als klein op de markt gebracht, allebei in staat om hardop te antwoorden, en vrijwel niets anders gemeen. LFM3-Omni-2B is een dense checkpoint van 2,17 miljard parameters van Liquid AI dat tekst, afbeeldingen, video en audio als invoer neemt en tekst of spraak op 24 kHz retourneert. Ming-3.0-audio-tiny is een mixture-of-expertsmodel van inclusionAI met 9,3 miljard parameters, waarvan 2,7 miljard parameters per stap actief zijn, en het neemt audio en tekst als invoer en retourneert tekst of spraak op 44,1 kHz. De ene probeert een complete assistentstack te vervangen. De andere probeert het best mogelijke oor te zijn. Een specialist en een generalist kunnen achter één sleutel zitten. één endpoint Verzoeken worden volgens regels gerouteerd, met automatische failover als een route uitvalt.

De naamgeving maakt dit moeilijker dan nodig. "Tiny" verwijst in Mings familie naar de positie ten opzichte van Ming-3.0-audio-flash, niet naar de absolute omvang: met in totaal 9,3B is het meer dan vier keer het aantal parameters van het Liquid-model. En LFM3-Omni-2B is geen audiomodel met eraan vastgeschroefde visie — het is een algemeen multimodaal model dat toevallig een audiopad heeft. Ze rij voor rij vergelijken zou voor beide oneerlijk zijn. Ze vergelijken op basis van het werk dat ze doen, is de enige vergelijking die ertoe doet.

Wat elk ervan eigenlijk is

Ming-3.0-audio-tiny is een native audio-taalmodel: een audio-encoder en projector die een sparse MoE-taalbackbone voeden, met een aparte Talker-fase die spraak genereert wanneer je daarom vraagt. Het ondersteunt Chinees en Engels, inclusief accenten en dialecten, en het ondersteunt voicecloning op basis van een referentieclip plus transcript. De gewichten zijn MIT-gelicenseerd en beschikbaar op Hugging Face en ModelScope; er bestaan community-kwantisaties voor MLX en GGUF, en er is een werkende ROCm-demonstratie van een spraakassistent met lage latentie die erop is gebouwd. De repository is begin september 2026 geüpload en de modelkaart en config zijn medio oktober vernieuwd, het moment waarop het daadwerkelijk bruikbaar werd.

LFM3-Omni-2B is de tegenovergestelde constructie. Eén enkele dense trunk met een vision-encoder, een causale audio-encoder en LiquidCodec voor spraakuitvoer, getraind zodat één set gewichten vier invoermodaliteiten en twee uitvoermodaliteiten afhandelt. Het werd op 27 oktober 2026 gepubliceerd als een tak van Liquids LFM3-familie van zes modellen, zonder afzonderlijke aankondiging en zonder onafhankelijke evaluatie. De modelkaart vermeldt 2,17B parameters, een context van 32.768 tokens en de LFM Open License v1.0.

• Architectuur — 2,17B dense any-to-any versus 9,3B totaal met 2,7B actief per token, sparse MoE plus een aparte spraak-Talker.

• Invoer — tekst, afbeelding, video met soundtrack, 16 kHz audio versus alleen audio en tekst.

• Spraakuitvoer — 24 kHz via LiquidCodec, sneller dan realtime gestreamd versus 44,1 kHz mono via de Talker, met benoemde presetstemmen en cloning.

• Talen — 16 teksttalen en 19 spraakvarianten versus Chinees en Engels, inclusief dialecten.

• Context — 32,768 tokens, vermeld op de kaart versus geen contextvenster vermeld op de kaart; de gepubliceerde configuratie beschrijft een positiebudget van 131,072 tokens.

• Licentie — LFM Open License v1.0 met een omzetdrempel versus MIT.

• Voetafdruk — ongeveer 4,3 GB in BF16 versus ruwweg 21 GB in BF16, waarbij int8-expertkwantisatie het op ongeveer 12,5 GB brengt.

De twee rijen die daadwerkelijk overlappen

Benchmarktabellen tussen labs zijn meestal theater, omdat elk lab zijn eigen testopstelling kiest. Hier is de overlap klein genoeg om het precies te stellen: twee datasets komen in beide leveranciersrapporten voor, en beide zijn audiotaken waarbij de methodologie redelijk standaard is.

• Woordfoutpercentage voor Engelse ASR — 6,36 voor LFM3-Omni-2B vs 4,36 voor Ming-3.0-audio-tiny. Lager is beter, en Ming ligt twee absolute punten voor, ongeveer een derde minder fouten.

• VoiceBench — 64,73 vs 74,29. Ming ligt 9,6 punten voor op het opvolgen van gesproken instructies en gedrag als spraakassistent.

Bij de taken die beide modellen meten, wint de specialist, en dat is het verwachte resultaat. Ming besteedt 2,7 miljard actieve parameters aan horen en spreken. LFM3-Omni-2B besteedt 2,17 miljard aan horen, spreken, zien en lezen tegelijk. Een model dat zijn capaciteit niet in vier richtingen verdeelt, zou beter moeten zijn in de ene richting waarin het werkt, en dat is het ook.

Wat Ming rapporteert dat LFM3-Omni-2B niet doet, is een langere lijst: Chinese ASR-tekenfoutpercentage 3,79, dialect-tekenfoutpercentage 10,29, BigBenchAudio 99,20, MMAU 75,90, MMAU-Pro 56,42, lange-audioprecisie 56,39 en BFCL-v3 Audio 79,80. Dat zijn sterke cijfers voor een model van deze grootte, en ze beschrijven een systeem dat specifiek op audioreasoning is geëvalueerd in plaats van als één kolom in een multimodale tabel. De dichtstbijzijnde equivalenten op de Liquid-kaart zijn audio-understanding MMAR 51,40 en een tool-calling-score van 52,20 — maar de tool-calling-benchmark is niet dezelfde test als BFCL-v3 Audio, en die twee cijfers naast elkaar zetten zou precies het soort vergelijking zijn dat deze blog wil vermijden.

De benchmark die deze confrontatie niet kan beslechten

De interessante vraag is niet welk model beter hoort. Het is of één enkel omni-model audiovisueel kan redeneren zoals een pipeline dat niet kan. Ming-3.0-audio-tiny heeft helemaal geen visiepad: het kan niet naar een frame kijken en beschrijven wat er gebeurt, en het kan geen vraag beantwoorden over de soundtrack van een video terwijl het de video bekijkt. LFM3-Omni-2B kan beide, en Liquid rapporteert Daily-Omni 70.09 en WorldSense 47.10 voor precies die capaciteit.

Die cijfers hebben geen tegenhanger op Ming's kaart, omdat Ming de taak niet probeert. Zo wordt de vergelijking een kwestie van scope in plaats van kwaliteit: als je applicatie een spraakinterface voor een audiostream is, is Ming het capabelere oor en de kleinere actieve compute. Als je applicatie een camera plus een microfoon plus een luidspreker is, doet LFM3-Omni-2B iets wat Ming op geen enkele grootte kan, en is de audiokloof de prijs die je betaalt voor de camera.

De belasting is niet triviaal. Twee punten verschil in het Engelse woordfoutpercentage op een spraakinterface is het verschil tussen een transcript dat je snel kunt doorscannen en een dat je moet corrigeren. Als het audiopad het primaire product is en visie een bonus, dan is de eerlijke aanbeveling om Ming te gebruiken voor de audio en een apart visiemodel voor de frames, ook al betekent dat twee checkpoints.

De geheugenrekening bepaalt meer deployments dan de benchmark.

Ming-3.0-audio-tiny heeft ongeveer 21 GB aan gewichten nodig in BF16, of ongeveer 12,5 GB met int8-expertkwantisatie, en een volledige implementatie met audio-uitvoer kan de Thinker en de Talker over twee GPU's verdelen. LFM3-Omni-2B heeft ongeveer 4,3 GB nodig. Dat is geen klein verschil: het is het verschil tussen één midrange-GPU en een machine waar je omheen moet plannen, en het is het verschil tussen een telefoon en een server.

De vergelijking keert om, afhankelijk van wat je meet. De 2,7B actieve parameters van Ming maken het goedkoop per token ondanks de totale omvang, en dat is precies het hele punt van een sparse MoE. LFM3-Omni-2B is dense, dus elk token kost de volledige 2,17B — maar het hele model past in een fractie van het geheugen en draait op hardware waar Ming niet bij in de buurt komt.

Hier wordt de economie van routing concreet. OrcaRouter geeft de lijstprijzen van providers door zonder opslag, zodat een goedkopere specialist en een duurdere generalist achter één sleutel kunnen zitten zonder een tweede contract, en een prijswijziging van een leverancier dezelfde dag op je factuur doorwerkt in plaats van bij de volgende verlenging. Geen van beide modellen, LFM3-Omni-2B en Ming-3.0-audio-tiny, staat vandaag in onze catalogus, dus dit is een uitspraak over hoe het platform prijzen vaststelt, niet de bewering dat je nu een van beide modellen via ons kunt aanroepen. Maar het patroon dat deze twee modellen creëren — een goedkope specialist voor het gangbare geval, een generalist voor het moeilijke geval — is precies het patroon waarvoor een router bedoeld is.

De licentiekwestie, die de echte splitsing is

Ming-3.0-audio-tiny valt onder MIT. LFM3-Omni-2B valt onder de LFM Open License v1.0, een aangepaste overeenkomst met een omzetdrempel die bepaalt of commercieel gebruik een aparte regeling vereist. Voor een onderzoeksprototype is het verschil academisch. Voor een product is het het eerste waar de juridische afdeling naar zal vragen, en het kan een benchmarkkloof van welke grootte dan ook tenietdoen.

MIT verklaart ook waarom Ming al communityports heeft: MLX-builds, GGUF-quantisaties, een ROCm-demo van een spraakassistent. Die bestaan omdat de licentie ze gemakkelijk maakte, en ze zijn de reden dat Ming vandaag inzetbaar is op hardware die Liquid nooit heeft getest. LFM3-Omni-2B werd op 27 oktober gepubliceerd met 83 downloads, en er is één servingpad gedocumenteerd, alleen voor tekstuitvoer. Het ecosysteem ervan bestaat nog niet.

De praktische asymmetrie is groot. Qua audionauwkeurigheid, geheugenefficiëntie per actieve parameter, taaldekking voor Chinees en dialecten, stemklonen en licentievrijheid is Ming-3.0-audio-tiny vandaag de veiligere keuze. Qua modaliteitsdekking en ruwe omvang is LFM3-Omni-2B de enige van de twee die naar een kamer kan kijken en erover kan praten.

Wie moet welke ophalen?

Kies Ming-3.0-audio-tiny als je een spraakproduct bouwt — transcriptie, gesproken dialoog, stemklonen, gespreksanalyse — en je geen visie nodig hebt of bereid bent het te combineren met een apart visueel model. De MIT-licentie, de bestaande quantisaties en het tweeledige ASR-voordeel maken het de minder riskante implementatie, en de sparse architectuur houdt de kosten per token laag ondanks de 9,3B in totaal.

Kies LFM3-Omni-2B als het apparaat een camera en een microfoon heeft en de beperking geheugen is. Een checkpoint van 4,3 GB dat ziet, hoort en spreekt is een andere categorie object dan een audiospecialist van 21 GB, en geen enkele hoeveelheid ASR-nauwkeurigheid compenseert voor een model dat niet past. Accepteer dat je breedte koopt, geen diepte, en dat elk audiocijfer dat eraan hangt door de leverancier is opgegeven en niet is gereproduceerd.

Wat geen van beide modelkaarten je vertelt, is hoe ze zich in dezelfde toepassing gedragen. Die test — dezelfde audio, hetzelfde apparaat, hetzelfde latentiebudget — is door niemand buiten de twee bedrijven uitgevoerd. Totdat dat gebeurt, berust de beslissing op scope en licentiëring, die vandaag kenbaar zijn, in plaats van op nauwkeurigheid, die dat niet is.