{"id":2107,"date":"2026-10-22T15:43:33","date_gmt":"2026-10-22T15:43:33","guid":{"rendered":"https:\/\/makingmusic4ever.com\/?p=2107"},"modified":"2026-10-22T15:43:35","modified_gmt":"2026-10-22T15:43:35","slug":"how-to-generate-music-with-the-open-source-yue2-3b-model-on-google-colab","status":"publish","type":"post","link":"https:\/\/makingmusic4ever.com\/index.php\/2026\/10\/22\/how-to-generate-music-with-the-open-source-yue2-3b-model-on-google-colab\/","title":{"rendered":"How to Generate Music with the Open-Source YuE2-3B Model on Google Colab"},"content":{"rendered":"\n

Who owns the song you created with artificial intelligence? The question sounds simple, but the answer can change depending on the plan you pay for, the version of the terms of service and even the month in which you accepted the rules.<\/p>\n\n\n\n

Picture the scene. You spend an afternoon polishing a set of lyrics, choosing a style, generate ten versions and, finally, one of them moves you. You download the file, send it to a friend and maybe use it as the soundtrack for a video from your music school. Six months later, you cancel your subscription because the budget got tight. What happens to that song? Can you still use it? Can you monetize it? And who decides?<\/p>\n\n\n\n

In this post I show an alternative: generating music with an open-source model, YuE2-3B<\/strong>, running on Google Colab. We will first talk about copyright and terms of use, then about the hardware required and, finally, follow a step-by-step guide with code that is ready to copy and paste. Open-source means that the model files and the code to run them are published, and anyone can download and run them independently, as long as they respect the license.<\/p>\n\n\n\n

Before the first note: what you sign when you use a platform<\/h2>\n\n\n\n

Platforms such as Suno are convenient: you write an idea, click a button and minutes later you have a complete song. But that convenience comes with a contract, and it is worth reading the clauses with the same attention we would give to a record deal.<\/p>\n\n\n\n

In 2026, after its agreement with Warner Music Group, Suno rewrote parts of its terms. Language that used to say subscribers owned their songs changed to say they may receive commercial use rights<\/strong>. The company itself explains that, even with those rights, the user is generally not considered the owner of the work, because the output was generated by the platform. The terms also make it clear that there is no guarantee that any copyright will exist in what was generated.<\/p>\n\n\n\n

There are other points. Songs created on the free plan are for non-commercial use only and cannot be monetized. Retroactive rights may be granted in limited cases, but without any guarantee. New terms took effect on September 3, 2026, and introduced download limits: 7 downloads in total on the free plan, 20 per month on Pro and 60 per month on Premier, applying even to songs created before the change. And, according to analyses of the terms, the user grants the platform a broad license to use what is submitted and what is generated to improve its models.<\/p>\n\n\n\n

The company states that, if you cancel, your library stays in your account and songs downloaded as a subscriber keep their commercial rights. So, the problem is not necessarily what is written today. The problem is who writes the rules<\/strong>. They have changed more than once in a few months, they may change again, and you, who depend on the platform to access and download your own material, have no bargaining power at all. It is like composing in a studio that can change the contract after the recording. That is why you should always check the terms currently in force: they may have changed since I wrote this text.<\/p>\n\n\n\n

What changes with an open-source model<\/h2>\n\n\n\n

When you run an open model, the logic is reversed. You download the model files, run them on the machine you own or rented, and the result is an audio file that is in your hands. There is no subscriber account, no download limit and no music-platform clause telling you what you may or may not do with the result. If a service shuts down tomorrow, the model you downloaded keeps working. It is the difference between subscribing to a streaming service and owning your own recording equipment.<\/p>\n\n\n\n

But pay attention to a point many people forget: control is not the same as total freedom<\/strong>. The model has its own license. The YuE2-3B weights (the \u201cweights\u201d are the numbers the model learned, in other words, its knowledge stored in a file) are published under the Creative Commons CC BY-NC 4.0<\/strong> license, which allows non-commercial use and requires attribution to the authors. The inference code we use to run the model is Apache 2.0, which is far more permissive, but it is the weights that define what you can do with the music.<\/p>\n\n\n\n

In practice, this is great for study, teaching, demos, arrangement prototypes, soundtracks for personal projects and experiments. If your goal is to sell or monetize the music, read the license on the model\u2019s official page and, if possible, consult a lawyer who specializes in copyright. I am not a lawyer, this text is not legal advice, and laws vary from country to country.<\/p>\n\n\n\n

There is also the question of authorship. In many countries, copyright protection is tied to human creativity. The more of your own contribution a work contains, such as lyrics written by you, the structure, the arrangement choices and, afterwards, the editing and mixing, the stronger your position tends to be. Use AI as a session musician, not as a substitute for the composer.<\/p>\n\n\n\n

What about the training data?<\/h2>\n\n\n\n

There is a question that still has no definitive answer: the music used to train these models. Lawsuits around the world are debating whether training an AI on protected works is permitted use, and deals such as the one between Suno and Warner show that the market is negotiating the rules while the game is being played. This applies to closed platforms and open models alike, and it is an area of the law that may change in the coming years. So, follow the news and keep a record of which model and which settings you used for each track. The script we will use saves the \u201cartifacts\u201d of each generation, which helps with that.<\/p>\n\n\n\n

On balance, I still think it is better to generate music with an open model under your own control: you know which license applies, you choose the version, you keep your files and you do not depend on a company keeping today\u2019s rules. It is a risk decision, not a guarantee, and each person should weigh their own situation.<\/p>\n\n\n\n

The obstacle: the GPU<\/h2>\n\n\n\n

Music-generation models perform billions of calculations at the same time, and the part that does this heavy lifting is the GPU<\/strong>, the graphics processing unit. Think of the computer\u2019s CPU as an excellent conductor who reads the score note by note, while the GPU is an entire orchestra playing in parallel. To run YuE2-3B at original quality, without compression, the recommendation is a card with about 24 GB of video memory (VRAM), which is where the model has to fit while it works. There are quantized versions, that is, compressed ones with some loss of quality, that run on smaller cards, but the experience is more limited.<\/p>\n\n\n\n

GPUs with that much memory often cost well over a thousand dollars, and in many countries import taxes and exchange rates push the price even higher. For a musician or teacher who just wants to experiment, buying one is like buying a grand piano to find out whether you enjoy playing. The way out is to rent the \u201cstudio\u201d by the hour.<\/p>\n\n\n\n

Google Colab: the rehearsal studio rented by the hour<\/h2>\n\n\n\n

Google Colab<\/strong> (short for Colaboratory) is a Google service that lets you write and run Python code directly in your browser, on the company\u2019s own computers, including machines with a GPU. It works like renting a rehearsal room: you pay for the time you use and, when you finish, you hand the room back.<\/p>\n\n\n\n

The billing model that suits our case best is pay as you go<\/em>. Instead of subscribing to a monthly plan, you buy compute units<\/em>, which are Colab\u2019s currency. When I last checked, the price was US$ 9.99 for 100 units, with no subscription, and the units expire 90 days after purchase, which means three months. An A100 GPU consumes roughly 10 to 15 units per hour, which works out to 7 to 10 hours of use per 100 units, or around US$ 1 to US$ 1.50 per hour. Prices are in US dollars, change over time and may vary by region, so check the Colab pricing page before you buy.<\/p>\n\n\n\n

Since each song takes a few minutes to generate, 100 units yield dozens of generations for a fraction of the price of a graphics card. There are two cautions. The first is that Google does not guarantee which GPU you will get. The second is that units keep being spent while the session is open, even if you are not generating anything. Finished? End the session under Runtime > Disconnect and delete runtime.<\/p>\n\n\n\n

Colab runs on Linux: how to activate the graphics card<\/h2>\n\n\n\n

Under the interface, Colab runs Linux<\/strong> (Ubuntu). This explains a few details in the code: commands that start with an exclamation mark (!) are sent to the Linux terminal, such as apt-get, which installs programs. Commands that start with %%writefile save the content of the cell to a file. A cell is each block of code in the notebook, and you run them one at a time by clicking the play button beside each one.<\/p>\n\n\n\n

Before anything else, activate the graphics card. The one suggested for this model is the A100<\/strong>, which has plenty of memory for it:<\/p>\n\n\n\n

    \n
  1. Go to colab.research.google.com and create a new notebook.<\/li>\n\n\n\n
  2. In the menu, open Runtime > Change runtime type.<\/li>\n\n\n\n
  3. Under Hardware accelerator, choose the A100 GPU.<\/li>\n\n\n\n
  4. Save and click Connect.<\/li>\n<\/ol>\n\n\n\n

    If the A100 is not available at the moment, Colab may offer a different card. In that case, try again later. Our script checks for the GPU right at the start and warns you if none is found.<\/p>\n\n\n\n

    How the Python code works<\/h2>\n\n\n\n

    All the code in this post is written in Python<\/strong>, a language widely used in artificial intelligence and known for being readable, almost like reading a recipe. You do not need to know how to program to use it: you just copy, paste and change a few texts, such as the style and the lyrics.<\/p>\n\n\n\n

    The flow is always the same and resembles studio work. First, we load the model onto the graphics card, like switching on the equipment. Then we define the style<\/strong>, which is the briefing for the band (genre, instruments, mood), and the lyrics<\/strong>, which also carry the structure of the song, with markers such as [Verse] and [Chorus]. Next, we tell it to generate and, finally, we save the audio and the artifacts, which are the auxiliary files of the process, including the melody and chord plan.<\/p>\n\n\n\n

    Two parameters deserve an explanation. The first is cot=”full”. The abbreviation comes from chain of thought<\/em>. Instead of producing the audio in one go, the model first writes a symbolic plan of the song, with melody and chords in ABC notation (a simple text format for writing sheet music), and only then turns that plan into sound. It is like an arranger who sketches the score before calling in the musicians. For covers, the recommended mode is cot=”melody”. The second parameter is the seed<\/strong>: the number that starts the model\u2019s internal draw. With the same seed and the same texts, you tend to get the same result, like repeating the same take. Change the seed and new variations are born.<\/p>\n\n\n\n

    And why do we use a venv? YuE2 requires Python 3.10, while Colab usually ships with a different version. The solution is to create a virtual environment<\/strong>, or venv<\/em>: a folder with its own Python and its own libraries, isolated from the rest of the system. Think of a soundproof recording booth, where what happens inside does not interfere with the studio next door. That is why the scripts are run with \/content\/yue2_env\/bin\/python and not with the default Python.<\/p>\n\n\n\n

    Step 1: create the environment with Python 3.10<\/h2>\n\n\n\n

    In the first cell we install Python 3.10 with apt-get, the program manager of Ubuntu, and create the virtual environment in the \/content\/yue2_env folder. It takes a few minutes to run.<\/p>\n\n\n\n

    # Cell 1: Install Python 3.10 and create the virtual environment (venv)<\/p>\n\n\n\n

    !sudo apt-get update -y<\/p>\n\n\n\n

    !sudo apt-get install -y python3.10 python3.10-dev python3.10-venv<\/p>\n\n\n\n

    !python3.10 -m venv \/content\/yue2_env<\/p>\n\n\n\n

    Step 2: install YuE2<\/h2>\n\n\n\n

    The second cell updates pip (Python\u2019s package installer), installs a specific version of the huggingface-hub library, downloads the YuE2 inference package straight from the official repository on Hugging Face and installs it inside the venv. Hugging Face is a kind of \u201cGitHub for AI models\u201d, where the model files are published. The weights, which take up a few gigabytes, are normally downloaded the first time the script loads the model, so the first run is the slowest.<\/p>\n\n\n\n

    # Cell 2: Install the inference package in the new environment<\/p>\n\n\n\n

    !\/content\/yue2_env\/bin\/python -m pip install –upgrade pip<\/p>\n\n\n\n

    !\/content\/yue2_env\/bin\/python -m pip install huggingface-hub==0.36.2<\/p>\n\n\n\n

    !\/content\/yue2_env\/bin\/hf download m-a-p\/YuE2-3B yue2_infer-0.1.5-py3-none-any.whl –local-dir .<\/p>\n\n\n\n

    !\/content\/yue2_env\/bin\/python -m pip install .\/yue2_infer-0.1.5-py3-none-any.whl<\/p>\n\n\n\n

    Step 3: a quick test with the official example<\/h2>\n\n\n\n

    Before customizing anything, it is worth confirming that everything works by using the demo example from the repository itself. The script below downloads a ready-made request (style, lyrics and seed) and generates the song. If everything goes well, you will have a song.flac file (FLAC is a lossless audio format) next to the notebook.<\/p>\n\n\n\n

    # Cell 3: Create the test file with the official example<\/p>\n\n\n\n

    %%writefile teste_demo.py<\/p>\n\n\n\n

    import json<\/p>\n\n\n\n

    from pathlib import Path<\/p>\n\n\n\n

    from huggingface_hub import hf_hub_download<\/p>\n\n\n\n

    from yue2 import YuE2Pipeline<\/p>\n\n\n\n

    print(“Loading the YuE2Pipeline on the GPU…”)<\/p>\n\n\n\n

    pipe = YuE2Pipeline.from_pretrained(“m-a-p\/YuE2-3B”, device=”cuda”)<\/p>\n\n\n\n

    # Download the demo example from the repository<\/p>\n\n\n\n

    repo = “m-a-p\/YuE2-3B”<\/p>\n\n\n\n

    prompt_path = hf_hub_download(repo, “examples\/tonight-awake.json”)<\/p>\n\n\n\n

    demo = json.loads(Path(prompt_path).read_text(encoding=”utf-8″))<\/p>\n\n\n\n

    style, lyrics = demo[“style”], demo[“lyrics”]<\/p>\n\n\n\n

    print(“Generating the music…”)<\/p>\n\n\n\n

    song = pipe(style=style, lyrics=lyrics, cot=”full”, seed=demo[“seed”])<\/p>\n\n\n\n

    # Save the song and the artifacts<\/p>\n\n\n\n

    song.save(“song.flac”)<\/p>\n\n\n\n

    song.save_artifacts(“outputs\/song”)<\/p>\n\n\n\n

    print(“Generation complete! File saved as ‘song.flac’.”)<\/p>\n\n\n\n

    # Cell 4: Run the test with the venv’s Python 3.10<\/p>\n\n\n\n

    !\/content\/yue2_env\/bin\/python teste_demo.py<\/p>\n\n\n\n

    Step 4: the configurable generation script<\/h2>\n\n\n\n

    This is the script for everyday use. All the options sit in the CONFIGURE HERE block at the top of the file, so that is the only part you need to touch. Here is what each one does:<\/p>\n\n\n\n