Sooner or later every dwpose user peeks into the model folder and meets a small crowd of files with cryptic names: dw-ll_ucoco_384.onnx, yolox_l.onnx, maybe an RTMW-flavored option in the settings. Which of these do you actually need, what does each one do, and which ones can you safely ignore? This guide decodes the dwpose model files in plain language, explains the two-model team that does the work, covers the newer RTMW-based choices appearing in current node packs, and clears up the one confusion that wastes more beginner hours than all the rest combined.
The Two-Model Team
Dwpose estimation is a relay race with two runners. The first model is a detector: it scans the whole image and finds the people, drawing a bounding box around each one. The second model is the pose estimator proper: it takes each boxed person and predicts the 133 COCO-WholeBody keypoints. Neither half works well alone. Without the detector, the pose model would have to guess where in a large image the person even is. Without the pose model, the detector gives you rectangles and nothing more. When you read that dwpose “downloads its models” on first run, these are the two teammates arriving, and both are required for the standard setup.
yolox_l.onnx: The Person Finder
The detector file you will meet is yolox_l.onnx, a YOLOX model (the L marks its size class within that family). Its whole job is the first step: locate every person in the frame and box them. This is the file working when you choose a bbox_detector option in the DWPose Estimator settings, and it explains a few everyday behaviors. Multiple people each getting their own skeleton? The detector found multiple boxes. A bystander missing from the skeleton while the main subject is perfect? The detector likely skipped a small or heavily occluded figure. Because detection quality gates everything downstream, the standard advice is simple: leave the detector enabled and let it do its quiet, essential work.
dw-ll_ucoco_384.onnx: The Pose Model
The star of the pair is dw-ll_ucoco_384.onnx, the classic dwpose model file. Its name reads like a license plate, but each piece means something. The “dw” is dwpose itself. The “ucoco” points at the COCO whole-body data style it was built for, which is why its output follows the 133-keypoint COCO-WholeBody layout. The “384” refers to the input resolution the model works at, the size at which it examines each detected person. This file carries the distilled training from the original research: the big teacher’s knowledge compressed into a student model small enough to run happily beside your diffusion stack. When people say they “ran dwpose” on a photo, this is the file that did the measuring.
The RTMW-Based Options
Newer versions of the comfyui_controlnet_aux pack also offer RTMW-based model choices alongside the classic file. RTMW models come from the same MMPose ecosystem family tree and aim at strong whole-body accuracy with modern design. For everyday users the practical guidance is reassuring: the classic dwpose model remains the well-tested default that every tutorial assumes, while the RTMW options are there if you enjoy trying newer estimators or a specific reference photo defeats the default. Switching is a settings change, not a reinstall, since the pack manages the files. If you experiment, compare both on your hardest reference, the one with visible hands and a turned head, and keep the winner as your default.
ONNX and ONNX Runtime, in Plain Words
Every file above ends in .onnx, and that extension is doing quiet diplomatic work. ONNX is a standard format for saving trained models so they can run outside the framework they were trained in. ONNX Runtime is the engine that executes those files, with builds for CPUs and for NVIDIA GPUs through CUDA. This pairing is a big reason dwpose spread so easily: the same model files run inside a ComfyUI node pack, inside the A1111 extension, on Windows, Linux and macOS alike, with no compiling and no framework wrestling. When the fixes article talks about CPU fallback, it means ONNX Runtime ended up on the CPU provider instead of the GPU one; same files, slower engine room.
Where the Files Live and How They Arrive
You almost never download these files by hand. On the first dwpose run, the node pack or extension fetches them automatically and stores them in its own model storage area, and every later run loads them from there. Combined, the pair amounts to a few hundred MB, fetched once. Knowing the location still pays off during troubleshooting: if a run fails with model errors, checking that storage folder for both files, complete rather than truncated, tells you whether the download ever finished. A partial file from an interrupted first run is a classic gremlin, and deleting it so the pack can fetch a clean copy is the standard cure.
Which Combination Should You Use?
For nearly everyone, nearly all of the time: the standard detector plus the classic pose model, exactly as the tools configure themselves by default. That pairing is what the tutorials assume, what the community tests, and what produces the skeletons you have seen in demos. Reach for alternatives with a reason: RTMW options to experiment on a stubborn reference, detector variants when group shots or unusual framing misbehave. Change one file at a time and compare on the same photo, because model choice differences are real but subtle, and invisible unless everything else stays fixed.
What Is Not a DWPose Model
End with the confusion that matters most. The OpenPose ControlNet model in your ControlNet models folder is not a dwpose file, and no dwpose file can do its job. Dwpose models measure photos and produce skeleton maps. The ControlNet model consumes skeleton maps during generation and steers the diffusion process. They are partners, not substitutes, and a complete pose workflow needs one of each. When a setup “has dwpose” but poses do not transfer, the missing half is usually the ControlNet model, or a version mismatch between it and the checkpoint. The models guide and the fixes guide together cover both halves of that partnership, and between them, most model mysteries end.
Updating and Replacing Model Files
Model files are not sacred. When the node pack updates, it may refresh its model handling or add new options, and letting it manage that process beats hand-editing the storage folder. The situations where you should touch the files yourself are narrow and specific: a visibly truncated download after an interrupted first run, or a pack prompt telling you a model failed its checks. In those cases, delete the suspect file and run the estimator once more so a clean copy arrives. Outside troubleshooting, the healthiest relationship with this folder is indifference: know where it is, know what the two main files do, and spend your attention on reference photos and settings instead.
Conclusion
The dwpose model story is simpler than the file names suggest: a YOLOX detector finds people, the dw-ll_ucoco_384 pose model measures them at 133 keypoints, ONNX Runtime runs both anywhere, newer RTMW options wait in the wings for experimenters, and the ControlNet OpenPose model remains a separate partner that turns skeletons into steered generations. Keep the default pair, let the tools manage the downloads, and you will rarely need to think about this folder again, which is exactly how infrastructure should feel.
Read next: