PDMD has a documented 24GB GPU inference path, but it also requires 128GB host RAM and streamed, quantized components. This is not a lightweight laptop recommendation or an independently reproduced performance result.
The change is to the training update
The authors’ method projects out a component of the distribution-matching update associated with a student–critic residual. The project reports few-step video results and describes its comparison conditions. Our reading is that the claim concerns a training method; users still need the correct trained adapter, base model and inference configuration rather than adding one line to an arbitrary sampler.
The 24GB path also needs substantial system memory
The official repository documents an int8 streamed path for a 24GB GPU with 128GB host RAM. It offloads and streams the transformer and Qwen text encoder and provides separate 80GB instructions. For its cited A10 example at 1344×768 and 345 frames, the authors report roughly 31 minutes per loaded four-evaluation video, including decoding. FyreLinkz has not reproduced that result. The configuration is an example, not a claim that any 24GB card and host will match it.
Count every component before choosing hardware
Our proposed sizing sheet records the base model, selected adapter, text encoder, VAEs, downloaded bytes and peak host memory. A small adapter is not a small complete pipeline. Record whether a merged checkpoint or adapter fusion creates an additional disk artifact. Separate GPU memory, system RAM and storage in the budget rather than calling all three memory. For a rented instance, verify host RAM before reserving a GPU. The workstation planner is a budgeting aid; the documented workload still needs an exact configuration test.
Two and four evaluations need the same creative test
To compare released options, keep prompt, clip dimensions and duration consistent. Score visible action, continuity, audio quality and synchronization separately. Run repeated samples rather than assuming the lower-evaluation version preserves the same failure rate. If precision differs between hardware paths, do not call their output differences a pure step-count comparison. Record accepted clips and rejected candidates together. A useful production decision asks whether the faster option produces an accepted deliverable sooner, including review and reruns, rather than only whether denoising ends earlier.
| Proposed check | Keep fixed or record | Question it answers |
|---|---|---|
| Host resources | Count base, adapter, encoder and VAEs | RAM and storage distinct from VRAM |
| Step comparison | Fix duration, dimensions and precision | Accepted output rather than NFE alone |
| Worker operation | Separate startup from warm queued jobs | Failures, progress and repeated costs |
A low-VRAM worker needs operational planning
Our recommendation is to trial one documented job before building a queue around it. Log startup, adapter preparation, model loading, generation and decode time, then decide whether to keep a worker warm. Give long-running work a visible progress state and preserve failures so users do not unknowingly request repeated expensive jobs. Confirm checkpoint, base-model and code terms before commercial deployment; no blanket commercial-rights conclusion is established here. This article does not provide a measured consumer-GPU minimum, local benchmark or guarantee that the documented timing will transfer to another system.
Frequently asked questions
Does PDMD need only a 24GB GPU?
No. The documented streamed path also calls for 128GB host RAM and specific component handling.
Is the adapter the complete model?
No. The inference setup uses a MiniMax H3 base and additional components.
Was the cited A10 runtime measured by FyreLinkz?
No. It is an author-reported configuration-specific example.
Sources & further reading
Primary sources checked Oct 11, 2026. Vendor statements are attributed; editorial advice is our own.
- 1PDMD project and evaluation protocol ↗PDMD authors
- 2
Help us keep this useful. Check contact availability →
