Если сервер с AMD GPU после простоя начинает генерировать текст со скоростью 2-3 токена в секунду вместо ожидаемых 50, это не "медленная видеокарта" и не ошибка модели. Это деградация бэкенда Vulkan в llama.cpp. Мы столкнулись с ней на практике и перепробовали несколько известных мер. В итоге сработала только одна - и это важно зафиксировать, потому что остальные в нашем случае не дали ничего.
Симптом
После паузы в работе модель выдавала порядка 2.8 t/s вместо нормальных ~50 t/s. Swap при этом рос до 2.1 GiB - то есть модель вытеснялась из памяти. Первый запрос после простоя выполнялся в десятки раз дольше обычного.
Что мы пробовали
Мы применили набор мер, которые обычно советуют против деградации Vulkan в llama.cpp:
- amdgpu.runpm=0 в параметрах загрузки GRUB - запрет GPU уходить в runtime suspend;
- --load-mode mmap+mlock - фиксация страниц модели в RAM, чтобы ядро не вытесняло их в swap;
- --sleep-idle-seconds -1 - запрет роутеру выгружать простаивающую модель;
- GGML_VK_SUBALLOCATION_BLOCK_SIZE=4294967296 (4 GiB) - увеличенный блок субаллокации Vulkan-пула.
Что реально помогло
Сработал только amdgpu.runpm=0. После его применения скорость после паузы вернулась к норме: замеры показали 49.7-52.5 t/s после 15 секунд простоя, стабильно, без деградации. Swap упал до 512 KiB и не рос даже во время этапа merge, когда ffmpeg активно потребляет память.
Остальные три меры - --load-mode mmap+mlock, --sleep-idle-seconds -1 и GGML_VK_SUBALLOCATION_BLOCK_SIZE=4G - в нашей конфигурации ничего не дали. Мы их пробовали, эффекта не было. Это не значит, что они бесполезны вообще: в других условиях, на других моделях и размерах контекста они могут работать. Но в нашем случае деградацию устранил именно запрет runtime suspend на уровне драйвера.
Почему это важно
В публичных обсуждениях llama.cpp деградацию Vulkan часто объясняют фрагментацией пула, выгрузкой idle-модели или swap-вытеснением, и советуют соответствующие флаги. Наш опыт показывает, что набор "популярных" мер может не сработать, а причина окажется на уровне драйвера. Если вы боретесь с падением скорости после простоя на AMD GPU, начинайте с amdgpu.runpm=0 - это самая дешёвая проверка, и в нашем случае она оказалась единственной, которая дала результат.
Что мы не проверяли
Мы не проводили пошаговый A/B-тест с изоляцией каждой меры и не снимали профиль Vulkan-пула. Вывод "помог только runpm=0" основан на том, что после применения набора скорость восстановилась, а при последующем разборе выяснилось, что эффект дал именно этот параметр, а остальные в нашей конфигурации ничего не изменили. Ссылки на конкретные issue llama.cpp с цифрами и номерами мы в этой статье не приводим, потому что не сверяли их в процессе работы.
Автор статьи: https://jedig.ru