RunningHub VoxCPM Train LoRA
Train a VoxCPM voice LoRA without leaving ComfyUI
- lora_path
- info
This is the node that makes the pack special. RunningHub VoxCPM Train LoRA fine-tunes a VoxCPM model on your own audio from inside ComfyUI - no separate training environment, no Python scripts, no GPU cloud rental. Feed it the train_manifest from a Dataset Build node, pick how long to train, and it runs an actual LoRA training loop in-process and hands you a voice adapter you can load straight back into Load Model. The community discovered LoRA-training VoxCPM this way through a sibling pack in early 2026, and the reception was unambiguous: people report "100% faithfully recreat[ing] voices" with a custom LoRA, and rank 128 often beats the default 32 for quality.
What it needs before it runs
Two non-negotiable prerequisites beyond the pack install:
- The
voxcpm.trainingmodule. The training nodes reuse OpenBMB's upstream training code, which lives in the VoxCPM source tree, not the pip package alone. You need the full VoxCPM repo available - either installed, or a checkout atComfyUI/custom_nodes/VoxCPM/src/voxcpm/training/(or inside this plugin'svoxcpm/src/). If it can't find the module, the node raises a clear error telling you exactly that. - The base model.
model_nameis a dropdown of folders undermodels/voxcpm/(same list as Load Model). Training starts from these weights, so you'll be loading VoxCPM2 into memory as the training base.
The inputs that decide your result
The required block reads like a training config file, because it is one: model_name, train_manifest, output_name (folder prefix), num_iters (500), batch_size (1), grad_accum_steps (1), learning_rate (1e-4), lora_rank (32), lora_alpha (32). The ones you'll actually tune:
- num_iters - total steps. For a handful of clips, 500 is a reasonable first pass; check the
infooutput's summary and iterate. - lora_rank / lora_alpha - the classic LoRA dials. The defaults are safe; the community's higher-rank experiments (128) are where quality jumps for real voices.
- enable_lm / enable_dit (both default on) - which sub-networks get the LoRA. Leave both on unless you're troubleshooting;
enable_proj(off by default) adds projection layers.
The optional block is mostly scheduler plumbing - warmup_steps, weight_decay, max_grad_norm (0 disables clipping), val_manifest, save_interval (0 = save only at the end). Two that change workflow behavior: copy_to_loras_dir (default on) copies the finished weights into models/voxcpm/loras/ so Load Model picks them up after a frontend refresh, and zip_to_output (default on) zips the checkpoint for easy download - which is what RunningHub's web UI uses to hand you the file.
What actually happens
The node runs the upstream training loop in-process: it loads the base model, builds the dataloader from your manifest, and runs AdamW with a cosine schedule, gradient accumulation and all. There's a subtlety the code comment spells out that's worth knowing if you hit an error: ComfyUI wraps execution in torch.inference_mode(), which silently turns every tensor into an inference tensor - so the node explicitly disables inference mode and re-enables grad for the loop. If you see element 0 of tensors does not require grad, you're almost certainly running an old version of this pack that predates that fix.
Artifacts land in ComfyUI/output/voxcpm_train/<output_name>_<timestamp>/, with lora_weights.safetensors + lora_config.json. The two outputs are lora_path (the folder or the copied file) and info (a text summary: iterations, batch, lr, rank/alpha, output dir).
Setup and honest expectations
cd ComfyUI/custom_nodes
git clone https://github.com/RH-RunningHub/ComfyUI_RH_VoxCPM.git
cd ComfyUI_RH_VoxCPM && pip install -r requirements.txt
Training pulls in the heavy transformers/datasets dependencies, so this is the node most likely to collide with other packs' versions - the standard audio-stack dependency pain. And set your expectations on compute: a LoRA fine-tune of a 2B model is not the 10-minute affair image LoRAs can be; the community's multi-hour runs are normal, and a full fine-tune (a sibling node that's present but commented out in the registry) is the memory-hungry option the README warns you away from. Start with the two-clip demo workflow in examples/ to prove the loop, then scale up.
Inputs (22)
| Name | Type | Default | Description |
|---|---|---|---|
| model_name | COMBO | 1 options: None | |
| train_manifest | STRING | — | |
| output_name | STRING | VoxCPM2_lora | — |
| num_iters | INT | 5001–200000 | — |
| batch_size | INT | 11–64 | — |
| grad_accum_steps | INT | 11–64 | — |
| learning_rate | FLOAT | 0.00011e-7–0.1 | — |
| lora_rank | INT | 321–256 | — |
| lora_alpha | INT | 321–512 | — |
| val_manifestopt | STRING | — | |
| warmup_stepsopt | INT | 1000–10000 | — |
| weight_decayopt | FLOAT | 0.0100–1 | — |
| max_grad_normopt | FLOAT | 1.00–100 | — |
| num_workersopt | INT | 20–16 | — |
| log_intervalopt | INT | 101–10000 | — |
| save_intervalopt | INT | 00–100000 | — |
| lora_dropoutopt | FLOAT | 0.000–0.5 | — |
| enable_lmopt | BOOLEAN | true | — |
| enable_ditopt | BOOLEAN | true | — |
| enable_projopt | BOOLEAN | false | — |
| copy_to_loras_diropt | BOOLEAN | true | — |
| zip_to_outputopt | BOOLEAN | true | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| lora_path | STRING | — |
| info | STRING | — |