ComfyUI-VibeVoice turns Microsoft's dialogue models into graph nodes

It is a wrapper, and the wrapper does the awkward parts

ComfyUI-VibeVoice is a ComfyUI custom node for the VibeVoice TTS family, and the readme states its value proposition in one line: Microsoft's VibeVoice, with model download, VRAM management and audio handling handled for you.

That last clause is the reason to use the node rather than the upstream project. Microsoft's VibeVoice covers 1.5B and 7B long-form conversational TTS, a 0.5B realtime model, and ASR. Running that yourself means fetching multi gigabyte weights, deciding how they sit in memory next to whatever else is in your ComfyUI graph, and handling the audio yourself. The node does all three, and the models download on first run into ComfyUI/models/tts/VibeVoice/ and load under ComfyUI's VRAM manager, so the graph inherits the same unload and reload behaviour as the rest of your models.

The nodes are placed under WMNodes/sound/tts and WMNodes/sound/asr, and the package metadata names the display name WM VibeVoice TTS with a publisher id of wildai. The project requires ComfyUI 0.28.0 or newer, and the package itself needs Python 3.10 or newer.

What you get is a text to speech and speech recognition pair with a conversational structure rather than a single narration voice. The readme's framing is long-form, multi-speaker conversational audio, and the feature table backs that with up to 4 distinct voices in one output.

Four checkpoints, and the size you are committing to

The model table is the most useful thing in the readme, because it tells you what a given GPU means in gigabytes before you download anything.

So the small conversational model is a 3 GB download, the realtime one is 1.5 GB, and both the large conversational model and the ASR checkpoint are 17.4 GB. On a consumer card the 7B variant is a heavy ask even with quantization, while the 1.5B and realtime checkpoints are the realistic starting point.

Quantization is optional rather than mandatory, and the readme explains how to use it: point the Load VibeVoice Model node at a .gguf file or at a quantized safetensors file, and leave the node unconnected to use the standard model. The feature table lists GGUF, fp8, int8 and 4-bit formats, with 4-bit needing bitsandbytes, and the safetensors format alongside them.

Attention backends are selectable too, with eager, sdpa, flash_attention_2 and sage listed, and sageattention has its own install note with Windows wheels.

The ASR side deserves a mention too, because it is not a transcript button: the readme says the VibeVoice ASR node returns timestamped speaker segments, which means you get back who spoke and when, not just the words.

Installation is a manager click or a git clone

The supported path is ComfyUI Manager. The readme's instruction is to go to Manager, then Install Custom Nodes, search for ComfyUI-VibeVoice, install, and restart.

The manual path is three commands.

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

After restarting ComfyUI, the nodes appear under WMNodes/sound/tts.

The optional pieces are listed as a small table, and they map directly onto the features: sageattention if you want the sage attention backend, with Windows wheels provided separately, bitsandbytes if you want 4-bit quantization, and the audio-extra extra for the audio fallbacks.

The extras exist because resampling is the one part of the pipeline that is not guaranteed to be present. The package metadata explains that torchaudio is a hard dependency and the primary resampler, while scipy and librosa are used only if torchaudio is unavailable, and the node degrades gracefully without them.

That is a small but well made decision. A TTS node that hard fails because a resampling library is missing is a common annoyance, and having the fallback optional rather than required keeps the install small without hiding the failure.

Scripts are dialogue transcripts with speaker tags

The usage section is short, and the script format is the part you will spend time on.

You add the VibeVoice TTS node to the graph, connect a Load Audio AUDIO output to a speaker_*_voice input to clone that voice, leave an input empty to reuse a provided reference, write the dialogue in the text input, and queue the prompt. One audio file comes back for the whole conversation, not one file per line, which is the point of the model.

Lines are assigned to speakers in one of two formats, and the readme says both are treated identically.

[1] Hello, this is the first speaker.
[2] And this is the second.

Speaker 1: Hello, this is the first speaker.
Speaker 2: And this is the second.

The modern bracket form is the recommended one, the classic form is still accepted, and an optional colon after the bracket is handled too, so [1]: also works.

The practical consequence is that you are writing a script, not a prompt. That is a different mental model from most text to speech nodes, and it is what makes multi-speaker output coherent rather than a sequence of unrelated utterances.

One reference anchors every voice, so there is no zero-shot

This is the limitation to read first, and the readme puts it in a warning block rather than a footnote.

At least one speaker_*_voice reference audio is required. VibeVoice anchors the timbre of every speaker to a provided reference, so you cannot generate a fully reference-free, zero-shot voice for any speaker. To clone a voice you connect a Load Audio node to that speaker's input, for example speaker_1_voice. Any other speaker may be left empty, and when a speaker has no reference of its own, its voice is cloned from the reference you did provide rather than generated from scratch.

The hybrid example in the readme makes that concrete.

[1] This line will use the audio from speaker_1_voice.
[2] This line will reuse the cloned voice from speaker 1.
[1] I'm back with my cloned voice.

So the feature set is: one reference, up to four voices, and the differences between the voices are the ones the model can derive from a single exemplar. If your script needs a genuinely different timbre for each of four characters, one sample will not carry that.

There is a second constraint worth noting, which is about the input side rather than the model. Cloning works from a .wav or .mp3 file you already have, so the quality and cleanliness of that recording sets the ceiling for every voice derived from it. Voice cloning in this project is not a text to voice system with a reference attached, it is a reference that happens to be scripted.

Realtime mode changes the shape of the node

The realtime section is where the readme in the copy available here cuts off, but the first sentence is enough to matter.

Selecting a realtime checkpoint in the model_name input switches the VibeVoice TTS node to the official windowed realtime path, which is single-speaker and voiced from a cached reference. The windowing is the mechanism: rather than producing a whole conversation in one pass, the audio is produced in windows over a rolling context.

That is a different product from the long-form nodes, and it is worth knowing before you build around it. The multi-speaker features described earlier belong to the 1.5B and 7B path, while the realtime checkpoint at 1.5 GB gives you lower latency and a single voice. The readme's feature list carries a separate realtime badge for that model, which suggests the two paths are documented as distinct capabilities rather than one feature set with a speed switch.

For the purposes of an adoption decision, the practical question is which of the two you actually need. A scripted multi-voice scene for a video or a game is a long-form job, and the 1.5B model at 3 GB is the sensible first target. If you need speech as fast as it can be produced, the realtime checkpoint is the one to look at, accepting a single voice and reading the rest of that section first.

The dependency policy is deliberate, and the tests enforce it

The requirements files are unusual enough to be worth reading, because the reasoning is in the comments.

The requirements file lists only the packages that ComfyUI does not already bundle. Torch, numpy, safetensors and tqdm ship with every ComfyUI, so listing them again would be noise, and a test, tests/test_pyproject.py, checks that the requirements file is a subset of the declared dependency surface in pyproject.toml.

The interesting one is transformers, which is intentionally unbounded. The comment says the node is developed, tested and shipped against the 5.3.x line, but capping it here would make a ComfyUI-Manager install downgrade or pin a package the node does not own, since ComfyUI itself only asks for transformers 4.50.3 or newer, and it would break consumers on a newer 5.x. It also says not to re-add a cap to either file on your own, because the two files must agree and the test enforces that.

That is a defensible position for a node that lives inside somebody else's application. It is also a position with a cost: your environment decides the transformers version, and the node is tested against a line rather than pinned to one. If a new transformers release changes an API the node uses, the failure will surface in your graph rather than at install time.

On maintenance, the licence is MIT, the repository is not archived, and the last push was on 2026-10-08, the same day as release v2.12.2. Before that came 2.11.0 on 2026-09-28 and 1.5.1, described as a maintenance release, in September 2025. The repository carries a CHANGELOG.md, a pytest.ini, a conftest.py, example_workflows, a repro_sched.py and a tests directory, which is a reasonable shape for a node that people assemble graphs with.

Editorial conclusion

ComfyUI-VibeVoice fits a ComfyUI user who needs a scripted conversation with several distinct voices, produced inside the same graph as the rest of their pipeline, and who is willing to supply reference audio for at least one speaker. It is the wrong tool if you need zero-shot voice from text alone, if your GPU cannot hold a 1.5B to 17.4 GB model, or if you need more than four voices in one output. Check first that your ComfyUI version is 0.28.0 or newer, that you have a reference recording for the voice you want cloned, and that the transformers version in your ComfyUI environment is one the node has actually been tested against.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. wildminder/ComfyUI-VibeVoice on GitHub