LFM3-1.7B vs Granite 4.2 30B: Dwa modele agentowe, które dzielą werdykt według osi

Umieść LFM3-1.7B i Granite 4.2 30B na tej samej stronie, a średnie zagregowane wskazują przeciwne kierunki w zależności od tego, który wiersz czytasz. W Berkeley Function Calling Leaderboard V4 model Liquid AI z 1,73 mld parametrów uzyskuje 71,39 punktu wobec 61,39 IBM — dziesięciopunktowa przewaga dla modelu około siedemnastokrotnie mniejszego. W SWE-bench Verified Granite uzyskuje 57,00 wobec 43,40 LFM3-1.7B, co daje 13,6-punktową przewagę w przeciwnym kierunku.Routing nie dodaje marży do ceny katalogowej dostawcy. Ceny katalogowe dostawców są przekazywane z 0% narzutem.

Oba modele są zbudowane dla agentów, oba zostały wydane w ciągu dwóch miesięcy od siebie w 2026 roku, a obaj dostawcy publikują wystarczająco dużo nakładających się benchmarków, że możliwe jest prawdziwe porównanie, a nie kolaż. To sprawia, że jest to rzadkie starcie, w którym interesującym pytaniem nie jest to, który model jest lepszy, ale na której osi faktycznie opiera się Twoje obciążenie. Niewiele zadań wymaga jednocześnie wyniku 71 w BFCL i wyniku 57 w SWE-bench, a te, które tego wymagają, nie są dobrze obsługiwane przez żaden z modeli osobno.

Dwie liczby, które się przecinają

Granite 4.2 30B ukazał się 25 sierpnia 2026 r. na licencji Apache 2.0 — to gęsty model o ok. 30 mld parametrów, zbudowany na bazie Granite 4.1 30B i wytrenowany na około 15 bilionach tokenów. IBM pozycjonuje go jako rozwiązanie dla przedsiębiorstw: trzy konfigurowalne tryby rozumowania, natywne wywoływanie narzędzi zgodne ze schematem OpenAI, dwanaście przetestowanych języków oraz trójetapowy proces trenowania zakończony wielofazowym uczeniem ze wzmocnieniem GRPO.

LFM3-1.7B pojawił się dwa miesiące później — ogłoszony 27 października 2026 r., dotrenowany specjalnie na harnessach agentowych; Liquid wymienia Hermes Agent, PI i OpenClaw w karcie modelu. To gęsty model o 1,73 mld parametrów z kontekstem 256K, wyraźnie pozycjonowany do lokalnych agentów i wywoływania narzędzi, a nie do ogólnego rozumowania.

Przecięcie wyników benchmarków nie jest przypadkiem jednej słabej liczby. Cała opublikowana tabela LFM3-1.7B przechyla się w stronę agentową: 71,39 BFCL V4, 80,36 ToolSandbox, 68,01 τ³-bench, 45,60 LiveClaw, 38,42 WebArena-Verified. Tabela Granite przechyla się w stronę inżynierską: 57,00 SWE-bench Verified, 33,29 SWE-bench Pro, 41,89 SWE-bench Multilingual, 38,76 SciCode, 29,24 w TerminalBench 2.1. Każdy dostawca optymalizował pod inną definicję „agenta”, a tabele benchmarków uczciwie pokazują, którą.

τ³ przy 68,01 wobec 68,05 to prawdziwy nagłówek

Pod dwiema dramatycznymi lukami kryje się remis. W τ³-bench — ocenie użycia narzędzi, która mierzy ukończenie zadań wieloturowych z symulatorami użytkowników i politykami domenowymi — LFM3-1.7B uzyskuje 68,01, a Granite 4.2 30B 68,05, czyli różnicę czterech setnych punktu, nieodróżnialną od szumu.

To ciekawszy wynik niż którakolwiek z dużych różnic, ponieważ τ³ to benchmark najbliższy temu, co w rzeczywistości robi większość wdrożeń agentów: prowadzić rozmowę, przestrzegać polityki, wywołać właściwą funkcję, podnieść się po błędzie. Jeśli model 1,73B dorównuje tam gęstemu modelowi 30B, liczba parametrów kupuje coś innego niż sprawne wieloturowe korzystanie z narzędzi.

To, co to daje, widać w BFCL i SWE-bench, które mierzą różne rzeczy. BFCL V4 testuje poprawność pojedynczego wywołania funkcji względem schematu — wynik 71,39 modelu LFM3-1.7B sugeruje, że dostrajanie prowadzone przez Liquid na rzeczywistych środowiskach agentowych bezpośrednio się opłaciło. SWE-bench Verified testuje naprawę rzeczywistego zgłoszenia w GitHubie od początku do końca, co wymaga utrzymania repozytorium w kontekście, planowania między plikami i wygenerowania patcha, który przechodzi testy — 57,00 modelu Granite odzwierciedla model zdolny to zrobić oraz zbiór treningowy zbudowany w tym celu.

Podział jest czytelny. Mały model, dobrze wytrenowany na schematach narzędzi: wygrywa test wywołań funkcji. Duży model, wytrenowany na naprawianiu kodu: wygrywa test repozytorium. Remis w wieloturowej części pośredniej, gdzie oba były specjalnie trenowane.

To w kontekście specyfikacje różnią się najbardziej.

• Kontekst — 262 144 tokeny dla LFM3-1.7B; 128K natywnie dla Granite 4.2 30B, z możliwością rozszerzenia do 512K. Rozszerzenie nie jest darmowe, a IBM uczciwie przyznaje, że to rozszerzenie, a nie natywne okno.

• Retencja długiego kontekstu — 65.56 w RULER przy 128K dla LFM3-1.7B wobec 81.4 dla Granite 4.2 30B w tej samej rodzinie benchmarków. Większy model zatrzymuje więcej z długiego dokumentu, co jest przeciwieństwem tego, co sugerują główne liczby dotyczące kontekstu.

• Ślad pamięciowy — około 1 GB przy 4 bitach w porównaniu z około 30B wag BF16, z oficjalnymi buildami FP8, NVFP4 i MXFP4. To model na jedną GPU, a nie model laptopowy.

• Języki — szesnaście dla LFM3-1.7B w porównaniu z dwunastoma testowanymi dla Granite, z innym zakresem wspólnych języków. Dwanaście języków Granite obejmuje czeski i niderlandzki; zestaw Liquid obejmuje tajski, wietnamski i indonezyjski.

• Tryby myślenia — Granite 4.2 30B oferuje tryb pełny, niskiego wysiłku i bez myślenia. LFM3-1.7B nie ma takiej funkcji, a jego karta informacyjna mówi, że z założenia nie jest przeznaczony do złożonego, wieloetapowego rozumowania.

• Licencja — Apache 2.0 dla Granite w porównaniu z LFM Open License v1.0, która jest bezpłatna przy rocznym przychodzie poniżej 10 mln USD, a powyżej tego progu wymaga licencji komercyjnej.

Co kosztuje gęsty model 30B, czego nie kosztuje 1.73B

Granite 4.2 30B jest modelem gęstym, co oznacza, że przy każdym tokenie uruchamiane są wszystkie trzydzieści miliardów parametrów. Nie ma tu ulgi związanej z aktywnymi parametrami: koszt obliczeniowy na token jest około siedemnastokrotnie większy niż w małym modelu, a koszt pamięci to cały plik wag. IBM dostarcza kwantyzacje, aby uczynić to wykonalnym, ale nie istnieje konfiguracja, w której model działałby na telefonie.

Zaletą LFM3-1.7B nie jest przede wszystkim szybkość. Jest nią to, że model mieści się w tym samym budżecie pamięci co reszta aplikacji. Model o rozmiarze 1 GB pozostawia miejsce na magazyn dokumentów, pamięć podręczną i drugi model na tym samym urządzeniu — co sprawia, że lokalny agent jest możliwy, a nie tylko teoretycznie lokalny. Liquid podaje, że dekodowanie jest od 1,8 do 2,8 razy szybsze niż u poprzedników na testowanym sprzęcie, a pamięć podręczna KV wynosi 1,6 GB przy 128K; jedno i drugie ma znaczenie w przypadku agenta działającego na urządzeniu i prowadzącego długą rozmowę.

Przeciwwagą jest to, że pojemność 30B modelu Granite naprawdę przekłada się na wyniki SWE-bench. Jeśli zadaniem twojego agenta jest zmienianie kodu w całym repozytorium, luki 13,6 punktu mniejszy model nie nadrobi przez promptowanie, a oszczędności mocy obliczeniowej oznaczają gorszy wynik.

Licencjonowanie, podpisywanie i kwestia zamówień

Apache 2.0 jest powodem, dla którego duża organizacja może wdrożyć Granite 4.2 30B bez przeglądu prawnego. Nie ma progu przychodowego, wyzwalacza komercyjnego ani negocjacji. IBM od kwietnia 2026 r. również kryptograficznie podpisuje wydane modele Granite, co brzmi jak szczegół, dopóki to ty nie musisz udowodnić, że wagi w środowisku produkcyjnym to wagi, które zostały zweryfikowane.

LFM Open License v1.0 firmy Liquid jest naprawdę permisywna na skalę startupu — bezpłatna do użytku komercyjnego poniżej 10 mln USD rocznego przychodu — ale powyżej tego progu wymaga płatnej licencji komercyjnej. Dla indywidualnego dewelopera lub małego zespołu to nie problem. Dla jednostki biznesowej w większej firmie to rozmowa, która zaczyna się przed pierwszym wdrożeniem i może nie zakończyć się szybko. Ta asymetria nie znajduje odzwierciedlenia w żadnym benchmarku i często sama rozstrzyga tę kwestię.

Prowadzenie obu bez obstawiania żadnego

Praktyczny wzorzec dla zespołu oceniającego te dwa modele nie polega na tym, by najpierw wybrać jeden z nich. Oba mają otwarte wagi i oba są niesprawdzone przez niezależnych ewaluatorów, co oznacza, że jedynym benchmarkiem, który się liczy, jest wasz własny. Przepuść modele kandydujące przez pojedynczy punkt końcowy, uruchom te same ślady działania agenta przez oba i porównuj na podstawie własnego zadania, a nie BFCL lub SWE-bench.

OrcaRouter jest tu przydatny nie tyle jako host, ile jako płaszczyzna sterowania: jeden klucz i jeden rachunek obejmujący ponad 200 modeli, ceny listowe dostawców przekazywane bez marży (0%) oraz automatyczne przełączanie awaryjne, dzięki czemu przebieg ewaluacji nie pada tylko dlatego, że jeden dostawca miał złą godzinę. Ani LFM3-1.7B, ani Granite 4.2 30B nie znajdują się dziś w naszym katalogu — oba są modelami open-weight do pobrania, a dla każdego z nich drogą jest self-hosting. Routing zasługuje na swoje miejsce dzięki otaczającemu stosowi: model frontier, do którego eskaluje Twój agent, albo druga opinia, z którą porównujesz, gdy patch lokalnego modelu nie przechodzi testów.

Kto powinien co wziąć?

Wybierz LFM3-1.7B, jeśli agent działa na urządzeniu użytkownika, jeśli praca polega na wywoływaniu narzędzi i ekstrakcji strukturalnej względem API oraz jeśli kontekst 256K przy zużyciu pamięci 1 GB jest tym, co umożliwia realizację produktu. Przyjmij do wiadomości ostrzeżenie samego dostawcy, że model nie jest przeznaczony do kodowania agentowego, a większy model trzymaj w odwodzie na przypadki, w których jest potrzebny.

Wybierz Granite 4.2 30B, jeśli agent ma do czynienia z bazą kodu, jeśli potrzebujesz Apache 2.0 i podpisanych wag na potrzeby zamówień, jeśli obciążenie zyskuje na konfigurowalnym nakładzie rozumowania oraz jeśli masz GPU, z którego możesz go serwować. Deficyt BFCL jest realny, ale wąski: mierzy poprawność schematu w pojedynczym wywołaniu, a model 30B z dobrze zaprojektowanym schematem narzędzi w praktyce zamyka znaczną część tej luki.

Wybierz ten podział, jeśli budujesz to, do czego dążą obaj dostawcy — lokalnego agenta, który obsługuje rutynowe wywołania narzędzi w ramach gigabajta i eskaluje pracę na skalę repozytorium do serwera. Ta architektura wykorzystuje każdy model tam, gdzie według jego własnej tabeli benchmarków jest mocny, i jest to jedyny układ, w którym przecinające się osie przestają być problemem.

Uwaga warta obserwacji dotyczy tego, czy przepis Liquid na post-training agentowy przenosi się na większy checkpoint. Jeśli przyszły model LFM zachowa zachowanie BFCL z klasy 71,39 i doda pojemność do pracy w repozytoriach, podział osi się załamie, a to porównanie stanie się prostą decyzją o rozmiarze. Do tego czasu oba modele nie konkurują o to samo zadanie — są dwiema połówkami jednej całości.