MiniCPM5-2B проти 4B: чому агентний підхід розповідає іншу історію
MiniCPM5-2B перевершує своїх конкурентів 4B за результатами одноразових виконань, але відстає у два-три рази у сценаріях з агентним підходом. Проблеми з тестовими завданнями та продуктивність Ollama.
Джерела: The 2B Model That Beats 4B Rivals — Until You Test It as an Agent
Модель із 2,5 мільярда параметрів, яка, за твердженнями, перевершує конкурентів із 4 мільярдами параметрів у елітних тестах з програмування, здається чудовою пропозицією. Однак якщо використати цю саму модель у справжній багатокроковій агентській системі, її продуктивність може впасти аж у три рази. Оцінки за один запуск мало що говорять про складну реальність розробки програмного забезпечення в умовах виробництва. Якщо не звертати уваги на загальні показники та перевіряти продуктивність локально, можна отримати конкретну схему визначення ситуацій, коли ця модель є правильним інструментом.
Твердження
OpenBMB оприлюднив MiniCPM5-2B 7 вересня 2026 року. Це щільна каузальна мовна модель із 2,516 мільярдів параметрів, ліцензією Apache 2.0 та внутрішнім контекстом обсягом 131,072 токенів. Згідно з оголошенням, це найкраща відкрита модель серед моделей обсягом менше 4 мільярдів параметрів, яка показує середній бал 53,9 за 34 тестування та випереджає кількох конкурентів класу 4 мільярдів параметрів, зокрема Qwen3.5-4B, з такими результатами: MATH-500 — 94,6, AIME 2026 — 86,5, LiveCodeBench v6 — 69,1 та SWE-bench Verified — 46,4.
Тут ніхто не показує вибірковий скріншот табелі лідерів. Запуск був організованим та серйозним: вісім артефактів опустилися одночасно. Цей набір охоплює контрольні точки для базової стадії, середини навчання та окремо для SFT, а також фінальну модель, налаштовану за допомогою RL та OPD, конвертації у форматах GGUF та MLX, версію GPTQ у 4 біти та прототип моделі зі спекулятивним декодуванням під назвою MiniCPM5-2B-DSpark. Лабораторія, яка тихо тестує бенчмарки, не випускає продукт у такому вигляді. Схоже, цей продукт очікує ретельної перевірки та постачається з файлами для кожної потрібної среди виконання — від llama.cpp та Ollama через LM Studio, vLLM та SGLang до Transformers, MLX та мультичіпової системи FlagOS.
За повних умов стверджується, що модель, яка приблизно на 44 відсотки менша за Qwen3.5-4B, перевершує її у тестах з математики, програмування та інженерії програмного забезпечення. Якби це було правдою без жодних застережень, це було б значущим даним щодо масштабування моделей, орієнтованих на міркування після навчання. Однак це не є правдою без застережень, і найцікавіше — це те, де саме виникають проблеми та чому.
Що криється за кулісами
Знання того, що насправді використовується, допомагає, адже архітектура враховує як сильні сторони, так і слабкі місця. MiniCPM5-2B — це декодер, побудований приблизно як LlamaForCausalLM: 42 шари трансформера з використанням групованої уваги до запитів, де 16 голів запитів діляться 2 головами ключів/значень. Коефіцієнт 8 до 1 є значним для моделі такого розміру. Це суттєво зменшує розмір кешу KV на один токен, що є корисним, коли необхідно зберігати довгі історії викликів інструментів або коли кілька сеансів агента використовують одну GPU. Не використовується жодна екзотична розріджена чи лінійна увага, хоча моделі з родини MiniCPM, MiniCPM-SALA та MiniCPM4, експериментували з гібридними підходами. Команда залишилася вірною знайомому механізму та спрямувала зусилля в інші напрямки.
Причини цього — довжина контексту та підбір навчальних даних. Нормальна кількість токенів у 131 072 є незвичною для моделей із 3 мільярдами параметрів, адже більшість моделей такого розміру досягають максимуму близько 32–64 тисяч токенів, після чого якість погіршується. У завданнях, що вимагають від моделі ведення все довшого журналу викликів, змін та результатів роботи з терміналом, цей додатковий простір має більше значення, ніж проста кількість параметрів.
Модель розуміє лише англійську та китайську мови, без підтримки візуальних та аудіоданих. Це свідоме обмеження, а не пропуск, адже кожен параметр, витрачений на багатомодальну налаштовку, — це параметр, який не використовується для міркувань та використання інструментів. OpenBMB також оприлюднила дані після навчання: UltraData-SFT-Agent-2609 із 500 тис. зразків траєкторій дій агента та UltraData-RL-2609 із понад 80 тис. зразків для методу RL. Це справжня прозорість, адже поведінку агента, вбудовану в модель, можна перевірити без необхідності здогадувань на основі дельт у тестах.
Коли архітектура стає зрозумілою, твердження з тестів перетворюються з абстрактних чисел на перевірювані гіпотези щодо конкретного декодера та конкретної схеми навчання.
Перша проривна цифра: 23 проти 15
Проблеми виникли вже протягом дня після запуску. У оголошенні OpenBMB зазначалося, що рейтинг моделі за індексом штучного аналітичного інтелекту становить 23, тоді як незалежний трекер Artificial Analysis показав значення 15. Пізніша корекція індексу дала значення близько 13. Цілком зрозумілою була реакція у вигляді запитання, чи не завищила OpenBMB власні показники.
Цього не сталося, і цю ситуацію варто уважно розглянути, адже імпульсивний гнів є неправильною, а водночас найпоширенішою реакцією на розбіжності у показниках. У поясненні методології від Artificial Analysis пояснюється ця різниця. Коротко кажучи, вона не пов’язана з погіршенням якості моделі. Змінилися критерії оцінки: приватні набори даних тепер становлять 40 відсотків від загальної ваги, що більше, ніж у попередніх версіях, а версія 4.2 додала два нові елементи – оцінку за методом AA-Briefcase та тест на роботу з довгим контекстом.
Цифра 23 від OpenBMB була виміряна за допомогою індексу розуму версії v4.1.1. До того часу, як люди почали порівнювати ці числа, версія індексу в публічному трекері вже оновилася до v4.2, де змінилися коефіцієнти вагомості та з’явилися два компоненти, яких не було під час розрахунку початкової цифри. Порівняння значень 23 у одній версії та 15 у іншій не є ознакою брехні – це просто порівняння двох різних інструментів вимірювання, після чого висловлюється здивування через розбіжності.
Справжня проблема полягає у ранніх публікаціях, де обидві цифри наводилися поруч одна з одною без зазначення того, що вони належать до різних версій індексу, що призвело до хибних висновків, яких дані ніколи не підтверджували. У статтях, де наводиться сумарний бал індексу, необхідно вказувати версію, до якої він належить. Якщо цього не робити, числа 23 та 15 неможливо порівнювати – це насправді два різні показники, які мають спільну назву.
Цю проблему можна вирішити. Іншу – значно складніше усунути.
Справжня різниця: інструменти для агентів
Цифра, яка має вплинути на сприйняття цієї моделі, походить з Terminal-Bench v2.1. У цьому тесті MiniCPM5-2B показує оцінки від 8.6 до 9, тоді як Qwen3.5-4B — 25.8. Це приблизно втричі більша різниця, і через це MiniCPM5-2B посідає восьме місце в цьому тесті, хоча він лідирує в Індексі інтелекту серед моделей свого розміру. SWE-bench Pro показує схожу картину: у MiniCPM5-2B оцінка 14.4, а у Qwen3.5-4B — 28.2, що також становить приблизно подвійну різницю.
Розмістіть це поруч із твердженням про запуск. Результат OpenBMB у тесті SWE-bench Verified, який становить 46,4 та наводиться як кращий за Qwen3.5-4B, є однією з основ публікації про переваги моделі beats-4B. Однак SWE-bench Pro — це не той самий тест з просто більш страшною назвою. Він використовує ширший та більш складний набір реальних проблем з репозиторіями та працює через справжнє агентське середовище, де метод Verified ближчий до генерації патчів за один запуск. Terminal-Bench ще більше віддаляється від оцінки за один запуск — це живе термінальне середовище, у якому модель мусить планувати дії, виконувати команди, читати результати та виправляти власні помилки протягом багатьох етапів.
Незалежна оцінка від MindStudio сформулювала все прямо: модель показує перспективи у деяких агентських тестах, але значно відстає від Qwen у складніших тестах типу SWE-bench Pro та Terminal-Bench.
Цей результат, значно більше, ніж розбіжність версій індексу, має скоригувати очікування. Перемоги, які підтверджуються, — це написання правильного патча для охайного, ретельно підготовленого завдання, що є одноразовою генерацією, представленою як інженерна робота. Terminal-Bench та SWE-bench Pro надають винагороду за стабільну роботу протягом багатьох етапів використання інструменту, відновлення після невдалої команди терміналу та уникнення провалу на третьому кроці плану. Модель, очевидно, добре справляється з першим типом завдань, але значно слабкіша у другому. Будь-хто, хто використовує її як автономного підагента для програмування замість інструменту для створення патчів за один крок, буде стикатися саме з другим типом проблем.
Ця прогалина є реальною та нерозв’язаною, і жоден методологічний фактор її не пояснює, тому її варто перевірити вручну, замість того щоб довіряти сумарним показникам будь-якої зі сторін.
Відтворення локально
Здається, ніхто не опублікував систематичного аналізу кількості токенів на секунду за рівнем квантації на реальному обладнанні. У більшості випадків наводяться лише дані з таблички тестування з версії програмного забезпечення або окремі фактичні показники швидкості. Наведені нижче цифри стосуються лише однієї спроби виконання, а не контрольованих тестів з різними параметрами, тому вони слугують лише підставою для локальних вимірювань, а не остаточними висновками.
Обсяг пам’яті при квантації у режимі 8K:
Q4_K_M: приблизно 2,78 ГБQ8_0: приблизно 3,7 ГБBF16/FP16: приблизно 6,3 ГБ
Дані про продуктивність з незалежних джерел: близько 144,23 токенів на секунду на картці RTX 3070 Ti з 8 ГБ VRAM, з використанням модуля Q4 quant у LM Studio та однієї стрім-сесії – що є досить простою споживчою відеокартою. У обговореннях на Hacker News щодо цього випуску згадувалося, що на одній картці DGX Spark можуть одночасно працювати 32 підагента, які у сумі забезпечують середню швидкість 931 токену на секунду, а максимальна швидкість досягає 1 364 токенів на секунду. Ця друга цифра відповідає запланованому призначенню. Метою не є перемога у змаганнях з затримкою однієї стрім-сесії. Коефіцієнт GQA та невеликі розміри системи розроблені для одночасного обслуговування багатьох сесій, і 32 агента, які ділять один вузол, ідеально підходять для цього.
Найшвидший спосіб відтворити будь-що – це 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
Для конкретної квантації, запозиченої з Hugging Face у llama.cpp:
huggingface-cli download openbmb/MiniCPM5-2B-GGUF \
MiniCPM5-2B-Q4_K_M.gguf \
--local-dir ./minicpm5-2b-gguf
А для масштабованого обслуговування, сумісного з 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"}]}'
Якість змінюється залежно від завдання у способи, які не відображаються у загальних показниках. Практичні тести GGUF у MindStudio показали, що модель Q8_0 добре справлялася з автономним програмуванням та перевірюваними математичними та фізичними розрахунками, але сильно провалилася у завданні на виправлення помилок у SQL, специфічному для певної схеми, та у багатомовному перекладі, надаючи впевнені, але фактично неправильні відповіді.
Така впевнена, але неправильна поведінка має більше значення, ніж будь-який відсоток точності. Очевидні помилки легко виявити під час перевірки, але саме помилка, подана з впевненістю, є причиною того, що пошкоджена міграція SQL потрапляє у продакшн. У відтворюваності є ще одна підступність: llama.cpp поводиться досить по-різному залежно від версії компіляції та від того, як фронтенд застосовує шаблон чату. Якщо локальні значення відрізняються від значень у когось іншого, перевірте версію компіляції, перш ніж припускати, що модель змінилася.
У сукупності місцеві дані підтверджують наявність розбіжностей у тестах Terminal-Bench та SWE-bench Pro. Завдання з чіткими обмеженнями та можливістю перевірки виконуються добре, тоді як ситуація ускладнюється там, де потрібні точні знання зовнішньої структури чи багатоетапні оцінки без чітких критеріїв. Незалежні джерела послідовно підтверджують цю закономірність, що дозволяє покладатися на неї та приймати відповідне рішення.
Коли ця модель є правильним вибором
Як тільки суперечки щодо тестів відкидаються, залишається корисна система прийняття рішень, яка не є оцінкою якості „добре“ чи „погано“.
Ідеальні варіанти:
- Групи з багатьох підагентів, які працюють одночасно. Ключовими є ефективність використання пам’яті завдяки технології GQA та швидкість обробки 931 токену на секунду у 32 агентах на пристрої DGX Spark, що значно важливіше, ніж показник індексу.
Слабкі сторони:
- Генерація коду у вільній формі чи для творчих цілей. У тестах поза контекстом цієї задачі результати були гіршими, ніж у спеціалізованих моделей для програмування, під час створення HTML-сторінок чи SVG-малюнків, оскільки сильні сторони моделі полягають у міркуваннях, математиці, використанні інструментів та виклику функцій.
- Дебагування SQL з урахуванням специфічної схеми та багатомовний переклад, де модель часто дає помилки без можливості їх гідного вирішення.
- Будь-що, що обробляється через складнішу агентську інфраструктуру. Продакшн-агент, який працює з багатокроковими термінальними сеансами чи завданнями рівня Pro на SWE-bench, буде відставати від Qwen3.5-4B у два-три рази, і це не помилка округлення.
Щоб було справедливо, хоча емоційні коментарі це ігнорують: заперечення про те, що для порівнянь використовуються застарілі базові версії, такі як Qwen2.5-2B чи Gemma-2B, стосуються другорядних коментарів, а не офіційної картки моделі. У картці порівнюються найсучасніші моделі – Qwen3.5-2B, Gemma-4-E2B-it, granite-4.2-3B та LFM2.5-2.6B. Критика цієї версії має бути спрямована на її справжню слабкість – різницю в агентській інфраструктурі, а не на скарги щодо базових версій, які спростовуються основним джерелом.
Твердження щодо тестів базуються на конкретних тестах
Якщо не звертати уваги на цю конкретну модель, більш загальний урок є тим, що варто запам’ятати. Твердження щодо Beats-4B є правдивим, але обмеженим. Воно ґрунтується на математичних моделях OpenBMB та наборах для кодування одноразового типу AIME, LiveCodeBench та SWE-bench Verified, а також на збірних даних Artificial Analysis після виправлення версії. Однак воно провалюється на Terminal-Bench та SWE-bench Pro, де Qwen3.5-4B випереджає його у два-три рази. Усе це водночас є правдивим.
Стандартна процедура для будь-яких майбутніх тверджень щодо моделей розміром менше 4B: спочатку протестувати їх принаймні на одному конкурентному тесті, схожому на реальну роботу, такому як Terminal-Bench, SWE-bench Pro чи щось подібне, перш ніж дозволяти набору для одноразового прогнозування визначити, як буде виконуватися завдання агентом. Створення одного патча та виконання багатокрокового завдання — це різні навички, і модель може бути відмінною у першому випадку, але середньою у другому. У опублікованих збірних даних ніколи не зазначається, яка саме з цих навичок є доступною.
Для будь-якого індексу, який фіксує певну версію, чи то від Artificial Analysis, чи від будь-кого іншого, номер версії є обов’язковим метаданим. Він допомагає відрізнити справжню різницю від штучно створеної. Історія з 23 проти 15 здавалася скандалом приблизно день, поки примітки до методології не показали звичайне підвищення версії. Наступна суперечка щодо критеріїв оцінки може вирішитися так само або й інакше, і єдиний спосіб дізнатися — це перевірити.
Що варто запам’ятати
З огляду на свої розміри, MiniCPM5-2B є справді добре спроєктованим інструментом: він має 42 шари, співвідношення GQA 8 до 1, 131K корисного контексту, відкриті дані для навчання та вісім координованих елементів, які працюють з пристроями від DGX Spark до ноутбука. Те, що він показує хороші результати в деяких тестах, але погані — в інших, нічого з цього не скасовує. Критерії оцінки є обмеженими інструментами, кожен з яких вимірює певну конкретну характеристику, тож загальний бал ніколи не розповідає повної історії.
Перш ніж обрати наступну невелику модель, яка здається занадто хорошою, щоб бути правдою, виконайте принаймні один тест на адверсарську агентну діяльність та перевірте версію, яка стоїть за будь-яким сумарним показником індексу. Одна лише цифра з заголовка не повинна визначати архітектуру.
Пов’язані матеріали
- Створення планувального агента в LangGraph: планування, виконання, перепланування, звітування — чотиривузловий планувальний агент LangGraph для фінансових досліджень: структуровані плани, реєстр інструментів із урахуванням простору імен, обмеження на перепланування та приклад виконання зі слідкуванням.