Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Сжатую LLM научились подгонять под конкретную видеокарту, движок и нагрузку, а не под условное число параметров. В препринте, который не прошёл рецензирование и содержит замеры самих авторов, AutoCompress обошёл адаптированный Minitron во всех проверенных сценариях. Для команд со своей инфраструктурой это меняет порядок работы: сначала задаётся режим эксплуатации, затем под него выбирается архитектура.
Число параметров плохо предсказывает стоимость запуска
Одинаковый размер модели не означает одинаковую задержку. Две архитектуры с равным числом параметров отличались по задержке на RTX 5070 на 35%: узкая и глубокая модель работала медленнее широкой и менее глубокой.
Обратная ситуация возникла на H100. Две модели обеспечивали одинаковую пропускную способность, хотя одна содержала в 2,2 раза больше параметров. На результат влияют форма матриц, число слоёв, активные эксперты, выбранные ядра GPU, размер пакета запросов и работа движка.
Обычная оценка памяти тоже учитывает не всё. К весам и кешу запросов добавляются рабочая память предварительной обработки, буферы матричных операций, графы CUDA и служебные области движка. В одном из опытов расчёт только по весам, кешу и основному буферу пропустил примерно треть фактического потребления памяти.
Как аппаратные ограничения попали в поиск архитектуры
AutoCompress принимает контракт эксплуатации: GPU, движок, точность вычислений, размер пакета, длины входа и ответа, состояние кеша, предел памяти и требование к задержке либо пропускной способности. Поэтому поиск оптимизирует не абстрактную компактность, а возможность обслужить заданную нагрузку.
Сначала система строит модели стоимости. Она запускает разные конфигурации слоёв внутри целевого движка и через Nsight Systems измеряет время работы на GPU. Задержку полной архитектуры затем оценивает как сумму времён её слоёв с учётом общих расходов на эмбеддинги, выдачу токенов и сам движок.
Память рассчитывается отдельно. Модель стоимости складывает веса, кеш внимания и Mamba, рабочие области предварительной обработки и буферы для MoE и Mamba. К ним добавляется запас, полученный из разницы между расчётом и реальными запусками сервера.
После профилирования AutoCompress создаёт общую сеть весов для множества кандидатов. Компоненты исходной модели ранжируются по влиянию на активации, поэтому каждый кандидат использует свою начальную часть каналов, голов и экспертов.
Маршрутизатор архитектуры выбирает глобальный скрытый размер и число голов Mamba, а для каждого слоя отдельно — количество экспертов и ширину блоков MoE. В некоторых конфигурациях он может удалить слой. Выбор остаётся дифференцируемым: качество дистилляции и превышение аппаратного бюджета передают градиенты маршрутизатору, и тот учится распределять ёмкость между слоями.
После поиска система извлекает дискретную архитектуру из исходной модели и восстанавливает её качество дистилляцией. В итоговую модель переходят сохранённые веса родителя, а не временные веса общей поисковой сети.
Когда AutoCompress меняет план разработки
На общем наборе тестов среднее качество выросло относительно Minitron++ на 6,57 процентного пункта для RTX 5070 и на 0,57 пункта для H100; вариант для RTX 5080 также оказался лучше. В отдельном опыте Nemotron 3.5 Super сократили со 120B до 74B параметров, сохранив 95% среднего результата исходной модели.
Проверка охватывает две исходные гибридные модели с Mamba, вниманием и MoE. Сценарии включали локального игрового персонажа с жёсткой задержкой и памятью, помощника по программированию с длинным контекстом и пакетную обработку запросов в центре обработки данных. В качестве основной базы сравнения использовали Minitron++, адаптированный к тем же моделям стоимости и бюджетам, но с одинаковыми размерами блоков во всех слоях.
Работа меняет планы команд, которые собираются структурно сокращать модель для собственного оборудования. Вместо выбора условной модели на заданное число параметров имеет смысл зафиксировать движок и профиль нагрузки, измерить стоимость вариантов слоёв и включить эксплуатационные пределы прямо в поиск.
Результат при этом привязан к контракту эксплуатации. Переход на другой GPU, размер пакета или длину контекста меняет стоимость архитектур, поэтому таблицы времени и целевые ограничения придётся пересчитать. AutoCompress также требует доступа к исходной модели, целевому оборудованию и циклу дистилляции; для продукта, который вызывает только внешний API, этот процесс не заменяет выбор готовой модели у поставщика.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
