YuE2 模型服务

If you came here expecting a Load Checkpoint-shaped node with a dropdown of .safetensors files, read the next paragraph before you go looking for a missing model list. There isn't one.

What this node actually is

YuE2ModelLoader (显示名 "YuE2 模型服务") does not put YuE2-3B anywhere near ComfyUI's VRAM. It health-checks a separate background service and hands you back a small settings receipt that the other eleven nodes use. That service is a full second Python environment - CPython 3.12.10, its own CUDA 12.8 Torch - running in an isolated process on 127.0.0.1:8189. The nodes are thin HTTP clients.

That separation is the whole point of the pack, and it's the right call. Audio tooling in ComfyUI has a bad habit of wanting a different transformers than whatever you already have installed; the KB's own summary of the layer is that dependency conflict is the default failure mode, which is why the big TTS suites eventually moved to per-engine runtime isolation too. This pack skips straight to that answer: install it and your ComfyUI Torch stack is untouched. You pay for it with disk space (the pack asks for ~60 GB free) and a service that has to be running.

The mechanism

load() calls ensure_service(), which hits /api/health. Nothing there? It spawns runtime/python.exe -m app.yue2_app.service with YUE2_HOME set, waits up to 30 seconds, then validates the response: ok must be true, the service version must match the node version (1.3.0), and the service's install root must match your node directory unless you set YUE2_SERVICE on purpose. Then it checks that the packed model and vae weights are present and that the generation capability is live. Miss any of that and you get a RuntimeError naming exactly what's absent - core runtime, inference source, or model files.

Only then does it return a handle. So: if this node turns green, everything downstream can run.

The inputs that matter

• backend - torch-eager (default) or torch. In the vendored pipeline the sole difference is whether the autoregressive stage uses captured CUDA graphs. torch-eager = graphs off, the boring compatible setting. Switch to torch only if you want the AR stage faster and have headroom.
• memory_budget_gib - default 23.5, range 12–24 here. It's a ceiling the worker enforces, with 2 GiB held back for overhead. It does not shrink the model, and setting it lower will not make a small card finish a song. If your widget floors at 12 and your card is smaller, note the WebUI takes any value above 2 GiB - the node widget is just clamped.
• offload_ar - default on. Moves the AR weights off the device when the current stage doesn't need them; this is the long-song memory-peak fix from 1.1.5. Leave it alone.
• nar_attention / nar_query_chunk_size - sdpa (default), math for compatibility, cudnn; 256-row chunks by default. Chunking keeps the peak flat on long songs without shortening anything, because the context stays complete.

Outputs

model is the one that matters - wire it into every other YuE2 node. status is the raw health JSON, which is what you want open in a text/preview node the day something says the environment isn't ready.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/Comfyui-YuE2-T8.git

Then run install_runtime.bat once from that folder, and restart ComfyUI. It downloads the model bundle, the isolated runtime, CUDA Torch, FFmpeg and the offline score renderer. Windows 10/11 + NVIDIA GPU; 24 GB VRAM and 60 GB disk are the recommended asks. Registry install also works: comfy node install yue2-t8. Weights live in <node-dir>/models (seven subfolders plus the two manifests) - never in models/checkpoints.

Where people get burned

Two installs, one port. "端口 8189 已由另一套 YuE2 占用" means another copy owns the port. Stop it, or start the other one with --port 8198 --no-switch and set YUE2_SERVICE=http://127.0.0.1:8198 for the node. Version drift: an older service from a previous install fails validation with a message telling you to run stop_service.bat and retry - do that, the node restarts it. Interrupted downloads read as missing, because readiness compares exact pinned byte sizes rather than just checking a file exists. And the first generation after a cold service is slow; that's a model load, not a hang.