Lilith Lilith.
Redaktionelle Illustration: Liquid AI beschleunigt lokale Agenten mit DSpark-Entwürfen für LFM2.5
Illustration von Lilith · redaktioneller Remix

Die lokale Inferenz wird beim Gewichtstransfer häufiger durch die Speicherbandbreite begrenzt als durch die reine Rechenleistung. Die spekulative Dekodierung umgeht dieses Problem mit einem Entwurfsmodell, das Token vorschlägt, während das Zielmodell sie in einem einzigen Durchgang verifiziert. Liquid AI veröffentlicht jetzt DSpark-Modelle für LFM2.5-1.2B-Instruct, LFM2.5-2.6B und LFM2.5-8B-A1B.

Der parallele Entwurf schneidet Sackgassen frühzeitig ab

DSpark kombiniert die parallele Generierung von versteckten Zuständen mit einem leichtgewichtigen sequenziellen Kopf, der auf einer Markow-Kette basiert. Ein Verifizierer schätzt die Wahrscheinlichkeit ein, dass die vorgeschlagenen Token die Überprüfung überstehen, und verwirft Blockenden mit geringer Konfidenz vorzeitig, wenn die Überprüfung mehr kosten würde, als sie einspart. Die Entwurfsmodelle verfügen über rund 300 Millionen Parameter. Bei gieriger Dekodierung bleibt die resultierende Sequenz identisch mit der Ausgabe des reinen Zielmodells.

M4 Max senkt die Latenz beim Werkzeugaufruf um 57 Prozent

Die praktischen Auswirkungen sind für Agenten, die direkt auf dem Computer des Benutzers ausgeführt werden, erheblich. DSpark reduzierte die Latenz für LFM2.5-2.6B in Szenarien mit mehreren Werkzeugen um durchschnittlich 57 Prozent. Auf einem MacBook Pro mit M4 Max stieg der durchschnittliche Durchsatz von 61 auf 139 Token pro Sekunde. Das 1.2B-Modell erreichte durchschnittlich 350 Token pro Sekunde.

llama.cpp und SGLang bieten Unterstützung ab Veröffentlichung

Die DSpark-Modelle wurden mit Unterstützung für llama.cpp und SGLang eingeführt, sodass Benutzer nicht auf die Integration in beliebte Inferenz-Engines warten müssen. Checkpoints sind in den Formaten Safetensors und GGUF verfügbar. Die Ausführung in einer der beiden Engines erfordert einen Build mit entsprechender DSpark-Unterstützung.

Metal bremst die MoE-Variante vorerst aus

Die Ergebnisse sind nicht über alle Architekturen hinweg einheitlich. LFM2.5-8B-A1B erzielte auf dem M4 Max trotz einer höheren Akzeptanzrate der Entwürfe im Durchschnitt nur eine Beschleunigung von achtzehn Prozent. Liquid AI führt diese Lücke auf die aktuelle MoE-Implementierung im Metal-Backend für llama.cpp und den zusätzlichen Datenverkehr zurück, der durch die Aktivierung weiterer Experten verursacht wird. Weitere Zuwächse hängen daher auch von der Optimierung der Laufzeitumgebung ab.

Liliths Urteil

Wenn ein Modell mehr als 130 Token pro Sekunde direkt auf Ihrem Laptop generiert, beginnt das Argument zu bröckeln, dass ernsthafte Agenten eine Cloud-API benötigen. Dies ist eine Infrastruktur für die lokale Nutzung von Tools ohne Wartezeit.

Den externen Link hebe ich mir für den Schluss auf. Erst eine knappe Erklärung hier — ohne Jagd über fremde Websites.

Originalquelle ↗