Коротко: Встановив Gemma 4 на MacBook Pro M1 16 GB і протестував на двох реальних задачах — генерація Spring Boot коду і текст про RAG. Порівняв з Qwen3:8b і Mistral Nemo. Результат: Gemma 4 видає найкращу якість, але найповільніша. Qwen3:8b — майже та сама якість коду за 1/4 часу. Читай якщо хочеш знати чи варто перемикатись.
⚠️ Як я встановлював Gemma 4 на M1: реальна помилка з версією Ollama
Перше що я побачив — не модель, а помилку. І це перший корисний факт для тих хто захоче повторити.
Я вже давно використовую Ollama для локального AI — тож перше що зробив після виходу Gemma 4, це просто написав у терміналі:
ollama run gemma4
І одразу отримав:
Error: pull model manifest: 412:
The model you are attempting to pull requires a newer version of Ollama.
Please download the latest version at: https://ollama.com/download
Причина проста: у мене стояла версія 0.17.0, а Gemma 4 вимагає мінімум 0.20+. Перевірити свою версію: ollama --version. Оновити можна або через офіційну сторінку завантаження, або через Homebrew — що я і зробив (офіційна документація Ollama):
brew upgrade ollama
brew services restart ollama
Після цього встановилась версія 0.20.5 і модель завантажилась без проблем. Якщо ти встановлював Ollama давно — перевір версію перед тим як пробувати Gemma 4. Зекономиш 10 хвилин пошуку причини помилки.
Завантаження моделі:
ollama run gemma4
Розмір: 9.6 GB. На моєму інтернеті зайняло близько 2 годин. Після завантаження модель одразу запустилась у терміналі — символ ⠇ означає що вона завантажується в пам'ять, через кілька секунд з'являється >>>.
💾 Який варіант Gemma 4 підходить для M1 16 GB і чому не 26B
Gemma 4 — це не одна модель, а чотири. І на M1 16 GB підходить лише одна з них.
Про gemma4:26b окремо — в інтернеті її активно рекламують як "MoE-магія: якість 26B за ціною 8B". Це не зовсім правда. Реальний розмір файлу 18 GB, і на M1 з 16 GB unified memory це просто не влізе без агресивного свопінгу. Навіть на Mac mini з 24 GB люди повідомляють про зависання під навантаженням і повернення на e4b. Детально про це — в окремій статті про підводні камені Gemma 4 26B MoE.
Мій вибір: gemma4 (e4b) — дефолтний варіант, нічого додатково вказувати не треба.
💻 Тест 1 — генерація коду: Spring Boot endpoint з пагінацією
Один і той самий промпт — три моделі. Дивимось що вийшло.
Промпт який я використав:
Напиши Spring Boot REST endpoint для отримання списку користувачів з пагінацією. Використай JPA Repository.
Я свідомо обрав цю задачу — знаю Spring Boot добре, тому можу оцінити якість без гуглу.
Gemma 4 — результат:
Повна структура: Entity → Repository → Service → Controller + залежності в pom.xml + приклади URL-запитів. Правильний DI через конструктор, ResponseEntity<Page<User>>, коментарі до кожного кроку. Це production-ready код який можна брати і використовувати. Єдиний мінус — час. Спочатку 73 секунди "думала" (блок Thinking), потім ще ~3 хвилини генерувала текст. Загалом майже 4 хвилини.
Qwen3:8b — результат:
Та сама повна структура: Entity + Repository + Service + Controller. Додатково — залежності і для Maven, і для Gradle (чого Gemma не зробила). Якість коду практично ідентична. Час: ~32 секунди thinking + ~35 секунд генерація = 67 секунд загалом. У 3.5 рази швидше.
Mistral Nemo — результат:
Мінімальний код — тільки Controller, без окремого Service layer. Той самий блок коду продублювався двічі (схоже на баг генерації). Час ~30 секунд — найшвидша, але найслабша відповідь.
📝 Тест 2 — генерація тексту: пояснення RAG для бізнесу
Тут картина змінилась — Gemma 4 показала себе значно краще конкурентів.
Промпт:
Поясни що таке RAG (Retrieval-Augmented Generation) простою мовою для бізнесу. Без технічних термінів. 3-4 абзаци.
Обмеження "3-4 абзаци" і "без технічних термінів" — спеціально щоб перевірити чи модель слухається інструкцій.
Gemma 4 — результат:
Порушила обмеження по кількості абзаців — але правильно. Замість 3-4 абзаців зробила структуровану статтю з підзаголовками, аналогією ("учень з усіма книгами світу vs асистент з довідником вашої компанії") і таблицею порівняння "LLM без RAG vs з RAG". Це саме те що потрібно бізнесу — я знаю це по власному досвіду з AskYourDocs. Час: ~37 секунд thinking + ~1 хвилина тексту.
Qwen3:8b — результат:
Дотримався обмеження — рівно 3 абзаци. Чисто, лаконічно, зрозуміло. Є аналогія ("додаткове джерело знань"). Але порівняно з Gemma 4 — значно простіше, без структури і без таблиці. Час: ~18 секунд thinking + ~20 секунд тексту = 38 секунд загалом.
Mistral Nemo — результат:
6 абзаців замість 3-4 — не дотримався обмеження. Зміст водянистий, є повтори одних і тих самих думок різними словами. Час ~30 секунд, але якість найнижча з трьох.
📊 Порівняння з Qwen3:8b і Mistral Nemo: таблиця результатів
Цифри зібрані на MacBook Pro M1 16 GB. Не лабораторні бенчмарки — мої власні тести.
Модель
Розмір
Код: час
Код: якість
Текст: час
Текст: якість
gemma4
9.6 GB
~4 хв
⭐⭐⭐⭐⭐
~1.5 хв
⭐⭐⭐⭐⭐
qwen3:8b
5.2 GB
~67 сек
⭐⭐⭐⭐⭐
~38 сек
⭐⭐⭐⭐
mistral-nemo
7.1 GB
~30 сек
⭐⭐
~30 сек
⭐⭐⭐
Висновок з таблиці: для коду Qwen3:8b і Gemma 4 рівні за якістю, але Qwen3 у 3.5 рази швидша. Для тексту Gemma 4 помітно краща — структура, аналогії, таблиці. Mistral Nemo програє в обох тестах крім швидкості.
🧠 Reasoning mode на практиці: скільки часу з'їдає і чи варте того
Gemma 4 "думає" перед кожною відповіддю за замовчуванням. Це і є її головна перевага — і головна причина повільності.
Одразу після першого запиту я побачив незвичне:
Thinking...
Thinking Process:
1. Analyze the user's input...
2. Identify the core question...
...done thinking.
Це reasoning mode — модель будує план відповіді перед тим як генерувати текст. У Gemma 4 він увімкнений за замовчуванням через токен <|think|> у системному промпті. Детальніше про те як його вмикати і вимикати вручну — в окремій статті про reasoning mode в Gemma 4.
Що це дає на практиці — видно з тестів:
Код: 73 секунди thinking → відповідь з повною структурою і поясненнями
Текст: 37 секунд thinking → відповідь зі структурою яку не просили, але яка реально покращила результат
Чи варте того? Залежить від задачі. Для одноразових складних запитів — так, якість помітно вища. Для рутинних задач де потрібна швидкість (автодоповнення, короткі відповіді, чат) — reasoning тільки гальмує. У таких випадках краще Qwen3:8b.
✅ Висновок: коли на M1 брати Gemma 4, а коли залишитись на Qwen3
Gemma 4 не замінює всі моделі. Вона займає свою нішу — і в цій ніші вона дійсно найкраща.
Бери Gemma 4 якщо:
Пишеш складний текст — статті, документацію, пояснення для бізнесу
Потрібна максимальна якість коду і час не критичний
Хочеш модель яка сама структурує відповідь без детальних інструкцій
Плануєш використовувати в RAG-продукті — 128K контекст і нативний function calling
Залишайся на Qwen3:8b якщо:
Щодня генеруєш код і потрібна швидкість
Використовуєш як автодоповнення в IDE
Важлива реактивність у чаті
На моєму M1 16 GB обидві моделі зараз стоять одночасно — вони займають разом ~15 GB і не конфліктують. Я перемикаюсь залежно від задачі.
Якщо хочеш розібратись глибше — читай далі по темі:
Коротко: Gemma 4 26B MoE рекламують як "якість 26B за ціною 4B". Це правда щодо швидкості інференсу — але не щодо пам'яті. Завантажити потрібно всі 18 GB. На Mac з 24 GB — свопінг і 2 токени/сек. Комфортно працює на 32+ GB. Читай перш ніж завантажувати.
Що таке MoE і чому 26B...
Коротко: Reasoning mode — це вбудована здатність Gemma 4 "думати" перед відповіддю. Увімкнений за замовчуванням. На M1 16 GB з'їдає від 20 до 73 секунд залежно від задачі. Повністю вимкнути через Ollama не можна — але можна скоротити через /no_think. Читай коли це варто робити, а коли...
Коротко: Gemma 4 — нове покоління відкритих моделей від Google DeepMind, випущене 2 квітня 2026 року. Чотири розміри: E2B, E4B, 26B MoE і 31B Dense. Ліцензія Apache 2.0 — можна використовувати комерційно без обмежень. Підтримує зображення, аудіо, reasoning mode і 256K контекст. Запускається...
Коротко: Встановив Gemma 4 на MacBook Pro M1 16 GB і протестував на двох реальних задачах — генерація Spring Boot коду і текст про RAG. Порівняв з Qwen3:8b і Mistral Nemo. Результат: Gemma 4 видає найкращу якість, але найповільніша. Qwen3:8b — майже та сама якість коду за 1/4 часу. Читай якщо...
Розробник налаштував tool use, перевірив на тестових запитах — все працює.
У production модель раптом відповідає без виклику інструменту, впевнено і зв'язно,
але з даними річної давнини. Жодної помилки в логах. Просто неправильна відповідь.
Спойлер: модель не «зламалась»...
Коли розробник вперше бачить як LLM «викликає функцію» — виникає інтуїтивна помилка:
здається що модель сама виконала запит до бази або API.
Це не так, і саме ця помилка породжує цілий клас архітектурних багів.
Спойлер: LLM лише повертає структурований JSON з назвою...