Um modelo mais rápido é realmente mais rápido? Teste o trabalho completo — Morgan Suo, MiniMax
Autoria: AI Engineer · 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: Is a Faster Model Actually Faster? Test the Whole Job — Morgan Suo, MiniMax · Canal: AI Engineer · 17:10 · Assistir no YouTube
Tópicos: Aplicações empresariais de IA, Avaliação e benchmarks de IA, Inferência e otimização de modelos, Modelos de IA
Morgan Suo, da MiniMax, apresenta uma forma de avaliar modelos mais rápidos: medir o tempo, o custo e a qualidade do trabalho completo, não apenas a velocidade de geração. Usando uma tarefa de pesquisa financeira como exemplo, ele explica otimizações do M3.1 flash, incluindo sparse attention, quantização do KV cache, especialistas de baixa precisão e speculative decoding. A palestra também destaca que throughput, latência do primeiro token e esforço de raciocínio podem envolver trade-offs com a precisão e a utilidade do resultado. A recomendação é avaliar relatórios verificáveis em condições realistas, contabilizar tentativas e correções e registrar as configurações para reproduzir os resultados.
Pontos-chave
Seção intitulada “Pontos-chave”- A velocidade de geração, por si só, não determina se um modelo torna o trabalho mais rápido: é preciso medir o tempo até um resultado utilizável.
- A tarefa de pesquisa exige localizar fontes corretas, comparar períodos de divulgação, separar empresas e justificar conclusões com evidências verificáveis.
- Sparse attention pode reduzir o trabalho com contextos longos, mas precisa ser testada para garantir que encontre evidências importantes, como notas sobre fluxo de caixa.
- A quantização do KV cache e dos especialistas pode reduzir dados armazenados e movimentados; médias de pontuação podem ocultar erros relevantes para o usuário.
- Speculative decoding pode acelerar a geração, mas o custo de produzir, verificar e rejeitar tokens propostos também deve ser contabilizado.
- Mais throughput não garante menor espera: no teste apresentado, aumentar a concorrência elevou a latência P95 do primeiro token.
- O esforço de raciocínio precisa ser ajustado à tarefa; no exemplo de coding citado, reduzir o esforço diminuiu os tokens de saída, mas também a precisão.
- A avaliação deve incluir recuperação de fontes, tool calls, retries, correções humanas, custo, prazo e possibilidade de reproduzir os resultados.
Capítulos
Seção intitulada “Capítulos”| Início | Capítulo | Resumo |
|---|---|---|
| 00:12 | A pergunta: um modelo mais rápido acelera o trabalho? | Morgan Suo apresenta o tema e define uma tarefa de pesquisa financeira cujo resultado precisa ser verificável e útil para um analista. |
| 04:28 | Reduzir o trabalho com contextos longos | A palestra explica sparse attention e propõe testar se o modelo ainda encontra fatos importantes, como notas sobre fluxo de caixa. |
| 08:06 | KV cache, especialistas e speculative decoding | Suo discute quantização, cálculo com especialistas e geração especulativa, enfatizando que as otimizações devem ser avaliadas no resultado completo. |
| 11:47 | Throughput, latência e esforço de raciocínio | Os testes mostram que maior throughput pode vir acompanhado de maior latência P95 e que reduzir o esforço de raciocínio pode afetar a precisão. |
| 14:26 | Como avaliar e adotar o modelo | A recomendação é medir confiabilidade, custo e prazo do relatório utilizável, registrar configurações e fontes e iniciar com uma implantação gradual. |
Citações
Seção intitulada “Citações”O trabalho realmente ficou mais rápido com esse modelo mais rápido? — 01:16
Menos trabalho de attention ainda precisa encontrar as evidências importantes. — 06:33
A medida final é o tempo até um relatório que um analista realmente possa usar no próprio trabalho. — 11:15
Modelos mais rápidos realmente importam, mas o que mais importa é o que podemos fazer com eles. — 17:10
Conceitos e entidades
Seção intitulada “Conceitos e entidades”- MiniMax (empresa): Empresa representada por Morgan Suo na palestra e desenvolvedora dos modelos discutidos.
- Morgan Suo (pessoa): Palestrante da MiniMax que apresenta critérios para avaliar modelos mais rápidos.
- M3.1 flash (modelo): Modelo de linguagem da MiniMax usado como exemplo para discutir otimizações e avaliação de uma tarefa de pesquisa.
- sparse attention (conceito): Abordagem que seleciona blocos de texto para reduzir o trabalho de attention em entradas longas.
- KV cache (conceito): Armazenamento interno de keys e values associados ao texto processado pelo modelo.
- Mixture of Experts (conceito): Arquitetura que seleciona especialistas computacionais para processar cada token.
- speculative decoding (conceito): Método de geração em que um processo de rascunho propõe tokens que outro modelo verifica.
- P95 (conceito): Métrica de latência que indica o tempo dentro do qual chegam 95% das respostas consideradas no teste.
- PCB (conceito): Sigla de printed circuit board, placa que conecta componentes eletrônicos em dispositivos como servidores de IA.
Tradução completa (pt-BR)
Seção intitulada “Tradução completa (pt-BR)”00:12 Sou Morgan, da Minimax. Quantos de vocês conheciam a Minimax antes? Uau. Gostei disso. Sim. Porque entrei nesta empresa há quase três anos. Mas, quando começamos a entrar no mercado americano, quase ninguém nos conhecia. Naquela época, tínhamos o primeiro modelo de geração de vídeo. Vou mostrar algo sobre ele no fim desta palestra. Mas, primeiro, vou falar sobre nosso modelo de linguagem mais recente, que será lançado na semana que vem. Então, hoje, eu gostaria…
00:45 …de falar sobre o custo oculto de um modelo mais rápido. Quando as pessoas pensam em uma aplicação de IA ou em um produto integrado ao próprio workflow profissional, surge a pergunta: quando chega um modelo novo e alguém diz “Temos um modelo novo; você quer experimentar?”, ele pode executar uma tarefa mais rápido. Mas acho que a pergunta de vocês é: devo mudar para esse modelo? Então, vocês experimentam uma tarefa de pesquisa e…
01:16 …o relatório volta muito rápido, mas deixa de fora uma fonte muito importante. Alguém precisa encontrar essa fonte e corrigir o relatório. Acho que isso é algo que fazemos todos os dias. Então, o trabalho realmente ficou mais rápido com esse modelo mais rápido? Hoje, veremos como reduzimos a computação do modelo e, em seguida, vamos perguntar como testar o valor dessas mudanças no modelo. Deixe-me mostrar o trabalho que usaremos para responder a essa…
01:48 …pergunta. Na Minimax, criamos diferentes modelos e produtos multimodais que as pessoas usam, e uma resposta rápida em um chat e um relatório de pesquisa têm necessidades bem diferentes. A tarefa nos diz o que significa ter um bom desempenho. Hoje, vou me concentrar no nosso modelo de linguagem grande mais recente, o M3.1 Flash, e em uma tarefa de pesquisa. Esta é a pergunta do analista: com o aumento da demanda por servidores de IA, as…
02:19 …empresas que fornecem placas de circuito estão transformando esse crescimento em dinheiro? PCB significa placa de circuito impresso. Acho que vocês sabem disso. Ela conecta componentes eletrônicos dentro de dispositivos, como os servidores de IA. Nosso caso de pesquisa analisa empresas dessa cadeia de suprimentos. A análise interna descreve o trabalho com relatórios de 14 empresas, e o modelo tem várias tarefas. Ele precisa encontrar os relatórios certos. Precisa compilar os mesmos…
02:51 …períodos de divulgação de resultados e manter separadas empresas diferentes. Depois, precisa explicar o significado dos números. Pensem no analista que recebe o relatório. Ele precisa abrir a fonte por trás de uma afirmação importante e conferir um cálculo. Também precisa ver que evidências poderiam mudar a conclusão. Portanto, um relatório útil oferece ao analista algo que ele possa verificar, e esse é o nosso padrão para considerar uma tarefa de pesquisa concluída. Então, uma constatação mostra por que…
03:22 …essas verificações são importantes. Esta análise interna destacou uma distinção muito útil: o lucro pode crescer, mas o fluxo de caixa pode contar outra história. Uma empresa vende mais, então o lucro reportado aumenta, mas os clientes ainda não pagaram, ou ela comprou materiais que ainda estão em estoque. Portanto, o analista precisa saber por que o modelo deve apontar para a demonstração do fluxo de caixa…
03:54 …e as divulgações pertinentes. Um relatório conquista confiança quando suas afirmações podem ser verificadas, e a análise interna descreve aqui o resultado da pesquisa. Ainda precisamos verificar as fontes e os cálculos. Também precisamos medir o tempo e o custo nessa mesma tarefa. Mas as tarefas técnicas de benchmark são separadas. Elas nos ajudam a entender aspectos específicos das trocas envolvidas. Com essa tarefa definida, vamos ver o que muda dentro do M3.1 Flash.
04:28 Esta tabela mostra as principais mudanças dentro do M3.1 Flash. Vou relacioná-las a algumas perguntas simples. Primeiro: onde podemos reduzir o trabalho de atenção? Segundo: onde podemos armazenar e mover dados? Terceiro: como a configuração de serving afeta o tempo de espera do usuário? E, quarto, também controlamos quanto raciocínio o modelo faz. Essas escolhas…
04:58 …afetam diferentes partes do trabalho, e cada uma precisa ser avaliada em relação ao resultado que queremos. Toda otimização precisa ajudar a concluir o trabalho. Vamos começar por como o modelo processa uma entrada longa. Hoje em dia, acho que todo modelo diz: “Tenho uma context window enorme”; nós, por exemplo, dizemos que temos 1 milhão. Como esse milhão pode ajudar você a encontrar o resultado mais rápido e com precisão?
05:31 Algumas passagens, como neste relatório, importam muito mais do que outras para essa pergunta. Atenção esparsa significa que primeiro usamos uma etapa de seleção bem pequena, como a caixa azul. Ela atribui pontuações aos blocos de texto, e o cálculo principal de atenção usa os blocos selecionados. O modelo também mantém à vista o texto próximo, e essa…
06:01 …seleção pode mudar de acordo com a consulta; perguntas diferentes também podem exigir passagens diferentes do contexto. O número na parte inferior mostra quanto texto há nos exemplos publicados, e a entrada completa pode ser muito mais longa. Para nossa tarefa de pesquisa, o objetivo é reduzir esse trabalho de atenção em muitos desses documentos. Mas, dentro de um único documento, uma nota de rodapé muito curta pode mudar a conclusão inteira.
06:33 Então, para uma pergunta sobre fluxo de caixa, a nota de rodapé pode importar mais do que as páginas sobre as perspectivas do setor. Queremos que o modelo inclua essa passagem também. Reduzir o trabalho de atenção ainda exige encontrar as evidências importantes. A próxima pergunta é simples: ainda conseguimos encontrar os fatos de que precisamos? O M3.1 Flash também usa essa atenção em barras nas três primeiras camadas, o que torna essa recuperação uma verificação importante.
07:05 Essa tarefa separada coloca as informações em diferentes posições nas entradas longas. Em uma execução, o modelo processa todas as 39 solicitações, e as entradas mais longas tinham cerca de 830 mil tokens. O resultado cobre os casos deste teste. Para nossa tarefa de pesquisa, precisamos usar relatórios reais. O modelo consegue encontrar uma nota de rodapé sobre fluxo de caixa? Usa o período de divulgação correto? E consegue…
07:35 …identificar um conflito entre documentos diferentes? Então, movemos essa passagem importante para diferentes posições na entrada e fazemos a mesma pergunta novamente. Uma entrada longa é útil quando o modelo consegue encontrar um fato importante. Encontrar as evidências é uma das frentes. Em seguida, vamos olhar para os números que usamos dentro deste modelo. O modelo mantém informações internas do texto anterior; chamamos isso de cache KV. E o M3.1 Flash…
08:06 …reduz a precisão das chaves e dos valores de oito para quatro bits, mas a consulta continua em oito bits. Isso pode reduzir os dados que armazenamos e movemos. Também muda a posição dessas informações internas. Vejam a tabela. As pontuações médias são quase iguais, mas a pontuação de sinal cai 6,6 pontos percentuais. Algumas outras pontuações, porém, aumentam. Portanto, a pontuação média pode esconder um…
08:38 …erro que importa para o usuário. Esta comparação mostra duas configurações completas, mas não nos diz quais mudanças causaram cada pontuação. Para nossa tarefa de pesquisa, devemos verificar novamente o resultado. As fontes estão certas? Os cálculos estão certos? A explicação corresponde às evidências? As mesmas ideias se aplicam a outra parte do modelo: os especialistas. Nosso modelo usa a arquitetura MoE. Então…
09:11 …ele tem partes computacionais chamadas especialistas, que são os especialistas do MoE. O modelo seleciona alguns deles para cada token no M3.1 Flash. Esses especialistas selecionados usam pesos e ativações de quatro bits. O especialista compartilhado não faz parte dessa mudança. Pesos são valores armazenados no modelo, e ativações são valores que o modelo calcula. Uma precisão menor pode reduzir o movimento de dados e permitir uma computação mais…
09:41 …eficiente. Mas o cálculo completo tem várias etapas. Escalamos os números, executamos o cálculo e restauramos a escala. A posição dessas etapas é muito importante, e a tabela mostra onde ocorrem a escala e a restauração. Acertar essa ordem é parte de acertar a resposta. Portanto, a matemática rápida ainda precisa estar correta. E, quando verificamos o resultado completo, medimos a implementação completa. E, para…
10:12 Neste trabalho de pesquisa, fazemos as mesmas perguntas novamente. Investigamos por que as respostas ainda não passam nas nossas verificações. E agora analisamos os insights. Já analisamos o interior do modelo. Agora podemos ver como ele gera uma resposta para você. Um método de serving chamado speculative decoding funciona em duas etapas. Primeiro, um processo de rascunho mais rápido pode ajudar a propor uma sequência curta de tokens e
10:43 então o modelo-alvo pode verificá-la, e o sistema mantém a primeira parte que o modelo-alvo aceita, faz uma correção quando necessário e, em seguida, continua todo esse processo. Às vezes, ele mantém vários tokens propostos; outras vezes, o rascunho não funciona, e o sistema não consegue mantê-los. A oportunidade aqui é obter vários tokens com uma única verificação do modelo-alvo. Mas gerar rascunhos leva tempo, verificá-los leva tempo, e rejeitar esses tokens também leva tempo. Então, contabilize o
11:15 tempo gasto verificando o rascunho também. Essas verificações propõem tokens, mas alegações financeiras e fontes precisam das próprias verificações. Portanto, para o nosso trabalho de pesquisa, também devemos incluir a recuperação de fontes, as chamadas a ferramentas e as novas tentativas. A medida final é o tempo até a entrega de um relatório que um analista possa realmente usar no próprio trabalho. Assim, mesmo quando uma solicitação é executada bem, muitos usuários podem ter experiências diferentes.
11:47 Aqui está um teste separado de serving. Ele usa geração padrão com baixo esforço de raciocínio, mas agora aumentamos as solicitações concorrentes de 32 para 64. O total de saídas por segundo cresce cerca de 1,9 vez, mas observem o tempo de espera: o tempo de espera P95 pelo primeiro token aumenta. Ele passa de cerca de 1,5 segundo para 11,3
12:20 segundos, seis segundos. Então, para 95% dessas solicitações, o primeiro token chega dentro desse prazo, e a espera agora fica cerca de oito vezes mais longa. A mediana continua sendo um indicador que podemos atender. Mas não podemos olhar apenas para o tempo mediano. Isso muda tudo se olharmos só para esse número. Os usuários sentem a espera e, mesmo quando o throughput é de mais de 300 por segundo, ainda precisamos nos preocupar com o tempo de espera final.
12:52 Então, o primeiro token pode ser de raciocínio, e ainda precisamos medir quando o relatório utilizável chega. Definimos um prazo para esse relatório. Escolhemos uma carga que faça esse prazo ser perdido, e há mais uma configuração que muda o trabalho que pedimos ao modelo. Esta é a primeira vez que usamos esse controle de raciocínio diferente. Então, a partir daqui,
13:23 esta é a configuração máxima padrão que usamos na solicitação, e ela pode controlar quantos tokens usamos para o raciocínio do modelo. Na configuração documentada aqui, o raciocínio continua ativado, mas, se deixarmos o esforço em branco, o padrão é máximo. Portanto, uma configuração padrão pode mudar a quantidade de trabalho que solicitamos, e um teste de programação mostra essa compensação. Então, temos raciocínio alto e raciocínio máximo. O
13:54 nível alto usa menos tokens de saída do que o máximo, mas a precisão caiu de 80% para 68%. Portanto, a redução de tokens veio acompanhada de menor precisão nessas tarefas. Dê a essa tarefa o orçamento de raciocínio de que ela realmente precisa. Para o nosso trabalho de pesquisa, compare essas configurações nos mesmos relatórios e verifique se cada uma encontra as evidências e dá suporte aos cálculos. Uma primeira versão rápida do relatório, pronta para revisão,
14:26 pode precisar de orçamentos diferentes. Portanto, precisamos registrar essa configuração, ou qual controle de raciocínio devemos usar, e depois usá-lo no nosso trabalho futuro. Certo. Então, quando colocarmos em produção esse workflow de pesquisa com todas essas novas atualizações que temos para o modelo, primeiro podemos definir a pergunta sobre os relatórios-fonte e usar o mesmo
14:56 corte de informações e concordar sobre o que torna um relatório aceitável antes de executar essa comparação. Depois, podemos verificar três coisas. Primeiro: os analistas podem confiar no relatório, abrir as fontes por trás das alegações importantes, conferir os períodos dos relatórios, recalcular os números financeiros e procurar evidências que possam mudar a conclusão? Segundo: quanto custou o trabalho concluído? Quanto tempo levou? Inclua os custos de recuperação,
15:27 das chamadas a ferramentas e das novas tentativas. Se alguém precisar corrigir o relatório antes de usá-lo, contabilize também esse trabalho. Inclua todas as tentativas que falharam no custo de produzir relatórios aceitáveis. Então, teste com a quantidade de usuários que você espera e verifique se os relatórios chegam dentro do prazo prometido. Meça o custo de um relatório que você realmente possa usar. E, terceiro: podemos reproduzir esse resultado? Salve as versões do modelo
15:59 e do runtime, além das configurações de prompt e das fontes. Mantenha esses exemplos de falhas. Podemos começar com uma implementação gradual pequena e manter uma forma de voltar atrás. Antes de terminar, aqui está uma breve recapitulação da palestra de hoje. Ela foi criada com MiniMax A3, nosso modelo de vídeo de IA, e você pode conferir aqui.
16:38 Certo. Este é outro modelo em que estamos trabalhando, e ele tem pesos abertos. Então, qualquer pessoa que queira criar isso pode fazê-lo; na verdade, há apenas um problema com texto para vídeo. Certo. Vamos voltar à pergunta que abrimos hoje. Devemos mudar para um modelo mais rápido? E vamos pensar nesse trabalho concluído de que falamos nos últimos 18 minutos. Para o nosso analista, isso significa um relatório com fontes que ele possa abrir e números que possa conferir. Ele precisa chegar
17:10 quando for necessário. E, para o M3.1 Flash, as mudanças alteram a forma como gastamos computação; a tarefa completa mostra o que essas mudanças significam para o usuário. Portanto, meça o custo e o tempo necessários para concluir o trabalho. Modelos mais rápidos realmente importam, eu acho, mas o que mais importa é o que podemos fazer com eles. Obrigado, pessoal.
Transcrição original
[00:12] Uh I’m Morgan from Minimax. Uh how many of you knows Minax before? Oh wow. I like that. Yeah. Because uh I joined this M uh company for three almost three years. But when we first like step into the American market like uh almost no one knows us. But at that time we have the first video generation model. So I will show you something of that at the end of this speech. But first I will show you like about our the latest language model which will be released next week. So uh today um I would like
[00:45] to my topic is the hidden cost of a faster model. So when people thinking about like if you have a AI application your product built in in your own pro workflow. So when a new model arrives when I say oh please we have a new model do you want to try it? It can generate a task faster but your I think your question is should I switch to that model? So you try a research task and
[01:16] the report just comes back very soon and but it misses a very important source. So someone has to find that source and fix that report. I think this is the thing we did every every day. So did the job really get faster with this faster model. Today we will look at how we reduce the model computation and then we will ask how to test the value of those changes of this model. So let me show you the job that we will use to answer this
[01:48] question. So at minimax we build different multimodel models and pro products that people use and a quick chat reply and research report actually have different needs. So the task tells us what good performance means. Today I will focus on our latest uh large language model M3.1 flash and one research job. So here’s the analyst question as AI server demand is growing are the
[02:19] companies supplying the circuit boards turning this growth into cash? The PCB there means printed circuit board. I think you guys know that. and unc it connects electronic components that inside devices that such as the AI servers. So our research case looks like companies in this supply chain. The internal review describes work across 14 company reports and the model has several jobs. It must find the right reports. It must compile the same
[02:51] reporting periods and it must keep different businesses separate. Then it must explain what the numbers mean. Think about the analyst who receives the report. They need to open the source behind an important claim and they need to check a calculation. They need to see what evidence could change the conclusion. So a useful report gives the analyst something that they can check and that is our standard for a finished research job. So when funding shows why
[03:22] those checks matter. This internal review highlighted a very useful distinction. So profit can grow but cash flow tells a different story. A company sells more so is reported pro profit rises but customers have not paid yet or it has uh bought materials that are still in storage. So the anal the analyst needs to know why the model should point to the cash flow statement
[03:54] and the relevant is disclosures. So a report earns trust when it claims can be checked and the internal review here describes the research output. So we still need to verify it sources and calculations and also we also need to measure the time and cost on this same job. But the technical task a heart use separate tasks. So they help us to understand specific trade-offs. With this job clear, so let’s look at what changes inside M3.1 flash.
[04:28] This table shows the main changes inside M3.1 flash. So I will connect them to a few simple questions. First, where can we reduce the attention work? And second, where can we store and move data? And third, how does the serving setup affect the time a user waits? And fourth, we also control how much reasoning the model does. These choices
[04:58] affect different parts of the job and each knows a check against the result we want. So every optimization has to help the finished job. And let’s begin with how the model uses a long input. So nowadays I think every model says oh I have a very big context window like we said we have 1 million. So among this one million how it can help you to find the output find your result quickly faster and correct.
[05:31] So some passenger passages like in this report like miter just much more than others for this question. So sparse attention itself means like we uses a very small selection step first like the blue uh box there. So it scores the blocks of the tax and the main attention then calculation calculate the uses of the selected blocks and the model also keeps the nearby tax in view and this
[06:01] selection actually they can change with the query and different questions can also needs different passengers of the the context and the number on at the bottom show how much text is published examples lacks and the full input can be much longer. For our research job, the goal is to reduce this attention work across many of uh these documents. But just within this document, a very short footnote there may change the entire conclusion.
[06:33] So for a cash flow question, the footnote may matter more than the pages of industry outlook. So we want the model to include that passage too. less attention work still has to find the important evidence. So the next question is simple. Can we still find the facts we need M3.1 flash also uses like the this bar’s attention in its first three layers that makes this retrieval an important check.
[07:05] So this separate task places at different OP positions in long inputs. So in v run the model passes all 39 requests and the longest inputs were about uh 830k uh tokens. So the result covers the cases in this test and for our research job we need with real reports. Can the model find a cash flow footnote? Does it use the right reporting period? And can
[07:35] it spot a conflict between different documents? So move this important passage to different places in the input and then ask the same question again. A long input is useful when the model can find a key fact. So finding the evidence is one track too. Next we look at the numbers we used inside this model. So the model keeps the internal information from earlier text which we call this KV cache. And M3.1 flash
[08:06] changes its keys and values from eight bits to four bits, but the query still stays at eight bits. And this can reduce the data we store and move. It also changes the position of that internal information. Look at that table. So the average scores actually is almost the same but the sign score there it drops like 6.6 percentage. So some but some other scores rises. So the average score actually can hide a
[08:38] mistake we your user cares about. This compares that two full setups but it does not tell us which changes caused each score. So for our research job we should check the output out output again. Are the sources right? Are the calculations right? And does the explanation match the evidence? So the same ideas applies to another part of the model is experts. Uh our model is the MO ine architecture. So
[09:11] it has the computing parts that we called experts which is the uh M of E experts. So it selects some of them for each token in M3.1 flash. These selected experts use four bit ways and act activations. The shared expert is outside this change and ways of stored model uh values and activations are values the model calculates and lower precision can reduce data movement and support more
[09:41] efficient computation. But the full calculation has several steps. So we scale the numbers, we run the calculation and restore the scale. The position of these steps really matters and the table shows like where scale restore happens and getting that order right is the part of getting the answer right. So fast math still has to be corrected. And when we check the complete result, we we measure the complete imp uh implementation. And for
[10:12] this research job, we run the same questions again. We inspect why the answers still miss our checks. And now we look at insight. We have already look at inside the model. And now we can look at how it generates an answer for you. So a serving method called speculative decoding works in two stages. A faster draft process. It can help you to propose a short sequence of tokens and
[10:43] the then the targeting model can tracks it and the system keeps this first part that the target accepts and makes a correction when it’s needed and then continues this whole process. And sometimes it keeps several proposed tokens and sometimes the draft does work what it cannot keep. So the opportunity here is to get several tokens from one target check and but drafting takes time checking takes time. Rejecting this tokens also takes time. So count the
[11:15] time spent checking the draft too. These checks propose tokens and but financial claims and sources need their own checks. So for our research job we should also include the source retrieval the tool calls and retries. The final measure is the time to a report that an analyst can really use in their home own work. So even when one request runs well many users can change this diff experience.
[11:47] Here’s an separate serving test. So it’s uses the storage generation with low reasoning effort but the concurrence requests now like we rise from the 32s to 64. So the total output per second grows about 1.9 times but look at the weight time actually it the P95 weight for the first token rises. It goes from about 1.5 seconds to 11.3
[12:20] seconds uh6 seconds. So for 95% of this request the first token arrives by this time and the weight now is becomes like eight times longer. So the medium stay as uh the the time that we can satisfy it. But we we cannot only look at the median time. So it changed everything that if we only like look at that one. So the users feel the weight and even when the throughput you see like oh we
[12:52] have through like more than 300 per second but still you need to care about the final weight time. So the first token may be reasoning and we will still need to measure when the usable report arrives. So set a dial line for that report. we choose a low that miss it and there’s a one more setting that change the work we ask the model to do. So this is the first time we uh just use this different uh reasoning uh uh control. So uh from
[13:23] this part uh so this is the default max changes that we use in the request and it can controls how many tokens we use for this model thinking. So in the document setup here so thinking stays on but if we leave the effort blank the default is max. So a default can change the amount of work we request and one coding test there shows the tradeoff. So high reasoning and max reasoning. So the
[13:54] high uses fewer up output tokens than the max but the accuracy actually fell from 80% to 68%. So the fewer tokens came with lower accuracy on those task items. So give this task the thinking budget it really needs. So for our research job compare these settings on the same reports and check whether each setting finds the evidence and supports the calculations and the quick first pass on the report
[14:26] ready for review may need different budgets. So we need to record this setting or which reasoning control we need to put and then used in our later work. Okay. Then when we ship this research workflow with all these um new updates we have with this model. First we can fix this question on the source reports and use the same
[14:56] information cutoff and agree on what makes a report acceptable before running this comparison and then we can check three things. The first is can the analysts trust the report and open the resources behind the important claims and check the reporting periods recalculate the financial financial numbers and look for the evidence that could change the conclusion. And second, what did the finished job cost? How long did they take? And include retrieval
[15:27] tool costs and retries. So if a person must fix the report before use, count that work too. So include all the failed attempts in the cost of producing uh of producing this acceptable reports. So test are the number of these users you expect and check whether reports arrive within the promised time and measure the cost of report you can actually use. And the third one is can we repeat this result save this model
[15:59] and runtime versions and also save the prompt settings and sources. So keep these examples of failures and we can start with a small roll out and keep a way to switch back. So before we finish, here’s a short recap of today’s talk. It’s created with Miniax A3, our AI video model, and you can check here.
[16:38] Okay. So uh this is another model that we are working on and it’s opened way. So everyone that who wants to build this actually it’s only a one problem with the text to video. Okay. So let’s return to this uh our opening question today. Should we switch to a faster model and look at this finish job that we talking about for the last 18 minutes. So for our analyst that means a report with resources they can open and it has numbers they can check it must arrive
[17:10] when they need it and for uh this M3.1 flash changes how we spend computation and the complete task uh shows that those changes means for the user so measure what we cost to finish job and on time. So faster models uh I think like faster mo models really matter but what matter most is what we can do with them. Thank you guys.