Aberto por design: Together AI x MiniMax — palestras-relâmpago

Ver no idioma original →

Autoria: Together AI · 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: Open by design: Together AI x MiniMax — Lightning talks · Canal: Together AI · 42:11 · Assistir no YouTube

Tópicos: Infraestrutura e hardware de IA, Modelos de IA, Modelos locais e open source, Modelos multimodais

Resumo

Representantes da Together AI e da MiniMax discutem como levar modelos open weight à produção, destacando custos, desempenho, controle e os componentes necessários para servi-los. A MiniMax apresenta seus modelos multimodais e explica como escolhas de infraestrutura, como precisão, cache, concorrência e otimizações de inference, afetam custo e desempenho. Em seguida, Max, da Together AI, apresenta score centering, uma técnica proposta para estabilizar o reinforcement learning ao lidar com diferenças entre os modelos usados para gerar amostras e para treinar. A palestra também aborda experimentos que indicam que a técnica pode complementar métodos existentes e melhorar a estabilidade do treinamento.

Pontos-chave

• Modelos open weight oferecem controle, desempenho e oportunidades de reduzir custos, especialmente quando são adaptados a casos de uso específicos.
• A pilha para operar modelos abertos inclui o modelo, a camada de inference, gateways, a camada de aplicação e ferramentas.
• A Together AI oferece infraestrutura de inference e otimizações para servir modelos, além de suporte a deployments em várias regiões.
• A MiniMax destaca a multimodalidade e a abertura como princípios de seus modelos, com exceção mencionada para o modelo de fala.
• O MiniMax M3 usa sparse attention para reduzir o custo de processamento de contextos longos.
• Precisão, caching, prefill, decode e concorrência são fatores que podem ser ajustados para equilibrar custo, velocidade e qualidade.
• O post-training e o reinforcement learning são apresentados como formas de adaptar modelos a tarefas e setores específicos.
• Score centering busca estabilizar o reinforcement learning ao corrigir o descompasso entre os scores do sampler e do trainer.
• Segundo os experimentos apresentados, score centering pode ser combinado com importance sampling e melhorar a convergência em certos cenários.

Capítulos

Início	Capítulo	Resumo
00:01	A ascensão dos modelos open weight	A abertura do evento apresenta a crescente adoção de modelos open weight e seus atrativos de custo, desempenho e controle.
03:08	A pilha para servir modelos abertos	A palestra descreve as camadas de modelos, inference, gateways, aplicações e ferramentas necessárias para operar modelos abertos.
05:50	Casos de uso e infraestrutura da Together AI	São citados agentes de programação, automação financeira e geração de conteúdo, além dos serviços de infraestrutura e inference da Together AI.
11:16	A visão e os modelos da MiniMax	Rio apresenta a MiniMax, seus princípios de multimodalidade e abertura e os modelos de vídeo e texto da empresa.
17:18	Ajustes para reduzir custos em produção	A palestra explica como precisão, memória, caching, prefill, decode e concorrência afetam os custos e o desempenho.
22:20	Otimizações de inference e adaptação por setor	São detalhadas otimizações da Together AI e o uso de post-training para adaptar modelos a tarefas e domínios específicos.
27:52	Introdução ao reinforcement learning	Max apresenta os desafios de treinar agentes com reinforcement learning e explica por que os custos crescem com a escala.
31:14	Instabilidade e descompasso entre treino e amostragem	A palestra mostra como diferenças entre trainer e sampler podem desestabilizar o reinforcement learning e desperdiçar compute.
35:36	A proposta de score centering	Max apresenta a técnica, que estima o descompasso entre distribuições e o considera ao calcular as atualizações.
39:27	Resultados experimentais e conclusão	Os experimentos apresentados sugerem que score centering pode complementar importance sampling e ajudar na convergência.

Citações

Os principais motivos que vemos para a adoção de modelos open source são custo, desempenho e controle. — 02:07

A pergunta deixa de ser qual modelo é o melhor e passa a ser quais tarefas devo enviar ao melhor modelo. — 17:18

Você precisa equilibrar as considerações de custo e qualidade do modelo com o custo de executá-lo na GPU. — 19:00

A ideia que propusemos se chama score centering. — 36:43

Conceitos e entidades

• Together AI (empresa): Empresa que fornece infraestrutura e serviços de inference para modelos open weight.
• MiniMax (empresa): Laboratório de modelos de IA que apresenta modelos multimodais e de texto com pesos abertos.
• MiniMax M3 (modelo): Modelo de texto da MiniMax descrito como capaz de processar até um milhão de unidades de contexto e usar sparse attention.
• H3 (modelo): Modelo de geração de vídeo descrito na palestra como capaz de processar e gerar texto, vídeo e áudio.
• Together Link (ferramenta): Produto da Together AI mencionado como meio de usar modelos como o MiniMax M3 em interfaces como Claude Code.
• score centering (conceito): Técnica proposta para estabilizar o reinforcement learning ajustando os scores da policy em relação ao sampler.
• reinforcement learning (conceito): Método de treinamento abordado como forma de adaptar modelos e agentes, embora possa ser instável e custoso em grande escala.
• importance sampling (conceito): Técnica citada para lidar com diferenças entre distribuições de treinamento e geração de amostras.
• DeepSeek R1 (modelo): Modelo citado como exemplo de resultados aprimorados por reinforcement learning em tarefas que permitem verificação.
• Qwen 3 0.6B (modelo): Modelo pequeno usado em experimentos com ruído artificial para comparar técnicas de estabilização.

Tradução completa (pt-BR)

00:01 Boas-vindas a todos. Muito, muito obrigado por estarem aqui. É um verdadeiro prazer dar início a este evento hoje. Acho que este é o quinto evento desse tipo que realizamos. Demos a esta sessão o título “Aberto por design”. Nos últimos 3 a 6 meses, temos visto uma demanda incrível, especificamente na Europa, para entrar no mundo dos pesos abertos. Então, a pergunta já não é “queremos ou não usar pesos abertos?”, mas sim “como fazemos isso, de fato?”. Na sessão de hoje, vocês terão vários palestrantes da Together, dos nossos parceiros da MiniMax e, claro, de um dos nossos clientes, [trecho inaudível].

00:32 Vou apresentar nosso primeiro palestrante: In Sung, vice-presidente de sucesso do cliente da Together. Sou Sar Tropathy. Lidero a experiência do cliente na Together. Isso significa, basicamente, todas as pessoas que trabalham diretamente com nossos clientes para garantir que eles tenham bons resultados comerciais e técnicos: arquitetura de soluções, suporte de engenharia de implantação e tudo o que for necessário para garantir o sucesso dos nossos clientes. Sim. Então, eu só queria meio que…

01:03 …começar discutindo por que estamos aqui hoje. Como James mencionou, tem havido bastante repercussão positiva em torno dos modelos abertos nos últimos meses. No fim de semana, eu estava lendo este relatório da Mozilla, o “State of Open Source”, que abrange todas as tecnologias de código aberto. O fascinante é que sete dos dez principais modelos em volume de tokens neste momento são modelos de pesos abertos, o que é muito, muito empolgante e bem diferente…

01:34 …do que se via há um ano, ou mesmo há nove meses. O código aberto está realmente ganhando espaço. O que é muito empolgante é que nossos parceiros da MiniMax estão bem no centro dessa onda de pesos abertos, com seus modelos de ponta, que resolvem todos os tipos de casos de uso incríveis sobre os quais vocês vão ouvir hoje. E, aqui na Together, operamos a camada de inference que leva esses modelos de pesos abertos para produção. Por que as pessoas escolhem modelos de código aberto? Só para ter uma ideia rápida: quantos de vocês já interagiram com um modelo de código aberto ou fizeram o deploy de um…

02:07 …por conta própria? Certo, legal. Então, felizmente, não preciso explicar muito. Os principais motivos que vemos para as pessoas migrarem para modelos de código aberto são custo, desempenho e controle. Quanto ao custo, um exemplo: recentemente, aqui na Europa, um cliente empresarial economizou 98% usando um modelo de código aberto, em comparação com um modelo feito o deploy na OpenAI. Quanto ao desempenho, vemos ganhos de 3 a 5 vezes com modelos de código aberto em relação aos modelos fechados…

02:37 …especialmente quando se faz fine-tuning deles para casos de uso específicos. E, falando em fine-tuning, o controle é um aspecto importantíssimo, especialmente aqui na Europa. É algo que nossos clientes e a comunidade vêm pedindo em relação aos modelos, e isso os está levando a adotar modelos de pesos abertos. Como é a stack de modelos de pesos abertos? Pensamos bastante nisso e, com quase um milhão de desenvolvedores que usam a Together AI todos os anos e as centenas de clientes com quem…

03:08 …trabalhamos, elaboramos uma estrutura mental para a stack que compõe o serviço de modelos abertos de código aberto. Ela é formada por todas as coisas que muitos de vocês que levantaram a mão provavelmente usam e veem no dia a dia. A primeira é o próprio modelo: os pesos do modelo que fazem com que as respostas sejam ótimas. Uma camada fundamental aqui é a própria camada de inference. É claro que é aí que a Together entra, ao disponibilizar esses modelos de código…

03:40 …aberto. Vou comentar, só como exemplo, que, há dois anos, antes de trabalhar na Together AI, eu não entendia nem de longe o quão complexo era disponibilizar modelos de código aberto — ou servir modelos para inference, em geral. Há uma questão de desempenho, uma de confiabilidade e outra de estabilidade. É uma camada muito, muito complexa, e por isso empresas como a Together surgiram no mercado para tirar esse peso de vocês, usuários, de fato hospedar os modelos. A próxima camada são os gateways. Essa é a…

04:13 …camada que realmente decide qual provedor ou qual modelo vai atender à solicitação do usuário final. Essa área ganhou muita força no último ano, mais ou menos. Vocês viram a OpenRouter ser adquirida pela Stripe por causa dessa tecnologia incrível que criou. E vemos cada vez mais roteadores e gateways surgindo no setor, de excelentes colaboradores da comunidade de código aberto, para facilitar o uso dos modelos que vocês quiserem, sem que precisem se preocupar com a seleção desses modelos. A camada do harness. Essa é a camada de aplicação. Muitos de vocês provavelmente já usaram coisas como OpenCode, Cursor e Claude Code. É muito empolgante compartilhar também que muitas dessas variantes de aplicações frontend de código fechado agora conseguem interagir com modelos de código aberto. Uma coisa que criamos aqui na Together se chama Together Link, que permite…

04:44 …aos desenvolvedores usar modelos como o MiniMax M3 dentro do Claude Code. Se vocês tiverem interesse em usar modelos de código aberto em uma interface de código fechado, podemos conversar sobre isso. Acho que é algo que muita gente da comunidade ainda não conhece muito bem. E, claro, há a camada de ferramentas, a camada final da stack: seus MCPs, suas skills e as coisas que sabem exatamente como realizar tarefas específicas dentro da sua stack de código aberto. Essa é a stack. Fico feliz em conversar mais…

05:17 …sobre isso, mas essa é, de certa forma, a nossa visão de tudo o que vocês precisam para executar modelos abertos. Felizmente, os senhores supremos da IA já ficaram bons o bastante para fazer tudo isso por vocês, se realmente não quiserem pensar no assunto. Que casos de uso estamos vendo para modelos de código aberto? Sem surpresa, o maior deles são os agentes de programação. Acho que a maioria das empresas de desenvolvimento de software, até mesmo as semianvancadas, hoje em dia está…

05:50 …escrevendo mais código com agentes do que com pessoas, o que provavelmente é a maneira certa de fazer as coisas. Quantos de vocês já usaram agentes de coworking? Só por curiosidade. Esse é outro caso de uso que estamos vendo bastante. E, como hoje estamos em um dos maiores centros financeiros do mundo — moro em San Francisco, aliás, então é bom estar em Londres —, é um caso de uso que estamos vendo bastante nos serviços financeiros. Há muito trabalho com planilhas e com diferentes aplicações nos sistemas financeiros, então…

06:20 …treinar agentes de coworking para fazer esse trabalho com modelos de código aberto realmente inteligentes é algo que estamos vendo bastante. E, claro, há a geração de conteúdo de voz. Empresas como a Higgsfield estão criando produções cinematográficas incríveis — não apenas vídeos de gatos fingindo ser Donald Trump, mas vídeos e filmes de verdade — para publicar por aí, usando modelos de código aberto incríveis. Legal. Certo. Então, outro ponto…

06:53 Treinar agentes de colaboração para fazer isso com modelos open source realmente muito inteligentes é algo que estamos vendo bastante. E, claro, geração de conteúdo por voz. Empresas como a Higsfield estão produzindo filmes incríveis, não apenas vídeos de gatos fingindo ser Donald Trump, mas vídeos de verdade e filmes de verdade para publicar por aí usando modelos open source incríveis. Legal. Certo. Então, outro ponto que acho…

07:28 Isso seria interessante para vocês saberem e, de certa forma, conversarem a respeito: pós-treinamento em aprendizado por reforço. E vocês vão ouvir outra palestra sobre isso esta noite, do meu colega Max. Mas o pós-treinamento em aprendizado por reforço é, eu acho, assim como 2026 foi — ou está surgindo como — o ano dos modelos open source, vemos o fim de 2026 e o início de 2027 como o período em que haverá uma proliferação do pós-treinamento e do aprendizado por reforço. Essa é realmente a base sobre a qual nós

08:04 acreditamos que as empresas vão se diferenciar no longo prazo. Então, em um mundo em que surge todo dia um novo modelo open source incrível, como você, como empresa e como equipe de desenvolvimento, se mantém diferenciado? Isso é algo sobre o qual estamos conversando bastante com nossos amigos da MiniMax, além de realmente ajudar nossos clientes a fazer aprendizado por reforço para controlar a qualidade, a velocidade e o controle, e se manterem diferenciados com suas ofertas. E essa é mais uma área

08:36 em que adoramos retribuir aos usuários e ajudá-los a se manter na vanguarda de seus domínios, seja em serviços financeiros, saúde ou qualquer outra área. Então, não vou compartilhar muita coisa aqui, porque vocês vão ouvir muito mais sobre isso dos especialistas, mas esse é outro espaço muito interessante para acompanhar. Como talvez vocês saibam, a Together hospeda muitos modelos open source, de vários parceiros e em diferentes áreas, como modelos de linguagem e modelos de voz. Temos muitos parceiros no espaço open source

09:09 e vocês também vão ouvir diretamente nossos amigos da MiniMax falarem sobre eles hoje. Então, vou fazer uma introdução rápida à plataforma da Together. Não vou demorar muito; deixo para vocês fazerem perguntas depois. Mas, como vocês ouviram, fornecemos nossa infraestrutura de IA como serviço. Temos computação implantada globalmente e disponibilizamos mais de 200 modelos open source nesta plataforma, permitindo que vocês façam aprendizado por reforço, sirvam esses modelos e os adaptem,

09:40 oferecendo uma experiência rica para desenvolvedores gerenciarem tudo isso. Acho que um dos principais diferenciais da Together Compute é que a computação é nossa e operada por nós, globalmente. Assim, por meio da propriedade direta da computação, de joint ventures com pessoas no mundo todo e do aluguel de parte da capacidade computacional, conseguimos manter uma vantagem considerável para oferecer a vocês a computação de que precisam, quando precisam. O último ponto que vou mencionar, talvez o mais interessante, é o que nós

10:11 mais fazemos com os clientes: tornar a inference econômica para a comunidade. E, se vocês pensarem no que isso exige, são basicamente duas frentes. A primeira é otimizar o próprio mecanismo de inference. São coisas que vocês não vão querer fazer por conta própria quando se trata de inference: treinar modelos de decodificação especulativa, fazer cache de prefixo, separar o serving entre prefill e decode, gerar saídas estruturadas, fazer chamadas de função. Todos esses diferentes aspectos da pilha de inference são bastante complicados de executar

10:43 por conta própria. Nós fazemos isso para nossos usuários e trabalhamos com nossos desenvolvedores, parceiros e clientes para fazer isso por vocês. E, claro, há também os outros aspectos de simplesmente implantar um sistema distribuído, algo que nunca foi fácil e continua sendo um problema difícil de resolver: fazer escalabilidade automática, enfileiramento, alta disponibilidade, implantações em várias regiões, implantar pools de contextos e coisas assim. São coisas com as quais, por meio do nosso software, da nossa infraestrutura e das nossas

11:16 equipes de implantação, ficamos felizes em ajudar nossos clientes. Então, com isso, vou passar a palavra aos nossos amigos da MiniMax. Rio. >> Meu nome é Rio. Estou à frente dos desenvolvimentos da MiniMax, claro, Emia. Temos uma equipe aqui. Alguns dos integrantes, como Andrean, Jazz e Elliot; fiquem à vontade para procurá-los. E, se quiserem saber qualquer coisa sobre nós, podem perguntar. Acho que o tema de hoje é como executar modelos

11:51 em produção. Quando pensamos em produção, precisamos considerar todos os aspectos com os quais não precisaríamos nos preocupar se estivéssemos apenas chamando uma API. São todas as coisas que um modelo aberto permite fazer e ajustar com fine-tuning às qualidades que vocês desejam. E acho que, no fim das contas, o objetivo é alcançar um equilíbrio entre qualidade e preço, sendo econômicos. Vocês já ouviram falar bastante da MiniMax e dos casos de clientes apresentados pelo Sang. Então, só para resumir, nós

12:29 somos um laboratório de modelos de fronteira, estabelecido há quatro anos e meio. Somos o primeiro laboratório da Ásia a trabalhar em modelos de fundação, antes do lançamento do ChatGPT. Ao longo dos anos, ampliamos nossa presença pelo mundo e, na verdade, já estamos listados na bolsa de valores de Hong Kong. A maior parte da nossa receita vem de fora da China, e estamos migrando de serviços para consumidores para serviços empresariais. O relatório do último trimestre

12:59 divulgou este número: mais de 60%, ou seja, a maior parte da nossa receita agora vem de clientes empresariais. Acho que duas palavras-chave sobre a MiniMax são, primeiro, multimodalidade — isso está no nosso projeto desde o início. Desde o começo, nossa interpretação de alcançar AGI é, na verdade, simular o mundo real. Não é possível fazer isso sem ser realmente bom não apenas com modelos de texto, mas também com vídeo, áudio e tudo o que

13:35 abrange a forma como recebemos e percebemos informações no mundo real. A segunda palavra é abertura. A maioria dos nossos modelos — com a ressalva de que, no momento, o modelo de fala permite implantação privada —, de modelos de texto a modelos de vídeo e de música, tem pesos abertos, para que as pessoas possam baixá-los e executá-los. Fazemos isso porque está alinhado à missão da empresa: tornar a inteligência

14:09 acessível a todos. E é por isso que fazemos isso. Quero usar este caso para mostrar que não é preciso escolher entre geração de vídeo de ponta e modelos com pesos abertos, como se fossem opções incompatíveis. Esta é a primeira vez que o mercado tem um modelo de geração de vídeo que também tem pesos abertos. Ele alcançou a primeira posição no ranking, mas o ranking é algo que a comunidade trabalha continuamente para

14:39 aprimorar com o pós-treinamento e assim por diante. Por exemplo, um dos nossos outros parceiros, a FA, desenvolveu um modelo fantástico de transmissão ao vivo com base nos pesos que lançamos. Mas o H3 é um modelo que consegue gerar e compreender texto, vídeo e áudio em uma única passagem. Então, deixa eu mostrar a qualidade disso escolhendo um pato de Pequim. Algum de vocês já experimentou pato de Pequim?

15:10 Ótimo, então… Espero que este vídeo funcione, ou não? Deveria estar passando. Infelizmente, vamos ter que pular; hoje não vai ter pato de Pequim. Temos muitos exemplos que vocês podem pesquisar no YouTube. Esse foi o modelo de vídeo S3, mas acho que a joia da coroa é o nosso modelo principal, o M3. É um modelo baseado em texto. Ele pode receber até 1 milhão de unidades de informação contextual.

15:43 Ele consegue gerar código e assim por diante. Mas acho que o ponto sobre o custo-benefício da execução desse modelo tem a ver com a forma como ele presta atenção. Quando um modelo é executado, essas informações contextuais são o que mais custa, e desenvolvemos o sistema de modo que ele faça uma pontuação barata em todos os blocos de contexto e use apenas

16:13 prestando atenção àqueles seletivos. Certo? Então, chamamos isso de esquema de atenção esparsa e, com essa seletividade, é possível reduzir efetivamente sua execução a 5%. Isso, em comparação com a geração anterior, é a base de todos os benefícios de custo nos quais este modelo se apoia. Então, por que o preço importa? Atualmente, o MiniMax M3 funciona…

16:44 normalmente a US$ 0,3, algo como 5% a 20% do preço de todos os principais modelos fechados. E não são palavras nossas: Gilmo, que desenvolve o Verso, disse, quando nosso modelo foi lançado e ele o testou em comparação com os próprios benchmarks, que ele tem qualidade de desempenho de ponta, no mesmo nível de alguns dos melhores modelos, logo atrás dos principais modelos de fronteira fechados, mas é 10 vezes mais barato. Então…

17:18 a pergunta deixa de ser, quando você está executando em produção, “qual é o melhor modelo?” e passa a ser “quais tarefas devo enviar para o melhor modelo?”. No fim das contas, um sistema de produto pode perceber que isso se aplica a uma minoria das tarefas, e é por isso que a escalabilidade será alcançada usando modelos abertos. E acho que dizer que modelos abertos são mais baratos seria a mensagem errada e a lição errada a tirar. Na verdade, trata-se dos controladores, certo? Um modelo fechado oferece uma API, com um preço simples pelo consumo, mas tudo o que acontece dentro dele — como o modelo consome as memórias, como enfileira suas solicitações — é fechado, e essas decisões já foram tomadas por você. Mas um modelo aberto abre essas camadas, esses controles, que permitem fazer fine-tuning e trabalhar com parceiros como a Together AI…

17:53 para, junto com a Together, alcançar o ponto ideal na curva de custo-benefício para seus casos de uso específicos. Vou passar rapidamente por alguns desses controles para mostrar como é possível obter economias reais. O primeiro controle é a memória. A memória é o mais importante porque você provavelmente vai possuir ou alugar placas gráficas, e elas estarão entre as coisas mais caras que você já possuiu. [risos] Portanto, decidir…

18:27 qual nível de precisão dos modelos você executa é fundamental. Se você o reduzir, será necessária menos memória. Por exemplo, se você reduzir o nível de precisão pela metade, o modelo usará cerca de 50% menos memória. Mas é preciso ter em mente que uma precisão menor significa uma redução na qualidade das saídas do modelo. Portanto, é necessário equilibrar as considerações de custo da qualidade do modelo com o custo de executá-lo na sua placa gráfica. Certo?

19:00 Então, há um ponto da curva que você precisa considerar, mas essa decisão cabe a você. Os controles número dois e três são, acho, dois lados da mesma moeda. Temos prefill e decode. Basicamente, é como o modelo lê e escreve, certo? Então, você tem controles para fazer fine-tuning e, com a atenção esparsa do MiniMax, como mencionei, pode realmente acelerar a leitura do contexto…

19:36 e, assim, reduzir o tempo até o primeiro token. Você também pode fazer coisas como caching, certo? Assim, as informações são armazenadas apenas temporariamente. Em vez de ler todo o contexto novamente — e, em muitos casos, essa leitura do contexto é muito cara —, quando o modelo recebe sua entrada, ele percorre todo o histórico anterior e…

20:13 os documentos e conteúdos que você discutiu. Se você fizer caching corretamente, esse custo pode ser reduzido significativamente. Por isso, uma das métricas mais importantes em inference é a taxa de acerto do cache. A forma como você mede a qualidade do caching de uma plataforma determina, de fato, como você obtém economia de custos no seu sistema de produção. E coisas como decode, ou seja, a velocidade de escrita ou de saída, também…

20:46 importam. Você pode fazer otimizações de código de baixo nível, no nível do kernel, para melhorar essa velocidade também. O quarto controle às vezes passa despercebido porque é uma decisão de produto disfarçada de camada de infraestrutura. Há alguns números de benchmark, por exemplo: quando você executa o MiniMax M3 com apenas quatro placas e, dependendo de quantos usuários concorrentes você envia, se enviar apenas quatro usuários concorrentes para essas quatro placas, terá uma velocidade muito alta, de 200 tokens por segundo por usuário. Mas, se decidir enviar mais usuários concorrentes, cada usuário terá uma velocidade menor, mas a saída total dessas gerações será maior. Portanto, o custo por token da execução é menor. Certo? Então, você precisa pensar no tipo de caso de uso e nas aplicações que executa. Para um agent assistente de programação…

21:18 talvez você decida que a velocidade é mais importante. Portanto, precisa enviar menos usuários por placa GPU. Já para alguns processos do tipo operações em lote, o throughput total, a saída total, é importante. Então, a concorrência às vezes também passa despercebida. A Together é, de fato, nossa parceira de nuvem preferida para o M3. Quando o M3 foi lançado, os engenheiros deles não apenas fizeram o download e o disponibilizaram para vocês, mas também realizaram otimizações muito sérias. É por isso que, como Saron estava dizendo, inference é algo incrivelmente difícil de fazer. Há muitas camadas diferentes nas quais você pode fazer fine-tuning para alcançar um throughput melhor ou melhorar a qualidade da disponibilização. Aqui estão quatro coisas que eles fizeram: mudaram o esquema de atenção, ou seja, a forma como o modelo lê…

21:48 e como as informações são transferidas entre a placa principal e as memórias temporárias. Em vez de transferi-las por multiplicação, eles reformularam a atenção de blocos KV para que os dados sejam lidos apenas uma vez. Também fizeram otimizações de código de baixo nível, no nível do kernel, e coisas como descarregar tarefas não críticas de pré-processamento de imagem e vídeo, em vez de deixá-las ocupar a GPU, usando chipsets comuns. Tudo isso se soma a resultados que vocês podem ver. É fácil mostrar os números, mas houve um trabalho incrivelmente difícil por trás deles. Eles conseguiram fazer tudo isso para vocês e oferecer o dobro do throughput que até nós conseguimos ao executar na nossa própria plataforma de inference. Outro estudo de caso: como mencionei brevemente, os casos de uso do Jensen Park…

22:20 Mas quero abordar isso por outro ângulo. Acho que a Together fez muitas otimizações do lado da inference, mas, nos casos de uso do GenP Park, há outro aspecto que está se tornando muito popular e importante neste ano: o caso de uso de aprendizado por reforço. Com conhecimento e dados específicos do setor, além de um bom modelo base, ao fazer fine-tuning e pós-treinamento, é possível alcançar não apenas eficiência de custo…

22:53 mas também resultados de ponta específicos para o setor e a tarefa que você está executando, certo? E, nos casos da Gen Chance Transpar, eles tinham apenas 2.000 apresentações de slides e fizeram o pós-treinamento do M3 com essas 2.000 tarefas de slides. Aqui, a tarefa completa é executada. Assim, agora a equação — o parâmetro de recompensa nessa equação que está sendo otimizado — é a apresentação inteira…

23:23 que é gerada. Portanto, todo o tipo de fidelidade do texto e a aparência da geração passam pelo treinamento, resultando em uma avaliação média dos usuários de 4,25 para a geração de slides do M3. O Opus 5, que alguns de vocês talvez usem diariamente para gerar slides, tem um nível semelhante, de 4,23. Então, quando vocês têm um desempenho equivalente e a 10% do custo…

23:54 mantê-los ocupando a GPU, mas descarregá-los em alguns chipsets comuns. Tudo isso se soma em alguns números, nos quais é possível ver — o que é muito simples de mostrar — que há um trabalho incrivelmente árduo a fazer. Então, eles conseguiram fazer tudo isso para vocês e atendê-los com o dobro da taxa de processamento que até nós conseguimos ao executar na nossa própria plataforma de inference. Outro estudo de caso: como mencionei brevemente, o GenPark…

24:27 …casos de uso, mas quero falar sobre isso por outro ângulo. Acho que a Together estava otimizando bastante o lado da inference, mas, nos casos de uso do GenPark, há outro aspecto que está ficando muito popular e é crucial este ano: o caso de uso de aprendizado por reforço com conhecimento e dados específicos do setor. Com um bom modelo base e, depois, aplicando fine-tuning e pós-treinamento, é possível alcançar não apenas eficiência de custos…

25:03 …mas também um resultado de ponta específico para o setor e a tarefa que vocês estão executando, certo? E, nos casos do GenSpark, eles tinham apenas 2.000 apresentações de slides e fizeram pós-treinamento do M3 com essas 2.000 tarefas de slides. Aqui, a tarefa é executá-la por completo. Então, o parâmetro de recompensa nessa equação, que está sendo otimizado, corresponde ao conjunto inteiro de slides…

25:33 …gerado. Assim, todos os aspectos de fidelidade do texto e da aparência dessa geração passam pelo treinamento, resultando em uma avaliação média de 4,25 pelos usuários para a geração de slides com o M3. O Opus 5, que alguns de vocês talvez usem diariamente para gerar slides, está em um nível semelhante, com 4,23. Então, quando vocês têm um desempenho equivalente e a 10% do custo, aí…

26:09 executá-los em produção realmente ajuda nesse caso. Quais são os pontos principais? Acho que há alguns. Então, a MiniMax é um laboratório de modelos de base. Trabalhamos no nível dos modelos de base, entregamos os modelos e garantimos que sejam competitivos e estejam disponíveis a tempo. Também trabalhamos em alguns dos desafios no nível da arquitetura, alguns dos desafios mais difíceis. E deixamos para a indústria e o ecossistema a tarefa de construir sobre isso, para garantir que possa atender a determinados setores e regiões geográficas, trabalhando juntos para ajudar e dar suporte aos nossos clientes. A perspectiva geográfica poderia ser, por exemplo, a soberania de dados europeia, na qual a Gems tem trabalhado tanto. Com o deploy da Together AI, você tem deploys 100% em conformidade com as normas europeias de dados, executando modelos M3.

26:44 Assim, você obtém os benefícios em termos de custo, além de atender aos requisitos de residência de dados. Também há situações em que você, como cliente, pode trazer seu conhecimento especializado e seus dados e fazer fine-tuning em uma infraestrutura em conformidade na Together AI. Esse resultado poderá dar suporte ao seu novo modelo de negócios, ajudar você a captar novos recursos e reduzir a barreira de entrada para participar dessa corrida pelo desenvolvimento de IA.

27:19 Acho que sim. Tendo isso em mente, estaremos por aqui para conversar mais. >> Certo. [aplausos] >> Um dos tópicos que o Rio mencionou, com razão, é RL. Isso tem a ver com levar modelos de pesos abertos ao próximo nível. Agora vou receber nosso VP de model shaping, Max. Aí está você. Dá para ver por um segundo? Ele vai falar sobre tudo relacionado a RL. Max? Obrigado pela apresentação, James. Olá,

27:52 pessoal, meu nome é Max. Trabalho com model shaping e pós-treinamento na Together AI e hoje vou fazer uma breve apresentação de um dos nossos projetos de pesquisa mais recentes, chamado score centering, que estabiliza o RL off-policy. Mas, antes de entrar em detalhes sobre esse projeto, quantas pessoas aqui já usaram agents para trabalhar em conjunto, programar ou realizar todas essas tarefas? Levantem a mão direita. Quantas pessoas já treinaram agents com RL para programação, ou algo assim?

28:22 Levantem a mão esquerda. Algumas pessoas. Deveríamos conversar, porque estamos contratando. Vou falar sobre todos os desafios que surgem ao treinar agents cada vez maiores e fazer isso a custos menores, seguindo o espírito do nosso evento. Primeiro, tive que incluir este slide, essencialmente, porque isso está se tornando cada vez mais importante para os LLMs. Esses dados já são bem antigos. São da apresentação do 01 da OpenAI,

28:56 e o da direita é do Deepseek R1, que demonstrou com bastante clareza que conseguimos resultados cada vez melhores em várias tarefas que normalmente exigem verificação ao escalar o RL sobre modelos de linguagem. Isso se tornou algo extremamente importante em todos os pipelines de pós-treinamento de LLMs. Portanto, não é surpresa que os relatórios técnicos mais recentes incluam muitos detalhes sobre como diferentes

29:31 organizações e laboratórios escalaram o aprendizado por reforço. A segunda coisa relacionada a isso é que o custo de executar o aprendizado por reforço como etapa de adaptação de modelos também está aumentando. A essa altura, já foram estabelecidas muitas relações entre a quantidade de computação usada para treinar modelos com escalonamento de RL, aumentando as fases de rollout e de treinamento — gerando e treinando com mais

30:05 observações do ambiente — e as melhorias que isso proporciona. Como podem ver, é possível aumentar bastante esse volume. Isso vem do artigo sobre escala publicado no início deste ano. Os resultados continuam melhorando de forma bastante constante, embora se estabilizem em certo ponto. Isso se aplica a uma distribuição bem ampla de tarefas. Aqui, são principalmente tarefas de matemática, mas o mesmo vale para programação e muitos outros casos de uso. Então, é claro que, quando vocês começam a pensar nos desafios

30:38 de tentar usar os custos de GPU com eficiência, começam a pensar em otimizar a inference, algo que nós, da Together, já fizemos bastante, porque grande parte da computação aqui é usada na própria inference. Então, todas as técnicas de otimização de kernels, compressão de modelos, compressão de KV cache e muitas outras otimizações entram em jogo, certo? Mas o problema é que, quando vocês começam a aplicar muitas dessas

31:14 técnicas de redução de custos e otimização para RL, surge outro problema. O RL, especialmente em grande escala, nos níveis que mostrei antes, é notoriamente instável. Se vocês aplicassem uma receita de aprendizado por reforço bem padrão, de livro-texto, a configurações de treinamento de LLMs grandes com ambientes suficientemente sofisticados,

31:48 tentando treinar um agent para a própria organização com um modelo de centenas de bilhões de parâmetros, provavelmente veriam o experimento fracassar, e não de uma forma que fosse fácil de recuperar. É claro que isso é muito doloroso quando acontece. Nós, da Together, fazemos muitos experimentos de RL. Então, sentimos essa dor na prática e, obviamente, reiniciar esses experimentos repetidamente resulta em mais

32:18 custos, porque toda a computação de GPU que vocês usaram até aquele momento é basicamente desperdiçada. Bem, vocês ganham experiência, mas depois precisam explicar isso ao pessoal de finanças. Certo. Como resolver isso? Vamos voltar à questão de como o RL funciona em geral e precisamos falar sobre RL off-policy. A função objetivo padrão do gradiente de política, sem modificações, é assim. Essencialmente, o que

32:51 tentamos otimizar — os tipos de atualizações que tentamos fazer — são os gradientes da política, isto é, das probabilidades do modelo de linguagem que produz as ações, ponderados pelas recompensas. Podemos incluir vantagens aqui, como vantagens centralizadas por grupo, ou o que preferirem, mas o princípio central continua o mesmo. O problema é que, na prática, não usamos o mesmo modelo para gerar os rollouts e para treinar,

33:24 para aplicar as atualizações de pesos. Há, então, a parte do trainer e a parte do sampler. Isso significa que a expectativa muda. Obtemos amostras de uma distribuição diferente. No papel, todo o procedimento de treinamento se torna inválido. Na prática, há muitos motivos para essas distribuições não corresponderem. Por exemplo, vocês podem usar kernels diferentes na etapa de treinamento e na etapa de geração, o que costuma ser feito por razões de eficiência, mesmo

33:58 que eles executem as mesmas operações matemáticas, porque as diferenças numéricas podem se acumular bastante. Outro problema é que algumas operações específicas, como a escolha de experts em modelos de mistura de experts, também podem ser diferentes devido a essas diferenças numéricas que se acumulam e levam a decisões diferentes. Isso também precisa ser levado em conta. E o último ponto é que, novamente por razões de eficiência,

34:31 o gerador pode usar versões ligeiramente desatualizadas dos pesos, porque queremos manter nosso pipeline de inference ocupado o tempo todo, sem esperar que todas as atualizações sejam feitas. Isso costuma ser chamado de RL síncrono. As técnicas existentes para resolver isso geralmente se resumem a coisas como amostragem por importância, uma técnica bastante conhecida para voltar à distribuição de treinamento, ou coisas como kernels determinísticos e roteamento

35:01 Há bastante pesquisa sobre infraestrutura e muitos posts de blog especificamente sobre esse problema, mas, no nosso trabalho, Martin, que foi estagiário na nossa equipe e liderou essa pesquisa, e eu pensamos nisso por uma perspectiva um pouco diferente. Será que podemos resolver essa discrepância diretamente na origem? Essa é a ideia central do artigo. Queríamos entender o que torna o RL instável, especificamente,

35:36 …e há bastante pesquisa sobre infraestrutura e publicações de blog sobre esse problema específico. Mas, no nosso trabalho, Martin, que era estagiário da nossa equipe e liderou essa pesquisa, e eu pensamos nisso de uma perspectiva um pouco diferente. Será que podemos resolver essa incompatibilidade diretamente na origem? Essa é a ideia central do artigo. Queríamos entender o que torna o RL instável, especificamente em comparação…

36:08 para SFT. E vou acelerar só um pouquinho aqui. Mas, essencialmente, o problema é que, mesmo comparando o treinamento offline e online, é fácil ver que o comportamento das execuções estáveis e instáveis difere dependendo da recompensa. Então, não se trata apenas da natureza das recompensas no RL, mas também do fato de que as atualizações são online, em comparação com a maneira como você executaria o SFT contra uma distribuição fixa e desalinhada

36:43 que seria algo como destilação. Então, a ideia que propusemos se chama centralização de scores, e quero parar nesta animação só por um segundo para deixar a ideia assentar. A ideia aqui é que há uma lacuna estática entre o treinador e o sampler, que resulta de todas as diferenças que se acumulam por causa dessa implementação numérica e assim por diante. Essa lacuna resulta em uma diferença persistente na maneira como ambas as

37:19 distribuições se comportam, e podemos, de fato, medi-la e levá-la em consideração ao calcular as atualizações em relação às recompensas que realmente geramos. Então, em 10 ou 20 segundos, essa é a ideia central do artigo. Mas o caminho que seguimos é este. Então, sem mais uma tonelada de notação, a ideia é a seguinte. Vamos considerar

37:49 explicitamente esse score esperado em relação ao sampler. Isso basicamente nos diz como os gradientes se comportam quando os ponderamos em relação à distribuição do sampler. Certo? Se o sampler for igual ao gerador, o score esperado é zero. Então, não deveria haver diferença. Mas, agora, se fizermos um pouco de teoria das probabilidades de graduação

38:22 — não olhem para todas essas fórmulas —, chegamos a essa decomposição. A recompensa esperada, cuja fórmula vocês viram há pouco, pode ser expressa como a soma de dois fatores. O segundo fator é o que queremos manter. Ele basicamente nos dá o sinal para o treinamento. Então, é algo que conecta a recompensa aos scores da política. Mas o primeiro é algo que chamamos de deriva. E esse fator depende da

38:53 recompensa média e desse score esperado. Então, novamente, se estivermos on-policy, isso deveria ser zero, mas, infelizmente, na realidade não é. O que podemos fazer nesse caso é ajustar os scores em relação a esse s com uma barra em cima, que podemos calcular explicitamente. Essa é a ideia central: pegar os scores existentes da política e subtrair esses scores esperados em relação à

39:27 distribuição do sampler. Na prática, isso significa que basta pegar as log-probabilidades do sampler e reutilizá-las ao calcular a expectativa. Agora, nossa atualização fica livre de deriva. Ótimo, problema resolvido. Mas vamos olhar os experimentos. Basicamente, há três resultados principais que quero mostrar. Primeiro, adicionamos um pouco de ruído artificial a modelos pequenos, como o Qwen 3 0.6b, e comparamos nosso método com diferentes técnicas importantes de amostragem

40:00 de importância. O resultado central aqui é que, se continuarmos aumentando o grau de desvio em relação à política, os métodos mais robustos são as técnicas de amostragem de importância mais avançadas e a centralização de scores. Mas a vantagem é que podemos combinar a centralização de scores com a amostragem de importância, porque essas duas técnicas não se sobrepõem de forma alguma. E, ao combiná-las, obtemos resultados ainda melhores. Depois, à medida que avançamos para configurações mais realistas, chegamos a

40:35 quantização int8 ou a algum treinamento superassíncrono, o que é ótimo se você quiser economizar custos. E, novamente, a combinação da centralização de scores com a amostragem de importância, ou a centralização de scores sozinha, às vezes supera todos os outros métodos por uma margem bastante grande. E quero dizer que aqui estudamos configurações extremamente radicais, mas isso nos permite avançar ainda mais no aspecto da economia de custos. E então, no caso mais

41:06 interessante, quando passamos para modelos de 30 bilhões, que são consideravelmente maiores, e treinamos com conjuntos de dados de matemática, estudamos várias técnicas diferentes de amostragem de importância, além da centralização de scores, e descobrimos que ela, por si só, tem um desempenho surpreendentemente bom. Então, não é preciso fazer nenhuma correção de importância, mas, ao mesmo tempo, ela produz esses bons resultados. Assim, mesmo quando nenhuma outra técnica consegue

41:38 convergir de forma eficaz, a centralização de scores oferece esse bom aumento de qualidade durante o treinamento. Sobre os detalhes de implementação, vou dizer rapidamente que não é necessário ter toda a distribuição do sampler, porque isso geraria muita sobrecarga na transferência de dados. Você só precisa dos 128 tokens mais prováveis e, na verdade, em alguns casos é possível reduzir ainda mais esse número. Então, para concluir, propomos uma nova perspectiva sobre como pensar no desalinhamento entre a inferência do treinador e a do modelo no RL.

42:11 A outra coisa que estudamos é que propomos a centralização de scores como uma técnica para essa estabilização. Ela é tanto competitiva quanto compatível com abordagens existentes, como a amostragem de importância. O artigo e o código estarão disponíveis muito em breve. Muito obrigado por ouvirem, e agora estou pronto para devolver a palavra ao James. [aplausos] Muito, muito, muito, muito obrigado.

Transcrição original

[00:01] Welcome everyone. Thank you very very much for being here. Um you know a real pleasure to get us kicked off today. I think this is our fifth uh event that we’ve run like this. So um we titled this session open by design. You know over the last 3 to 6 months we’ve seen incredible demand specifically in Europe um to go into the open weight world. So it’s no longer a question of like do we don’t we want to use open weights is how do we actually do it? And today’s session uh you’ve got um a number of speakers from both together uh our

[00:32] partners at Miniaax and of course one of our customers to be in deal. I’m going to introduce our first speaker in sung who’s VP of customer success uh for together. Uh I’m Sar Tropathy. I lead customer experience at together. Um that is really just sort of means everybody that works with our customers directly to make sure that they have strong business and technical outcomes. um that solution architecture for deployed engineering support uh and just making sure all of our customers are successful. Yeah. So I I just kind of

[01:03] want to started start by kind of discussing why we’re here today. Uh as James mentioned, there’s been quite uh a lot of uh noise, positive noise around open models uh the last uh several months and uh and and I just sort of was reading over the weekend and found this Mozilla um you know sort of open state of open source report and this reports across all open source technologies. Uh what was fascinating is that seven of the top 10 models by token volume right now are openw weightight models which is super super exciting and quite different

[01:34] than what you would have seen a year ago or even 9 months ago. Uh and so open source is really taking over. What’s super exciting is that our partners at Miniax are right inside that openweight uh wave um with um with their bleeding edge models that are solving all sorts of amazing use cases that you’ll hear about today. uh and here at together we run that inference layers that take that inference layer that takes these models openweight models into production. Now why do people select open source models? Just out of just get a quick show of hands, how many of you have uh interacted with or deployed an open

[02:07] source model uh yourselves? Okay, cool. So um fortunately then I won’t have to explain this too much but the the core you know reasons we’re seeing around uh you know folks moving to open source models or cost performance and control. cost. One example I’ll give is here in Europe recently with an enterprise we had a we had a customer save 98% uh using an open source model versus uh a model deployed on open AI uh performance we seeing anywhere from 3 to 5x gains on open source models versus closed source

[02:37] models especially when you fine-tune them specific to use cases and on the point of fine-tuning control is a massive massive aspect specifically here in Europe that we’re hearing uh our customers and the community ask for uh uh around uh around models which is shifting them toward openw weight models. Now what does the openw weight model stack look like? We’ve thought a lot about this and you know with the with the nearly million developers that leverage together AI on a yearly basis and the hundreds of customers that we

[03:08] work with, we’ve sort of designed this construct uh you know in our heads of the stack that makes up serving open uh open source models. And it’s really all the stuff that the many of you that raise your hands uh probably use and have seen on a day-to-day basis. The first is the model itself. Um so so you know what you know the actual model weights uh that um you know that sort of make your responses great. One key critical layer here is the inference layer itself. Uh of course this is where together sits uh in serving these open

[03:40] source models. Uh I’ll just you know anecdotally say two years ago when I was not yet at together AI I did not understand nearly how complex it was to actually serve open source models or ser serve models for inference at all right there’s a performance element there’s a reliability element there’s stability element this very very complex layer which is why you’ve seen you know folks like together emerge in the market to take this burden off of you the consumer um from actually hosting the models. Uh the next is gateways. So um this is the

[04:13] layer that that really decides whether it’s which provider or which model is actually serving the end user request. Uh this is a area that’s really popped off in the last uh you know in the last year or so. You saw open router got acquired by stripe for this amazing technology that they’ve built. And we see more and more routers coming up uh and gateways coming up in the um in the field um you know from from from great contributors in the open source community to just make it easy for you all uh the community to leverage

[04:44] whichever models that you want and not really have to think about where uh the selection of these models. Uh the harness layer. So this is the application layer. I mean, you know, many of you have probably used things like open code, things like cursor, uh things like cloud code. Um super exciting, uh to also share that, you know, a lot of these sort of closed source variants of uh front-end applications are now able to interact with open source models. So one thing that we’ve built here at together uh is called together link uh which actually enables

[05:17] developers to use models like miniax m3 um within cloud code. So if that’s something that you guys are interested in leveraging open source models within a closed source interface that’s something that u you know that we can absolutely chat about and I think something that in the community people don’t know a whole lot about and then of course there’s the tools layer uh the final layer of the might stack um which uh which is your MCPs your skills uh and the things that know exactly sort of how to do specific tasks um you know within uh within your open source stack. This is the might stack. Happy to chat more

[05:50] about this, but this is sort of our take on everything that you need to run open models. Uh and uh and and fortunately uh the AI overload lords have gotten good enough to sort of do all this for you if you really don’t want to think about it. What are we seeing uh in in terms of use cases for open source models? Um you know, unsurprisingly, the the biggest is coding agents. Uh I I think most uh uh even semi-advanced uh sort of software development shops these days are um are

[06:20] writing more code through agents than uh through humans which uh which is likely the right way to do things. How many of you you have used co-working agents? I’m just curious. So this is another one that we’re seeing quite a bit and being that we are in one of the world’s largest financial hubs today. I’m based in San Francisco by the way, so it’s I’m uh it’s it’s nice to nice to be in London. But what this is a use case that we’re actually seeing quite a bit of in financial services. Uh there’s so much sort of excelling and various different application work to be done in different financial systems that

[06:53] training co-work agents to go do this um with really really smart open source models is something that we’re seeing quite a bit of. Uh and then of course voice content generation. Um, the likes of folks like Higsfield are are making uh incredible incredible movie productions, not just, you know, cat videos pretending to be Donald Trump, but like true uh true videos uh and true movies um to uh uh to to, you know, to sort of put out there using incredible open source models. Cool. Okay. So another point uh I think

[07:28] that would be interesting uh for you guys to know and to sort of speak about is post- training in RL. And this is something that you’ll hear uh another talk uh from my colleague Max about this evening. Uh but post training in RL is I think you know just as in 26 2026 was the year or is emerging as the year of open source models. We see the sort of late 2026 and early 2027 to be um you know the time that’s going to sort of see the proliferation of post- training and reinforcement learning. Uh this is really the sort of basis on which uh we

[08:04] believe um companies are going to become differentiated long term. So, in a world where there’s an amazing new open- source model every day, um, how do you as a company and you as a development shop, you know, stay differentiated? And this is something that we’re spending a lot of time talking to our friends at Miniax about as well as is actually helping our customers do reinforcement learning to control the quality, speed, control, and stay differentiated um with their offerings. And this is something that uh that just another sort of area

[08:36] we love um giving back to users and helping them um you know stay sort of at the forefront of um of their of their domains be it financial services or healthcare or whatever it may be. So I won’t share too much here because you’re going to hear a lot more about uh you know from the expert but this is another very interesting uh space to watch. uh as uh you know as you may know uh together hosts many open source models um you know various you know across language models across uh voice models uh we have many different partners in

[09:09] the open source space uh and uh and you’ll hear and you’ll hear directly from our uh our friends at Miniax about them as well today so I’ll just give you a quick quick intro into the together platform I won’t spend too much time here let you guys sort of ask questions later later but Um as you sort of heard themes we you know we provide our AI infrastructure as a service. We have compute deployed globally and serve 200 plus open source models on this platform allowing you to do reinforcement learning serve these models shape these

[09:40] models giving you a rich developer experience on top to sort of manage all of this. Our compute I think one of the key differentiators of together comput is owned and operated by us uh globally. So through uh through owning compute directly through having joint ventures uh with f folks globally and through leasing some compute we do uh you know retain quite a bit of an advantage on getting you the compute that you need when you need it. Final point I’ll make perhaps the most interesting thing that we uh that we

[10:11] spent most of our time doing with customers uh is making inference cost effective for the community. And so uh if you think about what this takes, it’s really sort of twopronged. Uh the first is optimizing the inference engine itself. This is these are the things that you don’t want to do yourself when it comes to inference. uh things like training specular decoding models, doing prefix caching, disagregated serving uh between prefill and decode, structured outputs, function calling. All of these different uh aspects of the inference stack that are quite complicated to to execute

[10:43] yourself, we sort of do uh for our users and we partner with our uh with our developers uh as well as uh our partners and customers uh to do for you. And then of course there are the the there are the other aspects of just deploying a distributed system which um has never really been easy um and and continues to be a hard problem to solve. Uh doing autoscaling, queuing, high availability, multi-region deployments, uh deploying context pools, things like this. These are all things that between our software, our infrastructure, and uh our

[11:16] for deployed teams, we’re we’re happy to help our customers with. So um with that I will pass it on to uh our friends at Miniax. Rio >> my name is Rio. Um I’m heading up the Minimax developments of course Emia. Uh we do have a team here. Some of the members like Andrean Jazz and Elliot feel free to grab them and everything that you interested about us you can feel free to ask. Um I think the content of today um is about how to run um open

[11:51] models in production. So when you think about the production then you need to think about all the attributes where if you are just calling API wouldn’t be worried about. So it’s all the things that uh a open model enables you to do uh and to fine-tune to the qualities that you like. And I think ultimately the goal is to achieve a balance between quality and pricing being cost effective. Um what minmax is uh you’ve heard of a lot about the names minmax and doing uh the customer cases by um by sang here and uh just very quickly uh we

[12:29] are a frontier model lab so established four and a half years ago. Uh we are the Asia’s first uh lab working on foundation models. before Chachibility was launched. Uh and over the years uh we’ve made uh our presence across the world and actually we already been uh listed on Hong Kong stock exchange. Most of our revenue comes from outside of China and we we’ve been pivoting from consumer uh services to enterprise services and last quarter report

[12:59] disclosed this number. So over 60% so a majority of our revenue now comes from uh enterprise customers. So um and I think two key words about minmax uh is uh is first one is multimodality uh that is by design. Uh so right from the very beginning our interpretation of achieving AGI is actually simulation of the real world. You can’t do that without really see uh de being really good at not just the text model but also the video and the audios everything that

[13:35] encompasses how you would receive and perceives information uh in the real world and second is about openness right so most of our model with a caveat that uh the speech model right now supports private deployment but everything else so ranging from text model to video model to music model even open weights so where people can download and run them. We we are doing this uh because that’s in line with the mission of the company. So uh making intelligence uh

[14:09] accessible for everyone and that’s why uh that’s why we’re doing this. Uh I want to use this case to show you that the uh frontier video generation and open weights model are not something there’s a trade-off you need to choose between them. So this is the very first time that the market has a sort video generation model which is also open weights. um it’s achieved number one ranking but the ranking is something that the community work continuously to

[14:39] build on with the post training uh etc. So for example like one of our other partner FA developed a fantastic live streaming model based on uh the the ways that we’ve released but H3 is a model that can generates understands and generates text video and audio in one pass. So uh let me show you a quality uh of this by a picking duck. So um any of you have tried picking duck before

[15:10] great then uh so hopefully this one plays or not? So it should be playing we’ll have to skip unfortunately no ping duck tonight. So we we we have loads of uh you know examples where you can search on YouTube. Um so that was uh the the video model S3 but I think the crown of the jewel is our flagship model M3. So it’s a textbased model. Um it can intake up to 1 million of contextual information. Uh

[15:43] it can generates coding uh etc. But I think the point about how uh economically this model runs is something to do with how the model pays attention right so uh when when a model runs um these context information is where is mostly expensive and we’ve developed the system such that uh it will do a cheap scoring across all the contextual trunks and we’ll be only

[16:13] paying attention to those selective ones. Right? So that’s we call it the sparse attention scheme and with this selectiveness then effectively it can lower that uh running of it to a 5% level. So compared to the previous generation and it is a foundation of all the cost effects uh that this model uh builds on. So why pricing would matter? So um currently um minimax M3 it runs

[16:44] you know normally at $.3 that’s something like5 to 20% of all the uh top close models um and not by our words but by uh Gilmo he runs Verso and he did say upon our model launching uh when he was testing against his own benchmarks that it is the top performance quality on par with some of the best models right behind the top uh frontier close models but 10 times cheaper. So

[17:18] the question now uh stops being uh when you’re running production stops being so uh which model is the best model but now you’re asking so which tasks should I send to the best model right and at the end of the day a product system may realize that it’s a minority uh of the tasks and and that is why uh the scalability uh will be achieved using open models um and I think um saying by saying linking open model is cheaper would be

[17:53] the wrong message and wrong lesson to go is really the about the the controllers right so a closed model it gives you an API it’s a simple uh price of the uh consumptions and but everything inside it uh how the model consumes the memories how they cue your request everything is closed and that decisions has been made for you but an open model opens us those layers those levers where you can fine-tune and you can walk through the partners uh like together AI

[18:27] to to together to achieve the optimal on that uh cost effectiveness curve for your specific use cases and I’ll be quickly going through like some of the levers to show you like there’s real cost savings can be delivered there so lever number one is memory u memory is most important thing because uh you will probably own or rent uh graphic cards and those will be some of the most expensive things you ever owned. [laughter] Um and therefore uh deciding

[19:00] like what precision level of the models that you run is very critical. So if you lower that memory is needed. So for example, if you half half it um the the precision level then it takes like 50% less of the memory but you have to uh bear in mind that lower precision does mean like a reduction in the quality of the model outputs. Therefore you need to balance uh the cost considerations of the model uh quality versus the cost of running it on your graphic card. Right?

[19:36] So um the there’s some point of the curve that you need to uh consider but that choice of uh determination would be yours. Uh lever number two and number three are really I think uh both sides of the same coin. So we’ve got prefill and decode. So basically uh how uh a model reads uh and writes right. So um you have the levers to to fine-tune and for with minimax sparse attention as I mentioned. So uh you can really like jump uh when when in the contextual uh

[20:13] readings. So therefore uh achieve a lower percentage of the token to first uh time arriving and uh you can also do things like uh caching right. So only stores uh the information temporarily. So uh in instead of going through the whole uh contextual reading again and in a lot of the cases contextual reading is very expensive to run right when a model takes your input. you actually go through all the back history and

[20:46] documents and uh contents that you have talked through and if you do caching well uh that low that cost can be significantly lowered. Therefore, one of the most important metrics in inferencing is that cache heat rates. How you measure a platform uh the quality uh of the caching actually determines how you run uh your real real production system cost savings. um and things like the and decodings or when the rights or the output speeds also

[21:18] matters. You can do some lowlevel coding optimizations like on the kernel level to improve that uh speed as well. Um level number four and this is some sometimes like get overlooked because it’s kind of like a um product decision wrapped in the infrastructure layer. Uh so like there’s some benchmark numbers for example so when you run minimax M3 on just four cards and depending on how

[21:48] many concurrent users you send right so if you just send four concurrent users to those four cars and you get really fast speed like 200 tokens per second per user. But if you decide to send more concurrent user to that then each of the user will get less of the speed but the total output of that generations is higher. Therefore the per token cost of running is cheaper. Right? So you need to think about the kind of use case and applications you run for coding

[22:20] assistant agent then you might decide it is more critical the speed matters. Therefore, you need to send less users per uh GPU card and for some like batch operations type of the processes then that total uh throughput uh total output is important. So um concurrency sometimes gets overlooked as well. together is is really um our preferred uh cloud partner uh for M3 and when M3 was shipping so their engineers just not not just like download it and then serve

[22:53] it to you guys but they did some really serious optimizations to it and that’s why like Saron was saying like inferencing is actually incredible hard thing to do. there’s uh many many different layers where you can fine-tune to achieve a better like throughput or or or or the uh kind of quality of of serving it. uh things like uh there there are four four things listing here that they’ve done uh like changing the how the attention scheme so uh when a

[23:23] model reads so how that uh you know information is passed between the main card and the temporary memories uh instead of passing them uh like multiplying through uh they’ve uh reworked on that KV uh block attention so that it just gets read once things like the lowlevel kernel level of the coding optimization ations uh that they’ve done uh things like offloading like non-critical image and video pre-processing type of tasks not let

[23:54] them occupy the GPU but offload them with some normal like chipsets. So all of things are adding together in some numbers where you can see which which is very light in just showing it but there’s like incredible hard work to do. So they’ve managed to do all of this uh for you and serve them at twice of the throughput that even for us uh like running through our own uh inferencing uh platform. Another case study so uh as like briefly touched upon Jensen Park

[24:27] use cases but I want to uh talk about it through another angle. So uh I think together was optimizing a lot on the inferencing side but on the genp park use cases there’s another side to it which is getting very very popular and critical for for this year the reinforce learning use case um with industry’s specific knowledge uh and and data then with a good foundation base model and when you finetune it post train it uh it can achieve not only the cost efficiency

[25:03] but also a top result specific to the industry and task that you are running right and in the gen chance transpar cases they’ve only got like 2,000 slide deck and they’ve post trend M3 with these 2,000 slide uh tasks so here it’s a complete task of running it so so now the equation in that uh uh so the reward uh parameter in that equation that’s getting optimized is the entire uh slice

[25:33] slice stack gets generated. So all the kind of like faithfulness of the text and uh the look and feel of that generation will get trend and therefore resulting in a um 4.25 average user rating for uh M3 uh slice generation and the OPUS 5 which some of you might use that on a daily basis for slice generation uh is similar level of 4.2 two three. So when you have such performance uh on par with each other and at 10 of 10% of the cost then

[26:09] running these uh in production uh is really uh helping uh the case. Um what’s the takeaways? So um I think a couple points so uh minimax. So we are the foundation model lab. We uh work on uh the foundation model level and we ships the model and making sure that they’re competitive and they are in time. Um and we work on some of the architectural level uh of the challenges, some of the very uh toughest challenges there. Um and um and and we

[26:44] leave it to the uh industry uh and the ecosystem to build on uh on top of that to make sure it can serve some particular industry can serve some particular geographic regions uh and working together to uh help and support our customers. The geo uh like angle could be like the European uh data sovereignty angle that gems has been working so hard on. So with together AI deployment you have a 100% European data compliant deployments running M3 models.

[27:19] So you get the benefits of the cost as well as the uh data residency requirements. Uh there are also the cases where you as a customer can bring your specialized knowledge and data and get trend on compliant uh infrastructure on uh together AI and that uh result will be able to support your new business model will get you new fun raising uh fundraising and and lower the bar of entry for you to uh participate uh in that uh AI uh AI development race.

[27:52] I think so. Uh with that in mind, so um we we’ll be here to for further discussions. >> Okay. [applause] >> Um one of the topics Rio kind of um rightly mentioned is the topic of RL. So um you know that’s really about taking open weight models to the next level. And so now I’m going to be joined by our VP of model shaping in Max. There you are. Can see for a sec. Who’s going to talk through um all things RL Max? Thank you for the introduction James. Hey

[28:22] everyone, my name is Max. I work on model shaping and post- trainining at together AI and today I am going to give a short overview of one of our latest research projects uh the name of which is score centering uh that stabilizes of policy RL uh but before I go into any detail on that project how many people here have used uh agents for co-working for coding for all of these tasks lift your right hand how many people have trained um agents for RL for coding any

[28:56] of that raise your left hand uh a few uh we should talk because we are hiring uh but um I’m going to talk about all of the challenges that come with training progressively larger agents and doing this at lower costs in the spirit of our event. First of all uh I had to include this slide essentially for uh large language models is growing to be increasingly important. These are like super like old figures by now. These are from the 01 presentation um by OpenAI

[29:31] and the right one is from Deepseek R1 where it was demonstrated pretty clearly that we are able to achieve stronger and stronger results on a variety of tasks that usually require verification uh by scaling RL on top of language models. So that’s grown to be an extremely important thing in all of the LLM post training pipelines. So you would not be surprised to find that the latest technical reports all include tons of details about how uh different

[30:05] organizations, different labs scaled reinforcement learning. Now the second thing that comes to that uh with that is that the price of running reinforcement learning as a stage of uh model adaptation is growing as well. Uh there have been like plenty established relationships by this point between the amount of compute you spend on training models with a rail like scaling the rollout phase and the training phase uh generating and training on more uh

[30:38] observations from the environment uh and the improvement that you get from that. So as you can see you can increase that pretty far. That’s from the scale paper uh earlier this year. the results while uh leveling off at some point uh keep improving quite steadily. So that holds across quite a broad distribution of tasks. Here it’s mostly maths but the same thing uh applies to coding and many other use cases. So of course once you start thinking about the uh challenges

[31:14] of trying to spend the GPU cost efficiently you start thinking about optimizing inference which of courseh we together have done quite quite a lot and because a lot of the compute here is spent on inference itself. So all of the techniques behind kernel optimizations uh model compression, KV cache compression and many many other uh optimizations they come into play here, right? But the problem is that as you start applying uh many of these

[31:48] cost-saving techniques and optimization techniques for RL, you are faced with another problem. And here the problem is that uh RL especially at scale at the scales that I’ve shown to you previously is notoriously unstable. If you were to apply a very standard like textbook reinforcement learning recipe to large uh language model training setups with sufficiently sophisticated environments

[32:18] uh trying to train an agent for your own organization with like a model that takes hundreds of billions of parameters, you would likely see uh your experiment fail and not in a way that uh would like be easily recoverable. That of course is very painful when you’re faced with this. We together like run uh lots of aerial experiments. So we’ve experienced that pain firsthand and um obviously as you keep needing to restart such experiments, it results in further

[32:51] cost increases for you because all of the GPU compute you’ve spent up until that point is basically wasted. Well, you gain some experience but then tell it to finance. Okay. Um so how do you solve this? Let’s now get back into [clears throat] the question of uh how RL works in general and we need to talk about of policy RL. So the default policy gradient object [laughter] objective unmodified one looks like this. So essentially what

[33:24] we’re trying to uh optimize the kinds of updates we’re trying to make are essentially the uh gradients of the policy of the like language model probabilities that produces the actions uh weighted by the rewards. You can add advantages here like group centered advantages you name it but the core principle remains the same. Right now the problem is that we uh in practice do not use the same model for generating rollouts and for training

[33:58] for applying the weight updates. So there is the trainer part and the sampler part. What it means is that the expectation now changes. We get samplers from a different distribution. the whole uh training procedure on paper becomes invalid. And uh in practice there are many reasons why these distributions do not match. Uh for instance, you could be using different kernels at the training stage and the generator stage which is often done for efficiency reasons even

[34:31] if they perform the same mathematical operations because of the numerical differences that can accumulate quite a lot. The other problem is that some operations specifically such as expert choices in mixture of expert models might also differ uh due to this numerical differences that accumulate and result in different decisions. So that also needs to be taken into account. Um and the final point is that the generator again for efficiency

[35:01] reasons might be using slightly outdated versions of the weights because we want to keep our inference pipeline busier at all times without waiting for all the updates to be performed. That’s usually called a synchronous RL. So um the existing techniques to solve this usually boil down to things such as important sampling uh which is a fairly well-known technique to get back on the training distribution or things such as deterministic kernels rout

[35:36] and there’s like plenty of infrastructure research and blog posts about this problem specifically but in our work uh Martin who was an intern on our team who’s like actually led that research uh uh and myself uh thought about it from a slightly different perspective. Uh can we address that uh mismatch directly at its root and that’s the core idea of the paper. We wanted to understand what makes RL unstable specifically compared

[36:08] to SFT. And I’m going to speed up just a bit here. But essentially the problem is that we uh even comparing uh offline and online training uh can easily see that the behavior of uh like stable and unstable runs differs depending on the reward. So there is something not just about the nature of rewards in RL but also about the fact that the updates are online compared to the way you would run SFT against a fixed uh mismatched

[36:43] distribution which would be kind of like distillation. So the idea that we proposed is called score centering and I want to stop on this uh animation for just a second to let uh it sink in. And the idea here is that uh there is um static gap between the trainer and the sampler that results from all of the differences that like accumulate due to this like numeric implementation and so on. So that gap results in a persistent difference in how uh like both

[37:19] distributions behave and we can actually measure it and uh take it um into consideration when computing the updates with respect to our like actually generated rewards. So that on like in 10 20 seconds is the core idea of the paper. But the way we go through it is like this. So without again like tons of notation, the idea is as follows. Let’s have

[37:49] uh this uh expected score uh with respect to the sampler explicitly written out. So that basically tells us uh how do the gradients uh behave when we weigh them with respect with the sampler distribution. Right? So if the sampler is the same as the generator the score in expectation is zero. So there should be no um difference. But now if we u do a bit of like uh second year

[38:22] undergrad probability theory don’t look at all of these formulas. We end up with this decomposition. So the expected reward, the formula you’ve seen uh a bit of time ago, can be expressed as a sum of two factors. The second factor is the one we want to keep. It basically gives us the signal for the training. So that’s something that uh connects the reward and the policy scores. But the first one is something that we call the drift. And that one depends on the

[38:53] average reward and on this uh expected score. So again if we are on policy that should be zero but in reality sadly it isn’t. Uh what can we do in that case is let’s just adjust the uh scores with respect to this s u uh overline that we can compute explicitly. So that’s the core idea like let’s just take uh the existing scores of uh the policy and then subtract these expected scores with

[39:27] respect to the sampler distribution. In practice it means that we simply need to take the log probabilities of the sampler and reuse them when we compute the expectation. Now uh our update here becomes free of drift. Cool problem solved. But let’s actually look at the experiments. So basically there are three main results that I want to show. Number one, uh we add some artificial noise for small models like quen 3 0.6b and compare

[40:00] ourselves against different important sampling techniques. The core result here is that if you keep increasing the degree of of policiness, the strongest methods that survive are the most um advanced uh important sampling techniques and score centering. But the advantage here is that we can combine score centering with important sampling because these two techniques they do not overlap in any way. So and as you combine them you get even better results. Um then as we move to more realistic settings we end up with uh

[40:35] like intate quantization or some super asynchronous training which is cool if you want to save costs. And here again like the combination of square centering with important sampling or square centering standalone sometimes outperforms all of the other methods by quite a huge margin. And I do want to say that here we study super extreme settings but that uh kind of allows us to push further the uh costsaving angle. Um and then like in the most um

[41:06] interesting case when we move to 30 billion models like uh quite a bit larger and train on math data sets. We’ve studied a number of different important sampling techniques as well as score centering and it turns out that uh on its own it performs uh surprisingly well. So you do not need to do any uh important corrections but at the same time it’s uh like produces this uh nice results. So even when no other techniques are able to effectively

[41:38] converge, score centering gives you uh this nice boost in uh quality during training. So for implementation details, I will just quickly say that you do not need to have the whole distribution from the sampler because that would be lots of data transfer overhead. Uh you need just top 128 uh tokens and actually it’s possible to reduce even further in some cases. Uh so conclusion we propose a new perspective on [snorts] how one could think about uh trainer inference

[42:11] mismatch in RL. The other thing that we study is that we propose score centering as a technique for this uh stabilization. Uh it is both competitive and compatible with existing approaches such as important sampling. Um and the paper with the code are coming very very soon. Uh thank you very much for listening and now I’m ready to give it back to James. [applause] Thank you very very very very much.