Оптимизация запуска больших MoE-моделей на видеокарте с 6 ГБ памяти в llama.cpp

MoE-модели — Практические эксперименты по запуску больших MoE-моделей на скромном домашнем ПК с видеокартой на 6 ГБ и 24 ГБ ОЗУ показывают, что ручное распределение слоев часто уступает стандартному поведению утилит. В ходе настройки работы gpt-oss-20b выяснилось, что запуск больших MoE-моделей на слабом железе требует отказа от привычных ключей вроде -ngl 99 в пользу встроенных механизмов автоматического подбора.

Основной целью подобных изысканий является адаптация современных языковых моделей под скромные аппаратные конфигурации без необходимости приобретать производительные графические ускорители или оформлять платные подписки. Поскольку у моделей типа Mixture of Experts в обработке каждого токена задействована лишь небольшая доля доступных экспертов, ключевую роль играет грамотное управление дисковым чтением и оперативной памятью.

Используемый аппаратный стенд и методика

Для проведения тестов применялась конфигурация на базе процессора Ryzen 5 1600 с шестью ядрами Zen 1, 24 гигабайтами оперативной памяти стандарта DDR4, видеокартой GTX 1660 SUPER с 6 ГБ видеопамяти, быстрым SATA SSD и операционной системой Windows 10. Исследуемая модель gpt-oss-20b в исходном формате MXFP4 занимала файл размером 11,3 ГиБ. Измерения производительности проводились в стандартных сценариях, где обрабатывался длинный запрос на 16 тысяч токенов с последующей генерацией ответа целиком на 256 токенов, что соответствует типичной повседневной нагрузке при анализе кода или документов.

Почему не стоит использовать флаг -ngl 99

Многочисленные сетевые инструкции по работе с llama.cpp часто рекомендуют принудительно переносить все слои на графический ускоритель с помощью параметра -ngl 99. Однако для моделей, которые физически не помещаются в видеопамять, на системе Windows это приводит к негативным последствиям. Запрос на 16 тысяч токенов при размещении в быстрой памяти примерно 46% веса модели демонстрирует существенную разницу в производительности в зависимости от выбранной раскладки.

Параметр -ngl 99 запрашивает у шестигигабайтной видеокарты объем памяти, почти вдвое превышающий ее реальные возможности. В среде Linux подобная конфигурация обычно завершается ошибкой загрузки, но драйверы Windows молча перенаправляют излишки данных в общую системную память через шину, вызывая постоянные задержки. Скорость генерации при этом нестабильна, а объем чтения данных с накопителя возрастает многократно по сравнению с альтернативными методами.

Встроенный флаг -fit действует иначе: он оставляет на видеокарте уровень внимания и ровно такое количество экспертов, которое способно поместиться, а остальных переносит в оперативную память. По мере увеличения контекста и заполнения видеопамяти KV-кэшем система автоматически корректирует размещение экспертов. Ловушка заключается в том, что автоматический режим активен по умолчанию, но отключается при ручном задании параметров вроде -ngl, -ot или -ncmoe. Таким образом, принудительное выставление максимального числа слоев на GPU фактически блокирует эффективный штатный алгоритм распределения.

Настройка размера убатча для обработки длинных запросов

Вторым значимым параметром, влияющим на скорость обработки запроса, выступает размер убатча -ub. Значение по умолчанию составляет 512, однако эксперименты показывают немонотонную зависимость скорости от этого показателя. Для запроса на 16 тысяч токенов увеличение убатча до 1024 ускоряет процесс, а дальнейшее повышение до 1536 обеспечивает пиковые показатели.

Чрезмерное увеличение убатча приводит к нехватке ресурсов: крупные блоки начинают вытеснять кэш страниц, провоцируя интенсивное обращение к накопителю. На контексте в 65 тысяч токенов оптимальные значения сдвигаются, требуя аккуратного подбора параметров под конкретную длину запроса и объем доступной оперативной памяти.

Оценка влияния KV-кэша на производительность

Формат кэша ключей и значений заметно влияет как на скорость работы, так и на точность модели. Применение квантования q8_0 практически не ухудшает перплексию, сохраняя качество генерации на исходном уровне. В то же время более агрессивное квантование q4_0 приводит к заметному росту погрешности, из-за чего часть наиболее вероятных токенов в ответах заменяется альтернативными вариантами.

На больших контекстах KV-кэш занимает существенный объем видеопамяти и способен вытеснять оттуда экспертов модели. Использование оптимизированных форматов хранения кэша позволяет эффективнее использовать ограниченные ресурсы графического адаптера на длинных последовательностях.

Неэффективные подходы и факторы искажения замеров

Попытки задействовать спекулятивное декодирование с помощью n-грамм на исследуемой архитектуре не принесли ощутимого прироста скорости. Из-за отсутствия собственной выделенной MTP-головы черновик формировался на основе контекста, однако реальная частота успешных срабатываний оказалась слишком низкой, чтобы перекрыть погрешности измерения. Ограничения процессора с архитектурой Zen 1 также играют свою роль: вычисления упираются в производительность ядер при обработке векторных инструкций.

Отдельное внимание в работе уделено методике сбора метрик. Утилита llama-bench по умолчанию заполняет модель случайными токенами, что приводит к некорректной оценке компонентов, зависящих от работы маршрутизатора MoE. Кроме того, на результаты сильно влияют кэширование файлов операционной системой, тепловой троттлинг и общий дрейф производительности между последовательными запусками, что требует усреднения данных и проведения тестов вперемешку.