# Pinned memory для GPU: бюджет закреплённой памяти хоста

Как ограничить pinned host memory для GPU: живые буферы, стоимость закрепления, давление на RAM, NUMA и проверка повторного использования.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/gpu-pinned-host-memory-budget/
Language: ru

## Понять назначение закрепления

Pinned, или page-locked, память хоста используется для передачи данных между CPU и GPU. Это RAM сервера, а не дополнительная VRAM. [CUDA Best Practices Guide](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html) объясняет преимущества и ограничения закреплённых буферов, включая стоимость выделения и опасность чрезмерного использования. Поэтому совет «закрепить всю доступную память» плохо описывает рабочий inference-процесс. Следует определить, какие данные действительно участвуют в передачах, как долго они живут и когда могут использоваться повторно. Большой объём свободной RAM до старта ещё не означает, что такой же объём можно безопасно удерживать закреплённым после запуска остальных процессов и загрузки модели.

## Составить бюджет живых буферов

Практический артефакт — таблица владельцев: входные staging-буферы, выходные буферы, число одновременно обслуживаемых операций и запас для служебных структур. Для каждого владельца записывают размер, максимальное количество и событие освобождения. Общий верхний предел рассчитывают из одновременно живых объектов, а не из суммарного объёма данных за день. Если буфер используется повторно, его нельзя считать новым выделением на каждую генерацию. И наоборот, пул без ограничения может постепенно вырасти до максимальной исторической нагрузки. План должен включать политику отказа или ожидания при исчерпании бюджета, чтобы давление не переносилось незаметно на всю память хоста.

## Отделить выделение от передачи

Измерение одной короткой операции может показать высокую стоимость закрепления вместо скорости копирования. Поэтому сравнивают полный цикл приложения и отдельную передачу из уже подготовленного буфера. В контрольном опыте удерживают одинаковые размеры, направление передачи и число одновременно активных операций. Записывают время выделения, время использования и момент безопасного повторного применения. Не следует освобождать или перезаписывать память до завершения зависимой операции. Если reusable pool улучшает время копирования, но увеличивает остаточную память, это явный компромисс, который должен отражаться в отчёте. Одного среднего bandwidth недостаточно для решения о размере пула или количестве рабочих процессов.

## Учитывать размещение на NUMA

В многосокетном сервере расположение CPU, GPU и памяти влияет на исследуемый путь. [Политики памяти NUMA в Linux](https://docs.kernel.org/admin-guide/mm/numa_memory_policy.html) описывают области действия и варианты размещения; сам факт закрепления не заменяет инвентаризацию топологии. Сначала фиксируют affinity процесса и доступные NUMA nodes, затем проверяют фактическое размещение выбранных буферов доступными средствами системы. Диагностическая развилка: если локальный подготовленный буфер стабилен, а общий пул даёт разброс, исследуют конкуренцию и размещение. Нельзя автоматически приписывать разницу CUDA или считать одну политику оптимальной для любой машины. Изменять несколько политик вместе опасно для объяснимости результата, даже если итоговый прогон быстрее.

## Проверить влияние на весь сервер

Ограниченный тест постепенно меняет только размер пула и сохраняет показатели RAM, задержки приложения, ошибок выделения и фоновой работы. Останавливаются при заранее определённом ухудшении состояния, не доводя систему до исчерпания памяти ради последней точки графика. Контекст дают [memory-optimized hosting](/ru/journal/memory-optimized-hosting/) и [сервер с 128 GB RAM](/ru/journal/server-128gb-ram-llm/). Вывод относится к исследованному workload и конфигурации. Более быстрый отдельный transfer не доказывает ускорения всего inference, а отсутствие ошибок в коротком опыте не устанавливает универсальный безопасный процент закрепления. Итоговый бюджет должен оставлять измеримый запас хосту и описывать механизм ограничения живых буферов.