Liquid AI beschleunigt multimodales LFM2.5-VL-Modell mit spekulativem Decoding

Gemeldete Geschwindigkeitsgewinne

Liquid AI hat den DSpark-Drafter sowohl auf Edge-Hardware als auch auf einer H100-GPU untersucht. Bewertet wurden sechs unterschiedliche visuelle Aufgaben. Dazu zählen allgemeine Visual Question Answering-Aufgaben, Fragen zu Text in Bildern, Bildbeschreibung, Diagrammverständnis, komplexes Schlussfolgern und mehrteilige Dialoge. Als Referenz diente nach den veröffentlichten Angaben der MMSpec-Benchmark.

Ergebnisse auf Apple-Hardware

Bei einer Ausführung mit MLX auf einem Apple M5 Max soll die Decoding-Geschwindigkeit je nach Aufgabe zwischen 2,30- und 3,13-fach höher liegen. Die End-to-End-Latenz, also die Zeit für die vollständige Verarbeitung einschließlich weiterer Modellphasen, verbessert sich laut Liquid AI um den Faktor 1,56 bis 2,62.

Auf einem Apple M3 Ultra mit llama.cpp wurden beim Decoding Verbesserungen zwischen 1,57- und 2,14-fach angegeben. Die vollständige Latenz soll sich dort um den Faktor 1,30 bis 1,77 reduzieren. Die Unterschiede zwischen den beiden Plattformen zeigen, dass nicht nur das Modell, sondern auch die konkrete Implementierung, die Speicherarchitektur und die verfügbaren Beschleuniger eine Rolle spielen.

Ergebnisse auf einer H100-GPU

Auf einer NVIDIA H100 berichtet Liquid AI von einer bis zu 2,66-fachen Beschleunigung beim Decoding. Für die gesamte Verarbeitung werden Verbesserungen von bis zu 2,27-fach genannt. Je nach Aufgabe liegen die Werte darunter. Die Zahlen sind daher als Messbereich unter den beschriebenen Testbedingungen zu verstehen und nicht als allgemeine Garantie für jede Anwendung.

Die Differenz zwischen Decoding- und End-to-End-Werten ist technisch erwartbar. Der Drafter beschleunigt nur einen Teil der Verarbeitung. Bei kurzen Antworten, großen Bildern, langen Eingabeaufforderungen oder anspruchsvoller Bildanalyse können andere Phasen den überwiegenden Anteil der Laufzeit ausmachen.

Warum die Gesamtbeschleunigung geringer ausfällt

Die Inferenz eines Vision-Language-Modells besteht grob aus mehreren Abschnitten. Zunächst wird das Bild verarbeitet. Danach werden Bildrepräsentationen und Text in den Kontext des Sprachmodells eingebracht. Diese Phase wird häufig als Prefill bezeichnet. Erst anschließend beginnt die schrittweise Ausgabe, also das Decoding.

LFM2.5-VL-DSpark wirkt vor allem auf die letzte Phase. Die Bildkodierung und das Prefill werden durch den Drafter nicht automatisch schneller. Auf Edge-Geräten verfügen Prozessoren und integrierte Grafik- oder Neural-Processing-Einheiten über deutlich weniger Rechenleistung als moderne Rechenzentrums-GPUs. Dadurch kann die Vorverarbeitung dort einen größeren Anteil der gesamten Antwortzeit beanspruchen.

Dieses Verhältnis lässt sich mit dem Prinzip von Amdahl erklären. Wird nur ein Teil eines Prozesses beschleunigt, bleibt der Gesamtnutzen durch den unveränderten Teil begrenzt. Wenn beispielsweise die Hälfte der Latenz auf Bildencoder und Prefill entfällt, kann eine beliebig schnelle Token-Generierung die Gesamtzeit nicht im gleichen Umfang reduzieren.

Für die Bewertung eines Projekts sollten Sie daher mindestens drei Kennzahlen getrennt erfassen:

- Zeit bis zum ersten Token, insbesondere bei interaktiven Anwendungen

- Geschwindigkeit der Token-Ausgabe während des Decodings

- Gesamtlatenz vom Eingang des Bildes bis zur vollständigen Antwort

Je nach Anwendungsfall kann eine dieser Größen wichtiger sein als die anderen. Bei einem sprachgesteuerten Assistenzsystem zählt häufig eine schnelle erste Rückmeldung. Bei der automatisierten Erstellung längerer Bildberichte ist dagegen der Gesamtdurchsatz entscheidend.

Unterstützte Laufzeitumgebungen

Das Modell wurde zum Start für mehrere Open-Source-Umgebungen verfügbar gemacht. Genannt werden llama.cpp, MLX-VLM und SGLang. Damit adressiert Liquid AI unterschiedliche Bereitstellungsszenarien: lokale Ausführung auf Apple-Silicon-Systemen, ressourcenschonende Inferenz über kompatible C++-Backends sowie serverseitige Ausführung mit einer auf hohe Auslastung ausgelegten Laufzeitumgebung.

Die jeweilige Unterstützung hängt von konkreten Versionen und Integrationen ab. Für SGLang ist eine Version mit DSpark-Unterstützung für LFM-Zielmodelle erforderlich. Bei llama.cpp und MLX-VLM müssen ebenfalls entsprechende Implementierungen verwendet werden. Unternehmen sollten deshalb vor einem produktiven Einsatz prüfen, ob die benötigten Funktionen bereits in der eingesetzten Version enthalten sind oder aus einem Entwicklungszweig übernommen werden müssen.

Die verfügbaren Modellformate erweitern die Einsatzmöglichkeiten. Liquid AI stellt LFM2.5-VL-DSpark nach den veröffentlichten Angaben sowohl als Safetensors- als auch als GGUF-Modell bereit. Safetensors wird häufig in Python- und Transformer-basierten Umgebungen genutzt, während GGUF besonders im Umfeld von llama.cpp verbreitet ist.

Was Unternehmen vor dem Einsatz prüfen sollten

Die angekündigten Beschleunigungen können für Anwendungen mit vielen visuellen Anfragen interessant sein. Ein geringerer Rechenaufwand pro Antwort kann die Betriebskosten senken, die Interaktion beschleunigen oder den Einsatz leistungsfähiger multimodaler Funktionen auf lokalen Geräten ermöglichen. Daraus folgt jedoch nicht automatisch, dass jede bestehende Anwendung von der Integration profitiert.

Für eine belastbare Bewertung empfiehlt sich ein Test mit den eigenen Daten und Antwortlängen. Allgemeine Benchmarks bilden typische Aufgabengruppen ab, ersetzen aber keine Messung unter realen Bedingungen. Besonders relevant sind Bildauflösung, Seitenzahl bei Dokumenten, Länge der Anfragen, gewünschte Antwortlänge und Anteil paralleler Anfragen.

Darüber hinaus sollten Sie folgende Punkte berücksichtigen:

- Prüfen Sie, ob die Zielhardware ausreichend Arbeitsspeicher für Zielmodell, Drafter, Bildencoder und Laufzeitreserven bereitstellt.

- Vergleichen Sie End-to-End-Latenz und Token-Durchsatz getrennt voneinander.

- Messen Sie die Akzeptanzrate der vorgeschlagenen Token auf Ihren typischen Aufgaben.

- Testen Sie unterschiedliche Blockgrößen, insbesondere acht und neun Token, sofern die Laufzeitumgebung dies zulässt.

- Überprüfen Sie die Qualität bei OCR, Tabellen, Diagrammen, kleinen Objekten und langen Dokumenten.

- Berücksichtigen Sie die Versionen von llama.cpp, MLX-VLM oder SGLang sowie die jeweiligen Treiber und Backends.

- Klären Sie Lizenzbedingungen, kommerzielle Nutzung und Anforderungen an Weitergabe oder Anpassung.

- Erheben Sie Energieverbrauch und Geräuschentwicklung, wenn das Modell auf Arbeitsplatzrechnern, mobilen Systemen oder Industriehardware ausgeführt werden soll.

Qualität, Determinismus und Validierung

Ein wesentlicher Vorteil des beschriebenen Verfahrens liegt darin, dass der Drafter nicht als eigenständiges Entscheidungsmodell eingesetzt wird. Die vorgeschlagenen Token werden vom Zielmodell kontrolliert. Liquid AI bezeichnet das Verfahren deshalb als exakt und erklärt, dass bei gieriger Decodierung dieselbe Ausgabe wie beim alleinigen Zielmodell entsteht.

Diese Aussage bezieht sich auf die algorithmische Prüfung der Token. In realen Systemen können dennoch Unterschiede auftreten, etwa durch unterschiedliche Präzision, Quantisierung, Kernel, Zufallsparameter oder Einstellungen der Sampling-Strategie. Für Anwendungen mit hohen Anforderungen an Nachvollziehbarkeit sollten Unternehmen deshalb Vergleichstests zwischen Basisbetrieb und spekulativem Decoding durchführen.

Die Qualitätsprüfung sollte nicht nur die exakte Zeichenfolge einer Antwort betrachten. Bei multimodalen Anwendungen sind auch korrekte Objektbezüge, Seitenpositionen, Zahlenwerte aus Diagrammen, Tabellenstrukturen und die Vollständigkeit extrahierter Inhalte relevant. Ein unverändertes Decoding-Ergebnis ist technisch wichtig, ersetzt aber keine Prüfung der Fähigkeiten des zugrunde liegenden Vision-Language-Modells.

Potenzielle Anwendungsfelder

Die Kombination aus multimodaler Verarbeitung und spekulativem Decoding kann vor allem dort interessant sein, wo Antworten häufig lokal erzeugt werden und eine niedrige Interaktionslatenz erforderlich ist. Dazu zählen beispielsweise mobile Assistenzsysteme, Dokumentenanalyse auf dem Arbeitsplatzrechner, visuelle Wartungsunterstützung und Anwendungen in der Robotik.

In der industriellen Qualitätssicherung könnte ein lokales Modell Bilder von Bauteilen analysieren und Prüfergebnisse in Textform ausgeben. In der Logistik wären Szenarien denkbar, in denen Etiketten, Packstücke oder Schadensbilder ausgewertet werden. Im Wissensmanagement könnte ein System Dokumentseiten lokal lesen und gezielt Fragen zu Tabellen oder Abbildungen beantworten.

Ob LFM2.5-VL-DSpark dafür geeignet ist, hängt von den jeweiligen Anforderungen ab. Besonders wichtig sind die Erkennungsqualität, der Umgang mit vertraulichen Daten, die Hardwareverfügbarkeit und die Integration in bestehende Anwendungen. Die gemeldete Beschleunigung ist ein Infrastrukturvorteil; sie sagt allein noch nichts über die fachliche Eignung für einen bestimmten Geschäftsprozess aus.

Einordnung in die Entwicklung effizienter KI-Modelle

Die Veröffentlichung steht im Zusammenhang mit einem breiteren Trend zur Optimierung der Inferenz. Während die öffentliche Debatte häufig die Größe und Leistungsfähigkeit von Modellen in den Mittelpunkt stellt, wird für Unternehmen zunehmend entscheidend, wie effizient diese Modelle betrieben werden können. Kosten, Energieverbrauch, Latenz, Datenschutz und Offline-Fähigkeit beeinflussen die Wirtschaftlichkeit eines KI-Produkts unmittelbar.

Liquid AI hatte zuvor DSpark-Entwurfsmodelle für mehrere textbasierte LFM2.5-Modelle veröffentlicht. Dabei wurden nach eigenen Angaben ebenfalls erhebliche Verbesserungen beim Decoding erzielt. Die Erweiterung auf ein Vision-Language-Modell zeigt, dass spekulative Verfahren nicht auf reine Textanwendungen beschränkt bleiben müssen. Gleichzeitig macht die multimodale Verarbeitung die Grenzen des Ansatzes sichtbarer, weil Bildencoder und Prefill einen größeren Anteil der Laufzeit beanspruchen können.

Für die Modellarchitektur bedeutet dies, dass künftige Optimierungen wahrscheinlich mehrere Ebenen kombinieren werden. Dazu gehören effizientere Bildencoder, kürzere oder besser komprimierte visuelle Tokenfolgen, optimierte Speicherzugriffe, Quantisierung, bessere Laufzeitkerne und Verfahren wie spekulatives Decoding. Der größte Vorteil entsteht voraussichtlich dann, wenn Modell und Ausführungsumgebung gemeinsam auf das tatsächliche Anwendungsszenario abgestimmt werden.

Offene Fragen für die Praxis

Die Veröffentlichung ist als experimenteller Entwurf gekennzeichnet. Damit bleiben mehrere Fragen für den produktiven Einsatz offen. Dazu gehören die Stabilität über unterschiedliche Hardwaregenerationen hinweg, das Verhalten bei sehr langen Bild-Text-Kontexten, die Akzeptanzraten bei domänenspezifischen Daten und der Aufwand für die laufende Pflege der Integrationen.

Auch die Lizenzbedingungen sollten vor einer kommerziellen Nutzung geprüft werden. Die Modellseiten weisen auf eine eigene Lizenzregelung der LFM-Familie hin. Angaben zur kostenlosen Nutzung und zu Umsatzgrenzen können sich auf bestimmte Bedingungen beziehen und sollten anhand der jeweils aktuellen Lizenzdokumente bewertet werden. Eine technische Verfügbarkeit auf Hugging Face ist nicht gleichbedeutend mit einer uneingeschränkten Nutzung in jeder Unternehmensumgebung.

Für regulierte Branchen kommen zusätzliche Anforderungen hinzu. Unternehmen müssen unter anderem klären, ob Bilddaten das eigene Netzwerk verlassen, wie Protokolle und Zwischenspeicher behandelt werden und wie sich Modellversionen reproduzierbar dokumentieren lassen. Bei Anwendungen mit personenbezogenen oder geschäftskritischen Bildern sind Datenschutz, Zugriffskontrolle und Löschkonzepte bereits in der Pilotphase zu berücksichtigen.

Fazit

LFM2.5-VL-DSpark verfolgt einen klar abgegrenzten Ansatz: Ein zusätzliches, deutlich kleineres Modell schlägt Tokenfolgen vor, während das multimodale Zielmodell die Vorschläge überprüft. Nach den von Liquid AI veröffentlichten Messungen kann dieses Verfahren die Decoding-Geschwindigkeit auf Edge-Hardware und H100-GPUs deutlich steigern. Der zusätzliche Modellumfang bleibt mit rund 280 Millionen Parametern im Verhältnis zum etwa drei Milliarden Parameter großen Zielmodell begrenzt.

Für die Bewertung der Technologie ist die Unterscheidung zwischen Decoding und vollständiger Inferenz entscheidend. Die ausgewiesenen End-to-End-Gewinne liegen unter den maximalen Decoding-Werten, weil Bildverarbeitung und Prefill nicht automatisch beschleunigt werden. Unternehmen sollten daher eigene Messungen mit realen Bildern, Antwortlängen und Hardwarekonfigurationen durchführen.

Die Veröffentlichung erweitert die Optionen für lokale und ressourcenschonende multimodale KI. Sie ist insbesondere für Teams interessant, die offene Modelle einsetzen, die Inferenz näher an den Daten ausführen und die Antwortgeschwindigkeit auf Edge-Geräten verbessern möchten. Ob der Ansatz einen messbaren Geschäftsvorteil erzeugt, entscheidet sich letztlich an den konkreten Latenz-, Qualitäts-, Kosten- und Compliance-Anforderungen des jeweiligen Projekts.

Bibliografie

1. Liquid AI: „LFM2.5-VL-DSpark: Accelerating vision-language models on edge and beyond“, 24. September 2026. https://www.liquid.ai/blog/lfm2-5-vl-dspark
2. Hugging Face Blog / Liquid AI: „Accelerating vision-language models with LFM2.5-VL-DSpark“, 24. September 2026. https://huggingface.co/blog/LiquidAI/lfm2-5-vl-dspark
3. Liquid AI: „Liquid Foundation Models – Models built for real-world constraints“. https://www.liquid.ai/models
4. Hugging Face: „LiquidAI/LFM2.5-VL-3B – Model Card“. https://huggingface.co/LiquidAI/LFM2.5-VL-3B
5. Liquid AI: „LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacBook“, 20. August 2026. https://www.liquid.ai/blog/lfm2.5-dspark
6. Hugging Face: „LiquidAI/LFM2.5-2.6B-DSpark – Model Card“. https://huggingface.co/LiquidAI/LFM2.5-2.6B-DSpark
7. Hugging Face Papers: „DSpark“, Paper-ID 2607.05147. https://huggingface.co/papers/2607.05147
8. MMSpec Benchmark, Referenz im Beitrag zu LFM2.5-VL-DSpark. https://huggingface.co/papers/2603.14989