Перейти к содержимому
Экосистема AI Vibe

Разборы

Gemma 4 на ноутбуке: три режима, CPU, GPU и честный ABBA

Редакция 24 сентября 2026 г.

Gemma 4 на ноутбуке: три режима, CPU, GPU и честный ABBA

Три режима на ноутбуке с Gemma 4 E2B в q4_0: только шестиядерный CPU, только GTX 1650 Ti с 4 GB VRAM или один замер без чередования порядка (последний может сдвинуть вывод примерно на 2%). Медиана decode по сетке автора, 4.14×, важнее округления 4.1× в заголовке для соло, который держит llama.cpp рядом с IDE, если нет temperature gate и протокола ABBA. Сетка, MCP-слой и железо: в LINK:замере.

Локальный inference: одна модель, два рига llama.cpp

На Lenovo Yoga 9 автор поднимает один и тот же GGUF google/gemma-4-E2B-it-qat-q4_0-gguf (~3.35 GB) через llama-server на 127.0.0.1:8080: на CPU с -ngl 0, на GPU с -ngl 99 после сборки llama.cpp (commit f95b0d9, сервер 0.4.1-dev) с CUDA 13.4. Контекст 8192, шесть потоков на CPU (i7-10750H, 6 ядер / 12 потоков), flash-attention и метрики включены: типичный стек «модель рядом с агентом», а не абстрактный dev-блог без ИИ.

Сетка замеров: длины входа 94, 516, 998 и 1959 токенов × выход 32 или 128 токенов, три повтора на ячейку, один запрос за раз. Скрипт sweep.py гоняет OpenAI-совместимый endpoint; в отчёте decode tok/s, TTFT и lead CPU/GPU по ячейкам. Медианы по восьми ячейкам: decode 4.14×, prefill 3.42×, end-to-end 3.62×. Заголовок с 4.1× округляет decode, а не спорит с данными.

ABBA и ~2%: порядок замеров против цифры из заголовка

Порядок проходов зафиксирован как CPU → GPU → GPU → CPU: два захода на каждое устройство в одной сессии. Перед каждым проходом temperature gate: минимум 120 секунд и пока пакет CPU ≤ 50 °C, GPU ≤ 45 °C. На одном кулере CPU и Max-Q это попытка не смешать троттлинг с вопросом «кто быстрее».

Если сначала CPU, затем GPU, lead decode выходит 4.09×; если наоборот, 4.17×; усреднение ABBA даёт те же 4.14×, что и медиана по сетке. Сдвиг от порядка около 2% значит для агента, который выбирает runtime по одному скриншоту таблицы, разницу между «GPU всегда в 4.1× быстрее» и «цифра плавает от того, что грелось первым».

Диапазон lead decode по ячейкам от 3.93× до 4.30×. Пример 516 токенов на входе и 32 на выходе: CPU 17.06 tok/s decode, GPU 70.61, lead 4.14×. Дрейф между CPU-проходами в худшей ячейке до 9.3% decode связывают с троттлингом; не стоит строить политику «только CPU» или «только GPU» по одному замеру.

MCP и attest: когда агент не должен перепутать устройство

Перед sweep автор не полагается на ручной -ngl: в репозитории gemma4-dev два рига (GPU с GGML_CUDA=ON, CPU без GPU-бэкендов), attest.py сверяет бинарник, -ngl и загрузку CUDA через /proc. Sweep не стартует, если активно «не то» устройство.

Для деплоя и проверок описан набор Python MCP-инструментов; в требованиях к окружению Claude Code или любой MCP-клиент со stdio: агент может стартовать/остановить сервер и получить аттестацию устройства до замера. Это мост от локальной Gemma 4 к циклу с агентом: не облачный биллинг, но тот же класс задач, не дать модели ответить с GPU-стека, пока вы думаете, что гоняете CPU-only.

GPU для интерактива, CPU когда карта занята

Для интерактивной работы с этой моделью на этом железе автор рекомендует GPU: примерно 4× быстрее по измеренным длинам промпта, стабильнее по его таблице, меньше греет общий пакет. CPU-сборка остаётся запасным вариантом при занятой или недоступной карте (16–18 tok/s decode в таблице).

Если вы поднимаете OpenAI-совместимый endpoint для агента на ноутбуке соло, копируйте не только -ngl и версию llama.cpp, но и ABBA вместе с gate: иначе сравнение «облако vs локально» или «CPU vs GPU» превращается в маркетинг одного числа из заголовка. Отчёт замера 22 сентября 2026 и риги лежат в открытом репозитории автора, удобная точка для повторения протокола на своём железе.

Источники