Liquid AI veröffentlicht mit LFM2.5-VL-3B ein kompaktes Vision-Language-Modell für lokale Bild- und Bildschirmaufgaben. Der interessante Teil ist nicht eine neue Benchmark-Tabelle, sondern ein praxistauglicher Bereitstellungspfad: OCR, UI-/Layout-Verständnis, Grounding und Tool-Call-Vorschläge sollen in einem rund 3-GB-Modell auf Edge-Hardware laufen.
Was Liquid AI veröffentlicht hat
Der Hersteller veröffentlichte das Modell am 12. August 2026 auf Hugging Face. LFM2.5-VL-3B ist ein 3,1B-Parameter-Vision-Language-Modell. Liquid nennt Unterstützung für Screen Understanding, OCR, Objekt-Grounding, mehrbildrige Eingaben und Function Calling. Das zugehörige Repository dokumentiert ein Transformers-Checkpoint-Format; der Lizenzhinweis lautet lfm1.0, also keine Standard-Open-Source-Lizenz wie Apache-2.0.
Der operative Punkt: lokale Inferenz ist ein Runtime-Thema
Liquid nennt Unterstützung ab Veröffentlichung für llama.cpp, MLX, vLLM, SGLang und ONNX. Damit ist das Modell nicht an einen einzelnen Cloud- oder Python-Stack gebunden. Für Teams ist diese Runtime-Breite relevanter als ein einzelner Score: Derselbe visuelle Request kann in einem mobilen, lokalen oder serverseitigen Pfad evaluiert werden, ohne die Aufgabenklasse neu zu entwerfen.
| Pfad | Geeignete Aufgabe | Worauf achten? |
|---|---|---|
| Lokales Gerät | OCR, Screen Understanding, datensensible Bilder | Speicher, thermische Limits, Modell-Lizenz |
| Edge-Server | visuelle Qualitätsprüfung, Dokumentenfluss | Batching, Latenz und Bilddaten-Grenzen |
| Tool-Call-Pfad | strukturierte Aktionsvorschläge | Schema-Validierung und Autorisierung getrennt halten |
Die Performance-Zahlen bleiben Herstellerangaben: Liquid nennt etwa 3 GB Speicherbedarf sowie 20 Decode-Tokens pro Sekunde auf einem Galaxy S26 Ultra. Das ist ein nützlicher Anhaltspunkt für einen eigenen Hardware-Test, aber keine Zusage für andere Quantisierung, Bildgrößen oder Laufzeitumgebungen.
Tool Calling ist kein Ausführungsrecht
Gerade bei UI-Agenten ist die Trennung wichtig: Das Modell kann eine Aktion vorschlagen oder strukturierte Parameter erzeugen. Es sollte aber weder entscheiden dürfen, ob eine Aktion erlaubt ist, noch sie unmittelbar ausführen. Ein robuster Pfad hat mindestens drei getrennte Stufen:
- Modell: Bild oder Screen interpretieren und einen Tool-Call-Vorschlag erzeugen.
- Validator: Tool-Name und Parameter gegen ein Schema prüfen.
- Policy: Berechtigung, Zielsystem, Freigabe und Audit vor der Seiteneffekte-Ausführung entscheiden.
# Modell-Ausgabe bleibt untrusted input.
proposal = vlm.analyze(image, tools=tool_schema)
validated = validate_against_schema(proposal)
authorize_and_execute(validated, user, policy)Was Teams jetzt testen sollten
- Mit eigenen Screenshots und Dokumenten testen – insbesondere kleine Schrift, mehrere Fenster und mehrdeutige UI-Zustände.
- Runtime und Quantisierung explizit festlegen; ein nativer Checkpoint, GGUF und ONNX sind Deploymentsartefakte, keine identischen Betriebsprofile.
- Grounding und Tool-Parameter getrennt evaluieren: Ein korrekt erkanntes Objekt bedeutet nicht automatisch einen sicheren Aktionsparameter.
- Die Lizenz
lfm1.0vor Produktiv- oder kommerziellem Einsatz prüfen.
Einordnung: Kleine VLMs werden dann interessant, wenn sie nicht nur Bilder beschreiben, sondern an vorhandene Inferenzruntimes und kontrollierte Aktionspfade anschließen. LFM2.5-VL-3B liefert dafür ein klar abgegrenztes, jetzt testbares Artefakt. Ob die Herstellerwerte im eigenen Produkt tragen, entscheidet erst ein Test mit realen Screens, Geräten und Policy-Grenzen.
Quellen
- Liquid AI auf Hugging Face: LFM2.5-VL-3B for Better and Faster Vision Capabilities for the Edge (veröffentlicht am 12. August 2026, 14:00 UTC)
- LiquidAI/LFM2.5-VL-3B – offizielle Modellkarte und Artefakte
Leave a Reply