Ett hjälterubrikkort med texten "LFM3-Omni-2B vs Ming-3.0-audio-tiny" och underrubriken "En som ser, en som lyssnar". En vänsterpanel listar 2,17B dense, vision och ljud in, tal ut och anpassad licens; en högerpanel listar 9,3B totalt med 2,7B aktiva, endast ljud, tal ut och MIT-licens. OrcaRouter-logotypen sitter längst ner till höger.
Guides & Insights

LFM3-Omni-2B vs Ming-3.0-audio-tiny: En ersättning för hela stacken mot en specialist

Författare

Alistair Wren

Publiceringsdatum

Senaste modellerna · 20Visa alla modeller →
Benchmarks: Artificial Analysis · uppdateras dagligen
Tillbaka till alla inlägg

Två modeller, båda marknadsförda som små, båda kan svara högt, och nästan inget annat gemensamt. LFM3-Omni-2B är en tät checkpoint med 2,17 miljarder parametrar från Liquid AI som tar emot text, bilder, video och ljud och returnerar text eller tal i 24 kHz. Ming-3.0-audio-tiny är en mixture-of-experts-modell med 9,3 miljarder parametrar från inclusionAI med 2,7 miljarder parametrar aktiva per steg, och den tar emot ljud och text och returnerar text eller tal i 44,1 kHz. Den ena försöker ersätta en hel assistentstack. Den andra försöker vara ett så bra öra som möjligt. En specialist och en generalist kan sitta bakom en enda nyckel. en slutpunkt Förfrågningar dirigeras enligt regel, med automatiskt failover om en väg misslyckas.

Namngivningen gör detta svårare än det behöver vara. "Tiny" i Mings familj syftar på dess position i förhållande till Ming-3.0-audio-flash, inte på dess absoluta storlek: med totalt 9,3B har den mer än fyra gånger så många parametrar som Liquid-modellen. Och LFM3-Omni-2B är inte en ljudmodell med syn påklistrad — det är en allmän multimodal modell som råkar ha en ljudväg. Att jämföra dem rad för rad skulle vara orättvist mot båda. Att jämföra dem utifrån det arbete de utför är den enda jämförelse som spelar roll.

Vad var och en faktiskt är

Ming-3.0-audio-tiny är en nativ ljud-språkmodell: en ljudkodare och projektor som matar en gles MoE-språkryggrad, med ett separat Talker-steg som genererar tal när du ber om det. Den hanterar kinesiska och engelska, inklusive accenter och dialekter, och den stöder röstkloning från ett referensklipp plus transkription. Vikterna är MIT-licensierade och finns på Hugging Face och ModelScope; det finns community-kvantiseringar för MLX och GGUF, och det finns en fungerande ROCm-demonstration av en röstassistent med låg latens byggd på den. Förvaret laddades upp i början av september 2026 och modellkortet och konfigurationen uppdaterades i mitten av oktober, vilket är då den i praktiken blev användbar.

LFM3-Omni-2B är den motsatta konstruktionen. En enda tät stomme med en visionskodare, en kausal ljudkodare och LiquidCodec för talutdata, tränad så att en uppsättning vikter hanterar fyra indatamodaliteter och två utdatamodaliteter. Det publicerades den 27 oktober 2026 som en gren av Liquids sexmodellfamilj LFM3, utan ett fristående tillkännagivande och utan oberoende utvärdering. Modellkortet anger 2,17B parametrar, en kontext på 32 768 token och LFM Open License v1.0.

• Arkitektur — 2,17B tät any-to-any kontra 9,3B totalt med 2,7B aktiva per token, gles MoE plus en separat tal-Talker.

• Indata — text, bild, video med ljudspår, 16 kHz-ljud jämfört med enbart ljud och text.

• Talutmatning — 24 kHz via LiquidCodec, strömmad snabbare än realtid jämfört med 44,1 kHz mono via Talker, med namngivna förinställda röster och kloning.

• Språk — 16 textspråk och 19 tallokaler jämfört med kinesiska och engelska, inklusive dialekter.

• Kontext — 32 768 token, angivet på kortet vs inget kontextfönster angivet på kortet; den publicerade konfigurationen beskriver en positionsbudget på 131 072 token.

• Licens — LFM Open License v1.0 med ett intäktströskelvärde jämfört med MIT.

• Minnesavtryck — cirka 4,3 GB i BF16 jämfört med ungefär 21 GB i BF16, med int8-kvantisering av experter som tar ner det till cirka 12,5 GB.

A headless-browser capture of the Hugging Face model card for LiquidAI/LFM3-Omni-2B, showing the model-details panel with 2.17B parameters, an any-to-any pipeline tag, a 32,768-token context, the sixteen listed text languages, nineteen speech languages and locales, the LFM Open License v1.0, and a note that thinking mode is unsupported.

De två raderna som verkligen överlappar varandra

Benchmarktabeller mellan labb är mestadels spel för galleriet, eftersom varje labb väljer sitt eget testramverk. Här är överlappningen tillräckligt liten för att kunna anges exakt: två datamängder förekommer i båda leverantörsrapporterna, och båda är ljuduppgifter där metoden är någorlunda standard.

• Engelsk ASR-ordfelsfrekvens — 6,36 för LFM3-Omni-2B mot 4,36 för Ming-3.0-audio-tiny. Lägre är bättre, och Ming ligger före med två absoluta punkter, ungefär en tredjedel mindre fel.

• VoiceBench — 64,73 vs 74,29. Ming ligger före med 9,6 poäng när det gäller att följa talade instruktioner och röstassistentbeteende.

På de uppgifter som båda modellerna mäter vinner specialisten, och det är det förväntade resultatet. Ming använder 2,7 miljarder aktiva parametrar på att höra och tala. LFM3-Omni-2B använder 2,17 miljarder på att höra, tala, se och läsa samtidigt. En modell som inte delar sin kapacitet på fyra sätt bör vara bättre på det enda sätt den fungerar, och det är den.

Det som Ming rapporterar men som LFM3-Omni-2B inte gör är en längre lista: teckenfelkvot för kinesisk ASR 3,79, teckenfelkvot för dialekter 10,29, BigBenchAudio 99,20, MMAU 75,90, MMAU-Pro 56,42, noggrannhet för långt ljud 56,39 och BFCL-v3 Audio 79,80. Det är starka siffror för en modell av den här storleken, och de beskriver ett system som utvärderades specifikt för ljudresonemang snarare än som en kolumn i en multimodal tabell. Liquid-kortets närmaste motsvarigheter är MMAR för ljudförståelse 51,40 och en poäng för verktygsanrop på 52,20 – men benchmarken för verktygsanrop är inte samma test som BFCL-v3 Audio, och att ställa de två siffrorna sida vid sida skulle vara den typ av jämförelse som den här bloggen finns för att undvika.

Riktmärket som den här matchen inte kan avgöra

Den intressanta frågan är inte vilken modell som hör bättre. Det är huruvida en enda omni-modell kan utföra audiovisuellt resonemang som en pipeline inte kan. Ming-3.0-audio-tiny har ingen synväg alls: den kan inte titta på en bildruta och beskriva vad som händer, och den kan inte svara på en fråga om en videos ljudspår medan den tittar på videon. LFM3-Omni-2B kan göra båda, och Liquid rapporterar Daily-Omni 70,09 och WorldSense 47,10 för exakt den förmågan.

De siffrorna har ingen motsvarighet i Mings kort eftersom Ming inte försöker utföra uppgiften. Jämförelsen landar därför i en fråga om omfattning snarare än en kvalitetsfråga: om din applikation är ett röstgränssnitt mot en ljudström är Ming det mer kapabla örat och den mindre aktiva beräkningskraften. Om din applikation är en kamera plus en mikrofon plus en högtalare gör LFM3-Omni-2B något som Ming inte kan göra oavsett storlek, och ljudgapet är skatten du betalar för kameran.

Skatten är inte obetydlig. Två procentenheter i engelsk ordfelsfrekvens på ett röstgränssnitt är skillnaden mellan en transkription du kan ögna igenom och en du måste korrigera. Om ljudvägen är huvudprodukten och syn är en bonus, är den ärliga rekommendationen att använda Ming för ljudet och en separat synmodell för bildrutorna, även om det innebär två checkpoints.

Minnesräkningen avgör fler driftsättningar än vad benchmarken gör

Ming-3.0-audio-tiny behöver ungefär 21 GB vikter i BF16, eller cirka 12,5 GB med int8-expertkvantisering, och en fullständig distribution för ljudutdata kan dela upp Thinker och Talker på två GPU:er. LFM3-Omni-2B behöver ungefär 4,3 GB. Det är inte en liten skillnad: det är skillnaden mellan ett enda grafikkort i mellanklassen och en maskin man måste planera kring, och det är skillnaden mellan en telefon och en server.

Jämförelsen vänder beroende på vad du mäter. Mings 2,7B aktiva parametrar gör den billig per token trots sin totala storlek, vilket är hela poängen med en gles MoE. LFM3-Omni-2B är tät, så varje token kostar hela 2,17B — men hela modellen får plats i en bråkdel av minnet och körs på hårdvara som Ming inte kan hantera.

Det är här routingekonomin blir konkret. OrcaRouter för vidare leverantörernas listpriser utan påslag, så en billigare specialist och en dyrare generalist kan ligga bakom en och samma nyckel utan ett andra avtal, och en prisförändring från leverantören når din faktura samma dag i stället för vid nästa förnyelse. Varken LFM3-Omni-2B eller Ming-3.0-audio-tiny finns i vår katalog i dag, så detta är ett konstaterande om hur plattformen prissätter saker, inte ett påstående om att du just nu kan anropa någon av modellerna via oss. Men mönstret som dessa två modeller skapar – en billig specialist för det vanliga fallet, en generalist för det svåra – är precis vad en router är till för.

Licensfrågan, som är den verkliga forken

Ming-3.0-audio-tiny har MIT-licens. LFM3-Omni-2B omfattas av LFM Open License v1.0, ett anpassat avtal med en intäktströskel som avgör om kommersiell användning kräver en separat överenskommelse. För en forskningsprototyp är skillnaden akademisk. För en produkt är det det första juridikavdelningen kommer att fråga om, och det kan åsidosätta ett benchmarkgap av vilken storlek som helst.

MIT förklarar också varför Ming redan har communityportar: MLX-byggen, GGUF-kvantiseringar, en ROCm-röstassistentdemo. De finns eftersom licensen gjorde dem enkla, och de är anledningen till att Ming idag kan driftsättas på hårdvara som Liquid aldrig har testat. LFM3-Omni-2B publicerades den 27 oktober med 83 nedladdningar, och den har en dokumenterad serveringsväg endast för textutdata. Dess ekosystem finns inte ännu.

Den praktiska asymmetrin är slående. När det gäller ljudnoggrannhet, minneseffektivitet per aktiva parameter, språktäckning för kinesiska och dialekter, röstkloning och licensieringsfrihet är Ming-3.0-audio-tiny det säkrare valet i dag. När det gäller modalitetstäckning och rått fotavtryck är LFM3-Omni-2B den enda av de två som kan titta på ett rum och prata om det.

A headless-browser capture of Liquid AI's LFM3 launch post dated October 27, 2026, showing the headline 'Introducing LFM3: Every Modality for Specialized Intelligence' and the Highlights box stating that six 2B-class models were trained from LFM3-1.7B-Base across text, vision, audio, omni and decision, with a 256K context window for the text model and download links for the weights, the API and the Playground.

Vem ska hämta vilken?

Välj Ming-3.0-audio-tiny om du bygger en talprodukt – transkription, talad dialog, röstkloning, samtalsanalys – och antingen inte behöver vision eller är villig att kombinera den med en separat visuell modell. MIT-licensen, de befintliga kvantiseringarna och fördelen med tvåpunkts-ASR gör det till det lägre-riskalternativet vid driftsättning, och dess glesa arkitektur håller kostnaden per token nere trots totalt 9,3B.

Välj LFM3-Omni-2B om enheten har en kamera och en mikrofon och begränsningen är minne. En checkpoint på 4,3 GB som ser, hör och talar är en annan typ av objekt än en ljudspecialist på 21 GB, och ingen ASR-noggrannhet kompenserar för en modell som inte får plats. Acceptera att du köper bredd, inte djup, och att varje ljudmått som anges för den är leverantörsrapporterat och inte reproducerat.

Det som ingen av modellernas modellkort berättar är hur de beter sig i samma applikation. Det testet – samma ljud, samma enhet, samma latensbudget – har inte körts av någon utanför de två företagen. Tills det har gjorts vilar beslutet på omfattning och licensiering, som går att känna till i dag, snarare än på noggrannhet, vilket inte går.

A generated two-column scoreboard titled 'LFM3-Omni-2B vs Ming-3.0-audio-tiny'. The left column lists 2.17B dense parameters, 2.17B active per token, image, video, audio and text input, 24 kHz speech output, English ASR word error rate 6.36 and a custom license. The right column lists 9.3B MoE parameters, 2.7B active per token, audio and text input, 44.1 kHz speech output, English ASR word error rate 4.36 and the MIT license, above a footer reading 'Vendor-reported; English ASR WER is the only directly comparable audio row.'