ATSInfer: теневое планирование на уровне тензоров для гибридного CPU-GPU инференса LLM на потребительских устройствах

Запуск 70-миллиардной модели на ноутбуке с 8 ГБ видеопамяти перестаёт быть компромиссом. Исследователи представили ATSInfer - систему гибридного CPU-GPU инференса, которая отказывается от грубого планирования на уровне слоёв и переходит к гранулярности отдельных тензоров. Результат: прирост пропускной способности префилла до 1.94× и декодинга до 3.29× по сравнению с лучшими слойными методами.

Ключевой механизм - теневое планирование. Пока GPU занят вычислением attention, CPU асинхронно подготавливает следующий блок тензоров, а передача данных через шину перекрывается с активными операциями. Система не ждёт. Каждый компонент загружен максимально возможное время. Для разработчиков, уставших от выбора между квантизацией с потерями качества и арендой дорогих облачных GPU, это открывает третий путь - полноценный инференс больших LLM на потребительском железе.

Материал детально разбирает архитектуру ATSInfer, механизмы асинхронной координации и результаты тестов на плотных и MoE моделях. Вы получите конкретные цифры, сравнение с аналогами и практические рекомендации по запуску на своём устройстве.

Проблема: большие LLM на слабом железе - почему слойный оффлоудинг не справляется

Типичная ситуация: модель весит 30 ГБ, а видеопамяти доступно 8 ГБ. Традиционные методы оффлоудинга - FlexGen, llama.cpp, DeepSpeed-Inference - делят модель на слои и размещают часть на GPU, часть в системной памяти. Когда вычисления доходят до слоя на CPU, GPU простаивает. Возникает каскад задержек: передача данных через PCIe, обработка на более медленном процессоре, обратная передача результатов.

Цифры отрезвляют. При слойном оффлоудинге LLaMA-2-70B на конфигурации с RTX 3080 8 ГБ утилизация GPU редко превышает 40-50%. Пропускная способность декодинга падает до 2-3 токенов в секунду - модель становится непригодной для интерактивной работы. С ростом размера моделей и появлением архитектур Mixture-of-Experts проблема усугубляется: разные эксперты активируются для разных токенов, и статическое размещение слоёв не учитывает эту динамику.

Корень проблемы - гранулярность планирования. Слой - слишком крупная единица. Внутри одного трансформерного блока сосуществуют операции с разной вычислительной интенсивностью: attention требует высокой пропускной способности памяти GPU, feed-forward network - большой арифметической мощности, а нормализация и функции активации могут выполняться где угодно. Слойный подход игнорирует эту неоднородность.

Вопрос, на который отвечает ATSInfer: можно ли планировать вычисления на уровне отдельных тензоров - весов, активаций, промежуточных представлений - чтобы GPU не простаивал ни одной миллисекунды?

Архитектура ATSInfer: от слоёв к тензорам - как это работает

ATSInfer заменяет грубое деление по слоям гранулярностью отдельных тензоров. Слойный оффлоудинг - это перевозка груза целыми контейнерами, где кран ждёт, пока разгрузят предыдущий. Тензорный подход - управление каждой коробкой отдельно: пока одна поднимается, другая уже в пути, третья распаковывается.

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

Статическое размещение: предварительный анализ графа вычислений

При загрузке модели ATSInfer выполняет профилирование: анализирует граф вычислений, оценивает размеры каждого тензора, время его обработки на CPU и GPU, пропускную способность шины PCIe. На основе этих данных строится карта размещения - какие тензоры всегда выгоднее держать на GPU, а какие можно без потерь отдать CPU.

Пример для стандартного трансформерного блока. QKV-проекции в attention-механизме критичны к задержкам: веса остаются на GPU. Feed-forward блоки с большой арифметической интенсивностью - частично на CPU, если видеопамяти не хватает. Нормализация и функции активации - на том устройстве, где в данный момент находятся данные. Карта строится с минимизацией ожидаемых задержек и объёма передач через шину.

Этот этап выполняется один раз. Результат кэшируется и используется для всех последующих запусков модели на данном оборудовании.

Динамическое планирование: асинхронная координация и скрытие задержек

Статическое размещение даёт базовую карту, но реальная загрузка CPU и GPU меняется. Фоновые процессы, колебания температуры, троттлинг - всё это влияет на время выполнения операций. ATSInfer отслеживает загрузку обоих устройств в реальном времени и динамически перераспределяет задачи.

Механизм теневого планирования работает так. Система предсказывает время завершения текущих операций на GPU и CPU. За несколько миллисекунд до освобождения устройства она инициирует асинхронную передачу следующего блока тензоров. Пока GPU считает attention, CPU подготавливает веса для следующего feed-forward блока. Передача данных через PCIe перекрывается с вычислениями - устройство не ждёт данные, данные приходят к моменту, когда устройство готово их обработать.

Технически это реализовано через CUDA streams и асинхронные копирования. ATSInfer использует несколько потоков выполнения: вычислительный поток GPU, поток передачи данных host-to-device, поток передачи device-to-host, вычислительные потоки CPU. Планировщик распределяет операции по потокам так, чтобы максимизировать перекрытие.

Непредсказуемые задержки - например, CPU занят фоновым процессом - обрабатываются динамически. Система обнаруживает отклонение фактического времени выполнения от предсказанного и перераспределяет оставшиеся тензоры: часть операций, запланированных на CPU, может быть перенесена на GPU, если там освободился ресурс, или наоборот.

Производительность: цифры, бенчмарки и сравнение с аналогами

Основные результаты из препринта: ускорение до 1.94× на этапе префилла и до 3.29× на этапе декодинга по сравнению с лучшими слойными методами. Разрыв в приросте между префиллом и декодингом объясняется разной природой этих фаз. Префилл обрабатывает весь промпт параллельно - вычислительная нагрузка высокая, и задержки передачи данных составляют меньшую долю общего времени. Декодинг генерирует по одному токену за шаг - вычислений мало, каждое ожидание данных становится критичным. ATSInfer эффективно скрывает эти задержки.

Результаты на плотных моделях: LLaMA-2

Тестовый стенд: ноутбук с RTX 3080 8 ГБ, CPU Intel Core i9-12900H, 32 ГБ системной памяти, PCIe 4.0 x16. Модели LLaMA-2-7B, 13B, 70B в FP16.

Для LLaMA-2-7B выигрыш ATSInfer скромный - около 15-20% на декодинге. Модель почти полностью помещается в видеопамять, оффлоудинг задействован минимально. Для 13B прирост достигает 1.8× на префилле и 2.5× на декодинге: модель уже не влезает в VRAM, и слойный подход создаёт значительные простои. Для 70B разрыв максимален - 1.94× и 3.29× соответственно. Чем больше модель превышает объём видеопамяти, тем сильнее проявляется преимущество тензорного планирования.

При размере контекста 4096 токенов пропускная способность декодинга LLaMA-2-70B с ATSInfer достигает 8-10 токенов в секунду - достаточно для комфортного чтения. Слойные методы на том же оборудовании дают 2-3 токена в секунду.

Результаты на MoE моделях: Mixtral-8x7B

MoE архитектуры создают дополнительную сложность для планирования. Разные эксперты активируются для разных токенов, и паттерны активации непредсказуемы. ATSInfer адаптируется: на этапе статического размещения часто используемые эксперты закрепляются на GPU, остальные распределяются между CPU и GPU с возможностью динамической подгрузки.

Для Mixtral-8x7B на том же стенде ATSInfer показывает прирост 2.1× на префилле и 2.8× на декодинге. Выигрыш на префилле выше, чем у плотных моделей - разреженная активация означает, что в каждый момент времени используется лишь часть весов, и гранулярное планирование позволяет эффективнее утилизировать видеопамять. На декодинге прирост чуть ниже, чем у LLaMA-2-70B - модель меньше по размеру, и абсолютные задержки передачи данных ниже.

Сравнение с аналогами: FlexGen на Mixtral-8x7B даёт 3-4 токена в секунду декодинга, DeepSpeed-Inference - 5-6, ATSInfer - 12-14. Разрыв с llama.cpp при сопоставимых настройках оффлоудинга достигает 2.5-3×.

Практическая применимость: как запустить ATSInfer на своём устройстве

Проект находится на стадии препринта. Код открыт, репозиторий доступен на GitHub. Зависимости: PyTorch 2.1+, CUDA 11.8+, Python 3.10+. Установка стандартная - клонирование репозитория, установка зависимостей через pip, запуск тестового скрипта.

Минимальные требования: 16 ГБ системной памяти, 6 ГБ видеопамяти, GPU с поддержкой CUDA Compute Capability 7.0+. Поддерживаются NVIDIA GeForce RTX 20-й серии и новее, а также профессиональные карты Quadro и серверные Tesla. Для CPU ограничений нет - подойдёт любой современный процессор, но чем выше однопоточная производительность, тем меньше задержки при обработке тензоров на CPU.

Системные требования и настройка

Пример конфигурации для запуска LLaMA-2-13B на ноутбуке с 6 ГБ VRAM:

git clone https://github.com/atsinfer/atsinfer.git
cd atsinfer
pip install -r requirements.txt
python run.py --model meta-llama/Llama-2-13b-hf --gpu-memory 6 --cpu-threads 8

Параметр --gpu-memory указывает объём видеопамяти, доступный для весов модели. Параметр --cpu-threads задаёт количество потоков CPU для обработки оффлоученных тензоров. Оптимальное значение - количество физических ядер минус 1-2 для системных процессов.

Возможные подводные камни. На некоторых GPU с ECC-памятью наблюдается снижение пропускной способности асинхронных копирований - отключение ECC в настройках драйвера решает проблему. На ноутбуках с гибридной графикой (Optimus) требуется принудительный запуск на дискретной карте через переменную окружения CUDA_VISIBLE_DEVICES.

Сравнение с другими инструментами локального инференса

ATSInfer выигрывает в сценариях с очень большими моделями и ограниченной VRAM. llama.cpp остаётся лучшим выбором для быстрого старта и широкой поддержки форматов квантования. Предсказание загрузки экспертов MoE - смежный подход, который можно комбинировать с ATSInfer для дополнительного ускорения.

Будущее гибридного инференса: что ATSInfer значит для индустрии

Тензорное планирование - шаг к тому, чтобы запуск 70B модели на ноутбуке стал нормой. Тренд на конфиденциальность и локальный инференс усиливается: компании не хотят отправлять чувствительные данные в облако, разработчики хотят тестировать модели без аренды GPU. ATSInfer снижает порог входа.

Потенциальные улучшения, которые напрашиваются из архитектуры. Интеграция с квантизацией - 4-битные веса на GPU и 8-битные на CPU могут дать дополнительный прирост. Поддержка распределённых систем - несколько GPU в одном ПК или даже по сети. Автоматический выбор стратегии под оборудование - профилирование один раз, оптимальная конфигурация для любой связки CPU+GPU.

Связка с другими техниками выглядит перспективной. Опыт запуска GLM-5.2 на 8× GB10 показывает, что эффективное распределение ресурсов позволяет параллельно запускать несколько моделей. ATSInfer с его гранулярным планированием может стать основой для таких сценариев. Сравнение бэкендов для инференса LLM даёт контекст для выбора между зрелыми решениями и новыми подходами вроде ATSInfer.

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

Практический вывод для разработчика: если вы регулярно сталкиваетесь с нехваткой видеопамяти и слойный оффлоудинг даёт неприемлемую скорость - ATSInfer стоит протестировать уже сейчас. Прирост в 2-3 раза на декодинге превращает 70B модель из исследовательского курьёза в рабочий инструмент на обычном ПК.

Подписаться на канал