Liquid AI macht d1 Decision Models Open Source: Triage von Support-Tickets auf der CPU mit dem 600M-Modell
Liquid AI hat seine d1-Entscheidungsmodelle für Text, Vision und Audio offengelegt, darunter das kleine d1-omni-600M. Das Modell läuft auf einer normalen CPU und eignet sich etwa für das Vorfiltern von Support-Tickets, hat aber auch Grenzen, an denen es falsche Ergebnisse liefert.
Veröffentlicht am 9. Okt. • Zuerst erschienen auf yongboyu.hashnode.dev
Attributierter Compile plus ein kleiner echter CPU-Lauf Primärquellen (Liquid AI, 07.10.2026): Open d1: Edge decision models for text, vision, and audio (Liquid AI Blog), Multimodal open d1 decision models for the edge (Hugging Face Blog) sowie die Modellkarten für d1-3B und d1-omni-600M Hintergrund: Introducing d1: The most capable decision model, now with vision (Liquid AI, 05.10.2026) Alle Benchmark- und Latenzwerte für d1-3B stammen von Liquid AI. Die Zahlen, die ich für d1-omni-600M berichte, stammen aus einem einzigen Lauf auf einem geteilten Linux-Rechner mit 8 vCPUs und 12 Tickets, die ich selbst geschrieben habe. Das ist ein Smoke-Test, keine Evaluation.
Diese Woche hat Liquid AI zwei seiner d1-Entscheidungsmodelle auf Hugging Face als offene Gewichte veröffentlicht: d1-3B (Text plus Bilder) und ein experimentelles d1-omni-600M (Text plus Bilder oder Text plus Audio). Das geschah in derselben Woche, in der OpenAI seine Decisions API in die öffentliche Beta überführte, und die Diskussion auf X drehte sich schnell darum, solche Entscheidungen lokal auszuführen, statt pro Aufruf zu zahlen.
Die Idee ist einfach und für Backend-Leute interessanter als ein weiteres Chat-Modell. Ein decision model schreibt keinen Text. Man übergibt ihm einen Zustand (einen String, JSON, ein Bild) und eine Reihe benannter Fragen, und es liefert typisierte, kalibrierte Antworten in einem einzigen Forward-Pass, mit null Output-Tokens. Drei Fragetypen decken den größten Teil der Pipeline-Verkabelung ab:
Das ist genau die Form der Ticket-Router, Intent-Klassifikatoren und Moderationsprüfungen, die viele von uns derzeit mit einem LLM-Aufruf bauen, mit einem Prompt, der sagt "antworte nur mit JSON", und einem Parser, der auf das Beste hofft.
Aus dem Blog und den Modellkarten, kurz zusammengefasst:
Das 3B-Modell ist das, das Liquid pusht. Ich habe das 600M-Modell laufen lassen, aus einem banalen Grund: d1-3B braucht etwa 12 GB in float32 auf der CPU, und der Rechner, den ich verwendet habe, hatte etwa 6 GB frei. Wenn du eine GPU oder einen Mac mit M-Serie hast, fange mit dem 3B an.
Die Modellkarte des 600M-Modells verlangt transformers>=5.15 (die Karte des 3B sagt >=5.14). Also explizit pinnen:
python3 -m venv.venv &&..venv/bin/activate pip install --index-url https://download.pytorch.org/whl/cpu torch torchvision pip install "transformers>=5.15" pillow soundfile Enter fullscreen mode Exit fullscreen mode Dann beantwortet ein einziger Aufruf drei Fragen zum selben Ticket:
import torch from transformers import AutoModel model = AutoModel. from_pretrained ( " LiquidAI/d1-omni-600M ", trust_remote_code = True, dtype = torch. float32 ) questions = { " refund ": { " type ": " noul ", " instructions ": " Is the customer asking for a refund? " }, " team ": { " type ": " choice ", " instructions ": " Which team should handle this? ", " criteria ": { " billing ": " Charges, refunds, invoices ", " technical ": " App or site faults ", " fraud ": " Suspected unauthorised use ", }, }, " urgency ": { " type ": " score ", " instructions ": " How urgent is this?
", " criteria ": [ " Can wait ", " Today ", " Blocking the customer now " ], }, } out = model. system_one ( " I was charged twice for my October plan. Please refund the duplicate. ", questions ) print ( out [ " answers " ]) Enter fullscreen mode Exit fullscreen mode In meinem Lauf kam dieses Ticket als billing mit einer Konfidenz von 0.994 zurück, mit P(refund) = 0.999 und einem Dringlichkeitswert von 1.69 auf der Skala von 0 bis 2, unter Verwendung von 157 Input-Tokens und 0 Output-Tokens.
Zwei Hinweise aus der Modellkarte: auf der CPU float32 verwenden (das Modell wurde damit trainiert) und auf der GPU bfloat16 vermeiden, womit Liquid laut eigener Aussage bei einem kleinen Anteil der Zeilen die Top-Antwort umkippen ließ. trust_remote_code lädt zudem Python-Dateien aus dem Repository herunter, also pinne eine Revision, bevor du das irgendwo auslieferst.
Ich habe 12 kurze Support-Tickets mit ihren erwarteten Team- und Refund-Labels geschrieben, bevor ich irgendetwas laufen ließ: vier zu billing, vier zu technical, vier mit Betrugsbezug, darunter eine Phishing-E-Mail-Frage und ein gekapertes Konto.
Das sind CPU-Zahlen auf einem geteilten Xeon-Rechner, also behandle sie als "schnell genug für eine Hintergrund-Queue", nicht als Latenz-Benchmark. Zwölf einfache Tickets sagen auch nichts über deine Daten aus; der Punkt ist, dass die API-Form funktioniert und die Wahrscheinlichkeiten brauchbar sind.
Der nützlichere Teil war, wo die Konfidenz sank. Die Phishing-Frage ("Ich habe eine E-Mail bekommen, in der ich gebeten werde, meine Kartennummer auf einem komischen Link zu bestätigen. Ist das von euch?") ging zwar immer noch an fraud, aber nur mit 0.477. Das Ticket zum gekaperten Konto ging mit 0.633 an fraud. Genau das sind die Tickets, bei denen ich möchte, dass ein Mensch sie sieht, und das Konfidenzfeld markiert sie ohne jedes Prompt-Engineering.
Eine choice-Frage wählt immer eine deiner Optionen. Ich habe zwei Eingaben geschickt, die überhaupt keine Tickets sind:
Eine Konfidenzschwelle allein fängt also keinen Müll ab. Die naheliegende Lösung ist eine Sammeloption, also fügte ich "other": "None of the above, or not a real support request" hinzu sowie eine separate noul-Gate-Frage, "Is this a genuine customer support request?". Das behob den Müll: Das Wirrwarr wanderte zu other (0.663) mit P(request) = 0.004, und die Adressfrage wanderte zu other (0.896).
Dabei verschoben sich aber auch zwei echte Tickets. Mit verfügbarer other-Option ging die Phishing-Frage an other (0.603) und "Do you have a nonprofit discount?" an other (0.699) statt an billing. Die klaren Tickets (Doppelabbuchung, abstürzende App) blieben bei 0.90 oder höher. Eine Sammeloption zu ergänzen verschiebt die Entscheidungsgrenze für jede Grenzeingabe, nicht nur für den Müll.
Jahrelang war das Muster: ein LLM aufrufen, um JSON betteln und es parsen. Ein kleines Modell, das Wahrscheinlichkeiten in einem Durchgang zurückgibt, auf einer CPU läuft und pro Aufruf nichts kostet, ist eine echte Option für die langweiligen 80 Prozent der Klassifikationsarbeit. Es ersetzt kein Urteilsvermögen bei den schweren 20 Prozent, aber es sagt dir, welche Tickets das sind.
Die Skripte und die rohe Ausgabe dieses Laufs ( triage.py, other_option.py ) benötigen nur die obige pip-Installation und keinen API-Schlüssel.
YongBo Yu ist ein KI-Ingenieur in Toronto, der LLM-Workflows und Agentensysteme entwickelt. Mehr unter yongbo-yu.vercel.app und auf GitHub.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 9 • Originally published at yongboyu.hashnode.dev
Attributed compile + one small real CPU run Primary sources (Liquid AI, 2026-10-07): Open d1: Edge decision models for text, vision, and audio (Liquid AI blog), Multimodal open d1 decision models for the edge (Hugging Face blog), and the model cards for d1-3B and d1-omni-600M Background: Introducing d1: The most capable decision model, now with vision (Liquid AI, 2026-10-05) All benchmark and latency figures for d1-3B are Liquid AI's. The numbers I report for d1-omni-600M come from one run on a shared 8-vCPU Linux box with 12 tickets I wrote myself. That is a smoke test, not an evaluation.
This week Liquid AI put two of its d1 "decision models" on Hugging Face as open weights: d1-3B (text + images) and an experimental d1-omni-600M (text + images, or text + audio). It landed the same week OpenAI put its Decisions API into public beta, and the conversation on X quickly turned to running these decisions locally instead of paying per call.
The idea is simple and, for backend people, more interesting than another chat model. A decision model does not write text. You hand it a state (a string, JSON, an image) and a set of named questions, and it returns typed, calibrated answers in one forward pass, with zero output tokens. Three question types cover most pipeline glue:
That is exactly the shape of the ticket routers, intent classifiers, and moderation checks that a lot of us currently build with an LLM call, a prompt that says "answer only with JSON", and a parser that hopes for the best.
From the blog and model cards, in short:
The 3B model is the one Liquid is pushing. I ran the 600M one, for a boring reason: d1-3B wants about 12 GB in float32 on CPU, and the box I used had about 6 GB free. If you have a GPU or an M-series Mac, start with the 3B.
The 600M model card asks for transformers>=5.15 (the 3B card says >=5.14 ). so pin it explicitly:
python3 -m venv.venv &&..venv/bin/activate pip install --index-url https://download.pytorch.org/whl/cpu torch torchvision pip install "transformers>=5.15" pillow soundfile Enter fullscreen mode Exit fullscreen mode Then one call answers three questions over the same ticket:
import torch from transformers import AutoModel model = AutoModel. from_pretrained ( " LiquidAI/d1-omni-600M ", trust_remote_code = True, dtype = torch. float32 ) questions = { " refund ": { " type ": " noul ", " instructions ": " Is the customer asking for a refund? " }, " team ": { " type ": " choice ", " instructions ": " Which team should handle this? ", " criteria ": { " billing ": " Charges, refunds, invoices ", " technical ": " App or site faults ", " fraud ": " Suspected unauthorised use ", }, }, " urgency ": { " type ": " score ", " instructions ": " How urgent is this?
", " criteria ": [ " Can wait ", " Today ", " Blocking the customer now " ], }, } out = model. system_one ( " I was charged twice for my October plan. Please refund the duplicate. ", questions ) print ( out [ " answers " ]) Enter fullscreen mode Exit fullscreen mode On my run, that ticket came back as billing with confidence 0.994, P(refund) = 0.999, and an urgency score of 1.69 on the 0 to 2 scale, using 157 input tokens and 0 output tokens.
Two notes from the card: use float32 on CPU (the model was trained in it), and avoid bfloat16 on GPU, which Liquid says flipped the top answer on a small share of rows. trust_remote_code also downloads Python files from the repo, so pin a revision before you ship this anywhere.
I wrote 12 short support tickets and their expected team and refund labels before running anything: four billing, four technical, four fraud-ish, including a phishing email question and a hijacked account.
Those are CPU numbers on a shared Xeon box, so treat them as "fast enough for a background queue", not as a latency benchmark. Twelve easy tickets also say nothing about your data; the point is that the API shape works and the probabilities are usable.
The more useful part was where confidence dropped. The phishing question ("I got an email asking me to confirm my card number on a weird link. Is that you?") still went to fraud, but at 0.477. The hijacked-account ticket went to fraud at 0.633. Those are exactly the tickets I'd want a human to see, and the confidence field flags them without any prompt engineering.
A choice question always picks one of your options. I sent two inputs that are not tickets at all:
So a confidence threshold alone does not catch junk. The obvious fix is a catch-all option, so I added "other": "None of the above, or not a real support request" and a separate noul gate, "Is this a genuine customer support request?". That fixed the junk: the gibberish moved to other (0.663) with P(request) = 0.004, and the address question moved to other (0.896).
It also moved two real tickets. With other available, the phishing question went to other (0.603) and "Do you have a nonprofit discount?" went to other (0.699) instead of billing. The clear tickets (double charge, crashing app) stayed put at 0.90 or higher. Adding a catch-all moves the decision boundary for every borderline input, not just the junk.
For years the pattern has been to call an LLM, beg for JSON, and parse it. A small model that returns probabilities in one pass, runs on a CPU, and costs nothing per call is a real option for the boring 80% of classification work. It doesn't replace judgment on the hard 20%, but it tells you which tickets those are.
The scripts and raw output from this run ( triage.py, other_option.py ) need only the pip install above and no API key.
YongBo Yu is an AI engineer in Toronto building LLM workflows and agent systems. More at yongbo-yu.vercel.app and GitHub.