Gemma 4 как локальная замена облачной модели в Codex CLI: тест на MacBook Pro и Dell GB10

Gemma 4 в двух конфигурациях — 26B MoE на MacBook Pro M4 Pro с 24 ГБ памяти и 31B Dense на Dell GB10 с 128 ГБ unified memory — прошла практический тест в Codex CLI: написать Python-функцию parse_csv_summary с обработкой ошибок, покрыть её тестами и прогнать их. Обе конфигурации задачу выполнили, но путь к рабочему состоянию занял разное время и потребовал разных решений.

Главным поводом для теста стали три практических ограничения облачных моделей: стоимость токенов при интенсивном использовании, передача кодовой базы на сторонние серверы и зависимость от доступности API. Предыдущие поколения Gemma для агентной работы не годились — результат на бенчмарке tau2-bench function-calling составлял 6,6%, то есть 93 провала из 100. У Gemma 4 31B тот же показатель вырос до 86,4%, что и стало поводом проверить модель в реальных условиях.

На Mac первая попытка через Ollama провалилась из-за двух багов версии v0.20.3: tool calls из ответов Gemma 4 попадали в reasoning output вместо массива tool_calls, а Flash Attention зависал на промптах длиннее примерно 500 токенов — тогда как системный промпт Codex CLI сам по себе занимает около 27 000 токенов. Рабочим решением стал llama.cpp через Homebrew с тщательно подобранными флагами: -np 1 ограничивает число слотов и сдерживает рост KV cache, -ctk q8_0 -ctv q8_0 сокращают его с 940 МБ до 499 МБ, --jinja обязателен для шаблона tool calling, а прямой путь до модели через -m предпочтительнее -hf, который незаметно подтягивает ещё 1,1 ГБ vision projector и роняет всё по памяти. На GB10 планировался vLLM, но скомпилированные расширения версии 0.19.0 оказались несовместимы с единственным доступным для aarch64 Blackwell вариантом PyTorch — 2.11.0+cu128 против ожидаемого 2.10.0. Ollama v0.20.5 на NVIDIA не воспроизвёл баг со стримингом, характерный для Apple Silicon, и заработал сразу.

Результаты теста разошлись заметно. GPT-5.4 написал код с type hints, цепочкой исключений и распознаванием булевых значений, все пять тестов прошли с первой попытки за 65 секунд. 31B Dense на GB10 выдал рабочий код без type hints и без распознавания булевых значений, но с нормальной обработкой ошибок — пять тестов прошли после трёх tool calls за 7 минут. 26B MoE на Mac оставил в коде артефакты: незавершённый цикл с комментарием «Actually, let's simplify», пять попыток записи тестового файла с разными опечатками — filerypt, encoding=' 'utf-8' с лишним пробелом, fileint(file_path) — и итоговые 10 tool calls против трёх у GB10.

При этом по скорости генерации токенов Mac неожиданно оказался в 5,1 раза быстрее GB10, несмотря на одинаковую пропускную способность памяти у обеих машин — 273 ГБ/с LPDDR5X. Причина в архитектуре: Dense-модель на каждый токен читает все 31,2 млрд параметров, тогда как MoE активирует лишь 3,8 млрд — около 1,9 ГБ при квантовании Q4. Скорость генерации токенов оказалась выше у Mac, но качество результата — хуже: для агентной работы с кодом точность tool calls и стабильность вывода важнее сырой скорости.

Практический вывод из теста: GB10 с 31B Dense через Ollama v0.20.5 поднялся примерно за час, большую часть которого заняло скачивание модели. Mac с 26B MoE через llama.cpp потребовал почти полного рабочего дня на отладку. Разница в качестве итогового кода соответствует разнице в затраченных усилиях.