На 24 мая 2026 года всё больше владельцев видеокарт с 4 ГБ VRAM жалуются на одну и ту же странность: Gemma 4 e2b (квантованная модель от Google) начинает откровенно тупить после 30–40 инференсов. Ответы становятся короче, теряют логику, а иногда модель просто молчит. Баг воспроизводится стабильно, но официального фикса до сих пор нет. Давайте разбираться, что происходит под капотом и как хотя бы диагностировать проблему, пока разработчики не выпустили патч.
Важно: проблема проявляется только на картах с 4 ГБ (GTX 1650, RTX 3050, древние Quadro) при запуске через llama-server с флагами --flash-attn и контекстом ~4096 токенов. На 6+ ГБ баг не замечен.
Стабильность до 30 — а потом обрыв
Типичный сценарий: вы запускаете Gemma 4 e2b Q4_K_M, первые 30–40 запросов модель радует адекватными ответами. Потом внезапно — пустые генерации, повтор одних и тех же слов, игнорирование системного промпта. Это не OOM (Out of Memory) — процесс не падает, но качество валится в пропасть. Некоторые пользователи замечали, что после 50-го инференса модель начинает отвечать как рандомный генератор.
Ключевая деталь: проблема исчезает, если сбросить контекст или перезагрузить llama-server. Это намекает на накопление «мусора» в памяти, а не на повреждение самой модели.
Подозреваемый №1: KV cache и фрагментация
4 ГБ — это жесткий лимит. Даже с квантованием Q4 модель занимает ~2.5 ГБ под веса. Остаётся всего 1.5 ГБ на KV cache, промежуточные активации и буферы. При каждом новом инференсе llama-server выделяет новый блок для KV cache, а старый не всегда освобождается полностью. Фрагментация памяти растёт, и через 30–40 циклов выделить непрерывный блок для нового токена становится всё сложнее.
Flash-Attention, который должен ускорять вычисления, в данном случае не спасает — он лишь меняет порядок операций, но не решает проблему фрагментации кучи CUDA. Более того, при --flash-attn может использоваться дополнительная временная память, что усугубляет ситуацию.
Сравните с Gemma 4 против Qwen3.5: когда KV cache съедает вашу видеопамять и как это исправить — там мы подробно разбирали механизмы утечки.
Подозреваемый №2: баг в llama.cpp или особенности e2b
Версия e2b (extended to batch?) Gemma 4 была выпущена с поддержкой пакетной обработки. При батчевом инференсе через llama-server память переиспользуется иначе. Есть гипотеза, что внутренний указатель на KV cache для первого запроса в батче не сбрасывается, и после накопления определённого числа запросов происходит переполнение буфера — не в плане суммы, а в плане логики индексации.
Также нельзя исключать, что это проявляется только на конкретных сборках llama.cpp от 15–20 мая 2026 года. В практическом руководстве по TurboQuant KV Cache сжатию упоминалось, что многие фиксы ещё не вошли в мейнлайн.
Диагностика: как убедиться, что это не галлюцинация
Если вы заметили падение качества — не спешите обвинять квантование. Вот простой протокол проверки:
- Сравни ответы на один и тот же промпт: например, «Перечисли основные причины Второй мировой войны». После 1-го и после 35-го инференса ответ должен быть одинаковым — если нет, фиксируем деградацию.
- Мониторинг VRAM: используй
nvidia-smiкаждые 5 запросов. Если занятая память растёт (а не колеблется), это утечка. Нормальная ситуация — небольшие колебания ±50 МБ. - Логи llama-server: включи флаг
--verboseи следи за предупреждениями о повторном выделении буферов. Появление сообщений вродеcan't allocate KV cache block, reallocating— тревожный звоночек. - Смена версии бинарника: откатись на сборку от 1 мая 2026 или попробуй ночную — иногда баг уже исправлен, но не вошёл в официальный релиз.
Совет: если деградация проявляется, попробуй установить --cache-type-k=f16 и --cache-type-v=f16 — это снизит точность кэша, но уменьшит фрагментацию. По данным сообщества, это отодвигает порог сбоя до 50–60 инференсов.
Альтернативные гипотезы: семплинг, контекст, драйверы
Некоторые пользователи списывали всё на «усталость» модели, но LLM не устают. Более реально: при малом объёме VRAM может срабатывать fallback на CPU для части вычислений — это вызывает задержки и сбивает семплинг. В обзоре z-lab отмечали, что DFlash частично решает проблему за счёт offloading части тензоров, но на 4 ГБ он тоже не панацея.
Также стоит проверить драйверы NVIDIA — на Linux ветка 550.xx давала меньше артефактов, чем 545.xx. Переключение на CUDA 12.4 иногда полностью убирает фрагментацию.
Пока патча нет, но можно жить
Google пока молчит. В репозитории llama.cpp issue #8743 (открыт 18 мая) собирает логи диагностики. Если у вас 4 ГБ и Gemma 4 e2b — не ждите чуда. Обновите llama.cpp до последней ночной сборки, уменьшите контекст до 2048 или используйте лайфхак с Q8 mmproj для более эффективного сжатия KV cache.
И напоследок: не бойтесь экспериментировать с флагами. Иногда замена --no-kv-offload на --kv-offload (или наоборот) кардинально меняет поведение. И держите под рукой скрипт для автоматической перезагрузки сервера через каждые 30 запросов — костыль, но рабочий.
