В этом материале
Закреплённая память — ограниченный ресурс хоста; её объём задают по одновременно живым буферам и проверяют вместе с памятью системы.
Понять назначение закрепления
Pinned, или page-locked, память хоста используется для передачи данных между CPU и GPU. Это RAM сервера, а не дополнительная VRAM. CUDA Best Practices Guide объясняет преимущества и ограничения закреплённых буферов, включая стоимость выделения и опасность чрезмерного использования. Поэтому совет «закрепить всю доступную память» плохо описывает рабочий inference-процесс. Следует определить, какие данные действительно участвуют в передачах, как долго они живут и когда могут использоваться повторно. Большой объём свободной RAM до старта ещё не означает, что такой же объём можно безопасно удерживать закреплённым после запуска остальных процессов и загрузки модели.
Составить бюджет живых буферов
Практический артефакт — таблица владельцев: входные staging-буферы, выходные буферы, число одновременно обслуживаемых операций и запас для служебных структур. Для каждого владельца записывают размер, максимальное количество и событие освобождения. Общий верхний предел рассчитывают из одновременно живых объектов, а не из суммарного объёма данных за день. Если буфер используется повторно, его нельзя считать новым выделением на каждую генерацию. И наоборот, пул без ограничения может постепенно вырасти до максимальной исторической нагрузки. План должен включать политику отказа или ожидания при исчерпании бюджета, чтобы давление не переносилось незаметно на всю память хоста.
Отделить выделение от передачи
Измерение одной короткой операции может показать высокую стоимость закрепления вместо скорости копирования. Поэтому сравнивают полный цикл приложения и отдельную передачу из уже подготовленного буфера. В контрольном опыте удерживают одинаковые размеры, направление передачи и число одновременно активных операций. Записывают время выделения, время использования и момент безопасного повторного применения. Не следует освобождать или перезаписывать память до завершения зависимой операции. Если reusable pool улучшает время копирования, но увеличивает остаточную память, это явный компромисс, который должен отражаться в отчёте. Одного среднего bandwidth недостаточно для решения о размере пула или количестве рабочих процессов.
Учитывать размещение на NUMA
В многосокетном сервере расположение CPU, GPU и памяти влияет на исследуемый путь. Политики памяти NUMA в Linux описывают области действия и варианты размещения; сам факт закрепления не заменяет инвентаризацию топологии. Сначала фиксируют affinity процесса и доступные NUMA nodes, затем проверяют фактическое размещение выбранных буферов доступными средствами системы. Диагностическая развилка: если локальный подготовленный буфер стабилен, а общий пул даёт разброс, исследуют конкуренцию и размещение. Нельзя автоматически приписывать разницу CUDA или считать одну политику оптимальной для любой машины. Изменять несколько политик вместе опасно для объяснимости результата, даже если итоговый прогон быстрее.
Проверить влияние на весь сервер
Ограниченный тест постепенно меняет только размер пула и сохраняет показатели RAM, задержки приложения, ошибок выделения и фоновой работы. Останавливаются при заранее определённом ухудшении состояния, не доводя систему до исчерпания памяти ради последней точки графика. Контекст дают memory-optimized hosting и сервер с 128 GB RAM. Вывод относится к исследованному workload и конфигурации. Более быстрый отдельный transfer не доказывает ускорения всего inference, а отсутствие ошибок в коротком опыте не устанавливает универсальный безопасный процент закрепления. Итоговый бюджет должен оставлять измеримый запас хосту и описывать механизм ограничения живых буферов.