ComfyUI-VoxCPM treats voice cloning as three modes, not one switch

Direct parameters beat config nodes, and that ordering matters

Four node groups cover the surface area. A unified TTS node handles zero-shot synthesis, voice design, voice cloning, ultimate cloning and LoRA. A Voice Cloning node takes prompt and reference audio plus voice activity detection trimming and feeds the TTS node's voice config input. An Advanced Params node carries the diffusion settings and feeds the advanced params input. Three training nodes handle LoRA training configuration, dataset creation from audio, and the trainer itself.

Values resolve in a fixed order: direct parameters on the node beat config node values, which beat defaults. That ordering is worth knowing because voice design is a direct parameter on the TTS node rather than part of the Voice Cloning config, so setting it inside the cloning node has no effect.

One bundled feature is off by default on purpose. The ZipEnhancer denoiser is disabled to keep the dependency list light, which means reference audio is fed in as recorded unless you turn that on.

Install is a clone into custom_nodes and one requirements file

ComfyUI Manager is the easy route: search for the package name and install it. The manual route is three commands.

cd ComfyUI/custom_nodes/
git clone https://github.com/wildminder/ComfyUI-VoxCPM.git
cd ComfyUI-VoxCPM
pip install -r requirements.txt

Restart ComfyUI afterwards and the nodes appear under the audio and text to speech category. Model weights download themselves to a tts folder inside the models directory on first use, so there is no separate download step.

The package targets Python 3.10 or newer and ComfyUI 0.28.0 or newer. Its declared dependencies are torch and torchaudio pinned to 2.5.0 or newer, transformers pinned to 4.36.2 or newer, plus safetensors, huggingface_hub, einops, addict, pydantic, simplejson, sortedcontainers, soundfile, diffusers, tqdm and bitsandbytes. The classifier list names NVIDIA CUDA explicitly.

Three checkpoints with very different language counts

The node drives three checkpoints, and the differences between them are larger than the parameter counts suggest.

The newest is a 2 billion parameter model producing 48 kHz output across more than thirty languages. It adds voice design from a plain text description and a controllable cloning mode where style instructions ride along with the reference.

The middle option is 800 million parameters at 44.1 kHz and two languages, Chinese and English, with LoRA support and native LoRA training. The smallest is 640 million parameters at 16 kHz and two languages.

So the choice is not simply larger versus smaller. The 2B checkpoint is the only one with wide language coverage and the only one offering voice design, while the 1.5 checkpoint is the one that pairs with the training nodes. Everything else in the node is shared.

Cloning is three modes, and they take different inputs

What gets called voice cloning here is three separate wiring patterns.

The first follows the 1.5 style. You load an audio file into the prompt audio input and supply the matching text in the prompt text field. A transcript is required.

The second is reference cloning on the 2B checkpoint. Reference audio goes into the reference audio input and no transcript is needed at all. Voice design instructions can be layered on top of the reference for controllable cloning.

The third is ultimate cloning, which uses both inputs for different jobs: reference audio carries the identity of the speaker while prompt audio with its transcript carries the prosody, the rhythm and delivery.

Because these are separate inputs rather than a mode switch, a graph can satisfy one, two or all three, and the difference in required inputs is the main thing to get right when building a pipeline.

prompt_text wants a transcript, not a description

The clearest warning in the documentation is about the prompt text field: it is the exact transcript of the audio, not a description of the voice.

That distinction is easy to get wrong, because a description is the obvious thing to type into a field next to audio. Three rules follow from the requirement.

The transcript has to match the audio word for word. Punctuation matters, because it affects intonation. And five to fifteen seconds of clear speech is the range that works best, with anything longer or more complex being where instability shows up.

The repository ships three sample pairs to check against: a female sample, a Rick and Morty style male sample and a Stewie style male sample, each with its audio file and a matching prompt text file. Running one of those before your own material is the quickest way to find out whether a problem is your transcript or your clip.

Voice design is dropped the moment prompt audio takes over

Voice design takes a written description instead of a voice sample, and the 2B checkpoint ships a table of examples with their expected results: a warm female voice gives a soft gentle female result, a deep male voice gives a low-pitched result, a cheerful young girl gives something energetic and high-pitched, a professional announcer gives a clear authoritative result, and a whispering voice gives a quiet intimate one.

Descriptions also combine, so a warm female voice with a slight British accent is a valid single entry.

The catch is scope. Voice design is applied in plain text to speech and in reference cloning. It is ignored when prompt audio is used, which is the continuation cloning path. There is no warning when this happens; the instruction simply stops having any effect, so a graph can appear configured and produce the opposite of what was asked. Deciding which input carries the instruction is therefore the part to get right.

AudioVAE stays in FP32 no matter what you choose

Diffusion parameters are exposed with defaults chosen for stability rather than speed. Temperature defaults to 1.0 across a 0.1 to 2.0 range, where lower is stable and higher is expressive. Sway sampling coefficient also defaults to 1.0. The CFG-Zero optimization is on by default, guidance scale defaults to 2.0 across a 0.1 to 10.0 range, and inference timesteps default to 10 across a 1 to 100 range where more steps mean higher quality and slower output.

Device and precision both default to automatic, with cuda, cpu, mps, xpu and npu offered for the device and bf16, fp16 and fp32 for the dtype. The exception worth knowing is that the audio VAE always runs in FP32 for numerical stability, so selecting a lower precision elsewhere does not shrink that part of the model.

Voice activity detection for the 2B checkpoint defaults to trimming off, with a maximum silence of 200 milliseconds and a top threshold of 35.0, where a lower value trims more aggressively.

The frontend is lazy loaded, with a stated 95 percent reduction in startup payload, so heavy JavaScript loads only once a VoxCPM node is placed. Model selection uses a custom widget with badges instead of the stock dropdown, and downloads show live file level progress with a cancel option.

Editorial conclusion

This node suits someone already running ComfyUI who wants speech generation to live in the same graph as everything else, because cloning, voice design and LoRA training all sit inside the canvas rather than behind a separate interface. It suits you less if you need long form narration on a CPU only, since the diffusion defaults assume a GPU and the two smaller checkpoints cap out at two languages. Before trusting a clone, check that your transcript is verbatim, keep reference clips inside the five to fifteen second window, and decide deliberately about voice design, because it is discarded without warning the moment you attach prompt audio. Use it only with voices you have the right to clone.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. wildminder/ComfyUI-VoxCPM on GitHub