AI Model Dynamic Offloader

This project is a pytorch VRAM allocator that implements on-demand offloading of model weights when the primary pytorch VRAM allocator comes under pressure.

Support:

• Nvidia GPUs (CUDA) and AMD GPUs (ROCm/HIP)
• PyTorch 2.8+
• CUDA 12.8+ (Nvidia) / ROCm 7+ (AMD)
• Windows 11+ / Linux as per python ManyLinux support

How it works:

• The pytorch application creates a Virtual Base Address Register (VBAR) for a model. Creating a VBAR doesn't cost any VRAM, only GPU virtual address space (which is pretty much free).
• The pytorch application allocates tensors for model weights within the VBAR. These tensors are initially un-allocated and will segfault if touched.
• The pytorch application faults in the tensors using the fault() API at the time the tensor is needed. This is where VRAM actually gets allocated.

If the fault() is successful (sufficient VRAM for this tensor):

1. If the fault() resultant signature is changed or unknown:
   • The application uses tensor::_copy() to populate the weight data on the GPU.
   • The application saves the returned signature against this weight for future comparison
2. The layer uses the weight tensor.
3. The application calls unpin() on the tensor to allow it to be freed under pressure later if needed.

If the fault() is unsuccessful (offloaded weight):

1. The application allocates a temporary regular GPU tensor.
2. Uses _copy to populate weight data on the GPU.
3. The layer uses the temporary as the weight.
4. Pytorch garbage collects the temp when the layer is finished.

see examples/example.py

Priorities:

• The most recent VBARs are the highest priority and lower addresses in the VBAR take priority over higher addresses.
• Applications should order their tensor allocations in the VBAR in load-priority order with the lowest addresses for the highest priority weights.
• Calling fault() on a weight that is higher priority than other weights will cause those lower priority weights to get freed to make space.
• Having a weight evicted sets that VBAR's watermark to that weight's level. Any weights in the same VBAR above the watermark automatically fail the fault() API. This avoids constantly faulting in all weights each model iteration while allowing the application to just blindly call fault() every layer and check the results. There is no need for the application to manage any VRAM quotas or watermarks.
• Existing VBARs can be pushed to top priority with the prioritize() API. This allows use of an already loaded or partially model (e.g. using the same model twice in a complex workflow). Using prioritize resets the offload watermark of that model to no offloading, giving its weights priority over any other currently loaded models.

Backend:

• VBAR allocation is done with cuMemAddressReserve(), faulting with cuMemCreate() and cuMemMap() and all frees done with appropriate converse APIs.
• For consistency with VBAR memory management, main pytorch allocator plugin is also implemented with cuMemAddressReserve -> cuMemCreate -> cuMemMap. This also behaves a lot better on Windows systems with System Memory fallback.

On AMD, the equivalent HIP APIs (hipMemAddressReserve -> hipMemCreate -> hipMemMap, and their converse calls) are used throughout via the same flow.

Dinkster native wheel channel

Dinkster publishes the Linux x86_64, Linux aarch64, Windows amd64, and Windows arm64 native wheels to PyPI and the matching GitHub Release. Install an exact release from PyPI with:

pip install dinkster-aimdo==0.5.5.post1

The distribution name is dinkster-aimdo; the Python import remains comfy_aimdo. Each GitHub Release also includes a JSON manifest that records the exact source commit and every native wheel's filename, platform tags, byte size, and SHA-256 hash. The pure-Python stub wheel is not part of this channel.

Caveats:

• There is no real way for this allocator to tell the difference between high usage and bad fragmentation in the pytorch caching allocator. As we always return success to the pytorch caching allocator it experiences no pressure while weights are being offloaded which means it can run in an extremely fragmented mode. The assumption is model weight access patterns are reasonably regular over blocks or iterations and it finds a good set of sizes to cache. What you should generally do though, is completely flush the pytorch caching allocator before each new model run, which avoids completely un-used reservations from taking priority over the next models weights.