Running YuE2 on 16GB and Windows: The Graph, the Settings, and What the Files Measure

TL;DR — YuE2's official requirement is a 24 GB NVIDIA GPU on Linux. It ran here on a 16 GB RTX 5080 under Windows, through ComfyUI's native support, from a 3.69 GB int8 checkpoint — and generated 150 seconds of music in 35.3 seconds, which is 4.25× realtime against the reference figure's 3.04× on a 24 GB 4090. The full node graph and every parameter are below. What this article does not do is tell you how it sounds: the measurements are mine, the listening is not.

Yesterday's piece looked at whether YuE2 actually beat Suno on the benchmark — short answer, only at four times the sampling budget. This is the other half: does the thing run on hardware normal people own, and what comes out of it.

The claim that turned out not to bind

The model card is specific:

Linux · Python 3.10+ · 24GB NVIDIA GPU with BF16 support

That requirement is for the reference implementation. ComfyUI merged native YuE2 support in PR #16250 on 11 September 2026, and a separate implementation is not bound by the reference implementation's memory profile. The question was whether the gap was big enough to matter.

It is:

	Reference (model card)	Measured here
GPU	RTX 4090, 24 GB	RTX 5080, 16 GB
OS	Linux	Windows
Checkpoint	full precision	int8, 3.69 GB
Throughput	216 s of audio in 71 s	150 s of audio in 35.3 s
Realtime factor	3.04×	4.25×

The int8 build is why. A 3.69 GB checkpoint fits somewhere a full-precision 3B model plus its text encoder and VAE would not, and it runs faster while doing it. Whether it costs audio quality against the full-precision weights is not something this test can answer — there is no full-precision run on this machine to compare against.

The environment, exactly

GPU        NVIDIA GeForce RTX 5080, 16303 MiB
OS         Windows
Runtime    ComfyUI (native YuE2, PR #16250, merged to master 2026-09-11)
Checkpoint yue2_3b_int8_convrot.safetensors — 3.69 GB

The checkpoint is all-in-one. It carries vae. and text_encoders. prefixes, so a single CheckpointLoaderSimple yields MODEL, CLIP and VAE — no separate loaders, no manual wiring of three files.

From ComfyUI's supported_models.YuE2:

Model type	ModelType.FLOW
memory_usage_factor	4.0
Precision	bf16 / fp32
FRAMES_PER_SECOND	25

The graph

Six nodes, in this order:

CheckpointLoaderSimple
  → YuE2GenerateABC        (writes the symbolic score first)
  → YuE2GenerateMusic      (score + lyrics + style → conditioning, seconds)
  → EmptyYuE2LatentAudio   (seconds comes from the node above)
  → KSampler
  → VAEDecodeAudio
  → SaveAudio

Two details that are easy to get wrong.

EmptyYuE2LatentAudio takes its length from YuE2GenerateMusic, not from you. The music node returns a seconds value as its second output, and you wire that into the latent. Setting a length by hand fights the planner.

The negative conditioning is ConditioningZeroOut of the positive. There is no text negative prompt in this path.

Parameters

YuE2GenerateABC — the score stage:

mode	full
max_abc_tokens	8192
temperature	0.7
top_p	0.9
top_k	30
repetition_penalty	1.005
penalty_window	100

YuE2GenerateMusic — the audio conditioning stage:

mode	full
temperature	1.0
top_p	0.95
top_k	100
repetition_penalty	1.2

KSampler: euler, simple scheduler, 20 steps, cfg 3.0, denoise 1.0.

Note how much gentler the score stage is than the audio stage — temperature 0.7 against 1.0, top_k 30 against 100, repetition penalty 1.005 against 1.2. The score is where structure is decided, so it is sampled conservatively; the audio stage is allowed to vary. That asymmetry is the interesting part of the configuration, and it follows from the architecture rather than from tuning.

The prompt

Style, verbatim:

Dreamy cinematic synthwave with a wide ambient intro, warm analog pads,
a slow four-on-the-floor pulse, glassy arpeggios and a soft female vocal
floating on top. Nocturnal, spacious, hopeful. 92 BPM, A minor.

Lyrics were supplied with explicit section tags — [Intro], [Verse], [Chorus], [Outro] — including two empty ones. The empty [Intro] and [Outro] are doing work: they reserve instrumental sections without giving the model words to sing there.

Timings

Four runs, all with the ABC stage enabled, 20 steps, cfg 3, pulled from ComfyUI's execution history:

Requested	Wall clock	Realtime factor
30 s	12.1 s	2.48×
30 s	14.6 s	2.05×
150 s	35.3 s	4.25×
195 s	39.2 s	— (see below)

Longer requests are more efficient — the fixed cost of the score stage amortises. At 30 seconds you are paying setup; at 150 you are paying for music.

The 195-second request returned 166.84 seconds. The model stopped 28 seconds short and did not error. If you need an exact duration, the length you ask for is a ceiling rather than a target.

I did not capture peak VRAM during the runs, so I cannot tell you the headroom on a 16 GB card — only that it completed without falling back or erroring.

What came out, measured

Three takes, analysed with ffmpeg. These are properties of the files, not opinions about the music.

	30 s take	150 s take	166.84 s take
Format	FLAC 48 kHz / 16-bit stereo	same	same
Duration	30.00 s	150.00 s	166.84 s
Integrated loudness	−12.99 LUFS	−12.98 LUFS	−12.41 LUFS
True peak	+0.65 dBTP	+1.44 dBTP	+0.92 dBTP
Loudness range	16.70 LU	6.00 LU	10.20 LU
Dead air > 0.8 s	none	none	none

Every take clips. All three exceed 0 dBTP, the 150-second one by 1.44 dB. That is inter-sample clipping in the raw output — it is not a mastering choice, because nothing has been mastered. Anything you do with these files should start with a limiter or a loudnorm pass. It is a small thing that will bite anyone who drops the output straight into a video timeline.

The loudness range differences are worth noting too: 16.70 LU on the short take against 6.00 on the long one. The longer generation is far more compressed in dynamics — consistent with it settling into a steady section rather than moving through an arc.

The 48 kHz is real

A 48 kHz file proves nothing on its own; upsampled 16 kHz content is still a 48 kHz file. So, energy by band, relative RMS:

Band	30 s	150 s	166 s
20 Hz – 4 kHz	−14.7 dB	−14.8	−14.2
4 – 10 kHz	−36.2	−31.8	−30.9
10 – 14 kHz	−38.9	−35.2	−36.4
14 – 16 kHz	−41.5	−38.7	−40.0
16 – 20 kHz	−42.8	−40.2	−41.5
20 – 23 kHz	−53.6	−51.0	−52.3

There is no cliff at 16 kHz. The 16–20 kHz band sits about 1.3 dB below 14–16 kHz — a smooth roll-off, not the wall you get from upsampled lossy material. The drop above 20 kHz is where real instruments run out too. The bandwidth is genuine.

The structure is visible

Reading the 150-second take without listening to it:

• 0 – ~30 s — sparse, low-frequency weight only. The wide ambient intro that was asked for.
• ~32 s onward — full-band energy arrives with heavy vertical striping. Vertical stripes are transients; that is the four-on-the-floor pulse.
• ~65 s — a clean discontinuity, a section boundary rather than a glitch.
• ~110 – 118 s — a near-silent break, visible as a dark column. Structure, not a dropout: it recovers into the densest passage in the piece.
• to the end — sustained dense section.

Intro, entry, section change, breakdown, outro. The requested structure is present in the file, which is the thing the symbolic score stage is supposed to deliver. Whether the music is good is a different question and not one a spectrogram answers.

What I cannot tell you

How it sounds. I measured these files; I did not listen to them. Nothing above is a judgement on musicality, the vocal, lyric intelligibility, or whether the chorus lands. Any article that tells you an AI song is "surprisingly musical" on the strength of a spectrogram is making it up.

How int8 compares with full precision. No full-precision run exists on this machine. The quantised build is fast and completes; whether it loses anything audible against the reference weights is untested here.

Peak VRAM. Not captured during the runs. The model loads and completes on 16 GB, which is the useful part, but I cannot tell you how close it came to the limit.

Whether this generalises. One style prompt, one lyric set, one seed family, four runs. Synthwave at 92 BPM is a forgiving target — sparse, pad-driven, tolerant of timing drift. A dense acoustic arrangement would be a harder test and has not been run.

The practical summary

The 24 GB Linux requirement is about the reference implementation, not the model. On ComfyUI with an int8 checkpoint, a 16 GB Windows card runs it, faster in realtime terms than the published 4090 figure.

Ask for longer takes. The score stage is a fixed cost. 150 seconds ran at 4.25× realtime against 2.48× for 30 seconds.

Treat the requested duration as a ceiling. 195 s asked, 166.84 s delivered, no error.

Normalise before you use anything. Every take clipped.

And remember the licence. The weights are CC BY-NC 4.0. All of the above is about whether it runs, not whether you may ship what it makes.

FAQ

Can YuE2 run on a 16 GB GPU?

Yes, in this test. ComfyUI's native implementation with the yue2_3b_int8_convrot checkpoint (3.69 GB) ran on a 16 GB RTX 5080 under Windows, despite the model card specifying a 24 GB Linux setup. It generated 150 seconds of audio in 35.3 seconds.

Does it need Linux?

Not through ComfyUI. This test ran on Windows. The Linux requirement in the model card applies to the reference inference package.

How fast is it?

4.25× realtime for a 150-second request on a 16 GB RTX 5080 — faster than the model card's own reference figure of 3.04× on a 24 GB RTX 4090, because of the int8 checkpoint. Short requests are less efficient: 30 seconds ran at about 2.5× realtime.

What settings were used?

A single CheckpointLoaderSimple, then YuE2GenerateABC (temperature 0.7, top_k 30, repetition penalty 1.005, max 8192 tokens) → YuE2GenerateMusic (temperature 1.0, top_k 100, repetition penalty 1.2) → EmptyYuE2LatentAudio → KSampler (euler, simple, 20 steps, cfg 3.0) → VAEDecodeAudio. Negative conditioning is ConditioningZeroOut of the positive.

Is the output really 48 kHz?

Yes. Band-energy measurement shows a smooth roll-off with no cliff at 16 kHz — the 16–20 kHz band is only about 1.3 dB below 14–16 kHz. That is genuine high-frequency content rather than upsampled lossy material.

Is the output ready to use?

Not directly. All three takes exceeded 0 dBTP — up to +1.44 — so the raw files clip. Run a limiter or loudness normalisation before putting them in anything. And the weights are non-commercial regardless.

---

← Back to all posts