LFM3-Audio in llama.cpp: eine Datei, ein Port, fertige Sprachkonferenz

Am 27. Oktober hat Liquid AI die LFM3-Familie veröffentlicht, am selben Tag hat llama.cpp die Sprachmodelle LFM3-Audio-2B und Omni-2B ins Format gebracht, und knapp sieben Stunden später war der Realtime-Endpunkt gemergt. Zum ersten Mal braucht man für einen lokalen Sprachassistenten keine Kette aus drei Diensten mehr, sondern eine Binary und eine Datei. Das ist ein Ereignis für jeden, der Sprach-KI im Haus betreiben will. Und die Support-Zahl, die auf der Modellkarte steht, bestätigt es: b11960, Build von dem an llama.cpp das Format und den Endpunkt mitbringt.

Kurz gefasst: Der Realtime-Endpunkt ist ein WebSocket-Pfad (/v1/realtime) im llama-server, nach dem Vorbild der OpenAI-Realtime-API. Er hält eine offene Verbindung, über die Spracheingabe, Antworttexte und Audioantworten in beide Richtungen fließen. Der Server braucht dafür ein Modell mit Audio-Ein- und -Ausgabe, den Rest erledigt eine einzige Instanz ohne externen Dienst.

Die eine Datei: was /v1/realtime in llama.cpp wirklich ist

Der PR #31269 kam von Xuan Son Nguyen, dem llama.cpp-Mann für Audio, und ist am 28. Oktober um 00:26 UTC gemergt. Der neue Modus lebt in einer Datei von 1.169 Zeilen (tools/server/server-realtime.cpp, Stand 28.10.) und spiegelt bewusst den Drahtprotokoll-Stil, den OpenAI mit seiner Realtime-API getrieben hat: Client verbindet WebSocket, sendet Audio-Chunks, der Server antwortet mit Text- und Audiounterbrüchen, alles über dieselbe Sitzung. Zwei Sitzungsarten bringt der Endpunkt mit. conversation führt das laufende Gespräch mit erkannter Eingabe; transcription (über ?intent=transcription) macht reine Abschrift. Und mit output_modalities entscheidet der Client pro Sitzung, ob er Text, Audio oder beides im Wechsel zurückbekommt. Das Wechsel-Modell, beim Fachjargon interleaved, ist genau das, was LFM3-Audio intern baut: Das Modell denkt in denselben Tokenstrom Sprache und Text gemischt.

Die Anbindung ist absichtlich dünn. Ein Session-Objekt pro Slot, ein Eingabepuffer für PCM16-Mono bei der Modellrate, mehr ist es nicht. Der mitgelieferte Testclient examples/realtime_client.py braucht genau zwei Dinge: llama-server -hf LiquidAI/LFM3-Audio-2B-GGUF und pip install "openai[realtime]" numpy, dann läuft die Unterhaltung. Wer die OpenAI-API je bedient hat, bedient auch diesen Endpunkt. Der eigentliche PR-Wert liegt in dieser Tür: Sie öffnet den Endpunkt für eine grosse Zahl fertiger Clients.

Was unter der Haube steckt: LFM3

LFM3 ist die dritte Generation der Liquid Foundation Models und architecturisch eine Abkehr vom reinen Attention-Bau. Die 24 Schichten des 1.7B-Modells sind aufgemischt: 13 Kurz-Konvolutionsschichten mit Kernel 7, fünf gleitende Fenster mit 256 Token Schlitz, nur sechs echte globale Aufmerksamkeiten. Dazu Attention-Head-Weiser, teilweise RoPE und Sandwich-Norm. Trainiert wurde nach Anbieterangabe mit 22 Billionen Tokens, das Vokabular fasst 128.000 Zeichen, der Kontext des Audio-Modells 32K Token. Diese Mischbauart ist genau der Trick, der ein kleines Modell für Echtzeit brauchbar macht: Der größte Teil der Schichten rechnet konstant pro Token, unabhängig davon, wie lang die Sitzung schon läuft.

Beim Audio-Modell selbst: 2 Milliarden Parameter, Audioeingabe über einen 16-kHz-Encoder, Ausgabe wahlweise Text, Sprache bei 24 kHz oder beide im Wechsel. Der Audio-Tokenizer heisst LiquidCodec, die Spracheingabe kann streamend kausal encodet werden, damit die Antwort nicht auf das Ende des Satzes warten muss. Achtzehn bis neunzehn Sprachregionen nennt die Karte, Deutsch inklusive. Werkzeugaufrufe beherrscht das Modell auch, was den Realtime-Endpunkt endgültig vom Spielzeug trennt: Ein Modell, das während des Gesprächs einen Funktionsaufruf absetzt, kann in Home Assistant oder ein Ticketsystem greifen.

Messeinheit: GiB, Messdatum 28.10.2026, Messstelle: HTTP-Content-Length auf die LFS-Download-URLs des offiziellen GGUF-Repos (curl, eigene Messung).

Die Größe ist die Sensation: Ein 2-Milliarden-Modell, das sprechend antwortet, passt quantisiert in knapp ein Gigabyte. Wer die Bandbreitenprobleme der 5090 kennt, weiß: Das passt auf jede Karte, die wir je besaßen, und bei dieser Dateigröße ist der Ladevorgang eine Randnotiz. Ein eigener Durchsatzlauf durch unsere Lane steht noch aus; erst wenn er da ist, stehen hier gemessene tok/s-Zahlen. Bis dahin sind die harten Fakten die der Karte und die der Lizenz.

Der Haken: die Lizenzdatei, nicht die README

LFM Open License v1.0, so steht es im LICENSE-File des Modells (auf Hugging Face als license:other markiert, intern lfm1.0), ist eine Source-Available-Lizenz mit Umsatzschwelle. Absatz 5, Commercial Use Limitation: Rechtspersonen mit Jahresumsatz ab zehn Millionen US-Dollar dürfen das Modell kommerziell nicht nutzen, ohne den Anbieter zu kontaktieren; Ausnahmen gelten für Gemeinnützige und Forschung. Das Muster kennen wir von Timestral vor wenigen Wochen, derselbe Hebel, dieselbe Datei-Stelle. Für den reinen Eigenbetrieb in unserem Haus ändert das operativ nichts, wir nutzen intern. Sobald aber ein Produkt, eine Leistung oder ein kundensichtbarer Assistent auf diesen Gewichten laufen soll, ist die Lizenz vor dem ersten Development-Tag geklärt. Wer die eigenen KI-Strecken plant, prüft die Lizenzdatei ohnehin als erste, bevor er ein Modell in den Kauf-Prozess einordnet, und sei es bei einem Kandidaten, der erst zwei Wochen im Format ist.

Was das hier im Haus ändern würde

Unsere Sprachspur läuft heute als getrennte Bausteine: Ein Piper-Synthesedienst in unserem Home-Assistant-Container antwortet, eine Phrasen-Erkennung nimmt Kommandos, ein LLM schreibt den Text dazwischen. Diese Kette funktioniert, aber sie ist genau die Architektur, die der Realtime-Endpunkt ersetzt: drei Dienste, drei Ausfallpunkte, eine Latenz, die sich aus drei Läufen aufsummiert. Ein einziges Modell am Realtime-Port würde die Kette auf einen Dienst verkürzen, mit deutscher Stimme aus dem Modell statt aus der Fertigungsdatei. Die Entscheidung, ob sich das trägt, fällt ein Gegenlauf mit unserem eigenen Material. Dasselbe Satzmaterial, gemessen an Latenz bis zur ersten Silbe und Verständlichkeit der deutschen Ausgabe. Erst danach steht eine Umbauplanung an.

Einordnung zum Overhype-Potential: Das Audio-Modell ist zwei Monate alt, das llama.cpp-Format zwei Tage, der Endpunkt keine zwölf Stunden. Die Download-Zahlen beider GGUF-Repos lagen bei unserer Messung nahe null, es gibt kein unabhängiges Messergebnis. Was man mitnehmen kann, ist die Architektur-Richtung. Wer einen sprechenden Assistenten für den Produktiveinsatz in einem Monat sucht, wartet einen Monat; wer ihn bauen will, fängt jetzt mit dem Testclient an, denn die Richtung ist gesetzt: llama.cpp hat mit diesem Build die Brücke gebaut, die OpenAI proprietär hält, und zwar offen.

Quellen und Messbasis

• PR #31269, /v1/realtime in llama-server (Merge 28.10.2026)
• PR #31257, LFM3-Audio im llama.cpp-Format (Merge 27.10.2026)
• Modellkarte LiquidAI/LFM3-Audio-2B (aktualisiert 27.10.2026)
• GGUF-Repo LFM3-Audio-2B mit Lizenzdatei (Lizenztext dort, Stand 28.10.2026 gemessen)
• Liquid-AI-Ankündigung LFM3 (27.10.2026)
• HF-Blog zur LFM3-Veröffentlichung (27.10.2026)