Что известно о PLE disk offload в vLLM на данный момент
В nightly-сборках vLLM появилась поддержка PLE disk offload. За короткой формулировкой стоит конкретная инженерная идея: данные per-layer embeddings (PLE) можно хранить не в видеопамяти, а на диске и подгружать по мере необходимости. Для тех, кто запускает локальные модели на картах с 8-16 ГБ VRAM, это меняет расклад по памяти.
Деталей мало. Новость разошлась через обсуждение на Reddit, без описания алгоритма подкачки, параметров запуска и замеров. Официального анонса с техническими подробностями, который можно было бы разобрать по пунктам, на момент подготовки материала в открытом доступе не нашлось. Поэтому дальше речь пойдёт о механике: что такое PLE, почему они дорого стоят для VRAM, как устроена выгрузка на диск и где начинаются компромиссы.
Про статус сразу: nightly-сборки vLLM собираются из основной ветки разработки и не гарантируют стабильность API. Функция, появившаяся там сегодня, может измениться или исчезнуть через неделю. Это эксперимент, а не готовая возможность стабильного релиза.
Маршрут по статье: сначала PLE и их место в памяти, потом механика disk offload и цена в латентности, затем сценарии с реальной выгодой, риски nightly-канала и практическая проверка того, что функция есть в вашей сборке.
Что такое PLE в контексте vLLM
PLE расшифровывается как per-layer embeddings, послойные эмбеддинги. Обычная модель подаёт эмбеддинг токена только на вход первого слоя. С PLE в каждый слой или в часть слоёв дополнительно подмешивается вектор из отдельной таблицы, выбранный по индексу токена. Схема встречается в моделях семейства Gemma, в частности в Gemma 3n.
Для inference-движка вывод простой: PLE это ещё один набор параметров, которым нужно управлять отдельно. Растворить их в матрицах весов трансформера нельзя, у них другая логика доступа.
Чем PLE отличаются от обычных весов модели
Веса трансформера участвуют в матричных умножениях на каждом шаге генерации. Их читают постоянно и большими блоками, поэтому они и лежат в VRAM. Таблица PLE работает иначе: движок обращается к ней по индексу токена, как к словарю. Доступ точечный, а не потоковый.
Отсюда разные стратегии размещения. Веса обязаны быть быстрыми, иначе генерация встанет. К таблице PLE применима другая логика: держать редко используемые строки на более медленном уровне памяти и подтягивать по требованию. На этой разнице и строится disk offload.
Почему PLE стали проблемой для VRAM
PLE увеличивают суммарный объём параметров, которые движок держит в памяти. Рядом живёт KV-cache, растущий с длиной контекста и размером батча, плюс рабочие буферы и память под графы. На картах с 8-24 ГБ бюджет кончается быстро, и каждый гигабайт на счету: лишние 2-3 ГБ под таблицу PLE легко превращаются в разницу между «модель влезла» и «не влезла».
Точные размеры таблиц зависят от конфигурации чекпоинта. Их нужно сверять по карточке модели и по конфигу движка, а не брать из обсуждений. У разных моделей доля PLE в общем объёме заметно отличается, поэтому универсального процента экономии не существует.
Зачем нужен disk offload и как он работает
Offload это перенос данных на более медленный уровень иерархии памяти с подгрузкой по необходимости. Уровней в типичной локальной сборке четыре, и разница между ними по скорости измеряется порядками.
| Уровень | Скорость чтения | Типичный объём | Что обычно держат |
|---|---|---|---|
| VRAM (HBM) | сотни ГБ/с и выше | 8-80 ГБ | веса, KV-cache, активные PLE |
| CPU RAM | десятки ГБ/с | 32-512 ГБ | выгруженные веса, кэш PLE |
| NVMe SSD | единицы-десятки ГБ/с | терабайты | выгруженные PLE |
| HDD | сотни МБ/с | терабайты | холодные данные |
Disk offload освобождает самый дефицитный и самый быстрый уровень памяти ценой латентности на обращениях. Для PLE такой обмен осмыслен: обращения точечные, а таблица может занимать гигабайты, которые нужнее KV-cache.
Что освобождается в VRAM и что уходит на диск
На GPU остаётся то, что требуется на каждом шаге генерации: веса трансформера и KV-cache. Таблица PLE переезжает на диск. Размер выигрыша равен доле, которую PLE занимают в конкретной модели, поэтому у одного чекпоинта освободятся единицы гигабайт, у другого результат окажется скромнее. Проверять нужно по конфигурации модели и по коду движка, других надёжных способов нет.
Если в вашей модели PLE нет, функция к ней неприменима в принципе: выгружать нечего, а веса трансформера на диск так не уедут.
Компромисс по скорости и латентности
Чтение с NVMe на порядки медленнее чтения из VRAM. Когда нужная строка PLE уже в кэше, шаг генерации проходит штатно. Когда нет, движок ждёт накопитель, и токен выдаётся с задержкой. Насколько большой, зависит от размера кэша, разнообразия токенов в ответе и скорости SSD. HDD в этой роли предсказуемо плохой выбор.
Порядок величин виден на смежных экспериментах с дисковыми тирами в локальном инференсе: разбор запуска 85-гигабайтной MoE-модели на RTX 3060 12 ГБ через дисковый тир Overspill показывает, что модель работает, но счёт идёт на единицы токенов в секунду. Официальных бенчмарков PLE disk offload в vLLM нет, поэтому конкретные цифры для этой функции приводить нельзя.
Кому PLE disk offload реально поможет
Функция адресована тем, у кого память упирается раньше, чем производительность. Практические сценарии выглядят так.
- Домашний AI-сервер с GPU на 8-16 ГБ, где модель с PLE иначе просто не помещается в VRAM вместе с KV-cache.
- Эксперименты с моделями семейства Gemma, где слой послойных эмбеддингов занимает заметную часть бюджета памяти.
- Задачи, где важнее получить работающую модель на длинном контексте, чем максимальную скорость генерации: разборы документов, черновики, редкие запросы.
- Одиночный пользователь с быстрым NVMe и запасом системной RAM, который готов подождать ответа.
Если вы ещё выбираете движок под свой сетап, полезно сравнить общий контекст: чем vLLM отличается от llama.cpp при локальном запуске MoE-моделей с выгрузкой тензоров в системную память. Логика размещения данных по уровням памяти там та же, отличается реализация.
Сценарии, где выгода сомнительна
Высоконагруженный inference с требованиями к латентности: любое обращение к диску в горячем пути ломает предсказуемость SLA. Конфигурации без быстрого SSD: на HDD задержки станут доминирующей статьёй расхода времени. Модели без PLE: функция для них бесполезна. Случаи, когда узкое место не память, а вычисления: освободившиеся гигабайты не ускорят матричные умножения.
Про то, как ищут прирост на стороне вычислений, а не памяти, говорит другой материал: эксперимент с патчами для MoE-инференса в llama.cpp на RTX 4080. И отдельный взгляд на узкие движки под конкретную модель: зачем нужны overfit-рантаймы и какие компромиссы они несут.
Чек-лист для самопроверки перед тем, как пробовать:
- Сколько VRAM остаётся свободной после загрузки весов и KV-cache?
- Есть ли в выбранной модели PLE и какую долю они занимают?
- Стоит ли в системе NVMe SSD или обычный диск?
- Готовы ли вы к росту задержек на отдельных токенах?
- Допустима ли на вашей машине nightly-сборка?
Nightly-сборки vLLM: что это и чем они отличаются от стабильных релизов
Nightly-сборки это автоматические сборки из основной ветки разработки. Они выходят регулярно и содержат свежие изменения задолго до того, как те попадут в стабильный релиз. Стабильные версии проходят более длинную проверку, получают семантический номер и фиксируются в документации. Отсюда и разница в рисках: nightly показывает будущее, стабильный релиз описывает настоящее.
Как отличить nightly от стабильного релиза при установке
Стабильная версия выглядит как обычный семантический номер вроде 0.x.y. Ночные сборки помечают датой или привязкой к коммиту, поэтому их легко узнать по суффиксу. Ставятся они из отдельного канала: отдельный pip-индекс либо отдельный Docker-образ nightly. Точные имена индексов, теги образов и команды установки берите из официальной документации vLLM, а не из сторонних постов.
В рабочем проекте фиксируйте конкретную сборку: точную версию в requirements или digest Docker-образа вместо плавающего тега. Так обновление не приедет само в момент, когда вы правите что-то другое.
Риски nightly-сборок и как их снизить
Основные риски: регрессии в работе движка, нестабильный API и переименование аргументов запуска, падения на нетипичных конфигурациях, отсутствие гарантий поддержки, изменение поведения между двумя соседними сборками. Функция, доступная сегодня, к следующей сборке может обзавестись новыми ограничениями.
Меры простые и работают в большинстве случаев:
- Отдельное виртуальное окружение или контейнер, изолированные от рабочей установки.
- Жёсткая фиксация версии и digest образа.
- Тестовый стенд с вашей моделью и типичными промптами перед переносом на основную машину.
- Готовый путь отката на стабильный релиз: сохранённые requirements, старый образ, скрипт запуска.
Для продакшена нужен стабильный релиз. Nightly остаётся каналом для экспериментов и проверки новых возможностей.
Как проверить, что PLE disk offload есть в вашей сборке
Проверка занимает несколько шагов и не требует чтения Reddit.
- Документация vLLM: разделы про поддерживаемые модели, аргументы движка и работу с памятью.
- Release notes и changelog: там изменения фиксируются по версиям и сборкам.
- Исходный код на GitHub: поиск по ключевым словам PLE, per-layer и offload покажет, есть ли соответствующие модули и аргументы.
- Issues и пул-реквесты репозитория: обсуждение реализации обычно идёт там, а не на форумах.
- Справка по аргументам запуска в вашей версии: список параметров движка отражает то, что реально поддерживается в этой сборке.
Если в документации функции нет, а в коде она присутствует, ориентируйтесь на код и на комментарии авторов в пул-реквесте. Обсуждение на Reddit полезно как сигнал, но не как источник истины: скриншот или короткий пост не заменяют changelog.
Итог: стоит ли пробовать PLE disk offload
Функция интересна узкой группе: тем, кто упирается в VRAM при запуске моделей с послойными эмбеддингами. Она даёт шанс запустить модель, которая иначе не помещается, и платить за это придётся латентностью и зависимостью от скорости накопителя. Это nightly-возможность без опубликованных бенчмарков, поэтому ждать от неё предсказуемой производительности в проде не стоит.
В материале нет собственных замеров: AI-Manual не запускал сборку с этой функцией, оценки механики даны по общим принципам работы памяти и инференса. Детали реализации проверяйте по официальной документации и коду vLLM.
Практические шаги:
- Проверьте в документации и коде vLLM, есть ли PLE disk offload в вашей сборке и какие аргументы запуска он использует.
- Посчитайте бюджет памяти: веса плюс KV-cache на нужной длине контекста, и сравните с объёмом VRAM.
- Поднимите nightly в отдельном контейнере или окружении, зафиксируйте версию или digest образа.
- Прогоните свою модель на своих промптах и решите, приемлема ли задержка на дисковых обращениях.
- Оставьте рабочую установку на стабильном релизе, пока nightly не покажет ожидаемое поведение.