Я хотел понять, может ли Gemma 4 заменить облачную модель в моей обычной повседневной работе с кодом через агента. Не в теории, а по-настоящему. Я каждый день пользуюсь Codex CLI, и модель по умолчанию у меня — GPT-5.4. Работает она хорошо, но есть два нюанса: каждый токен стоит денег, и каждый промпт уводит мой код на чужие серверы. Плюс у меня есть друзья, которые всерьёз думают вложиться в локальные сетапы, а я до сих пор не был уверен, что для такой работы это вообще имеет смысл.

Я допускал, что могу ошибаться.

Gemma 4 обещала рабочий локальный tool calling. И я решил потратить день, чтобы проверить, не развалится ли всё это, как только Codex CLI начнёт читать файлы, писать патчи и гонять тесты.

Я собрал два стенда:

• MacBook Pro на M4 Pro с 24 ГБ памяти — мой основной ноутбук, который всегда со мной. На нём я запускал вариант 26B MoE через llama.cpp в Q4_K_M, потому что это был максимум, который ещё реально помещался в память.

• Dell Pro Max GB10 с 128 ГБ unified memory на NVIDIA Blackwell, где я запускал 31B Dense через Ollama v0.20.5.

Обе модели я подключил в Codex CLI как кастомных провайдеров через config.toml с wire_api = "responses". Потом дал всем одну и ту же задачу по генерации кода и для сравнения прогнал её ещё и на облачной модели.

К концу дня обе локальные конфигурации задачу всё-таки выполнили. Но только после долгих зависаний, сломанных tool calls и одной маковской настройки, которая оказалась куда быстрее, чем заслуживал её конечный результат.

---

Зачем мне вообще всё это понадобилось

Причин было три.

Во-первых — деньги.
Я много гоняю Codex CLI: по несколько сессий в день, иногда сразу параллельно. Счета за API довольно быстро начинают кусаться.

Во-вторых — приватность.
Некоторые кодовые базы, с которыми я работаю, вообще-то не должны покидать мой компьютер.

В-третьих — надёжность.
Облачные API умеют тормозить, падать, душить лимитами и внезапно менять цены. Локальная модель просто у тебя есть — и всё.

Почему я не сделал это раньше? Потому что локальные модели толком не умели работать с инструментами. А вся ценность Codex CLI именно в этом: модель должна читать файлы, писать код, запускать тесты и применять патчи. Если она не может стабильно выдать что-то вроде:

{"tool": "Read", "args": {"file": "package.json"}}

то как агент она бесполезна.

У предыдущих поколений Gemma результат на бенчмарке tau2-bench function-calling был 6,6%. То есть 93 провала из 100. На таком ничего серьёзного не построишь.

У Gemma 4 31B на том же бенчмарке — 86,4%. Вот это уже звучит как повод попробовать.

---

Кстати, об инструментах. Если вам нужен доступ ко всем ключевым моделям — Claude, GPT, Gemini — загляните на BotHub.

Для доступа не требуется VPN, можно использовать российскую карту.

По ссылке вы можете получить 300 000 бесплатных токенов  для первых задач и приступить к работе с нейросетями прямо сейчас!

---

Что понадобилось, чтобы всё вообще завелось

С первой попытки не заработала ни одна машина.

Mac

На Mac я сначала пошёл самым простым путём — через Ollama. И почти сразу всё умерло из-за двух багов.

Первый — баг со стримингом в v0.20.3. Ответы Gemma 4 с tool calls улетали не туда: вместо массива tool_calls они оказывались в reasoning output.

Второй — зависание Flash Attention. На Apple Silicon с Gemma 4 Ollama зависал на любом промпте длиннее примерно 500 токенов. А системный промпт Codex CLI сам по себе — это примерно 27 000 токенов. То есть в реальности всё выглядело так: запрос приходит, промпт начинает загружаться — и дальше тишина.

В итоге я пересел на llama.cpp, установленный через Homebrew. Рабочая команда сервера у меня получилась такая:

llama-server \
  -m /path/to/gemma-4-26B-A4B-it-Q4_K_M.gguf \
  --port 1234 -ngl 99 -c 32768 -np 1 --jinja \
  -ctk q8_0 -ctv q8_0

На машине с 24 ГБ памяти тут важен реально каждый флаг. Я не претендую на звание эксперта, но времени на подбор вариантов потратил прилично.

• -np 1 — ограничивает всё одним слотом, потому что несколько слотов резко раздувают KV cache.

• -ctk q8_0 -ctv q8_0 — квантуют KV cache и уменьшают его примерно с 940 МБ до 499 МБ.

• --jinja — обязателен для шаблона tool calling у Gemma 4.

• -m с прямым путём до модели лучше, чем -hf, потому что -hf незаметно тащит ещё 1,1 ГБ vision projector, после чего всё падает по памяти.

В конфиге Codex CLI ещё пришлось поставить web_search = "disabled", потому что Codex CLI отправляет тип инструмента web_search_preview, а llama.cpp его не понимает.

До всего этого я дошёл самым обычным способом: читал ошибки, рыл issues на GitHub и по одному менял параметры, пока запросы не начали вести себя как надо.

GB10

С GB10 я был уверен, что всё взлетит на vLLM, потому что именно его советовал гайд, по которому я ориентировался. Не взлетело.

Проблема была в том, что скомпилированные расширения vLLM 0.19.0 собраны под PyTorch 2.10.0, а единственный CUDA-вариант PyTorch для aarch64 Blackwell (sm_121) — это 2.11.0+cu128. ABI не совпадает. На старте — ImportError.

Я собрал llama.cpp из исходников с CUDA. Он нормально собрался и даже хорошо прошёл бенчмарки. Но у Codex CLI в режиме wire_api = "responses" есть типы инструментов, которые не считаются function tools, и llama.cpp их отбрасывает.

В итоге рабочим вариантом оказался Ollama v0.20.5. На моём GB10 баг со стримингом, который ломал Apple Silicon, на NVIDIA просто не воспроизвёлся.

Дальше всё было уже просто:

• ollama pull gemma4:31b

• SSH-туннель, чтобы пробросить порт 11434 на Mac(потому что режим --oss в Codex CLI смотрит только на localhost)

• запуск:

  codex --oss -m gemma4:31b
  

Генерация текста и tool calling заработали сразу.

Mac я ковырял почти весь день. GB10 поднялся примерно за час, и большая часть этого часа ушла просто на скачивание модели.

---

Сам тест

Я дал всем трём конфигурациям одну и ту же задачу через:

codex exec --full-auto

Задача была простая и практичная: написать Python-функцию parse_csv_summary с обработкой ошибок, написать тесты и прогнать их.

Это не был какой-то суперстрогий научный бенчмарк. Просто один нормальный реальный прогон, которого хватает, чтобы увидеть, где что ломается внутри одного и того же Codex CLI workflow.

GPT-5.4

GPT-5.4 написал код с type hints, нормальной цепочкой исключений, распознаванием булевых значений и аккуратной вспомогательной функцией. Все пять тестов прошли с первой попытки за 65 секунд. После этого мне не пришлось ничего допиливать.

GB10 с 31B Dense

31B Dense на GB10 выдал рабочий код без type hints и без распознавания булевых значений, но с хорошей обработкой ошибок и без мусора в коде. Все пять тестов прошли с первого раза после трёх tool calls. Общее время — 7 минут.

Mac с 26B MoE

26B MoE на Mac оставил в коде мусор. Например, модель сначала написала цикл для вывода типов, потом бросила его как есть, а ниже переписала логику заново, оставив в исходнике комментарий вроде “Actually, let’s simplify”.

Файл с тестами она пыталась записать пять раз. И каждый раз умудрялась сломаться по-новому:

• filerypt вместо file_path

• encoding=' 'utf-8' с лишним пробелом

• fileint(file_path)

В итоге получилось 10 tool calls на то, что GB10 сделал за 3.

Сразу оговорюсь: это не «приговор Gemma 4 на Apple Silicon». Это результат конкретной связки: 24 ГБ памяти + Q4_K_M + Codex CLI.

---

Про скорость — и почему Mac оказался неожиданно быстрым

Я прогнал llama-bench на обеих машинах с одинаковыми длинами контекста.

И тут вышел сюрприз: Mac генерировал токены в 5,1 раза быстрее, чем GB10.

Я этого не ожидал, потому что у обеих машин пропускная способность памяти 273 ГБ/с LPDDR5X.

Объяснение оказалось в архитектуре Mixture of Experts.

Генерация токенов упирается в пропускную способность памяти: чтобы сгенерировать токен, нужно прочитать активные параметры модели из памяти.

• У 31B Dense на каждый токен читаются все 31,2 млрд параметров.

• У 26B MoE активируются только 3,8 млрд параметров на токен — это примерно 1,9 ГБ при Q4.

В итоге:

• Mac проталкивает 1,9 ГБ на токен через свои 273 ГБ/с и получает 52 ток/с

• GB10 тащит 17,4 ГБ на токен через те же 273 ГБ/с и получает 10 ток/с

То есть «труба» одинаковая, но объём груза совершенно разный.

С обработкой промпта у меня тоже было неправильное ожидание. Я думал, что GPU Blackwell в GB10 тут всех размажет. Но нет — Mac держался очень близко:

• 531 ток/с у Mac

• 548 ток/с у GB10

на контексте 8K.

Похоже, sparse-активация MoE помогает не только генерации, но и обработке длинного промпта.

---

Что в итоге изменило моё мнение

Я заходил в этот тест с мыслью, что всё будет решать скорость генерации токенов.

Оказалось — не всё.

Mac генерировал токены в 5,1 раза быстрее, но закончил задачу всего на 30% быстрее:
4 мин 42 сек против 6 мин 59 сек.

Почему? Потому что время ушло не на генерацию, а на косяки:

• 10 tool calls вместо 3

• 5 неудачных попыток записать тесты

• мёртвый код, который модель сама не убрала

GB10 был медленнее по токенам, но просто делал меньше ошибок.

Облачная модель показала это ещё жёстче: она была самой быстрой, потратила меньше всего токенов и не потребовала вообще никакой последующей чистки. Пять из пяти — за 65 секунд.

Для такого сценария надёжность с первой попытки важнее, чем голая скорость токенов.

Но главный вывод всё равно позитивный: локальный запуск уже жизнеспособен. Обе машины смогли выдать рабочий код с проходящими тестами.

И именно здесь разница между Gemma 3 и Gemma 4 действительно важна:

• Gemma 3 — 6,6% по tool calling

• Gemma 4 — 86,4%

Это переход из категории «сломано» в категорию «работает». А именно он и делает локальное агентное кодирование реально пригодным к жизни.

Что касается Mac, тут важная оговорка — квантизация. Я запускал максимально вмещающийся вариант Q4_K_M на машине с 24 ГБ памяти. Это не значит, что Gemma 4 везде на Apple Silicon будет вести себя ровно так же. Я пока не повторял тот же тест на более свободной машине Apple Silicon с более качественной квантизацией, но ожидаю, что разница будет заметной.

Мне вполне видится нормальный гибридный сценарий:

• codex --profile local — для быстрых итераций и приватных задач

• облако по умолчанию — для сложной работы

В Codex CLI профили переключаются одним флагом, так что это вполне удобно.

---

Если захотите повторить у себя

Пара вещей, которые сэкономят вам время.

На Apple Silicon

Для той нагрузки, что я тестировал, Ollama с Gemma 4 был непригоден. Я бы сразу шёл в llama.cpp с --jinja.

Что ещё важно:

• в профиле Codex CLI поставить web_search = "disabled"

• использовать -m с прямым путём к GGUF, а не -hf

• ставить контекст 32 768, потому что один только системный промпт Codex CLI требует минимум 27 000 токенов

• квантуйте KV cache через:

  -ctk q8_0 -ctv q8_0
  

На NVIDIA GB10

У меня первым по-настоящему рабочим вариантом оказался Ollama v0.20.5.

Запускал так:

codex --oss -m gemma4:31b

Если машина у вас удалённая — пробрасывайте порт 11434 через SSH.

Не забудьте про таймаут

Поставьте stream_idle_timeout_ms хотя бы в 1,800,000 в конфиге провайдера.

Один цикл tool call на Mac у меня занимал 1 минуту 39 секунд. С дефолтным таймаутом сессия просто умрёт раньше, чем модель закончит.

И ещё один важный момент

Фиксируйте версию llama.cpp.

Между сборками уже замечали регресс скорости до 3,3 раза, так что ваши бенчмарки могут внезапно уехать буквально за одну ночь.

---

Условия теста

Бенчмарки прогонялись 12 апреля 2026 года.

Использовалось:

• Codex CLI v0.120.0

Mac

• llama.cpp ggml 0.9.11 (build 8680)

• 24 GB M4 Pro MacBook Pro

• модель gemma-4–26B-A4B-it Q4_K_M

GB10

• Ollama v0.20.5

• Dell Pro Max GB10(128 GB, NVIDIA Blackwell)

• модель gemma-4–31B-it Q4_K_M

Облачная база для сравнения

• GPT-5.4 с высоким reasoning effort

Во всех трёх случаях использовался один и тот же промпт через:

codex exec --full-auto

Сырые замеры скорости делались через llama-bench.