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

Разборы

Gemma 4 на ноутбуке: три множителя скорости и один флаг llama.cpp

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

Gemma 4 на ноутбуке: три множителя скорости и один флаг llama.cpp

Три цифры из одного замера на ноутбуке: межтокенный decode на дискретной карте быстрее примерно в 4,3 раза, prefill (TTFT) около 3,6×, сквозной ответ около 3,8×. Для соло-разработчика с локальным inference на 127.0.0.1 рядом с IDE или агентом это развилка: ускорится поток токенов в чате или упрётесь в первый байт длинного контекста.

Локальный LLM рядом с агентом: decode, prefill и сквозной ответ

xbill (Google Developer Experts) гоняет квантованную Gemma 4 E2B в формате GGUF через llama.cpp коммита c6824a9 на одном ноутбуке: Intel Core i7-1360P (12 ядер / 16 потоков) против GTX 1650 Ti Max-Q на 4096 MiB VRAM. Модель google/gemma-4-E2B-it-qat-q4_0-gguf, файл около 3,35 GB; сервер слушает 127.0.0.1:8080, контекст 8192 токена, один параллельный запрос.

Фокус замера — decode, межтокенная скорость по SSE. В таблице восьми ячеек (длины промпта 94, 516, 998, 1959 токенов × выход 32 и 128 токенов, по три повтора) медиана отношения GPU к CPU по decode 4,27× (по ячейкам 4,04×–4,34×; округление до 4,3× в англоязычном заголовке замера укладывается в коридор). Prefill (TTFT) медианно 3,63×; xbill считает эту величину верхней границей, потому что на CPU-руке не закреплён affinity. End-to-end медиана 3,81×.

Для сценария «агент стримит ответ в чат» критичен decode: на GPU примерно 67–71 tok/s против ~16–18 tok/s на CPU при росте длины промпта. Для сценария «залили длинный system prompt и ждём первый токен» доминирует prefill: выигрыш карты меньше, чем в заголовке, и сильнее зависит от длины входа (при 1959 входных токенах TTFT на CPU порядка 24 с, на GPU около 6,5 с).

Инструментальный рычаг: -ngl 0 против -ngl 99 и сборка llama.cpp

Вся разница между руками в примере командной строки сводится к одному параметру offload слоёв на GPU:

-m gemma-4-E2B_q4_0-it.gguf --host 127.0.0.1 --port 8080 \
  -ngl {0|99} -c 8192 -ctk f16 -ctv f16 -fa 1 -t 4 -tb 8 --parallel 1 --metrics

CPU-режим: сборка GGML_CUDA=OFF, запуск с -ngl 0. GPU-режим: CUDA-сборка, -ngl 99. Остальные флаги совпадают. CUDA-бинарник с -ngl 0 не считается чистой CPU-рукой; устройство фиксируют по /proc (exe, maps, cmdline), а не по HTTP-ответу.

На GPU при сервинге занято 1598 MiB VRAM: значительная часть файла (lazy embedding, порядка 58% по отчёту xbill) не выгружается на карту. На CPU заметен большой анонимный RSS (~1,2 GB в метрике RssAnon) из‑за repack Q4_0 под AVX2. Для vibe-coding на одной машине вывод простой: «4 GB карта + IDE» остаётся реалистичной, если не грузить параллельно тяжёлый графический стек и не ждать, что весь файл 3,35 GB осядет в VRAM.

Между замерами cooldown 120 s (подобран xbill, не измерен); CPU-рука всегда первая. Порядок прогонов и термали могут слегка занижать GPU относительно холодного старта; в методике это проговорено.

Границы ноутбучного замера для агентного цикла

Один ноутбук, один GGUF, warm page cache, concurrency 1. Холодный старт и эксперимент со сброшенным кэшем для lazy embedding в протоколе не фигурируют. Обсуждение на Dev.to про другие рантаймы и cold start к таблице xbill не относится.

xbill в заключении намекает на сравнение локальных ускорителей через MCP, но протокол не разбирает. Узкий вывод: перед встраиванием модели в цикл с вызовами инструментов, RAG и несколькими запросами отдельно померьте свой mix decode/prefill на той же машине, а не экстраполируйте заголовочные 4,3× на весь агентный цикл.

Воспроизводимые отчёты и артефакты лежат в репозитории gemma4-dev.

Источники