Великі мовні моделі Granite 4.2: як їх створено

Технічний огляд того, як ми створили сімейство моделей міркування Granite 4.2.

Автори: команда Granite, IBM

---

Коротко: Granite 4.2 — це наше перше сімейство щільних LLM-моделей міркування лише з декодером, випущене у трьох розмірах: 3B, 8B і 30B. Кожну модель попередньо навчено з нуля приблизно на 15T токенів за п’ятифазною стратегією, яка розширює контекстне вікно до 512K токенів; потім моделі проходять контрольоване донавчання на даних із ланцюжками міркувань, міркуваннями та агентними траєкторіями, а після цього — донавчання за допомогою багатоетапного конвеєра навчання з підкріпленням. Конвеєр включає агентне RL, у межах якого моделі 8B і 30B навчаються працювати з інструментами в реальних ізольованих середовищах. Кожна модель має перемикач міркування / без міркування, режим міркування з низькими зусиллями, який витрачає короткий бюджет міркувань на прості запитання, а також нативний виклик інструментів. Усі моделі Granite 4.2 випущено за ліцензією Apache 2.0.

Посилання:

• Колекція Granite 4.2 на HF
• Репозиторій GitHub
• Документація Granite

---

Огляд

Granite 4.2 — це орієнтований на міркування реліз сімейства мовних моделей Granite. Попередні релізи Granite були потужними асистентами, які добре виконували інструкції; Granite 4.2 додає явне міркування. Кожна модель може сформувати ланцюжок міркувань перед відповіддю та працювати в режимі міркування або без міркування залежно від того, наскільки ретельного обдумування потребує завдання. Режим із низькими зусиллями є проміжним: він використовує короткий бюджет міркувань для простих запитань.

Три розміри (3B, 8B і 30B) мають однакову архітектуру та проходять той самий конвеєр навчання (попереднє навчання з нуля, SFT, а потім багатоетапне RL), кожен у власному масштабі. Усі три моделі добре міркують і виконують інструкції. Найчіткіше розділення можливостей проявляється на етапі постнавчання. Моделі 8B і 30B додатково проходять блок агентного RL, який навчає їх працювати як агенти: викликати інструменти, редагувати й запускати код, керувати терміналом і шукати інформацію в інтернеті всередині реальних середовищ. Кожна модель підтримує нативний виклик інструментів. Якщо обслуговувати її через сумісну з OpenAI кінцеву точку (наприклад, за допомогою vLLM), вона генерує виклики інструментів у форматі виклику функцій OpenAI та підключається до агентних оболонок без додаткового коду. Granite 4.2 також підтримується в SGLang; готовий рецепт запуску дивіться в кулінарній книзі SGLang.

У решті публікації ми розглянемо процес створення: архітектуру, попереднє навчання, контрольоване донавчання, багатоетапний конвеєр RL і результати.

---

Архітектура моделі

Моделі Granite 4.2 побудовано на щільній трансформерній архітектурі лише з декодером, що містить такі основні компоненти:

• Механізм уваги: групова увага до запитів (GQA) із 40 головками уваги та 8 KV-головками
• Позиційне кодування: обертальне позиційне кодування (RoPE) із θ = 10,000,000
• Прямий прохід: MLP з активацією SwiGLU
• Нормалізація: RMSNorm (ε = 1e-5)
• Вбудовування: окремі вбудовування входу/виходу (не пов’язані)
• Точність: bfloat16

Компонент	Щільна 3B	Щільна 8B	Щільна 30B
Розмір вбудовування	2560	4096	4096
Кількість шарів	40	40	64
Розмір головки уваги	64	128	128
Кількість головок уваги	40	32	32
Кількість KV-головок	8	8	8
Прихований розмір MLP	8192	12800	32768
Активація MLP	SwiGLU	SwiGLU	SwiGLU
Довжина послідовності	131072	131072	131072
Позиційне кодування	RoPE	RoPE	RoPE
# Параметрів	3B	8B	30B

---

Попереднє навчання

Granite 4.2 навчено з нуля приблизно на 15 трильйонах токенів за п’ятифазною стратегією. Фази 1–2 зосереджені на базовому попередньому навчанні, фази 3–4 виконують проміжне навчання з поступовим переходом до даних вищої якості, а фаза 5 запроваджує навчання на довгому контексті, розширюючи контекстне вікно до 512K токенів. Кожна фаза використовує окрему суміш даних і власний графік швидкості навчання, поступово переходячи від широких вебмасштабних даних до більш ретельно відібраних високоякісних джерел.

Рецепт попереднього навчання тісно наслідує попереднє покоління; докладний опис поєднання даних, розкладу фаз і розширення довгого контексту дивіться в блозі Granite 4.1.

---

SFT: підготовка даних і контроль якості

Контрольоване донавчання (SFT) перетворює базову модель на надійного асистента, який виконує інструкції, міркує та використовує інструменти. Суміш даних SFT поєднує агентні (31,6%) і неагентні (68,4%) дані, загалом приблизно 7,2 мільйона прикладів, або близько 100B токенів, із яких приблизно 65B є навчальними.

Агентний корпус охоплює широкий спектр галузей, зокрема програмну інженерію (SWE, 69%), виклик інструментів (12,1%), використання термінала (8,0%), математику (3,5%), пошук (0,8%) і дії (0,2%). Ці приклади та траєкторії генеруються за допомогою різноманітних агентних каркасів і оболонок, зокрема OpenHands, OpenCode, Terminus-2, SWE-agent, OpenResearcher, MiniSWE, OpenSeeker, EnvScaler, Gemini CLI, Hermes, Codex і Goose. Агентні дані поєднують приклади з наборів даних із відкритим кодом і власних синтетично згенерованих середовищ RL, охоплюючи різноманітні комбінації агентів і оболонок.

Неагентний корпус складається з кількох основних категорій: виконання інструкцій (18,8%), програмування (18,8%), математика (14,6%), багатомовність (7,0%), наука (5,4%), міркування (3,0%) і безпека (0,8%).

Контроль якості даних

Перед потраплянням прикладу до фінальної суміші SFT ми застосовуємо кілька етапів контролю якості. Спочатку дані з різних джерел нормалізуються та переформатовуються до узгодженого формату OpenAI Chat, завдяки чому структура діалогу й взаємодія з інструментами є однаковими в усіх наборах даних і каркасах.

Потім ми використовуємо GPT-OSS-120B і Gemma 4 як суддів на основі LLM для оцінювання якості прикладів. Приклади з низькими оцінками видаляються, так само як і приклади, що містять галюциновану або вигадану інформацію, некоректні взаємодії з інструментами чи виклики функцій, не визначених у відповідному списку інструментів. За потреби також застосовуються спеціальні евристичні правила для окремих наборів даних, щоб додатково підвищити якість і усунути відомі джерела шуму.

Нарешті, ми виконуємо локальну та глобальну дедуплікацію. Вона ґрунтується на хешах SHA-256, обчислених для комбінації полів tools і messages, завдяки чому дублікати видаляються як усередині окремих джерел даних, так і в усій суміші SFT.

Деталі навчання SFT

Спочатку весь корпус перемішується глобально, щоб зменшити вплив порядку та забезпечити належне перемішування прикладів із різних галузей під час навчання. Потім перемішаний корпус розподіляється на фрагменти .parquet однакового розміру, які токенізуються токенізатором моделі та її шаблоном чату й готуються до великомасштабного розподіленого навчання.

Перед запуском фінальних великомасштабних прогонів ми налаштовуємо гіперпараметри на репрезентативних конфігураціях, перебираючи графіки швидкості навчання, початкові швидкості навчання та коефіцієнти прогрівання, щоб знайти параметри, які стабільно навчають моделі різних розмірів. Підсумкову конфігурацію навчання наведено нижче:

Фаза 2 SFT для моделі 30B

Для моделі 30B ми додатково виконуємо другу фазу SFT, спеціально зосереджену на агентному програмуванні. На цій фазі агентні дані, SWE- і програмувальні дані збільшуються в кількості, щоб підвищити їхній ефективний внесок у розподіл навчання, тоді як приблизно 16% суміші зберігається як дані повторного відтворення з початкового корпусу SFT.

Потім модель 30B донавчається приблизно ще одну епоху з нижчою швидкістю навчання 3.0e-6. Ця цілеспрямована друга фаза збільшує вплив на модель агентних траєкторій програмування, не втрачаючи можливостей, набутих під час початкової фази SFT.

---

Навчання з підкріпленням: багатоетапний конвеєр у різних середовищах

Після SFT ми застосовуємо багатоетапний конвеєр навчання з підкріпленням у різних середовищах. Замість одного проходу RL ми запускаємо ланцюжок цілеспрямованих етапів у багатьох середовищах: математика, код, наука, виконання інструкцій, використання інструментів і структурований вивід, а потім програмна інженерія, використання термінала та вебпошук. Кожен етап є незалежним прогоном RL, спрямованим на одну можливість і ініціалізованим із контрольної точки попереднього етапу.

Рисунок 1. Поетапна навчальна програма RL. Базове RL (перевірювані винагороди + підсилювачі навичок) виконується для всіх розмірів; блок агентного RL (SWE → термінал → пошук) — лише для 8B і 30B. Кожна модель завершує навчання RLHF. Кожен етап є окремим прогоном GRPO, ініціалізованим із попередньої контрольної точки.

Методологія навчання

На кожному етапі використовується асинхронний GRPO (Group Relative Policy Optimization), тому генератор і тренер не блокують один одного. Пул робітників генерації продовжує вибирати відповіді та поміщати завершені траєкторії до спільного буфера; щойно буфер містить повний крок, тренер забирає цей пакет, виконує крок оптимізатора та передає оновлені параметри робітникам генерації без їхньої паузи. Оновлення може відбутися посеред розгортання, через що одна траєкторія буде складена з двох сусідніх версій політики. Ми допускаємо це, замість того щоб витрачати ресурси на запобігання: робітники повторно використовують наявний KV-кеш, а не перебудовують його після кожного оновлення; єдине обмеження не дозволяє їм відставати від тренера більш ніж на одне оновлення. Будь-яка невідповідність, що залишається в межах цього обмеження, обробляється в цільовій функції за допомогою усіченого вибіркового оцінювання важливості, яке обмежує відношення логарифмічних імовірностей навчання та генерації фіксованою верхньою межею, щоб невелика кількість застарілих токенів не домінувала над оновленням.

Переваги є групово-відносними та використовують базову лінію leave-one-out: кожна відповідь оцінюється порівняно із середньою винагородою інших зразків, згенерованих для того самого запиту, що усуває потребу в окремій мережі значень. Для конкретизації розглянемо RLVR, перший і найдовший етап: кожен крок поєднує 256 запитів із 16 згенерованими відповідями для кожного, утворюючи пакет із 4 096 прикладів, який тренер обробляє одним кроком оптимізатора перед початком наступного розгортання. На наступних етапах механізм залишається незмінним, змінюється лише форма кожного етапу.

Конфігурація навчання RL

Конвеєр зберігає спільний набір гіперпараметрів на всіх етапах, що спрощує запуск і порівняння навчальної програми. Кілька параметрів усюди фіксовані:

Від етапу до етапу змінюється форма кожного прогону: кількість запитів і генерацій за крок, довжина контексту, наявність агентного циклу та сила повернення до еталонної політики. У таблиці нижче наведено точні параметри ланцюжка для 30B, етап за етапом:

Параметри наведено для моделі 30B. Глобальний розмір пакета = запити/крок × генерації/запит (наприклад, 256 × 16 = 4096 для RLVR). Моделі 3B і 8B використовують той самий рецепт і гіперпараметри, але мають менше етапів (див. «Відмінності трьох розмірів»); змінюється список етапів, а не параметри.

Розклад KL відповідає типу винагороди: вільно досліджувати там, де винагорода є об’єктивною та перевірюваною (RLVR і SWE 2 працюють із KL 0), і залишатися близько до еталона там, де мета пов’язана з уподобаннями, безпекою чи вузьким перенесенням навички (RLHF і підсилювач коду використовують KL 0,05). Стовпець ходів розгортання підраховує взаємодії із середовищем, які сам GRPO бачить під час одного розгортання. У кожному випадку модель навчається на повних траєкторіях із реального середовища.

Поетапна навчальна програма

Кожен етап є окремим прогоном RL з однією метою та власним сигналом винагороди. Після завершення його політика експортується у формат Hugging Face і стає базовою моделлю для наступного етапу, тож конвеєр є послідовністю теплої ініціалізації:

SFT ─▶ RLVR ─▶ Skill boosters ─▶ SWE agent ─▶ Terminal ─▶ Search ─▶ RLHF
      └──────── foundational RL ────────┘   └──────── agentic RL (8B / 30B) ────────┘

Моделі 8B і 30B проходять повну послідовність. Модель 3B проходить скорочений шлях: базове RL і вирівнювання без агентного блоку.

Сигнали винагороди

Етап визначається передусім тим, як його оцінюють. У конвеєрі є три типи винагороди, і один етап може використовувати більше одного:

Перевірювані винагороди є об’єктивними, і їх важко обманути, тому конвеєр використовує їх на ранніх етапах. Винагороди від суддів і на основі уподобань обробляють відкриті якості, які не може виразити жоден перевіряльник. Винагороди за агентний результат є найрозрідженішими: часто це лише один біт наприкінці довгої траєкторії використання інструментів.

Базове RL: формування навичок

RLVR: RL із перевірюваною винагородою

RLVR — це базовий етап і найширша суміш даних у конвеєрі: єдиний об’єднаний набір даних, що охоплює багато перевірюваних галузей.

• Математика: ланцюжок міркувань із перевіркою відповіді в рамці, а також формальне доведення в Lean
• Змагальне програмування: рішення перевіряються прихованими тестами в ізольованому середовищі
• STEM / наукові MCQA рівня магістратури та загальні знання
• Виконання інструкцій: завдання зі структурованим виводом та обернені інструкції
• Виклик інструментів / функцій: одноетапне використання інструментів
• Головоломки на міркування та утримання від відповіді (розуміння, коли слід відмовитися)

Кожен тип завдання має власний перевіряльник, тому винагорода обґрунтована для кожного прикладу. RLVR виконується у два раунди для 3B і 8B та у три раунди для 30B. Кожен раунд є новим прогоном із теплою ініціалізацією на переважно зваженій суміші відкритих і внутрішньо підготовлених даних RL.

Підсилювачі навичок: цільове вдосконалення

Після RLVR кілька коротких етапів підсилення загострюють конкретні можливості, яким корисне концентроване навчання в таких галузях:

• Виконання інструкцій (IF): багатотуровий чат, обернений IFEval, структуровані виводи
• Код: лише змагальне програмування

Підсилювачі — це невеликі цілеспрямовані прогони. Невеликий штраф KL утримує модель близько до її поточної поведінки, водночас посилюючи одну навичку.

Агентне RL: навчання діяти (8B / 30B)

На агентних етапах модель навчається діяти: викликати інструменти, спостерігати за результатами та повторювати дії в реальному середовищі, отримуючи винагороду за фактичне виконання завдання. Ці етапи мають однакову структуру: багатотурове використання інструментів, реальні (не симульовані) середовища, розріджені винагороди за результат і GRPO із теплою ініціалізацією з контрольної точки після підсилення програмування. Вони виконуються в такому порядку: SWE → термінал → пошук.

Рисунок 2. Три середовища агентного RL. Кожне поєднує реальну оболонку з реальним середовищем і розрідженою винагородою, заснованою на результаті. Модель 3B не використовує жодного з них.

• SWE-агент (програмна інженерія). Кожне завдання є реальним репозиторієм у власному ізольованому середовищі. За допомогою оболонки OpenHands модель читає код, редагує файли та запускає набір тестів протягом багатьох внутрішніх ходів. Винагорода є перевірюваною: чи проходять приховані тести? Завдання взято з відкритих наборів даних SWE; кожен приклад підтримується образом контейнера для відповідного репозиторію.
• Термінальний агент (робота з терміналом / ОС). Багатокрокові завдання в активній оболонці, що виконуються через агентну оболонку Harbor / Terminus-2. Модель планує послідовність команд, спостерігає за їхнім виводом і відновлюється після помилок. Винагорода нараховується після успішного виконання завдання. Це єдиний етап, на якому багатотуровий агентний цикл виконується на рівні GRPO, а розгортання охоплюють до 64 ходів у середовищі.
• Пошуковий агент (глибоке дослідження). Модель відповідає на складні багатокрокові запитання, використовуючи виклики інструментів живого вебпошуку в циклі агента перегляду: збирає докази на різних етапах, міркує над ними та формує відповідь. Оскільки правильність тут є відкритою, винагороду за фінальну відповідь визначає суддя LLM.

Вирівнювання: RLHF

Фінальним етапом кожної моделі є RLHF для людських уподобань і безпеки. Він оптимізує модель за допомогою генеративної моделі винагороди (GenRM) щодо уподобань, а також винагороди за безпеку, що охоплює стійкість до джейлбрейків і належні відмови. На цьому етапі використовується найвищий штраф KL у конвеєрі, що вирівнює тон і безпеку, не руйнуючи можливості, сформовані попередніми етапами. Окрім узгодження з людськими уподобаннями та вимогами безпеки, цей етап також застосовує штраф за довжину міркувань, щоб стримувати надмірно багатослівну поведінку, набуту на попередніх етапах.

Відмінності трьох розмірів

Метод і інфраструктура однакові; різниця полягає в тому, наскільки далеко по послідовності проходить кожна модель.

3B — це потужна модель базового RL; 8B і 30B додатково проходять блок агентного RL, навчаючись діяти з інструментами в реальних середовищах.

---

Інфраструктура агентного ШІ для масштабованого RL

Навчання з підкріпленням у такому масштабі потребує інфраструктури, здатної одночасно керувати циклом навчання та парком активних середовищ. Найбільше це важливо на агентних етапах, де кожен навчальний приклад є багатотуровим розгортанням, яке редагує код, запускає команди або переглядає вебсторінки. RL для Granite 4.2 працює на двох відкритих компонентах: NeMo-RL на стороні навчання та NeMo-Gym на стороні розгортання.