Големите езикови модели Granite 4.2: Как са създадени

Технически преглед на начина, по който създадохме семейството reasoning модели Granite 4.2.

Автори: Екипът на Granite, IBM

---

Накратко: Granite 4.2 е първото ни семейство от плътни, decoder-only reasoning LLM модели, предлагани в три размера: 3B, 8B и 30B. Всеки модел е предварително обучен от нулата върху приблизително 15 трилиона токена с петфазова стратегия, която разширява контекстния прозорец до 512K токена, след което е дообучен с учител върху данни за верига на мисълта, reasoning и агентски траектории, а накрая е дообучен с многоетапен pipeline за обучение с подсилване. Този pipeline включва агентско RL, при което моделите 8B и 30B се научават да работят с инструменти в реални среди в пясъчник. Всеки модел има превключвател между режими с мислене / без мислене, режим на мислене с ниско усилие, който използва кратък бюджет за reasoning при лесни въпроси, както и вградена поддръжка за извикване на инструменти. Всички модели Granite 4.2 се разпространяват под лиценза Apache 2.0.

Връзки:

• HF колекция Granite 4.2
• GitHub хранилище
• Документация за Granite

---

Общ преглед

Granite 4.2 е ориентираното към reasoning издание на семейството езикови модели Granite. По-ранните издания на Granite бяха силни асистенти за следване на инструкции; Granite 4.2 добавя явно reasoning. Всеки модел може да генерира верига на мисълта преди отговора си и може да работи в режим с мислене или без мислене в зависимост от това колко обмисляне изисква задачата. Режимът с ниско усилие е междинен вариант, който използва кратък бюджет за reasoning при лесни въпроси.

Трите размера (3B, 8B и 30B) споделят един и същ архитектурен дизайн и следват един и същ обучителен pipeline (предварително обучение от нулата, SFT и след това многоетапно RL), всеки в своя мащаб. И трите са силни в reasoning и следването на инструкции. Най-ясното разделение по способности се проявява при дообучението. Моделите 8B и 30B допълнително преминават през етап на агентско RL, който ги учи да действат като агенти: да извикват инструменти, да редактират и изпълняват код, да управляват терминал и да търсят в интернет в реални среди. Всеки модел поддържа вградено извикване на инструменти. Когато се обслужва чрез съвместим с OpenAI endpoint (например с vLLM), той генерира извиквания на инструменти във формата за function calling на OpenAI и се интегрира в агентски harness-и без допълнителен свързващ код. Granite 4.2 се поддържа и в SGLang; вижте рецептата за SGLang за готова конфигурация за обслужване.

В останалата част на публикацията разглеждаме изграждането: архитектурата, предварителното обучение, supervised fine-tuning, многоетапния RL pipeline и резултатите.

---

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

Моделите Granite 4.2 са изградени върху плътна transformer архитектура само с decoder със следните основни компоненти:

• Attention: Grouped Query Attention (GQA) с 40 attention глави и 8 KV глави
• Position Embedding: Rotary Position Embedding (RoPE) с θ = 10 000 000
• Feed-Forward: MLP с активация SwiGLU
• Normalization: RMSNorm (ε = 1e-5)
• Embeddings: Отделни входни/изходни embeddings (не са свързани)
• Precision: bfloat16

Компонент	3B Dense	8B Dense	30B Dense
Размер на embedding-а	2560	4096	4096
Брой слоеве	40	40	64
Размер на attention главата	64	128	128
Брой attention глави	40	32	32
Брой KV глави	8	8	8
Скрита MLP размерност	8192	12800	32768
MLP активация	SwiGLU	SwiGLU	SwiGLU
Дължина на последователността	131072	131072	131072
Позиционно embedding	RoPE	RoPE	RoPE
# Параметри	3B	8B	30B

---

Предварително обучение

Granite 4.2 е обучен от нулата върху приблизително 15 трилиона токена с петфазова обучителна стратегия. Фази 1–2 са насочени към базово предварително обучение, фази 3–4 извършват междинно обучение с постепенно отгряване на данни с по-високо качество, а фаза 5 въвежда обучение с дълъг контекст и разширява контекстния прозорец до 512K токена. Всяка фаза използва различна смес от данни и график на learning rate, като постепенно преминава от широкообхватни уеб данни към по-подбрани, висококачествени източници.

Рецептата за предварително обучение следва отблизо предишното поколение; за подробно разглеждане на сместа от данни, графика на фазите и разширяването на дългия контекст вижте публикацията за Granite 4.1.

---

SFT: Подготовка на данните и контрол на качеството

Supervised fine-tuning (SFT) превръща базовия модел в надежден асистент за следване на инструкции, reasoning и използване на инструменти. Сместа от SFT данни комбинира агентски (31,6%) и неагентски (68,4%) данни, общо приблизително 7,2 милиона извадки, или около 100 милиарда токена, от които около 65 милиарда са обучаеми.

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

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

Контрол на качеството на данните

Прилагаме няколко етапа на контрол на качеството, преди дадена извадка да влезе във финалната SFT смес. Първо, данните от различните източници се нормализират и преформатират в единен OpenAI Chat формат, така че структурата на разговорите и взаимодействията с инструментите да са еднакви във всички набори от данни и scaffolds.

След това използваме GPT-OSS-120B и Gemma 4 като LLM-базирани оценители за преценка на качеството на извадките. Извадките с ниски оценки се премахват, както и тези, съдържащи халюцинирана или измислена информация, невалидни взаимодействия с инструменти или извиквания на функции, които не са дефинирани в съответния списък с инструменти. Когато е уместно, прилагаме и няколко целеви евристични правила, специфични за отделните набори от данни, за допълнително подобряване на качеството и отстраняване на известни източници на шум.

Накрая извършваме както локална, така и глобална дедупликация. Дедупликацията се основава на SHA-256 хешове, изчислени върху комбинацията от полетата tools и messages, като се премахват дублираните извадки както в отделните източници на данни, така и в цялата SFT смес.

Подробности за SFT обучението

Пълният корпус първо се разбърква глобално, за да се намалят ефектите от реда и да се гарантира, че извадките от различни области са добре смесени по време на обучението. След това разбърканият корпус се разделя на еднакви по размер фрагменти .parquet, които се токенизират с tokenizer-а и chat template-а на модела и се подготвят за широкомащабно разпределено обучение.

Преди стартирането на финалните широкомащабни изпълнения настройваме хиперпараметрите върху представителни конфигурации, като изпробваме графици на learning rate, начални learning rate стойности и коефициенти за warm-up, за да намерим настройки, които се обучават стабилно при различни размери на моделите. Финалната обучителна конфигурация е обобщена по-долу:

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

За модела 30B допълнително извършваме втора фаза на SFT, фокусирана специално върху агентско програмиране. В тази фаза агентските, SWE и програмните данни се oversample-ват, за да се увеличи ефективният им принос към обучителното разпределение, докато приблизително 16% от сместа се запазва като replay данни от оригиналния SFT корпус.

След това моделът 30B се дообучава за приблизително още една епоха с по-нисък learning rate от 3.0e-6. Тази целева втора фаза увеличава излагането на модела на агентски траектории за програмиране, без да се губят способностите, придобити по време на първоначалната SFT фаза.

---

Обучение с подсилване: многоетапен pipeline в множество среди

След SFT прилагаме многоетапен pipeline за обучение с подсилване в множество среди. Вместо един-единствен RL проход изпълняваме верига от фокусирани етапи в множество среди: математика, код, наука, следване на инструкции, използване на инструменти и структурирани изходи, след което софтуерно инженерство, използване на терминал и уеб търсене. Всеки етап е независимо RL изпълнение, насочено към една способност и стартиращо от checkpoint-а на предишния етап.

Фигура 1. Поетапната RL програма. Фундаменталното RL (проверими награди + усилватели на уменията) се изпълнява за всички размери; блокът за агентско RL (SWE → терминал → търсене) се изпълнява само за 8B и 30B. Всеки модел завършва с RLHF. Всеки етап е отделно GRPO изпълнение, което започва от предишния checkpoint.

Методология на обучението

Всеки етап се обучава с асинхронен GRPO (Group Relative Policy Optimization), така че генераторът и обучаващата част на цикъла никога да не се блокират взаимно. Пул от worker-и за генериране постоянно взема извадки от отговори и поставя готовите траектории в споделен буфер; когато буферът събере достатъчно данни за цяла стъпка, trainer-ът извлича batch-а, изпълнява optimizer стъпка и предава обновените параметри обратно към worker-ите за генериране, без да ги спира. Обновяване може да настъпи по средата на rollout, оставяйки една траектория, съставена от две съседни версии на политиката. Допускаме това, вместо да плащаме цената за предотвратяването му: worker-ите използват повторно съществуващия си KV cache, вместо да го изграждат отново след всяко обновяване, а единствената защитна мярка е ограничение, което не им позволява да изостават с повече от една актуализация спрямо trainer-а и така ограничава отклонението от политиката. Всяко несъответствие, останало в рамките на това ограничение, се обработва в целевата функция чрез усечено importance sampling, което ограничава съотношението между log-вероятностите при обучение и генериране до фиксиран таван, така че няколко остарели токена да не доминират дадена актуализация.

Предимствата са относителни спрямо групата и използват leave-one-out baseline: всеки отговор се оценява спрямо средната награда на останалите извадки, генерирани за същия prompt, което премахва нуждата от отделна value мрежа. За конкретен пример, нека разгледаме RLVR, първия и най-дълго изпълняван етап: всяка стъпка съпоставя 256 prompts с 16 генерирани отговора за всеки за batch от 4096 примера, който trainer-ът обработва с една optimizer стъпка, преди да започне следващият rollout. По-късните етапи запазват този механизъм непроменен и коригират само формата за съответния етап, показан по-долу.

Конфигурация на RL обучението

Pipeline-ът запазва общ набор от хиперпараметри във всички етапи, което улеснява изпълнението и сравняването на програмата. Няколко настройки са фиксирани навсякъде:

Това, което се променя от етап до етап, е формата на всяко изпълнение: колко prompts и генерирания има на стъпка, колко дълъг е контекстът, дали работи агентският цикъл и колко силно се връщаме към референтната политика. Таблицата по-долу дава точните настройки за веригата при 30B, етап по етап:

Показани са параметрите за модела 30B. Глобален batch size = prompts/стъпка × генерирания/prompt (напр. 256 × 16 = 4096 за RLVR). Моделите 3B и 8B използват същата рецепта и хиперпараметри с по-малко етапи (вижте „Разлики между трите размера“); променя се списъкът с етапи, а не настройките.

Графикът на KL следва типа награда: изследване без ограничения, когато наградата е обективна и проверима (RLVR и SWE 2 работят при KL 0), и близост до референтната политика, когато целта е свързана с предпочитания, безопасност или тясно специализирано умение (RLHF и code booster използват KL 0.05). Колоната rollout-turns отчита взаимодействията със средата, които самият GRPO вижда за един rollout. Във всички случаи моделът се обучава върху пълни траектории от реална среда.

Поетапната програма

Всеки етап е отделно RL изпълнение с единствена цел и собствен сигнал за награда. След приключването му политиката се експортира във формат на Hugging Face и става базов модел за следващия етап, така че pipeline-ът представлява последователност от warm-start:

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

Моделите 8B и 30B следват пълната стълбица. Моделът 3B следва съкратен път: фундаментално RL и подравняване, без агентския блок.

Сигнали за награда

Етапът се определя предимно от това как се оценява. В целия pipeline има три типа награди, като един етап може да използва повече от един:

Проверимите награди са обективни и трудни за манипулиране, затова pipeline-ът ги поставя в началото. Наградите от оценители и предпочитанията обработват отворени качества, които никой проверяващ не може да изрази. Наградите за агентски резултат са най-оскъдни: често представляват един-единствен бит в края на дълга траектория с използване на инструменти.

Фундаментално RL: изграждане на уменията

RLVR: RL с проверима награда

RLVR е фундаменталният етап и най-широката смес от данни в pipeline-а: единна комбинирана колекция, обхващаща множество проверими области.

• Математика: верига на мисълта с проверка на отговор в кутия, както и формално доказване в Lean
• Състезателно програмиране: решения, проверявани със скрити тестове в пясъчник
• STEM / научни MCQA въпроси на ниво висше образование и общи знания
• Следване на инструкции: задачи със структурирани изходи и обратни инструкции
• Извикване на инструменти / функции: използване на инструмент в една стъпка
• Пъзели за reasoning и въздържане от отговор (разпознаване кога трябва да се откаже)

Всеки тип задача има собствен проверяващ, така че наградата е обоснована за всеки пример. RLVR се изпълнява на два тура за 3B и 8B и три за 30B. Всеки тур е ново изпълнение с warm-start върху претеглена наново смес от публични и вътрешно подбрани RL данни.

Усилватели на умения: целеви подобрения

След RLVR няколко кратки етапа тип booster изострят конкретни способности, които се възползват от концентрирано обучение, фокусирано върху следните области:

• Следване на инструкции (IF): многоходови разговори, inverse-IFEval, структурирани изходи
• Код: само състезателно програмиране

Booster-ите са малки, фокусирани изпълнения. Леката KL санкция задържа модела близо до текущото му поведение, като същевременно подобрява едно конкретно умение.

Агентско RL: обучение за действие (8B / 30B)

В агентските етапи моделът се учи да действа: да извиква инструменти, да наблюдава резултатите и да повтаря действията в реална среда, като получава награда според това дали задачата действително е решена. Тези етапи споделят една и съща форма: многоходово използване на инструменти, реални (не симулирани) среди, разредени награди за резултат и GRPO, стартиращи от checkpoint-а след усилване на програмирането. Изпълняват се в следния ред: SWE → Terminal → Search.

Фигура 2. Трите среди за агентско RL. Всяка съчетава реален harness с реална среда и разредена награда, базирана на резултата. Моделът 3B не използва нито една от тях.

• SWE агент (софтуерно инженерство). Всяка задача е реално хранилище в собствен пясъчник. Управляван чрез harness-а OpenHands, моделът чете код, редактира файлове и изпълнява тестовия пакет през множество вътрешни итерации. Наградата е проверима: преминават ли скритите тестове? Задачите са взети от отворени SWE набори от данни, като всеки екземпляр е подкрепен от container image за съответното хранилище.
• Terminal агент (терминал / операции с ОС). Многостъпкови задачи в активна shell среда, изпълнявани чрез агентския harness Harbor / Terminus-2. Моделът планира последователност от команди, наблюдава изхода им и се възстановява от грешки. Наградата се присъжда при успешно приключване на задачата. Това е единственият етап, който управлява своя многоходов агентски цикъл на ниво GRPO, с rollout-и, обхващащи до 64 взаимодействия със средата.
• Search агент (задълбочено проучване). Моделът отговаря на трудни въпроси с множество преходи, използвайки активни извиквания на инструменти за уеб търсене в агентски цикъл за сърфиране: събира доказателства през няколко прехода, разсъждава върху тях и създава отговор. Тъй като коректността тук е отворена, наградата се определя от LLM оценител върху крайния отговор.

Подравняване: RLHF

Финалният етап на всеки модел е RLHF за човешки предпочитания и безопасност. Той се оптимизира спрямо генеративен reward model (GenRM) за предпочитания, плюс награда за безопасност, обхващаща устойчивост на jailbreak и подходящи откази. Този етап използва най-високата KL санкция в pipeline-а, като подравнява тона и безопасността, без да влошава способностите, изградени от по-ранните етапи. Освен подравняването с човешки предпочитания и безопасност този етап прилага и санкция за дължината на reasoning-а, за да обезкуражи прекалено многословното поведение при reasoning, придобито в по-ранните етапи.

Разлики между трите размера

Методът и инфраструктурата са еднакви; разликата е докъде по стълбицата стига всеки модел.

3B е силен модел с фундаментално RL; 8B и 30B добавят блока за агентско RL и се научават да действат с инструменти в реални среди.

---

Инфраструктура за агентски AI за мащабируемо RL

Обучението с подсилване в този мащаб изисква инфраструктура, която едновременно да управлява обучителен цикъл и множество активни среди. Това е най-важно в агентските етапи, където всеки обучителен пример е многоходов rollout, който редактира код, изпълнява команди или сърфира в интернет. RL изпълненията на Granite 4.2 работят върху два отворени компонента: NeMo-RL от страната на обучението и NeMo-Gym от страната на rollout-ите.

Фигура 3. RL системата. NeMo-RL управлява GRPO цикъла (обучителен backend Megatron-Core, генериране с vLLM и Megatron-Bridge за конвертиране на тегла HF⇄Megatron). NeMo-Gym оркестрира rollout-ите и хоства инструментите, пясъчниците и извикванията към награди/проверяващи като включваеми Resources.

Разпределението на задачите:

• NeMo-RL (страна на обучението). Megatron-Core е обучителният backend; vLLM генерира rollout-ите; Megatron-Bridge преобразува теглата между форматите на Megatron и Hugging Face, така че всеки етап да може да експортира чист HF checkpoint за следващия.
• NeMo-Gym (страна на rollout-ите). Той предоставя всяка среда като набор от Resources (проверяващи, инструменти, пясъчници и reward модели) чрез единен интерфейс. Това е точката за включване на агентските етапи: пясъчниците на SWE хранилищата, терминалният harness и инструментите за уеб търсене се свързват тук и за обучителния цикъл изглеждат по същия начин като обикновен проверяващ на математически задачи.

Именно тази унифицираност прави практична описаната по-горе поетапна програма: базираният на правила проверяващ на booster-а и пълният SWE пясъчник предоставят един и същ интерфейс към GRPO.

Това разделение прави физически възможен и асинхронния обучителен цикъл, описан по-горе: генерирането и обновяването на политиката работят върху отделни GPU пулове, така че скъпата инфраструктура за генериране — включително активните агентски среди — остава заета, вместо да бездейства по време на optimizer стъпките.

---

Резултати

Granite 4.2 беше оценен по отношение на агентско програмиране, общо агентско поведение и използване на инструменти, reasoning, чат и следване на инструкции, както и дълъг контекст. Пълната таблица с бенчмаркове е по-долу, последвана от графики, които представят основните резултати според размера на модела.

Задача	3B Dense	8B Dense	30B Dense
Агентско (програмиране)
SWE Bench Multilingual	NA	30.78	41.89
SWE Bench Pro	NA	19.11	33.29
SWE Bench Verified	NA	47.67	57.00
Terminal-Bench 2.1	NA	20.56	29.24
Агентско (общо)
τ³-bench	50.99	66.34	68.05
BFCL (v4)	52.41	50.29	61.39
ProfBench	32.10	41.20	42.90
BirdBench	NA	41.07	41.85
GDPval	NA	1189.00	1225.00
Reasoning
AIME25	78.33	86.67	89.17
HMMT Feb25	66.67	78.33	89.17
GPQA	54.80	64.14	66.41
LiveCodeBench v6	69.71	73.24	75.77
SciCode	24.11	36.09	38.76
Чат и следване на инструкции
MMLU-Pro	67.84	74.04	77.60
MMLU-ProX lite (IBM)	27.78	61.06	66.64
Arena-Hard-V2	34.96	65.19	67.93
IFBench (prompt)	74.33	79.33	74.67
Дълъг контекст
RULER 64K	67.52	80.99	89.96
RULER 128K	55.30	71.41	81.38

Поддържани езици: английски, немски, испански, френски, японски, португалски, арабски, чешки, италиански, корейски, нидерландски и китайски.

Графиките по-долу представят резултатите по области на способностите.

Фигура 4. Reasoning (pass@1). Резултатите се повишават последователно с размера на модела при математика (AIME25, HMMT), наука (GPQA) и reasoning при код (LiveCodeBench, SciCode).

Фигура 5. Проценти на решаване при агентско програмиране. Блокът за агентско RL се обучава само за 8B и 30B; моделът 30B води във всички варианти на SWE-Bench и Terminal-Bench.

Фигура 6. Общи бенчмаркове за агентско поведение и използване на инструменти, представени за трите размера.

---

Квантизация

Също така пуснахме четири квантизирани варианта на моделите Granite 4.2 за inference с vLLM. Моделите се преобразуват във FP8, NVFP4 и MXFP4 чрез LLM Compressor, а във формат GGUF — чрез framework-а llama.cpp за deployment с намалена употреба на памет.

FP8

Версията FP8 е квантизирана с динамични тегла по канали и активации по токени. Не се използва калибриране.

FP4

Версиите NVFP4 и MXFP4 са квантизирани чрез GPTQ, калибриран върху 2K извадки от SFT набора от данни. Максималната дължина на контекста по време на калибрирането е 2K.

GGUF

Преобразуването на моделите Granite 4.2 към GGUF се извършва с canonical инструмента llama.cpp, както е описано на https://github.com/IBM/gguf#gguf-conversion--quantization.

Предлагат се няколко GGUF формата:

• Q8_0
• Q6_K
• Q5_K_S
• Q5_K_M
• Q5_1
• Q5_0
• Q4_K_S
• Q4_K_M
• Q4_1
• Q4_0
• Q3_K_S
• Q3_K_M
• Q3_K_L
• Q2_K

---

Инфраструктура

Хардуер

Обучихме езиковите модели Granite 4.2 върху клъстер NVIDIA GB200 NVL72, хостван от CoreWeave, който включва:

• 72-GPU NVLink домейн за високоскоростна комуникация в рамките на rack-а
• Неблокираща Fat-Tree NDR 400 Gb/s InfiniBand мрежа за пълнолентова свързаност между rack-овете
• Хиляди GPU-та, работещи в мащаба на клъстера

Тази инфраструктура осигурява високоскоростната комуникация с ниска латентност, необходима за ефективно широкомащабно разпределено обучение.

Софтуерен стек

Софтуерният стек за обучение е пакетиран в container images .sqsh, като всяко изображение предоставя на изпълнението възпроизводима, преносима среда със съвместими със SBSA CUDA цели, Linux aarch64 Python wheels и фиксирани специфични за GPU бинарни файлове. Широкомащабните SFT изпълнения използват базово NGC PyTorch image (Ubuntu 22.04, CUDA 12.8, Python 3.12); RL стекът работи в собствен NeMo-RL контейнер.

---

Първи стъпки (Transformers)

Инсталиране

pip install torch
pip install accelerate transformers

Базов inference (режим с мислене)

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_path = "ibm-granite/granite-4.2-3b"
tokenizer = AutoTokenizer.from_pretrained(model_path)
model = AutoModelForCausalLM.from_pretrained(model_path, device_map="cuda", torch_dtype=torch.bfloat16)
model.eval()

messages = [
    {"role": "user", "content": "How many r's are in the word 'strawberry'?"},
]

text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True, enable_thinking=True)
inputs = tokenizer(text, return_tensors="pt").to(model.device)

with torch.no_grad():
    output = model.generate(**inputs, max_new_tokens=8192, temperature=1.0, top_p=0.95, do_sample=True)

print(tokenizer.decode(output[0][inputs.input_ids.shape[-1]:], skip_special_tokens=False))

Примерен изход

<think>
Okay, let's see. The problem is to find how many 'r's are in the word 'strawberry'.

First, I need to write out the word: s t r a w b e r r y.

Now, I need to count the number of 'r' letters. Let's list each letter and check for 'r'.

1. s – not r
2. t – not r
3. r – yes, that's one
4. a – no
5. w – no
6. b – no
7. e – no
8. r – yes, that's two
9. r – yes, that's three
10. y – no

Total r's = 3.
</think>
There are **3** r's in the word "strawberry".<|im_end|>

Режим без мислене

messages = [
    {"role": "user", "content": "What is the capital of France?"},
]
text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True, enable_thinking=False)
inputs = tokenizer(text, return_tensors="pt").to(model.device)

output = model.generate(**inputs, max_new_tokens=2048, temperature=1.0, top_p=0.95, do_sample=True)
print(tokenizer.decode(output[0][inputs.input_ids.shape[-1]:], skip_special_tokens=False))

Примерен изход

<think></think>The capital of France is Paris.<|im_end|>

Мислене с ниско усилие

messages = [
    {"role": "user", "content": "What is 2 + 2?"},
]
text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True,