Я решил проверить, способна ли Gemma 4 стать полноценной альтернативой облачным решениям в моей ежедневной практике с Codex CLI. Сейчас моим основным инструментом является GPT-5.4. Она безупречна в работе, однако есть два серьезных минуса: стоимость каждого запроса и необходимость отправлять исходный код на сторонние серверы. Мои коллеги активно интересуются локальным хостингом моделей, и мне хотелось выяснить, насколько это оправдано в рабочих сценариях.
Признаться, я сомневался, что локальные решения справятся.
Gemma 4 заявила о качественной поддержке работы с инструментами (tool calling). Я выделил день на эксперимент, чтобы понять, выдержит ли система нагрузку при чтении файлов, написании правок и выполнении тестов через Codex CLI.
Для тестирования я подготовил две конфигурации:
-
MacBook Pro на базе M4 Pro с 24 ГБ объединенной памяти — мой рабочий ноутбук. На нем я запустил версию 26B MoE с квантованием
Q4_K_Mчерезllama.cpp— это предел возможностей по памяти. -
Dell Pro Max GB10 с 128 ГБ памяти на базе NVIDIA Blackwell, где через Ollama v0.20.5 была развернута 31B Dense модель.
Обе модели были интегрированы в Codex CLI в качестве кастомных провайдеров через config.toml с параметром wire_api = "responses". Затем я предложил им одну и ту же задачу, дополнительно прогнав её через облако для сравнения.
В итоге обе локальные системы справились с задачей, но это потребовало изрядных усилий: частых зависаний, сбоев в вызове функций и тонкой настройки системы, которая оказалась неожиданно прыткой.
Почему я вообще за это взялся
Основные стимулы были следующими:
Во-первых, оптимизация расходов. Я интенсивно использую Codex CLI, запуская множество сессий ежедневно, поэтому счета за API стали ощутимыми.
Во-вторых, конфиденциальность. Ряд проектов, над которыми я тружусь, не должны покидать контур моего рабочего места.
В-третьих, стабильность. Облачные API подвержены задержкам, внезапным изменениям тарифов и лимитам. Локальное решение дарит независимость.
Почему я не перешел на это раньше? Предыдущие модели плохо справлялись с инструментами. Для работы Codex CLI критически важно, чтобы модель могла корректно считывать файлы, внедрять изменения и запускать тесты. Без стабильного формирования команд типа:
{"tool": "Read", "args": {"file": "package.json"}}агент просто неэффективен. Предыдущие версии Gemma демонстрировали лишь 6,6% успеха на бенчмарке tau2-bench. Теперь же Gemma 4 31B показывает впечатляющие 86,4% — это стало весомым аргументом для теста.
Кстати, если вам нужен удобный доступ к ведущим моделям (Claude, GPT, Gemini), обратите внимание на BotHub.
Сервис работает без VPN и поддерживает оплату российскими картами.
Перейдя по ссылке, вы получите 300 000 бонусных токенов для ознакомления и сможете начать работу с нейросетями немедленно!
Трудности интеграции
С первой попытки запустить рабочую среду не удалось ни на одной из машин.
Mac
Изначально я пытался использовать Ollama, но столкнулся с двумя критическими ошибками. Во-первых, баг стриминга в v0.20.3 приводил к тому, что вызовы функций попадали в вывод рассуждений (reasoning), а не в целевой массив. Во-вторых, конфликты Flash Attention вызывали зависания на любых промптах длиннее 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Здесь важен каждый параметр: -np 1 экономит KV-кэш, а квантование кэша -ctk q8_0 -ctv q8_0 снижает потребление памяти почти вдвое. Также пришлось отключить web_search в Codex CLI, так как llama.cpp не понимает специфические типы инструментов для поиска.
GB10
Я рассчитывал на vLLM, но возник конфликт библиотек: скомпилированные расширения vLLM 0.19.0 не совпадали с актуальными версиями PyTorch для архитектуры Blackwell. В итоге я использовал Ollama v0.20.5. На этой системе отсутствовал баг со стримингом, поэтому запуск прошел гладко: я пробросил порт 11434 через SSH-туннель и запустил клиента командой codex --oss -m gemma4:31b. Если на Mac я возился почти весь день, то с GB10 уложился в час.
Тестирование
Задачей была реализация функции parse_csv_summary с обработкой исключений и написание тестов.
-
GPT-5.4: справился за 65 секунд. Идеальный код, тесты пройдены с первого захода.
-
GB10 (31B Dense): выдал рабочий код без лишних изысков. Потребовалось 3 вызова функций, общая длительность — 7 минут.
-
Mac (26B MoE): оставил «черновики» в коде и сделал 10 попыток вызова функций из-за мелких синтаксических ошибок. Время выполнения — 4 минуты 42 секунды.
Скорость vs Надежность
Интересный момент: несмотря на архитектурные различия, Mac генерировал токены в 5 раз быстрее GB10. Это связано с Mixture of Experts: при каждом токене Mac активирует гораздо меньше параметров, чем плотная модель на GB10. Тем не менее, Mac потратил на задачу всего на 30% меньше времени, чем GB10, так как совершил больше ошибок и потребовал больше итераций.
Главный вывод: локальные LLM стали реально пригодны для работы. Если для быстрой итерации и приватности достаточно локального профиля, то для сложных архитектурных задач можно использовать облако. Переключение между ними в Codex CLI теперь занимает секунды.
