YuE2-3B: Self-Host AI Song Generation (AWS, Windows, Kali)

YuE2-3B is a 3-billion-parameter open-weights music model from the Multimodal Art Projection team that turns plain lyrics and a style prompt into finished 48 kHz stereo songs — lead vocal, backing vocals, instruments — and on the authors’ own WildSongBench evaluation it out-scored Suno v5 (6.9632 vs 6.8721 SongBench average, best-of-8). Here is the counterintuitive part: that frontier-quality “Suno rival” peaks at 11.18 GiB of VRAM and generates one song at a time on a single 24 GB NVIDIA card, so self-hosting it is a by-the-hour AWS g5.xlarge or the gaming-class PC you may already own — not a datacenter contract. Welcome back to our another AI series.

Jake runs a phone shop and keeps a gaming-class PC under the counter for repairs and demos. Last week a regular walked in wanting a personal retirement song for her husband — thirty years at the rail yard, a deadline on Friday — and Jake said “sure” before his brain caught up with his mouth. She’s the kind of customer who brings her whole family’s repair business with her; a “no” on Friday quietly reroutes all of it to the shop across the street. Jake burned an hour on a commercial song service and hit its limits, and now he wants to know if the open-source model everyone is talking about will run on his own hardware. Ethan, his mentor on all things with a version number, had opinions ready.

What YuE2-3B Actually Is

YuE2-3B is what the machine-learning world calls a lyrics-to-song model: you hand it a style description (“English rock, expressive lead vocal, piano, brushed drums”) and sectioned lyrics (marked [Verse], [Chorus], and so on), and it hands back a complete song with a singing voice and full accompaniment. It also does two things most single models don’t: it can cover an existing recording in a new style, and it lets you edit the composition itself — the melody and chords — before the final audio is rendered. The authors’ tagline for the architecture is “compose in symbols, create in sound.”

Under the hood, the model card describes one AR–NAR Mixture-of-Transformers backbone. Unpacking that, because you should never have to open a second tab: AR is autoregressive, meaning it writes its output left to right, one piece at a time, the way you type a sentence. NAR is non-autoregressive, meaning it fills in many pieces at once, the way you’d paint a wall after the sketch exists. The model uses both: the autoregressive half writes the musical score and the semantic tokens — tokens being the small chunks of sound and meaning the model produces one at a time, like words in a sentence — and the non-autoregressive half generates the actual audio in bulk. A Mixture-of-Transformers is simply that two-counter arrangement inside one model: one counter handles the planning, the other handles the sound.

From there the card says the model produces acoustic latents through flow matching, and a VAE turns them into stereo audio. Flow matching is the technique of sliding smoothly from pure noise toward music — imagine tuning a radio dial from static to a clear station, except the model learns the entire journey. The VAE (variational autoencoder) is the printer at the end of the line: the model’s internal sketch becomes actual 48 kHz stereo sound. The score it writes along the way uses ABC notation, which is sheet music written as plain text — the letters A through G for notes, plus symbols for rhythm and chords — and that score is the editable part. You can open it, read it, change one chord, and re-render the whole song.

About that leaderboard: the authors are careful to say the small gap between the highest means “does not establish statistical significance,” which is a rare and honest line in a model release. For context, the same table lists Mureka 9 at 6.9377, Suno v5 at 6.8721, and Suno v4.5 at 6.6995 — so YuE2 sits in a cluster at the top rather than standing alone. What is not in dispute is the price of admission: the proprietary systems in that table are services you rent, and YuE2’s weights are downloadable.

“So it’s a free Suno,” Jake said, the way he says things that are about to be corrected.

“It’s a downloadable Suno-class model,” Ethan answered. “The word ‘free’ is doing sneaky work in that sentence, and we’ll get to why. But the engineering part — the part you’re actually asking about — yes. A 3B model that competitive, running on one card. That part is genuinely remarkable.”

The Hardware Reality Check

The model card’s supported baseline is specific: Linux, Python 3.10+, a 24 GB NVIDIA GPU with BF16 support, 24 GB of available host RAM, one song at a time, no quantization. Two of those terms deserve a plain sentence. VRAM is the memory that lives on the graphics card itself — think of it as counter space in a tiny kitchen; the model, its working notes, and the song in progress all have to fit on that counter at once. BF16 (bfloat16) is a number format that carries roughly half the digits of a standard float, letting the card do math about twice as fast on hardware that supports it — which is why “with BF16 support” is part of the requirement and not decoration. And quantization — the trick of shrinking a model’s numbers so it fits into less memory, at some cost in quality — is not part of the documented path here: the card’s numbers are full-size weights, measured as shipped.

Here is what the authors actually measured, from the speed-and-resources table on the model card. The HF inference package uses PyTorch 2.10, Transformers 4.57.6, CUDA graphs, and FlashAttention, with BF16 for the language-model stages and FP32 for the VAE — in plain terms: CUDA is NVIDIA’s software layer that lets programs talk to the GPU, CUDA graphs record a stretch of GPU work once and replay it with less overhead, and FlashAttention is a faster, leaner way for the model to look back at everything it has generated so far; FP32 is the full-precision number format reserved for the delicate audio decode. The rows are the authors’ measurements in full CoT mode — the default melody-and-chords planning mode; the cot settings get a section of their own below:

The “LM tokens/s” column is language-model tokens per second — how fast the writing half of the model works. Read the middle row the way a shopper reads a price tag: a 3.6-minute song takes 71 seconds of generation on an RTX 4090, with another 214.85 seconds of audio decode on top — roughly five minutes wall-clock for the whole pipeline. And the memory ceiling the authors report across all their maximum-context testing is 14.08 GiB. An 80-gigabyte server card uses less VRAM than a 24-gigabyte consumer card leaves idle. Ethan’s pizza-truck line lives here: “Don’t buy an 80-gigabyte card for a 3B model. That’s a delivery truck to move one pizza.”

What does not fit: cards below the documented envelope. An 8 or 16 GB card is outside the supported baseline, and the skill documentation is blunt about the honest response — free your memory allocations or move to suitable hardware, and do not silently shorten the song or lower inference settings to hide an out-of-memory error. That last instruction is worth internalizing, because a truncated song that “completed” is the most annoying possible failure mode: no crash, just a missing final chorus.

Read the License Before the README

This is the section most write-ups bury below the fold, and it changes the math more than any GPU spec does.

In plain US English: if you make a song with YuE2-3B, you can share it, remix it, and build on it — and you can never sell it or use it to sell something. Jake’s retirement-song customer is fine: a gift is not commerce. Jake’s nephew’s garage band is not fine the moment money changes hands. If your plan involves a storefront, a paid demo service, or a client invoice, the CC BY-NC 4.0 terms point you toward a commercial license conversation with the rights holders rather than a workaround — and no amount of self-hosting changes that, because the restriction travels with the weights, not the server.

“The model is the cheap part,” Ethan told him. “The thing everyone skips is the license. You self-host to get freedom and privacy and no subscription — not to get a business model. Read the NC part twice.”

Self-Hosting on AWS: Pick the Instance and the AMI

AWS’s G5 family is the natural home for this workload, because each G5 instance carries NVIDIA A10G Tensor Core GPUs with 24 GB of memory per GPU per AWS’s G5 product page — which meets the model card’s documented 24 GB requirement exactly. The EC2 instance-types specification table lists the g5.xlarge’s GPU allocation as 22 GiB (1 × 22 GiB) alongside 4 vCPUs, 16 GiB of system RAM, a 2nd Gen AMD EPYC 7R32 processor, up to 10 Gbps of network bandwidth, and a 250 GB NVMe SSD instance store. Since YuE2’s worst-case measured peak is 14.08 GiB, the A10G clears the documented envelope with room to spare.

One wrinkle: the model card also asks for 24 GB of available host RAM, and the g5.xlarge’s 16 GiB is under that. The g5.2xlarge — same single A10G, 8 vCPUs, 32 GiB of RAM, per the same EC2 spec table — is the size that satisfies both lines of the requirement without renting a second GPU you won’t use.

For the operating system, skip the blank-Ubuntu-plus-manual-CUDA dance and use the Deep Learning OSS Nvidia Driver AMI GPU PyTorch 2.9 (Ubuntu 24.04). AWS’s DLAMI documentation lists G5 among its supported instance families, and it ships with the NVIDIA driver and PyTorch 2.9 preinstalled. One detail from the DLAMI release notes worth knowing before you’re confused by it: starting with PyTorch 2.9, CUDA and its libraries live inside the PyTorch virtual environment at /opt/pytorch/cuda rather than at the system level, so you activate the environment with source /opt/pytorch/bin/activate before anything CUDA-shaped will resolve.

An AMI, by the way, is an Amazon Machine Image — a preinstalled disk snapshot, the cloud equivalent of a laptop that arrives with the software already loaded. The release notes page for this AMI shows current releases dated through August 28, 2026, and AWS documents two ways to always resolve the latest one: an SSM parameter (a named pointer AWS keeps updated to the current version) or a plain EC2 API query:

aws ssm get-parameter --region us-east-1 \
  --name /aws/service/deeplearning/ami/x86_64/oss-nvidia-driver-gpu-pytorch-2.9-ubuntu-24.04/latest/ami-id \
  --query "Parameter.Value" --output text

aws ec2 describe-images --region us-east-1 --owners amazon \
  --filters 'Name=name,Values=Deep Learning OSS Nvidia Driver AMI GPU PyTorch 2.9 (Ubuntu 24.04) ????????' \
  'Name=state,Values=available' \
  --query 'reverse(sort_by(Images, &CreationDate))[:1].ImageId' --output text

1. Resolve the current AMI ID with the SSM parameter above (or find the AMI by name in the EC2 console’s launch screen).
2. Launch a g5.2xlarge on that AMI — or a g5.xlarge if you accept the 16 GiB RAM gap — in your nearest region, with a security group that allows SSH from your IP only. SSH is the encrypted remote-terminal protocol you’ll use to drive the machine from your own desk.
3. Give the root volume enough space for the model weights plus the virtual environment; the model files download from Hugging Face on first use and a small default root volume will not survive that.
4. Connect over SSH and run nvidia-smi to confirm the A10G and the driver are visible before you install anything.
5. When you’re done for the day, stop (or terminate, if you launched a Spot instance — AWS’s cheaper, interruptible pricing class) the machine: the meter runs while it’s running, and current pricing lives on AWS’s EC2 On-Demand pricing page, which changes often enough that a number quoted here would be stale before you read it.

Install YuE2-3B and Generate Your First Song

Once you’re connected to the instance, activate the AMI’s PyTorch environment and install the YuE2 inference package. The model card’s quick start gives the exact three lines: a pinned huggingface-hub, a download of the wheel from the model repository, and the install itself. A wheel is just a prebuilt Python package file — the .whl is the installable artifact.

source /opt/pytorch/bin/activate

python -m pip install huggingface-hub==0.36.2
hf download m-a-p/YuE2-3B yue2_infer-0.1.5-py3-none-any.whl --local-dir .
python -m pip install ./yue2_infer-0.1.5-py3-none-any.whl

One warning the skill documentation states in bold, and which we will repeat just as firmly: do not substitute an unverified package with a similar name from PyPI. The runtime pins its own dependencies (PyTorch 2.10.0, Transformers 4.57.6, NumPy 2.2.6 per the setup reference), and a lookalike package is how dependency versions quietly stop matching the model. One versioning note so nothing surprises you: the model card’s quick start pins the 0.1.5 wheel, while the repository’s release links point at a v0.1.6 wheel archive — both are the authors’ own artifacts; whichever you install, build the whole environment around that one version rather than mixing.

The GitHub route is equally documented, and is what you’ll use on the local machines later: clone the official repository, make a virtual environment (a venv is an isolated Python sandbox — a separate workbench so this project’s pinned tools can’t collide with your system’s), and install the package from source. The quick start in the repository uses Python 3.12:

git clone https://github.com/multimodal-art-projection/YuE.git
cd YuE
python3.12 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install .
python examples/generate.py --output outputs/first-song

Either route ends the same way. The Python interface from the model card, using their own demo request so you’re not inventing a style prompt on your first run:

import json
from pathlib import Path
from yue2 import YuE2Pipeline

pipe = YuE2Pipeline.from_pretrained("m-a-p/YuE2-3B", device="cuda")

# The card's own demo (the Mandarin funk / nu-disco song):
from huggingface_hub import hf_hub_download
repo = "m-a-p/YuE2-3B"
prompt_path = hf_hub_download(repo, "examples/tonight-awake.json")
demo = json.loads(Path(prompt_path).read_text(encoding="utf-8"))
style, lyrics = demo["style"], demo["lyrics"]

song = pipe(style=style, lyrics=lyrics, cot="full", seed=demo["seed"])
song.save("song.flac")
song.save_artifacts("outputs/song")   # ABC, tokens, latents, audio and settings

That save_artifacts call is more valuable than it looks: the output directory keeps the audio (audio.flac), the editable ABC score, the exact token IDs, the acoustic latents (latent.npy), the request, the configuration, the timing, and the model identities and hashes — everything you need to reproduce or edit that exact song later. The save method writes FLAC or WAV; the skill documentation notes that MP3 is a separate delivery conversion you’d do afterward with your own tool. Generation prints English progress messages by default, including the current stage and token throughput; the card tells you how to silence them (progress=False in from_pretrained, or yue2 generate --quiet / yue2 batch --quiet on the command line).

“Five minutes for one song,” Jake said, doing the arithmetic on the 4090 numbers. “So Friday’s deadline is fine, but a whole album in an evening is a fantasy.”

“One song at a time is the supported baseline on the HF package — that’s the card’s phrasing, not a limitation I’m inventing,” Ethan said. “There’s a serving runtime for batches of people; there is not a documented mode for batch-generating forty songs on one 24-gig card tonight. Plan the evening accordingly.”

Running It Locally on Windows 11 (the WSL 2 Route)

The model card’s quick start line reads “Linux · Python 3.10+” — native Windows is not the documented path, and this page will not pretend otherwise. The documented bridge is WSL 2, the Windows Subsystem for Linux: a real Linux kernel running inside Windows, so the Linux instructions apply with almost no changes. Microsoft’s WSL documentation lists Ubuntu among the distributions you can install — and, in a detail that fits this article’s exact audience, it lists Kali too, so one Windows machine can genuinely host either local route below. For YuE2, Ubuntu is still the saner host: you want a quiet, standard Linux for CUDA work, not a rolling pentest distribution. Microsoft’s Enable NVIDIA CUDA on WSL 2 guide exists precisely for this scenario — CUDA machine-learning workloads running inside WSL using an NVIDIA driver installed on Windows.

Microsoft’s install documentation is refreshingly short: the single wsl --install command enables the required Windows components, downloads the latest Linux kernel, sets WSL 2 as the default, and installs a Linux distribution for you (Ubuntu by default). It requires Windows 10 version 2004 (build 19041) or later, or Windows 11. On Windows 11 you run it from an elevated PowerShell — Microsoft’s own phrasing for that step is Start menu > PowerShell > right-click > Run as Administrator. (A small Windows 11 trap while you’re in the file explorer later: the right-click menu is condensed, and the legacy entries live under Show more options — worth knowing when a guide tells you to right-click something that isn’t in the modern menu.)

1. Open PowerShell as Administrator (Start menu > PowerShell > right-click > Run as Administrator) and run wsl --install. Reboot when Windows asks you to.
2. Install the NVIDIA driver for Windows — Microsoft’s “Enable NVIDIA CUDA on WSL 2” documentation directs you to the CUDA-enabled driver for WSL, which is the ordinary Windows-side driver; WSL uses that driver rather than needing its own.
3. Launch Ubuntu from the Start menu and finish the first-run username setup.
4. Inside Ubuntu, follow the same Linux install as the AWS section — either the pinned-wheel route or the git-clone-and-venv route — then run the same YuE2Pipeline.from_pretrained example.
5. If CUDA isn’t visible inside Ubuntu, NVIDIA’s CUDA on WSL user guide is the official troubleshooting reference; the fix documented there is the Windows-side driver, not a driver installed inside WSL.

One honest Windows 10 note, because plenty of readers are on it: WSL 2 works on Windows 10 version 2004 and later per Microsoft’s prerequisites, but Windows 10 passed its end of support on October 14, 2025 — a machine on 10 without Extended Security Updates enrolled is running unsupported, which is a poor foundation for a CUDA stack you plan to keep. The Windows 11 path is the one this guide walks.

Running It Locally on Kali Linux

Kali is a rolling, Debian-based distribution — current release 2026.2, Xfce desktop by default, Linux kernel 6.19 per the Kali release notes — and everything about installing NVIDIA drivers on it is documented on kali.org. The one structural thing to know first: Kali is rolling, meaning packages update continuously rather than in scheduled big releases, and that has a specific consequence for GPU work. The NVIDIA driver is built as an out-of-tree kernel module through a system called DKMS (the machinery that rebuilds the driver every time the kernel updates), and kernel headers must be installed for that build to succeed. Skip the headers, and a routine kernel update can leave you at a blinking cursor instead of a desktop.

The official Kali NVIDIA guide also states its scope plainly: it covers an installed Kali (bare metal or a VM with real GPU passthrough) — not a live-booted session, live boot meaning running Kali straight from the USB stick without installing — and it installs the closed-source NVIDIA driver in place of the open-source nouveau one. It recommends CUDA compute capability above 5.0 on your card. The documented sequence, from kali.org’s own page:

1. Confirm the contrib, non-free, and non-free-firmware components are enabled in your repositories — on Kali 2026.2 the sources live in the DEB822-format file /etc/apt/sources.list.d/kali.sources, and the documented check is grep "contrib non-free" /etc/apt/sources.list.d/kali.sources.
2. Update fully: sudo apt update then sudo apt -y full-upgrade. Kali has no root login by default, so sudo is the way.
3. Install the headers for your running kernel: sudo apt install linux-headers-$(uname -r) -y, and reboot if /var/run/reboot-required exists.
4. Install the driver and CUDA toolkit together: sudo apt install -y nvidia-driver nvidia-cuda-toolkit. The installer will warn that nouveau conflicts with the NVIDIA module and that a reboot is the clean fix.
5. Reboot, then verify with nvidia-smi — the Kali guide shows exactly what a healthy output looks like, with your GPU listed and the driver version on the header line.

One Kali-specific trap that has bitten plenty of people mid-install, and that kali.org documents a fix for: if apt update fails with an error like Sub-process /usr/bin/sqv returned an error code, that is APT’s signature verifier rejecting an expired repository signing key — Kali’s keys are periodically re-extended. The documented repair is to fetch the fresh keyring directly:

wget https://archive.kali.org/archive-keyring.gpg -O /usr/share/keyrings/kali-archive-keyring.gpg
sudo apt update

With the driver healthy, the Python side is ordinary Debian-land: install python3-pip and python3-venv from the Kali repositories (both documented on kali.org’s tools pages), create a virtual environment for YuE2, and run the same pinned-wheel or git-clone install from the AWS section. If you plan to try the cover workflow later, give SheetSage2 its own venv — the setup reference is explicit that the two projects pin different PyTorch, Transformers, and NumPy versions, and a shared environment is how both break at once.

Jake’s nephew’s garage band has a Kali box they use for exactly this kind of thing — three of them sharing a machine that one of them rebuilt twice — and the group chat’s verdict after the driver install was that the scary part took ten minutes and the venv took two. The song took five minutes per attempt, which is the part nobody believes until the progress messages start scrolling.

The Three Generation Modes, and What Each One Is For

Every generation call takes a cot argument (chain-of-thought, in the authors’ naming — how much the model “thinks” in symbols before it sings) that decides how much symbolic planning happens before the audio. This is the single most important knob on the model, and the documentation describes all three settings precisely:

How you fill the two text fields matters more than any knob, and the skill documentation is unusually specific about it: put genre, instruments, vocal character, language, and intended tempo in the style; put the section tags and the actual words in the lyrics; and keep implementation notes out of the lyrics — the lyrics field is a lyric sheet, not a prompt. It also warns against a clever trick that doesn’t work: each cot mode selects its own native instruction, and you cannot override that by pasting your own instruction text into the style prompt. The request schema has one more alias worth knowing — tags is accepted as a synonym for style, and if you supply both they must agree.

Two controls sit next to the mode. cfg_scale is the text-guidance strength — how strictly the model obeys your style prompt, with 1.0 as the no-guidance baseline and the card suggesting 1.2 for stronger guidance if you want to experiment. seed makes a run reproducible: the authors’ own cover example pins seed=831001, and the skill docs treat pinned seeds plus saved artifacts as the way to make a claim about a song checkable. What the request doesn’t accept is just as documented: there is no field for reference audio, phoneme alignment, BPM, a negative prompt, or a reference singer. Tempo and meter belong in the ABC; vocal character belongs in the style text.

For power users, the pipeline is also exposed stage by stage — pipe.plan() then pipe.generate_semantic(plan) then pipe.synthesize(semantic) then pipe.decode(latents), with pipe.close() when you’re finished. The staged form is what the editing workflows are built on, and there’s a decoder choice at load time: YuE2-Vae is the default listening decoder, while vae="m-a-p/YuE2-Vae-legacy" in from_pretrained selects the benchmark decoder the authors used for their reported evaluation numbers.

Cover Songs: From a Recording to a New Arrangement

The cover workflow is the feature that made Jake’s customer idea feel possible at all, and the model card documents it as a three-step chain. First, transcribe the existing recording with SheetSage2 (the authors’ companion model) and save the melody as ABC without chord symbols — the point of removing the chords is that the new style gets to invent its own harmony. Second, get the lyrics: the card suggests asking an agent to find them, or transcribing the vocal with Qwen3-ASR or the Gemini API, then organizing the words into sections that match the recording. Third, generate with cot="melody" and your target style:

cover = pipe(
    style="Jazz-funk, warm lead vocal, Rhodes piano, electric bass, tight drums",
    lyrics=Path("cover_lyrics.txt").read_text(encoding="utf-8"),
    abc=Path("melody.abc").read_text(encoding="utf-8"),
    cot="melody", seed=831001,
)
cover.save("cover.flac")

The part every guide skips and the skill documentation does not: SheetSage2 runs in its own environment. Its pins are different from YuE2’s — the setup reference gives Python 3.10 or 3.11, torch==2.8.0 with torchaudio==2.8.0 from the cu126 index, Transformers 4.45.2, NumPy 1.24.3, and FFmpeg 6.1 on the host — and it loads with trust_remote_code=True, which executes the model repository’s own Python code, so you should use a reviewed revision and record it. The authors’ own phrasing on keeping the environments separate is worth adopting as a rule: a shared Hugging Face cache is fine; a shared venv is not. Run the stages sequentially so each model releases GPU memory before the next one loads.

Editing the Score, and the Agent Skill

Editing is where the “editable scores” claim becomes concrete. You generate once, export the plan with pipe.plan(...) and plan.save("original_plan"), then copy the resulting score.abc to an edited.abc and change whatever the song needs — a reharmonization, a different tempo, a bridge that earns its place. Regenerate with the edited file supplied as abc=, and the model renders a brand-new recording of the revised composition. One documented caveat: editing generates a new complete recording; it does not preserve the original waveform outside the edit. This is not a splice-and-patch audio editor — it is a composer that will re-perform your revision.

The repository also ships an agent skill — a skills/yue2-music/ folder with a SKILL.md that teaches an AI agent (any one that supports skill packages) how to run the whole toolkit: generate, transcribe, cover, edit ABC scores, check musical invariants, and organize listening comparisons. The skill’s helper scripts wrap the documented calls: python scripts/run_yue2.py generate --request assets/prompt.json --output outputs/pop, plus plan and all-modes variants. Its most opinionated rule, and one worth keeping even when you’re driving by hand: retain an original song and its plan before making changes, and inspect the truncation flags in the artifacts before calling anything a finished song — a status of “complete” does not, by itself, mean the song wasn’t cut short.

If node-based tools are how you like to work, ComfyUI’s official documentation includes a YuE2 music-generation guide, wrapping the same 3B model in a node interface — full song structures with intro, verse, chorus, bridge, and outro, and support for multiple singing languages. The model underneath is the same one documented above; the workflow is whichever interface you actually enjoy using.

Serving More Than One User at Once: the vLLM Route

The Hugging Face package is one song at a time. For concurrent requests, the authors document a separate serving runtime — vLLM 0.19 on an H800 server — and publish its throughput numbers alongside the single-GPU ones. vLLM, if the name is new, is a serving engine built to keep many requests in flight at once, the way a restaurant kitchen runs multiple tickets instead of cooking one dish start to finish. The card’s measurements, warm batch throughput through all stages:

Notice what that table quietly says: concurrency 16 buys you roughly three times the songs-per-hour of concurrency 1 on the same 80 GB card — the win is batching, not hardware. And notice the server row the card includes: this runtime is separate from the HF quick start, with PyTorch 2.10 and Triton 3.6 for the language-model stages and PyTorch 2.6 for the VAE. It is not a setting you turn on inside the wheel you installed.

Ethan’s take, in his own voice: “If you’re one person generating one song, vLLM is a race-car pit crew for a bicycle. It’s for teams — a classroom, a studio with a queue, a service with users. Set it up when you have the queue, not before.”

When It Breaks: the Honest Failure Modes

Every fix on this page has a documented failure mode attached to it, and pretending those don’t exist is how a reader ends up stuck at 2 a.m. Here they are in one place, with the cause named rather than the symptom:

And the section nobody writes, which is the one you need at the end of a bad evening: when nothing works. If your card is under the envelope, no flag combination fixes physics — the honest move is the AWS section, a g5.2xlarge, and a closed browser tab. If your plan needs to sell the output, no amount of self-hosting launders the CC BY-NC 4.0 weights — the honest move is a different model or a license conversation. If the import fails and the versions don’t line up, the honest move is a fresh venv and the pinned install from scratch, in that order, before you start editing dependency versions by hand. What we cannot tell you is which of these your machine will hit, because nobody in this chain ran any of it — the measurements above are the authors’ measurements, and the failure modes are the ones the documentation names.

Frequently Asked Questions

What GPU do I need to run YuE2-3B?

The documented baseline is a 24 GB NVIDIA GPU with BF16 support, plus 24 GB of available host RAM. In the authors’ measurements the model peaks at 11.18 GiB of VRAM in normal use and 14.08 GiB in their maximum-context testing, so a 24 GB card clears it with headroom while an 8 or 16 GB card is outside the supported envelope.

Does YuE2-3B run natively on Windows 11?

Not as a documented path — the model card targets Linux with Python 3.10 or newer. The supported Windows route is WSL 2: Microsoft’s single wsl --install command sets up Ubuntu inside Windows, the NVIDIA driver is installed on the Windows side, and every Linux command in this guide then runs unchanged inside Ubuntu.

Can I run YuE2-3B on Kali Linux?

Yes, as a standard Linux target. The extra steps are the documented Kali ones: enable the contrib and non-free repository components, install linux-headers for your running kernel, then install nvidia-driver and nvidia-cuda-toolkit, reboot, and verify with nvidia-smi. After that, the pinned-wheel or git-clone install runs as on any Debian-based system.

Which AWS instance type fits YuE2-3B best?

A g5.2xlarge is the documented-requirement fit: one NVIDIA A10G with 24 GB of GPU memory (22 GiB usable per the EC2 spec table), 8 vCPUs, and 32 GiB of RAM, meeting both the VRAM and host-memory lines. A g5.xlarge meets the GPU requirement but has 16 GiB of RAM, under the card’s 24 GB host ask.

How long does one song take to generate?

On an RTX 4090 in full CoT mode, the authors report a 3.6-minute song at 71.04 seconds of generation plus 214.85 seconds of audio decode — roughly five minutes wall-clock for the complete pipeline. An H800 finishes generation faster (54.74 seconds) but audio decode takes similar time.

Can I use YuE2-3B commercially?

No, not under the weights’ default license. The model checkpoint is licensed CC BY-NC 4.0, which permits sharing and adapting but prohibits commercial use. The repository code is Apache 2.0, but the authors’ notices state the weights are separately licensed and that this does not relicense anything else.

What do cot="full", cot="melody", and cot="off" mean?

They set how much symbolic planning happens before audio. “full” plans melody and chords (the default for new songs), “melody” plans melody only with free accompaniment (the documented recommendation for covers), and “off” generates directly from lyrics and style with no editable score. You can also supply your own ABC score with abc= in full or melody mode.

How do I make a cover of an existing song?

Transcribe the recording with SheetSage2 and save the melody as ABC without chord symbols; gather the lyrics (the card suggests Qwen3-ASR or the Gemini API); then generate with cot="melody" and your target style. SheetSage2 needs its own environment — its pinned dependencies differ from YuE2’s.

Does YuE2-3B work with languages other than English?

The model repository lists English and Chinese. The authors’ own demo songs include a Mandarin funk/nu-disco track and a Mandarin-to-English agentic editing walkthrough, so both languages are exercised in their own materials.

Can I run YuE2-3B on an AMD or Intel GPU?

The documented requirement is an NVIDIA GPU with BF16 support, and the measured numbers all come from NVIDIA hardware. There is no AMD or Intel route in the model card, and no documented CPU-only path either — anything along those lines is undocumented territory this guide won’t speculate about.

How do I serve YuE2-3B to multiple users at once?

The Hugging Face package handles one song at a time. For concurrency, the authors document a separate vLLM 0.19 serving runtime on an H800, measured at 119.43 songs per hour at concurrency 1 and 373.53 songs per hour at concurrency 32.

YuE2-Vae or YuE2-Vae-legacy: which decoder should I use?

YuE2-Vae is the default decoder for listening. YuE2-Vae-legacy is the benchmark decoder — the one used for the reported WildSongBench numbers — selected by passing vae="m-a-p/YuE2-Vae-legacy" to from_pretrained. The skill documentation’s advice: don’t infer their roles from the word “legacy,” and keep decoded files separate.

Where do the model weights come from, and can I run offline?

The weights download from the Hugging Face Hub on first use — the repository documents cache_dir and local_files_only options on from_pretrained, along with --model, --revision, and --vae-revision flags in the skill’s helper scripts, so a fully offline run from local snapshots is a supported pattern.

Why did my song get cut off before the last verse?

Truncation is a documented condition: a generation status of “complete” does not imply an untruncated song. Inspect the truncation flags in the saved artifacts along with the duration and the ending before accepting a take, and don’t silently shorten songs or lower inference settings to dodge memory pressure.

How is YuE2-3B different from Suno or Udio?

The proprietary services are closed, rented, and output-only. YuE2-3B’s weights are downloadable, it writes an editable ABC score you can inspect and revise before rendering, it does zero-shot covers and agentic editing from the same checkpoint, and on the authors’ WildSongBench evaluation its best-of-8 average (6.9632) sits above Suno v5’s (6.8721) — with the authors themselves noting the small gap doesn’t establish statistical significance.

Which Python version does YuE2-3B need, and can I share one environment with other models?

The model card says Python 3.10 or newer; the repository quick start uses Python 3.12, and the runtime pins PyTorch 2.10.0, Transformers 4.57.6, and NumPy 2.2.6. Don’t share the environment: SheetSage2 alone pins different versions (Python 3.10/3.11, torch 2.8.0, Transformers 4.45.2, NumPy 1.24.3), so the documented practice is one venv per project, exchanging only files between them.

Revision note. Written September 2026. A YuE2 point release, a DLAMI refresh, or Kali 2026.3 will move the pinned versions on this page — the model card and the release pages are the live truth. If you’ve spent the week between VRAM errors and license fine print, take heart: the hard part is one venv, one driver, and one honest read of the NC clause — and your first full song is closer than it looks. See you on next post!