Liquid AI d1-omni-600M vs Liquid AI d1-3B: Vilken halva av d1-familjen behöver du egentligen?

Liquid AI d1-omni-600M och Liquid AI d1-3B laddades upp till Hugging Face inom åtta timmar från varandra den 5 oktober 2026 och släpptes tillsammans i samma tillkännagivande den 7 oktober, vilket gör den vanliga frågan – vilken är nyare, vilken är bättre – till fel fråga. De är de två ändarna av en avsiktlig avvägning. Liquid AI d1-3B är den färdiga produkten: 3,12B parametrar, en 48,57 på den leverantörsbedömda Decision Index 0.2.1, benchmarktabeller, latens mätt ner till en Jetson Orin Nano, och en plats som i releaseinlägget beskrivs som den högsta beslutskvaliteten i sin storlek. Liquid AI d1-omni-600M är experimentet: 587M parametrar, en 15,95 på samma index, ljudinmatning som 3B inte har, och ett modellkort som rakt ut säger att det är en tidig forskningsrelease utan inferenssiffror eftersom den fortfarande är under aktiv utveckling. Att välja mellan dem är inte ett kvalitetsbeslut. Det är ett beslut om huruvida du behöver de extra modaliteterna längst ner i familjen eller den extra noggrannheten högst upp, och siffrorna ställer sig bakom den uppdelningen snarare än att sudda ut den.

Allt nedan kommer från de två modellkorten och releaseinlägget från den 7 oktober, med releaseinläggets egen märkning respekterad: d1-raderna i Decision Index poängsattes av Liquid AI med den officiella poängsättaren i stället för att skickas in till den offentliga resultattavlan, och inget här har oberoende reproducerats.

Två stamnät som aldrig skulle konvergera

d1-familjen skalade inte ned ett enda recept. De två checkpoints utgår från motsatta ändar av Liquids modellkatalog och möts i mitten.

Liquid AI d1-3B är byggd ovanpå LFM2.5-VL-3B, leverantörens dekoderbaserade bild- och språkmodell från augusti 2026. Dess bas skapades genom att medelvärdesberäkna vikterna för LFM2.5-2.6B med textryggraden i LFM2.5-VL-3B och därefter finjustera checkpoints under olika slumpmässiga seedningar och datablandningar innan de slogs samman igen. Den har en SigLIP2 NaFlex-formoptimerad 400M-visionsencoder, en kontext på 32 768 token, en vokabulär på 128 000 token och sexton dokumenterade språk.

Liquid AI d1-omni-600M kommer från det andra hållet. Dess stam är LFM2.5-Encoder-350M, en dubbelriktad encoder, först finjusterad på beslutsuppgifter och sedan utökad i etapper – en 17-lagers FastConformer-encoder plus en adapter för ljud, där ljudencodern senare finjusterades mot en fryst text-backbone, sedan ett SigLIP2-torn lyft från LFM2.5-VL-450M med en adapter och LoRA-uppdateringar av backbonen för vision. Den slutliga modellen slogs samman från LoRA-uppdateringarna och medelvärdesbildades med den föregående checkpointen. Den hamnar på totalt 587M parametrar: en delad stam och ett beslutshuvud på 381M, en visionsencoder på 94M och en ljudencoder på 112M.

Decoder-only kontra dubbelriktad är det man ska hålla fast vid. 3B läser ett tillstånd och fattar ett beslut så som en språkmodell producerar en tokensekvens, en riktning i taget. 600M läser hela tillståndet på en gång och fattar beslut, vilket är vad man kan förvänta sig av en encoder som aldrig byggdes för att generera. Båda är tränade att rapportera svar utifrån modellens distribution med noll utdatatoken, men maskineriet under huven är inte samma modellklass, och noggrannhetsgapet nedan är den synliga kostnaden för den mindre, encoder-formade designen.

Spridningen i Decision Index är stor, och delpoängen är mer intressanta än totalen.

På Decision Index 0.2.1 rapporterar Liquid 48,57 för Liquid AI d1-3B och 15,95 för Liquid AI d1-omni-600M, mot 50,02 för Winnow-12B. Det är en skillnad på 32 punkter mellan två checkpoints som släpptes samma dag av samma labb, och att läsa de fem delpoängen förklarar varifrån den kommer.

• Kunskap — 23,8 för Liquid AI d1-3B mot 8,3 för Liquid AI d1-omni-600M

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

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

• Verktyg — 74,5 mot 15,1

• Konst — 36,3 mot 6,8

Retrieval är det enda område där den lilla modellen håller stånd, med ett tapp på mindre än en tredjedel av 3B:s poäng, medan den i de andra fyra kategorierna tappar 60 till 80 procent. Det mönstret stämmer överens med vad 600M är: en tränad encoder med verklig representationskapacitet för att matcha ett tillstånd mot innehåll, och mycket mindre av den skiktade förmåga som 3B ärver från en decoder som förtränats på långt mer språk. Om din arbetsbelastning är ett retrieval-liknande beslut – besvarar detta stycke den här frågan, vilket av dessa dokument är relevant – är 600M:s profil mindre dålig än vad dess totala resultat antyder. Om din arbetsbelastning är ett verktygsroutningsbeslut är gapet på 51 punkter i den kolumnen siffran att stirra på.

Textbenchmark-tabellen berättar en mildare historia än indexet, vilket är värt att veta innan något av siffrorna används för att argumentera för en tes. På sju offentliga benchmarkar leder 3B med ett medelvärde på 82,9 och 600M når 78,4. 600M förlorar faktiskt 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), men den vinner på Civil Comments toxicitetsdetektering (95,8 mot 93,0) och på PAWS-X parafrasidentifiering (79,5 mot 76,9). Liquids egen formulering är att 600M slår Decider 2B:s medelvärde på 77,1 med bara en fjärdedel av parametrarna. Två benchmark-sviter, två olika skenbara slutsatser, båda leverantörsrapporterade – det är vad bevisen stöder, och inte mer.

Vad 600M har som 3B inte har

Anledningen till att tolerera ett indexgap på 32 punkter är att Liquid AI d1-omni-600M gör en sak som Liquid AI d1-3B inte kan, och det är inte en skillnad i återgivningstrohet.

• Ljud — Liquid AI d1-omni-600M tar upp till 30 sekunder tal per begäran genom sin FastConformer-kodare; Liquid AI d1-3B tar inga

• Modalitetsmixning — 600M tar emot text med bilder eller text med ljud och kastar ett ValueError om båda kommer samtidigt; 3B tar emot text och bilder

• Kontextfönster – 16 384 tokens över text-, bild- och ljudpositioner för 600M, med texten trimmad till 896 tokens när bilder finns; 32 768 tokens för 3B

• Ordförråd — 65 536 för 600M, 128 000 för 3B

• Precision – 600M-kortet rekommenderar float16 på GPU och varnar för att bfloat16 ändrade toppsvaret på vissa rader; 3B:n levereras med 15 kvantiseringar, inklusive en w8a8-version

• Språk – 600M listar 16 språk i en annan uppsättning än 3B:s 16, och dess ljud beskrivs som tränat på utbyten mellan en engelsktalande person och en assistent, vilket är en snäv del av vad ett produktionsljudflöde innehåller

Anteckningen om ljudträning är lätt att ögna förbi, och det borde den inte vara. En modell tränad på engelska utbyten mellan talare och assistent har sett en talargeometri, en struktur för turtagning och en accentfördelning. Att driftsätta den på callcenterljud eller fältinspelningar är att be om ett beteende som modellkortet inte gör anspråk på, och lanseringsinlägget är uppriktigt om att det inte finns något benchmark för ljudbeslut att kontrollera den mot – Liquid kallar det "för närvarande ett öppet problem" och bjuder in gemenskapen att bygga ett.

Latens: det ena syskonet har tabellerna, det andra har en fotnot

För beslutsmodeller är den intressanta siffran end-to-end-latens, eftersom det inte finns någon avkodning att ta tid på. Liquid publicerar en fullständig uppsättning för 3B och ingen för 600M.

• En fråga — 8 ms på en RTX 4090, 9 ms på en MI325X, 16 ms på en Jetson AGX Thor, 26 ms på en Jetson AGX Orin 64 GB, 50 ms på en Orin Nano, 30 ms på en Apple M5 Pro

• Tre frågor över ett tillstånd – 21 ms på RTX 4090 och 20 ms på AGX Thor, ungefär 1,3x kostnaden för en enda fråga snarare än 3x

• Ett tillstånd på 3,4K token – 102 ms på 4090, 220 ms på Thor, 1 640 ms på Orin Nano

• Packad genomströmning — 475 beslut per sekund på RTX 4090, 1 106 per sekund på MI325X

• En 384px-bild — 17 ms på 4090, 18 ms på MI325X

De siffrorna beskriver endast Liquid AI d1-3B. För Liquid AI d1-omni-600M anger modellkortet att inferenssiffror inte rapporteras eftersom modellen är en tidig forskningsversion under aktiv utveckling. Det är inte så att den lilla modellen är långsammare — det motsatta är nästan säkert, eftersom en femtedel av parametrarna inte blir långsammare vid samma precision — det är att ingen siffra finns, och att citera 3B:ns millisekunder för 600M skulle vara en fabricering med en trovärdig form. Vad som kan sägas utan att hitta på något är att vid den float16-precision som kortet rekommenderar är 587M parametrar i storleksordningen 1,2 GB vikter före aktiveringar, vilket är aritmetik på ett publicerat parameterantal snarare än en mätning.

Kaskaden är det verkliga svaret för de flesta arbetsbelastningar

Eftersom båda checkpoints släpptes tillsammans och returnerar samma typ av objekt – en sannolikhet, en etikett med en konfidens eller en ordnad poäng – komponerar de på ett sätt som två godtyckliga modeller inte gör. 600M kan gallra och 3B kan döma. Poängsätt inkommande objekt med Liquid AI d1-omni-600M och eskalera de som den placerar nära mitten av sin skala till Liquid AI d1-3B för ett skarpare beslut. Eskaleringsreglerna är konfidensen och fördelningen som 600M redan returnerar, så routningslogiken behöver ingen extra modell. På en arbetsbelastning med en stark majoritet enkla objekt når det mesta av trafiken aldrig 3B och spenderas det mesta av pengarna aldrig.

Det mönstret är också anledningen till att de två modellerna är värda att köra bakom en router. Via OrcaRouter skulle båda ligga bakom en enda API-nyckel till varje leverantörs listpris vidarebefordrat med 0 % påslag, så kaskaden är en routingregel snarare än en andra integration, och en eskalering som misslyckas på leverantörsnivån görs om mot en reservlösning i stället för att begäran misslyckas. Automatisk redundans spelar större roll här än för en etablerad modell, eftersom den ena halvan av det här paret är en checkpoint vars beteende leverantören själv beskriver som under aktiv utveckling.

Inget av det är ett påstående om tillgänglighet, och distinktionen förtjänar att sägas rakt ut: de öppna d1-checkpointarna finns inte i vår katalog. Leverantörens väg är att ladda ner vikterna och köra dem lokalt – llama.cpp-stöd fanns från dag ett för hårdvara från Apple, AMD, Qualcomm och NVIDIA – eller att nå dem via leverantörens eget API och tredjepartsplattformar.

Att välja, i ett svep

Om du behöver text och bilder, och svaret måste vara rätt, välj Liquid AI d1-3B. Den har benchmarkarna, latens-tabellerna, den bredare kontexten, det större ordförrådet och kvantiseringarna, och det är den av de två som Liquid positionerar som kvalitetsledare i sin storleksklass.

Om du behöver tal i beslutsvägen ska du ta Liquid AI d1-omni-600M, eftersom det är det enda öppenviktsalternativet i den här familjen som överhuvudtaget tar emot ljud, och acceptera att du antar det på magkänsla och en demo tills någon publicerar ett benchmark för ljudbeslut eller den undanhållna vision-splitten.

Om du ännu inte vet vilken av dessa som beskriver din arbetsbelastning börjar du med 3B och instrumenterar den konfidens den returnerar. Delpoängen är avslöjandet: en uppgift som hör hemma i kolumnerna Tools eller Language kommer att bli illa betjänad av 600M, medan något retrivalformat är det enda stället där den lilla checkpoints ligger närmare än vad dess total antyder. Familjen finns för att du ska kunna byta noggrannhet mot fotavtryck, och bytet är bara säkert om du vet vilken kolumn din uppgift tillhör.

Via OrcaRouter ligger båda modellerna bakom en enda API-nyckel vid en routingregel snarare än en andra integration och en eskalering som misslyckas i leverantörslagret görs om mot en fallback i stället för att förfrågan misslyckas.