Dev.to AI πŸ€– Ai πŸ‘ 0 πŸ“– 6 min read

H3 Acceleration Exports: PDD, OpenVDN, and LightX2V Without a Fake Speed Ranking

Six exports can explain how three acceleration routes are configured without proving which one is fastest. This package pairs reference-image and first/last-frame variants for PDD, OpenVDN and LightX2V. The useful compar

Six exports can explain how three acceleration routes are configured without proving which one is fastest. This package pairs reference-image and first/last-frame variants for PDD, OpenVDN and LightX2V. The useful comparison begins with their actual inputs and schedule sources, not a race declared from filenames.

There are 121 nodes and 161 explicit links across the six JSON files. The source title and transcript discuss a broader comparison, including twenty-step and attention-level approaches. These supplied exports are not a newly executed twenty-step baseline, a Sage-only benchmark or a controlled speed ranking. No inference, hardware timing, image/audio acceptance or quality study was performed for this guide.

Start with the six configurations

Code Supplied route Saved image connections Important qualification
01 PDD reference One generic reference image Ref2VA base, setup variant and task selected
02 PDD endpoints First and last frame FL2VA setup coexists with I2VA first-frame task selection
03 OpenVDN reference One generic reference image Prompt mentions two pictures, but only one is connected
04 OpenVDN endpoints First and last frame Ref2VA task remains selected; two other examples are bypassed
05 LightX2V reference One generic reference image AUTO task and explicit four-step scheduler
06 LightX2V endpoints First and last frame AUTO task; different LoRA and video sigma shift from 05

Connections establish where data is supplied, not how every custom implementation resolves conflicting settings. Review codes 02 and 04 before promising endpoint control. This package preserves those configurations rather than silently repairing them or declaring a proven runtime failure.

PDD: a setup node supplies the sampling components

The reference version selects minimax_h3_ref2va_int8_convrot.safetensors. Its PDD setup chooses MiniMax-H3-Ref2VA-Acc-8Step_comfyui_pdd-T8.safetensors, Ref2VA base variant and strength 1. Image 5 reaches the conditioner's first generic reference slot.

The endpoint version selects minimax_h3_fl2va_int8_convrot.safetensors and the corresponding FL2VA PDD asset. Image 5 reaches first_frame and image 30 reaches last_frame. However, the conditioner task widget says I2VA, described as first-frame image-to-video, while the setup selects FL2VA.

That mismatch cannot be resolved by the filename. Check the installed conditioner/setup semantics and the emitted conditioning before accepting a first/last-frame result. Two endpoint wires do not independently prove that the selected task consumes both as intended.

In both files, setup node 8 receives the base model and audiovisual latent. It supplies the model to BasicGuider and supplies sampler/sigmas to SamplerCustomAdvanced. No numeric sigma schedule is serialized, and the report output is unused. The eight-step class and asset names identify the selected route, not observed evaluations or wall-clock cost.

PDD output settings are smaller than the other exports

Both PDD conditioners store 736Γ—416 and length 124, with native audio configured and no external width/height/length overrides. Their noise controls randomize. The sampled output reaches an AV decoder, whose frames and generated audio feed VHS_VideoCombine.

VHS stores 24 fps, H.264 MP4, CRF 19, yuv420p and trim_to_audio false. Its prefix is AnimateDiff, but that string does not make this an AnimateDiff model route. Identify the architecture and stage through the actual loaders and connections.

At 24 fps, 124 output frames would have a nominal duration of about 5.167 seconds. That is arithmetic, not a measurement of generated length, audio alignment or the final file.

OpenVDN: selected stage versus stale titles

The reference export uses the Ref2VA base; the endpoint export uses the FL2VA base. Both composers select OpenVDN/vdn-minimax-h3 and stage_dmd_8nfe, with verify_hashes false and allow_structural_base true.

The execution-plan node supplies model, sampler and sigmas to the active sampling path. There is no explicit numeric schedule in the saved export. DMD8 and evaluation-count labels should not be presented as measured execution counts. A successful JSON hash check also does not establish weight-hash verification when that composer option is off.

The reference graph connects one image to a generic reference slot. Its prompt discusses two pictures, but the graph does not supply a second image. Use an instruction consistent with the actual input set instead of treating prose as a hidden image connection.

The endpoint graph connects first_frame and last_frame, yet retains Ref2VA as its task selection. As with the PDD mismatch, inspect the matching implementation rather than claiming the task automatically resolves correctly.

Only one endpoint example is enabled

The endpoint file contains three full example chains. Its main chain is enabled; the other two, including their saves and image loaders, are bypassed. Do not count their prompts or media as active examples, and do not advertise three successful outputs from one file.

Some conditioner titles still mention 960Γ—544 and 39 frames. Actual saved widgets specify 896Γ—512 and 124 frames, with no overriding links. The title is stale. Both active OpenVDN outputs decode generated audio and assemble video at stored 24 fps and 8-bit before SaveVideo with auto format/codec options.

No upscale or interpolation stage should be borrowed from a different episode's OpenVDN package. These are the supplied graphs, not a generic template presumed to contain every later addition.

LightX2V: four steps are an explicit saved control

Unlike the setup-generated schedules above, these exports contain BasicScheduler configured as simple, 4 steps and denoise 1, plus an Euler selection. That is genuine saved configuration; it should not be dismissed merely because no benchmark was run. It still does not prove actual latency, quality or a speed winner.

Code 05 selects the Ref2VA base and minimax_h3_ref2v_turbo_4step_v0.1_comfyui_bf16.safetensors at strength 1. Its sigma shift stores video 12 and audio 3. One image reaches the generic reference slot, and task selection is AUTO.

Code 06 selects the FL2VA base and minimax_h3_fl2v_turbo_4step_v1.2_768p_comfyui_bf16.safetensors, also at strength 1. Its sigma shift is video 6 and audio 3β€”not the same video shift as the reference version. First and last images are connected, with AUTO task selection.

Both select 896Γ—512 and 124 frames. The 768p text inside the second LoRA filename is not the saved output dimension. Noise controls are fixed, but that is not a general reproducibility guarantee across versions or hardware.

The sampled latent feeds video and audio decoders, then CreateVideo and one SaveVideo node. The two MarkdownNote nodes in each file are explanatory notes, not additional generation branches or tested cases.

Why these files do not establish a fair speed contest

The PDD generation request is 736Γ—416, while the active OpenVDN and LightX2V requests are 896Γ—512. Base variants, schedule providers, seed controls and task selections also differ. Treating output frame rate as inference throughput would add another error: 24 fps describes video assembly, not frames generated per second of compute.

For a real comparison, record the exact model and node versions, hardware, requested and actual dimensions, frames, input media, prompts and timing method. Check the emitted schedule where possible, and separate load/startup cost from generation if that distinction matters to the use case. Resolve conflicting task settings before interpreting failed or changed outputs as a method's quality.

The source transcript discusses inference-level and attention-level acceleration separately. The absence of a standalone Sage patch in these exports does not prove what backend an installed runtime uses, nor does it supply a missing attention benchmark.

Audio and acceptance boundaries

Every enabled output routes decoded generated audio into its video. No input-audio passthrough is connected, and conditioner mux_audio is unused. Prompt soundscape instructions are requests, not proof that the output contains the described speech, effects or music.

Use authorized images, verify actual input roles and perform a small test in a working copy. Inspect identity, motion, endpoint behavior, soundtrack, duration and saved dimensions before acceptance. A connected image or a native-audio setting does not substitute for watching and listening.

The selected covers are same-stem WebP files in the matching source folders; alternative PNG/root images are not silently treated as additional accepted examples. Covers have not been visually reviewed. Source originals are preserved, and only recorded historical preview fields are cleared in new copies.

The source-provided tutorial is recorded without live verification. Model weights and external inputs are not bundled. Workflow, model, LoRA, node, image and cover rights require separate review. This walkthrough supplies configuration distinctionsβ€”not a new benchmark, blanket license or published result.

Getting the workflows

Published by this channel. The graphs are free; weights, LoRAs and input assets are separate and carry their own terms.

πŸ“° Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.