Liquid AI fügt spekulatives Decoding zu LFM2.5-VL-3B für schnellere Vision-Language-Inferenz hinzu

Liquid AI hat ein experimentelles Modell für spekulatives Decoding veröffentlicht, das darauf ausgelegt ist, sein Vision-Language-Modell LFM2.5-VL-3B zu beschleunigen und einen zentralen Engpass in der multimodalen Inferenz anzugehen: Antworten schnell zu erzeugen, nachdem ein Bild und ein Prompt verarbeitet wurden.

Das Modell mit dem Namen LFM2.5-VL-DSpark ergänzt das Zielmodell mit 3 Milliarden Parametern um ein Draft-Modell mit 280 Millionen Parametern. Liquid AI zufolge lieferte die Kombination in der internen Evaluierung Decoding-Beschleunigungen von bis zu 3,13x auf einem Apple M5 Max und bis zu 2,66x auf einer Nvidia H100. Die End-to-End-Latenzgewinne waren geringer und erreichten 2,62x auf dem M5 Max und 2,27x auf der H100.

Die Veröffentlichung ist vor allem für Teams relevant, die Vision-Language-Modelle auf lokaler Hardware einsetzen, wo Antwortlatenz und Speichergrenzen strenger sein können als auf großen Inferenz-Clustern. Außerdem erweitert sie den DSpark-Ansatz von Liquid AI von Textmodellen auf multimodale Workloads, ohne einen anderen Algorithmus für spekulatives Decoding zu benötigen.

Ein Drafting-Modell für multimodale Eingaben gebaut

Spekulatives Decoding nutzt ein kleineres Modell, um mehrere Tokens auf einmal vorzuschlagen. Das größere Zielmodell überprüft diese Vorschläge dann, akzeptiert die Tokens, die mit seiner eigenen nächsten Tokenverteilung übereinstimmen, und erzeugt bei Bedarf Ersatz. Der Ansatz kann die Zahl der teuren Schritte des Zielmodells reduzieren, ohne die Ausgabe des Zielmodells bei exakter Verifikation zu verändern.

Laut der Hugging-Face-Veröffentlichung von Liquid AI nimmt das Draft-Modell LFM2.5-VL-DSpark Hidden States aus ausgewählten Schichten von LFM2.5-VL-3B auf und schlägt Blöcke von Kandidaten-Tokens vor. Bilder und Text werden zunächst in eine gemeinsame Repräsentation projiziert, sodass das Draft-Modell Vektoren mit derselben Dimensionalität unabhängig von der Eingabemodalität erhält.

Liquid AI sagt, dass das Vision-Drafting-Modell während des Trainings vier Attention-only-Schichten und eine Blockgröße von neun verwendet. Für die Inferenz empfiehlt das Unternehmen je nach Hardware eine Blockgröße von acht oder neun. Das Draft-Modell erhöht die Parameterzahl des bereitgestellten Modells um etwa 8,9 %, was im Vergleich zum Betrieb eines separaten großen Modells für dieselbe Aufgabe einen relativ kleinen Speicheranstieg darstellt.

Das Modell wurde mit einer Mischung aus Vision-Language-Supervised-Fine-Tuning-Daten trainiert, gewichtet auf die Workloads, die Liquid AI bedienen möchte. Das Unternehmen testete Designs mit drei, vier und fünf Schichten und trainierte die ausgewählte Konfiguration für 10 Epochen. Es berichtete, dass die Akzeptanz mit zusätzlichen Tokens zunahm, bevor abnehmende Erträge eintraten.

Gemeldete Gewinne variieren je nach Hardware und Aufgabe

Liquid AI evaluierte das System über sechs visuelle Workloads hinweg mit dem MMSpec-Benchmark. Zu den Aufgaben gehörten allgemeines visuelles Fragebeantworten, textfokussiertes visuelles Fragebeantworten, Bildbeschreibung, Fragenbeantwortung zu Diagrammen, komplexes Schlussfolgern und Multi-Turn-Konversation.

Die On-Device-Ergebnisse wurden mit MLX auf einem M5 Max und mit llama.cpp auf einem M3 Ultra gemessen. Liquid AI berichtet, dass das Decoding mit MLX je nach Aufgabe 2,30x bis 3,13x schneller war, während sich die End-to-End-Latenz um 1,56x bis 2,62x verbesserte. Mit llama.cpp lagen die Decoding-Gewinne zwischen 1,57x und 2,14x, und die End-to-End-Latenz verbesserte sich von 1,30x bis 1,77x.

Die Bewertung auf der H100 ergab laut dem Unternehmen Decoding-Gewinne von bis zu 2,66x und End-to-End-Verbesserungen von bis zu 2,27x. Das Quellmaterial enthält für den unteren Wert des H100-Decoding-Bereichs eine inkonsistente Angabe, daher sollte das breitere Ergebnis als vom Anbieter gemeldetes Maximum und nicht als einheitliche Leistungserwartung betrachtet werden.

Dies sind Messungen von Liquid AI, kein unabhängiger Benchmark. Sie beschreiben außerdem spezifische Hardware-, Software-Konfigurationen, Aufgabenmischungen und eine DSpark-Blockgröße von acht. Die tatsächlichen Gewinne hängen von der Akzeptanzrate der vorgeschlagenen Tokens, der Prompt-Länge, der Bildkomplexität, der Quantisierung, der Batch-Größe und dem Anteil der Gesamtlatenz ab, der für Bildverarbeitung und Prompt-Aufnahme aufgewendet wird.

Liquid AI sagt, dass spekulatives Decoding exakt ist, weil das Zielmodell jeden vorgeschlagenen Token überprüft. In seiner Implementierung sollte die greedy Ausgabe daher mit dem Zielmodell ohne Spekulation übereinstimmen. Diese Eigenschaft adressiert eines der Hauptbedenken bei Beschleunigungstechniken: die Geschwindigkeit zu verbessern, ohne das Modellverhalten stillschweigend zu verändern.

Warum End-to-End-Latenz die schwierigere Kennzahl bleibt

Der gemeldete Unterschied zwischen Decoding-Geschwindigkeit und Gesamtlatenz ist für Produktteams wichtig. Spekulatives Decoding beschleunigt die Token-Erzeugung, aber nicht den Vision-Encoder oder die Prefill-Phase, die die Bild-Tokens und den Text-Prompt verarbeitet.

Vision-Language-Modelle können beträchtliche Zeit verbringen, bevor sie das erste Token erzeugen. Ein Bild wird durch einen Vision-Encoder geleitet, danach verarbeitet das Sprachmodell Hunderte visueller Tokens zusammen mit der Texteingabe. Auf Edge-Hardware kann das geringere Rechenbudget diese Phasen zu einem größeren Anteil der gesamten Antwortzeit machen. Daher führt eine dreifache Verbesserung beim Decoding nicht zu einer dreifachen Reduzierung der für Nutzer sichtbaren Latenz.

Diese Einschränkung ist ein Beispiel für das Amdahlsche Gesetz: Die Teile einer Workload, die unverändert bleiben, begrenzen den Gesamtnutzen. Für eine Anwendung wie Bild-Chat, Dokumentenanalyse oder Diagramminterpretation müssen Teams die Zeit bis zum ersten Token und die vollständige Antwortzeit getrennt messen. Ein schnellerer Decode-Pfad kann besonders wertvoll für längere Antworten, wiederholte Gesprächsrunden oder Workflows sein, bei denen die Ausgabeerzeugung dominiert, nachdem das Bild bereits kodiert wurde.

Die Ergebnisse deuten auch darauf hin, dass die Hardwarewahl das Wertversprechen prägen wird. Die stärksten gemeldeten Decoding-Werte von Liquid AI kamen von Apple Silicon, während die H100 in den Tests des Unternehmens geringere, aber dennoch spürbare Gewinne lieferte. Das macht die Veröffentlichung sowohl für lokale Inferenz als auch für GPU-gestützte Dienste relevant, belegt jedoch nicht, dass jede Bereitstellung dieselbe Verbesserung sehen wird.

Integrationen senken die Hürde zum Testen

LFM2.5-VL-DSpark ist über Integrationen für llama.cpp, MLX-VLM und SGLang verfügbar. Liquid AI sagt, dass das Draft-Modell auf Hugging Face in den Formaten Safetensors und GGUF angeboten wird, was Entwicklern Wege für native und quantisierte Bereitstellungs-Workflows eröffnet.

Die SGLang-Integration erfordert einen Build mit DSpark-Unterstützung für LFM2-Ziele, während llama.cpp und MLX-VLM ebenfalls Versionen benötigen, die die relevanten Implementierungsänderungen enthalten. In SGLang hängen Betreiber das Draft-Modell an das Zielmodell an und fragen einen OpenAI-kompatiblen Endpunkt ab. Die Blockgröße wird aus der Modellkonfiguration gelesen, und das Antwort-Timing kann offenlegen, wie viele Draft-Tokens vorgeschlagen und akzeptiert wurden.

Für Entwickler ist dieses Integrationsmodell bedeutsam, weil die Veröffentlichung weder den Austausch des Ziel-Vision-Language-Modells noch eine Neugestaltung der Anwendungsoberfläche erfordert. Teams können eine Basisbereitstellung mit spekulativem Decoding unter Verwendung desselben Zielmodells vergleichen und Akzeptanz, Latenz, Speichernutzung und Ausgabeäquivalenz messen. Die zusätzlichen 280 Millionen Parameter bringen jedoch weiterhin Speicher- und Ladeaufwand mit sich, was auf kleineren Edge-Geräten relevant sein kann.

Worauf man als Nächstes achten sollte

Das klarste Folge-Signal wird unabhängiges Testen von LFM2.5-VL-DSpark über mehr Bildgrößen, Quantisierungsstufen, Batch-Größen und produktionsähnliche Prompts hinweg sein. Unabhängige Ergebnisse würden helfen zu klären, ob die gemeldeten Gewinne außerhalb der von Liquid AI ausgewählten Sechs-Aufgaben-Bewertung Bestand haben.

Entwickler sollten außerdem Akzeptanzraten und End-to-End-Latenz beobachten, statt sich nur auf die Schlagzeilen-Mehrfachwerte beim Decoding zu verlassen. Unterstützung in llama.cpp, MLX-VLM und SGLang wird wichtig bleiben, während Implementierungen reifen, insbesondere für Nutzer, die auf Apple Silicon oder eingeschränkter lokaler Hardware einsetzen.

Weitere DSpark-Veröffentlichungen für andere Vision-Language-Modelle könnten zeigen, ob sich die Architektur über LFM2.5-VL-3B hinaus verallgemeinern lässt. Umgekehrt könnte der Ansatz, wenn die Gewinne stark von Modellarchitektur oder Workload abhängen, eine gezielte Optimierung bleiben statt einer breit portablen Inferenzschicht.

Creati.ai-Perspektive

Die Veröffentlichung von Liquid AI ist ein praktisches Inferenz-Update und kein neues Fähigkeitsmodell. Ihr wichtigster Beitrag besteht darin zu zeigen, wie spekulatives Decoding an ein multimodales Ziel angepasst werden kann, während die exakte Verifikation erhalten bleibt und das zusätzliche Modell relativ klein bleibt.

Die kommerzielle Bedeutung wird von der gesamten vom Nutzer wahrgenommenen Latenz abhängen, nicht von der maximalen Decoding-Zahl. Für Teams, die Vision-Language-Workloads lokal ausführen, könnte die Kombination aus offenen Gewichten, vorhandenen Runtime-Integrationen und messbaren Gewinnen Tests rechtfertigen. Käufer sollten die aktuellen Leistungsangaben jedoch als vom Anbieter gemeldet betrachten und sie gegen ihre eigenen Bilder, Prompts, Hardware und Latenzziele validieren.