Короткий ответ: 96 ГБ VRAM могут быть достаточны, но модель не перестаёт требовать память
Короткий ответ: 96 ГБ VRAM могут хватить для запуска MoE-модели с весами 186 ГБ, если движок хранит часть весов в host RAM и доставляет нужные экспертные блоки на GPU во время генерации. При одинаковом представлении весов разница составляет минимум 90 ГБ: этот объём не поместится в VRAM, даже если отдать под веса всю видеопамять.
LayerStoRm описывается как экспериментальный open-source inference-движок с подходом continuous expert streaming. Его идея не уменьшает модель и не отменяет требования к памяти. Она меняет место хранения экспертных весов и порядок их подачи на GPU. Для запуска нужны запас системной RAM, свободные ресурсы CPU, подходящая PCIe-топология и подтверждённая совместимость с конкретной картой, включая упоминаемую в описании проекта NVIDIA SM120.
Число 96 ГБ описывает доступный объём VRAM, а не полный бюджет памяти для модели. Точный результат зависит от формата весов, квантизации, длины контекста, batch size, числа запросов, версии движка и схемы размещения данных. Публичных проверяемых цифр LayerStoRm для разных стендов недостаточно, поэтому обещать конкретные tokens/s или TTFT для произвольной конфигурации нельзя.
Почему объём весов и требуемая VRAM - не одно и то же
Веса хранят параметры модели. Во время работы GPU нужны и другие области памяти, поэтому свободная VRAM быстро расходуется на несколько типов данных:
- Весовые тензоры. Это основной объём модели. У MoE большая часть экспертных весов может находиться вне GPU, если рантайм умеет доставлять нужные блоки во время вычислений.
- KV-cache. Кэш хранит ключи и значения для уже обработанных токенов. Его размер растёт вместе с контекстом, batch size и числом одновременных запросов.
- Временные буферы. GPU нужны рабочие области для матричных операций, копирования и промежуточных результатов.
- Служебные данные рантайма. Сюда входят метаданные, графы CUDA, очереди операций и внутренние буферы.
MoE создаёт предпосылку для экономии VRAM: маршрутизатор выбирает часть экспертных ветвей для текущего токена, а остальные эксперты не участвуют в этой конкретной операции. Их веса всё равно принадлежат модели и требуют места, но их не обязательно постоянно держать на GPU. Конкретная экономия зависит от архитектуры, маршрутизации и возможностей движка.
Похожую ошибку легко допустить при анализе обычного запуска LLM: размер файла весов принимают за полный объём VRAM. В разборе Qwen3.8-Flash-Next в llama.cpp отдельно обсуждаются VRAM, RAM, KV-cache и режимы загрузки. Эти наблюдения полезны как методика подсчёта, но показатели llama.cpp нельзя переносить на LayerStoRm.
Что означает формулировка «186 ГБ весов на 96 ГБ VRAM»
Такая формулировка описывает схему размещения, а не готовую аппаратную спецификацию. Если 186 ГБ и 96 ГБ относятся к одному представлению весов, а вся VRAM теоретически занята только ими, минимум 90 ГБ должны находиться вне GPU. В реальном запуске часть VRAM понадобится под KV-cache и рабочие буферы, поэтому эта разница не равна требуемому объёму RAM.
| Параметр | Что нужно уточнить | Почему это влияет на запуск |
|---|---|---|
| Формат весов | Тип данных и способ хранения | Размер файла и объём копий в памяти могут различаться |
| Квантизация | Точный вариант квантованных весов или отсутствие квантизации | Меняются требования к памяти и вычислениям |
| Host RAM | Полный объём и свободный запас | В RAM могут находиться веса, кэш, буферы и данные ОС |
| Контекст | Длина входа и размер KV-cache | Длинная сессия может исчерпать память независимо от размера весов |
| Нагрузка | Batch size и число параллельных запросов | Несколько потоков увеличивают расход памяти и конкуренцию за PCIe |
| Аппаратная схема | Число GPU, PCIe и NUMA-топология | Передача данных может стать главным ограничением |
Пока эти параметры не указаны, цифра 186 ГБ отвечает на вопрос о размере весов. Она не отвечает на вопросы о минимальной RAM, скорости генерации и стабильности работы.
Что такое LayerStoRm и почему здесь важен expert streaming
LayerStoRm в этом материале стоит воспринимать как экспериментальный open-source движок для проверки идеи запуска крупных MoE-моделей при ограниченной VRAM. Основной интерес представляет связка host RAM и потоковой доставки экспертных весов. Список поддерживаемых моделей, точные требования к драйверам, правила кэширования и методы предвыборки нужно сверять с актуальными материалами самого проекта.
MoE-модель: почему все эксперты не обязаны быть активны на каждом токене
Плотная модель использует один общий набор основных весов при обработке каждого токена. В MoE внутри отдельных блоков находятся экспертные подсети, а маршрутизатор выбирает, какие из них обработают конкретный вход.
За счёт этого совокупный размер модели может быть большим, а вычислительная работа для отдельного токена - меньше, чем у плотной модели с таким же числом параметров. Это не означает, что невыбранные эксперты исчезают из памяти. Они остаются частью набора весов и должны находиться на одном из уровней хранения: VRAM, host RAM или другом поддерживаемом носителе.
Для expert streaming важен именно разрыв между полным набором весов и активным набором текущего шага. Если маршрутизатор использует отдельные экспертные блоки, движок получает возможность работать с ограниченным GPU-набором, а остальные данные хранить вне VRAM. Точный эффект зависит от того, как LayerStoRm обрабатывает общие слои, экспертные слои и повторные обращения к одним и тем же экспертам.
Continuous expert streaming: подгрузка экспертов в ходе генерации
Continuous expert streaming можно описать как повторяющийся цикл доставки данных между host RAM и GPU. Рантайм не загружает весь набор экспертных весов в видеопамять перед началом работы, а старается подавать нужные блоки по мере вычислений.
- Маршрутизатор определяет путь обработки текущего токена.
- Движок находит весовые блоки, нужные для выбранных экспертных ветвей.
- Нужные данные передаются из host RAM в память GPU.
- GPU выполняет вычисления над загруженными блоками.
- Движок освобождает, сохраняет или повторно использует данные в зависимости от своей политики памяти.
Последовательность описывает принцип, а не гарантированную внутреннюю схему LayerStoRm. Предвыборка следующих экспертов, размер кэша, очередь копирования и возможность перекрыть передачу вычислениями требуют подтверждения в документации или коде проекта. Без таких данных нельзя приписывать движку конкретную стратегию планирования.
Главный компромисс виден сразу: GPU получает доступ к модели большего размера, но каждый промах по нужному экспертному набору может добавить ожидание. Скорость генерации начинает зависеть от памяти хоста и канала GPU-RAM, а не только от количества CUDA-ядер.
Expert streaming и обычный offload: похожая цель, разные ограничения
Offload: экономия VRAM ценой обращений к памяти вне GPU
При CPU offload часть данных модели размещается в оперативной памяти. Когда GPU доходит до операции, которой нужны эти данные, рантайм копирует их в видеопамять или выполняет отдельные операции на CPU. Если передача не перекрывается вычислениями, GPU ждёт.
Грубое разделение слоёв, перенос отдельных экспертных блоков и потоковая загрузка могут называться offload, хотя поведение у них различается. Поэтому одного флага CPU offload недостаточно для оценки скорости. Нужно знать, какие данные перемещаются, как часто это происходит и способен ли рантайм готовить следующую операцию заранее.
| Подход | Что находится вне VRAM | Когда происходит передача | Главный риск |
|---|---|---|---|
| Обычный offload | Слои или часть весов | При обращении к размещённым вне GPU данным | GPU простаивает во время копирования |
| Expert streaming | Часть экспертных весов | По мере смены активного экспертного набора | Задержка каждого шага зависит от RAM и PCIe |
| Полное размещение в VRAM | Минимум весов вне GPU | Главным образом при загрузке и обслуживании запросов | Модель и KV-cache могут не поместиться |
Что меняет потоковая работа именно с экспертами
Потоковый подход работает с более узкой частью модели. В идеальном сценарии GPU хранит общие компоненты и небольшой набор востребованных экспертов, а остальные экспертные веса остаются в host RAM. Это потенциально позволяет запускать модели, которые не помещаются в VRAM целиком.
Цена такой схемы связана с частотой обращений. Если соседние токены используют разные экспертные блоки, движку приходится чаще менять содержимое GPU-памяти. Если набор долго не меняется, часть передачи можно сократить за счёт кэша. Конкретное поведение зависит от маршрутизации и политики LayerStoRm.
Expert streaming не превращает PCIe в расширение VRAM с такой же задержкой. Host RAM и VRAM остаются разными уровнями памяти. Проект лишь пытается организовать обмен так, чтобы ограниченный GPU-ресурс обслуживал активную часть модели.
Когда streaming может проиграть локальному размещению весов
- Слабая или перегруженная PCIe-связь. Паспортной пропускной способности недостаточно, если линии делят несколько устройств или соединение работает уже не на заявленной ширине.
- Неудачная NUMA-топология. GPU может получать буферы через удалённый узел CPU и дополнительный межсокетный переход.
- Недостаток RAM. При давлении на память ОС начнёт вытеснять страницы, а задержки станут непредсказуемыми.
- Параллельные запросы. Несколько пользователей конкурируют за RAM, PCIe и кэш экспертных блоков.
- Большой KV-cache. Длинный контекст сокращает запас VRAM и RAM, который можно отдать под потоковую работу.
- Промахи кэша. Частая смена экспертных блоков увеличивает число передач и снижает стабильность decode.
Параллельная подготовка данных сама по себе не гарантирует ускорение. В отдельном инженерном тесте на файле размером 76,3 МБ восемь worker-потоков завершили задачу за 7,558 секунды, а один worker - за 6,535 секунды. Этот пример относится к другому инструменту и не даёт прогноза для LayerStoRm, но хорошо задаёт правило проверки: результат нужно измерять на реальной нагрузке, а число потоков не считать ускорением заранее.
Железо для LayerStoRm: RAM, PCIe и NUMA важнее красивой цифры VRAM
Для такой схемы нужно оценивать всю систему. Большой объём VRAM помогает, но не компенсирует слабый канал к host RAM, неправильное расположение памяти или нехватку свободного места под контекст.
Host RAM: где будут лежать веса и какой запас нужен рантайму
RAM нельзя рассчитывать как точную копию размера файла весов. В ней могут одновременно находиться часть или весь набор экспертных весов, буферы передачи, метаданные, страницы библиотек, данные операционной системы и состояние нескольких запросов.
Если движок держит полный набор весов за пределами VRAM, свободной RAM потребуется больше размера весового файла. Если он хранит только часть данных и подгружает остальное по другой схеме, требования меняются. Без документации LayerStoRm нельзя назвать корректный минимальный объём.
Механика mmap в других движках не делает данные бесплатными: она меняет способ доступа к файлу, но не устраняет требования к хранилищу, RAM и пропускной способности. Практическое распределение памяти между GPU, CPU и NVMe разобрано в материале о mmap в llama.cpp. Это отдельная технология, поэтому её поведение нельзя приписывать LayerStoRm.
- Оставьте запас RAM для ОС и фоновых процессов.
- Проверьте, не создаёт ли рантайм дополнительные копии весов при конвертации или передаче.
- Измерьте свободную память во время длинной генерации, а не сразу после запуска.
- Проверьте, как меняется расход RAM при двух и более параллельных запросах.
PCIe: почему скорость генерации упирается не только в GPU
GPU может быстро выполнять матричные операции и при этом выдавать низкий decode, если ждёт очередной экспертный блок из host RAM. В такой ситуации вычислительная мощность карты простаивает, а задержка появляется на пути передачи данных.
Перед тестом нужно выяснить поколение PCIe, фактическую ширину соединения, расположение GPU в слотах, общий root complex и устройства, которые делят линии или пропускную способность. Несколько GPU, сетевые карты, NVMe и другие ускорители могут конкурировать за тот же ресурс.
Паспортная скорость интерфейса не заменяет измерение. Для LayerStoRm важны устойчивые задержки небольших и средних передач, очередь копирования и возможность перекрывать обмен вычислением. В разборе сервера на двух Radeon показано, почему VRAM, KV-cache, PCIe и tiered expert offload нужно считать как одну систему. Аппаратные цифры из этого материала не относятся к LayerStoRm.
NUMA: лишняя дистанция между CPU, RAM и GPU становится задержкой
NUMA означает неравномерный доступ к памяти. В многосокетной системе каждый CPU имеет локальный узел RAM, а обращение к памяти другого узла проходит через межсокетное соединение.
Если GPU подключена к CPU0, а буфер с экспертными весами выделен в памяти CPU1, данные проходят лишний участок маршрута. Средняя задержка растёт, а разброс времени передачи становится заметнее. При постоянной загрузке это может проявиться как нестабильный tokens/s и скачки latency.
До запуска нужно зафиксировать соответствие GPU, CPU и NUMA-узлов, проверить локальность выделяемой RAM и убрать конкурирующую нагрузку. Конкретные команды диагностики стоит брать из документации к поддерживаемой ОС и версии LayerStoRm, поскольку набор требований к драйверу и стеку пока не подтверждён.
Упоминание NVIDIA SM120 не заменяет проверки совместимости. Нужно сверить поддерживаемую архитектуру GPU, версию драйвера, CUDA-стек, ограничения по числу карт и известные проблемы в README, issues и release notes проекта.
Как читать заявленные tokens/s и TTFT без самообмана
Одна цифра скорости редко описывает опыт работы с потоковым inference. TTFT и скорость декодирования отвечают на разные вопросы, а холодный запуск и прогретая сессия дают разные результаты.
TTFT и скорость декодирования отвечают на разные вопросы
TTFT, time to first token, показывает время от отправки запроса до первого токена ответа. В него могут входить обработка prompt, подготовка графов, загрузка весов и ожидание первых передач, если методика включает холодный старт. Поэтому рядом с TTFT нужно указывать режим прогрева и точку начала отсчёта.
Tokens/s обычно описывает темп выдачи следующих токенов. Это метрика decode, а не время подготовки длинного prompt. Expert streaming может сильнее влиять на одну фазу, чем на другую: prefill и decode используют разные объёмы данных и создают разную нагрузку на шину. Факт нужно подтверждать отдельными замерами, а не переносить по аналогии.
Для интерактивного агентного кодинга высокий tokens/s не компенсирует слишком большой TTFT, если каждый шаг агента начинается новым запросом. Для длинной генерации, наоборот, пользователь сильнее замечает устойчивый decode и скачки latency.
Минимальный набор параметров для сопоставимого бенчмарка
| Группа | Что указать в отчёте |
|---|---|
| GPU | Модель, число карт, доступная VRAM, PCIe-поколение и ширина соединения |
| CPU и RAM | Модель CPU, объём и скорость RAM, NUMA-раскладка, занятая память |
| Программный стек | ОС, драйвер, CUDA или другой backend, версия и commit движка |
| Модель | Точное имя, вариант весов, формат, квантизация и активная конфигурация |
| Запрос | Длина входа, длина ответа, шаблон prompt и наличие инструментов |
| Нагрузка | Batch size, concurrency, число повторов и состояние прогрева |
| Метрики | TTFT, prefill tokens/s, decode tokens/s, среднее значение и разброс |
Отчёт без этих полей полезен как сигнал для дальнейшей проверки, но не как прогноз для другого стенда. В этой статье нет подтверждённых чисел производительности LayerStoRm, поэтому конкретные обещания по TTFT и tokens/s здесь отсутствуют.
Где LayerStoRm может быть полезен: агентный кодинг, длинный контекст и checkpointing
Агентный кодинг: когда размер модели важен, а latency всё ещё имеет значение
AI-агент для разработки делает серию вызовов: читает файлы, строит план, вызывает инструменты, анализирует результат и меняет код. Один запрос может содержать большой фрагмент репозитория, историю действий и инструкции для следующего шага.
Большая MoE-модель может быть интересна в таком сценарии благодаря качеству рассуждений и работе с кодом, но сам факт запуска ещё не делает систему удобной. Нужно измерять время первого ответа, устойчивый decode, задержки после вызовов инструментов и поведение при повторной загрузке экспертных блоков.
LayerStoRm потенциально полезен владельцу стенда, где GPU не хватает для полного размещения весов, но RAM и PCIe дают возможность принять обмен. Для ежедневной работы с агентом потребуется проверить серию запросов, а не один удачный прогон.
Длинный контекст и mid-prompt checkpointing: что нужно проверить отдельно
Потоковая загрузка экспертных весов не решает проблему KV-cache. При росте контекста кэш продолжает занимать память, а несколько параллельных диалогов увеличивают нагрузку ещё сильнее. В результате модель может запускаться на коротком prompt и упираться в RAM или VRAM на длинной сессии.
Mid-prompt checkpointing означает сохранение промежуточного состояния внутри длинной работы, чтобы продолжить её позже или не обрабатывать весь prompt заново. Для конкретного движка нужно проверить, что именно сохраняется: текст, KV-cache, экспертный кэш, состояние агента или комбинация этих данных.
- Совместим ли checkpoint с той же версией модели и весов.
- Хранится ли состояние в RAM, на диске или в другом слое.
- Сколько времени занимает сохранение и восстановление.
- Растёт ли потребление памяти при нескольких checkpoint.
- Сохраняется ли состояние после перезапуска процесса.
Поддержка mid-prompt checkpointing не следует автоматически из наличия expert streaming. Это отдельная функция, которую нужно подтвердить документацией и тестом. Для сравнения поведения MoE в streaming-стеке полезно посмотреть на различие prefill и decode в разборе Qwen3.8-Next на Mac, но его показатели нельзя переносить на NVIDIA SM120 или LayerStoRm.
Кому стоит пробовать LayerStoRm сейчас, а кому лучше подождать
LayerStoRm имеет практический смысл как экспериментальная площадка для владельцев мощных систем и разработчиков inference. Он особенно интересен тем, кому нужно изучить запуск крупной MoE-модели при ограниченной VRAM и кто готов самостоятельно разбираться с памятью, топологией и нестабильными режимами.
Перед запуском: короткий чек-лист верификации
- Проверьте официальный репозиторий, лицензию, README, актуальный release и известные ограничения.
- Уточните поддержку конкретной GPU, NVIDIA SM120, версии драйвера и вычислительного backend.
- Сверьте точный вариант модели, формат весов и квантизацию.
- Посчитайте свободную host RAM с запасом под ОС, рантайм, буферы, KV-cache и параллельные запросы.
- Зафиксируйте PCIe-поколение, ширину линий, root complex и конкурирующие устройства.
- Проверьте NUMA-связь между GPU, CPU и областью RAM, где будут находиться экспертные веса.
- Запишите версию движка, commit, настройки batch, контекст, concurrency и режим прогрева.
- Проведите отдельные тесты холодного старта, прогретого decode, длинного prompt и серии запросов.
- Снимите TTFT, prefill tokens/s, decode tokens/s, расход VRAM и RAM, ошибки передачи и скачки latency.
- Проверьте mid-prompt checkpointing отдельно, если эта функция заявлена для выбранной версии.
Для production-сервиса со строгим SLA, ограниченной RAM или слабой PCIe-полосой риск пока высок. В такой ситуации рациональнее выбрать модель, которая помещается в доступную память, и зрелый inference-стек с воспроизводимыми тестами.
Формула «186 ГБ весов на 96 ГБ VRAM» описывает возможность распределить данные между уровнями памяти. Она не обещает одинаковую скорость на любом железе и не отменяет требования к host RAM, PCIe, NUMA и KV-cache. LayerStoRm стоит пробовать как экспериментальный open-source проект после проверки совместимости и собственных бенчмарков, а не как универсальный способ запуска любой крупной MoE-модели.