29 апреля IBM выкатила семейство Granite 4.1 под Apache 2.0 — три плотные модели на 3B, 8B и 30B параметров. Заголовок релиза, который повторяют все: 8B-инструкт стабильно догоняет или обходит собственную предыдущую модель IBM Granite 4.0-H-Small на 32B параметров (9B активных при MoE-архитектуре). И делает это плотным декодером без всяких трюков — ни Mixture-of-Experts, ни расширенным рассуждением (extended reasoning). Та же простая архитектура, в которой каждый параметр работает на каждом токене.
Это либо очень круто, либо предыдущая 32B-модель была собрана недостаточно хорошо. Скорее всего — оба варианта одновременно. И вот этот честный разбор того, что именно дало прирост, мне как ML-инженеру зашёл сильнее, чем сами цифры в табличках.
Та самая цифра, на которой залипаешь
Давайте сразу к мясу. На ArenaHard (бенчмарк, где GPT-4 судит ответы на 500 сложных реальных промптов) 8B-инструкт выбивает 69.0, а старая 32B MoE — меньше. На BFCL V3 — стандартном бенчмарке вызова инструментов — 8B даёт 68.3 против 64.7 у 32B. На GSM8K (школьная математика) — 92.5. На EvalPlus (код) — 80.2. И так по всему чарту: AlpacaEval, MMLU-Pro, BBH, MBPP+ — везде денсная мелочь обходит более жирную MoE-предшественницу.
Старшая 30B-модель, кстати, забирает первое место на BFCL V3 с результатом 73.7, обходя Gemma-4-31B (72.7) — это уже не «своих сравнивали со своими», это публичный лидерборд. А 3B-малыш на BFCL V3 даёт 60.8 — выше, чем Qwen3-8B (60.2), модель в два с лишним раза больше.
Но и пара трезвых оговорок сразу. На IFEval (instruction following) Gemma всё равно ведёт со счётом 94.1 — Granite 8B на 87.1 идёт примерно вровень с Qwen3.5-9B (87.2), но не лидирует. И Hacker News отреагировал жёстко — самый заплюсованный комментарий звучал примерно так: «по сравнению с другими семействами моделей Granite 4.1 8B проигрывает; единственное, в чём он действительно хорош, — это отсутствие галлюцинаций и следование инструкциям». Сообщество указывает, что Qwen 3.5 9B обходит Granite 4.1 30B на нескольких локальных бенчмарках по коду. Так что фрейм «8B матчит 32B MoE» — это внутреннее сравнение IBM в собственной семье моделей, и это полезно держать в голове.
Как это вообще получилось: 15 триллионов токенов и пять фаз
Весь секрет тут не в архитектуре — она почти скучная по нынешним меркам: decoder-only dense transformer, GQA-внимание, RoPE-позиционные эмбеддинги, MLP со SwiGLU, RMSNorm, общие input/output эмбеддинги. Никаких MoE-роутингов, sparse-слоёв, никакого встроенного chain-of-thought режима. Что отправил — то и обработалось, предсказуемо, каждый раз.
Магия — в данных. IBM раскатала 15 триллионов токенов в пять последовательных фаз с разными миксами:
📚 Фаза 1 — широкий захват. CommonCrawl 59%, код 20%, математика 7%. Модель учится «видеть мир целиком».
🧮 Фаза 2 — техасский крен. Математика прыгает до 35%, код до 30%. Веб-данные отходят на второй план — теперь учим думать.
🧠 Фазы 3 и 4 — заточка. В микс подмешивают траектории цепочку рассуждений (chain-of-thought) и instruction-данные плюс самый высококачественный веб-контент, который у IBM есть.
📏 Фаза 5 — растягиваем контекст. До 512K токенов для 8B и 30B (3B доходит «всего» до 128K).
Большинство команд выбирают один data mix и обучают на нём всю претрейн-сессию. IBM меняла его четыре раза с явным намерением на каждом шаге. Это, кстати, та самая идея обучения по нарастающей сложности (curriculum learning), к которой все возвращаются после очередного цикла «давайте просто увеличим параметры». И кажется, у IBM получилось.
Тренировали на NVIDIA GB200 NVL72 в облаке CoreWeave — упомяну это, потому что инфраструктурный момент важен: GB200 — это уже Blackwell, и без такого железа продавить 15T токенов через несколько фаз с разными миксами было бы запретительно дорого по времени.
Фильтр-палач: как они выбросили мусор до того, как он успел навредить
Тут начинается самая интересная инженерная часть. После предобучения нужно превратить базовую модель в нормальный инструкт-помощник через SFT (supervised fine-tuning). Проблема в том, что плохие примеры в SFT-датасете — это не нейтральный шум. Это сигнал, который модель честно усваивает. Галлюцинированный ответ, ответ невпопад, уверенно неправильное вычисление — модель учится производить именно это.
IBM построила перед SFT-этапом трёхуровневый фильтр:
🧑⚖️ LLM судья (LLM-as-Judge) оценивал каждый ответ по шести параметрам: следование инструкции, корректность, полнота, лаконичность, естественность и калиброванность (насколько модель «знает, чего она не знает»). Ответы ниже порога летели в мусорку.
❌ Жёсткие триггеры авто-отбраковки. Галлюцинации, ложные предпосылки, неправильные вычисления — мгновенный кик независимо от итогового скора. Никаких частичных кредитов. В RAG-сценариях, если ответ не был обоснован извлечёнными документами — это считалось галлюцинацией. В tool-calling сценариях вызовы сверялись с разрешёнными тулами и схемами параметров.
🧰 Rule-based pipeline. Поверх LLM-судьи — обычный детерминистический контроль: длина, форматирование, валидация схем, дедупликация по всему датасету.
На выходе осталось 4.1 миллиона отфильтрованных примеров. Звучит много. Но в эпоху, когда коммьюнити-датасеты раздувают до десятков миллионов синтетического шума, 4.1M кураторских образцов — это нарочитая сдержанность. И именно она, по моему опыту, обычно даёт лучший результат, чем массивные грязные корпусы.
Четыре раунда RL, или «честная история о том, как мы сломали математику и починили её»
Это, на мой вкус, самая ценная часть техрепорта IBM. Они открыто признают, что у них что-то поломалось в середине обучения, и описывают, как это лечили.
После SFT в IBM провели четыре последовательных этапа обучения с подкреплением (RLHF):
🎯 Стадия 1 — совместное обучение по 9 доменам сразу. Математика, естественные науки, логика, следование инструкциям, структурированный вывод, преобразование текста в SQL, временное (темпоральное) рассуждение, общий диалог, обучение в контексте. Зачем все вместе? Чтобы модель не забывала ранние домены, пока полирует поздние. Каждый шаг градиента видит весь спектр задач.
💬 Стадия 2 — RLHF на чат-промптах. AlpacaEval подскочил в среднем на +18.9 пункта. Чатовая помощь стала заметно лучше.
🔥 Тут поломалось. RLHF, улучшая чат, просадил математику. И GSM8K, и DeepMind-Math регрессировали. Это очень знакомая история — RLHF-этап давит модель в сторону «приятных» ответов и часто рушит более «скучные» способности типа точного счёта.
🪪 Стадия 3 — калибровка идентичности и знаний. Короткие 40 шагов, чтобы стабилизировать, как модель представляет себя и что она знает. Маленькая стадия, но измеримое улучшение на самоидентификации.
🔧 Стадия 4 — спасение математики отдельной RL-сессией. Сработало: GSM8K вернулся и переплюнул SFT-бейзлайн на +3.8, DeepMind-Math восстановился на +23.5 пункта.
Что мне в этом нравится — это инженерная честность. Большинство релизов выходят с лоснящимся техрепортом, где всё шло по плану. IBM у себя говорит: «мы попробовали — просела математика, поэтому сделали отдельный рантайм для восстановления». Это уровень открытости, который реально полезен сообществу.
512K контекст без потери ближнего радиуса
Расширить контекст до 512K — задача по нынешним меркам решённая. Но расширить до 512K, не потеряв качество на 4K — задача отдельная и куда более противная. Когда модель учится держать в голове книгу на пол-миллиона токенов, она часто перестаёт нормально работать на коротких запросах.
IBM решила это с помощью поэтапного расширения с последующим объединением результатов. Сначала 32K. Потом 128K. Потом 512K. На финальной стадии переключились на микс 80% книги / 20% код-репозитории — потому что у книг и больших кодовых баз есть естественная связность на десятках тысяч токенов, которой у веб-данных нет.
И главный трюк — после каждой стадии расширения IBM делала model merging: сливала длинноконтекстный чекпойнт обратно с более ранними весами. Это вместо того чтобы просто продолжать обучение. Цель — сохранить ту самую короткоконтекстную компетенцию, которая иначе уплывает.
На бенчмарке RULER (он специально проверяет, что длинный контекст реально работает, а не просто формально влезает) 8B даёт 83.6 на 32K, 79.1 на 64K, 73.0 на 128K. Деградация есть, но без обрыва. 30B держится получше: 85.2 / 84.6 / 76.7.
Что я думаю обо всём этом
Тут стоит честно развести две вещи. Это не frontier-модель. Granite 4.1 не догоняет ни Claude Opus 4.7, ни топовые reasoning-модели OpenAI/Google. Это и не задача, которую IBM решала.
То, что IBM сделала, — это контртрендовая ставка. Пока NVIDIA Nemotron, GLM-5.1, Mistral Large 3 и большинство релизов 2026 года кренятся в сторону MoE + reasoning-режимов с длинными цепочками рассуждений, IBM удваивает ставку на dense + no-reasoning + экстремально длинный контекст. И ставит на enterprise-сегмент, в котором:
🧾 Стоимость инференса должна быть предсказуемой. Никаких «ой, модель решила подумать ещё 3000 токенов». Что отправили — то и обработали, цена линейна.
⚡ Латентность должна быть детерминированной. Кастомер-сервис чатбот не может иногда отвечать за 200 мс, а иногда за 8 секунд из-за reasoning-режима.
📜 Лицензионная чистота — обязательна. Apache 2.0, к тому же модели первыми в мире получили сертификацию ISO 42001 и идут с криптографическими подписями. Для регулируемых отраслей (банки, медицина, госсектор) это не nice-to-have — это допуск к продакшену.
🔧 Архитектура должна быть простой для дотюнинга. Плотный декодер дотюнится без сюрпризов. MoE-модели — головная боль для команд, которые раньше с экспертными роутерами не работали.
Если вы делаете разговорный поиск по корпоративной доке, агента-помощника саппорта, или тулзу с tool calling по предсказуемому списку API — Granite 4.1 8B реально стоит померить против Qwen3.5-9B и Gemma на ваших данных. Если вы пишете код или решаете олимпиадную математику — берите что-то другое.
Меня лично в этой истории больше всего трогает методологическая часть. Нынешнее поколение open-weight-релизов учит ML-инженеров одной вещи: прогресс достигается не размером, а данными и pipeline-инженерией. 4.1M отфильтрованных SFT-сэмплов, четыре стадии RL с честным признанием регрессии и её фиксом, model merging на длинном контексте — всё это техники, которые применимы в проектах сильно меньшего масштаба, чем IBM. Если у вас есть, скажем, доменный SFT-набор и вы дотюните Qwen или Mistral — вот здесь стоит почитать репорт IBM целиком и подсмотреть, как они отсеивали мусор.
Мой итоговый вывод: «8B обгоняет 32B» — это маркетинговый заголовок, к которому стоит относиться с долей скепсиса. Реальная новость — IBM показала, что внимание к качеству данных даёт выигрыш одного порядка с увеличением параметров. Если кто-то ещё сомневался, что эра «навалим параметров — пойдут метрики» постепенно сменяется эрой «навалим pipeline-инженерии — пойдут метрики», — Granite 4.1 это иллюстрирует довольно убедительно.
Запустить, кстати, всё крайне просто — ollama pull granite4.1 в терминале, и вы пробуете 8B на своей машине. FP8-квантование сжимает модель примерно вдвое с минимальной потерей качества — на 16-гиговой видеокарте 8B-инструкт пойдёт без вопросов.
Источники:
🔗 Оригинальный разбор Firethering — firethering.com: Granite 4.1: IBM's 8B Model Is Competing With Models Four Times Its Size
🔗 Анонс IBM Research — research.ibm.com: Introducing the IBM Granite 4.1 family of models
🔗 Карточка модели Granite-4.1-8B на Hugging Face — huggingface.co/ibm-granite/granite-4.1-8b
🔗 Документация IBM по семейству Granite 4.1 — ibm.com/granite/docs/models/granite4-1
🔗 Вся коллекция моделей на Hugging Face — huggingface.co: Granite 4.1 Language Models
🔗 Granite 4.1 на Ollama для локального запуска — ollama.com/library/granite4.1
🔗 Критический разбор от byteiota с реакцией Hacker News — byteiota.com: Granite 4.1 IBM 8B Model Beats 32B Through Training Quality
🔗 Контекст про предыдущее поколение Granite 4.0 — ibm.com: IBM Granite 4.0 Hyper-efficient High Performance Hybrid Models
🔗 Аналитический пост Себастьена Дюбуа о позиционировании Granite 4.1 — dsebastien.net/granite-4-1