Liquid AI d1 vs Liquid AI d1-omni-600M: Den öppna beslutsmodellen som kan höra dig

Söker du efter namnet Liquid AI d1 så hamnar du på en modell med tre miljarder parametrar som läser text och bilder. Den andra öppna checkpointen i samma familj är en femtedel så stor, hanterar upp till trettio sekunder tal, och är den enda av de två som överhuvudtaget kan avgöra något om en röst. Den heter Liquid AI d1-omni-600M, och om du hittade familjen via ett lokalt runtime-bibliotek i stället för via leverantörens egen dokumentation, finns det en god chans att du aldrig har sett dess namn. Det är situationen som den här jämförelsen är till för att åtgärda, eftersom de två modellerna inte är konkurrerande svar på samma fråga. De är svar på två olika frågor, och bara en av dem handlar om att lyssna.

Varje siffra nedan kommer från Liquid AIs eget material: modellkortet för LiquidAI/d1-omni-600M, det medföljande repositoriet d1-omni-600M-GGUF och lanseringsinlägget den 7 oktober som tillkännagav båda öppna checkpoints samtidigt. Prestandaraderna poängsattes av leverantören på ett index som den själv underhåller i stället för att ha skickats in för offentlig rankning, och inlägget säger rent ut att dedikerade benchmarkar för ljudbeslut är ett öppet problem. Inget här har reproducerats av någon utanför labbet.

Vad 587 miljoner parametrar består av

Rubriksiffran döljer en ovanlig uppdelning. De totala parametrarna uppgår till 587M, och de utgör inte en enda stack: en delad stam på 381M med beslutshuvudet anslutet, en visionskodare på 94M och en ljudkodare på 112M. Varje modalitet passerar genom samma stamvikter, vilket är designbeslutet som håller alltihop litet — modellen är inte tre modeller i en trenchcoat, det är en beslutande stam med två sätt att mata den.

Delarna kommer från olika platser i Liquids katalog. Stommen härstammar från LFM2.5-Encoder-350M, en bidirektionell encoder, i stället för från den decoder-only-linje som det större syskonet kommer från. Visionstornet är en SigLIP2 hämtad från LFM2.5-VL-450M med en adapter och LoRA-uppdateringar applicerade på backbonen. Ljudvägen är en 17-lagers FastConformer-encoder med sin egen adapter, finjusterad mot en fryst text-backbone. Kortet rapporterar en kontext på 16 384 tokens som delas över text-, bild- och ljudpositioner tillsammans, med texten trimmad till 896 tokens när bilder finns med, och en vokabulär på 65 536 tokens – hälften av det större syskonets 128 000. Den sista siffran är värd att lägga märke till om du arbetar på ett språk som familjen bara delvis täcker.

Bidirektionell kontra endast dekoder är anledningen till att de två modellerna känns olika för alla som har kört båda. Den enkoderformade stammen läser hela tillståndet på en gång, i båda riktningarna, innan den producerar något. Den dekoderformade läser framåt på samma sätt som en språkmodell gör. Båda är tränade att rapportera svar utifrån en distribution med noll utdatatoken, så ingen av dem skriver text — men maskineriet under huven är en annan klass av modell, och noggrannhetsgapet som diskuteras nedan är den synliga kostnaden för den mindre, enkoderformade designen.

Trettio sekunder av tal, och ingenting att poängsätta det med.

Ljud är anledningen till att denna checkpoint finns. Den tar emot ett enda klipp på upp till 30 sekunder, 16 kHz mono, i samma framåtpassning som producerar svaret, och den är den enda medlemmen i familjen med öppna vikter som kan göra det. För arbete direkt på enheten är det inte en marginell funktion. En kamera som flaggar en defekt i en produktionslinje är ett datorseendeproblem som det större syskonet redan hanterar; en enhet som dirigerar en talad begäran, klassificerar ett yttrande eller avgör om en uppringare ber om återbetalning är ett problem som bara den här kan riktas mot.

Två begränsningar vilar på den förmågan och båda är dokumenterade, vilket innebär att det inte finns någon ursäkt för att snubbla över dem i produktion. För det första innehåller en begäran bilder eller ljud, aldrig båda — att skicka båda utlöser ett ValueError i stället för att tyst hoppa över en av dem, så felet är högljutt och billigt att hitta i testning. För det andra tränades ljudvägen på utbyten mellan en engelsktalande person och en assistent, med klippen kapade vid 30 sekunder. Det är en talargeometri, en turstruktur och en accentfördelning. Att rikta den mot callcenterinspelningar eller fältljud är att begära beteende som kortet inte gör anspråk på, och det är exakt den typ av lucka som ett benchmark skulle synliggöra om ett sådant fanns.

Inga sådana finns. Lanseringsinlägget kallar dedikerade benchmarks för ljudbeslut "för närvarande ett öppet problem" och uppmanar communityn att bygga ett, vilket är en uppriktig sak för ett labb att skriva och en verklig begränsning för alla som utvärderar modellen. Liquid AI d1-omni-600M ombeds motivera sig med styrkan hos en förmåga som ingen ännu kan mäta. Leverantören undanhöll dessutom helt och hållet inferenssiffror, med den angivna motiveringen att modellen är en tidig forskningsutgåva under aktiv utveckling. Så det finns ingen latenssiffra för 600M överhuvudtaget – inte för text, inte för vision och inte för ljudvägen som är hela poängen.

Det som kan sägas utan att hitta på någonting är aritmetik utifrån det publicerade parameterantalet: vid den float16-precision som kortet rekommenderar för GPU:er är 587M parametrar i storleksordningen 1,2 GB vikter före aktiveringar, mot ungefär 6,2 GB för 3,12B-syskonmodellen vid samma precision. Kortet har också en precisionsvarning som är lätt att förbise och som inte bör förbises: modellen tränades i float32, float16 rekommenderas på GPU:er, och bfloat16 ändrade det främsta svaret på vissa rader under testning. Om din serveringsstack använder bfloat16 som standard är detta en modell där den standarden inte är säker.

Varför familjens mindre hälft är lätt att missa

Anledningen till att en läsare hamnar vid 3B och stannar är strukturell snarare än tillfällig. Liquid AI:s dokumentationsindex listar tre rader under beslutsmodeller och de läses inte på samma sätt: d1-3B och d1-omni-600M har Hugging Face- och GGUF-länkar med ett "Nej" i kolumnen för träningsbarhet, medan d1 ligger i en egen rad med enbart bokstäverna "API" där alla andra modellers nedladdningslänkar skulle stå. Släppinlägget kallar d1 ett familjenamn och skiljer aldrig den serverade slutpunkten från den öppna checkpointen. Lokala runtime-bibliotek tar sedan 3B, eftersom det är den vars storlek och modalitetsantal matchar posten de vill publicera, och 600M förekommer inte alls i samma lista.

Resultatet är en familj vars publicerade åtkomsthistoria, snabbt läst, ser ut som en modell och en API-rad. Vad som faktiskt erbjuds är två öppna checkpoints med olika trunks, olika modaliteter och en 32-punktsskillnad mellan deras poäng på leverantörens eget index, plus en hostad endpoint vars förhållande till någon av checkpointarna leverantören aldrig har bekräftat. 600M är inte dold bakom någonting. Den har helt enkelt inget namn som en sökning på d1 kommer att få fram, och den är den enda av de två som hör.

Poängen som finns, och den enda kolumnen värd att läsa

På Decision Index 0.2.1 rapporterar leverantören 15,95 för Liquid AI d1-omni-600M mot 48,57 för sitt större syskon — en skillnad stor nog att summan är näst intill oanvändbar som grund för att välja. Delpoängen är mer informativa än summan, och en av dem är genuint överraskande.

• Kunskap — 8,3 mot 23,8

• Språk — 12,9 mot 56,4

• Hämtning — 35,0 mot 52,8

• Verktyg — 15,1 mot 74,5

• Konst — 6,8 mot 36,3

Retrieval är där den lilla modellen står sig, och förlorar mindre än en tredjedel av den större modellens poäng, medan den i de andra fyra kolumnerna förlorar 60 till 80 procent. Det mönstret matchar vad en tränad encoder borde vara bra på: att matcha ett tillstånd mot innehåll ligger nära det som stommen byggdes för, och det är mycket mindre beroende av den lageruppbyggda språkförmåga som det decoderformade syskonet ärvde från betydligt mer förträning. Kolumnen Verktyg är den motsatta historien, och en skillnad på 59 punkter där är siffran att stirra på om din arbetsbelastning går ut på att dirigera en begäran till rätt funktion.

På sju offentliga textbenchmarkar mjuknar bilden. Tillverkaren rapporterar ett medelvärde på 78,4 för 600M mot 82,9 för 3B, där den lilla modellen förlorar med knapp marginal på SQuAD 2.0 (74,0 mot 85,3), PubMedQA (61,3 mot 66,0), BoolQ (77,7 mot 86,7) och XNLI (74,7 mot 85,0), samtidigt som den vinner på Civil Comments toxicitetsdetektering (95,8 mot 93,0) och PAWS-X parafrasidentifiering (79,5 mot 76,9). Liquids egen formulering är att 600M slår en 2B-beslutsmodells medelvärde på 77,1 med en fjärdedel av parametrarna. Två benchmark-sviter ger två olika skenbara utfall, båda självrapporterade, och den ärliga tolkningen är att ingen av dem avgör något om ljudvägen, eftersom ljudvägen inte ingår i någon av sviterna.

Där de två faktiskt möts

Trots all divergens är programmeringsmodellen identisk, och det är vad som gör dem utbytbara i en specifik bemärkelse. Båda besvarar noul-, val- och poängfrågor över ett tillstånd, båda returnerar det valda svaret med en sannolikhetskarta och ett konfidensvärde mellan 0 och 1, och båda rapporterar output_tokens: 0. Konfidensfältet är det fält som folk misstolkar: det mäter hur starkt sannolikheterna talar för ett svar, inte sannolikheten att svaret är korrekt. En 0,96 på en dåligt formulerad fråga är ett säkert felaktigt svar, och fältet kommer inte att varna dig.

Där de möts i praktiken är en kaskad. Gallra med Liquid AI d1-omni-600M — billigt, lokalt och inklusive de ljudfall som ingen textbaserad bedömare kan hantera — eskalera sedan de poster den placerar nära mitten av sin skala till det större checkpointet för ett skarpare besked. Eskaleringsreglerna är den konfidens och den fördelning som 600M redan returnerar, så routningslogiken behöver ingen extra modell, och i en arbetsbelastning med en stark majoritet av enkla poster når merparten av trafiken aldrig det andra steget. Den sammansättningen fungerar eftersom båda modellerna returnerar samma typ av objekt. Två godtyckliga modeller skulle inte göra det.

Om den där kaskaden någonsin släpper igenom ett anrop till en generativ modell som du hyr i stället för att köra, är det underliggande lagret där rörmokeriet blir intressant, och det är också där vi kommer in. Att routa ett beslut genom en kedja av modeller är precis den typ av problem som en routingregel är till för: OrcaRouter sammanställer flera modeller bakom en OpenAI-kompatibel endpoint, var och en till sin leverantörs listpris vidarebefordrat med 0 % påslag, med automatisk failover mellan leverantörer så att en eskalering som misslyckas på leverantörsnivå gör ett nytt försök på en fallback i stället för att misslyckas med begäran. Vi driftar ingen Liquid AI-modell – vi kollade innan vi skrev detta – så inget ovan är ett påstående om att anropa dessa vikter via oss. Poängen är att beslutsmodellen är den billiga delen av pipelinen och den lånade modellen på andra sidan är den del som går ner.

Var filen kommer ifrån, om du vill köra den idag

För lokal driftsättning levererar leverantörens eget GGUF-förråd för 600M Q8_0 vid 407 MB samt F16 och BF16 vid 764 MB vardera, utan någon listad 4-bitarsversion — så den minsta officiella nedladdningen är ungefär sju gånger mindre än motsvarande byggversion av den större modellen och ungefär lika stor som ett medelupplöst fotografi. Kortets eget exempel startar en llama.cpp-server med batchflaggor på 4096 och föreslår att höja dem till 16384 för längre tillstånd, och frågar sedan samma /v1/systemone-slutpunkt som det större syskonet använder.

Det enda den lokala vägen inte ger dig är ljudvägens siffror, eftersom de inte finns. Om du tänker köra tal genom detta inför riktiga användare är utvärderingen din att bygga: en märkt uppsättning klipp, samma tre frågetyper och en uppmätt svarsfrekvens per klass. Det är inte att avfärda modellen – en 587M-checkpoint som fattar beslut om ett röstklipp i ett enda pass är ett genuint annat verktyg än en textklassificerare som skruvats fast på ett transkriberingssteg, och den förtjänar ett riktigt test snarare än ett vibesbaserat.

Om den kaskaden någonsin styr ett anrop till en generativ modell som du hyr i stället för att köra själv, OrcaRouter komponerar flera modeller bakom en enda OpenAI-kompatibel slutpunkt, där var och en förmedlas till respektive leverantörs listpris med 0 % påslag.

Att välja en omni-checkpoint framför den textbaserade är också ett bra tillfälle att titta på vad som redan har gått fel i den här klassen: de dokumenterade AI-incidenterna och agentmisslyckandena som involverar små multimodala modeller samlas i the OrcaRouter AI Incident Archive, där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och flagga för omtvistade uppgifter.