Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Новый движок MINE ускоряет генерацию LLM, когда GPU обрабатывает один запрос и не может распределить загрузку весов между несколькими задачами. В препринте ETH Zurich, который не прошёл рецензирование и содержит замеры самих авторов, максимальное ускорение составило 2,52 раза относительно самого быстрого конкурента. Такой подход может изменить выбор движка для локальных ассистентов и сервисов с жёстким требованием к задержке, но не заменяет обычную оптимизацию пакетной обработки.
Почему сжатие ускоряет один запрос
При генерации каждого токена GPU должен прочитать из памяти почти все веса модели. Для одного запроса вычислительные блоки часто успевают обработать данные быстрее, чем память передаёт следующую порцию, поэтому скорость ограничивает пропускная способность памяти.
Пакетная обработка смягчает проблему: одни и те же веса участвуют сразу в нескольких запросах. Но локальный запуск и интерактивные сервисы не всегда могут ждать, пока накопится пакет. В таком режиме сокращение объёма читаемых данных напрямую влияет на задержку.
MINE применяет энтропийное кодирование (entropy coding): частые значения весов хранит короче редких. Распределение остаётся неравномерным даже после квантования, поэтому движок можно поставить поверх уже сжатого варианта модели. Само кодирование не меняет значения весов и не добавляет новую потерю качества, хотя исходное квантование могло быть неточным.
Обычная распаковка свела бы выгоду на нет: GPU пришлось бы сначала записать восстановленные веса в глобальную память, а затем снова прочитать их для вычислений. Ядро dtANS-LLM распаковывает веса и сразу умножает их на вектор активаций. Редкие значения оно выносит в отдельный поток поправок, чтобы основной массив оставался плотным и подходил для параллельной обработки.
Как MINE выбирает между размером и задержкой
Самое плотное кодирование не обязательно даёт самый быстрый ответ. Оно сокращает чтение из памяти, но требует больше инструкций для распаковки. Баланс зависит от распределения весов, устройства конкретного GPU и формы каждого тензора.
Перед запуском MINE перебирает варианты кодирования: объединяет разное количество весов в символ, меняет размер таблицы декодирования и ширину участка, который обрабатывает поток. Заведомо невыгодные комбинации отбрасывает по прогнозу размера, остальные измеряет на выбранном GPU.
В результате движок строит границу Парето: набор конфигураций, где нельзя уменьшить модель без роста задержки или ускорить её без дополнительной памяти. При загрузке плагин для vLLM получает бюджет памяти и выбирает конфигурацию для каждого запуска ядра. Бюджет относится только к весам, поэтому место под KV-кэш, активации и подготовку промпта нужно резервировать отдельно.
Проверка охватила 19 вариантов Llama 3.1 8B Instruct: от BF16 и FP8 до нескольких способов низкобитного квантования. На RTX 4060 Ti движок чаще выбирал более плотное сжатие, а на RTX 5090 предпочитал менее затратную распаковку. Для EntQuant эффективный размер составил соответственно 2,24 и 3,43 бита на вес; на второй видеокарте ускорение достигло 1,48 раза.
MINE сравнивали с оптимизированными ядрами vLLM, Marlin и Humming, а также с движками DFloat11, ZipServ, NeuZip и EntQuant. Он показал лучшую скорость на всех проверенных вариантах, но иногда достигал её не собственным ядром: если распаковка была невыгодна, MINE передавал слой штатному механизму vLLM.
Когда работа меняет планы по развёртыванию
MINE имеет смысл закладывать в прототип, если продукт последовательно генерирует ответ для одного пользователя, работает на потребительской NVIDIA GPU или должен вместить модель в фиксированный объём памяти. Здесь энтропия квантованных весов становится таким же практическим параметром, как номинальная разрядность: два варианта с одинаковым числом битов могут по-разному сжиматься и давать разную задержку.
Цена такого выбора — отдельная настройка для каждой пары из модели и GPU. В экспериментах полный подбор занимал до 262 минут. Полученный файл настроек можно использовать повторно, но смена видеокарты или варианта весов требует нового прогона.
Для длинных промптов и нескольких одновременных запросов вывод осторожнее. Оптимизированное ядро работает при пакете из одного запроса; в остальных случаях MINE восстанавливает слой в памяти и запускает обычное матричное умножение. На проверенном длинном промпте скорость подготовки контекста составила 94% от vLLM, поэтому выигрыш зависит от того, какую долю времени продукт тратит на последовательную генерацию.
Границы проверки узкие, но практически понятные: одна архитектура модели, две потребительские видеокарты NVIDIA и набор вариантов представления её весов. Работа не доказывает такой же выигрыш для других семейств LLM или серверных ускорителей. Зато опубликованный пакет включает исходный код, плагин vLLM, CUDA-ядра и сценарии воспроизведения, поэтому подход можно проверить на целевой конфигурации до изменения инфраструктурного плана.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
