Liquid AI stellt mit LFM2.5-24B-A2B ein neues lokales Reasoning-Modell für werkzeuggestützte Agenten bereit. Dadurch wird der gesamte Arbeitsablauf nicht automatisch privat. Für Unternehmen in Deutschland muss die Abnahme den vollständigen Auftrag umfassen: Modellendpunkt, Werkzeugprozesse, Retrieval, Protokollierung und Ausweichrouten. Geben Sie einen lokalen Pilotbetrieb erst frei, wenn diese Datengrenze beobachtbar und technisch durchgesetzt ist – nicht allein deshalb, weil die Modelladresse auf localhost zeigt.
Was sich mit dieser Veröffentlichung ändert
Am 13. Oktober 2026 hat Liquid AI LFM2.5-24B-A2B veröffentlicht. Basis- und nachtrainierte Gewichte stehen zum Download bereit. Die Modellkarte beschreibt ein reines Textmodell mit insgesamt 24 Milliarden Parametern und ungefähr zwei Milliarden aktiven Parametern pro Token. Der Schwerpunkt liegt auf Reasoning und Werkzeugnutzung, nicht auf Bildverarbeitung. Es handelt sich weder um die frühere Vision-Language-DSpark-Veröffentlichung noch um deren Hilfsmodell für spekulatives Decoding.
Gegenüber LFM2-24B-A2B bleibt die hybride MoE-Architektur aus Faltungen und Attention bestehen. Das Kontextfenster wächst von 32.768 auf 131.072 Token, das Vokabular von ungefähr 65.000 auf 128.000 Token. Für die Integration ist besonders relevant: Das neue Modell arbeitet ausschließlich mit Reasoning. Seine Chat-Vorlage beginnt eine Assistentenantwort mit einem Reasoning-Tag. Ein Client, der unmittelbar anzeigbaren Text oder einen Werkzeugaufruf erwartet, muss diese Struktur korrekt verarbeiten.
Liquid AI nennt Unterstützung für llama.cpp, MLX, vLLM, SGLang und ONNX. Die Modellkarte verlinkt GGUF-, FP8-, MLX- und ONNX-Varianten, kennzeichnet das eigene DSpark-Hilfsmodell jedoch als „coming soon“. Planen Sie keine Wirtschaftlichkeit mit einem noch nicht verfügbaren Hilfsmodell. Fixieren Sie Modellrevision, Tokenizer, Chat-Vorlage, Präzision und Serving-Build gemeinsam. Der Familienname allein beschreibt keine reproduzierbare Bereitstellung.
Zugang, kommerzielle Bedingungen und die gehostete Alternative
Die Gewichte lassen sich über Hugging Face für kundenseitig kontrollierte Hardware beziehen. Damit entsteht eine Alternative zur Übertragung von Prompts an einen gehosteten Inferenzdienst. Daraus folgt jedoch keine vertragliche Zusage über Verarbeitung in Deutschland, Support oder sämtliche Komponenten einer Agentenanwendung. Hardwarekapazität und Laufzeitkompatibilität müssen Sie auf dem vorgesehenen Gerät prüfen.
Für Liquid Console nennt die Ankündigung außerdem US$0,10 pro Million Eingabetoken, US$0,05 pro Million gecachter Eingabetoken und US$1,00 pro Million Ausgabetoken. Das sind die zum Prüfzeitpunkt veröffentlichten API-Preise des Anbieters: keine Kostenschätzung für lokalen Betrieb und keine Zusage zur Verarbeitungsregion. Lokale Inferenz ersetzt Tokenrechnungen durch Hardware-, Energie-, Kapazitäts- und Wartungsaufwand. Ein gehosteter Ausweichweg verändert die Datenflussentscheidung, auch wenn er die Verfügbarkeit verbessert.
Die LFM Open License v1.0 im Repository enthält eine Einschränkung kommerzieller Nutzung und definiert einen Schwellenwert von US$10 Millionen Jahresumsatz. Auch die Definition der juristischen Einheit ist relevant. Leiten Sie aus der Formulierung „without restrictions“ in der Ankündigung keine uneingeschränkten kommerziellen Unternehmensrechte ab. Lassen Sie die genaue Schwellenwertformulierung, den organisatorischen Geltungsbereich und Ihre Nutzung rechtlich prüfen; beschaffen Sie bei Bedarf passende Vertragsbedingungen. Die geprüften Quellen nennen keinen Preis für eine separate Unternehmensvereinbarung. Dies ist ein Beschaffungsprüfpunkt, keine Rechtsberatung.
Die Datenschutzgrenze umfasst mehr als einen Prozess
Ein denkbarer Wartungsassistent liest ein freigegebenes lokales Handbuch, prüft einen Anlagenstammsatz und erstellt einen Arbeitsauftragsentwurf zur Freigabe. Dabei kann das Modell lokal laufen, während ein Suchwerkzeug die Frage an einen externen Dienst überträgt, die Anwendung Traces exportiert oder nach einem Timeout einen Gesprächsverlauf an einen Ersatzanbieter sendet. Das sind zu prüfende Architekturmöglichkeiten, keine Vorwürfe gegen dieses Modell.
Die Anleitung von Liquid AI für Agenten-Harnesses beschreibt die Anbindung an einen lokalen OpenAI-kompatiblen Endpunkt. Das konfiguriert die Inferenzroute, aber keine Netzwerkregel des Betriebssystems. Die Anleitung verwendet derzeit ein anderes Familienmitglied, LFM2.5-2.6B. Dessen Artefaktgrößen und Beispielbefehle sind keine Dimensionierungsgrundlage für die 24B-Veröffentlichung.
Definieren Sie vor dem Pilotbetrieb, was „privat“ operativ bedeutet. Eine Richtlinie kann nach der Bereitstellung der Artefakte ausschließlich lokale Dateien und Dienste erlauben. Eine andere erlaubt bestimmte interne APIs, verbietet aber öffentlichen Netzverkehr. Eine dritte gestattet einen freigegebenen externen Abruf mit minimierter Nutzlast. Das sind unterschiedliche Betriebsprofile. Ein bestandener Test in einem Profil ist keine Freigabe für die anderen.
Setzen Sie das gewählte Profil außerhalb des Modells durch: Begrenzen Sie Werkzeugidentitäten, Dateizugriffe und Netzwerkziele, trennen Sie Artefaktinstallation und Auftragsausführung und machen Sie jeden Ausweichweg explizit. Die Bindung an Loopback reduziert unbeabsichtigte Erreichbarkeit des Endpunkts, verhindert aber keine ausgehende Verbindung des Harnesses. Umgekehrt kann eine vollständige Netzsperre ohne funktionierenden Kontrollauftrag ein defektes System scheinbar perfekt privat erscheinen lassen.
Für das übergreifende Berechtigungskonzept bietet der bestehende Beitrag zu Kontrollgrenzen für Agenten den Rahmen. Diese Veröffentlichung ergänzt eine konkrete Abnahmefrage: Kann das neue lokale Reasoning-Modell den freigegebenen Auftrag erledigen, während der übrige Harness innerhalb der festgelegten Datengrenze bleibt?
Schnelles Decoding ist kein abgeschlossener privater Auftrag
Liquid AI berichtet von 184 decodierten Token pro Sekunde auf einem M5 Max und 114 auf einem Ryzen AI Max+ 395. Die Modellkarte nennt für diese Edge-Messungen llama.cpp, Q4_K_M-Quantisierung und einen Eingabekontext von 4K Token. Die GPU-Durchsatzaussage bezieht sich auf eine einzelne B300 mit SGLang 0.5.22, BF16, 1.024 Eingabetoken, bis zu 256 Ausgabetoken und dauerhaft aufrechterhaltener Parallelität. Das sind Anbietermessungen unter unterschiedlichen Bedingungen, keine unabhängigen Nachweise für Ihr Gerät oder Ihre Last.
Die Angabe von zwei Milliarden aktiven Parametern beschreibt die dünn besetzte Berechnung, nicht den Speicherbedarf aller Gewichte. Längere Kontexte, parallele Anfragen und Laufzeitpuffer beeinflussen die Kapazität zusätzlich. Messen Sie maximalen Speicherbedarf und Abschlusslatenz mit der tatsächlich gewählten Quantisierung und dem Kontextbudget, statt das beworbene Kontextmaximum als sinnvollen Standardwert zu übernehmen.
Reasoning-Token können Zeit verbrauchen, bevor eine verwendbare Antwort oder Aktion vorliegt. Erfassen Sie die Zeit bis zum ersten gültigen Werkzeugvorschlag, die gesamte Auftragsdauer, fehlgeschlagene Aufgaben und Bedienereingriffe – nicht nur die Decoding-Rate. Vergleichen Sie das Kandidatensystem mit dem freigegebenen Verfahren bei gleichen Aufgaben und Berechtigungen. Der SLO-Rahmen für selbst gehostete Inferenz liefert die Dienstperspektive, ersetzt aber keine fachliche Ergebnisprüfung.
Die Benchmark-Ergebnisse des Anbieters unterscheiden sich deutlich nach Aufgabe: Seine Tabelle nennt 65,01 für BFCLv4, aber 8,04 für τ³-Bench Banking. Die Benchmarks verwenden unterschiedliche Definitionen; daraus lässt sich keine gemittelte betriebliche Erfolgsquote ableiten. Sie begründen einen Werkzeugtest, nicht unbeaufsichtigte Arbeit an produktiven Anlagen. Für diesen Beitrag wurden keine unabhängigen Hardware- oder Modellbenchmarks durchgeführt.
Abnahmecheckliste für diese Veröffentlichung
Beginnen Sie mit synthetischen Anlagenstammdaten und ungefährlichen Testendpunkten. Die folgende Entscheidungstabelle ist ein vorgeschlagenes Pilot-Gate, kein Bericht über bereits bestandene Tests von LFM2.5-24B-A2B.
|
Beobachtete Bedingung |
Freigabeentscheidung |
|---|---|
|
Lokale Inferenz; Werkzeugverkehr unklar |
Anhalten: Datenausgänge erfassen |
|
Lokaler Endpunkt fällt aus; Cloud startet |
Offline-Profil ablehnen; Ausweichweg prüfen |
|
Kein Datenabfluss; Auftrag bleibt offen |
Keine Betriebsreife behaupten |
|
Aufgaben bestanden; Nutzungsrechte unklar |
Kommerziellen Rollout anhalten |
|
Datengrenze und Aufgabentests bestanden |
Begrenzten lesenden Pilotbetrieb starten |
1. Inferenzroute und Artefakte fixieren
Dokumentieren Sie Modell- und Tokenizer-Revision, Vorlage, Quantisierung, Server-Build, Endpunktbindung und bereitgestellten Kontext. Führen Sie einen ungefährlichen Werkzeugtest durch die tatsächliche Clientintegration aus. Prüfen Sie, dass Reasoning-Text nicht als Werkzeugauftrag ausgeführt wird und Werkzeugergebnisse im richtigen Gespräch landen. Weisen Sie fehlerhafte oder unzulässige Aufrufe an der Anwendungsgrenze zurück, statt das Modell um eine Reparatur von Berechtigungen zu bitten.
2. Jeden erlaubten Datenausgang beobachten
Inventarisieren Sie Harness, Kindprozesse, Werkzeuge, Retrieval-Speicher und Telemetrieexporte. Erfassen Sie Ziel- und Prozessnachweise, ohne routinemäßig sensible Promptinhalte aufzubewahren. Prüfen Sie einen erlaubten lokalen Vorgang und einen kontrollierten, zu sperrenden externen Zugriff. Die Aussage des Modells, offline geblieben zu sein, ist kein Netzwerknachweis. Eine leere Aufzeichnung ohne funktionierende Erfassung ist nicht aussagekräftig.
3. Den Fehlerpfad erzwingen
Machen Sie den lokalen Endpunkt in einer isolierten Testumgebung unerreichbar. Bei einem Offline-Profil lautet das Abnahmekriterium: sichtbarer Fehler statt stiller Anbieterwechsel. Ist ein gehosteter Ausweichweg zulässig, benötigen Nutzlast und Ziel eine explizite Richtlinienentscheidung vor der Aktivierung. Testen Sie auch nicht verfügbares Retrieval und gesperrte Werkzeuge. Der Agent soll die fehlende Fähigkeit melden, nicht einen erfolgreichen Abschluss erfinden.
4. Nutzbare Ergebnisse unter denselben Kontrollen prüfen
Verwenden Sie repräsentative deutsche Fachbegriffe, lokale Dokumente mit bekannten Antworten und mehrstufige Aufgaben mit beobachtbarem Endzustand. Zählen Sie korrekte Abschlüsse getrennt von richtlinienkonformen Fehlschlägen. Erzwingen Sie Budgets für Auftragsdauer, Reasoning und Ausgabe sowie Werkzeugaufrufe im Harness. Eine Aufgabe, die lokal bleibt, aber nie fertig wird, erfüllt eine Begrenzungsbedingung – nicht die Dienstanforderung.
5. Einen reversiblen Freigabenachweis erhalten
Bewahren Sie Konfiguration, Richtlinie, synthetische Testfälle, beobachtete Ziele, Ergebnisse und kommerzielle Freigabe gemeinsam auf. Das Muster eines reproduzierbaren Release-Bundles hält diese Nachweise auch bei Änderungen an Tokenizer, Laufzeit oder Berechtigungen nutzbar. Starten Sie mit lesenden Aufgaben und menschlich geprüften Ausgaben. Lokaler Betrieb erteilt keine Berechtigung, Maschinen anzusteuern oder produktive Datensätze autonom zu ändern.
Legen Sie fest, was der Pilot beweisen muss
LFM2.5-24B-A2B ist eine Prüfung wert, wenn kundenseitig kontrollierte Inferenz und Werkzeugnutzung eine tatsächliche Betriebsanforderung adressieren. Weniger geeignet ist das Modell, wenn die Aufgabe stark von externem Wissen abhängt, die Hardware den notwendigen Kontext nicht trägt oder kommerzielle Rechte ungeklärt bleiben. Retrieval kann die Quellenbindung verbessern; sein Standort und seine Berechtigungen werden jedoch Teil derselben Prüfung.
Bringen Sie einen Arbeitsablauf, seine zulässigen Ziele und die Fehlerfallrichtlinie in ein Review Ihrer KI-Implementierung ein. Das nächste Ergebnis sollte ein begrenzter Pilot mit beobachtbaren Auftragsresultaten und nachgewiesener Datengrenze sein. Ein lokales Modell ist ein Bestandteil dieses Nachweises – nicht bereits dessen Ergebnis.
