﻿# Dynamo KVBM: отдельные бюджеты GPU, RAM и хранилища

KV Block Manager как иерархия памяти: перемещение блоков, закреплённая RAM, задержка хранилища и ограничения интеграции конкретной версии.

Автор: Команда Retrivium
Обновлено: 2026-11-03
Канонический URL: https://retrivium.ai/ru/journal/dynamo-kvbm-memory-tiers/
Language: ru

Dynamo KV Block Manager, или KVBM, управляет состоянием инференса в иерархии, а не превращает все доступные байты в единый пул. Блоки в памяти GPU, оперативной памяти и хранилище имеют разные задержки доступа и сроки жизни. Планирование требует большего, чем сложение заявленных ёмкостей устройств: запросу нужно получить конкретное совместимое состояние вовремя.

## Нарисуйте жизненный цикл блока

[Обзор KVBM](https://docs.dynamo.nvidia.com/dynamo/components/kvbm) описывает выделение и управление KV-блоками на неоднородных ресурсах. Для конкретного развёртывания проследите выделение, завершение вычисления, удержание, выгрузку, загрузку и вытеснение. Укажите принимающий решение компонент и процесс, владеющий данными на каждом этапе.

Запрос, которому блок нужен сейчас, не может воспользоваться абстрактной общей ёмкостью. Совместимое состояние должно прибыть до исчерпания бюджета задержки. Отдельно отмечайте данные, ожидающие переноса, и уже размещённые данные, готовые для использования исполняющим воркером без дополнительного ожидания.

## Выделите бюджет каждому уровню

Фиксированный [справочник Dynamo v1.5.0](https://docs.nvidia.com/dynamo/v1.5.0/reference/components/kvbm-configuration) различает настройки уровней, включая RAM и хранилище. Используйте его как описание определённой версии, а не доказательство включения или пригодности всех уровней в любой последующей установке.

Оставьте запас оперативной памяти для движка, ОС, буферов и соседних процессов. Закреплённая память имеет эксплуатационные последствия помимо размера. Большая ёмкость диска не оправдывает слишком маленькую или перегруженную промежуточную RAM, если фактический путь передачи требует прохода данных через этот уровень.

## Измерьте путь между уровнями

Проверьте маршрут передачи выбранного оборудования и коннектора. Запускайте тест вместе с инференсом и предполагаемым количеством воркеров. Изолированный тест хранилища не показывает конкуренцию с копированием GPU, согласованием рангов и одновременной загрузкой других блоков.

Записывайте запрошенные и реально переданные байты, задержку загрузки и давление вытеснения. Включите документ, блоки которого находятся на разных уровнях. Единственная отметка «попадание в кэш» скрывает цену восстановления пригодного состояния. Ёмкость хранения и время доступа должны оставаться разными столбцами отчёта даже при удачной общей средней задержке.

## Не складывайте независимые рецепты

[Документация собственного offload vLLM в Dynamo](https://docs.nvidia.com/dynamo/latest/knowledge-base/modular-components/backends/v-llm/native-kv-offloading) описывает другой путь интеграции. KVBM, механизм самого движка и внешний коннектор кэширования не являются взаимозаменяемыми переключателями, которые автоматически складываются ради увеличения общей ёмкости.

Зафиксируйте выбранный менеджер и поддерживаемое сочетание backend. Подтвердите владельца удержания, передачи и регистрации блоков. Когда два компонента независимо считают себя управляющими одним жизненным циклом, конфигурация может успешно стартовать, но вести себя непредсказуемо при заполнении памяти или после перезапуска воркера.

## Проверьте иерархию при вытеснении

Возьмите нагрузку со стабильным горячим набором, одноразовыми проходами и всплесками повторных длинных контекстов. Наблюдайте сохранность горячих блоков после большого прохода. В контролируемой среде перезапустите воркер и временно уберите доступ к необязательному уровню хранения.

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

## Материалы по теме

[Pinned memory для GPU: бюджет закреплённой памяти хоста](/ru/journal/gpu-pinned-host-memory-budget/), [KV-кеш и экономика GPU: зачем считать память активных запросов](/ru/journal/kv-cache-economics/).
