LFM3-1.7B vs. Granite 4.2 30B: Zwei Agentenmodelle, die das Urteil nach Achse aufteilen

Setze LFM3-1.7B und Granite 4.2 30B auf dieselbe Seite, und die aggregierten Durchschnittswerte weisen je nach gelesener Zeile in entgegengesetzte Richtungen. Im Berkeley Function Calling Leaderboard V4 erzielt das 1,73-Milliarden-Parameter-Modell von Liquid AI 71,39 gegenüber 61,39 von IBM — ein Zehn-Punkte-Sieg für ein Modell, das rund siebzehnmal kleiner ist. Bei SWE-bench Verified erreicht Granite 57,00 gegenüber 43,40 von LFM3-1.7B, ein 13,6-Punkte-Sieg in die andere Richtung.Routing addiert keine Marge auf den Listenpreis eines Anbieters. Bei Listenpreisen von Anbietern erfolgt die Weitergabe mit 0 % Aufschlag.

Beide Modelle sind für Agenten konzipiert, beide wurden 2026 innerhalb von zwei Monaten zueinander veröffentlicht, und beide Anbieter veröffentlichen genügend überlappende Benchmarks, dass ein echter Vergleich möglich ist statt einer bloßen Zusammenstellung. Das macht dies zu dem seltenen Duell, bei dem die interessante Frage nicht lautet, welches Modell besser ist, sondern auf welcher Achse Ihre Arbeitslast tatsächlich liegt. Nur sehr wenige Aufgaben benötigen sowohl einen BFCL-Wert von 71 als auch einen SWE-bench-Wert von 57, und diejenigen, die es tun, werden von keinem der beiden Modelle allein gut bedient.

Die beiden Zahlen, die sich kreuzen

Granite 4.2 30B wurde am 25. August 2026 unter Apache 2.0 veröffentlicht – ein dichtes Modell mit ~30B Parametern, das auf der Granite 4.1 30B-Basis aufbaut und mit rund 15 Billionen Tokens trainiert wurde. IBMs Positionierung ist Enterprise: drei konfigurierbare Denkmodi, natives Tool-Calling nach dem OpenAI-Schema, zwölf getestete Sprachen und eine dreistufige Trainingspipeline, die in mehrphasigem GRPO-Reinforcement-Learning mündet.

LFM3-1.7B kam zwei Monate später, angekündigt am 27. Oktober 2026, und wurde speziell auf agentische Harnesses nachtrainiert – Liquid nennt Hermes Agent, PI und OpenClaw in der Modellkarte. Es ist ein dichtes Modell mit 1,73B Parametern und 256K Kontext und ausdrücklich für lokale Agenten und Tool Calling positioniert, nicht für allgemeines Reasoning.

Die Benchmark-Überschneidung ist kein Zufall einer einzelnen schwachen Kennzahl. Die gesamte veröffentlichte Tabelle von LFM3-1.7B ist agentisch ausgerichtet: 71,39 BFCL V4, 80,36 ToolSandbox, 68,01 τ³-bench, 45,60 LiveClaw, 38,42 WebArena-Verified. Die Tabelle von Granite ist engineering-lastig: 57,00 SWE-bench Verified, 33,29 SWE-bench Pro, 41,89 SWE-bench Multilingual, 38,76 SciCode, 29,24 bei TerminalBench 2.1. Jeder Anbieter hat für eine andere Definition von „Agent“ optimiert, und die Benchmark-Tabellen sind ehrlich darüber, welche es ist.

τ³ bei 68,01 gegen 68,05 ist die eigentliche Schlagzeile

Unter den beiden dramatischen Abständen verbirgt sich ein Kopf-an-Kopf-Rennen. In τ³-bench, der Tool-Use-Evaluierung, die die Multi-Turn-Aufgabenbewältigung mit Nutzersimulatoren und Domänenrichtlinien misst, erreicht LFM3-1.7B 68,01 und Granite 4.2 30B 68,05 – ein Unterschied von vier Hundertstel Punkten, der nicht von Rauschen zu unterscheiden ist.

Das ist ein interessanteres Ergebnis als jede der beiden großen Lücken, denn τ³ ist der Benchmark, der dem, was die meisten Agenten-Deployments tatsächlich tun, am nächsten kommt: ein Gespräch führen, eine Policy befolgen, die richtige Funktion aufrufen, sich von einem Fehler erholen. Wenn ein 1,73B-Modell dort mit einem 30B-Dense-Modell gleichzieht, kauft die Parameteranzahl etwas anderes als kompetente Tool-Nutzung über mehrere Turns.

Was es bringt, zeigt sich in BFCL und SWE-bench, die unterschiedliche Dinge messen. BFCL V4 testet die Korrektheit einzelner Funktionsaufrufe in einem einzigen Turn gegen ein Schema – die 71,39 von LFM3-1.7B deuten darauf hin, dass sich Liquids Post-Training auf echten Agent-Harnesses direkt ausgezahlt hat. SWE-bench Verified testet die End-to-End-Reparatur eines echten GitHub-Issues, was erfordert, ein Repository im Kontext zu halten, dateiübergreifend zu planen und einen Patch zu erzeugen, der die Tests besteht – Granites 57,00 spiegelt ein Modell wider, das die Fähigkeit dazu besitzt, sowie ein dafür aufgebautes Trainingsset.

Die Aufteilung ist also klar erkennbar. Kleines Modell, gut trainiert auf Tool-Schemas: gewinnt den Function-Call-Test. Großes Modell, trainiert auf Codereparatur: gewinnt den Repository-Test. Gleichstand auf dem Multi-Turn-Mittelweg, auf dem beide gezielt trainiert wurden.

Der Kontext ist der Punkt, an dem die Spezifikationen am stärksten auseinandergehen.

• Kontext — 262.144 Token für LFM3-1.7B; 128K nativ für Granite 4.2 30B, erweiterbar auf 512K. Die Erweiterung ist nicht kostenlos, und IBM ist ehrlich, dass es sich um eine Erweiterung und nicht um ein natives Fenster handelt.

• Beibehaltung langer Kontexte — 65,56 bei RULER mit 128K für LFM3-1.7B gegenüber 81,4 für Granite 4.2 30B in derselben Benchmark-Familie. Das größere Modell behält mehr von einem langen Dokument, was dem Gegenteil dessen entspricht, was die Kontextzahlen in der Überschrift vermuten lassen.

• Speicherbedarf — etwa 1 GB bei 4-Bit gegenüber rund 30B an BF16-Gewichten, mit offiziellen FP8-, NVFP4- und MXFP4-Builds. Dies ist ein Single-GPU-Modell, kein Laptop-Modell.

• Sprachen — sechzehn für LFM3-1.7B gegenüber zwölf für Granite getesteten, mit einer anderen Überschneidung. Granites zwölf umfassen Tschechisch und Niederländisch; die von Liquid umfassen Thai, Vietnamesisch und Indonesisch.

• Denkmodi — Granite 4.2 30B bietet vollständige, aufwandsarme und denkfreie Modi. LFM3-1.7B verfügt über keine solche Oberfläche, und seine Karte besagt, dass es ohnehin nicht für komplexes mehrstufiges Schlussfolgern gedacht ist.

• Lizenz — Apache 2.0 für Granite im Vergleich zur LFM Open License v1.0, die bei einem Jahresumsatz unter 10 Millionen US-Dollar kostenlos ist und darüber eine kommerzielle Lizenz erfordert.

Was 30B dense kostet, was 1,73B nicht kostet

Granite 4.2 30B ist ein dichtes Modell, was bedeutet, dass alle dreißig Milliarden Parameter bei jedem Token zum Einsatz kommen. Es gibt hier keinen Rabatt bei den aktiven Parametern: Die Rechenkosten pro Token liegen ungefähr siebzehnmal so hoch wie bei dem kleinen Modell, und der Speicherbedarf entspricht der vollständigen Gewichtsdatei. IBM liefert Quantisierungen, um das handhabbar zu machen, aber es gibt keine Konfiguration, in der es auf einem Telefon läuft.

Der Vorteil von LFM3-1.7B liegt nicht in erster Linie in der Geschwindigkeit. Sondern darin, dass das Modell in dasselbe Speicherbudget passt wie der Rest Ihrer Anwendung. Ein 1-GB-Modell lässt auf demselben Gerät Platz für einen Dokumentenspeicher, einen Cache und ein zweites Modell – was einen lokalen Agenten erst möglich macht, anstatt ihn bloß theoretisch lokal zu halten. Liquid meldet auf getesteter Hardware eine 1,8- bis 2,8-mal schnellere Dekodierung als bei den Vorgängermodellen sowie einen KV-Cache von 1,6 GB bei 128K – beides wichtig für einen On-Device-Agenten, der ein langes Gespräch führt.

Das Gegenwicht ist, dass Granites 30B-Kapazität in den SWE-bench-Zahlen echte Arbeit leistet. Wenn die Aufgabe Ihres Agenten darin besteht, Code in einem gesamten Repository zu ändern, ist die Lücke von 13,6 Punkten nichts, was ein kleineres Modell durch Prompting aufholt, und die Einsparungen bei der Rechenleistung erkaufen Ihnen ein schlechteres Ergebnis.

Lizenzierung, Signierung und die Beschaffungsfrage

Apache 2.0 ist der Grund, warum eine große Organisation Granite 4.2 30B ohne rechtliche Prüfung einführen kann. Es gibt keine Umsatzschwelle, keinen kommerziellen Auslöser, keine Verhandlung. IBM signiert seit April 2026 außerdem veröffentlichte Granite-Modelle kryptografisch, was nach einem Detail klingt, bis man die Person ist, die nachweisen muss, dass die Gewichte in der Produktion die geprüften Gewichte sind.

Liquid's LFM Open License v1.0 ist im Start-up-Maßstab wirklich permissiv – kostenlos für die kommerzielle Nutzung bei einem Jahresumsatz unter 10 Millionen US-Dollar –, aber oberhalb dieser Grenze ist eine kostenpflichtige kommerzielle Lizenz erforderlich. Für einen einzelnen Entwickler oder ein kleines Team ist das kein Thema. Für einen Geschäftsbereich innerhalb eines größeren Unternehmens ist es ein Gespräch, das vor dem ersten Deployment beginnt und möglicherweise nicht schnell endet. Diese Asymmetrie spiegelt sich in keinem Benchmark wider und entscheidet die Frage oft ganz allein.

Beide laufen lassen, ohne auf eines von beiden zu setzen.

Das praktische Vorgehen für ein Team, das diese beiden evaluiert, besteht nicht darin, zuerst eines auszuwählen. Beide haben offene Gewichte, und beide sind von unabhängigen Evaluatoren noch nicht belegt, was bedeutet, dass der einzige Benchmark, der zählt, Ihr eigener ist. Leiten Sie die Kandidatenmodelle über einen einzigen Endpoint, führen Sie dieselben Agent-Traces durch beide und vergleichen Sie anhand Ihrer Aufgabe statt anhand von BFCL oder SWE-bench.

OrcaRouter ist hier nicht so sehr als Host, sondern als Steuerungsebene nützlich: ein Schlüssel und eine Abrechnung für mehr als 200 Modelle, durchgereichte Anbieter-Listenpreise bei 0 % Aufschlag und automatisches Failover, damit ein Evaluierungslauf nicht deshalb abbricht, weil ein Anbieter eine schlechte Stunde hatte. Weder LFM3-1.7B noch Granite 4.2 30B sind heute in unserem Katalog – beides sind Open-Weight-Downloads, und Self-Hosting ist für beide der Weg. Wo Routing seinen Platz verdient, ist der umgebende Stack: das Frontier-Modell, zu dem dein Agent eskaliert, oder die zweite Meinung, mit der du vergleichst, wenn der Patch des lokalen Modells seine Tests nicht besteht.

Wer sollte welches nehmen

Nimm LFM3-1.7B, wenn der Agent auf dem Gerät des Nutzers läuft, wenn es um Tool-Calling und strukturierte Extraktion gegen eine API geht und wenn ein 256K-Kontext mit 1 GB Speicherbedarf das ist, was das Produkt möglich macht. Akzeptiere die Warnung des Anbieters, dass es nicht für agentisches Coding gedacht ist, und halte ein größeres Modell dahinter bereit für die Fälle, die eines brauchen.

Nehmen Sie Granite 4.2 30B, wenn der Agent eine Codebasis berührt, wenn Sie Apache 2.0 und signierte Gewichte für die Beschaffung benötigen, wenn die Arbeitslast von konfigurierbarem Denkaufwand profitiert und wenn Sie eine GPU zum Bereitstellen haben. Das BFCL-Defizit ist real, aber eng begrenzt: Es misst die Schema-Korrektheit bei einem einzelnen Aufruf, und ein 30B-Modell mit einem gut gestalteten Tool-Schema schließt diese Lücke in der Praxis weitgehend.

Entscheiden Sie sich für die Aufteilung, wenn Sie das bauen, worauf beide Anbieter abzielen — einen lokalen Agenten, der Routine-Tool-Aufrufe in einem Gigabyte erledigt und Arbeit im Repository-Maßstab an einen Server eskaliert. Diese Architektur setzt jedes Modell dort ein, wo seine eigene Benchmark-Tabelle es als stark ausweist, und sie ist die einzige Anordnung, in der die gekreuzten Achsen aufhören, ein Problem zu sein.

Die Frage, die es zu beobachten gilt, ist, ob das agentische Post-Training-Rezept von Liquid auf einen größeren Checkpoint übertragbar ist. Wenn ein zukünftiges LFM-Modell das BFCL-Verhalten der 71,39-Klasse beibehält und zusätzliche Kapazität für Repository-Arbeit hinzugewinnt, fällt die Achsenaufteilung weg und dieser Vergleich wird zu einer einfachen Größenentscheidung. Bis dahin konkurrieren die beiden Modelle nicht um dieselbe Aufgabe — sie sind die zwei Hälften eines Ganzen.