MiniCPM5-2B kontra 4B: Dlaczego agentowe rozwiązania przedstawiają inny obraz sytuacji

Model z 2,5 miliarda parametrów, który rzekomo przewyższa konkurencyjne modele 4B w elitarnych testach programowania, brzmi jak okazja. Jednak gdy ten sam model zostanie włączony do rzeczywistego systemu wieloetapowego, jego wydajność spada nawet trzykrotnie. Oceny jednorazowe niewiele mówią o skomplikowanej rzeczywistości inżynierii oprogramowania w warunkach produkcyjnych. Przyjrzenie się poza ogólnymi wynikami indeksowymi i odtworzenie wydajności lokalnie dostarcza konkretnych kryteriów określających, kiedy ten model jest odpowiednim narzędziem.

Twierdzenie

OpenBMB opublikował MiniCPM5-2B 7 września 2026 roku. Jest to gęsty model językowy przyczynowo-skutkowy z 2,516 miliarda parametrów, licencją Apache 2.0 oraz natywnym kontekstem obejmującym 131 072 tokenów. Zgodnie z informacjami o wydaniu, jest to najlepszy model otwarty o pojemności poniżej 4 miliardów parametrów, osiągający średnią 53,9 punktu w 34 testach, przewyższając kilku konkurentów z klasy 4B, w tym Qwen3.5-4B, który uzyskał następujące wyniki: MATH-500 na poziomie 94,6, AIME 2026 na poziomie 86,5, LiveCodeBench v6 na poziomie 69,1 oraz SWE-bench Verified na poziomie 46,4.

Nikt tu nie pokazuje selektywnie wybranego zrzutu ekranu z tabeli wyników. Uruchomienie odbyło się w sposób zorganizowany i poważny: osiem artefaktów wylądowało jednocześnie. Zbiór ten obejmuje punkty kontrolne dla etapu bazowego, środkowej fazy szkolenia oraz samej fazy SFT, a także ostateczny model dostosowany za pomocą RL i OPD, konwersje w formatach GGUF i MLX, wersję GPTQ w formacie 4-bitowym oraz prototyp modelu do dekodowania spekulatywnego o nazwie MiniCPM5-2B-DSpark. Laboratorium, które po cichu testuje benchmarki, nie wypuszcza takich rozwiązań. Ten projekt wydaje się oczekiwać dokładnej analizy i dostarcza pliki dla każdego możliwego środowiska działania – od llama.cpp i Ollamy, przez LM Studio, vLLM i SGLang, aż po Transformers, MLX oraz systemy FlagOS wielochipowe.

Według twierdzeń, w pełnej mocy model o około 44 procent mniejszy od Qwen3.5-4B przewyższa go w testach z zakresu matematyki, programowania i inżynierii oprogramowania. Gdyby to dotyczyło bez żadnych zastrzeżeń, byłoby to istotny punkt danych dotyczący skalowalności modeli skupionych na rozumowaniu po szkoleniu. Jednak nie dotyczy to bez zastrzeżeń, a interesujące jest to, gdzie dokładnie występują problemy i dlaczego.

Co kryje się pod maską

Wiedza o tym, co faktycznie jest uruchamiane, jest pomocna, ponieważ architektura uwzględnia zarówno mocne strony, jak i słabe punkty. MiniCPM5-2B to dekoder zbudowany w podobny sposób jak LlamaForCausalLM: 42 warstwy transformatora wykorzystujące uwagę grupowaną z zapytaniami, przy czym 16 głowic zapytań dzieli się 2 głowicami kluczy/wartości. Stosunek 8 do 1 jest imponujący jak na model tej wielkości – znacznie zmniejsza on rozmiar pamięci KV na token, co jest korzystne, gdy trzeba przechowywać długie historie wywołań narzędzi lub gdy wiele sesji agentów korzysta z jednej karty graficznej. Nie używa się żadnej egzotycznej, rzadkiej ani liniowej metody uwagi, mimo że pokrewne modele z rodziny MiniCPM, takie jak MiniCPM-SALA i MiniCPM4, eksperymentowały z hybrydami. Zespół pozostał przy znanym mechanizmie i skupił się na innych rozwiązaniach.

Decydujące czynniki to długość kontekstu oraz selekcja danych treningowych. Naturalna liczba tokenów na poziomie 131 072 jest nietypowa przy parametrach poniżej 3 miliardów, ponieważ większość modeli tej wielkości osiąga maksymalnie od 32 tysięcy do 64 tysięcy tokenów, zanim spada jakość. W zastosowaniach opartych na agentach, gdzie model musi przechowywać coraz dłuższe zapisy połączeń, różnic oraz wyników działania w środowisku shell, ta marginesowa przepustowość ma większe znaczenie niż sama liczba parametrów.

Model obsługuje wyłącznie język angielski i chiński, bez funkcji rozpoznawania obrazu ani audio. Jest to celowe ograniczenie, a nie przeoczenie, ponieważ każdy parametr przeznaczony na synchronizację multimodalną to parametr, którego nie można użyć do rozumowania i korzystania z narzędzi. OpenBMB udostępnił również dane po szkoleniu: UltraData-SFT-Agent-2609 zawierający 500 tysięcy próbek trajektorii agenta oraz UltraData-RL-2609 z ponad 80 tysiącami próbek z zakresu uczenia się przez wzmacnianie. To prawdziwa przejrzystość, ponieważ zachowanie agenta wbudowane w model można sprawdzić bez konieczności domyślania się na podstawie różnic w wynikach benchmarków.

Gdy architektura zostanie zrozumiana, twierdzenia z benchmarków przekształcają się z abstrakcyjnych liczb w hipotezy poddawalne testom dotyczące konkretnego dekodera i określonej metody szkolenia.

Pierwsza luka: 23 przeciwko 15

Problemy pojawiły się w ciągu jednego dnia od uruchomienia. W komunikacie OpenBMB podano, że model osiągnął wynik 23 w indeksie sztucznej inteligencji analitycznej, podczas gdy niezależny tracker Artificial Analysis wskazał wartość 15. Późniejsza rewizja indeksu podniosła tę wartość do około 13. Spodziewaną reakcją było pytanie, czy OpenBMB zawyżyło własne dane.

Nie zrobiło tego, a sprawa zasługuje na uważne przyjrzenie się, ponieważ odruchowy gniew jest niewłaściwą reakcją na różnicę w wynikach benchmarkingu, a jednocześnie najczęstszą. Notatka metodologiczna od Artificial Analysis wyjaśnia tę różnicę. Krótko mówiąc, różnica nie wynika z pogorszenia się modelu. Zmieniono metodę oceny: prywatne zestawy testowe stanowią teraz 40 procent całkowitej wagi, w porównaniu z wcześniejszymi wersjami, a wersja 4.2 dodała dwa nowe elementy – ocenę agentową AA-Briefcase oraz test z długim kontekstem.

Liczba 23 podana przez OpenBMB została uzyskana przy użyciu Intelligence Index v4.1.1. Zanim ludzie mogli porównać te wartości, wersja publiczna przeszła na v4.2, która miała inne wagi oraz dwie składowe, których nie było w wersji użytej do obliczenia początkowej liczby. Porównywanie wartości 23 z wersji jednej z jednej strony i 15 z drugiej nie ujawnia kłamstwa – chodzi tu o porównanie dwóch różnych narzędzi pomiarowych, a następnie wyrażenie zdziwienia z powodu ich różnic.

Prawdziwy błąd leży po stronie wczesnych doniesień prasowych, które przedrukowały obie liczby obok siebie, nie wspominając, że pochodzą one z różnych wersji indeksu, co doprowadziło do błędnego wniosku, którego dane w żaden sposób nie potwierdzały. Artykuł odnoszący się do ogólnej oceny indeksu powinien podać wersję, z którą się ona wiąże. Jeśli tego nie zrobi, liczby 23 i 15 nie mogą być porównywane – są to w rzeczywistości dwa różne pytania, które dzielą ten sam etykietę.

Tę lukę można załatać. Drugą natomiast nie da się zamknąć tak łatwo.

Prawdziwa luka: narzędzia oparte na agentach

Wartość, która powinna wpłynąć na postrzeganie tego modelu, pochodzi z testu Terminal-Bench v2.1. MiniCPM5-2B osiąga tam wyniki w przedziale 8,6–9, podczas gdy Qwen3.5-4B ma wynik 25,8. Jest to różnica około trzykrotna, co sprawiło, że MiniCPM5-2B zajął ósme miejsce w tym teście, mimo że lideruje w rankingu Intelligence Index wśród modeli o podobnej wielkości. Test SWE-bench Pro pokazuje podobny obraz – MiniCPM5-2B ma wynik 14,4, natomiast Qwen3.5-4B 28,2, co daje różnicę około dwukrotną.

Umieść to obok twierdzenia o uruchomieniu. Wynik 46,4 uzyskany przez OpenBMB w teście SWE-bench Verified, który ma pokazać przewagę nad Qwen3.5-4B, stanowi jeden z filarów nagłówka mówiącego o przewadze nad 4B. Jednak SWE-bench Pro to nie ten sam test z tylko bardziej przerażającą nazwą. Wykorzystuje szerszy i bardziej wymagający zbiór rzeczywistych problemów z repozytoriów oraz działa w ramach rzeczywistego narzędzia typu agentic harness, przy czym wersja Verified jest bliższa generowaniu poprawek w trybie jednorazowym. Terminal-Bench jest jeszcze dalej od oceny w trybie jednorazowym – to żywe środowisko terminalowe, w którym model musi planować, wykonywać polecenia, czytać wyniki i naprawiać własne błędy na przestrzeni wielu rund.

Niezależna ocena przeprowadzona przez MindStudio stwierdziła wprost: model wykazuje potencjał w niektórych testach typu agentic, ale znacznie ustępuje Qwen w trudniejszych testach tego typu, jak SWE-bench Pro i Terminal-Bench.

Ten wynik, znacznie bardziej niż niezgodność wersji indeksu, powinien dostosować oczekiwania. Nagrody za napisanie poprawnego patcha do uporządkowanego, starannie przygotowanego zadania, które polega na generacji jednorazowej przedstawianej jako praca inżynierska, są sprawdzane. Terminal-Bench i SWE-bench Pro nagradzają utrzymanie postępów podczas wielu rund używania narzędzi, odzyskanie po nieudanej komendzie wiersza poleceń oraz uniknięcie załamania trzy kroki przed zakończeniem planu. Model wyraźnie radzi sobie dobrze z pierwszym rodzajem zadań, natomiast słabiej z drugim. Każdy, kto używa go jako autonomicznego podagenta do programowania zamiast narzędzia do pisania patchów w jednej rundzie, będzie miał do czynienia z drugim rodzajem problemów.

Ta luka jest rzeczywista i nierozwiązana, a żaden artefakt metodologiczny jej nie wyjaśnia, dlatego należy ją sprawdzić ręcznie, zamiast ufać sumom obu stron.

Odtworzenie lokalnie

Wygląda na to, że nikt nie opublikował systematycznego badania liczby tokenów na sekundę w zależności od poziomu kwantyzacji na rzeczywistym sprzęcie. Dane dostępne to głównie powtórzenia tabeli z testów z czasu wydania produktu lub pojedyncze, anegdotyczne wartości prędkości. Podane poniżej liczby odnoszą się do jednego przebiegu testu, a nie do kontrolowanego badania różnych ustawień, więc służą jako wskazówka do pomiarów lokalnych, a nie jako ostateczny wniosek.

Zajmowana pamięć przy kwantyzacji w kontekście 8K:

• Q4_K_M: około 2,78 GB
• Q8_0: około 3,7 GB
• BF16/FP16: około 6,3 GB

Przekazane wartości wydajności z niezależnych źródeł: około 144,23 tokenów na sekundę na karcie RTX 3070 Ti z 8 GB pamięci VRAM, przy użyciu kwantyzacji Q4 w LM Studio z jednym strumieniem, co jest standardową kartą konsumencką. W przypadku najwyższych modeli dyskusja na Hacker News na temat tej wersji wspomniała o 32 agentach działających jednocześnie na jednej karcie DGX Spark, które łącznie osiągały średnio 931 tokenów na sekundę, a ich maksymalna wartość wynosiła 1 364. Ta druga wartość odpowiada zamierzonemu zastosowaniu – celem nie jest wygranie wyścigu latencji przy jednym strumieniu. Stosunek GQA oraz niewielkie wymiary karty zostały zaprojektowane tak, aby obsługiwać wiele sesji jednocześnie, a 32 agenty dzielące jeden węzeł doskonale do tego pasują.

Najszybszym sposobem na odtworzenie tego efektu jest Ollama:

# macOS
brew install ollama

# Linux
curl -fsSL https://ollama.com/install.sh | sh

# Recommended flags for flash attention + quantized KV cache
OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve &

# Run directly from Ollama's registry
ollama run openbmb/minicpm5-2b

Dla konkretnej kwantyzacji pobranej z Hugging Face do llama.cpp:

huggingface-cli download openbmb/MiniCPM5-2B-GGUF \
  MiniCPM5-2B-Q4_K_M.gguf \
  --local-dir ./minicpm5-2b-gguf

A dla skalowalnej obsługi kompatybilnej z OpenAI, vLLM:

pip install vllm

vllm serve openbmb/MiniCPM5-2B \
  --max-model-len 131072 \
  --dtype bfloat16 \
  --port 8000

# Query it like any OpenAI chat completion endpoint
curl http://localhost:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model": "openbmb/MiniCPM5-2B", "messages": [{"role": "user", "content": "Write a quicksort in Rust"}]}'

Jakość różni się w zależności od zadania w sposób, który nie jest widoczny w ogólnych wskaźnikach. Testy GGUF przeprowadzone przez MindStudio wykazały, że model Q8_0 dobrze radzi sobie z samodzielnym programowaniem oraz weryfikowalnym rozwiązywaniem zadań z matematyki i fizyki, ale słabo funkcjonuje przy zadaniach związanych z debugowaniem SQL specyficznym dla określonego schematu oraz przy tłumaczeniach wielojęzycznych, dając pewne, lecz błędne odpowiedzi.

Takie błędne, choć pewne siebie zachowanie ma większe znaczenie niż jakikolwiek procent dokładności. Wyraźne błędy są łatwe do wykrycia podczas przeglądu, ale to właśnie błędy podawane z pewnością siebie powodują, że wadliwa migracja SQL trafia do produkcji. Reprodukowalność też kryje w sobie pułapkę: llama.cpp zachowuje się zupełnie inaczej w zależności od wersji budowy oraz od sposobu, w jaki interfejs stosuje szablon rozmowy. Gdy lokalne wartości różnią się od tych u kogoś innego, sprawdź wersję budowy, zanim uznasz, że model uległ zmianie.

Łącznie lokalne dane potwierdzają istnienie luki pomiędzy Terminal-Bench a SWE-bench Pro. Zadania o ograniczonych, sprawdzalnych wymaganiach są realizowane dobrze, natomiast sytuacja staje się bardziej niepewna, gdy potrzebna jest dokładna wiedza o zewnętrznym schemacie lub otwarte, wieloetapowe osądy. Niezależne źródła spójnie potwierdzają ten wzorzec, co pozwala na poleganie na nim przy podejmowaniu decyzji.

Kiedy ten model jest właściwym wyborem

Gdy usuniemy spory dotyczące benchmarków, pozostaje przydatna struktura decyzyjna, która nie stanowi oceny jakościowej „dobrego” czy „złego”.

Dobre przypadki zastosowania:

• Grupy wielu podagentów działających jednocześnie. Kluczowe są efektywność pamięci zapewniona przez GQA oraz prędkość 931 tokenów na sekundę u 32 agentów na DGX Spark – to parametry decydujące, znacznie ważniejsze niż wynik indeksu.
• Rozwiązania typu on-device i edge. Wersja o rozmiarze 2,78 GB w czwartym kwartale działa sprawnie na sprzęcie konsumenckim, telefonach i mini-PCach za pomocą GGUF lub MLX.
• Procesy, które przechowują długie zapisy narzędzi lub dokumenty i faktycznie wykorzystują okno 131K, bez oddzielnego warstwy wyszukiwania.
• Inferyencja lokalna, gdzie ważna jest opóźniona reakcja, z wykorzystaniem modelu MiniCPM5-2B-DSpark jako wstępnego modelu do dekodowania spekulatywnego.

Słabe strony:

• Generowanie kodu w formie swobodnej lub kreatywnej. Testy poza specjalistycznymi zastosowaniami pokazały gorsze wyniki w porównaniu z dedykowanymi modelami do programowania przy zadaniami takich jak tworzenie stron HTML czy grafiki SVG, ponieważ moc modelu leży w rozumowaniu, matematyce, używaniu narzędzi i wywoływaniu funkcji.
• Łatanie błędów w SQL opartych na specyficznych schematach oraz tłumaczenie wielojęzyczne, gdzie model często zawodzi bez żadnej elastyczności.
• Wszystko to, co jest przetwarzane za pośrednictwem bardziej skomplikowanych narzędzi typu agentic harness. Agent do kodowania w środowisku produkcyjnym, który musi radzić sobie z wieloetapowymi sesjami terminalowymi lub zadaniami typu SWE-bench na poziomie Pro, wykazuje dwu- do trzykrotną stratę w porównaniu z Qwen3.5-4B, i to nie jest błąd zaokrąglenia.

Należy być sprawiedliwym – skoro niektórzy pomijają ten aspekt, to zarzut, że porównania opierają się na przestarzałych modelach takich jak Qwen2.5-2B czy Gemma-2B, odnosi się raczej do komentarzy dodatkowych, a nie do oficjalnej karty modelu. Karta ta porównuje model z najnowszymi wersjami, takimi jak Qwen3.5-2B, Gemma-4-E2B-it, granite-4.2-3B oraz LFM2.5-2.6B. Krytyka tej wersji powinna skupiać się na jej rzeczywistym słabym punkcie, czyli różnicy w efektywności wynikającej z użycia narzędzi agentic harness, unikając zarzutów dotyczących przestarzałych baz porównawczych, które są już obalone przez oficjalne źródła.

Twierdzenia dotyczące benchmarków są specyficzne dla danego benchmarku

Patrząc poza ten konkretny model, to szersze wnioski są tym, co warto zachować. Twierdzenie dotyczące Beats-4B jest prawdziwe, ale ograniczone. Opiera się na matematyce OpenBMB oraz zestawach do kodowania typu single-shot: AIME, LiveCodeBench i SWE-bench Verified, a także na agregacie Artificial Analysis po poprawieniu wersji. Poddaje się on próbom na Terminal-Bench i SWE-bench Pro, gdzie Qwen3.5-4B wyprzedza go dwukrotnie lub trzykrotnie. Wszystkie te informacje są jednocześnie prawdziwe.

Standardowa procedura przy każdym przyszłym twierdzeniu dotyczącym modeli poniżej 4B to przeprowadzenie ich przynajmniej przez jeden benchmark oparty na rzeczywistych zadaniami, taki jak Terminal-Bench, SWE-bench Pro lub coś równoważnego, zanim pozwoli się zestawowi single-shot przewidzieć wyniki agenta. Stworzenie jednego patcha oraz wykonywanie zadań wieloetapowych to odrębne umiejętności – model może doskonale radzić sobie z pierwszym, będąc przeciętny w drugim. Agregat opublikowany na Twitterze nigdy nie wskazuje, który z tych aspektów jest brany pod uwagę.

Dla każdego indeksu agregowanego z fiksem wersji, niezależnie od tego, czy pochodzi on z Artificial Analysis, czy od kogokolwiek innego, numer wersji nie jest opcjonalnym metadanem. Pozwala on odróżnić prawdziwą rozbieżność od sfabrykowanej. Historia z 23 przeciwko 15 wyglądała jak skandal przez około dzień, dopóki notatki metodologiczne nie ujawniły zwykłej aktualizacji wersji. Kolejna kontrowersja dotycząca standardów pomiarowych może zostać rozwiązana w ten sam sposób lub nie, a jedynym sposobem, by się dowiedzieć, jest sprawdzenie.

Co wynosić z tego

Biorąc pod uwagę swoje rozmiary, MiniCPM5-2B jest naprawdę dobrze zaprojektowany – posiada 42 warstwy, stosunek GQA wynoszący 8 do 1, 131K danych kontekstowych, otwarte dane treningowe oraz osiem skoordynowanych artefaktów obejmujących urządzenia od DGX Spark po laptopa. Fakt, że w niektórych standardach pomiarowych daje dobre wyniki, a w innych słabe, nic z tego nie zmienia. Standardy pomiarowe to wąskie narzędzia, każde mierzące coś konkretnego, a ogólna ocena nigdy nie opisuje całej sytuacji.

Zanim przyjmiesz kolejny mały model, który brzmi zbyt dobrze, by być prawdziwy, przeprowadź przynajmniej jedno testowanie typu adversarial agentic i sprawdź wersję leżącą u podstaw każdego ogólnego wyniku indeksu. Jeden tylko liczbowy wynik z nagłówka nie powinien decydować o architekturze.