# BAR1 and VRAM: why GPU memory readings differ

Separate GPU BAR1 mappings from framebuffer allocations. Diagnose the failed operation with matching units and scope instead of adding two unrelated free-memory values.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/gpu-bar1-vs-framebuffer/
Language: en

## Two views of device memory

BAR1 and framebuffer memory appear near each other in GPU management reports, which makes them easy to mistake for two pools available to a model. They describe different things. Adding their free values produces a capacity figure that does not represent the space in which an inference engine can allocate its weights and runtime state.

The [nvidia-smi documentation](https://docs.nvidia.com/deploy/nvidia-smi/index.html) describes BAR1 as a mapping used for access to device memory by the CPU or other PCIe devices. Framebuffer reporting describes device-memory capacity and usage. Start a memory investigation by naming the view being read rather than labeling every number VRAM.

## Identify the actual failing operation

Distinguish loading weights, allocating a runtime buffer, mapping memory for another device and transferring data. A failure in one operation does not automatically implicate every memory field. Retain the original error text and the relevant engine or driver context before comparing the management snapshots.

The [NVML query reference](https://docs.nvidia.com/deploy/nvml-api/latest/api/group__nvmlDeviceQueries.html) exposes separate memory queries and documents reporting details and support. Preserve which API and structure version produced the observation. Reserved memory, operating-system management and partition scope can affect interpretation; an exporter should not silently rename an unsupported or differently scoped field into a common total.

## Use a paired observation

Take a bounded sequence before model loading, after loading and during the failing workload. Keep GPU identity, process identity and timestamps alongside framebuffer and BAR1 values. Include query status and units. Avoid combining MiB from a command display with raw byte values from an API without a declared conversion.

Imagine a hypothetical record where framebuffer free memory decreases after weights load while BAR1 usage changes only slightly. That does not show that the missing framebuffer space is hidden in BAR1. The measurements describe allocation and mapping from different perspectives. Interpret the operation that actually failed before proposing a capacity change.

## Keep configuration questions separate

The size of a mapped resource window and the amount currently mapped are separate observations. A platform capability or firmware setting also does not show that the application exercised a particular path. Resource assignment belongs in a platform inventory; mapping usage belongs in a runtime observation.

Do not use BAR1 free space as an automatic recommendation for model size. Likewise, a larger mapped aperture does not create additional physical VRAM. Check the workload's allocation budget and the specific transfer or mapping requirement independently, then connect the evidence only where the software path justifies it.

## Produce a memory-view table

A useful report has one row per field, with its meaning, unit, scope, support status and the operation it helps examine. Add the observed changes across the same workload interval. This small table prevents a misleading combined-memory headline and directs investigation toward either an allocation problem, a mapping problem or missing evidence rather than a guessed hardware limitation.

## Related reading

- [RAM and VRAM: which memory matters for an AI server?](/journal/ram-vs-vram/)
- [CUDA OOM Allocated vs Reserved: Read the Evidence](/journal/cuda-oom-reserved-vs-allocated/)