Kurz gesagt: Liquid AI hat mit LFM2.5-2.6B ein kleines, direkt lokal deploybares Modell für agentische Workflows veröffentlicht. Der interessante Teil ist nicht die Parameterzahl allein: 131.072 Token Kontext, Tool Calling und mehrere Laufzeitformate verschieben die Frage von „welches Cloud-Modell?“ zu „welcher Arbeitsschritt muss die Maschine überhaupt verlassen?“
Der Release ist am 4. August erschienen und bringt ein post-trainiertes Textmodell mit 2,69 Milliarden Parametern. Liquid positioniert es ausdrücklich für Tool Use und Edge- beziehungsweise lokale Ausführung – nicht als Ersatz für ein großes Coding- oder Recherchemodell.
Was tatsächlich neu ist
- 128K Kontext: Die Model Card nennt exakt 131.072 Token. Das ist für ein Modell dieser Größe genug, um längere Zustände, Dokumentenpakete oder Tool-Historien nicht sofort in eine externe Retrieval-Pipeline auslagern zu müssen.
- Tool Calls gehören zum Modellpfad: Das Chat-Template unterstützt Funktionsaufrufe; Liquid dokumentiert sowohl Python-artige Aufrufe als auch JSON-Ausgabe auf Anweisung. Für einen kleinen lokalen Executor ist das wichtiger als ein abstraktes „agentic“-Label.
- Mehr als ein Checkpoint: Neben nativen Gewichten stehen GGUF für
llama.cpp, ONNX für ONNX Runtime/WebGPU und MLX für Apple Silicon bereit. Das reduziert die sonst übliche Konvertierungsarbeit für lokale Tests und Geräte-Targets. - CPU ist ein vorgesehenes Ziel: Liquid gibt bis zu 113 Output-Token/s auf einem Ryzen AI Max+ 395 und einen Speicherbedarf unter 2,5 GB an. Das sind Herstellerangaben, keine unabhängigen Benchmarks – aber sie beschreiben die beabsichtigte Betriebsform klar.
Die Architektur ist kein gewöhnlicher Mini-Transformer
LFM2.5-2.6B besteht laut Model Card aus 30 Schichten: 22 Double-Gated-Short-Convolution-Blöcken und acht GQA-Blöcken (Grouped-Query Attention). Diese hybride Konstruktion erklärt, warum Liquid das Modell aggressiv für Inferenz auf begrenzter Hardware positioniert. Nicht jede Sequenzverarbeitung muss durch volle Attention laufen; zugleich bleiben Attention-Blöcke für globalere Abhängigkeiten erhalten.
Der praktische Reiz liegt nicht darin, einen Frontier-Agenten auf dem Laptop zu imitieren. Er liegt darin, die kleinen, klar abgegrenzten Tool-Schritte lokal auszuführen – Extraktion, Klassifikation, Routing oder eine kontrollierte RAG-Antwort.
Wo der Release im Stack sinnvoll ist
| Workload | Passt? | Warum |
|---|---|---|
| Dokumenten-Extraktion und strukturierte Ausgabe | Ja | Langer Kontext plus Tool-/JSON-Pfad sind direkt relevant. |
| Lokaler RAG-Responder | Ja, mit Evaluation | GGUF, ONNX und MLX verkürzen den Weg zu den üblichen lokalen Runtimes. |
| Agentischer Coding-Executor | Eher nicht | Liquid grenzt wissensintensive und anspruchsvolle Coding-Aufgaben selbst ab. |
| Autonome Web-Recherche | Mit Vorsicht | Tool Calling ersetzt weder Quellenbewertung noch Browser-Sandboxing. |
Der operative Test, den Teams jetzt machen sollten
Statt das Modell gegen einen generischen Chat-Benchmark zu fahren, lohnt sich ein enger Test mit einem echten Arbeitsschritt: eine feste Tool-Signatur, ein repräsentatives Dokumentenpaket und ein Schema-Validator hinter der Ausgabe. Entscheidend sind dabei nicht nur Tokens pro Sekunde, sondern Tool-Argument-Fehler, Kontextverlust nach mehreren Aufrufen und der Speicherbedarf im Zielruntime.
# bewusst enges Eval: gleiche Funktion, gleiches Schema, lokaler Runtime-Test
prompt = "Extrahiere Rechnungsnummer und Betrag. Nutze submit_invoice."
# messen: gültige Tool-Calls / Latenz / Peak-RAM / Fehler nach langem KontextFür lokale Agenten ist das ein vernünftiger Release: kein Modell, das alles verspricht, sondern ein Artefaktpaket für Workloads, die bisher unnötig in eine Cloud-API geroutet wurden. Die Herstellerwerte müssen sich erst in reproduzierbaren Setups bewähren. Aber die Kombination aus Kontextfenster, Tool Calling und verbreiteten Auslieferungsformaten macht LFM2.5-2.6B zu einem Kandidaten, den Infrastrukturteams diese Woche tatsächlich ausprobieren können.
Leave a Reply