LFM3-Omni-2B vs Ming-3.0-audio-flash: Een telefoon tegenover een rack

De stuklijst bepaalt deze vergelijking voordat de benchmarks er überhaupt aan te pas komen. Ming-3.0-audio-flash heeft 126 miljard parameters, ongeveer 259 GB aan bfloat16-gewichten, en een referentie-serveerprofiel gebouwd op 80GB H800's in tensor-parallel — vier in de 128K-configuratie, acht wanneer lange audio het geheugen uitput. LFM3-Omni-2B heeft 2,17 miljard parameters, wordt geleverd als gewone BF16-gewichten en is ontworpen om op een telefoon te draaien. Beide nemen audio op. Beide kunnen luidop antwoorden. De ene is een datacenterasset en de andere is een functie die je aan een app kunt toevoegen, en bijna al het andere eraan volgt uit dat ene feit.

Ze verschenen ook zonder veel ceremonie. Liquid AI kondigde de LFM3-familie op 27 oktober 2026 aan, met LFM3-Omni-2B als een van zes modellen in de 2B-klasse in één bericht; de repository ervan was sinds 21 oktober openbaar. inclusionAI uploadde Ming-3.0-audio-flash op 3 september 2026 met vrijwel geen documentatie en publiceerde pas op 19 oktober, zes weken later, een echte modelkaart. Geen van beide leveranciers heeft een onafhankelijke benchmark, en geen van beide modellen heeft een gehoste endpoint dat je per token kunt huren.

Twee manieren om een mond op een model te plaatsen

Het architecturale verschil gaat niet over grootte. Het gaat over waar de audio zich bevindt.

Ming-3.0-audio-flash houdt audio zo lang mogelijk audio. Een encoder in Whisper-stijl — 32 lagen, breedte 1.280, 128 mel-bins — zet geluid om in een representatie die een 42-laags mixture-of-experts-backbone met 512 experts en 8 geselecteerd per token voedt. Spraak komt terug via een optionele Talker-module met ingebouwde Chinese stemmen en stem-prompting via referentieclips. De opgegeven context is 128K, een cijfer dat de configuratie pas claimde nadat een commit van 13 oktober de positie-embeddings van 8.192 naar 131.072 verhoogde.

LFM3-Omni-2B tokeniseert alles in één stream. Video wordt gesampled op 2 frames per seconde, elk 2×2-beeldpatch wordt één taaltoken, en audio gaat via een LFM3 causale audio-encoder naar dezelfde vocabulaire van 128.000 tokens als de tekst. Spraak uit is LiquidCodec op 24 kHz; audio in is 16 kHz mono. Het hele model past in een venster van 32K.

Dat is een compressieargument, en het snijdt beide kanten op. De aanpak van LFM3-Omni-2B is wat een model van 2.17B levensvatbaar maakt op een handset — alles is hetzelfde soort token, dus alles is op dezelfde manier goedkoop. De aanpak van Ming is wat een model van 126B een opname van een uur in gedachten laat houden zonder de prosodie weg te gooien. Geen van beide is een gratis lunch.

De cijfers die het waard zijn om naast elkaar te leggen

• Totaal aantal parameters — LFM3-Omni-2B: 2,17B dense; Ming-3.0-audio-flash: 126B in een mengsel van 512 experts.

• Actieve parameters — ongeveer 2,17 miljard tegenover 6,5 miljard per inferentiestap.

• Gewichten op schijf — een paar gigabyte tegenover ongeveer 259 GB aan bfloat16-shards plus de Talker.

• Referentiehardware — een telefoon, laptop of edge-board tegenover vier 80 GB H800's in tensor-parallel voor het 128K-profiel, acht wanneer lange audio het geheugen uitput.

• Context — 32K tokens voor invoer en uitvoer, tegen een opgegeven 128K.

• Spraakuitvoer — 24 kHz LiquidCodec met 19 spraaklocales; Ming retourneert tekst of tekst plus spraak via de Talker, met ingebouwde stemmen en het klonen van referentieclips.

• Licentie — LFM Open License v1.0, een licentie met een omzetdrempel, tegenover MIT.

• Prijs — geen prijs per token aan beide zijden, omdat geen van beide leveranciers inference voor deze checkpoints verkoopt.

Actieve parameters zijn geen snelheidsmeter

Het is verleidelijk om "6.5B active" naast "2.17B dense" te lezen en te concluderen dat Ming slechts drie keer duurder is per token. Die lezing is in beide richtingen onjuist.

Een mengeling van experts verbruikt geheugenbandbreedte, niet alleen rekenkracht. Het serveren van 6,5B actieve parameters uit 126B betekent dat expertgewichten op elke laag in de cache moeten worden verplaatst, en bij batchgrootte één — het regime waarin een spraakassistent zich bevindt — komt dat dicht bij het lezen van een groot deel van 259 GB voor elk token. Het acht-H800-profiel is geen aanbeveling voor piekdoorvoer; het is wat nodig is om de gewichten vast te houden. LFM3-Omni-2B met 2,17B heeft het omgekeerde probleem: geen spaarzaamheidswinst, maar ook niets om uit te wisselen, wat precies het profiel is dat een telefoon aannemelijk maakt.

De praktische consequentie is dat de twee modellen verschillende schaalcurves hebben. Ming wordt goedkoper per token naarmate je batcht, wat past bij transcriptiepijplijnen die een wachtrij van opgenomen gesprekken doorwerken. LFM3-Omni-2B blijft ongeveer constant per uiting, wat past bij een livegesprek waarbij de batchgrootte één is en het latentiebudget een paar honderd milliseconden bedraagt.

Wat de 126 miljard koopt

inclusionAI publiceert zijn evaluaties als afbeeldingen in plaats van tabellen, wat op zichzelf al een statement is, maar de cijfers zijn leesbaar. Op zijn eigen harness rapporteert Ming-3.0-audio-flash een gemiddeld foutpercentage voor Chinese ASR van 3,45, Engels 3,69, een dialectgemiddelde van 9,40 voor Kantonees, Shanghainees, Hunanees en Hokkien, en een diarisatiefoutpercentage van 8,58 op AISHELL-4. Rijen voor audioreasoning omvatten BigBenchAudio met 99,40 en MMAU met 82,00. Dit zijn leverancierscijfers op een leveranciersharness, met asterisken die de zelfgeëvalueerde rijen markeren. Niemand heeft ze gereproduceerd.

De zwakte die de leverancier toch heeft vermeld, is redeneren over lange audio: een Long-audio Chain-score van 12,31 en LongAudioSpan van 41,12, beide ruim achter de gehoste modellen in zijn eigen vergelijking. Dus de 126B is niet uniform beter in "audio begrijpen". Hij is beter in precies horen wat er is gezegd, met welk accent, door welke spreker — en aanzienlijk minder goed in een lange opname in gedachten houden en daarover redeneren.

Wat er voor 2,17 miljard wordt gekocht

LFM3-Omni-2B rapporteert een Engels ASR-woordfoutpercentage van 6,36 en een meertalig percentage van 6,72, een TTS-UTMOSv2 van 3,80, VoiceBench 64,73, MMAR 51,40 en een tool-calling-score van 52,20. De audio-invoer is beperkt tot 16 kHz mono, wat prima is voor spraak en nutteloos voor muziek.

Weersta de neiging om 6,36 te vergelijken met de 3,69 van Ming. Het zijn niet dezelfde test. Mings Engelse gemiddelde wordt berekend over zijn eigen set Engelse benchmarks; Liquids 6,36 is één getal uit één evaluatie, uitgevoerd met zijn eigen prompts en greedy-decodering. De enige verdedigbare bewering is directioneel: Mings ASR is waarschijnlijk beter, omdat een 126B audio-native model met een Whisper-achtige tower meer ruimte heeft om beter te presteren, en omdat dialectverwerking het punt is waar inclusionAI mee wilde uitpakken. Of het twee punten beter is of een half punt, is niet te weten uit deze twee modelkaarten.

Wat LFM3-Omni-2B oplevert, is niet nauwkeurigheid. Het is dat het model draait waar de microfoon is. Voor een pijplijn voor het opnemen van gesprekken is dat irrelevant. Voor alles met een live gebruiker verandert het de architectuur: geen upload, geen round trip, geen facturering per minuut, en geen audio die het apparaat verlaat.

De licentie is het stille verschil

Ming-3.0-audio-flash is MIT. Dat is ongeveer zo permissief als het maar kan: commercieel gebruik, wijziging, herdistributie, geen omzettoets, geen beperking op toepassingsgebied. LFM3-Omni-2B wordt geleverd onder de LFM Open License v1.0, de familielicentie die Liquid op alle LFM3 toepast, en dat is een licentie met een omzetdrempel in plaats van een door OSI goedgekeurde opensourcelicentie. Lees die voordat je er een product op bouwt. Voor een startup onder de drempel is het verschil academisch; voor een bedrijf erboven is MIT echt geld waard.

Integratie is waar het papierwerk zichtbaar wordt.

Het servingverhaal van Ming is nog niet rond. De aankondiging van inclusionAI suggereerde dat je de familie vandaag al met vLLM-Omni kunt serveren; wat de repository feitelijk laat zien, zijn open pull-requests — één over het tts-tiny-checkpoint, een andere die audio-flash-ondersteuning toevoegt. Tot die zijn samengevoegd, betekent Ming-3.0-audio-flash draaien: Transformers op een machine met voldoende geheugen, of het SGLang-Omni-pad dat de leverancier documenteert. Het is doenbaar en het is geen `pip install`.

Het verhaal van LFM3-Omni-2B is het tegenovergestelde: een Hugging Face-kaart die het fine-tuningrecept documenteert, en een Ollama-build die al in omloop is. Die build vermeldt een context van 125K tegenover de 32K van de kaart, wat je vertelt dat de packaging sneller bewoog dan de documentatie — een klein detail dat ertoe doet als je van plan was er lange audio aan te voeren.

Als geen van beide de juiste vorm voor je is, is het alternatief om de capaciteit te huren in plaats van te bezitten, en dat is een andere budgetpost. OrcaRouter is de gehoste kant van die keuze — één API voor meer dan 200 modellen tegen 0% opslag op de lijstprijs van de provider, met automatische failover wanneer een provider uitvalt — en noch LFM3-Omni-2B noch Ming-3.0-audio-flash staat vandaag in die catalogus. Dat is de eerlijke inkadering: dit stuk gaat over twee modellen die je downloadt, niet over twee die je kunt aanroepen.

Wie moet welke kiezen

Kies Ming-3.0-audio-flash als je GPU's hebt die je niet voor iets anders gebruikt, je audio Chinees of Engels is met accenten en meerdere sprekers, en je taak erin bestaat een nauwkeurig transcript of een beargumenteerd antwoord over een lange opname te produceren. De MIT-licentie maakt het de veiligere van de twee om een commercieel product op te bouwen, en de 128K-context maakt het de enige van het tweetal die een vergadering in één keer aankan.

Kies LFM3-Omni-2B als de audio aan de edge wordt gegenereerd, de gebruiker wacht en het antwoord in dezelfde ademteug moet worden teruggesproken. Accepteer dat je de nauwkeurigheid van een kleiner model krijgt, een beperktere taallijst en een licentie met een omzetclausule, in ruil voor een deployment die in een app past.

De vraag die je je voor beide moet stellen: waar gaat de audio naartoe? Als het antwoord "nergens" is, is de vergelijking voorbij.