# BAR1 и VRAM: почему показания памяти GPU различаются

Чем отображения BAR1 отличаются от framebuffer GPU и как исследовать отказ операции, не складывая разные показатели свободной памяти в вымышленную ёмкость.

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

## Два представления памяти устройства

BAR1 и framebuffer находятся рядом в отчётах управления GPU, поэтому их легко принять за два независимых пула памяти модели. Они описывают разные вещи. Если сложить их свободные значения, получится число, которое не соответствует пространству для размещения весов и рабочего состояния движка инференса.

В [документации nvidia-smi](https://docs.nvidia.com/deploy/nvidia-smi/index.html) BAR1 описывается как отображение для доступа CPU или других устройств PCIe к памяти GPU. Показатели framebuffer относятся к объёму и использованию памяти самого устройства. Исследование памяти стоит начинать с названия конкретного представления, вместо общей подписи VRAM для любого числа в отчёте.

## Установите операцию, которая не удалась

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

[Справочник запросов NVML](https://docs.nvidia.com/deploy/nvml-api/latest/api/group__nvmlDeviceQueries.html) предоставляет отдельные запросы памяти и описывает детали отчётности и поддержки. Сохраняйте API и версию структуры, которыми получено наблюдение. Резервирование, управление памятью операционной системой и область раздела GPU влияют на трактовку. Экспортер не должен молча переименовывать неподдерживаемое поле или поле другой области в общий итог.

## Сделайте связанные наблюдения

Соберите ограниченную последовательность до загрузки модели, после неё и во время проблемной нагрузки. Рядом со значениями framebuffer и BAR1 сохраняйте устройство, процесс и временные отметки. Указывайте статус запросов и единицы. Нельзя объединять MiB из табличного вывода с байтами API без явно заданного преобразования.

Представим условную запись: после загрузки весов свободная framebuffer-память уменьшилась, а использование BAR1 изменилось незначительно. Это не означает, что исчезнувший объём framebuffer спрятан в BAR1. Показатели описывают выделение и отображение с разных сторон. До предложения увеличить ресурсы нужно понять именно ту операцию, которая завершилась ошибкой.

## Отделяйте конфигурацию от использования

Размер назначенного окна ресурсов и объём текущего отображения являются отдельными наблюдениями. Наличие возможности платформы или настройки прошивки также не показывает, что приложение использовало определённый путь. Назначение ресурсов относится к паспорту платформы, а использование отображения — к наблюдению во время работы.

Не используйте свободное BAR1 как автоматическую рекомендацию размера модели. Увеличенное окно отображения тоже не создаёт дополнительную физическую VRAM. Проверяйте бюджет выделения памяти нагрузки и конкретное требование передачи или отображения независимо. Связывать их следует только там, где программный путь действительно объясняет такую связь.

## Подготовьте таблицу представлений памяти

В полезном отчёте одна строка соответствует одному полю: смысл, единица, область, поддержка и операция, для исследования которой поле пригодно. Рядом нужны изменения за один и тот же интервал нагрузки. Такая таблица предотвращает ошибочный заголовок об общей памяти и направляет диагностику к выделению, отображению либо недостающим свидетельствам вместо догадки об ограничении оборудования.

## Связанные материалы

- [RAM и VRAM: какую память считать при выборе AI-сервера](/ru/journal/ram-vs-vram/)
- [Allocated и reserved в CUDA OOM: как читать сообщение](/ru/journal/cuda-oom-reserved-vs-allocated/)