Native VMM usage and support

Optional execution-slot backing reclaim

DynamicOffloadConfig(vmm_execution_backing_reclaim=True) enables the experimental Windows DXGI policy only on vmm_fast_runtime. The default is False; DDO-owned environment configuration also recognizes DDO_VMM_EXECUTION_BACKING_RECLAIM=1. The standard backend build_config_from_args path honors this override for vmm/auto as well; explicit build_config overrides remain authoritative. An explicitly enabled policy requires a compatible allocator and native execution slots. Linux refuses automatic enablement because DXGI is Windows-specific. No equivalent Linux pressure policy or cross-platform performance is implied.

Before new Torch backing, native code may release at most one completed idle execution slot when reported local budget headroom is below the requested bytes plus 256 MiB. This margin is experimental. The virtual address remains reserved; the next slot acquisition recreates physical backing and the normal upload path reloads the weights. Leased/prefetched slots and pending consumers remain protected. Completion or partial release failures retain unsafe ownership and refuse reuse and close. There is no activation eviction, compression, retry or forced cleanup.

Explicit native release/recreation is shared by Windows and Linux; this does not enable a Linux automatic pressure policy. The local rc3 Linux wheel has selected WSL explicit-reclaim and Linux/WSL image functional validation, with automatic reclaim disabled. These image runs do not validate the Windows DXGI trigger or establish a speed improvement. Earlier isolated Windows evidence does not certify a different release artifact. See selected validation and metrics and collection controls. Capacity counters do not prove physical local-VRAM placement.

linear/auto remains the default portable PyTorch route. Choose native VMM explicitly; it is not silently enabled by a model class or platform.

Host selection	Route
--ddo-backend linear --ddo-preset auto	Existing one_shot_fast
--ddo-backend vmm --ddo-preset auto	Experimental vmm_fast_runtime
--ddo-backend vmm --ddo-preset nvme_baseline	Protected vmm_runtime

Installation and lifecycle

Install a matching platform allocator/DDO wheel pair using the installation guide. Native wheels provide the DLL/.so; an editable source install alone does not compile or supply it.

Maintainers can initialize the pinned allocator submodule and build a reviewed library using the build guide. Development extras .[vmm-dev] and .[vmm-dev-linux] are optional maintainer tools, not ordinary installation requirements.

Bootstrap can discover a conventional checkout build or the packaged binary: ddo_vmm_allocator/native/win32/ddo_vmm.dll or ddo_vmm_allocator/native/linux/libddo_vmm.so. A compatible packaged installation requires no manual library path. Explicit library_path takes precedence over DDO_VMM_LIBRARY_PATH, which takes precedence over automatic discovery. These are development/diagnostic overrides, not normal end-user requirements. Missing/invalid binaries fail clearly; no runtime compilation/download, build-directory scan or silent switch to an experimental binary is performed. Discovery imports neither Torch nor the allocator package in the parent. The child receives the resolved library path so bootstrap and DDO use the same artifact.

The runner must bootstrap before any CUDA-owning imports:

from ddo_vmm_bootstrap import ensure_vmm_fast_process, vmm_fast_requested

if vmm_fast_requested():
    ensure_vmm_fast_process()

# Only now import Torch, Diffusers and the application pipeline.

Then add DDO's standard arguments, resolve the route and pass its configuration. For native weights, load with from_pretrained_with_dynamic_offload(..., apply_dynamic=False) before enable_offload(...), so DDO can associate immutable checkpoint slices. The host provides the model loader and pipeline phases; DDO/native code owns descriptors, source bytes, transfers, events and cleanup. The checkpoint must stay immutable throughout execution.

Active GPU capacity, retained host storage and CUDA registration have separate ceilings. A virtual address reservation is not physical VRAM consumption. The benchmark used full-source coverage; smaller host capacity can introduce rereads or fallback and does not promise the same throughput. VMM capacity profiles are observations, not Python residency calibration.

Generic hosts can pass --ddo-vmm-source-cache-gb for retained storage and --ddo-vmm-source-registered-gb for the separate registration ceiling through add_dynamic_offload_arguments() / build_config_from_args(). Registration zero retains the existing storage-ceiling default. Values are GiB; explicit registration must fit retained storage and whole native segments. Adding this argument does not alter the selected benchmark's capacities or native policy.

Phase-staged execution

For tight memory, encode/read back outputs, collect the component's completed metrics and unload/delete its model and pipeline references before loading transformer weights. Decode after transformer outputs are consumed and native cleanup completes. Cleanup belongs in finally; preserve the original forward error if cleanup also fails. No per-step global synchronization is required. Native unload invalidates weights to meta placeholders; reload before reuse.

An attached DDO result offers an error-only boundary:

with result.cleanup_on_error():
    output = run_component(result.module)
    report = result.metrics_snapshot(collect_completed=True)
# Successful-path unload remains explicit at the application's phase boundary.

Success performs no automatic unload/wait. On an exception or interruption, DDO attempts the existing hook cleanup once and re-raises the original error; a second cleanup error is attached as a diagnostic. Failed native retirement retains ownership rather than force-releasing it. This boundary does not cover attachment before the result exists, nor promise poisoned-driver recovery. The host wrapper is CPU-tested; no new CUDA/performance run has been made for it.

Generic full-pipeline linear/compatibility examples do not prove simultaneous native encoder and transformer fit the configured ceilings. Native whole-component ownership is opt-in; supported immutable tensors, bounded buffers and shared aliases must pass preflight. Quantized/custom forwards normally remain on compatibility routes. The explicit, model-agnostic saved TorchAO recipe is the bounded experimental FP8 exception, not automatic support for all quantized tensors. Do not replace backend math with dense Linear execution.

Public reporting

import json

report = result.metrics_snapshot(collect_completed=True)
if args.show_profile:
    print(report.format_profile())
if args.show_metrics:
    print(json.dumps(report.as_dict(), indent=2))
# Pass report.as_dict() to the application's normal JSON writer.

Completion collection retires finished source tickets; it is not module unload or a per-step synchronization. Hosts consume this versioned object, not hook state/native attribute names. The sibling tracker accepts tracker.record_ddo_metrics(report, component="transformer"). See the metric catalog for units, collection points and diagnostics.

Support and validation

Selected Windows, native-Linux and WSL workloads are documented in support and validation. Installed allocator smoke tests are separate from full-model validation.

Multi-GPU, concurrent forwards/unload, unmanaged streams, hidden escaping weight views, arbitrary compiled forwards and poisoned-driver recovery are not established by selected acceptance. Windows standby purge is optional and safely no-ops elsewhere.

Model recipes and comparisons belong to DDO examples. For another model/environment, use the manual checklist.

At a completed phase, the optional PyTorch host-cache helper can release unused pinned blocks. It defaults to disabled and never clears native source storage or changes admission; it is not a general performance guarantee.