Я запустил Gemma 4 как локальную модель в Codex CLI

Я хотел понять, может ли 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.