Load Kimodo Model
One string input, a 17GB text encoder, and the whole reason people bounce off this node pack
- model
Kimodo is NVIDIA's kinematic motion diffusion model - text in, 3D humanoid motion out, on the SOMA skeleton. This node is the half of the pair that puts the weights on your GPU. It has exactly one input, a string, and if you skip it you get nothing, because KimodoTextToPose won't generate a frame without a KIMODO_MODEL wired into it.
It's also the node where most people fail. Not because it's subtle - because the thing it loads is enormous, and the dependency it needs isn't in the pack's own install list in the way you'd expect.
What it actually does
Two jobs. It turns a model name into a live model, and it does that the ComfyUI-correct way rather than the naive way.
The naive way is model.to("cuda") in your loader and hope. That's what the previous incarnation of this code did, and the pack's source docstring is candid about why it hurt: ComfyUI's LRU eviction would detach half the model, leaving diffusion buffers on CPU while the U-Net sat on the GPU, then RuntimeError about tensors being on different devices partway through a run. Fun.
So this loader instantiates on the CPU, wraps the raw module in ComfyUI's ModelPatcher, and lets ComfyUI's memory controller decide when it moves to the GPU. That's the contract that makes eviction safe. The actual transfer happens later, when KimodoTextToPose runs.
The bit that will eat your VRAM
Before it builds anything with Hydra, the loader calls unload_all_models() and soft_empty_cache() on ComfyUI's model management. That looks paranoid until you know why: Kimodo's text encoder is an LLM2Vec stack over a Llama-3 backbone, and it allocates on the GPU inside its constructor - before ComfyUI's memory bookkeeping gets a say. Leave a Qwen-Image-Edit or a Flux checkpoint cached in VRAM and that allocation OOMs.
The encoder is the whole cost. When Kimodo was announced on r/comfyui in March 2026, the top reply was the complaint you'd expect: "~17GB of VRAM to generate locally, primarily due to the text embedding model." Someone then tried to swap in an fp8-quantised encoder and gave up on "your typical Python whack-a-mole game with dependencies." Our knowledge base makes this a 2026 pattern rather than a Kimodo quirk - on LLM-encoded models the encoder is a second VRAM budget, often the file that decides whether anything fits.
The pack mitigates what it can. It pins the encoder to CPU with a TEXT_ENCODER_DEVICE env default and caches it per model variant in a module-level dict, so a second load of the same variant reuses the existing encoder instead of building a second ~21.7GB copy. That won't make it small. It does mean the second run isn't worse than the first.
Inputs and outputs
model_name is the only input, a plain string. Leave it empty and you get the pack's default variant, Kimodo-SOMA-RP-v1.1 - unless the KIMODO_MODEL env var says otherwise. If you don't know what to type here, don't type anything.
The single output is model, of type KIMODO_MODEL, which wires into KimodoTextToPose's model input. No image, no sampler, no scheduler - those live on the generation node, because Kimodo isn't a diffusers sampler you can swap.
Installing it
Through ComfyUI Manager, search the pack title ("Melite Kimodo Nodes" / melite-kimodo-nodes) and install. Or by hand:
cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/JayDataEngineer/melite-kimodo-nodes.git
cd melite-kimodo-nodes
pip install -r requirements.txt
Restart ComfyUI. Do run that pip install yourself even on a Manager install - the requirements file is where the interesting rows are: hydra-core, multihmr2 and kimodo both pinned to exact upstream git commits, plus trimesh, anny==0.6.0 and xatlas for the pack's body nodes. The git-URL installs pull from GitHub, so give it a minute and don't kill it.
Where it breaks
"No module named 'kimodo'" mid-run. The signature failure, and genuinely confusing: the pack registers fine - nodes show up, the graph validates, the whole workflow then dies with a soft "workflow failed" when the loader executes. nodes.py imports kimodo lazily, inside load(). The pack's __init__ tries to rescue you by adding a vendored source dir to sys.path, but on a fresh clone there may be nothing there to find. pip install -r requirements.txt is the fix; the pack's own notes name hydra-core as the single missing piece that broke the import chain on the image it was built from.
OOM at load, with a clean graph. You didn't unload the previous brick. The loader tries; ComfyUI's own accounting only fires for loaders that use it. Restart ComfyUI if a stale model is still resident.
It feels hung on first load. It's pulling a generative model plus a Llama-class encoder off CPU. The loader logs the resolved name, size in GB and elapsed seconds, so watch the console to tell working from wedged.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| model_name | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| model | KIMODO_MODEL | — |