Shared runner controls

Run commands from the examples root in the installed environment. Each runner's --help defines the options it supports; minimal and conventional controls expose only a subset. Shared options use the same spelling and meaning.

Execution

Custom blocks execute trusted Python code. Use sources you trust; a Hub revision does not change the HEAD of a local clone. Exact benchmark revisions belong in the model's reproduction recipe.

All public LTX image/video and Qwen entries use the shared vocabulary, including --ddo-preset and --custom-blocks where supported. The linear and SDNQ entries support --ddo-backend linear only. All three minimal entries use native --ddo-backend vmm --ddo-preset auto; their transformer uses DDO's source-aware loading and bootstrap before CUDA-owning imports. Qwen's conventional leaf control has no DDO backend/preset selectors. See the LTX image interface matrix for supported component and reporting controls. Diagnostic controls are kept out of these public commands. See the video interface matrix for video-specific sources, defaults and supported controls. Its native VMM entry uses the same DDO route/capacity and reclaim controls below; video capacities and staging defaults are listed in video parameters.

Public native image interface

All minimal entries select only vmm/auto. Their transformer capacity defaults come from DDO: 4 GiB active weights, 0.625 GiB total staging, zero retained-source cache and zero registration ceiling. These are configurable defaults, not the model benchmark recipes. Reclaim defaults to false and requires its positive switch. Encoders and decoders retain each minimal's existing component routes; the VMM selector refers to the transformer. Use the dedicated linear entries for linear/auto and other linear presets, and the full VMM entries for the protected NVMe route or additional model controls.

scripts/ltx2_image/run_dynamic_modular_vmm_distilled.py and scripts/qwen_image_21/run_dynamic_modular_vmm.py expose exactly the same seven DDO route/capacity and reclaim controls below. Model inputs, sampling and supported component options remain model-specific.

vmm/auto selects experimental native fast; vmm/nvme_baseline selects the protected NVMe runtime. This Qwen VMM entry requires backend vmm; use its linear entry for backend linear. The LTX entry also accepts backend linear, although the dedicated linear runner is the documented starting point. See runtime selection for the route mapping.

These preserve the existing capacities, not the published benchmark overrides. The model guides specify the measured capacities explicitly. Staging always means total host staging in GiB; it is not activation VRAM or total GPU memory. For the protected NVMe route, omitted staging preserves the existing two-slot defaults (LTX total 1.25 GiB; Qwen total 1.25 GiB). Source-cache options apply to the native fast route; do not treat them as NVMe controls.

LTX generation defaults are 1280×704, 8 steps, seed 43, guidance 1, guidance rescale 0.7 and no PAG. Qwen defaults are base, 1024×1024, 25 steps and seed 42; its 20-step benchmark recipe therefore keeps --steps 20 explicit. The public API selection is automatic. Workload calibration, native adapter selection, GPU timing and transport experiments belong in the diagnostic entries.

Reporting defaults remain LTX: full memory monitoring, metrics level 1, metrics display enabled and save disabled; Qwen: RSS, level 2, metrics display and save enabled. Separate profile display is off by default in both. Use the same explicit reporting settings for comparisons. Parameter availability does not establish GPU or performance acceptance.

Windows standby purge

Use the phase switches exposed by the selected runner: --purge-before-run, --purge-after-text-encoder, --purge-before-transformer and --purge-after-run. The corresponding --no-purge-... switch disables a phase.

Run elevated when requesting purge and check the reported result. Explicit switches take precedence over environment settings, then preset defaults. Omitting a switch means inherit, not universally enabled or disabled. The LTX image runner's default base settings and Qwen's VMM reporting helper both use one_shot_fast for lifecycle defaults. With an unmodified environment, both request purge before run, after text encoding and before the transformer; after-run purge is off. Keep the phase switches explicit in benchmark recipes and inspect the saved purge result rather than inferring success from a default. No administrator terminal is required when all purge phases are disabled. Outside Windows the helper is a safe no-op. Purge does not free live tensors or guarantee that native backing has returned to the driver.

Execution backing reclaim

The three public VMM entries accept --ddo-vmm-execution-backing-reclaim and --no-ddo-vmm-execution-backing-reclaim. The default is false: only the positive CLI switch enables it, even when DDO_VMM_EXECUTION_BACKING_RECLAIM=1 is inherited. Enabling requires --ddo-backend vmm --ddo-preset auto; linear, SDNQ and protected NVMe execution do not support this mechanism. Do not export the environment variable as shared setup for linear/SDNQ recipes.

Native execution buffers have stable virtual addresses and physical backing. Under pressure, the allocator can release eligible idle backing after the last consumer has completed. Buffers still leased or awaiting completion are protected. When needed again, backing is recreated and its contents materialized before the consumer can use it. This does not continuously release/recreate buffers: without pressure they can remain available for reuse.

The potential benefit is more available GPU memory for activations and less pressure from idle execution buffers. Recreating and materializing backing costs time, so a speed improvement depends on the workload and hardware. This is not tensor compression and does not increase the configured weight budget. An enabled setting with zero releases can be valid when pressure or eligible idle buffers are absent. Pool accounting does not prove local VRAM placement.

Diagnostics

GPU timing and native workload-profile selection remain diagnostic-entry options.

Persistent capacity profiles for linear runners

The BF16 modular linear entries for LTX image, LTX video and Qwen expose the same two controls: --ddo-profile NAME selects a saved profile; --build-ddo-profile --ddo-profile NAME creates one. Building requires a name and a linear DDO preset (auto, one_shot_fast, low_ram_safe, wsl_compat or warm_process). Minimal, native VMM and SDNQ public entries are unchanged. --show-profile only displays component measurements; it does not calibrate or select a persistent profile.

Calibration is real GPU inference with a zero resident-module budget. DDO measures the denoise memory peak and recommends a resident budget after subtracting its headroom (1 GiB by default). This estimates capacity, not the fastest budget. All three calibration modes stop before VAE decode and media export. LTX image uses its existing short calibration of up to two denoise steps; LTX video uses the requested distilled steps; Qwen base uses the requested steps, while Turbo preserves its saved checkpoint schedule. These measurements are not complete pipeline or decode peaks.

Profiles are JSON files under ~/.ddo/profiles (on Windows, C:/Users/<user>/.ddo/profiles), unless DDO_PROFILE_DIR is set. DDO owns the profile identity, storage and admission of recommendations. Choose a distinct name for each checkpoint, shape/duration, conditioning and computation recipe: the profile name must distinguish workload changes that the model identity alone does not capture. Reuse the same recipe and remove only --build-ddo-profile to use the stored recommendation. Explicit fixed budgets take precedence; automatic RAM admission and configured ceilings still apply. A missing compatible recommendation is reported and retains the normal plan.

See executable creation/reuse examples for LTX image, LTX video and Qwen. Calibration adds GPU monitoring and completion checks; CPU interface tests do not establish GPU acceptance.

Public native reporting

For the two public native image entries, use the following reporting controls.

Supported display/save switches also accept their negative forms. Both public image entries accept --no-show-profile, --no-show-metrics, --no-save-metrics, --no-show-denoise-steps and --no-local-files-only. The four purge switches above likewise accept negative forms. Other booleans accept only the forms listed by their runner; do not infer a --no- form for every opt-in experimental flag. RSS and USS are different memory measurements; callback intervals are not synchronized GPU timings. See metric labels. All listed LTX image/video and Qwen runners accept --memory-monitor rss and --memory-monitor full and pass the choice to the shared monitor. Defaults remain runner-specific to preserve existing recipes; select a mode explicitly when comparing measurements.

Model guides list their additional controls. Contributors can consult diagnostics and reporting for timing semantics and the runner interface contract.

Model sources and investigations

Use --model-path for the checkpoint in all public LTX image entries and the public Qwen entries. SDNQ source roles are specified in the model guides. Native API selection is automatic. Use the dedicated diagnostic entries for adapter, backing and transport investigations.

Complete model-specific inventories: Qwen native image parameters and LTX image parameters.