How Do I Render Heavy Volumetric VDB Sequences Without Choking My GPU?

How do I render heavy volumetric VDB sequences? A VDB sequence is a large volume file on every single frame, so the render reloads gigabytes of voxel data per frame and the card and disk both have to keep pace. It chokes when a heavy frame’s VDB exceeds VRAM, or when the disk cannot stream the files fast enough. The fixes that work: lower voxel resolution and tighten the narrow band on parts the camera does not inspect, clip each VDB to the camera frustum, delete fields you do not render, enable out of core so an oversized frame spills into system RAM, and stream the sequence from fast storage. VDB is already a sparse format, so the lever is voxel size and band width, not switching sparse on.

A single smoke VDB can be a couple of gigabytes. A sequence is that, times hundreds of frames, and the render has to load a fresh fat file for every one of them. That is the part that catches people out. A still frame renders fine in lookdev, then the full sequence drags or crashes, because rendering one VDB and streaming three hundred of them are not the same load on the machine.

Why a Sequence Chokes When a Single Frame Was Fine

Two pressures stack on a VDB sequence. The first is VRAM: each frame loads its volume into the card, and the heaviest frames in the sequence, the peak of the explosion, the densest smoke, can need far more memory than the calm frames you tested. The second is disk throughput, since the renderer has to read a large file per frame, and a slow drive turns into the bottleneck while the GPU sits waiting. A sequence that averages fine can still choke on its few heaviest frames or stall on a slow disk.

On one shot, a smoke VDB sequence averaged about 1.8 GB per frame on disk, and the densest frame peaked around 21 GB of VRAM. On a 16 GB card that frame choked while the lighter ones rendered. On a 24 GB card with out of core enabled it held, and reading from an NVMe drive kept the GPU fed instead of waiting on disk.

What chokes the sequence	What to do
Heaviest frames exceed VRAM	Lower voxel resolution and narrow band where the camera does not look, enable out of core
Off screen volume rendered	Clip each VDB to the camera frustum
Unused fields stored per frame	Delete velocity, temperature, fuel if not rendered
Disk too slow to stream	Render from NVMe or fast local storage, not a network drive

Optimise the Volume, Not the Format

The biggest wins are on the volume itself, and the mechanics of why volumes balloon are in our why dense volumetrics eat VRAM guide. Raise voxel size on background and mid ground volumes, tighten the narrow band and dilation in regions the camera never inspects, and clip to the frustum so you never pay for smoke off screen. One thing not to waste time on: VDB is already a sparse format, so empty space already costs almost nothing, and there is no sparse switch to flip for free memory. The real levers are resolution and band width.

When the Sequence Still Needs More

If the heaviest frames still exceed your card after optimising, out of core lets them spill into system RAM, which is where a large RAM pool earns its place on volume work. iRender pairs the 24 GB RTX 4090 with 256 GB of system RAM for exactly that paging, and renders from fast NVMe so the stream keeps up. The cost specific to VDB sequences: they are enormous on disk, often hundreds of gigabytes across the whole sequence, so the upload is a real part of the schedule, and you should start it well before you need frames back. How transfers and pricing work is in our iRender explainer, and CPU farms that sidestep VRAM are in the comparison.

Heavy VDB sequence choking your card or your disk?
Render it on a 24 GB + 256 GB RAM NVMe server at iRender →

---

Frequently Asked Questions

Why does my VDB sequence choke my GPU when a single frame renders fine?

Because a sequence loads a large volume file every frame, and the heaviest frames, like the peak of an explosion, can need far more VRAM than the calm frame you tested. The disk also has to stream a big file per frame, which can stall the GPU if it is slow. A sequence that averages fine still chokes on its densest frames or on a slow drive.

How do I reduce VRAM use on a VDB volume sequence?

Lower voxel resolution and tighten the narrow band on parts the camera does not inspect, clip each VDB to the camera frustum, and delete fields you do not render like velocity or temperature. Enable out of core so the heaviest frames spill into system RAM. VDB is already sparse, so the levers are voxel size and band width, not turning sparse on.

Does storage speed matter when rendering VDB sequences?

Yes, more than people expect. The renderer reads a large VDB file per frame, so a slow drive becomes the bottleneck while the GPU waits for data. Rendering a heavy sequence from fast NVMe or local storage rather than a network drive keeps the card fed. On a slow disk, even a card with plenty of VRAM stalls between frames.

See more: Why Do Dense Volumetrics Eat All My VRAM in VFX Renders?