d1-2B vs Liquid AI d1-omni-600M: När den avgörande indatan är ljud

Lägg ett röstmeddelande och en fotograferad faktura framför dessa två modeller, och bara en av dem kan svara – och det är inte den med bättre poäng. d1-2B läser text, JSON, bilder och video och kan inte ta emot ljud alls. Liquid AI d1-omni-600M läser text med bilder eller text med upp till 30 sekunders tal, och kan inte ta emot ljud och bilder i samma förfrågan. Den enda asymmetrin avgör de flesta verkliga driftsättningar innan någon av benchmarkarna konsulteras. Det som följer är ändå den ärliga versionen av jämförelsen: var 587M-modellen är genuint konkurrenskraftig, där 1,92B-modellen inte är i närheten av att vara utbytbar, och det enda pipeline-mönstret som använder båda utan att låtsas att de är alternativ.

Beslutet är en modalitetsfråga, inte en poängfråga.

En beslutsmodell tar ett tillstånd och en uppsättning namngivna frågor och returnerar en sannolikhet per svar, utan genererade token. Tillståndet är hela indata, och tillståndets typ är den bindande begränsningen. d1-2B:s kort listar text, JSON, bilder och video. Liquid AI d1-omni-600M:s kort listar text med bilder, eller text med ljud — och koden framtvingar uteslutningen: att skicka både en bild och ett ljudklipp till system_one kastar ett ValueError.

Så den första frågan är inte vilken modell som får högre poäng. Det är om det du behöver bedöma kommer som pixlar, som text eller som en vågform. Om det kommer som en vågform finns det ett svar i det här paret, och resten av den här sidan handlar om hur mycket noggrannhet du ger upp för att få det.

Vad 587M faktiskt köper

600M är inte en mindre version av d1-2B. Den är en annan konstruktion, och det är värt att se budgeten specificerad post för post eftersom den förklarar både dess styrkor och dess tak.

• Parametrar — 587M totalt: en delad stam och beslutsdel på 381M, en visionskodare på 94M och en ljudkodare på 112M. Varje modalitet går genom samma stamvikter.

• Base — LFM2.5-Encoder-350M, en dubbelriktad encoder, med ett SigLIP2-visionstorn lånat från LFM2.5-VL-450M och en 17-lagers FastConformer för ljud.

• Kontext — 16 384 token fördelade över text-, bild- och ljudpositioner tillsammans, och ett ordförråd på 65 536 token. d1-2B:s fönster är 128K.

• Ljud — upp till 30 sekunder av 16 kHz monotal per begäran. Kortet säger uttryckligen att ljudsidan tränades på förfrågningar mellan en engelsktalande talare och en assistent, vilket är en snäv fördelning för en modell som människor kommer att rikta mot samtalsinspelningar.

• Medieregel — bilder eller ljud, aldrig båda. Kortet dokumenterar ValueError i stället för att låta dig upptäcka det.

• Licens — LFM Open License v1.0, samma tröskelstruktur som d1-2B: kommersiell användning under 10 000 000 USD i årlig omsättning.

• Hastighet — inte publicerad. Kortet anger inga latenssiffror och kallar modellen en tidig forskningsversion under aktiv utveckling. d1-2B publicerar 5,7 ms på ett H100 PCIe, 3,8 ms på ett MI325X och 18,6 ms på en M5 Pro.

Tabellen för samma körning, och raderna där gapet är litet

Båda modellerna förekommer i benchmarktabellen på d1-2B:s kort, som poängsätter fyra öppna d1-modeller på identiska uppgifter med en identisk poängsättare. Det gör jämförelsen renare än de flesta jämförelser mellan kort, med ett förbehåll: d1-omni-600M:s eget kort rapporterar 15,95 på Decision Index 0.2.1, medan den här tabellen rapporterar 18,3 på version 0.3. Skillnaden är indexutgåvan, och båda siffrorna är korrekta för respektive test.

• Decision Index offentlig svit v0.3 — 51,1 för d1-2B mot 18,3 för Liquid AI d1-omni-600M.

• DecisionBench (Hanno Labs) v1 — 77,1 mot 58,7.

• Decision Bench (decisionbench.ai) v4 — 85,2 mot 57,9.

• ImajevBench v2.0-lite — 75,5 mot 21,7, den största skillnaden på beslutsdelen mellan de två.

• WorkflowEvals — 81,6 mot 48,8.

• Vision-genomsnitt, 18 benchmarkar — 70,2 mot 42,8.

• VisualWebBench — 96,2 mot 14,9, vilket är mindre en jämförelse än ett uttalande om hur mycket en visionsencoder på 94M kan bära.

Sedan raderna som talar för återhållsamhet. Typed Decisions är 61,3 mot 57,5 – en skillnad på 3,8 punkter för en modell med en tredjedel av parametrarna. POPE, benchmarken för objekthallucination, är 88,7 mot 82,7. JevBench är 77,9 mot 58,0, en stor skillnad, men DecisionBench v4 är 85,2 mot 57,9, och de två tillsammans säger att 600M är ojämn snarare än enhetligt svag. Liquid AI:s eget lanseringsinlägg anger sitt medelvärde för sju benchmarkar till 78,4, vilket är högt för 587M; d1-2B:s modellkort publicerar inte ett motsvarande medelvärde, så de två siffrorna bör inte ställas sida vid sida.

Det enda talet som inte smickrar någon av modellerna är det oberoende. Efraín Garay körde Liquid AI d1-omni-600M på ett urval på 6 000 förfrågningar från Decision Index 0.3 och fick 14,0, mot leverantörens egen 14,17 på samma urval – en nära reproduktion. Han fann också att 1 758 förfrågningar överskred modellens instruktions- och alternativbudget och avvisades, räknades som fel, vilket är en verklig kostnad för ett 16K-fönster i en svit byggd för längre tillstånd.

Där 600M är det enda alternativet

Ljudrouting är det fall som modellen byggdes för, och kortets exempel är konkreta: routing av samtal och röstmeddelanden, ljudevenemang, talade instruktioner över ett skrivet tillstånd. Inget av det är tillgängligt från d1-2B med någon som helst noggrannhet, eftersom den saknar ljudkodare och inte har några ljudpositioner i sitt indataschema.

Två oberoende datapunkter bör tona ner säljsnacket. Den första är utvärderingen ovan, där 600M fick en AUC på 0,580 för shots-detektion och en AUC på 0,593 för regnprognos på uppgifter med verkliga data – knappt över slumpnivå och sämre än varje större modell som testades. Den andra är en praktisk recension som uppmätte under 2 GB VRAM i användning och fann att modellen klassificerade framförande och ton i ljud långt mer tillförlitligt än semantisk betydelse, medan inferensliknande frågor låg nära en slantsingling. Båda pekar åt samma håll: detta är en screeningmodell. Den är bra på "vad är detta för typ av sak", och den är ingen ersättning för en modell som förstår vad som sades.

Det är inte en kritik av en 587M-checkpoint. Det är vad 587M köper när 381M av det är delad stam. Anledningen att använda den är kostnad och fotavtryck — under 2GB VRAM, ett GGUF-repositorium sedan 6 oktober, MLX-byggen sedan 12 oktober och ett beslut i en enda framåtpassning — inte trohet.

En kaskad som använder båda

Misstaget är att behandla dessa som konkurrenter. De är två steg i samma filter, och den naturliga pipelinen kör den billiga modellen först.

Steg ett: {{1}}Liquid AI d1-omni-600M{{/1}} tar emot det inkommande ärendet – ett röstmeddelande, ett supportsamtal, ett skriftligt klagomål med en bilaga – och besvarar översiktliga frågor. Är detta ett faktureringsproblem eller ett tekniskt problem? Är den som ringer arg? Innehåller det här meddelandet ens en begäran? Med under 2 GB och en enda genomkörning är det billigt nog att köra på varje ärende.

Steg två: allt som 600M placerar nära mitten av sin skala, eller allt som kommer med en bild som behöver läsas, eskalerar till d1-2B. 2B får ett 128K-fönster, videoinmatning och ungefär tre gånger genomsnittet för syn, och det ser bara den andel av trafiken som det första steget inte kunde avgöra.

Trösklarna är själva arbetet. Båda korten returnerar sannolikheter, och båda säger åt dig att kalibrera mot dina egna data – d1-2B:s kort säger det rent ut. En kaskad med ett okalibrerat mittenband eskalerar antingen allt, och då var 600M bara dekoration, eller inget, och då korrigerar 2B aldrig steget som inte kan läsa.

Det finns ett tredje steg i de flesta verkliga system: modellen som skriver svaret. Det är där ett hostat API kommer in, och där OrcaRouter är relevant. Ingen av Liquid AI-modellerna serveras av oss, så beslutsnoderna stannar på din egen GPU; det generativa steget som konsumerar deras etiketter kan komma från en OpenAI-kompatibel nyckel som täcker över 200 modeller, med 0 % påslag på leverantörernas listpriser och automatisk failover om en leverantör faller bort mitt i trafiken. Routing-DSL:en är också det ärliga sättet att uttrycka själva kaskaden — de två beslutsmodellerna som GPU-sidiga steg, svarsgenereringen som ett hostat steg, sammansatta i stället för ihopklistrade i applikationskoden.

Vad ingen av modellerna gör, och det tredje alternativet

Ingen av dem skriver text. Båda returnerar typade svar och sannolikheter med noll utdatatoken; om nästa steg behöver prosa är det en annan modell. Ingen av dem hanterar video med ljud: d1-2B tar videobilder men inget ljud, 600M tar ljud men inte tillsammans med bilder, och taket på 30 sekunder för ljud är en hård gräns snarare än en rekommendation.

Om kravet verkligen är "ljud och bilder i samma förfrågan" är svaret ingendera av dessa – det är d1-Omni-2B, 2.17B-syskonmodellen som Liquid AI skapade tjugofyra sekunder efter d1-2B och som accepterar text, bilder, videorutor och ljudklipp i en och samma medialista. Dess Decision Index-poäng är 49.0 i samma v0.3-tabell, dess genomsnitt för vision är 67.7, och den har samma avsaknad av oberoende tester som d1-2B. Den kostar ungefär fyra gånger parametrarna för 600M, vilket är priset för att inte behöva välja mellan modaliteter.

Så regeln är kort. Om tillståndet innehåller tal och inget annat behöver ses, är Liquid AI d1-omni-600M den enda medlemmen i det här paret som kan köras, och den bör behandlas som en skärm. Om tillståndet är text, bilder eller video och svaret måste hålla, är d1-2B modellen – och det är den som har en publicerad latenssiffra, ett 128K-fönster och ett benchmarkförsprång som håller när det läses rad för rad. Om tillståndet har båda är ingen av dem svaret, och det är 2.17B omni-modellen.