Tudo o que você precisa saber sobre o Muse Spark Open: uma conversa com Meta e Together AI

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: Everything you need to know about Muse Spark Open: A conversation with Meta and Together AI · Canal: Together AI · 58:56 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Inferência e otimização de modelos, Modelos locais e open source, Modelos multimodais

Resumo

Representantes da Meta e da Together AI apresentam o Muse Spark Open, um modelo de pesos abertos voltado a tarefas agentic, como programação, raciocínio multimodal e execução de fluxos de trabalho longos. A conversa detalha sua arquitetura MoE esparsa, o suporte a uma context window de até 1 milhão de tokens e os desafios de servir um modelo dessa escala. A equipe discute estratégias de inference, incluindo cache de KV, speculative decoding e separação entre prefill e decode, além de fine-tuning, tool calling e entradas de áudio. Ao final, a Meta explica por que disponibiliza modelos abertos e destaca o potencial de ampliar o acesso e a inovação.

Pontos-chave

• O Muse Spark Open é um modelo de pesos abertos da Meta Superintelligence Labs, treinado para fluxos de trabalho agentic de longa duração.
• A arquitetura MoE tem 816 bilhões de parâmetros totais e ativa 42 bilhões por token, selecionando oito entre 256 experts.
• O modelo aceita entradas de texto, imagem, vídeo e áudio, e produz texto.
• A context window pode chegar a 1 milhão de tokens; a maioria das camadas de atenção usa uma janela deslizante de 2 mil tokens.
• O serving exige equilibrar o uso de memória para os pesos, o cache de KV, os kernels e o processamento de requisições concorrentes.
• Speculative decoding e a separação entre prefill e decode são discutidos como formas de melhorar desempenho e throughput.
• O formato de conversa separa canais de raciocínio, comentários e tool calls, ajudando o harness a encaminhar ou exibir cada parte.
• A Meta afirma que o modelo pode ser fine-tuned; a conversa destaca a importância de evals adequados para orientar esse processo.
• A entrada de áudio permite analisar dados falados sem depender apenas de transcrição, abrindo possibilidades para aplicações empresariais e agentes.
• A Meta defende a publicação de modelos abertos como forma de ampliar o acesso à tecnologia e estimular novos usos.

Capítulos

Início	Capítulo	Resumo
00:01	Abertura e apresentações	Os participantes apresentam o objetivo do webinar e introduzem a conversa sobre o Muse Spark Open.
04:13	Apresentação do Muse Spark Open	Corey descreve o modelo, sua arquitetura, modalidades de entrada, usos pretendidos e avaliações.
09:24	Arquitetura e características do modelo	Joey detalha a esparsidade, a atenção por janela deslizante, os níveis de raciocínio e o formato de conversa.
14:08	Memória e custo da context window longa	A apresentação compara os requisitos de cache de KV e explica como a atenção por janela reduz a memória necessária.
20:21	Serving, cache e speculative decoding	Joey aborda os requisitos de GPU, o uso de memória, o batching e técnicas para acelerar a geração.
25:41	Separação de prefill e decode	A conversa explica como separar as etapas de serving e gerenciar cache para atender a cargas agentic.
30:21	Fine-tuning e evals	Os participantes discutem fine-tuning para casos de uso específicos e a necessidade de evals que orientem o processo.
36:37	Formato de conversa e tool calling	A equipe explica como os canais e tokens de término ajudam a coordenar raciocínio, respostas e chamadas de ferramentas.
41:19	Usos multimodais e entrada de áudio	Corey e o apresentador discutem aplicações de áudio, como analisar gravações e extrair informações além da transcrição.
44:53	Otimização para diferentes cargas de trabalho	Joey explica como considerar cache, throughput e escalabilidade ao configurar prefill e decode para diferentes usos.
49:02	Tool calling e avaliação do modelo	A conversa destaca a capacidade de verificar e refazer tool calls e recomenda testar o modelo com casos de uso próprios.
52:41	Otimização final e acesso aberto	Joey resume os desafios de cache e paralelismo, e Corey encerra defendendo o acesso amplo a modelos abertos.

Citações

O modelo é nativamente multimodal. Ele recebe entradas de texto, imagem, vídeo e áudio, e produz texto. — 05:14

O formato de conversa foi feito para um agent. — 18:16

O fine-tuning é uma das propostas de valor exclusivas dos modelos de pesos abertos. — 32:29

O futuro é para todos. — 57:24

Conceitos e entidades

• Muse Spark Open (modelo): Modelo de pesos abertos da Meta apresentado como voltado a coding, raciocínio multimodal e fluxos de trabalho agentic.
• Meta Superintelligence Labs (empresa): Organização da Meta identificada na conversa como responsável pelo Muse Spark Open.
• Together AI (empresa): Empresa que participa da apresentação e discute o serving e a otimização de inference do modelo.
• Corey Featherly (pessoa): Representante da Meta que apresenta o modelo e responde a perguntas sobre seus usos e fine-tuning.
• Joey Huang (pessoa): Integrante da equipe de inference da Together que explica a arquitetura e as estratégias de serving.
• Dan (pessoa): Participante da Together AI apresentado como líder de pesquisa.
• Mixture of Experts (MoE) (conceito): Arquitetura esparsa em que o modelo ativa apenas parte de seus parâmetros para processar cada token.
• Sliding Window Attention (SWA) (conceito): Mecanismo de atenção que limita o contexto considerado por determinadas camadas a uma janela deslizante.
• speculative decoding (conceito): Técnica que usa um modelo menor para propor tokens e o modelo-alvo para verificá-los em uma passagem.
• PD disaggregation (conceito): Separação das etapas de prefill e decode em recursos de serving distintos para otimizar cada etapa.
• KV cache (conceito): Cache que armazena estados de atenção para reduzir trabalho repetido durante o processamento de sequências.
• Muse model license (conceito): Licença mencionada na apresentação como aquela sob a qual o modelo é disponibilizado.
• Together platform (ferramenta): Plataforma citada como opção para fazer fine-tuning do modelo, incluindo RL, SFT e DPO.

Tradução completa (pt-BR)

00:01 [música] [música] [música] [música]

00:33 >> Olá, pessoal, sejam bem-vindos. Vamos esperar talvez alguns minutos para as pessoas começarem a chegar e, então, podemos começar. Olá. Oi, Dan. >> Oi, como vai? >> Oi. Estamos esperando há bastante tempo. Ótimo. Estamos esperando as pessoas começarem a

01:03 chegar e, então, podemos fazer uma rodada de apresentações e começar com as apresentações. Depois, também teremos uma discussão no final. Certo, ótimo. Estamos transmitindo no YouTube. Estamos ao vivo no X, antigo Twitter.

01:37 Certo. Beleza. Acho que recebi o sinal verde. Acho que podemos começar. Então, talvez eu contextualize o assunto e depois passe a palavra para todos se apresentarem. Aí podemos entrar no tema. Neste webinar, talvez durante a próxima hora, vamos nos aprofundar no Muse Spark Open. Quando entrei na Together, há cerca de dois anos, aquela era a semana em que o Llama 3 tinha sido lançado. Era outra época. Foi antes da era dos agents. Aquele era um modelo lendário. E agora temos este modelo desenvolvido para agents. Estou muito empolgado para aprender mais sobre ele, tanto sobre o comportamento do modelo quanto sobre a pilha de serving e como fazê-lo funcionar em produção. Vou começar me apresentando e depois passo a palavra para Corey, da Meta, e então para a equipe da Together. Sou engenheiro da equipe de DevRel. Estou muito empolgado em organizar estes webinars. E, se

02:10 a comunidade tiver outras coisas que gostaria de ver ou outras perguntas, fiquem à vontade para me avisar. Vamos reunir perguntas durante o webinar. Então, fiquem à vontade para enviá-las pelo YouTube, no chat. Depois, podemos respondê-las. Também tenho algumas perguntas que quero explorar. Podemos fazer isso também. Então, vou parar por aqui e passar a palavra para Corey se apresentar. >> Certo, prazer em conhecer todo mundo. Sou Corey Featherly, da Meta. Trabalho na Meta há cerca de oito anos e meio, no escritório de Austin, e faço parte da equipe de engenharia de parcerias de GenAI. Estou ansioso para conversar com vocês sobre o Muse Spark Open hoje. >> Ótimo. Joey, talvez você possa ir agora. >> Sim, claro. Oi, pessoal. Meu nome é Joey Huang e faço parte da equipe de inference da Together, onde trabalho principalmente para identificar oportunidades de otimização que permitam acelerar a inference e aumentar a capacidade de processamento. Estou muito empolgado para aprender e compartilhar informações sobre o novo modelo mais recente, o Muse Spark. >> Ótimo. Obrigado. Estou ansioso pela sua apresentação. E, por último, mas não menos importante… >> Oi, sou Dan. Lidero a área de pesquisa na Together. >> Ótimo. Beleza. Como eu disse, se alguém tiver perguntas, fique à vontade para enviá-las no chat. Vamos respondê-las depois das apresentações. Sem mais delongas, passo a palavra para Corey, que vai nos apresentar o Muse Spark Open e dar início à sessão. Vou sair do palco e colocar seus slides aqui, Corey. >> Certo. Ótimo. Como eu disse, estou empolgado para falar com todos sobre o Muse Spark Open hoje. Então, o que é o Muse Spark Open? É um modelo com pesos abertos da Meta Superintelligence Labs. Nesta breve introdução, vou falar sobre as capacidades que os desenvolvedores podem usar para criar soluções e sobre como o modelo dá suporte a programação, trabalho com agents e raciocínio multimodal.

02:41 ???

03:11 ???

03:42 ???

04:13 ???

04:44 ???

05:14 ???

05:45 ???

06:17 ???

06:47 ???

07:18 ???

07:50 ???

08:21 ???

08:52 ???

09:24 ???

09:56 ???

10:29 Nesta apresentação, talvez eu comece pela perspectiva de serving, mas minha apresentação terá duas partes. A primeira parte vai fazer uma análise aprofundada da arquitetura do modelo, e a segunda vai abordar o que essa arquitetura significa para o serving, especialmente para um provedor de inference como a Together. Certo, sim. Então, primeiro, alguns números importantes sobre o Muse que já mencionamos:

11:00 o modelo em si tem 816 bilhões de parâmetros, mas, para cada token, ativa apenas cerca de 42 bilhões. Portanto, são aproximadamente 5% dos pesos: é um modelo muito esparso. Para comprimentos de contexto intermediários, ele oferece suporte a até 1 milhão de tokens. E, sim, tem quatro modalidades — texto, imagem, vídeo e áudio — e quatro níveis de esforço. Sim, então…

11:30 Então, olhando para esses números, da minha perspectiva, podemos identificar algumas apostas. Primeiro, o modelo é muito esparso. Para cada token, ele usa apenas oito dos 256 experts, e é um modelo MoE. Portanto, de ponta a ponta, cada token usa apenas 5% da capacidade computacional do modelo completo. O que significa que podemos…

12:02 Sim, podemos falar um pouco mais sobre isso daqui a pouco, mas o modelo é muito esparso. Então, essa é uma aposta na esparsidade. A segunda aposta aparece quando olhamos para as camadas de atenção. Em linhas gerais, o Muse Spark usa GQA, ou atenção por consultas agrupadas. Mas a maioria das camadas — 46 das 62 — considera apenas uma janela deslizante de 2 mil tokens. Portanto, independentemente do comprimento do…

12:34 prompt, essas camadas só vão considerar até 2 mil tokens. E esse tipo de projeto também torna acessível e econômico oferecer serving para um contexto de 1 milhão de tokens. Além disso, é claro, é um modelo recente, e o usuário pode especificar diferentes níveis de esforço para ajustar quanto será gasto no raciocínio. Se…

13:04 a precisão for o mais importante, talvez você queira definir o nível como extra high. E, se for um caso de uso em que a baixa latência é importante, talvez possa defini-lo como low. Quanto à parte dos Sparse Experts, ela implica uma estrutura de MoE latente. O tamanho da camada oculta do modelo é 8.192. Antes de entrar na camada MoE — a camada MoE principal —, ela…

13:36 é projetada para uma dimensão de 4 mil. Em seguida, o roteador seleciona, em paralelo, oito dos 256 experts, e só esses experts são usados nos cálculos daquele caso específico. Depois da camada MoE, a representação é expandida de volta para as camadas ocultas de 8 mil e reintegrada ao fluxo principal. No total, apenas…

14:08 5% dos pesos são ativados para cada token. Portanto, em cenários de alto throughput, isso é muito eficiente. E, quanto à SWA, aqui está uma visualização da distribuição entre as camadas densas e as camadas SWA. A escolha é simples: se…

14:38 considerarmos a precisão FP8, que já é bastante compacta, e se todas as camadas fossem GQA densa convencional, para oferecer suporte a um contexto de 1 milhão de tokens seriam necessários 124 GB só para atender a uma única solicitação com contexto de 1 milhão de tokens. Isso basicamente não é viável no hardware atual. Mas…

15:09 por causa da GQA, em comparação com uma camada densa, especialmente nessa escala de contexto de 1 milhão de tokens, o custo da GQA é basicamente insignificante, porque ela só precisa manter o KV cache de 2 mil tokens. Assim, a maior parte do KV cache pode ser descartada imediatamente após o prefill.

15:39 Embora ainda seja necessário algum espaço, dá para calcular aproximadamente que isso economiza imediatamente 75% do KV cache, o que significa quatro vezes mais espaço para o KV cache e, portanto, capacidade para atender a mais tráfego. Com a SWA — desculpe, com a GQA —, são necessários apenas 32 GB reservados para cada…

16:11 grupo, para uma solicitação com contexto de 1 milhão de tokens. E, se usarmos TP, ou tensor parallelism, os 32 GB também podem ser divididos: com TP2 ou TP4, cada GPU precisa manter apenas 8 GB por solicitação. Se usarmos TP8, serão 4 GB por GPU, o que torna isso muito mais acessível. Além disso, por causa dessa atenção híbrida, o KV cache…

16:42 em si é muito eficiente e econômico. O que mais? Podemos falar dos detalhes na parte sobre serving, mas isso torna um pouco mais complicado gerenciar o tempo de vida do KV cache e também acrescenta alguma complexidade ao cache de prefixo. Hoje em dia, para coding agents ou agents em geral, as empresas têm contextos muito longos, então as solicitações que usam o cache de prefixo são bem importantes. Certo, agora vem o raciocínio. Quanto ao raciocínio, este modelo oferece suporte a quatro níveis de esforço, que correspondem a quatro níveis diferentes. Na verdade, como podem ver, mostramos isso em escala logarítmica, mas cada aumento no esforço de raciocínio aumenta o uso em algumas vezes. Um nível de raciocínio mais alto…

17:13 significa que o modelo vai usar mais tokens na etapa de raciocínio, ou seja, de pensamento. Então, se olharem para o template, verão que há canais separados. O modelo pensa, faz duas chamadas e depois volta ao usuário. Uma dica geral: se quiser usar um nível alto de esforço de raciocínio, defina um limite máximo de tokens suficientemente alto. Caso contrário, pode acontecer de o modelo…

17:44 continuar pensando bastante e ser truncado no meio; nesse caso, às vezes, vocês podem ver uma saída vazia. Pode ser isso que aconteceu. Para olhar mais de perto o formato de chat, na minha opinião, o template de chat foi feito para agents. Como podem ver, há canais separados. O canal do usuário é basicamente a entrada. O assistant pode falar consigo mesmo.

18:16 Essa parte fica sob o controle do harness, que pode exibi-la ou não ao usuário. Depois do raciocínio, o assistant, ou seja, o modelo, pode gerar uma saída de commentary para mostrar o progresso ao usuário. Em seguida, o assistant também pode fazer chamadas de ferramenta, e o harness executa a chamada e devolve o resultado ao modelo. O modelo gera a saída final para o usuário.

18:46 Isso oferece canais bem definidos e um template para uso com agents. E, sim, para mim, faz bastante sentido. No serving, também dá para ver que ele distingue entre EOT e EO, o fim da mensagem. Com EOT, a geração do modelo é interrompida. Basicamente, isso separa a geração do…

19:19 modelo. Já EO, do ponto de vista do serving, significa apenas que aquele canal terminou, mas a geração do modelo continua. Na prática, o usuário fornece um prompt, e o modelo continua gerando até fazer a primeira chamada de ferramenta e encontrar o primeiro EOT. Então, faz uma chamada de ferramenta e devolve o resultado ao modelo. Por fim, o modelo vai…

19:51 gerar mais uma vez e retornar ao usuário. Para as entradas multimodais, há um encoder separado para cada modalidade, que as mapeia para embeddings e preenche os tokens de espaço reservado na entrada de texto. Então, o que isso significa para o serving? Aqui, talvez eu…

20:21 gerar outra geração e voltar ao usuário. Para entradas multimodais, há um encoder separado para cada modalidade, que então mapeia para o embedding e preenche os tokens de espaço reservado na entrada de texto. Então, o que isso significa para o serving? Aqui, talvez eu só…

20:53 vou abordar principalmente os detalhes das técnicas. Isso não significa necessariamente que nosso uso em produção empregue a estratégia ou a técnica que mencionei nesta apresentação. Mas, para dar um exemplo, este modelo tem 816 bilhões de parâmetros. Mesmo em NVFP4, só para servir o modelo em si, você precisa de pelo menos…

21:26 …400 GB, um pouco mais de 400 GB. Isso significa que o número mínimo de GPUs para servir o modelo é pelo menos quatro B200. Para visualizar o uso de memória, a maior parte já é ocupada pelos pesos do modelo, e ainda é preciso reservar o restante para outras coisas, como o cache KV e o CUDA graph, além de bastante espaço de trabalho para os kernels. Também é preciso deixar uma margem para…

21:59 …o prefill. Então, dá para ver que ele é, na verdade, bem compacto. E, em um servidor real, se usarmos essa configuração como provedor de inference, o cache KV acaba sendo o maior gargalo. Então, quando falamos de inference, a primeira coisa que nos vem à cabeça é: como fazemos o prefill? Como tornamos a decodificação e o prefill eficientes? O prefill é mais limitado por computação, enquanto a decodificação é mais limitada pela largura de banda da memória. Mas, antes de…

22:32 …falar disso, acho que o maior problema imediato é como lidar com o cache KV e como agrupar o máximo possível de solicitações. Por isso, internamente, em comparação com a implementação inicial, fizemos alguns ajustes para compartilhar as camadas replicadas e também os…

23:03 …tensores o máximo possível. Há outros ajustes que ainda não apresentamos. Então, boa parte do trabalho de engenharia consiste em reduzir o uso de memória para liberar mais espaço para o cache KV. Depois de lidar com o cache KV, outra coisa importante é a decodificação especulativa. Como dissemos,

23:36 se não tivermos memória suficiente, estaremos sempre lutando contra o uso de memória do cache KV. Se não houver espaço suficiente no cache KV, não poderemos agrupar solicitações suficientes para levar a decodificação de um regime limitado pela largura de banda da memória para um limitado por computação. Isso também significa que, se o cache KV não for suficiente, a utilização da GPU não será…

24:08 …alta o bastante. Uma maneira de lidar com isso é usar decodificação especulativa, basicamente usando mais computação. Usamos um modelo auxiliar menor para gerar tokens candidatos e, em uma única passagem forward, o modelo-alvo verifica todos esses tokens candidatos. Assim, podemos gerar vários tokens em uma única passagem forward.

24:38 Nesse caso, basicamente trocamos mais computação por uma geração mais rápida. Então, quando falamos de decodificação especulativa, a avaliação às vezes é complicada, porque, em publicações abertas, você pode ver números de destaque bem impressionantes, como 1.000 TPS. A decodificação especulativa…

25:10 …é fácil de ajustar demais e também depende do domínio. Então, se você realmente quiser obter um número muito, muito alto, isso certamente é possível. Mas aqui também queremos ser realistas: medimos em diferentes conjuntos de dados e, em um agent de programação, conseguimos uma taxa de aceitação de pelo menos 2,7, talvez cerca de três tokens. E isso já é bem bom, na minha opinião.

25:41 Mas, claro, ainda há muito espaço para melhorar. Outro caso é a desagregação de prefill e decodificação. A comparação anterior que fiz foi basicamente com o serving agregado, em que fazemos o prefill e a decodificação no mesmo caminho. Outra otimização que podemos fazer é desagregá-los, porque…

26:12 …o prefill e a decodificação têm características bem diferentes. O prefill precisa fazer muitos cálculos em uma única passagem forward, então é limitado por computação; já a decodificação tende a ser limitada pelo cache KV ou pela memória, se o cache KV não for um problema. Separá-los também oferece muito mais…

26:43 …espaço para otimização, porque, no prefill, podemos usar uma estratégia de paralelismo diferente. Talvez possamos usar mais paralelismo de pipeline, sem precisar fazer uma comunicação muito custosa para cada rank. Para a decodificação, talvez possamos usar um rank de TP maior. Basicamente, dividimos o modelo em partes menores e, assim, temos mais margem para o cache KV.

27:14 É por isso que, quando fazemos a desagregação de prefill e decodificação, nosso objetivo é sempre obter maior throughput e mais concorrência. Isso representa um desafio maior para o nó de decodificação em relação ao cache KV. Outra coisa que podemos fazer, ao falar de como otimizar o throughput para cargas de trabalho com agents,…

27:45 …é sempre lidar com o cache KV e com como aproveitar melhor o cache de prefill. Separadamente, cada parte tem seu próprio cache de prefill no nível do dispositivo. Para as camadas densas, basta aproveitar tudo o que pudermos. Para a atenção de janela deslizante, talvez haja algo mais que possamos fazer. Na prática, só precisamos manter a janela mais recente. Não precisamos manter o cache KV inteiro.

28:16 Isso significa que, se o comprimento do contexto mudar — por exemplo, se fizermos uma pequena edição no meio —, talvez o cache de prefill não seja aproveitado. Na prática, mantemos apenas a janela mais recente, e não podemos garantir que o prefixo continue na…

28:47 …memória do dispositivo. Quando chega uma nova solicitação, é muito fácil remover o prefixo da memória. Mas, se simplesmente acrescentarmos os novos tokens depois do prompt inicial, é provável que o cache seja aproveitado. Na prática, aproveitamos o cache de prefill em produção, e os resultados dos nossos testes mostram que conseguimos atingir pelo menos 92%, e até mais. Portanto, 92% é uma estimativa bastante conservadora.

29:19 Sim. Mas, de novo, a memória do dispositivo é bem pequena. Então, na prática, provavelmente usaremos mais alguns níveis de cache KV, talvez na memória do host e no disco. Cada um tem suas próprias características. O disco é relativamente lento, então talvez não seja possível gravar todo o cache KV nele. Em vez disso, porém…

29:50 …provavelmente manteremos um checkpoint ou alguns tokens na memória do host. Também provavelmente alocaremos o cache KV globalmente, para não precisarmos sempre associar uma sessão a um único processo: ela poderá passar para outros processos graças ao cache KV global.

30:21 Sim, acho que é basicamente isso. Fiquem à vontade para testar o novo Spark open junto com este endpoint. Ótimo, muito obrigado. Podemos passar às perguntas. Com base nessas duas apresentações, tenho várias perguntas. Também há algumas perguntas no chat.

30:53 Acho que estou ouvindo retorno. Drew, talvez seja você. Vamos ver. Talvez eu comece dando um contexto sobre este modelo. Depois, quero falar sobre para que as pessoas estão usando o modelo e perguntar tanto ao Corey quanto ao Drew como o modelo foi projetado e como estamos servindo o modelo para lidar com muitas dessas…

31:25 casos de uso. Então, a série de modelos Llama que a Meta lançou, que até mesmo as pessoas estão usando agora. Uma pergunta que fiz ao Corey foi sobre a possibilidade de fazer fine-tuning. Um dos principais casos de uso que vimos na Together com a série de modelos Llama — Llama 3 8B, Llama 3 70B — era as pessoas fazerem fine-tuning do modelo para seu próprio caso de uso e, depois, implantarem modelos dedicados ou versões de fine-tuning sem servidor com LoRA. Agora

31:57 estamos vendo que as pessoas fazem fine-tuning com seus próprios dados. Agora que esse modelo está mais otimizado para casos de uso com agents sempre ativos, como agents de programação e fine-tuning com RL, vocês avaliaram a possibilidade de fazer fine-tuning desse modelo? Estão vendo pessoas fazendo fine-tuning dele e colocando-o em produção? Acho que esse pode ser um caso de uso muito poderoso, especialmente para este modelo.

32:29 >> Sim, com certeza. Acho que o fine-tuning é uma das propostas de valor realmente únicas dos modelos de pesos abertos. Ele permite alcançar um nível de desempenho e custo para um caso de uso específico que pode ser muito difícil de atingir de outra forma. Então, sim, acho que a possibilidade de qualquer pessoa pegar o modelo e fazer fine-tuning para aquilo que está fazendo especificamente é um dos casos de uso realmente importantes do modelo.

33:00 Então, você fez uma pergunta com várias partes. Pode me lembrar quais eram as partes que você queria abordar? >> Sim. Uma coisa bem interessante é saber se, antes de lançar o modelo, vocês avaliam o quanto ele pode ser ajustado com fine-tuning. Se eu quisesse fazer fine-tuning dele com minha própria base de código, conseguiria? E outro caso de uso em torno do qual muitas empresas estão criando soluções são esses agents pessoais assíncronos e sempre ativos. Sei que a Meta tem o produto Muse

33:32 , que faz bastante sucesso. Esse modelo foi motivado, em parte, pela intenção de viabilizar muitos desses casos de uso com agents pessoais também? >> Sim, o modelo certamente permite fine-tuning. Acho que essa é uma das intenções por trás da decisão da Meta de lançar o modelo. E isso é explicitamente mencionado na licença: o fine-tuning é permitido e é um dos casos de uso aceitos para o modelo.

34:03 E, em termos de como fazer fine-tuning, acho que isso realmente depende do usuário final e do caso de uso. É claro que, considerando a forma como o modelo foi treinado, provavelmente será mais fácil fazer fine-tuning para tarefas próximas desses casos de uso principais, certo? Então, se você ficar nesses casos de uso principais e quiser obter um pouco mais de desempenho para sua base de código específica ou ajudar o modelo a se familiarizar melhor com o que está acontecendo nela, isso é algo que você pode fazer. Também vale a pena ter em mente que, com uma

34:33 context window de um milhão de tokens, você também pode simplesmente colocar parte dessas informações diretamente na context window, certo? Essa pode ser uma opção interessante, em vez de fazer fine-tuning. Se houver contexto necessário, você tem uma ferramenta ou algo que possa inserir isso na context window, para que, em cada rodada específica de inference, receba as informações de que precisa dessa forma. Mas, em alguns casos, as pessoas querem fazer fine-tuning, e isso também é compatível; acho que é uma abordagem razoável. Quando se trata de fine-tuning,

35:04 uma das coisas realmente cruciais é ter um bom conjunto de evals para orientar o fine-tuning. Caso contrário, você não sabe muito bem o que está fazendo nem consegue obter uma direção realmente útil, certo? Então, se você tem um objetivo bem específico e um bom conjunto de evals que mostra como é um bom resultado e o que você precisa do modelo, além de um conjunto de dados suficientemente grande para treiná-lo nessa direção, então, sim, há uma oportunidade clara de usar o modelo para isso. Mas dá um pouco mais de trabalho, porque você precisa realizar o processo de fine-tuning, certo? Não é tão

35:34 acessível quanto simplesmente chamar a API e receber sua resposta na hora. >> [fungada] >> Sim, você mencionou os evals. Se começarmos a falar sobre evals, acho que ficaremos aqui por mais algumas horas. Conversei com muitas empresas que estão criando seus evals e identificando quais dados usar e como são bons evals. E acho que, especialmente agora que as empresas estão avaliando o modelo, a tarefa final precisa ser verificável.

36:05 Isso também reforça a importância de evals quantificáveis, com menos foco em impressões subjetivas. Há uma pergunta no chat sobre se o fine-tuning deste modelo é compatível. Na verdade, o fine-tuning deste modelo já é compatível na plataforma Together. Vou deixar um link na conversa. Você pode acessar esta página, onde verá todos os modelos compatíveis. Muse Spark Open é compatível. Você pode fazer fine-tuning com RL, SFT e DPO

36:37 deste modelo na plataforma. Certo, ótimo. Para a próxima pergunta, vou tentar fazer uma pergunta sobre o modelo, depois perguntar sobre a stack de serving e, em seguida, podemos alternar entre os assuntos e também pegar algumas perguntas do chat. A próxima pergunta talvez seja para Ju a ou Corey, porque é mais sobre o formato de chat. Ju a, você mencionou que o formato de chat foi feito especificamente para agents e que pode haver vários fluxos, nos quais o agent

37:08 pode parar uma parte, mas continuar outra. Também pode haver um token especial de fim de EOT em vez de EOM no template de chat. Você pode explicar um pouco melhor o que isso significa na prática para os desenvolvedores, em termos de casos de uso? Em quais casos de uso isso seria relevante e como isso difere dos outros modelos a que os desenvolvedores talvez estejam acostumados? >> Sim, posso talvez compartilhar alguns comentários do ponto de vista de inference, mas

37:39 deixo o Corey falar mais sobre isso depois. Para mim, cada modelo tem seu próprio template de chat, com certeza, e acho que este faz bastante sentido porque, primeiro, como os outros modelos, ele tem seu próprio canal para raciocínio. Essa parte é meio que padrão, porque todos os modelos atualmente fazem mais ou menos algum tipo de raciocínio, mas

38:11 o interessante é haver um canal separado para o raciocínio e outro canal para dar um breve retorno ao usuário antes de fazer qualquer outra coisa. Você pode querer raciocinar e, depois disso, voltar ao usuário para dizer o que vai fazer — por exemplo, fazer tool calls. Nesse caso, também haverá um canal de tool call, para descrever como o modelo vai usar uma ferramenta específica

38:42 e então transferimos o controle para o harness, que faz as chamadas de fato e retorna o resultado ao modelo. Então, sim. Acho que, primeiro, a separação entre os diferentes canais fica bem clara. Além disso, ao projetar esses canais, é interessante que cada um tenha um token especial diferente para marcar seu fim. E, de novo, do ponto de vista do

39:13 Do ponto de vista do servidor, isso facilita para o mecanismo de inference saber quando realmente deve parar. Porque, às vezes, há alguns canais, mas, para a inference, eles são apenas tokens, certo? Essencialmente, são apenas tokens. Então, EOM, FIM, você sabe, fim de mensagem, não significa necessariamente que o mecanismo precisa parar, mas ele pode continuar, continuar transmitindo os tokens e deixar o harness

39:44 decidir que parte devemos apresentar ao usuário, que parte devemos ocultar do usuário e em que parte devemos começar, de forma assíncrona, a fazer algumas chamadas de ferramentas e depois retornar ao modelo. Então, sim. Isso faz bastante sentido para mim e talvez Corey possa falar mais sobre como, do ponto de vista da modelagem, tomamos essa decisão? [fungada]

40:16 >> Sim, acho que você explicou muito bem. Acho que as três áreas são o raciocínio, o conteúdo e as chamadas de ferramentas. E, sim, acho que você explicou. Então, a menos que haja uma pergunta complementar, acho que está tudo certo. >> Sim, ótimo. Também sinto que agora um grande caso de uso são esses agents sempre ativos. E uma coisa muito interessante sobre isso é que cada harness de agent sempre ativo tem sua própria maneira de analisar a saída do

40:47 modelo. E, se você tiver muitos desses tokens especiais diferentes no template de chat, isso permite que o harness faça um trabalho mais personalizado. Por exemplo, você pode analisar os tokens de maneiras diferentes e permitir que diferentes harnesses revelem diferentes capacidades do modelo. Antes, você meio que improvisava uma solução no template de chat, que talvez não tivesse esses tokens especiais para fazer a análise. Então, sinto que esse é outro

41:19 aspecto em que estamos vendo isso: antes, os agents de programação eram o principal. Agora, esses agents pessoais que ficam rodando em segundo plano estão se tornando cada vez mais populares. E estamos vendo o ecossistema de modelos incorporar isso ao próprio modelo, o que é muito empolgante. E talvez, você mencionou que esse modelo tem modalidades de entrada bem diversas. Ele recebe texto, imagem, vídeo e áudio. Não são muitos os modelos que

41:49 fazem isso, certo? Então, Corey, você pode falar um pouco sobre por que decidiram tornar esse modelo tão multimodal? Quais eram alguns dos casos de uso que vocês pretendiam atender? E vocês viram alguns casos de uso interessantes surgir disso? Troy? >> Sim, ótima pergunta. Acho que essa é uma das coisas mais empolgantes do modelo: a capacidade de ingerir praticamente qualquer tipo de dado. E uma das coisas um pouco inéditas neste modelo, que não vimos tanto no passado, é a entrada de áudio. Acho que isso abre espaço para muitos casos de uso empresariais

42:19 muito interessantes, porque há situações em que seus dados ficam guardados em algum áudio. Por exemplo, chamadas de clientes gravadas, ou algo do tipo, e você precisa raciocinar sobre esses dados, recuperar respostas a perguntas sobre eles ou conseguir usá-los de uma forma mais acessível, sem transcrever milhares de horas de áudio ou algo assim e convertê-las manualmente em texto, porque esse é o tipo de entrada que o modelo exige. Mas poder simplesmente, sabe, enviar esse áudio

42:51 diretamente ao modelo, porque ele consegue nativamente raciocinar sobre entradas de áudio, acho que abre essencialmente um tipo totalmente novo de armazenamento de dados para uma empresa que opera de uma maneira em que parte dos dados fica guardada, essencialmente, em formato de áudio. >> Sim, concordo. Há alguns meses, antes disso, eu estava criando um app em que era possível gravar o próprio áudio e depois encontrar o modelo de text-to-speech que mais se parecia com a gravação. E isso é relevante porque, quando os clientes criam esses agents de voz, talvez queiram uma voz específica, mas têm um catálogo de vozes compatíveis com o modelo de TTS. Então, eu estava criando um app para ajudar as pessoas a escolher a voz perfeita e percebi que o único modelo open que aceitava voz como entrada era um modelo 2B ou 4B. E, quando você perguntava algo como… A ideia basicamente era fornecer um arquivo de áudio e extrair metadados

43:22 sobre como ele soa, qual é a emoção, e eu tinha esse modelo 2B ou 4B, que era o gargalo para o desempenho do app. Então, o fato de vocês terem um modelo tão grande que agora consegue raciocinar sobre entradas de áudio, e ao qual você pode perguntar coisas além de apenas transcrever… Você pode perguntar se o usuário parece estar com raiva. Pode fazer todo tipo de coisa, como classificação de emoções. Sinto que isso é um grande avanço, especialmente para muitos desses agents pessoais.

43:52 como, se você enviar algum tipo de arquivo de áudio para esse modelo, pode extrair emoções, fazer o agent realizar essa tarefa e depois responder de forma diferente com base nisso também. Isso é quase como ir além da modalidade de transcrição, STT. Vocês também abriram caminho para muitos outros casos de uso interessantes que as pessoas podem aproveitar agora. Além disso, também é possível fazer fine-tune nessa dimensão, o que é muito legal.

44:22 Ótimo. Então, Joey, você falou um pouco sobre a pilha de serving desagregada, em que se pode separar os workers de prefill dos workers de decode. Conversamos bastante sobre os diferentes casos de uso para os quais as pessoas podem querer aproveitar esse modelo. Você pode falar um pouco sobre como usar a desagregação de prefill e decode e otimizar essa configuração para um caso de uso de agent de programação

44:53 em que há uma sequência de entrada longa e uma sequência de saída curta, com uma taxa de acerto de cache muito alta, em comparação com um caso de uso de chatbot, em que a sequência é muito longa e a taxa de acerto de cache é baixa? Se você estiver usando a desagregação de prefill e decode, como pensa em otimizar esses diferentes tipos de carga de trabalho? >> Ah, essa é uma ótima pergunta. Na minha opinião, a desagregação de PD sempre tem como objetivo

45:24 melhorar o throughput, ou seja, operar na região de alto throughput. Mas, em diferentes cenários, como no caso de um agent de programação, há uma alta taxa de acerto de cache no prefill e um context window longo. Então, podemos fazer algumas otimizações específicas para esse cenário. Também há casos em que, talvez, em um chat normal, a sequência não seja tão longa, mas a saída pode ser longa. Sim, definitivamente são cenários diferentes.

45:54 O que eu costumo fazer, talvez em testes locais, no desenvolvimento geral, é descobrir a taxa de acerto de cache e tentar reproduzi-la no nó de prefill. Depois, tento maximizar o throughput do prefill e, em seguida, do decode, e tento combinar os nós de decode e prefill na proporção correta. Acho que isso

46:24 basicamente funciona na maioria das vezes, mas, em um servidor de produção, pode ser uma história bem diferente. Em produção, definitivamente precisamos de escalabilidade automática. Não é algo que ajustamos manualmente. O que realmente precisamos fazer é identificar as métricas corretas, como, para o prefill, o número de solicitações na fila e o TTFT do prefill, como métrica para a escalabilidade automática. Então, o nó de prefill e o kernel podem escalar…

46:56 basicamente, consegue funcionar na maior parte do tempo, mas, em um servidor de produção, a história pode ser bem diferente. Para um servidor de produção, definitivamente precisamos de escalabilidade automática. Não é algo que ajustamos manualmente. O que realmente precisamos fazer é descobrir as métricas corretas, como, para o prefill, o número de solicitações na fila e o TTFT do prefill como métrica para a escalabilidade automática. Então, o nó de prefill e o kernel podem escalar…

47:27 eles são independentes. Então, na prática, se o padrão de tráfego mudar com o tempo — talvez o tráfego da manhã e o da noite sejam um pouco diferentes —, você pode simplesmente mudar a configuração, porque de manhã talvez as pessoas ainda estejam dormindo e, então, a maior parte do tráfego seja para agents, certo? Durante o dia, talvez as pessoas também comecem a interagir com os agents, e isso pode mudar. Acho que o jeito certo e escalável é configurar tudo corretamente para escalar e conseguir adaptar dinamicamente a proporção entre P e D e, assim, maximizar o throughput, considerando a quantidade fixa de GPU.

47:59 É, acho que isso é um desafio enorme, certo? Você tem uma configuração implantada que é otimizada para programação e, então, as pessoas começam a enviar tráfego de chat para ela. Como você se adapta a isso? E então, talvez a resposta de verdade seja ter várias configurações otimizadas para essas diferentes cargas de trabalho, colocá-las em funcionamento e encaminhar o tráfego de acordo com isso. Uma pergunta interessante que foi mencionada, Corey, na sua apresentação — alguns usuários que temos na Lake, junto com a Factory e a Ollama, também falaram disso —, e você também mencionou na sua apresentação. Eu queria

48:31 abordar esse ponto, porque acho que ele não recebe muita atenção. Especificamente, você mencionou que este modelo é bom em tool calling, mas não só isso: ele é bom em tentar novamente as chamadas de ferramentas. Se fizer uma chamada de ferramenta errada, ele tenta de novo. Você pode falar um pouco sobre como isso funciona? Como é isso na prática? O modelo é simplesmente muito bom em corrigir os próprios erros? Ou há outros casos de uso para isso? É interessante que muitas das empresas que o estão usando mencionaram isso especificamente. Então, Corey, vou passar para você e depois o Joey também pode comentar.

49:02 Claro. Acho que acertar no tool calling é muito importante para muitos casos de uso empresariais, porque, se ele falhar uma parte substancial das vezes, pode ser muito difícil implementá-lo em workflows de produção. E, neste caso, especialmente, no passado, digamos que o tool calling nem sempre fosse tão bom quanto os usuários do Llama esperavam, certo? Então, havia espaço para melhorar. Acho que a ideia aqui foi que uma das maneiras de melhorar isso é fazer o modelo conferir o próprio trabalho e tentar novamente se não acertar.

49:32 Entendi. Então, ele faz isso com chamadas de ferramentas, mas também com recuperação. Digamos que você tenha uma base de conhecimento ou algum banco de dados do qual ele esteja recuperando informações: ele consegue analisar o contexto e, então, tentar novamente as chamadas de ferramentas se as informações corretas também não tiverem sido recuperadas.

50:03 Então, ele faz tool calling em várias etapas e também corrige os erros anteriores, certo? >> Isso mesmo. >> É, isso é muito legal. Sinto que o Llama foi criado para a era dos chatbots, e que esta coisa foi criada para a era dos agents; tool calling é o que viabiliza os agents. Então, é interessante que muitos dos clientes que experimentaram isso tenham mencionado especificamente esse ponto. A outra pergunta, talvez um desdobramento desta, Corey: você mostrou uma tabela comparando o novo Spark Open com vários outros modelos open source. Como você quer que os desenvolvedores pensem sobre o novo Spark Open? Para que você quer que eles o usem? Como quer que avaliem esse modelo para os próprios casos de uso e conduzam o processo de seleção de modelos?

50:35 É, como falamos antes, uma das melhores maneiras de avaliar o modelo para o seu próprio caso de uso é executá-lo com seus próprios e-mails e ver o que acontece, certo? Especialmente se você estiver em algum dos pontos fortes para os quais o modelo foi criado, como programação, compreensão multimodal e workflows agênticos. Se o seu caso for relacionado a essas áreas, provavelmente vale a pena avaliar o modelo e ver como ele se sai. Acho que esses são os principais pontos. E também falamos um pouco sobre a possibilidade de fazer fine-tuning do modelo.

51:07 Então, essa é outra coisa que pode tornar este modelo particularmente atraente em comparação com alguns dos outros disponíveis: se você tem um caso de uso com seu próprio conjunto de dados e quer um modelo moderno que possa fazer fine-tuning com esses dados para alcançar um resultado específico, provavelmente vale a pena conferir o modelo e ver o que o novo Spark Open pode fazer por você. >> É, ótimo. Além de termos dado suporte ao modelo desde o primeiro dia, sinto que, especificamente para este modelo, como o fine-tuning era um caso de uso importante para a família Llama, também oferecemos suporte para fine-tuning desde o primeiro dia, porque acho que isso é igualmente importante para este modelo open. Então, mais uma última pergunta para você, Joey, e depois passo para o Corey encerrar. Você mencionou que há muitas oportunidades diferentes para otimizar o serving deste modelo. Para um modelo tão grande, com cerca de 800 bilhões de parâmetros, e muito esparso, com cerca de 5% de esparsidade,

51:39 5% de esparsidade, por assim dizer, em uma passagem forward, o que você acha que traz mais benefícios em termos de otimização? Você mencionou spec decode, cache KV e PD disagg. Qual você acha que é o maior fator determinante, se tivesse que escolher entre todas as opções? >> Essa é uma boa pergunta. Se eu tivesse que escolher, acho que, como este modelo já é grande o bastante,

52:11 um grande desafio para colocá-lo em produção é encontrar a melhor configuração. Claro, podemos simplesmente usar TP e 8 GP300; isso certamente vai funcionar. Mas o problema é sempre o equilíbrio: queremos maximizar o prefill e a decodificação? Ou seja, estamos limitados pela computação ou pela largura de banda da memória? Queremos maximizar a utilização do hardware ou queremos

52:41 deixar espaço suficiente para o cache KV, para conseguirmos acomodar requisições suficientes e, por sua vez, maximizar a utilização? Por um lado, se quisermos maximizar a capacidade de prefill ou de decodificação, vamos precisar usar um tamanho de TP menor, ou até usar PP, ou seja, paralelismo de pipeline. Assim, podemos economizar um pouco; o formato do problema GEMM fica melhor, porque não encolhe tanto, e o GEMM fica grande o suficiente. Além disso, há pouca ou nenhuma sobrecarga de comunicação. Mas o problema é que, quando fazemos isso, o cache KV encolhe demais e acabamos limitados pelo cache KV, que impede o engine de aceitar mais requisições. O prefill e a decodificação ficam sempre com pouca carga. Então, é sempre uma disputa…

53:14 5% de esparsidade para um forward pass, o que você acha que traz mais benefícios de otimização? Você mencionou spec decode, mencionou cache de KV, mencionou desagregação de PD. Qual você acha que é o fator determinante mais importante, se tivesse que escolher entre todas as opções? >> Essa é uma boa pergunta. Se eu tivesse que escolher, acho que, como o modelo em si é grande o suficiente, então…

53:44 um grande desafio para colocá-lo em produção é encontrar a melhor configuração. Claro, podemos simplesmente usar TP e GP300 8GP300, e aí vai funcionar com certeza. Mas o problema é sempre fazer a troca entre maximizar o prefill e a decodificação. Então, ou o gargalo está na computação ou na largura de banda da memória, mas queremos maximizar a utilização do hardware, ou queremos…

54:16 dar folga suficiente para o cache de KV, para que possamos lidar com solicitações suficientes. Assim, podemos, por sua vez, maximizar a utilização. Por outro lado, se quisermos maximizar a capacidade de prefill ou de decodificação, precisaremos usar um tamanho de TP menor, talvez, ou até usar PP, paralelismo de pipeline. Assim, podemos economizar um pouco; o formato do problema GEMM fica melhor porque não…

54:49 diminuiu tanto, e o GEMM fica grande o suficiente. Além disso, há pouca ou nenhuma sobrecarga de comunicação. Mas o problema é que, quando fazemos isso, o cache de KV encolhe demais e, basicamente, ficamos limitados pelo cache de KV, que não permite que o engine aceite mais solicitações. O prefill e a decodificação ficam sempre com uma carga muito, muito, muito baixa. Então, sim, é sempre uma disputa…

55:20 entre, tipo, podemos ter mais cache KV ou quanto é suficiente? Então, nesse sentido, eu diria que o fator mais importante seria… Bem, é difícil escolher a coisa mais importante, mas acho que as duas principais seriam o cache KV global, para termos um cache KV externo além do cache KV do dispositivo, seja no host, no disco ou em ambos.

55:51 E então a desagregação de PD, que nos permitiu usar uma estratégia diferente: para o prefill, se o cache de prefill não for um problema, podemos usar uma estratégia de paralelismo em pequena escala; mas, para o decode, podemos usar uma escala um pouco maior e, então, aumentar o tamanho do cache KV para o host, a fim de atender a mais solicitações. É. >> É, sinto que sua resposta também é indicativa dos tempos atuais,

56:23 porque boa parte do tráfego é simplesmente tráfego de agent. Então, o cache provavelmente é a ferramenta econômica número um. >> É. >> É. >> E também há cargas de trabalho de prefill muito altas, que podem ser, por exemplo, um prefill de 800 mil tokens chegando de uma sessão que ficou parada por um tempo. Então, pode ser um prefill frio que chega; por isso, a desagregação de PD também é bastante importante. Certo, então talvez eu queira passar

56:53 a palavra para Corey. Isso é muito empolgante. É como quando você tem um filme favorito e sai uma continuação, e a Meta volta a disponibilizar modelos como open source. Este é um momento muito empolgante. Pode nos ajudar a encerrar? Conte por que a Meta está disponibilizando modelos como open source, o que você quer ver da comunidade com este novo modelo e o que está por vir para empolgar a comunidade. >> É, claro. Então, acho que eu

57:24 também estou muito empolgado com a Meta disponibilizando modelos como open source, já que trabalhei bastante com Llama no passado. [limpa a garganta] Naquela época, acho que era algo muito importante a fazer, porque é quase como… Não sei como dizer isso sem roubar o slogan do Zuck, mas o futuro é para todos, certo? Então, acho que é uma maneira muito importante de levar os grandes benefícios e resultados dessa tecnologia a mais pessoas, permitir mais inovação e mais casos de uso e dar a mais

57:55 pessoas acesso à tecnologia, em vez de mantê-la trancada atrás de um paywall de API, ao qual só uma parcela muito pequena das pessoas realmente tem acesso. >> É. >> Acho que isso vai abrir espaço para casos de uso mais interessantes e inovadores, que simplesmente não teríamos visto de outra forma. E outro motivo, acho, e aqui vou falar um pouco de algo pessoal, é que muitos dos dados usados no treinamento, sabe, não apenas dos modelos da Meta, mas de todos os modelos modernos de GAI, vêm de todos nós, certo? Então, todos nós deveríamos poder acessar os modelos, já que todos fornecemos os dados para eles. É justo. Então, acho que isso é uma parte importante de completar o ciclo: se estamos treinando com base nos dados de todo mundo, então disponibilizem o modelo e deem acesso a todos, certo? >> Amém, irmão. Certo. Então, com isso, talvez eu encerre. Se alguém tiver

58:25 os modelos modernos de IA generativa vêm de todos nós, certo? Então, todos nós deveríamos poder ter acesso aos modelos, já que todos estamos fornecendo os dados para eles. É justo. Acho que isso é uma parte importante de completar o ciclo: se estamos treinando com base nos dados de todos, então disponibilizem o modelo e deem acesso a todos, certo? >> Amém, irmão. Certo. Então, talvez eu encerre por aqui. Se alguém tiver alguma…

58:56 perguntas, fique à vontade para nos enviar. Faremos muitos outros encontros como este. Isso é incrível. A Meta está disponibilizando modelos como open source. Estamos de volta, pessoal. Vamos nessa. Certo, obrigado a todos. Até breve. Tchau.

Transcrição original

[00:01] [music] [music] [music] [music]

[00:33] >> Hey everybody, welcome. We are going to give maybe a couple of minutes here for people to start trickling in and then we can get started. Hello. Hey Dan. >> Hey, how’s it going? >> Hey. We’re just waiting for super long. Awesome. We’re just waiting for people to

[01:03] trickle in and then we can we can go around with intros and then we can get started with presentations and then we’ll have a discussion at the end as well. Right, awesome. So we’re streaming on YouTube. We’re live on X Twitter.

[01:37] All right. Okay, cool. I think I’ve got the green light. I think we should be good to go. Um So I maybe maybe what I’ll do is I’ll set the stage and then I’ll throw it over to everybody for intros and then we can we can get into it. So Uh, in this webinar maybe for the next hour we’re going to dive into M Spark open. Um, and so when I joined Together about 2 years ago, that was the week that Llama 3 had launched. And that was a different

[02:10] era. That was before the era of agents. That was a a legendary model. And now we’ve got this model that’s built for agents. So I’m super excited to kind of learn more about it, both the the model behavior side of things, and then also the serving stack and how to make it um run uh in in in prod. Uh, so yeah, I’ll start off with intros uh for myself, and then I’ll throw it over to Corey from Meta and then the Together team. Uh, I’m an engineer on the DevRel team. Um, super excited to put these webinars together. And uh if

[02:41] if the community has other uh other things that they’re interested in, other questions, feel free to do feel free to let me know. What we’ll do is we’ll collect questions throughout the webinar. So feel free to throw them into um into uh YouTube. Throw them in the chat. Uh, and then we can pick them up. Afterwards, I’ve also got some questions on my end that uh I want to dive into. So we can do that as well. So uh maybe let me stop there and throw it over to Corey for intros. >> All right, nice to meet everybody. I’m Corey Featherly from Meta. I’ve been

[03:11] working at Meta for about 8 and 1/2 years now out of the Austin office, and I’m on the GenAI partner engineering team. And looking forward to chatting with you all about uh M Spark open today. >> Awesome. Uh, Joey, maybe maybe you go next. >> Yeah, sure, sure. Hi everyone. Uh, my name is Joey Huang, and uh I’m part of the inference team at Together, where I’m mainly working on like identifying if there’s any uh like optimization uh opportunity for basically let the inference run faster

[03:42] and uh higher throughput. So yeah, today is very super excited to to learn and uh to share anything about the the new like latest new uh M Spark. Yeah. >> Awesome. Thank you. Looking forward to your uh forward to your talk. Uh, and last but not least, then >> Hey, I I’m Dan. I I lead research at Together. >> Awesome. Um okay, cool. So, like I said, if folks have questions, feel free to throw them in the chat. We’ll get to it

[04:13] after our presentations. Um but without further ado, let me throw it over to Corey, uh who will take us through Muse Spark Open and and get us started off here. So, I’ll take us off stage and I’ll bring your slides on on stage, Corey. >> All right. Okay, great. Um yeah, like I said, I’m excited to talk to everyone about Muse Spark Open today. So, what is Muse Spark Open? Uh it’s an open-weight model from the Meta Superintelligence Labs. And today, what I’ll cover in a quick intro

[04:44] are the capabilities developers can build with and how it supports coding, agentic work, and multimodal reasoning. Okay, so Muse Spark Open, what is it? It is an 816 billion mixture of experts uh for a parameter model. It’s an open-weight model from MSL, and it’s trained for a long-horizon agentic workflows such as coding and customer service agents. Uh like I mentioned, it’s an MoE model, so

[05:14] each token um activates 42 billion of the of that total parameter set. Uh the model is natively multimodal. It takes in um text, image, video, and audio inputs, and it produces text output. Um its use cases include things like complex software engineering, multi-step reasoning, and long-horizon task execution. And it’s released under the Muse model license. So, with that, um let’s talk about some of the model capabilities here. So, like

[05:45] I mentioned, enhanced coding capabilities is one of the the primary things that this model is trained for. Uh it’s also excels at multimodal understanding, um agentic workflows, and um it’s uh developer choice is number four. The weights are available for download through hugging face in both BF16 and and BFP4 versions. Uh and it’s also available via API through inference partners. Um

[06:17] Okay. So, let’s dig a little bit deeper into what some of the use cases for this model are. Uh it performs well across a variety of use cases. Um And those include things like multi-step reasoning. Sustaining coherent plans across complex extended workflows, encoding agents that write, debug, and resolve real-world software engineering tasks. Uh for end-to-end agentic tasks tasks, that includes multi-step planning,

[06:47] sequential tool invocation, failure recovery, and long-horizon task executions. Tool use also extends across multi-turn workflows, including diagnosing errors and retrying when tool calls fail. Um like I mentioned earlier, multimodal reasoning is one of the areas where this model excels, and it has some really fun use cases across things like interpreting screenshots, charts, documents, images, uh and even audio and video as well.

[07:18] Okay, so show me the evals. How did the model perform in evaluations? Um here we’re comparing Mixtral Spark Open with other leading open-weight models of similar size and architecture. The evaluations span agentic capabilities, knowledge and reasoning, coding, and multimodal performance with tools. Um a couple things to highlight, Mixtral Spark Open scores 61.8 on Job Bench and 76.4 on Terminal Bench. So, I’ll let you digest those more fully

[07:50] um on your own time. Uh and that to pull it all together here, this is the model card for Mixtral Spark Open. Um like I said, 816 billion total parameters, 42 active with the MoE architecture. Um And supports uh 1 million token context window at inference. Takes in multimodal input, text, image, video, and audio, and produces text output. Uh also, the model is a multilingual, trained on data from more than 100

[08:21] languages, and again, licensed under the Mongoose model license. So, what are some of the people that have used the model saying about it? Um from Factory, [clears throat] um we have Zimu, uh who said Miqu Spark Open consistently selected the right next tool and kept its responses compact, exactly the decisiveness production agents need. And from Ollama, we have Dong, who said, “This model performs particularly well

[08:52] on tool calling in long context, including multi-step and parallel calls with clean structured outputs.” Um So, with that, I’ll hand it over to the team to continue um the presentation. >> Awesome. Thank you so much. Um so, I we’ve got some questions here, but maybe what we’ll do is uh we’ll carry on with the conversation, and then we can have the discussion uh afterwards. Um

[09:24] so, you just went through kind of model details, uh how developers are using it it um how different companies a bunch of companies were trying the model out. Uh awesome things to say. Um this model is if you think back maybe a year, 800 billion would be kind of uh a huge model. So, if you think about serving this at trillion token scale, I I wanted you all to dive into some of the details uh on the serving stack. What are the complexities? How um how the Together team optimized the serving

[09:56] aspect of it? So, maybe what we’ll do um any comments on the presentation first of all? If there’s no comments, then we can uh we can go into the next presentation. All right, cool. So, maybe what we’ll do, Joel, I’ll add your slides here. You can you can go through the presentation Uh and then we can come back and we can get into the discussion session. >> Yeah, sure. Sounds good. Okay, yeah, let’s start. So, as I said, I I do I do inference in together. So, so in

[10:29] this presentation I will like maybe start from a perspective of serving and but my presentation will be two part. The first part will will will give a deep dive into the model architecture like and the second part will be like how do we how did that model architecture mean for serving especially for inference provider like together. Okay, yeah. So, first for Muse part, so some big number we already covered like

[11:00] model itself has 816 billion parameters, but for each token it will only activate like 42 billion per token. So, it’s roughly about 5% of the weights super sparse and for intermediate context length it can support up to 1 million tokens. And uh Yeah, and and the four modality text, image, video, audio four levels of effort levels. Um yeah, that’s And uh

[11:30] so by looking at those numbers, uh we can like from from my perspective like there’s a couple of bets we can see from this uh numbers. So, first the model is super sparse. So, each token only use eight out of out of 256 expert and then it’s later uh MoE. So, in end-to-end is each token only use the compute for like only 5% of the uh full model. Um which means like we

[12:02] we Yeah, we can we can talk a little details in a little bit, but the model is super sparse. So, it that bets on the sparsity. The second uh when we look at the attention layers, it so Uh, you know, high level they uh, the most back you Muse back use a GQ8 group cure attention. Um, but the most of their layers like a 46 out of the 62 layers actually only like take a sliding window of uh, 2K tokens. So no matter no matter how long the

[12:34] prompt is, it will only look at up to 2K tokens for those layers. And uh, so like so this kind of design also make 1 million context lens uh, affordable and like like economical to serve. And and then it’s like a it’s of course a recent model and uh, the user can specify different effort level to trade like the the the how much you will spend on the sinking and then if you if it’s a if it’s a like

[13:04] accuracy matters most you might want to set a um, extra high. And if you want like low latency use case maybe you can set low. Um, so for for the Sparse Expert part it uh, implies uh, a latent MoE uh, structure which means it will like so so the model’s hidden size itself is 8,192. And and then before entering the like uh, MoE layer MoE the core MoE it will

[13:36] be down projected to a 4K dimension and then the router will select like the like a router will like in parallel will select uh, eight out of 256 expert and then we’ll only use those expert to calculate for that particular expert. And then after doing the MoE it will like expand like uh, expand back to the 8K uh, hidden states and and and and the merge back to the like mainstream. Uh, in total it’s like a end to end only

[14:08] 5% of the weight got activated for each token. Um, so for like so for high throughput uh, scenario uh, that will be super efficient and like And the four for the like look uh SWA, you can here here’s a visual visualization of the distribution of dense layer versus SWA [clears throat] layers. Um the choice is simple like uh if we

[14:38] assume it’s like FP8 precision, which is already uh super uh like compact. And uh If all the layers are like vanilla dense uh GQA, if we want to support 1 million context length, you will need to uh have like 124 GB uh just to serve this one single like 1 million context length request, uh which is basically not that yes, not

[15:09] feasible for uh the current hardware. Uh but because of the GQA, um the GQA compared to the dense layer like especially at the 1 million context length this this this scale, um it’s uh it’s a cost of GQA is basically negligible because GQA only need to make keep the KV cache of 2K tokens. So, most majority of the KV cache can be evicted immediately after doing the preview.

[15:39] Uh so, although it is still take some like but you can roughly uh calculate that it only need to uh it immediately save like a 75% of the uh KV cache, which means four times more KV cache room for for for for for for serving more traffic. Uh so so with with GQA, uh I was sorry with SWA, it only need to uh cost like reserve 32 GB uh for each

[16:11] group for for for 1 million context length request. And if you do TP to tensor parallelism, the 32 can also be like divided by if it’s TP2 TP4, the each GPU only need to keep 8 GB for each request. Uh if we do TP8, then we’ll be 4 GB for each GPU, then it’s much uh much more affordable. Um also like because of this hybrid attention TV, so

[16:42] itself is super uh efficient and um cost efficient. Um what else uh we can talk about details uh in in the serving part, but it is make it slightly uh a little bit more complicated to manage the key make the lifetime of uh the key make cache and also add some little bit complexity uh for previous caching. Cuz nowadays for coding agent or like general agent, the

[17:13] this company has super long so the previous cache request is pretty important. Okay, then is the reasoning. So for reasoning uh the this model supports four reasoning efforts, and then it will be mapped to like four different levels. Uh you can see it’s actually we present it at the log scale, but each like when we increase the reasoning effort, it actually increase uh couple of times uh larger. And uh higher

[17:44] reasoning effort means it will the model will spend so more tokens at the reasoning uh thinking stage. So that So that So that if you look at the template, then it will be separate channels. Model will do thinking and then then make two calls and then go back to the user. Uh so a general tips is to if you want to use high uh reasoning effort, then at least you need to set the max token large enough, otherwise uh if there is a chance that the model

[18:16] keeps doing a lot of thinking and then they got truncated in the middle, then you might sometimes see empty output. Uh then it could be this case. So, to take a closer look at the chat format, so I I’m for my opinion the chat template is for a beautiful agent. You can see that there’s a different separated channels. The user channels is basically input. The assistant can talk to itself.

[18:46] Uh this part and they all harness it can show or not present to the user. And after doing the reasoning, the assistant the model can do like commentary output just to show the progress for the user. Um and immediately the the assistant can also make two calls and harness does the actual two call and get back to the two call to the model. The model uh generate the actual output to the user.

[19:19] So, this provides a very clean channels and and the template for for for agent use. And um yeah, it’s like to me makes a lot of sense. So, in in in actual for for serving, you can see that it also distinguished EOT and EO end of message. So, for EOT, uh the model generation will stop. That this basically separation of the

[19:51] model generation, but EO message from the serving perspective it is is basically just that you tell this channel has stopped, but then the model generation still keeps going on. So, in practice then what the model Sorry, the user give a prompt and the model will keep generating until the first the two call being made and it hits the first EOT. And then it will make a two call and it get back the two call result to the model. Then eventually the model we to

[20:21] make another uh generation and uh get back to the user. Uh for multimodal inputs uh is uh it has a separate encoder for different modality and then my map to the embedding and and and the fill in the placeholder tokens in the uh text input. So, uh how does that mean for serving? So, so here I I might just

[20:53] mostly cover the techniques details. It does not mean necessarily mean our production use uh the the the strategy or or the technique I mentioned in the in this presentation. But like to to give a example uh so this model itself has 800 816 billion parameters even in uh MVIP 4 is still like a at least just to serve just to have the model itself you need to at least

[21:26] uh 400 a little more than 400 GB. Um that means uh the minimum number of GPU to serve is like at least a four B200 and to visualize the memory footprint um the most of memory already been taken by the model weights and uh the remaining you still need to do other stuff like to to to book the TV cache and CUDA graph um a lot of like workspace for kernels. Uh header room for for

[21:59] preview. So, uh you can see it’s actually pretty compact. And uh so actual server if you use this uh if as an inference provider if we use this kind of config the TV cache is actually the biggest the bottleneck. So, yeah. This when we talk about the inference we immediately the first first thought will be okay, how do we do do the preview? How do we efficiently do the decoding and the preview is more compute bound decoding is more memory bandwidth bound but that before

[22:32] talking about that I think the the biggest immediate problem is how do we handle the how do we do how’s the key key we cash how do we be able to batch more requests as much as possible. And so internally compared to the initial implementation we did some uh tricks to share the the the replicated the layers and also to share the

[23:03] um the the tensors uh like as much as possible. There are also other tricks we haven’t putting onto the table. So it’s really the a lot of the engineering details to cut down the memory footprint so we have more space for the key we cash. And uh and then and then uh the after the talk about after tackling the key we cash another important thing is is a speculative decoding. As we said

[23:36] like if we don’t have enough memory we’re always fighting with the key we cash memory footprint and uh because if we don’t have enough key we cash we cannot batch enough requests to push the decoding like to from memory bandwidth bound towards compute bound. Then it also means if we don’t have enough key we cash like it always be um the the GPUs compute is uh the the utilization of GPU is not high

[24:08] enough. Uh one way to like to to cope with it it is to use a speculative decoding basically to use more compute. We use a smaller draft to provide the candidate tokens and then one forward pass the the target model check all these tokens of draft tokens in one forward pass. And then uh to like >> [clears throat] >> or and and then we can generate a multiple tokens in one forward pass.

[24:38] So, in this case we basically trade more compute to to like make generation faster like um So, So, when [snorts] we talk about speculative coding is sometimes always a hard thing to do the evaluation because it’s uh in the in the in the in the public post you might see there’s a very like uh crazy headline numbers like 1,000 TPS. Uh because speculative decoding is

[25:10] really uh is easy to overfit and then it’s also domain dependent. So, if you really want to get a super super high number, that’s that’s definitely possible. But, here we also want to be realistic and uh um we measure on the different data set and uh in the coding agent this can achieve at at least the 2.7 uh maybe roughly three acceptance lens. And which is actually already pretty good to me.

[25:41] Uh but we was but yeah, of course there is a big room to further improve. Um another case is uh PD dis- PD disaggregation. Um so, I I mentioned the the the the the prior comparison I made is basically on aggregated serving. So, we when we do uh preview and decoding in the same path. Uh another optimization we can make is to do the PD disaggregation because

[26:12] preview and decode having such a different um like feature like previous uh need to do a lot of computing in one forward pass so it’s uh preview bound sorry, it’s it’s compute bound and uh and the decoding is like likely to be uh either key we cash bound or memory bound response if key cash is not a problem. And uh and then by separate reason it’s also provides much higher

[26:43] room for optimization because we can for preview we can do a different like parallel strategy for preview. Maybe we can do more like uh pipeline parallelism. So we don’t we we don’t need to do a very expensive communication for for each rank. And uh for for decode maybe we can do uh do higher TP rank. So basically shot the model in a fine grain and then we have more headroom for key we cash.

[27:14] Uh this is why we do pre- PD disaggregation we always target for high throughput, higher concurrency and then it would be uh like it would through uh like a bigger challenge for uh the decode node on the key we cash side. And another thing we can do is is as we talk about the how to how to optimize the throughput for agent equal work workload

[27:45] is always key we cash and how do we hit more previous cash? Uh for for for for stand alone for each part it itself has a device level previous cash. Uh so for dense layer we just need to hit uh everything we can hit for the sliding window attention maybe there’s something else we can do. Um because we only in practice we only need to keep the last window. We don’t need to keep the full

[28:16] key we cash. Uh which means uh if the counter length change like if we do some little a little change in the middle to do some edit in the middle uh it it might not hit the previous cache. Uh because uh in practice we will only keep the last window window and we cannot guarantee the prefix to still keep in the the the

[28:47] the the the device memory. Um as the new request coming, it’s very easy to evict the the prefix. Uh but as long as the the the prompt is we append the new tokens after the initial prompt, then it is likely to hit. So, in practice we will hit the previous cache in our production and our testing results shows we can achieve at least a 92 and even higher So, 92 is actually a very conservative estimation.

[29:19] Um [clears throat] Yeah. And but again, the device memory is pretty small. So, in practice we will likely to do uh couple other tiers of key cache. Uh maybe hostile and a disk disk level. Each has its own uh specification like disk is is really relatively slow. So, we might not be able to flash all the key cache into the disk, but but

[29:50] uh instead like keeping a checkpoint or couple of something of tokens for the host memory, we will likely to do a global level uh allocated the key cache to Um so, we do not need [clears throat] to always attach one session to one pass and that can actually flow to other pass because of the global key cache.

[30:21] Yeah. So, yeah, that’s pretty much, I think. Uh yeah, feel free to try out the new Spark open uh together with this endpoint. Um Awesome. Thank you so much. Um we can go into uh just from these couple of presentations, I’ve got a bunch of questions. Um I there’s some questions from the from the chat as well.

[30:53] So I may [snorts] I think I’m getting feedback. Drew, that might be you. >> [clears throat] >> Um let’s see. Okay, so maybe maybe uh what I’ll do is I’ll set the stage for kind of this model, and then uh I wanted to get into both what people are using this model for, uh and then I wanted to ask both Corey and Drew a questions around like how the model was designed, how we’re serving the model to address uh a lot of those

[31:25] use cases. Um so uh like the Llama series of models that Meta launched where uh even people are people are even using them now. And so one question that I had for Corey was around uh fine-tune-ability. One of the kind of the biggest use cases that we saw on Together for the Llama series of models, Llama 3 8B, Llama 3 70B, was that people would fine-tune the model for their own use case, and then they would deploy kind of dedicated models or Lora serverless uh fine-tunes of it. Now

[31:57] we’re seeing kind of um the and they would kind of uh fine-tune it on their own data. Now that this model is more optimized for kind of always-on agent use cases, coding agents, um RL fine-tuning. Uh uh have you guys kind of looked at the fine-tune-ability of this model, and are you guys seeing uh people fine-tune this model and put it into production? Um I feel like that could be a very powerful use case, uh especially for this model.

[32:29] >> Yeah, for sure. And I you know, I think fine-tuning is a really one of the things that is uh unique value proposition for open-weight models. Uh and it allows you to hit an area of like performance and cost for a specific use case that can be really difficult to achieve otherwise. Um, so yeah, I mean I think it’s one of the really important um use cases for the model is the ability for uh anyone to be able to take that model and fine-tune it for whatever it is that they’re doing specifically.

[33:00] Um, so yeah, you asked like a multi-part question there. Let me remind me what are what are the parts that you wanted >> Yeah, I guess one one one thing that’s really interesting is uh whether um before you guys release the model, do you guys study how fine-tunable this model is for if I wanted to fine-tune it on my own uh code base, uh would I be able to do that? And then another use case that a lot of companies are building around are these always-on async personal agents. So I I know that Meta has the Muse

[33:32] product, which is quite successful. Uh was a motivation behind this model to kind of power a lot of these uh personal agent use cases as well. >> Yeah, um yeah, the the model is absolutely fine-tunable. Um, so and that’s one of the things that you know you know I think is behind the intention of Meta releasing the model. Uh and it’s explicitly, you know, called out in the license that like, you know, fine-tuning is is um allowable and one of the things that’s uh supported use case for the model.

[34:03] Um, and in terms of how it’s fine-tuned, I think that really depends on the end user uh and what their what their use case is. I think obviously, given the way the model was trained, it’s probably going to be an easier lift to fine-tune for things that are adjacent to those primary use cases, right? So if you if you stick with those primary use cases, and then you wanted to eke out a little bit of additional performance for your specific code base or help the model become more familiar with what’s going on there, um that is something that you can do. It’s also worth keeping in mind with a

[34:33] million, you know, token context window, you can also just put some of that stuff directly in the context window, right? You and you could an attractive option for you to go that route as opposed to doing the fine-tune. Like if if there’s needed context, do you have a tool or something that can inject that into the context so that in in each specific round of inference, you’re getting the information you need that way. Um but in some cases, people do want to do a fine-tune and that’s supported as well and I think it’s a reasonable approach. I think when it

[35:04] comes to fine-tuning, one of the things that’s really critical is you have to have a good set of eval stick to guide the fine-tune otherwise you you don’t you don’t really know what you’re doing or you can’t get really get a useful direction out of it, right? So, if you have a very specific goal and a good set of evals that lets you know like this is what good looks like and this is what I need from the model and then large enough data set where you can train it toward that, then yeah, there’s definitely an opportunity to use the model for that. It does come with a little bit more work in terms of like you then have to go do the fine-tuning process, right? It’s not as

[35:34] accessible as just, you know, hitting the API and and getting your response immediately. >> [snorts] >> Yeah, you you touched on the the evals and if we start talking about evals, I feel like we’ll be here for another another couple of hours. I’ve spoken to so many companies that are kind of building their evals out and and kind of identifying what data and what good evals look like. And I feel like especially now that companies are are eling the model, the end task needs to be verifiable.

[36:05] This is kind of leads to even underscoring the importance of evals that are quantifiable and less more less vibes. There’s one question in the chat around whether fine-tuning for this model is supported. Fine-tuning for this model is actually supported right now on the Together platform. I’ll drop a link for in in the in the thread here. You can go over here. This is where you’ll see all the models that are supported. So, Mews park open is supported. You can RL, SFT, DPO

[36:37] fine-tune this model on the on the platform. Okay, awesome. So, so the next question I wanted to go into maybe what I’ll try to do is I’ll ask a question about the model then I’ll ask about the serving stack and then I’ll we can ping-pong back and forth and we can also take some some questions from the from the chat here. So the next question maybe to actually this one can go to Ju a or Corey because this is more about the chat format. Ju a you mentioned that the chat format is specifically for agents and you mentioned that you can have this kind of multiple stream where the agent

[37:08] can stop one aspect of it but it can keep um you can have a end of EOT versus an EOM special token that’s in the chat template. Can you talk can you talk a little bit more about practically what this means for developers in terms of use cases and where what use cases would would this be relevant for and how is this different from all the other models that developers might be used to see? >> Uh yeah, I can maybe I can share a little bit like comments from from inference guy but

[37:39] like I will let the Corey say more like later. So to to me that different model has their own chat template for sure and for for this one I think it makes a lot of sense because the it first of course like as as other model it has its own channel to do the reasoning so it uh that that that part is like a kind of like a regular because everyone like right now every model is always more or less that do some like reasoning and then but it’s

[38:11] that the interesting part is like a separate channel for reasoning and a separate channel for get some like brief feedback to the user before doing anything more. Like you want to do reasoning after doing the reasoning and then get back to the user to say what what’s what’s I’m going to do is to make some tool calls for example for for tool calls and then there will also be a tool call channel um just to to describing how the model going to use specific tool

[38:42] um and then we hand over to the to to the harness that you do at making actually the two calls and get back to the model. So, uh So, yeah. So, I think that the separation that the different the channel is very clear for first. And then also uh when when when when designing the these channels is an interesting select there they have different special token to mark the the end for each channel. Um and then from again like a from the

[39:13] survey perspective uh it’s makes it easier to like let them let the let the inference engine to know like when to actually stop. Because sometimes there are a couple of uh channels, but for inference to they’re just tokens, right? They’re essentially just token. Um So, EEO MFEOM that you you know end of message that don’t necessarily mean the the engine need to stop, but you can just keep going keep going streaming back the token and let the harness

[39:44] decide which part should we present to the user which part should we like hide hidden from the user and then which part of should we actually asynchronously start to make some tool calls and then get back to the model. So, yeah. So, yeah, that that makes a lot of sense to me and uh maybe Corey can say more about how to how do we like from a modeling perspective uh how do we [snorts] make this decision?

[40:16] >> Um yeah, I mean I think you covered it pretty well. Um I think the three areas there are reasoning, the content, and the tool calls. And yeah, I think you covered it. So, unless there’s like a follow-up question to that, I think we’re good on that. >> Yeah, awesome. Um I also feel like now uh a big use case are these always-on agents. And so, one uh really interesting thing about that and uh every kind of always-on agent harness has its own uh way to parse output from

[40:47] the model. And so, if you a lot of these different um unique special tokens in the chat template, it allows the harness to do more customized lifting. Like, you can parse the tokens differently, you can enable different different harnesses to uncover different capabilities of the model. Whereas before you were kind of you were kind of duct taping over this in the chat template chat template might not have have those special tokens to parse around. So, I feel like that’s another

[41:19] where we’re seeing like coding agents used to be the thing. Now, these personal agents that are always running in the background are are increasingly more and more popular. And now we’re seeing kind of the the ecosystem of models incorporate this into the model itself as well, which is which is super exciting. Um And maybe what one you mentioned that this model has kind of a very diverse input modality. It takes in text, image, video, audio. Um that’s not like not a lot of models

[41:49] do this, right? So, Corey, can you talk a little bit about why you guys decided to make this model so multimodal? What were some of like the use cases that you guys were targeting? And have you seen um some cool use cases come out of this? Uh Troy? >> Yeah, um great question. I think that’s one of the things that’s really exciting about the model is that your ability to sort of like ingest pretty much any any type of data. And one of the things that is a little bit novel with this model that we haven’t seen as much of in the past is audio input. Um and I think that opens up a lot of

[42:19] really interesting enterprise applications because there are situations where your data is locked away in audio somewhere. Like, you have recorded customer calls or whatever it might be, and you need to reason over that data or retrieve you know, um uh answers to questions about that data or sort of like be able to make use of it in a more accessible way without like transcribing thousands of hours of audio or something like that and make manually turning it into a text input because that’s the input that the model requires. But, being able to just, you

[42:51] know, shove it into the model directly because the model natively is able to reason over audio input I think unlocks essentially a whole new type of data store for a business that might be operating in a way where some of their data is locked away essentially in an audio format. >> Yeah, I would agree. I I was building an app before this a couple months ago where I needed to take in like you could record your own audio and then you could find what the closest

[43:22] text-to-speech model is that sounded like the recording audio and this is kind of when when customers are building these voice agents, they might have a voice that they wanted to sound like but they’ve got a catalog of that are supported with their TTS model and so I was building an app to help people pick the perfect voice and I realized that the only open model that supported voice in was like a 2B 4B model and so when you ask it like what basically the idea was give it an audio file and then extract out metadata

[43:52] around how it sounds, what the emotion is like and I’ve got this like 2B 4B model which is the bottleneck to how well this app runs and so the fact that you guys have this like very large model that can now reason over audio input and you can ask it more things other than just transcription. You can ask it does the user sound like angry? You you can ask it do you can do all sorts of things like emotion classification. I feel like that’s a a very big unlock for especially a lot of these personal

[44:22] agents like if you get if you’re sending this model some sort of audio file, you can actually do emotion extraction, have the agent do that and then respond differently based on based on that as well which is yeah, it’s it’s almost like outside the transcription STT modality. You’ve you’ve also unlocked a lot of these other interesting use cases as well that people can do now. Not only that but you can also fine tune on that aspect of it as well which is very very cool.

[44:53] Um Awesome. So let me Joey, you talked a little bit about the serving stack disaggregated serving stack where you can separate out the pre-fill workers from the decode workers. We’ve talked a lot about the different use cases that people might want to leverage this model for. Can you talk a little bit about how you can use pre-fill decode disagg and then how you can optimize that configuration for like a coding agent use case

[45:24] where you’ve got like a large high input sequence length, small output sequence length, really high cache hit rate versus like a chatbot use case where you’ve got really high sequence length, low cache hit rate. If you’re doing like a pre-fill decode disagg, how do you think about optimizing those different types of workloads? >> Oh, that’s a super good question. So, to my opinion, like uh PD disaggregation itself is like always targeting at

[45:54] improving the throughput, like the high throughput region. Um but for different scenario, like if it’s coding agent, then it’s high cache rate high cache hit rate for pre-fill and long contest. So, it can we can do some like specific optimization for this scenario and there were also cases like maybe regular chat sequence sequence is not that long, but it the output might be long. Um Yeah, yeah, definitely different uh

[46:24] scenario. Uh what I usually do is to maybe for for local testing for the for the for the general development, what I usually do is to figure out the like the the cache hit rate and then try to mimic the cache hit rate with on the pre-fill node and then then try to maximize the throughput for the pre-fill and then and then and then the decode and then and then just try to pair the decode with the pre-fill nodes to the correct ratio. Uh, I think that’s

[46:56] basically can work uh in the most of the time, but in in production server it it could be a very different story. Like for for production server we definitely need the auto scale. So, not it’s not like something we we uh tune manually. Uh, what we really need to do is to find out the the correct metrics like for preview, uh the number of queue requests, the the preview TTFT as as a metric of auto scale. Then the preview node and the kernel can uh scale uh

[47:27] they’re independently. Um, so in practice like if the the traffic pattern change from time like maybe in the morning at the the traffic in the morning and in the in the evening are actually slightly different, you can just changing from cuz in the morning maybe people are still sleeping, so then the most of traffic is to uh agent. Right? At at at the daytime maybe people also start to interact with with with the agents and like this this could could change. Uh, I think the right way and the scalable way is to to

[47:59] correctly config everything to scalable and uh be able to adaptively uh adapt adapt adaptively change the ratio between P and D and the uh then we can maximum the throughput uh given the fixing given the different amount of GPU. >> Yeah, I think that that’s like a super challenging thing, right? You’ve got if you deploy a config that’s optimized for coding and then people start throwing chat traffic at it, how do you how do

[48:31] you adjust to that? And so, um yeah, maybe maybe the maybe the the real answer is you’ve got multiple configs that are optimized for these different workloads and then you bring them up and then you can route traffic accordingly. Um, what one kind of interesting uh question that was mentioned Corey in your presentation, um a couple of the users that we have around Lake with with factory and Ollama mentioned in as well. Uh, you you mentioned this in your presentation as well. I I wanted to

[49:02] touch on this cuz I don’t think this gets a lot of attention. Specifically, this model you mentioned that this model is good at tool calling, but not only that, it’s good at retrying tool calls. If it makes a wrong tool call, it it retries that tool call. Um, can you talk a little bit about what this looks like and how you guys, um, like how Yeah, in action, what does this look like? Is the model just really good at if it makes a mistake, fixing it? Or are there other uh, use cases for this? Um,

[49:32] it’s interesting that a lot of the companies that are using it bought brought this up specifically. So, maybe Corey, I’ll throw it over to you and then Joey can comment as well. >> Yeah, sure thing. I mean, I think getting the tool calling right is something that’s really important for um, a lot of the business use cases because if it’s missing that uh, substantial portion of the time, it can be really hard to implement it into a production workflows. Uh, and so I think in this case, uh, especially, you know, in in the past, um, let’s just say that tool calling

[50:03] isn’t always as good as uh, users of Llama might have hoped that it could have been, right? So, there was room some room for improvement there. And so, I think the the idea here was uh, one of the ways that we can make that better is by sort of like getting the model to check its own homework and retry if it doesn’t get it right. >> I see. And so, it’ll do that for tool calls, but it’ll also do that for retrieval. So, if you let’s say you’ve got an a knowledge base or you’ve got some database that it’s retrieving from, it’ll be able to look at the context and

[50:35] then retry uh, tool calls uh, based on if the right thing wasn’t uh, retrieved as well. So, it’ll do like multi-turn tool calling where it’ll fix its previous mistakes as well, right? >> Yep, exactly. >> Yeah. Um, yeah, that’s pretty awesome. I feel like uh, Llama was built for the era of chatbots and this this thing is built for the era of agents and uh, tool calling is the unlock for for agents. So, uh, it’s interesting that a lot of these customers that tried it out brought brought this up specifically. Um

[51:07] The The other question, maybe a follow-on to this, Corey, you you showed a kind of this table of comparing new Spark open to a bunch of other open source models. How do you How do you want developers to think about new Spark open? Uh What do you want them to use it for? How do you want them to kind of evaluate this model for their own use cases and and go about that model selection process? >> Yeah, I mean, you know, like we talked about before, one of the best ways to

[51:39] evaluate the model for your own use case is if you have your own email, like just run it against the model and and see what shakes out, right? Especially if you’re in some of these sweet spots that the model is being built for, things like, you know, coding, multimodal understanding, and agentic workflows. Uh if you’re adjacent to those, it’s probably worth evaluating the model and seeing and seeing um you’re at. Um Um yeah, and I think those are those are the main thing. And the other thing is we also discussed a little bit about is fine-tunability of the model as well.

[52:11] Um so, that’s that’s the other thing that I can see being particularly attractive about this model versus some of the other models that are available is if you have a use case where you really have like your your you have your own data set and you want to have a you know, a modern model that’s able to fine-tune toward that data set to get you a particular outcome, it’s probably worth taking a look at the model and seeing what new Spark open can do for you. >> Yeah. Awesome. Um Uh not only did we have the model supported on day zero, but I feel like

[52:41] for this model specifically, because for the Llama family, fine-tuning was a big use case, um we had day zero support for fine-tuning as well, cuz I feel like that’s just as important for uh for this open model. Um so, maybe one one last question for you, Joey, and then I’ll I’ll throw it over to Corey to to take this home, but you mentioned that there’s a lot of different opportunities to optimize the the serving for this model. Um for a model that’s this large, about 800 billion parameters, and it’s um very sparse, so about 5% as sparse,

[53:14] 5% sparsity uh for for like uh a forward pass, what do you think uh has the most uh benefits of optimizing? You You mentioned spec decode, you mentioned KV caching, you mentioned uh PD disagg. What do you think is the biggest determining factor if uh if you had to choose out of all of the options? >> Um that’s a good question. So, if I have to choose, I think So, because of this model itself is big enough, then

[53:44] uh a big challenging to put it into production is to finding the best like Of course, we can just do TP and we can use GP300 8GP300, then that it will definitely work, then uh but the problem is always like doing the trade-off between uh whether we want to maximize the the the the like the pre and the decoding that So, it’s either computer bound or memory bandwidth bound, but we want to maximize the hardware utilization, or we want to

[54:16] uh give enough headroom for the KV cache so we can cope like host enough uh requests, then we can then in turn the maximize the utilization because uh from the for the first uh side, if we want to maximize the prefill capability or decode capability, then we will need to do use a smaller maybe smaller TP size, or even use PP uh pipeline parallelism, then we can save some uh the the the the the the gem problem shape will be look better cuz it did not

[54:49] shrink that much, and the the gem will be large enough, and uh also there’s no or uh much less uh communication overhead, uh but the problem is once we do that, then the KV cache shrink too much, and uh we basically bottleneck at the KV cache, and the KV cache is not allowed the the engine to take more requests. The pre-fill and decode is always on light light light load. Um so it’s yeah so it’s always fighting

[55:20] between like can we have more key we cache or how much is enough? Uh so in in in in this angle then I would say the most important factor would be Well, I was it’s hard to find the best thing the most important but but I think that the top two would be uh key we global key we cache for to have a external key we cache uh in addition to the device key we cache uh either host or disk or both.

[55:51] And uh then the PD disaggregation it which allowed us to use a different strategy like for for pre-fill if the pre-fill cache is not a problem then for pre-fill we can use a small scale uh uh parallelism strategy but for decode we can use a slightly uh larger and to to to then uh take to enlarge the key we uh key key we key we cache size to host more requests. Yeah. >> Yeah, I feel like your your answer is also indicative of the times right now

[56:23] because a lot of the traffic is just um agent traffic. So caching is probably the number one economic >> Yeah. >> Yeah. >> tool uh and then also you’ve got kind of very high uh pre-fill workloads that are you might have like 800,000 uh token pre-fill that’s coming in that might be from a session that’s been sitting there so it might be like a a cold pre-fill that comes in so PD disag is is also uh fairly important. Um Okay, so maybe I’m I’m I want to throw

[56:53] it over to Corey. This is super exciting. This is like when you have a favorite movie uh and then a second part comes out and Meta open sourcing models again. This is a super exciting time. Can you maybe take us home? Tell us about um Um, why Meta is open sourcing models uh models and what you want to see from the community with this new model, and and what you’ve got coming coming down in the pipeline to get the community excited. >> Um, yeah, sure. So, I mean, I think I’m

[57:24] also really excited about Meta open-sourcing models as someone who worked with Llama [clears throat] a lot in the past during that time. I think it’s a really important thing to do um, because uh, it’s almost like um, I don’t know how to I don’t want to steal Zuck’s tagline, but like the future is for everyone, right? And so, I think it’s a really important way to take the this the great benefits and output of this technology and put it in the hands of more people and allow more innovation and more use cases and more

[57:55] people to have access to the technology as opposed to having it locked up behind like an API paywall where only a very small subset of people actually really have access to it. >> Yeah. >> I I think that is going to open up the door for some more interesting and innovative use cases that we just would not have seen otherwise. And another reason, I guess, we’re getting into a little bit of a personal note here, but like I think it’s important because a lot of the data that, you know, is training, you know, not just Meta models, but all of the

[58:25] modern GAI models is coming from all of us, right? And so, like all of us should be able to have access to the models if we’re all providing [clears throat] the data for it. It’s only fair. So, I think it’s it’s it’s an important sort of like part of completing the cycle and is is, you know, if we’re training based on everyone’s data, then take the model and put it out there and give everyone access to it, right? >> Amen to that, brother. All right. Um, so with that, maybe I’ll end it off. Um, if folks have any

[58:56] questions, feel free to feel free to send it to us. We’ll do a lot more of these. Um, this is awesome. Meta is open-sourcing models. We’re We’re back, baby. Let’s do it. All right. Thanks, everybody. See you soon. Bye.