A Xiaomi abriu o código dos segredos de treinamento com RL — usei-os para treinar minha própria IA

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Xiaomi Just Open-Sourced Its RL Training Secrets — I Used Them to Train My Own AI · Canal: Prompt Engineer 48 · 16:15 · Assistir no YouTube

Tópicos: Geração de conteúdo com IA, Modelos de IA, Modelos locais e open source

Resumo

O vídeo demonstra como usar ambientes de reinforcement learning abertos pela Xiaomi para treinar um modelo a compor música em notação ABC. Com uma GPU alugada, cerca de 1 hora e 40 minutos de treinamento e aproximadamente US$ 12, a taxa de músicas tocáveis no conjunto de teste subiu de 0,6% para 11,9%. A descoberta decisiva foi que linhas em branco faziam o grader rejeitar composições que, de outro modo, eram válidas; durante o treinamento, o autor deu crédito parcial a esses casos. O resultado ainda é limitado, mas mostra como ambientes com verificadores automáticos podem viabilizar experimentos de RL em pequena escala.

Pontos-chave

A Xiaomi abriu cerca de 7 mil ambientes de reinforcement learning usados no treinamento de MiMo, em áreas como código, cibersegurança, conhecimento geral, web design e música.
Os ambientes incluem verificadores automáticos, além de dados e código de treinamento.
O experimento usou o ambiente de música, notação ABC e um grader em Python que avalia seis dimensões musicais.
O treinamento com GRPO compara várias respostas para o mesmo prompt e favorece as que pontuam melhor em relação às demais.
O modelo base frequentemente produzia linhas em branco que encerravam a música em ABC e levavam o grader a atribuir nota zero.
Durante o treinamento, composições rejeitadas apenas por linhas em branco receberam crédito parcial; a avaliação final não teve essa correção.
Em 40 prompts de teste não vistos no treinamento, a proporção de músicas tocáveis subiu de 1 em 160 para 19 em 160.
O comprimento médio das respostas caiu de cerca de 2.100 para 1.250 tokens, resultado atribuído à penalidade de comprimento.
O resultado final ainda é modesto: o autor ressalta que o grader mede semelhança com música humana, não beleza musical.

Capítulos

Início	Capítulo	Resumo
00:01	O experimento e os ambientes abertos pela Xiaomi	O autor apresenta a melhora na geração de música e explica o que a Xiaomi disponibilizou para treinamento com reinforcement learning.
03:13	Como funciona o treinamento e a avaliação musical	O vídeo explica GRPO, a notação ABC e o grader que avalia as composições.
06:01	O problema das linhas em branco	Os testes iniciais revelam que linhas em branco fazem o grader rejeitar muitas músicas, levando o autor a criar um sinal de recompensa parcial para o treinamento.
08:10	Preparação dos dados e código	O autor descreve o conjunto de treino e teste, o pré-teste do grader e as configurações de GRPO e do adapter.
11:22	Execução e resultados do treinamento	Após resolver problemas de configuração e memória, o treinamento termina e a avaliação em prompts não vistos mostra a melhora na taxa de músicas tocáveis.
14:08	Teste cego e compartilhamento do modelo	O autor apresenta um teste de escuta, explica como mesclou e publicou o modelo e conclui com as limitações e próximos passos.

Citações

O RL só pode melhorar aquilo que o modelo às vezes já consegue fazer. — 04:53

O modelo sabe escrever música; ele só tem um mau hábito. — 07:39

12% ainda é pouco. — 13:35

Encontrar o problema das linhas em branco foi o verdadeiro ponto-chave. — 15:43

Conceitos e entidades

reinforcement learning (conceito): Método de treinamento em que o modelo recebe sinais de recompensa por suas respostas.
GRPO (conceito): Método que compara respostas de um mesmo grupo e favorece as que obtêm resultados melhores que a média do grupo.
ABC notation (conceito): Notação musical em texto que pode ser convertida em MIDI e, depois, em áudio.
MiMo-V2.6 (modelo): Família de modelos da Xiaomi apresentada no vídeo junto aos ambientes e materiais de treinamento abertos.
MiMo 2.6 Distill 9B (modelo): Modelo de 9 bilhões de parâmetros disponibilizado como ponto de partida para experimentos de reinforcement learning.
Qwen3 8B (modelo): Modelo usado como base para o treinamento e para a versão final compartilhada pelo autor.
Xiaomi (empresa): Empresa que abriu os ambientes de reinforcement learning, os dados e materiais de treinamento mencionados no vídeo.
Hugging Face (ferramenta): Plataforma em que o vídeo consulta o conjunto de dados e publica o modelo e o adapter treinado.
RunPod (ferramenta): Serviço usado para alugar a GPU empregada no experimento.
TRL (ferramenta): Biblioteca usada no código de treinamento com GRPO.
GGUF (conceito): Formato em que o autor também disponibilizou o modelo para execução local.

Tradução completa (pt-BR)

00:01 Certo. Neste vídeo, veremos como treinei um modelo para compor música. À esquerda, está o modelo-base. Ele não consegue escrever nem uma música que dê para tocar. À direita, está o mesmo modelo depois do reinforcement learning (RL). E dá para ouvir que ele está realmente tocando uma música. Vale lembrar que o método, os dados e o avaliador — tudo isso — foi disponibilizado como open source pela Xiaomi no lançamento do MIMO versão 2.6. Peguei o ambiente de música deles

00:33 e usei uma GPU alugada por cerca de 1 hora e 40 minutos de treinamento, gastando aproximadamente US$ 12. Passamos de menos de 1% de músicas tocáveis para quase 12% — cerca de 20 vezes mais. Neste vídeo, vou mostrar, do começo ao fim, como preparar o sistema, obter os dados, treinar o modelo, conseguir o adapter, mesclá-lo e usá-lo. Então, vamos começar. Esta é a novidade: a Xiaomi acabou de disponibilizar como open source cerca de 7.000

01:04 ambientes de RL, ambientes de reinforcement learning que eles usaram para treinar o MIMO em áreas como programação, cibersegurança, conhecimento geral, desenvolvimento web e música. Muita gente está chamando isso de um dos maiores acontecimentos relacionados a dados de ambientes de RL open source. E eu concordo mesmo. O MIMO versão 2.6 vem em dois tamanhos. O Pro é um modelo mixture of experts com 1 trilhão de parâmetros, dos quais 42 bilhões são ativos, e o Flash tem 310

01:37 bilhões de parâmetros, dos quais 15 bilhões são ativos. Mas, mais do que os modelos, o realmente interessante é o que mais eles lançaram. Se você acessar o Hugging Face, verá este conjunto de dados: Mimo versão 2.6 RLS. Ele tem cinco subconjuntos: code, cyber, general, webdev e music. E não são apenas prompts. São ambientes completos, com verificadores, o que significa que, para cada tarefa, há uma maneira de checar automaticamente se o modelo fez tudo certo. E também temos o

02:08 código de treinamento. Eles fizeram um fork do veRL, uma biblioteca de treinamento de RL da ByteDance, e adicionaram suas receitas por cima. Gosto de pensar assim: a ByteDance construiu o prédio da escola, e a Xiaomi escreveu o currículo, as provas, as avaliações e as regras contra trapaça — e depois entregou tudo isso. Também lançaram um modelo pequeno de 9 bilhões, o MIMO versão 2.6 distill 9 billion, como ponto de partida para seu próprio reinforcement learning. E, no relatório técnico,

02:41 eles até informam os custos: gastaram cerca de US$ 2,6 milhões em RL para o modelo Pro e cerca de US$ 900 mil para o modelo Flash. A ideia principal do artigo é bem simples. Se você continuar aumentando a escala do reinforcement learning — mais computação, mais ambientes e avaliadores melhores —, o modelo continua melhorando. Dá para ver todas as linhas dos benchmarks subindo conforme aumentam as etapas de treinamento. Então, quis testar essa ideia por conta própria, com um orçamento pequeno, e escolhi o ambiente de música

03:13 e vou explicar por quê. Música é de turno único. Não há sandboxes do Docker nem LLM as a judge, e o avaliador é feito inteiramente em Python. É o ambiente mais fácil de executar em uma GPU. Além disso, dá para ouvir os resultados, o que é bem mais divertido do que olhar resultados de testes de código. Antes de entrar no código, deixe-me explicar rapidamente como esse treinamento funciona, porque é bem simples quando você entende. Damos ao modelo um prompt. Por exemplo: “componha uma peça tranquila e superficial em mi menor”. Em vez de uma resposta, o

03:45 modelo escreve oito respostas diferentes para o mesmo prompt. Aqui estão essas oito tentativas. Depois, o avaliador dá uma nota a cada uma. Algumas recebem zero, outras tiram uma nota boa. E aqui está o ponto principal: não comparamos as respostas com uma resposta perfeita. Comparamos cada resposta com a média do próprio grupo. Assim, se uma resposta for melhor do que as outras do grupo, incentivamos o modelo a fazer mais daquilo. E, se for pior, o desincentivamos. É só isso. Isso é GRPO, ou otimização de política relativa ao grupo. Repetimos o processo para

04:19 muitos prompts e muitas etapas, e o modelo aprende aos poucos o que agrada ao avaliador. A Xiaomi acrescentou alguns truques, e um deles também usei aqui: a penalidade por comprimento. Se duas respostas estiverem corretas e uma for muito mais longa do que a outra dentro do grupo, a mais longa recebe uma pequena penalidade. Assim, o modelo aprende a ser correto e conciso. Essa é a equação quatro do artigo, e são cerca de 10 linhas de código, que vou mostrar. E há uma coisa importante que o artigo diz, e que veremos

04:53 em ação daqui a pouco: às vezes, o RL só consegue melhorar o que o modelo já sabe fazer. Se o modelo nunca acerta uma resposta sequer, todas as notas são zero. Cada resposta equivale à média, e não há nada a aprender. Lembre-se disso, porque foi exatamente o que aconteceu comigo. Então, o que é essa notação ABC? É uma maneira de escrever música como texto simples. Aqui, X é o número da melodia, T é o título, M é a métrica, como 3 por 4, K é a tonalidade, e as notas são apenas letras. C, D, E, F, G, A, B: são sete das

05:27 12 notas. Também temos os sustenidos e os bemóis, totalizando 12 notas. Isso é ótimo para modelos de linguagem, porque eles só escrevem texto mesmo. Depois, podemos converter esse texto em um arquivo MIDI com uma ferramenta chamada ABC to MIDI e, então, em um arquivo de áudio para podermos ouvir. O avaliador da Xiaomi faz algo muito inteligente: pega o MIDI e mede 18 aspectos diferentes, agrupados em seis áreas, como ritmo, textura, acústica, tonalidade, registro e estrutura. E compara cada um deles

06:01 com música feita por pessoas de verdade. Basicamente, ele pergunta: “Isso parece ter sido escrito por uma pessoa?” A nota final fica entre zero e um. E há uma regra rígida: se o ABC tiver erros, muitos compassos quebrados ou até mesmo uma linha em branco no meio, a nota é zero. Lembre-se dessa questão da linha em branco, porque ela acaba sendo muito importante. Então, aluguei uma GPU de 80 GB no RunPod. Você pode conferir os links. Configurei tudo. Primeiro, testei os modelos-base antes de treinar qualquer coisa. E foi aí que

06:34 a coisa ficou interessante. O modelo Qwen 2.5 de 3 bilhões teve 0 de 160: 0%. E dá para entender por quê. Olhe a saída: métrica 203 por 4 e depois apenas mi bemol, mi bemol, mi bemol, mi bemol. Isso não é música. O Granite 2.5 de 7 bilhões também teve 0%. Depois, tentei o próprio modelo da Xiaomi, o MIMO distill de 9 bilhões, e foi realmente surpreendente. Ele pensa tanto que usou todo o limite de 8.000 tokens só pensando, sem sequer

07:05 começar a escrever a música. Vale lembrar que, no treinamento da própria Xiaomi, eles permitem 100.000 tokens para isso. Quando dei a ele 16.000 tokens, consegui 2,5%. O melhor foi o Qwen 3 de 8 bilhões: cerca de 6% com o thinking ativado e cerca de 1% com o thinking desativado. Então, agora temos um problema. Lembre-se do que eu disse: se tudo recebe nota zero, o RL não tem nada para aprender. Fui olhar os exemplos que falharam para entender o que estava acontecendo. E dá para ver que a música em si muitas vezes estava boa. O problema eram as linhas em branco. O modelo coloca uma linha vazia entre as seções, como uma pessoa

07:39 faria em um documento. Mas, na notação ABC, uma linha em branco significa que a música acabou. Então, o avaliador descarta tudo. Isso aconteceu em 74 das 80 peças que falharam. Quando simplesmente removi as linhas em branco, a taxa de validade passou de 1% para 16%. Então, o modelo consegue escrever música; ele só tem um mau hábito. Durante o treinamento, fiz o seguinte: se a peça falhasse apenas por causa das linhas em branco, eu a avaliava depois de removê-las. Aí, ela recebia apenas 30% do crédito. Então

08:10 O modelo recebe um sinal, mas fica claramente sabendo que receberá uma recompensa fixa, que receberá mais se corrigir isso. E precisei deixar isso bem claro aqui para o resultado final que vou mostrar. Não há nenhuma ajuda. O avaliador é rigoroso e não foi alterado, e avalia 40 prompts que o modelo nunca viu durante o treinamento. Então vamos dar uma olhada no código. Está tudo nesta pasta music demo, e vou compartilhar com vocês. Primeiro, os dados. Este é o subconjunto de música da Xiaomi no Hugging Face. São 10.000 prompts. Metade está em

08:43 inglês e metade em chinês. Então, em prep data.py, seleciono 496 em inglês e separo 40 para usar como conjunto de teste. O modelo nunca treina com esses 40, e é assim que vamos verificar se ele é honesto no final. Depois, na pasta MIMO scorer, há uma cópia exata do avaliador da Xiaomi, copiada do repo. Não alterei uma única linha. Aqui estão os seis grupos, com seus pesos. Ritmo vale 22%, textura, 20%, e assim por diante. E então temos pre-check.py.

09:14 Agora, por que precisamos disso? A própria configuração da Xiaomi traz um aviso. Se o ABC2 MIDI não estiver instalado, todas as pontuações viram zero silenciosamente, e o treinamento ainda parece estar funcionando bem. Então, antes de gastar dinheiro com GPU, esta execução passa uma valsa escrita à mão pelo avaliador. Ela recebe 619 pontos, e um texto sem sentido recebe zero. Assim, sabemos que o avaliador está ativo. Depois, temos o arquivo reward.py, que é o coração do processo.

09:45 A primeira função é um avaliador puro da Xiaomi, usado para avaliação. Depois, há uma recompensa de treinamento com o crédito pela linha em branco que acabei de explicar. E aqui embaixo podemos ver a penalidade por comprimento, que é a equação 4 da Xiaomi. Ela examina todas as respostas corretas de um grupo, calcula o comprimento típico e, se uma resposta for muito mais longa do que isso, reduz um pouco a recompensa. Depois temos o GPRO.py. Estamos usando o TRL do Hugging Face com VLM para geração rápida, e estas

10:18 são as configurações importantes. Oito respostas por prompt, oito prompts por etapa, 30 etapas, sem penalidade de KL, o que é igual à receita da Xiaomi. Estamos usando adaptação de baixa ordem, ou LoRA, com rank 64, o que significa que não treinamos os 8 bilhões de pesos completos. Treinamos um pequeno adaptador por cima. Isso é o que permite executar o treinamento em uma única GPU. Depois, temos as ferramentas de comprovação. Generate.py executa o modelo nos 40 prompts de teste antes e depois, usando a mesma seed. Render.py

10:50 converte o ABC em áudio MIDI e nessas imagens de piano roll. Charts.py cria todos os gráficos, e blindfare.py cria um teste de audição cego, que vou mostrar no final. Para executar tudo, bastam dois comandos. Setup pod.sh instala tudo e executa a verificação prévia. E run all.sh executa o teste completo: teste antes do treinamento, teste depois, áudio e gráficos. Para executar isso, usei run pod 1H 1800 com 80 GB, que custa cerca de US$ 350 por

11:22 hora. Quando o pod fica pronto, copio a pasta e executo run setup pod. Vocês podem ver que ele instala ABC to MIDI, FluidSynth, TRL e VLM, baixa os prompts da Xiaomi e, em seguida, a verificação prévia dá 619 pontos para a valsa e zero para o texto sem sentido. O avaliador está ativo, ótimo. E vou ser sincero: não funcionou de primeira. A primeira execução travou porque a configuração tinha sido renomeada na nova versão do TRL. Depois, fiquei sem memória da GPU porque oito respostas longas de uma vez eram demais. Então,

11:57 reduzi para duas respostas por passagem. Aí funcionou, mas estava lento demais: cerca de sete minutos por etapa. Reduzi o número de prompts por etapa, e então passou para cerca de três minutos e meio por etapa. Aí começou o treinamento. Vocês podem ver que, a cada etapa, ele exibe a recompensa. Na etapa um, a recompensa é 0,13, e começa a subir aos poucos. Então, 30 etapas levaram cerca de uma hora e 40 minutos, e a conta total, incluindo o pod em que tive um problema com a chave SSH, ficou em cerca de US$ 12 para a mesma ideia em que a Xiaomi gastou

12:28 milhões na escala completa. Claro, em uma escala muito, muito menor, mas o método funciona, e é assim que se faz. Então, vamos ver os resultados. Primeiro, a recompensa do treinamento. Vocês podem ver que começou em 0,13 e, no fim, fica por volta de 0,1, às vezes 0,15. Isso é cerca de oito a dez vezes mais, e dá para ver que está subindo de forma constante. O modelo está claramente aprendendo alguma coisa. Mas a recompensa do treinamento não é o teste de verdade. Então, aqui está o teste de verdade: 40 prompts que o modelo nunca viu. Quatro

13:01 respostas para cada um. O avaliador rigoroso da Xiaomi, sem nenhuma ajuda. Antes do treinamento, uma das 160 respostas era tocável: 0,6%. Depois do treinamento, 19 das 160, ou 11,9%. Isso dá cerca de 20 vezes mais músicas tocáveis. E passamos de um prompt com uma peça válida para 13 prompts entre 40. E vejam este dado: o comprimento médio das respostas caiu de cerca de 2.100 tokens para cerca de 1.250. Isso é 40% mais curto. É a penalidade por comprimento funcionando exatamente como a Xiaomi descreveu no

13:35 artigo. Agora, quero ser honesto: 12% ainda é pouco. A maioria das respostas ainda terá o hábito da linha em branco. Então, este é um ótimo começo, não um compositor pronto, mas são 30 etapas em uma GPU. Se você treinar por mais tempo ou fizer fine-tuning primeiro com bons exemplos, como a Xiaomi faz, com certeza terá resultados melhores. Mais uma coisa: o avaliador mediu se a música soava humana. Não mediu se ela era bonita. Então, também

14:08 preparei este teste cego. Cada par tem uma peça do modelo base e uma do modelo treinado, e você não sabe qual é qual. Vou deixar o link na descrição. Tente adivinhar qual foi treinada e me conte nos comentários. Agora, ao final do treinamento, temos um adaptador LoRA. Ele tem cerca de 700 MB e contém tudo o que o modelo aprendeu. Então, mesclei esse adaptador de volta com o Qwen 3 de 8 bilhões e enviei o modelo completo para o meu Hugging Face. Também o converti para o formato GGUF, para que você possa executá-lo

14:41 no seu próprio laptop também. Então, se você acessar prompt 48 no Hugging Face, verá o Gwen 3 of 8 billion MIMO music GPRO. Dá para ver todos os resultados aqui, e também o adaptador, caso queira mesclá-lo por conta própria. Para o GGUF, a versão Q4 KM tem cerca de 5 GB, então funciona em um laptop com GPU de 8 GB, como o meu. Você pode executar esta linha no Ollama. E vamos dar a ele um prompt: “Componha uma peça curta e calma para piano em dó maior. Adicione /no think think no

15:11 final, porque o treinamos com thinking.” E vocês podem ver que ele está escrevendo o ABC aqui. Depois, convertemos… [música] …e tocamos. Então, neste vídeo, vimos como podemos pegar o ambiente de RL que a Xiaomi tornou open source e treinar nossos modelos para escrever música com GPRO em uma GPU. Passamos de menos de 1% de músicas tocáveis para quase 12% em cerca de uma hora e 40 minutos, por cerca de US$ 12. E o aprendizado mais

15:43 importante aqui, que a Xiaomi também mencionou no artigo, é que o RL só pode melhorar aquilo que o modelo já consegue fazer. Por isso, encontrar o problema da linha em branco foi a verdadeira chave. Agora, se quiser levar isso mais longe, treine por mais tempo, experimente o modelo de 9 bilhões da Xiaomi com um orçamento maior de tokens ou experimente os ambientes de código e desenvolvimento web. Todos os scripts estão na descrição. O modelo está no meu Hugging Face. E, se tiver interesse, pode conferir este aqui e experimentá-lo no seu próprio sistema. Depois, me conte como

16:15 foi. Vejo vocês em outro vídeo. Confira este próximo.

Transcrição original

[00:01] All right. In this video, we will see how I trained a model to write music. And you can see that on the left, this is the base model. It cannot write even one playable song. And on the right, this is the same model after reinforcement learning RL. And you can hear that [music] it actually is playing some music. Now mind you the method the data and the grader all of it was open source by Zomi with their MIMO version 2.6 release. I took their music

[00:33] environment one rented GPU about 1 hour 40 minutes of training and about $12 and we went from less than 1% playable music to almost 12% that’s about 20 times. So in this video I will show you end to end how to get the system ready, get the data, train the model, get the adapter, merge it and use it. So let’s go ahead and get started. So this is the news. Zomi is just open sourced around 7,000

[01:04] RL environments, reinforcement learning environments that they use to train Mimo across code, cyber security, general knowledge work, web design, and music. And people are calling this one of the biggest things that happen in open-source RL environment data. And I do really agree with that. Now, MIMO version 2.6 come in two sizes. The pro is a 1 trillion parameter mixture of experts model with 42 billion active parameters and the flash one is 310

[01:37] billion 15 billion active. But more than the models, the really interesting thing here is what else they released. So if you go to hugging face, you can see this data set. Memo version 2.6 RLS. It has five subsets here. So code, cyber, general, webdev, and music. And these are not just prompts. These are full environments with verifiers, which means for every task there is a way to automatically check whether the model did it right. And then we have the

[02:08] training code as well. So they forked ver which is a bite dense RL training library and they added their recipes on top of it. The way um I like to think of this is bite built the school building and Xiaomi wrote the syllabus the exams the examiners and the anti-cheing rules and then they gave all it away. They also released a small 9 billion model uh Mimo version 2.6 six distill 9 billion as a starting point for your own reinforcement learning and the tech

[02:41] report uh they even tell you the bill they spend about $2.6 $6 million on RL for the pro model and about $900,000 for the flash model. And the main idea of this whole paper is really simple. If you keep scaling reinforcement learning, more compute, more environments, and better graders, the model keeps getting better. You can see all the benchmark lines go up as the training steps go up. So, I wanted to test this idea myself on a small budget and I picked the music

[03:13] environment and let me tell you why. music is single turn. There is there are no Docker sandboxes, no AI judge and the grader is pure Python and it’s the easiest one to run on one GPU and also you can actually hear the results which is a lot more fun than looking at code test results. So before you go into the code, let me quickly explain how this training actually works because it’s really simple once you see it. We give the model one prompt. For example, composed a calm shallow piece in E minor. Now instead of one answer, the

[03:45] model writes eight different answers for the same prompt. You can see these eight attempts here. Then the grader scores every one of them. Some got zero, some get a good score. And now here is the key thing. We don’t compare the answers with some perfect answer. We compare each answer with the average of its own group. So if an answer is better than its siblings, we push the model to do more of that. And if it’s worse, we push it away from that. And that’s it. That’s GPRO or group policy or group relative policy optimization. Repeat this for

[04:19] many prompts and many steps and the model slowly learns what the grader likes. Now Zomi added a few tricks on top of this and one of them I have used here as well which is the length penalty. So if two answers are both correct and one way is and one is way longer than the other in its group the one that one gets a small penalty. So the model learns to be correct and short. It’s equation four in the paper and it’s about 10 lines of code which I will show you. And one important thing that the paper says which we will see in

[04:53] action in just a moment. RL can only improve what the model can already do sometimes. If the model never gets a single answer right, every score is zero. Every answer is equal to the average and there is nothing to learn from. Keep this in mind because this is exactly what happened to me. So what is this ABC notation? It’s a way to write music as plain text. So you can see here X is the tune number, T is the title, M is the meter like 3x4, K is the key, and then the notes are just letters. So C, D, E, F, G, A, B, that’s seven notes of

[05:27] the 12 notes. And then we have the sharps and the flat notes as well. So total of 12 notes. And this is really good for language models because they only write text anyway. Then we can convert this text into a MIDI file and uh uh with a tool called ABC to MIDI and then into audio file so that we can listen. Now Zami’s grader there does something really smart here. It takes the MIDI and it measures 18 different things group into six areas like rhythm, texture, acoustics, tonal, register and structure. And it compares each of them

[06:01] against real human music. So basically it’s asking does this sound like a human wrote it? And the final score is between one and zero. And one strict rule, if ABC has errors or too many broken bars or even a blank line in the middle, the score is straight zero. Remember this a blank line thing because it actually becomes really important. So what I did is I rented uh an 880GB GPU on RunPod. You can go ahead and check the links. Set everything up. And first I tested the base models before training anything. And this is where it

[06:34] got interesting. the Quen 2.53 billion model 0 out of 160 0% and you can see why look at the output meter 203x4 and then just E flat E flat E flat E flat that’s not music grand 2.57 billion again 0%. Then I tried Xomi’s own model, the Mimo distill 9 billion and that was really surprising. It thinks so much that it used the ent 8,000 token budget yet just thinking and it never even

[07:05] started writing the music. Mind you, the Xiaomi’s own training they allow 100,000 tokens for this. When I gave it 16,000 tokens, I got 2 and a half%. And the best one was quen 38 billion was around 6% with thinking on and around 1% with thinking off. So now we have a problem. Remember what I said. If everything scores zero, RL has nothing to learn from. So I went inside the failures to see what’s going on. And you can see the music itself was often fine. The problem was this blank lines. The model puts an empty line between sections like a human

[07:39] would do in a document. But in ABC notation, a blank line means the song has ended. So the greater throws the whole thing out. 74 out of 80 failed pieces had this. And when I just remove the blank lines, the valid rate went from 1% to 16%. So the model can write music, it just has a bad habit. So what I did during training only, if the piece fails only because of blank lines, I grade it with the blank line removed. then it gets only 30% of the credit. So

[08:10] the model gets a signal but it clearly told but it’s clearly told that you would get fixed that you would get more uh if you fix this. And I really had to be clear here for the final result that I will show you. There is no help at all. It’s strict grider unchanged on 40 prompts that the model never saw during the training. So let’s go ahead and look at the code. Everything in in is in this music demo folder and I will share this with you. First the data. This is Xiaomi’s music subset on hugging face. 10,000 prompts. Half of them are in

[08:43] English, half are Chinese. So in prep data.py I take 496 English ones and I keep 40 aside as a test set. The model never trains on these 40 and that’s how we’ll check its honesty at the end. Then this MIMO scorer folder there’s a Xiaomi’s grader copied exactly from the repo. I haven’t changed a single line. You can see the six groups here with their weights. Rhythm is 22% texture 20 and so on. And then we have pre-check.py. Uh

[09:14] now why do we need this? Xiaomi’s own config has a warning. If ABC2 MIDI is not installed, every score silently becomes zero and the training still looks healthy. So before spending any money on GPU this run uh this runs one handwritten walls through the grader it scores 619 and plain text scores zero. So we know the grader is live. Then this reward.py file which is the heart of it.

[09:45] The first function is a pure Xiaomi grader which is used for evaluation. And then there is one training reward with the blank line credit that I just explained. And then down here we can see the length penalty which is Xiaomi’s equation 4. It looks at all the correct answers in a group takes the typical length and if an answer is way longer than it is then that it cuts a little bit of the reward. Then we have the GPRO.py. Uh we are using TRL from hugging phase with VLM for fast generation and these

[10:18] are important settings. Eight answers per prompt, eight prompts per step, 30 steps, no KL penalty, which is the same as Xiaomi’s recipe. We’re using low rank adaptation or Laura, which ranks 64 with rank 64, which means we don’t train the full 8 billion weights. Uh we train a small adapter on top. This is what this fits on one GPU only. And then we have the proofs tool. Generate.py Pi runs the model on the 40 test prompts before and after with the same seat. Render.py

[10:50] turns the ABC into MIDI audio and these piano roll pictures. Charts.py makes all the charts and uh blindfare.py creates a blind listening test which I will show you at the end. And to run everything, you just need two commands. Setup pod.sh installs everything and runs the pre-check. And run all.sh SH does the full test before test uh training after test audio and charts. Now for running this I use run pod uh 1H 1800 with 80GB which is about $350 an

[11:22] hour. So once a pod is ready, I copy the folder uh run setup pod and you can see that it installs ABC to MIDI fluid sync TRL and VLM u download ZOMI’s prompts and then pre-check wall scores 619 garbage text score zero scorer is live really good and I’ll be honest it didn’t work for the first time the first run crashed because the setting was renamed in the new TRL version then it run out of ran out of GPU memory because eight long answers at once was too much. So I

[11:57] reduced it to two answers per pass then it was working but it was too slow about [snorts] 7 minutes per step. I reduced the prompts per step and then it got about 3 and 1/2 minutes per step and now it’s training. You can see every step it prints the reward. Step one the reward is 013 and it slowly starts going up. So 30 steps took about 1 hour 40 minutes and the total bill including the pod where I had SSH key issue was about $12 for the same idea that Xiaomi spent

[12:28] millions on his full scale. Of course at a much much smaller scale but the method works and this is how it’s done. So let’s see the results. First the training reward. You can see it started at point at 013 and by the end it’s around.1 sometimes.15. So that’s about 8 to 10 times higher and you can see it’s going up steadily. The model is clearly learning something. But the training reward is not the real test. So here is the real test. 40 prompts the model never saw. Four

[13:01] answers each. Zami strict greater no help. Before training, 1 out of 160 was playable. 0.6%. After training, 19 out of 160, 11.9%. That’s about 20 times more playable music. And it went from one prompt of the valid piece to 13 prompts out of 40. And uh look at this one. The average answer length went from about 2,100 tokens to about 1,250. That’s 40% shorter. That’s the length penalty working just like Xiaomi described in

[13:35] the paper. Now I want to be honest here 12% is still low. Most answer will uh still have the blank line habit. So this is a really good start not a finished composer but this is 30 step on one GPU. If you train it longer or first fine-tune it on good examples uh like Zami does you will definitely get better results. Now one more thing the grader measured it uh if humanlike. The grader measured if it sound humanlike not if it sounds beautiful. So I always uh also

[14:08] made this blind test. So every pair has one piece from the base model and one from the train model and you don’t know which is which. I’ll put this in the description. Try to guess which one is trained and let me know in the comments. Now we get at the end of the training uh is a Laura adapter. It’s about 700 MB and it contains everything the model learned. So what I did is I merged this adapter back with quen 38 8 billion and I’ve uploaded the full model on my hugging face uh and I also converted it into GGUF format so that you can run it

[14:41] on your own laptop as well. So if you go to prompt 48 on hugging face you can see Gwen 3 of 8 billion MIMO music GPRO. You can see all the results here and the adapter as well if you want to merge it yourself. And for the GGUF, the Q4 KM version is about 5GB, which will work on an 8GB GPU laptop just like mine. So you can go ahead and run this one line in Olama. And let’s give it a prompt. Compose a short calm piano base in C major. Add slash no think think at the

[15:11] end because we train it with thinking of. And you can see it’s writing the ABC here. And then we convert it >> [music] >> and play it. So in this video we have seen how we can take the RL environment that Zami opens sourced and train our models to write music with GPRO on one GPU. We went from less than 1% playable music to almost 12% in about 1 hour 40 minutes for about $12. And the most

[15:43] important learning here which Zomi also said in their paper, RL can only improve what the model can already do sometimes. That’s why finding the blank line problem was the real key. Now if you want to push this further uh train on it longer, try Zomi’s 9 billion with a bigger token budget or try the code and webde them webdev environments. All the scripts are in the description. The model is on my hugging face. And if you’re interested, you can go ahead and check this one out and try this out on your own system and let me know how it

[16:15] goes. I will see you in another one. Check out this next