Reasoning mode в Gemma 4: як вмикати, коли потрібно і скільки коштує — 2026

🧠 Що таке reasoning mode і як він з'явився в Gemma 4

Gemma 4 — перша модель в лінійці Google яка вміє думати перед тим як відповідати. Це не маркетинг — це окремий технічний механізм який реально змінює якість відповідей.

Reasoning mode (або thinking mode) — це здатність моделі генерувати внутрішній монолог міркувань перед фінальною відповіддю. Модель будує план, перевіряє логіку, виправляє себе — і тільки після цього видає результат користувачу. Те що ви бачите у фінальній відповіді — це вже результат після внутрішньої "роботи над помилками".

Звідки це з'явилось

Ідея "думати перед відповіддю" не нова — але у відкритих моделях вона масово з'явилась лише у 2025-2026 роках. Перші хто поширив цей підхід — DeepSeek-R1 (китайська відкрита модель) і OpenAI o1. Обидві показали що модель яка витрачає час на внутрішнє міркування вирішує складні задачі значно краще ніж модель яка відповідає одразу.

Google пішов тим самим шляхом. У Gemma 3 reasoning не було — модель відповідала одразу, що думала те й казала. Gemma 4 отримала вбудований thinking mode як одну з ключових нових можливостей. Саме це пояснює найдраматичніший стрибок у бенчмарках: AIME (змагальна математика) з 20.8% до 89.2%, Codeforces ELO з 110 до 2150. Без thinking такі результати неможливі — математичні задачі вимагають покрокового міркування, а не миттєвої відповіді.

З того часу reasoning mode з'явився і в інших популярних відкритих моделях — зокрема Qwen3.5:4b який вміє думати при значно меншому споживанні ресурсів. Це зробило вибір між моделями цікавішим: детальне порівняння — у розділі Gemma 4 vs Qwen3.5:4b нижче.

Як це працює технічно

Технічно reasoning у Gemma 4 реалізований через спеціальний токен <|think|> у системному промпті. Коли модель бачить цей токен — вона активує режим міркування і перед фінальною відповіддю генерує внутрішній монолог довжиною до 4000+ токенів.

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

Важлива деталь: через Ollama токен <|think|> вставляється автоматично — вам нічого не треба налаштовувати. Це відрізняється від деяких інших моделей де thinking треба явно активувати через системний промпт або параметри API.

Чим це відрізняється від звичайної генерації

Звичайна генерація тексту у LLM — це послідовне передбачення наступного токену. Модель не "планує" відповідь — вона просто продовжує текст токен за токеном на основі контексту. Це добре працює для простих запитів, але погано для задач де потрібна логіка, математика або багатокроковий план.

Reasoning mode змінює це: перед генерацією фінальної відповіді модель отримує "простір для думок" де може вільно міркувати, помилятись і виправлятись. Це принципово інший підхід — і саме тому моделі з reasoning показують настільки кращі результати на складних задачах.

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

Що це означає для вас на практиці

Якщо ви вперше запустили Gemma 4 і здивувались що вона довго "думає" перед відповіддю — тепер ви знаєте чому. Це не баг і не гальмування заліза. Це цілеспрямована поведінка яка покращує якість відповіді.

На MacBook Pro M1 16 GB thinking займає від 15 до 73 секунд залежно від складності задачі. Детальні цифри — у секції про вартість thinking нижче. А поки — подивимось що саме відбувається всередині блоку Thinking.

🔍 Як виглядає блок Thinking — що там насправді відбувається

Блок Thinking — це не прихований технічний лог. Це реальний процес міркування моделі який можна читати і з якого можна навчитись.

Коли ви запускаєте запит до Gemma 4 через Ollama термінал або UI, перед відповіддю з'являється блок:

Thinking...
Thinking Process:

1. Analyze the user's input...
2. Identify the core question...
3. Recall personal identity/nature...
...done thinking.

Що відбувається всередині цього блоку — залежить від задачі. Я спостерігав три патерни:

Для простих запитань (наприклад "скільки у тебе параметрів?") — модель будує короткий план з 4-7 кроків: визначити мову запиту, зрозуміти питання, пригадати релевантні факти, сформулювати відповідь. Займає 20-37 секунд.

Для складного коду (Spring Boot endpoint) — модель аналізує що саме потрібно, перераховує компоненти які треба включити (Entity, Repository, Service, Controller), планує структуру, робить self-correction якщо щось забула. Займає 60-73 секунди.

Для тексту (пояснення RAG для бізнесу) — модель визначає аудиторію, формулює аналогії, планує структуру абзаців, перевіряє чи дотримані обмеження промпту. Займає 37 секунд — і саме завдяки цьому вона сама додала таблицю порівняння яку я не просив, але яка реально покращила відповідь.

Ключовий момент: блок Thinking видно тільки вам — у фінальній відповіді його немає. Це внутрішній процес моделі.

⚙️ Як керувати reasoning через Ollama термінал і API

Повністю вимкнути thinking через Ollama неможливо — але можна суттєво скоротити. І це важливо знати перш ніж розчаруватись у швидкості моделі.

Згідно з офіційною документацією Ollama, керування thinking відбувається через токен у системному промпті:

# Thinking увімкнено (за замовчуванням)
# Токен <|think|> вставляється автоматично

# Щоб вимкнути — прибрати токен з системного промпту
# Але через стандартний Ollama CLI це не так просто

Спосіб 1 — /no_think на початку промпту:

Найпростіший спосіб скоротити thinking прямо в запиті:

ollama run gemma4
>>> /no_think Поясни що таке Docker простими словами

За моїми тестами це скорочує thinking з ~37 секунд до ~20 секунд. Повністю не вимикає — модель все одно думає, але коротше.

Спосіб 2 — створити окрему модель без thinking через Modelfile:

# Створюємо Modelfile
echo 'FROM gemma4
SYSTEM ""' > Modelfile

# Будуємо нову модель
ollama create gemma4-fast -f Modelfile

# Запускаємо
ollama run gemma4-fast

Теоретично це має прибрати системний промпт з токеном <|think|>. На практиці — thinking все одно з'являється, але у скороченому вигляді. Це відома поведінка Gemma 4 через Ollama яку обговорюють у GitHub issues.

Спосіб 3 — через Ollama API з параметром think: false:

curl http://localhost:11434/api/chat -d '{
  "model": "gemma4",
  "think": false,
  "messages": [
    {
      "role": "user",
      "content": "Поясни що таке Docker"
    }
  ]
}'

Надійний спосіб для програмного керування thinking. Параметр think: false підтримується в Ollama 0.24+. Для повного вимкнення — найкращий варіант серед CLI-методів.

Спосіб 4 — num_predict як непрямий контроль бюджету thinking:

В Ollama 0.24+ через параметр num_predict можна обмежити загальну кількість токенів які модель генерує — включно з thinking-блоком. Це не прямий контроль глибини міркування, але дає передбачуваніший час відповіді:

curl http://localhost:11434/api/chat -d '{
  "model": "gemma4",
  "messages": [
    {
      "role": "user",
      "content": "Поясни що таке Docker"
    }
  ],
  "options": {
    "num_predict": 1024
  }
}'

Для простих задач — значення 512–1024 достатньо і суттєво пришвидшує відповідь. Для складного коду або архітектурних рішень — встановлюйте 2048–4096, інакше thinking може обірватись посередині.

Детальніше про те як підбирати глибину thinking під конкретну задачу — у наступному розділі Thinking budget.

🖥️ Як керувати reasoning в Open WebUI

У графічному інтерфейсі керувати thinking простіше — але можливості залежать від версії вашого UI.

Якщо ви використовуєте Open WebUI або інший Ollama-сумісний інтерфейс — thinking блок відображається як розкривна секція перед відповіддю. Зазвичай він згорнутий і позначений як "Thought for X seconds".

Щоб скоротити thinking в UI — є три підходи:

1. Через поле System Prompt (якщо є в налаштуваннях моделі): залиште порожнім або додайте власний системний промпт без токену <|think|>. Але як показав мій тест — це не гарантує повного вимкнення.

2. Через /no_think на початку повідомлення: працює і в UI так само як у терміналі — просто додайте на початку запиту. Thinking скоротиться але не зникне повністю.

3. Через параметри моделі в Advanced Settings (Open WebUI 0.6+): у розширених налаштуваннях з'явився параметр num_predict який можна виставити прямо в інтерфейсі без звернення до API. Це найзручніший спосіб для тих хто не хоче писати curl-запити.

Для більшості користувачів UI — найпрактичніше рішення: просто прийняти що thinking є і оцінювати модель за якістю фінальної відповіді, а не за швидкістю.

🧪 Мій тест: з thinking і без — порівняння якості

Я тестував на MacBook Pro M1 16 GB. Один і той самий промпт — два режими. Ось що вийшло.

Промпт для обох тестів:

Поясни що таке RAG (Retrieval-Augmented Generation) простою мовою для бізнесу. Без технічних термінів. 3-4 абзаци.

Тест 1 — звичайний запуск (thinking увімкнено):

Thinking зайняв ~37 секунд. Модель спланувала структуру, визначила аудиторію, вибрала аналогії. Результат: структурована відповідь з підзаголовками, сильна аналогія ("учень з усіма книгами світу vs асистент з довідником вашої компанії") і таблиця порівняння "LLM без RAG vs з RAG" — яку я не просив, але яка реально покращила відповідь. Загальний час: ~1.5 хвилини.

Тест 2 — з /no_think (thinking скорочено):

Thinking зайняв 20.3 секунди. Модель відповіла швидше. Результат: 4 абзаци, є аналогія ("стажер з внутрішньою базою знань"), зрозуміло і чисто. Але — без таблиці, без підзаголовків, менш структуровано. Загальний час: ~50 секунд.

Цікавий нюанс: з повним thinking модель порушила обмеження "3-4 абзаци" — додала таблицю і підзаголовки яких я не просив. Але зробила це правильно — відповідь стала кращою. З /no_think — суворо дотрималась інструкцій, але відповідь простіша.

⏱️ Скільки часу з'їдає thinking mode на M1 16 GB

Thinking — це не безкоштовно. Ось цифри з моїх тестів на MacBook Pro M1 16 GB.

Що впливає на тривалість thinking:

• Складність задачі — чим більше кроків потрібно спланувати, тим довше думає
• Кількість компонентів у відповіді — код з чотирма класами думається довше ніж один абзац тексту
• Наявність /no_think — скорочує приблизно вдвічі
• Поточне навантаження на M1 — якщо відкрито багато вкладок браузера, thinking повільніший
• Розмір моделі — Gemma 4 E4B думає довше ніж Qwen3.5:4b на аналогічних задачах через різницю в архітектурі

🎛️ Thinking budget: тонке керування глибиною міркування

Не завжди потрібно вмикати thinking на повну або вимикати повністю. Є середній варіант — контролювати бюджет токенів для міркування.

Офіційна документація Google по Gemma 4 описує підхід до "LOW thinking" — замість повного вимкнення ви інструктуєте модель думати коротше через системний промпт:

# Повний thinking (за замовчуванням)
system: "<|think|>"

# Скорочений thinking через інструкцію
system: "<|think|> Think briefly and efficiently. Focus only on key steps."

# Мінімальний thinking
system: "<|think|> Use minimal reasoning. Answer directly after a short check."

Це працює тому що Gemma 4 має дуже сильне дотримання інструкцій — модель реально скорочує глибину міркування відповідно до вказівки. На практиці різниця між "повним" і "коротким" thinking — приблизно як між 73 і 25 секундами для задачі з кодом.

Практичне правило по бюджету для різних задач:

Важливо: якщо встановити занадто малий num_predict для складної задачі — thinking може обірватись посередині і якість відповіді впаде. Краще дати більше токенів ніж отримати незавершене міркування.

⚖️ Gemma 4 vs Qwen3.5:4b — порівняння thinking

Обидві моделі вміють думати — але по-різному. Ось де кожна виграє, а де програє.

Після виходу Qwen3.5:4b питання "яку модель взяти для локальної роботи" стало цікавішим. Обидві підтримують thinking mode, обидві вміщаються на 8–16 GB RAM — але поводяться по-різному.

Мій висновок після кількох місяців паралельного використання: це не конкуренти — це різні інструменти. Qwen3.5:4b — для швидкого щоденного потоку задач де важлива реактивність. Gemma 4 — коли задача складна і час не критичний. На M1 16 GB обидві живуть одночасно (~6 GB разом) і не конфліктують.

✅ Коли thinking потрібен, а коли він тільки гальмує

Thinking — інструмент а не обов'язок. Вмикайте коли потрібна якість, вимикайте (наскільки можливо) коли потрібна швидкість.

Thinking однозначно варте часу:

• Складна математика або логічні задачі — без thinking якість падає драматично
• Генерація структурованого тексту — статті, документація, пояснення для бізнесу
• Агентні сценарії з кількома кроками — planning перед виконанням критичний
• Код з нетривіальною архітектурою — модель сама виловлює помилки в плані до того як їх написати
• Будь-яка задача де якість важливіша за час

Thinking можна скорочувати через /no_think:

• Прості питання з однозначною відповіддю
• Переклад тексту
• Короткі відповіді де структура не потрібна
• Чат де важлива реактивність
• Шаблонний код який ви і так знаєте

Моя порада з досвіду: я залишаю thinking увімкненим за замовчуванням і додаю /no_think тільки коли явно хочу швидку відповідь на просте питання. Для складних задач — thinking себе виправдовує навіть на M1 де він повільніший.

Якщо вам потрібна модель де thinking швидший або де його можна надійно вимкнути — розгляньте Qwen3.5:4b. Детальне порівняння швидкості і якості — у розділі вище.

📚 Читайте також

• Gemma 4 на M1 16 GB — реальні тести: код, текст, швидкість
• Gemma 4: повний огляд — розміри, ліцензія, порівняння з Gemma 3
• Ollama на 8 GB RAM — які моделі працюють у 2026
• Ollama у 2026: що це таке і чому розробники масово переходять на локальний AI