В этом материале
KV Block Manager как иерархия памяти: перемещение блоков, закреплённая RAM, задержка хранилища и ограничения интеграции конкретной версии.
Dynamo KV Block Manager, или KVBM, управляет состоянием инференса в иерархии, а не превращает все доступные байты в единый пул. Блоки в памяти GPU, оперативной памяти и хранилище имеют разные задержки доступа и сроки жизни. Планирование требует большего, чем сложение заявленных ёмкостей устройств: запросу нужно получить конкретное совместимое состояние вовремя.
Нарисуйте жизненный цикл блока
Обзор KVBM описывает выделение и управление KV-блоками на неоднородных ресурсах. Для конкретного развёртывания проследите выделение, завершение вычисления, удержание, выгрузку, загрузку и вытеснение. Укажите принимающий решение компонент и процесс, владеющий данными на каждом этапе.
Запрос, которому блок нужен сейчас, не может воспользоваться абстрактной общей ёмкостью. Совместимое состояние должно прибыть до исчерпания бюджета задержки. Отдельно отмечайте данные, ожидающие переноса, и уже размещённые данные, готовые для использования исполняющим воркером без дополнительного ожидания.
Выделите бюджет каждому уровню
Фиксированный справочник Dynamo v1.5.0 различает настройки уровней, включая RAM и хранилище. Используйте его как описание определённой версии, а не доказательство включения или пригодности всех уровней в любой последующей установке.
Оставьте запас оперативной памяти для движка, ОС, буферов и соседних процессов. Закреплённая память имеет эксплуатационные последствия помимо размера. Большая ёмкость диска не оправдывает слишком маленькую или перегруженную промежуточную RAM, если фактический путь передачи требует прохода данных через этот уровень.
Измерьте путь между уровнями
Проверьте маршрут передачи выбранного оборудования и коннектора. Запускайте тест вместе с инференсом и предполагаемым количеством воркеров. Изолированный тест хранилища не показывает конкуренцию с копированием GPU, согласованием рангов и одновременной загрузкой других блоков.
Записывайте запрошенные и реально переданные байты, задержку загрузки и давление вытеснения. Включите документ, блоки которого находятся на разных уровнях. Единственная отметка «попадание в кэш» скрывает цену восстановления пригодного состояния. Ёмкость хранения и время доступа должны оставаться разными столбцами отчёта даже при удачной общей средней задержке.
Не складывайте независимые рецепты
Документация собственного offload vLLM в Dynamo описывает другой путь интеграции. KVBM, механизм самого движка и внешний коннектор кэширования не являются взаимозаменяемыми переключателями, которые автоматически складываются ради увеличения общей ёмкости.
Зафиксируйте выбранный менеджер и поддерживаемое сочетание backend. Подтвердите владельца удержания, передачи и регистрации блоков. Когда два компонента независимо считают себя управляющими одним жизненным циклом, конфигурация может успешно стартовать, но вести себя непредсказуемо при заполнении памяти или после перезапуска воркера.
Проверьте иерархию при вытеснении
Возьмите нагрузку со стабильным горячим набором, одноразовыми проходами и всплесками повторных длинных контекстов. Наблюдайте сохранность горячих блоков после большого прохода. В контролируемой среде перезапустите воркер и временно уберите доступ к необязательному уровню хранения.
Измеряйте полезные завершения запросов и хвост первого токена, а не только удержанные байты. Определите переход к обычному вычислению при недоступном состоянии и политику хранения каждого уровня. Диск и объектное хранилище означают постоянную обработку данных: их нельзя случайно включать там, где политика разрешает только временное использование памяти.
Материалы по теме
Pinned memory для GPU: бюджет закреплённой памяти хоста, KV-кеш и экономика GPU: зачем считать память активных запросов.