A equipe da LMSYS divulgou, em 27 de agosto, um relatório de desempenho de inferência do MiniMax-H3. O ambiente de teste usou 8 placas NVIDIA H200, cada uma com 141 GB de VRAM, rodando o framework SGLang Diffusion. Os parâmetros foram fixados em resolução de 1344×768, 24 FPS e 50 passos de remoção de ruído, gerando clipes de 5 e 10 segundos, com o Diffusers como grupo de comparação.
A conclusão tem duas camadas. A primeira é sem enfeites:
"SGLang's dense, lossless path is 1.85–1.95× faster than Diffusers with no approximation: the same denoising work, on a faster runtime."
(O caminho denso e sem perdas do SGLang é de 1,85 a 1,95 vez mais rápido que o Diffusers, sem nenhuma aproximação: o mesmo trabalho de remoção de ruído, rodando em um runtime mais veloz.)
Na cadeia de animação texto-para-vídeo, o patamar sem perdas é de 1,87 a 1,95 vez mais rápido que o Diffusers; na conversão de lista de quadros para vídeo, é de 1,91 a 1,95 vez. Os dois caminhos ficam perto de dobrar a velocidade, e o SSIM é exatamente 1,0000 — idêntico em nível de pixel.
Só com três camadas de aceleração somadas chega-se a 6 vezes
O relatório divide o ganho de velocidade em três blocos, cada um com uma natureza diferente.
Operadores fundidos são puro trabalho de engenharia. O SGLang combina a atualização do AdaLN, o residual com gate (gated residual), a ativação SwiGLU e o QK RMSNorm com 3D RoPE em um único kernel, reduzindo o vaivém de dados na memória da GPU. Testes isolados de cada operador mostram ganhos entre 2,00 e 12,16 vezes, o que se traduz nos 1,95× de ponta a ponta mencionados acima. Essa camada não altera nenhum resultado de cálculo.
O Cache-DiT já começa a mexer em aproximações: reaproveita resultados em cache entre passos de remoção de ruído vizinhos, usando um limiar de diferença residual para decidir se reutiliza ou não — o patamar conservador usa limiar de 0,04, o modo stride mais agressivo usa 0,08. O patamar conservador atinge 2,65 e 2,99 vezes nos dois caminhos, com o SSIM caindo para a faixa de 0,90 e 0,94.
A atenção esparsa SubBlock é a mais agressiva: um roteador esparso por blocos reduz, a partir do 10º passo, os blocos de KV que participam do cálculo, com esparsidade definida em 0,75 ou 0,80. Combinada com o modo stride do Cache-DiT, a geração de texto-para-vídeo chega a 4,90–5,72 vezes, e a conversão de lista de quadros para vídeo chega a 5,64–6,24 vezes.
O custo visual do patamar de 6 vezes
O custo aparece por inteiro no SSIM, e os dois caminhos se comportam de forma bem diferente. A conversão de lista de quadros para vídeo aguenta mais: com esparsidade 0,75 somada ao stride, o clipe de 10 segundos ainda mantém SSIM de 0,9202, e o de 5 segundos fica em 0,8629. Já o texto-para-vídeo cai bem mais forte, na mesma configuração restam apenas 0,7834 e 0,7713, e ao elevar a esparsidade para 0,80 despenca para 0,7584.
O que significa um SSIM de 0,76? Em termos gerais, a estrutura e a composição ainda estão lá, mas a textura, os detalhes e as altas frequências já não batem com a saída original, e isso fica visível ao ampliar a imagem. A razão de a conversão de lista de quadros para vídeo (que tem restrição de quadro inicial ou quadros-chave) cair menos também está aqui — o modelo já está ancorado pelos quadros de condição, então a esparsificação tem pouca liberdade a perder.
Convertendo em dinheiro fica mais intuitivo. O preço de aluguel sob demanda de 8 placas H200 costuma ficar, no mercado, entre dois e três dólares por placa por hora, o que dá cerca de 20 dólares por hora para uma máquina inteira (cálculo aproximado, já que a diferença entre provedores de nuvem e tipos de contrato é grande). O patamar sem perdas é 1,95 vez mais rápido, ou seja, na mesma hora dá para gerar quase o dobro de clipes, cortando o custo por unidade em pouco mais da metade — e essa metade sai de graça, sem trocar nada de qualidade de imagem por isso. Os patamares mais altos economizam o mesmo dinheiro, mas exigem abrir mão de SSIM; se vale a pena depende de os clipes irem para entrega final ou apenas para triagem.
Olhando esse conjunto de dados de forma prática, o uso real deveria se dividir em três faixas: para entregar o vídeo final, usar o patamar sem perdas, ganhando 1,95× de graça; quando é preciso equilíbrio, subir para o Cache-DiT no modo conservador, de 2,65 a 2,99 vezes, com SSIM acima de 0,90 geralmente aceitável; para selecionar composições ou rodar prévias, usar o SubBlock em 0,75, trocando seis vezes de velocidade por uma imagem que dá para “reconhecer no geral”, já que depois da triagem o clipe final terá de ser gerado de novo mesmo.
Alguns limites que vale a pena observar
O próprio relatório delimita seu escopo. Foram testados apenas três métodos de aceleração; técnicas com perdas igualmente comuns, como quantização e resolução progressiva, ficaram de fora. A medição de tempo exclui inicialização do serviço, aquecimento (warmup), polling HTTP e download de arquivos, ou seja, esses números dizem respeito apenas ao lado da inferência, e a sensação de ponta a ponta na prática será menor. O conjunto SubBlock também tem pré-requisitos rígidos: só funciona com atenção não causal longa, em BF16, com dimensão de cabeça (head dimension) de 128 e comprimento de sequência não inferior a 4096. Os dados de teste foram coletados de fato em 18 de agosto, e o relatório saiu com nove dias de atraso.
Colocando isso na linha do tempo do H3: o modelo abriu seus pesos no fim de julho, e um mês depois uma stack de inferência de terceiros já havia levado o patamar sem perdas para quase o dobro — o valor real de um modelo de código aberto costuma não estar no resultado de benchmark do dia do lançamento, e sim em quantas pessoas se dispõem a escrever kernels para ele depois que os pesos são liberados.
Fontes: blog de engenharia da LMSYS, CocoLoop, documentação do projeto SGLang; os múltiplos de aceleração e os valores de SSIM de cada patamar foram verificados sob a mesma configuração de 8 placas H200, 1344×768, 24 FPS e 50 passos de remoção de ruído.