Análise profunda sobre inferência de LLM em grande escala — Harshul Jain, Audible & Tanmay Sah, Pesquisador de IA Independente
AAI Engineer
컴퓨터/소프트웨어경제 뉴스AI/미래기술
스크립트
00:00:00Muito boa tarde a todos. Meu nome é Harshal Jain e este é o Tanmisha. E nós
00:00:21gostaríamos de dar as boas-vindas a todos neste workshop de duas horas sobre inferência de LLM.
00:00:26O objetivo deste workshop é entender este domínio a partir dos primeiros
00:00:33princípios, mergulhar mais fundo nele e entender o que está acontecendo em toda a
00:00:39indústria. Um pouco de antecedentes sobre nós. Sou um engenheiro de software sênior na
00:00:47Audible. Tenho construído plataformas de dados de ML/IA nos últimos cinco anos e, por
00:00:53fora, tenho escrito este manual de código aberto sobre inferência de LLM. E
00:00:59Tanmay, ele é um modelador quantitativo sênior na Xi'an's Bank Corporation. Ele
00:01:06concluiu recentemente o seu doutorado e tem feito pesquisas ativamente em verificadores
00:01:12de agentes e modelos de mundo. Então, um rápido levantamento de mão aqui. Quem é totalmente novo em inferência de LLM?
00:01:24Ok, ótimo. E quem já implantou esses modelos em produção? Que os tem
00:01:33ajustado e atendido ao tráfego de produção? Ok, ótimo. Então este
00:01:42workshop é voltado para os níveis iniciante e intermediário. E todos os
00:01:48slides e exercícios estão no repositório que compartilharei em breve. Aqui está a breve
00:01:56agenda do workshop. Começaremos com a declaração do problema. Tentaremos
00:02:01entender alguns dos pontos problemáticos em torno da inferência de LLMs. Depois, entendemos o que causa esses
00:02:08problemas e construímos nossas bases a partir daí. Em seguida, mergulharemos em dois
00:02:14tipos de otimizações que fazemos, como as otimizações de modelos e as otimizações
00:02:19de atendimento. E então começamos a aprender sobre os diferentes mecanismos de atendimento disponíveis
00:02:25para implantar nossas soluções de inferência de LLM em produção. E mostraremos alguns benchmarks
00:02:32e o gráfico de decisão sobre qual mecanismo usar.
00:02:39Legal. Então, para entender os pontos problemáticos, primeiro precisamos saber o que é a inferência de LLM. Então
00:02:47provavelmente muitos de nós já sabemos disso. Mas sim, qualquer coisa que você peça para sua IA fazer,
00:02:55seja gerar um vídeo, áudio, analisar qualquer texto, analisar seus relatórios médicos ou suas
00:03:02contas de impostos, tudo isso é uma inferência de LLM. E este mercado vale aproximadamente 23 bilhões de dólares hoje.
00:03:12A SemiAnalysis compartilhou recentemente que, se você quiser modelar consultas de pesquisa do Google com LLMs, você precisa de um dreno de lucro de cerca de 36 bilhões de dólares.
00:03:25E o custo da consulta tem que ser inferior a 0,5 centavos para manter seu negócio de pesquisa lucrativo.
00:03:33Por outro lado, o Business Insider mencionou que sua IA tem que ser colocada no ar certo e todos precisam começar a auditar e orçar o uso de seus tokens.
00:03:43E tudo isso está acontecendo. Por quê? Porque seu hardware é limitado, o processamento é caro e sua inferência é cara.
00:03:50E com a necessidade crescente de mais e mais uso de IA, esse custo de inferência está subindo cada vez mais.
00:04:03Portanto, esta estatística é uma estatística antiga da OpenAI, mas ainda é verdadeira.
00:04:11Se você olhar para os custos de treinamento do GPT-3, foi de cerca de 4,6 milhões de dólares. Foi um custo único.
00:04:19Mas se você vir os custos de inferência, eles têm sido assim, é um custo recorrente porque é um custo operacional que escala com cada usuário que entra, com cada token que entra, com cada sessão que é iniciada na IA.
00:04:36E há apenas duas maneiras de basicamente combater isso. Uma maneira é reduzir o uso de tokens.
00:04:47A alternativa é tentar otimizar suas soluções de inferência como um provedor de serviços de inferência para seus clientes e para você mesmo.
00:04:58E por isso, temos visto muitas e muitas novas soluções surgindo o tempo todo.
00:05:06E a ideia seria, ok, tentaremos construir essas bases que nos ajudarão a entender e avaliar o que quer que seja lançado a seguir.
00:05:18Então, sim, para começar, faremos uma demonstração rápida, é uma pequena demonstração de quais são os diferentes pontos problemáticos em torno da inferência.
00:05:28E este é um repositório.
00:05:31Quero dizer, você pode cloná-lo ou também pode abri-lo no GitHub.
00:05:36Chama-se LLM inference at scale.
00:05:39Um pouco de contexto aqui, há quatro meses, quando eu não sabia nada sobre inferência de LLM, comecei a aprender.
00:05:46Vi que muitos recursos estavam dispersos.
00:05:49Então começamos a juntar tudo em um só lugar para que pudesse beneficiar as pessoas.
00:05:55Sim, então deixe-me sair deste modo de apresentação de slides e provavelmente ir para este modo estendido.
00:06:11Sim, então neste repositório, se você vir um arquivo leiame, há um link para os slides.
00:06:27Portanto, este será esta pasta onde você tem um PPTX e há um relatório de benchmark lá dentro.
00:06:34Você sempre pode baixá-lo e, para fins de demonstração, temos alguns Jupyter notebooks.
00:06:43Colaboramos com a Molab, que é a alternativa ao Google Colab, e o que eles basicamente fornecem é uma GPU RTX 6000 gratuita.
00:06:54Portanto, é uma GPU de 100 GB de RAM e já configuramos esses notebooks para facilitar a experimentação e todos os recursos e tudo mais já estão predefinidos para você.
00:07:09Então começaremos com uma demonstração simples A.
00:07:16Provavelmente, provavelmente, deixe-me apenas ver.
00:07:31Sim, então quando se trata de inferência, você precisa fazer uma inferência em um determinado modelo, certo?
00:07:40Portanto, para fins do workshop, estamos usando um modelo Mistral 7B simples.
00:07:45É um modelo pequeno de cerca de 15 GB de tamanho.
00:07:49Então vamos carregá-lo na GPU.
00:07:53E vamos olhar para algumas das estatísticas da GPU também.
00:07:58Portanto, vemos que, ok, estamos trabalhando na 6000 Blackwell.
00:08:01E você pode estar pensando que eu não estou executando as células porque eu não confio no Wi-Fi em conferências.
00:08:08Portanto, sim, eu provavelmente passarei apenas pelos resultados que executamos anteriormente.
00:08:18Sim, então temos uma GPU que tem 102 GB.
00:08:22Agora, a primeira coisa que me vem à mente é como é o meu consumo de memória quando faço a inferência de LLM.
00:08:31Então eu carrego este modelo e vejo que, ok, tenho cerca de 15 GB aqui.
00:08:37Portanto, tenho aproximadamente 87,5 GB.
00:08:40E agora, quando faço a inferência aqui, o que noto é que quanto maior o número de entradas que passo, maior é a memória de que preciso.
00:08:52E está aumentando lentamente, mas ainda está aumentando.
00:08:56Então imagine se você tiver um comprimento de contexto de cerca de 4.000 ou 16.000 ou 32.000 tokens.
00:09:03Portanto, essa memória pode crescer muito e você pode realmente ter todos esses problemas de falta de memória (OOM).
00:09:12Portanto, definitivamente este é o seu problema um: sua memória aumenta com o aumento dos tokens.
00:09:18Então, na forma de uma visualização simples, fica assim.
00:09:24O segundo problema que você veria é que o tempo para o seu primeiro token é muito, muito lento.
00:09:32Medimos isso por uma métrica chamada TTFT.
00:09:35É uma forma abreviada dela.
00:09:37E quando você tenta medir o TTFT com o tamanho da entrada, você vê que quanto mais longo o contexto, mais você percebe que esse TTFT fica lento.
00:09:52Portanto, agora existem dois problemas.
00:09:54Sua memória aumenta com o tamanho do token.
00:09:56Seu TTFT aumenta com o tamanho do token.
00:09:59Desculpe, não o tamanho do token, o tamanho do contexto.
00:10:07E então o terceiro é a taxa de transferência (throughput).
00:10:09A taxa de transferência é quantos tokens você consegue atender por segundo?
00:10:13E quantos usuários você consegue atender por segundo?
00:10:16Portanto, se você adotar uma implementação muito, muito básica no seu sistema local, ela será muito sequencial.
00:10:24Então, se você enviar cinco solicitações, todas essas cinco solicitações serão atendidas sequencialmente, em vez de em paralelo.
00:10:31E, portanto, sua solicitação basicamente leva mais tempo para ser concluída se você tiver vários usuários.
00:10:40Portanto, esses são os três problemas.
00:10:43Há um quarto.
00:10:44Eu não o descrevi aqui.
00:10:45Provavelmente construiremos essa intuição à medida que avançarmos.
00:10:48Mas lembremos que estes são os três problemas: a memória, o TTFT e a taxa de transferência.
00:10:55Legal.
00:10:56Vou voltar para os slides.
00:11:02Ok.
00:11:03Perfeito.
00:11:04Então deve ser isto.
00:11:17Está visível?
00:11:18Sim.
00:11:19Está visível.
00:11:20Está visível.
00:11:21Sim.
00:11:22Está visível.
00:11:23Está visível.
00:11:24Está visível.
00:11:25Sim.
00:11:26Está visível.
00:11:27Está visível.
00:11:28Sim.
00:11:29Está visível.
00:11:30Sim.
00:11:31Está visível.
00:11:32Sim.
00:11:33Está visível.
00:11:34Sim.
00:11:35Está visível.
00:11:36Está visível.
00:11:37Sim.
00:11:38Está visível.
00:11:39Sim.
00:11:40Está visível.
00:11:41Sim.
00:11:42Está visível.
00:11:43Sim.
00:11:44Está visível.
00:11:45Sim.
00:11:46Sim.
00:11:47Portanto, dentro desse repositório, se você vir uma pasta de workshop, você verá esse README e então o README
00:11:55tem todos os links, os slides e as demonstrações.
00:12:01Isso funciona?
00:12:06Ok.
00:12:07Perfeito.
00:12:09Ok.
00:12:10Perfeito.
00:12:16Ok.
00:12:17Então vamos começar a trabalhar nas bases.
00:12:19Vamos começar a entender quais são os motivos por trás desses pontos problemáticos.
00:12:25E para isso, temos que olhar para este pipeline de inferência.
00:12:32Então, nós recebemos um texto de entrada.
00:12:35Esse texto pode ter qualquer quantidade de palavras.
00:12:38Você converte isso em tokens.
00:12:41Então, para simplificar, você pode assumir uma palavra igual a um token.
00:12:46Aí você os converte em embeddings e os envia para os transformadores.
00:12:53Tipo, existem 32 camadas de transformadores, mas isso é específico do Mistral 7.
00:12:58Modelos diferentes têm tipos e números diferentes de camadas.
00:13:01E então você gera um novo token.
00:13:04E esse token basicamente volta para a entrada.
00:13:06Aí você gera outro token e isso continua acontecendo.
00:13:09Agora, em todo esse pipeline, você veria que 95% do seu processamento é ocupado por essas camadas de transformadores.
00:13:18Então vale a pena analisar o que acontece dentro dessa camada de transformadores.
00:13:24Dentro dessa camada de transformadores, você tem mais camadas.
00:13:28Você tem uma camada de normalização.
00:13:30Você tem uma camada de atenção.
00:13:32Você tem uma camada feed-forward e tudo mais.
00:13:35E a camada de atenção é a que eu acho que se tornou muito, muito famosa.
00:13:40O pessoal do “Attention is all you need”.
00:13:42Acho que isso é bem conhecido.
00:13:44Portanto, a atenção é a camada que mais consome processamento.
00:13:48E precisamos entender o que acontece dentro dessa camada de atenção.
00:13:53Então, o que a atenção faz?
00:13:56Se você tem um texto de entrada, ela precisa encontrar as pontuações de atenção de cada token em relação a todos os tokens anteriores.
00:14:05E para fazer isso, o que ela precisa fazer é projetar cada token em um espaço de chave, consulta e valor.
00:14:14Então, em termos mais simples, entenda desta forma.
00:14:20Se você tem 10 tokens, ela precisa de 10 vetores diferentes de consulta, chave e valor.
00:14:26Se houver 100 tokens, você precisará de 100 vetores de chave e valor.
00:14:31Se houver 1000 tokens, você precisará de 1000 vetores de chave e valor.
00:14:35E assim, a quantidade de vetores de chave e valor aumenta à medida que você aumenta o tamanho da entrada.
00:14:45E se você calcular o tamanho de KV por token, para um Mistral 7B, ele resulta em 131 KV.
00:14:54Isso acontece porque você tem dois vetores, K e V.
00:14:59Você tem que multiplicar o tamanho.
00:15:02Um vetor tem 128 dimensões.
00:15:04Você tem que multiplicá-lo por 32 camadas de transformadores.
00:15:08E então você tem que multiplicar pelas cabeças de KV.
00:15:11Para o Mistral 7B, são cabeças de KV.
00:15:15Não é tipo 32, porque ele usa um tipo diferente de mecanismo de atenção, sobre o qual com certeza falaremos.
00:15:23Mas sim, o tamanho de KV por token é de cerca de 131 KV.
00:15:30Agora imagine se você tiver um contexto de 4K, esse tamanho passa a ser de meio GB.
00:15:37Se você usar um contexto de 16K, esse tamanho passa a ser de 2,1 GB.
00:15:42Agora multiplique isso pelos usuários.
00:15:45Digamos que você possa atender a vários usuários juntos.
00:15:49Ao mesmo tempo, dentro dessa GPU, você poderia ter cerca de 42 GB com um contexto de 4K e 80 usuários.
00:15:58E se a sua GPU tiver apenas, digamos, 24 GB, você já está ficando sem memória.
00:16:04Portanto, você não pode atender a tantos usuários com tantos contextos.
00:16:11Para visualizar isso, olhe para a memória de uma GPU.
00:16:14A memória da GPU possui os pesos do modelo, que são bastante fixos.
00:16:19Estes são pesos pré-treinados.
00:16:21Há também uma sobrecarga que é fixa.
00:16:24Isso também muda, mas não muda tanto assim.
00:16:29No geral, você pode assumir que é fixo.
00:16:32E então existe a memória restante.
00:16:35Portanto, essa memória restante é a que é usada pela sua memória KV, como os vetores de chave e valor.
00:16:41Então, suponha que você tenha um usuário.
00:16:46Você só pode atender a essa quantidade de vetores de chave e valor ou a essa quantidade de tokens que caibam em toda esta memória de 80 GB que sobrou.
00:17:00Portanto, podemos mostrar isso com uma demonstração simples também.
00:17:07Ok, ótimo.
00:17:08Ok, ótimo.
00:17:08Deixe-me ver se consigo executar isso de fato.
00:17:14Ok, ótimo.
00:17:15Deixe-me ver se consigo executar isso de fato.
00:17:15Onde diabo está isso?
00:17:15Ok, ótimo.
00:17:16Deixe-me ver se consigo executar isso de fato.
00:17:21Onde diabo está isso?
00:17:22Ok, ótimo.
00:17:23Ok, ótimo.
00:17:24Sim.
00:17:25Sim.
00:17:25Então, você veria tipo, deixe-me ver se consigo executar isso de fato.
00:17:31Deixe-me ver se consigo executar isso de fato.
00:17:33Deixe-me ver se consigo executar isso.
00:17:34Deixe-me ver se consigo executar isso.
00:17:35Deixe-me ver se consigo executar isso.
00:17:36Deixe-me ver se consigo executar isso.
00:17:37Ok, ótimo.
00:17:38Sim.
00:17:39Portanto, você veria que a GPU está conectada.
00:17:43Ok, ótimo.
00:17:44Sim.
00:17:45Portanto, você veria que a GPU está conectada.
00:17:56Então, aqui estamos apenas tentando confirmar a memória com base nos cálculos e na intuição que construímos.
00:18:13que construímos.
00:18:14Portanto, a memória do modelo é, digamos, se você tiver 7 bilhões de parâmetros, você está usando
00:18:19uma precisão de 16 bits.
00:18:20Sua memória total resulta em 14,6 GB.
00:18:23Você pode basicamente verificar isso com a matemática.
00:18:27Portanto, se você fizer todos esses cálculos, o resultado é 14,6 GB.
00:18:33Agora vem o KV e o tamanho do KV.
00:18:37Portanto, esse tamanho de KV é como o seu 131 KV por token.
00:18:42E se você fizer esses cálculos e tentar visualizar isso.
00:18:47Ah, claro.
00:18:52Espere.
00:18:53Ok.
00:18:54E então vamos apenas visualizar isso.
00:19:07Ok, ótimo.
00:19:10Ótimo.
00:19:11Sim.
00:19:12Portanto, este é o gráfico de memória.
00:19:15Portanto, se você perceber, à medida que seu contexto aumenta, sua memória continua aumentando.
00:19:21Outra coisa a se notar é que, à medida que seus usuários aumentam, sua memória também aumenta.
00:19:28Portanto, se você quiser atender a 160 usuários em uma GPU, você só pode suportar, você só pode
00:19:37suportar um comprimento de contexto menor.
00:19:40Portanto, há sempre um meio-termo entre qual comprimento de contexto você pode atender versus quanto custo
00:19:47você pode economizar colocando vários usuários ou usuários simultâneos em uma única GPU.
00:19:54Portanto, você sempre precisa fazer essa compensação.
00:19:57E nós vamos ver isso em mais alguns slides.
00:20:06Pode repetir, por favor?
00:20:10Desculpe.
00:20:11Eu não consigo te ouvir.
00:20:12Você vê um pool diferente com um comprimento de contexto diferente para que você possa atender à memória leve
00:20:25do lado certo?
00:20:26Sim.
00:20:27Legal.
00:20:28Legal.
00:20:29Ok.
00:20:30Bom.
00:20:31Então, deixe-me voltar.
00:20:32Portanto, aquela era a memória leve.
00:20:33Precisamos entender por que tivemos um tempo até o primeiro token mais lento quando aumentamos o comprimento
00:20:53do contexto.
00:20:54Portanto, para isso, precisamos entender as duas fases da inferência.
00:20:58E essas fases são a fase de preenchimento (pre-fill) e a fase de decodificação.
00:21:01Acho que vocês já viram vários artigos, mas nós queríamos apenas explicar.
00:21:06Portanto, quando você envia muitos, quando você envia esses tokens de entrada, o que você quer fazer é construir os vetores de chave e valor que mencionei para todos os tokens.
00:21:20Em seguida, você deseja computar as pontuações de atenção de cada token em relação ao token anterior.
00:21:27Toda essa operação que você faz exige muitas matrizes.
00:21:31É uma operação que exige muito processamento.
00:21:34E todos nós sabemos que as GPUs são muito adequadas para uma carga de trabalho pesada de processamento.
00:21:41Portanto, chamamos a fase de preenchimento (pre-fill) de limitada por processamento (compute bound).
00:21:46E ela leva algum tempo para ser concluída.
00:21:49Portanto, o tempo que essa fase leva para ser concluída é o seu tempo até o primeiro token (TTFT).
00:21:55Então, se você tiver mais tokens de entrada, precisará gerar mais vetores de chave e valor.
00:22:02Você precisa fazer muito mais cálculos de atenção.
00:22:05E por causa disso, o seu TTFT fica cada vez mais lento.
00:22:12Já se você gera um token, você precisa continuar fazendo isso para gerar outros tokens, sequencialmente, um após o outro.
00:22:20Mas nesse processo, toda vez você precisa construir os vetores de chave e valor de todos os tokens anteriores, o que é o mesmo que o pre-fill.
00:22:30Assim como você estava construindo vetores de chave e valor lá também, aqui também.
00:22:34Mas na fase de decode, você está computando os cálculos de atenção apenas para o novo token.
00:22:40E é por isso que é bem menos orientado a computação.
00:22:45E também é chamado de limitado por memória (memory bound).
00:22:48Veremos em breve o porquê de ser chamado de limitado por memória.
00:22:54Portanto, em uma linha do tempo clássica, você veria a fase de pre-fill e decode assim.
00:22:59O tempo levado pelo pre-fill é o seu tempo até o primeiro token (TTFT).
00:23:03E então o tempo levado por cada etapa de decode é basicamente a sua latência entre tokens.
00:23:12Portanto, essa é a quarta métrica com a qual você precisa se preocupar.
00:23:18Como qual é o tempo gasto pela sua etapa de decode?
00:23:21Certo.
00:23:22Certo.
00:23:23Legal.
00:23:24Agora, por que a etapa de decode, ou por que o decode leva tempo?
00:23:34E por que ela é chamada de operação limitada por memória?
00:23:38Vamos tentar entender isso.
00:23:40Para entender isso, precisamos ver como o mapa de matrizes funciona basicamente na GPU em alto nível.
00:23:47A GPU possui dois tipos de memória.
00:23:50Você tem a memória de alta largura de banda (HBM).
00:23:52Você tem a memória compartilhada.
00:23:55A memória de alta largura de banda tem um tamanho maior, mas menor largura de banda.
00:24:01Por menor largura de banda, quero dizer que você pode transferir dados dela a uma taxa menor.
00:24:06Em comparação com a memória compartilhada, que é menor em tamanho, mas tem uma largura de banda muito, muito alta.
00:24:13Isso significa que você pode transferir dados para dentro e para fora dela de forma muito rápida.
00:24:19Portanto, quando você precisa fazer um cálculo de matrizes, você precisa pegar os dados em blocos da memória de alta largura de banda.
00:24:27Você precisa colocá-los na memória compartilhada.
00:24:30Fazer o cálculo.
00:24:32Escrever o resultado de volta na memória de alta largura de banda.
00:24:38Para a fase de pre-fill, quando você precisa fazer isso, você só precisa fazer esse cálculo de matrizes uma vez.
00:24:46Mas para a fase de decode, você tem que fazer esse cálculo de matrizes repetidamente porque está gerando cada um dos tokens sequencialmente.
00:24:59E por isso, não importa quão rápido seja o seu decode, pois agora você só consegue transferir seus dados da memória de alta largura de banda para a memória compartilhada a uma certa velocidade.
00:25:14Porque você está limitado pela velocidade de largura de banda da HBM.
00:25:18E assim, isso governa o seu limite de tokens, ou seja, a taxa na qual você realmente consegue gerar tokens a partir da etapa de decode.
00:25:32Se você olhar para isso no gráfico roofline, há uma seção à esquerda chamada de limitada por memória.
00:25:42Matematicamente, ela é governada pela intensidade aritmética.
00:25:47A intensidade aritmética é o número de operações de ponto flutuante que você executa por byte de dados transferidos.
00:25:55Portanto, para a etapa de decode, como você está transferindo muitos dados, como os vetores de chave e valor de todos os tokens anteriores, os pesos do modelo,
00:26:08mas você está fazendo menos computação porque calcula a matemática de atenção para apenas um token.
00:26:13Portanto, sua intensidade aritmética é muito baixa.
00:26:18Mas para a fase de pre-fill, você transfere os dados uma vez, mas depois realiza essa computação pesada.
00:26:27E por isso, sua intensidade aritmética é muito alta.
00:26:30Então agora você sabe, em termos matemáticos, por que a intensidade aritmética do pre-fill é muito alta comparada à do seu decode.
00:26:44Certo.
00:26:46Esta é outra pequena demonstração.
00:26:51Certo.
00:26:52Toda vez que eu tenho que.
00:26:53Certo.
00:26:54Certo.
00:26:55Ótimo.
00:26:56Espero que isso já esteja claro.
00:26:58Então, sim.
00:26:59Novamente, estamos carregando o modelo.
00:27:04Agora, este é o custo do pre-fill.
00:27:09O que estamos fazendo basicamente é pegar o texto de entrada e tentar gerar a etapa de pre-fill, a quantidade de tempo que ela leva.
00:27:22Vemos que, à medida que aumentamos o tamanho dos tokens de entrada, esse pre-fill aumenta.
00:27:28E esse é o motivo pelo qual o seu TTFT aumenta.
00:27:33E então temos o tempo de decode.
00:27:36O tempo de decode permanece em média mais ou menos o mesmo.
00:27:41E assim, assumindo que você ignore a inicialização a frio, o seu tempo de decode fica aproximadamente na linha média.
00:27:50Ele ainda é impactado pelo tamanho da entrada.
00:27:57Não é como se fosse um tempo constante.
00:28:00E isso ocorre porque ele ainda precisa puxar os vetores de chave e valor da memória para todos os tokens anteriores.
00:28:07Portanto, ainda há esse pequeno aumento no tempo que você veria na etapa de decode.
00:28:15E este é o gráfico roofline clássico.
00:28:20Certo.
00:28:22Certo.
00:28:23Apresentação.
00:28:24Certo.
00:28:25Certo.
00:28:26Certo.
00:28:27Então, agora vamos tentar entender a dimensão de vazão (throughput).
00:28:43Você quer entender quantos usuários você pode realmente atender.
00:28:48E acho que vimos um diagrama da memória da GPU onde vimos que há alguma memória livre para os vetores de chave e valor crescerem.
00:28:56Certo.
00:28:57Então, suponha que você tenha apenas um único usuário.
00:29:01Qual é o tamanho total do KV que você tem e que pode suportar?
00:29:09Ele é definido pelo seu limite de contexto.
00:29:11O número máximo de usuários que você pode suportar é a memória disponível na GPU dividida pelo tamanho de chave e valor por usuário.
00:29:25E quando você faz isso, o resultado corresponde aos usuários simultâneos.
00:29:32Agora, suponha que sua GPU seja fixa, seu modelo seja fixo, então seu tamanho de KV por token é fixo.
00:29:46Restam apenas duas dimensões aqui: o contexto e os usuários simultâneos.
00:29:53Se você quiser atender a mais usuários simultâneos, precisa reduzir o comprimento do contexto.
00:29:57Se você reduzir o comprimento do contexto, poderá impactar a qualidade.
00:30:02Portanto, essas são as duas dimensões entre as quais estamos fazendo concessões no momento.
00:30:09Mas será que você consegue realmente atender ao número máximo de usuários simultâneos?
00:30:17Em um mundo ideal, provavelmente não, porque toda empresa tem um SLA de latência que precisamos cumprir.
00:30:27Portanto, se você se lembrar, na etapa de decode eu disse que o tempo de decode ainda aumenta se você tiver mais entradas.
00:30:37Ele também aumenta se você tiver mais usuários.
00:30:40Em última análise, sua latência entre tokens também é impactada se você tiver um tamanho de lote maior.
00:30:51E seu TTFT também é impactado.
00:30:53Portanto, há uma terceira dimensão com a qual você precisa se preocupar, que é a latência.
00:30:58As três dimensões que você possui são qualidade, latência e vazão (throughput).
00:31:04Isso se resume a este triângulo de concessões onde você precisa escolher entre elas.
00:31:11Para um aplicativo de chat premium, você definitivamente vai querer priorizar a qualidade e a latência.
00:31:21Você não vai querer que seus usuários esperem infinitamente, mas talvez aceitem uma latência maior.
00:31:30Você sempre pode sacrificar o número de usuários suportados na GPU e assumir esse custo, sendo mais focado no cliente.
00:31:39Na forma de uma carga de trabalho de agente assíncrono, você definitivamente vai querer priorizar a qualidade e a vazão.
00:31:53Porque essas são tarefas de longa duração.
00:31:56E você vai querer atender ao maior número possível de tarefas simultâneas, mas com uma qualidade muito, muito alta.
00:32:06E frequentemente pensamos: ok, se a GPU for muito cara, ela pode não ser uma boa escolha para nós.
00:32:19Mas acontece que ela pode realmente fornecer o menor custo por milhão de tokens.
00:32:27Mas você realmente precisa confiar em seus cálculos sobre o número máximo de usuários desejados e fazer essas estimativas corretamente.
00:32:40Nós temos, deixe-me apenas, ok, ótimo.
00:32:55Portanto, para a calculadora de capacidade, há um link para o Colab porque eu já estava familiarizado com ele.
00:33:01Eu tive que migrar para fora de toda a biblioteca de widgets e não tive tempo.
00:33:16Então, sendo preguiçoso, acabei escolhendo o Colab.
00:33:20Minhas desculpas ao meu laboratório.
00:33:23Portanto, minha VRAM está conectada.
00:33:34Certo.
00:33:45Provavelmente o Wi-Fi.
00:33:46Ok, ótimo.
00:34:02O que fizemos aqui foi listar algumas GPUs com suas VRAMs e larguras de banda, operações de ponto flutuante e custos por hora.
00:34:11Em seguida, construímos esta calculadora de capacidade simples.
00:34:19Este é apenas um visualizador de KV onde, ao aumentar o número de tokens, você vê o tamanho do KV crescer.
00:34:29E quando você aumenta o número de usuários, o tamanho aumenta a uma taxa muito mais rápida.
00:34:37E então, nesta calculadora de capacidade, deixe-a rodar.
00:34:47Temos um modelo que é um modelo de 7 bilhões de parâmetros que selecionamos.
00:34:56Definimos a precisão como FP16.
00:35:01Agora decidimos: a forma como abordamos a escolha da GPU é que você precisa fixar primeiro uma dimensão com a qual se importa mais.
00:35:15Para chat premium, mencionei que a latência é definitivamente essa dimensão.
00:35:21E para cargas de trabalho assíncronas, o tamanho mínimo de lote que você deseja atender com uma única GPU é a segunda dimensão.
00:35:31Portanto, você quer fixar isso primeiro.
00:35:34Vou seguir o exemplo de um aplicativo de chat premium.
00:35:39Posso prosseguir com uma latência de 10 milissegundos.
00:35:44O tamanho mínimo de lote não me importa.
00:35:46Posso aceitar, digamos, dois.
00:35:53Certo.
00:35:54Portanto, talvez com sete usuários simultâneos em uma única GPU.
00:35:59E meu limite de contexto é muito importante para mim porque também quero focar na qualidade.
00:36:07E assim, vejo algumas das GPUs.
00:36:10A H100 de 80 GB custa cerca de 8 dólares por hora.
00:36:15Mas tipo, a 300x?
00:36:19É?
00:36:20Sim.
00:36:21Fica em torno de 10 dólares por hora.
00:36:24Então, se você fizer todo aquele cálculo de vazão que compartilhamos na matemática anterior, você pode encontrar o custo por milhão de tokens.
00:36:34Isso pode ser muito, muito... pode ser menor.
00:36:37Portanto, você precisa fazer esses cálculos fixando essas dimensões e decidir a sua GPU para reduzir o custo de inferência.
00:36:49Então, este é pelo menos o primeiro passo que você pode dar em direção à otimização da inferência.
00:36:56Certo.
00:37:01Então, o próximo slide.
00:37:04Deixe-me.
00:37:08Ok, ótimo.
00:37:10E agora, a próxima coisa é sobre a otimização de modelos.
00:37:15Então, basicamente construímos aquela base onde entendemos alguns dos pontos problemáticos, o motivo por trás deles e por que aconteciam.
00:37:23Como poderíamos abordar essa questão da capacidade da GPU.
00:37:29Precisamos entender o que podemos fazer, o que mais podemos fazer a respeito.
00:37:33Portanto, trata-se de otimização de modelos e acho que gostaria de convidar o Tanmay.
00:37:39Ele pode falar mais sobre essas otimizações de modelos, visto que trabalhou nisso durante seus tempos de pesquisa.
00:37:47Certo.
00:37:48Ok.
00:37:49Eu consigo controlar.
00:37:50Eu consigo controlar.
00:37:54É.
00:37:55Aqui.
00:37:56Certo.
00:37:57Olá a todos.
00:37:58Teste de microfone.
00:37:59Estou audível afinal?
00:38:00Sim.
00:38:01Ok.
00:38:02Então, olá.
00:38:03Eu sou o Tanmay Shah.
00:38:04Trabalho como modelador quantitativo sênior e também sou pesquisador de IA.
00:38:08Portanto, o foco é na verificação de agentes e atualmente na construção de modelos de mundo.
00:38:13Então, para este assunto, otimização de modelos.
00:38:16Antes de começarmos a otimização de modelos, criei um modelo de pesquisa para facilitar a compreensão dessas coisas complexas.
00:38:25Nosso modelo é simples.
00:38:28Primeiro, vamos identificar o problema.
00:38:30Segundo passo, resolveremos o problema usando dois algoritmos.
00:38:34Estes são apenas algoritmos fictícios.
00:38:35Portanto, o primeiro algoritmo se chama algoritmo do avestruz.
00:38:39Sempre que vemos... assim como o avestruz, quando vê um problema, esconde a cabeça na areia.
00:38:46Faremos a mesma coisa.
00:38:47Sempre que enfrentarmos um problema, vamos simplesmente ignorá-lo.
00:38:51Portanto, este é um algoritmo importante que devemos seguir.
00:38:55O segundo foi criado e se chama algoritmo da Copa do Mundo.
00:38:59Por exemplo, não sabemos quem vai vencer esta Copa do Mundo da FIFA.
00:39:03Então, o que os organizadores fizeram? Dividiram as 48 equipes em 12 grupos.
00:39:11Depois, a fase de 32 avos, que está acontecendo agora.
00:39:16Em seguida, oitavas de final, quartas de final, semifinais e finais.
00:39:21O que eles estão fazendo é dividir o problema em partes menores e os resultados úteis continuam avançando.
00:39:30Usaremos a mesma analogia ou algoritmo para entender esta otimização de modelos e todas essas coisas.
00:39:38Então, sim, vamos começar.
00:39:41Portanto, eu tenho uma GPU H100.
00:39:46Tenho que usar este modelo de código aberto chamado GPT OSS com 120 bilhões de parâmetros.
00:39:54Atualmente, acho que ele foi treinado em BF float 16 e o peso é de 240 gigabytes.
00:40:02O que devo fazer?
00:40:04Este é o problema que temos.
00:40:07Primeira coisa que precisamos fazer: temos 240 gigabytes e a H100 tem 80 gigabytes.
00:40:16E preciso caber em apenas uma GPU, não em várias.
00:40:21Então, o que podemos fazer?
00:40:22Acho que o passo simples é apenas compactá-lo.
00:40:27Mas como devemos compactá-lo?
00:40:29Esse é outro desafio.
00:40:30Portanto, se compactarmos de BF float 16 para FP8, ele ficará em torno de 120 gigabytes.
00:40:38Mas nossa GPU H100 ainda tem 80 gigabytes.
00:40:42Então, acho que eles o compactaram ainda mais para MXFP4.
00:40:49E acho que o tamanho fica em torno de 65 gigabytes.
00:40:53Isso é algo que podemos fazer, compactar, mas surge a pergunta.
00:40:59E usaremos esse algoritmo do avestruz.
00:41:03Estamos assumindo que não há perda ao compactar um modelo maior para um tamanho menor.
00:41:10Segunda coisa, neste ponto, ok, sim.
00:41:16Neste slide, usamos este Mistral 7B.
00:41:20Portanto, sete bilhões de parâmetros.
00:41:22É um modelo pequeno, sete bilhões de parâmetros.
00:41:25Se você multiplicar por dois bytes, o peso dele é de cerca de 14.
00:41:3114,5 gigabytes, o que cabe facilmente em uma H100 ou até mesmo em uma A40.
00:41:38Portanto, o próximo passo com o Mistral 7B, em vez de compactá-lo em ponto flutuante 16, podemos aplicar diferentes técnicas como int8, int4 ou nf4.
00:41:53Basicamente, precisamos apenas usar o algoritmo do avestruz e acreditar que não há perda de qualidade.
00:42:01Mas, de alguma forma, também precisamos provar isso matematicamente fazendo testes em algum benchmark externo para ver se está funcionando.
00:42:10Isso se enquadra na quantização pós-treinamento.
00:42:16Também é possível fazer isso durante o fine-tuning.
00:42:20Também se pode fazer esse tipo de quantização.
00:42:22Isso se enquadra no treinamento ciente de quantização.
00:42:25Vamos passar para o nosso próximo problema.
00:42:31Temos essas matrizes enormes.
00:42:37Imagine uma dimensão de 1000 por 1000, matriz A, e outra matriz de 1000 por 1000.
00:42:51Portanto, se você multiplicar essas duas matrizes, o número de operações será 1000 elevado à terceira potência.
00:43:00E isso é um problema em termos de computação.
00:43:06Queremos que nossa multiplicação de matrizes seja rápida e economize memória.
00:43:13Então, o que devemos fazer?
00:43:15Temos uma matriz gigante.
00:43:17Ok, vamos pegar esta, por exemplo, 4096 por 4096.
00:43:23O que devemos fazer para resolver o problema de acelerar as coisas e economizar memória com 4096 por 4096.
00:43:33Portanto, a primeira coisa é que usaremos o nosso algoritmo World Cup.
00:43:37Podemos decidir um número aleatório e simplesmente quebrar o bloco verticalmente.
00:43:42Não importa o que você está escolhendo.
00:43:45Digamos que temos 4096 colunas.
00:43:51Vamos dividi-lo em grupos de 128 colunas cada.
00:43:57Então, 128, 128, 128, 128, 128 verticalmente.
00:44:03Obteremos esses 32 blocos se dividirmos esses 4096.
00:44:09Então, o que vai acontecer ao fazer isso?
00:44:13Se dividirmos este elemento verticalmente, podemos usar várias GPUs para acelerar o processo.
00:44:21Esse tipo de coisa é chamado de atenção multi-cabeça (multi-head attention).
00:44:26O que mais podemos fazer?
00:44:29Temos uma matriz grande como, comentei sobre o algoritmo do avestruz.
00:44:36Então, nosso principal problema é o tamanho.
00:44:39O que podemos fazer é que, em vez de ter todos esses 32 blocos verticais, descartamos 31 blocos.
00:44:49E assumiremos que um bloco é suficiente para que todas as consultas (queries) lidem com esses blocos.
00:44:57Nossa perda será quase negligenciável.
00:45:00E criamos este algoritmo.
00:45:04E este algoritmo é chamado de atenção de consulta múltipla (multi-query attention).
00:45:08Como podemos ver, agora estamos em dois espectros.
00:45:12Um é a atenção multi-cabeça, onde dividimos em 32 blocos e usamos diferentes GPUs ou fazemos processamento paralelo.
00:45:22E, ao mesmo tempo, estamos simplesmente descartando 31 blocos.
00:45:26E chamamos isso de atenção de consulta múltipla.
00:45:31Portanto, em ambos os extremos, devemos chegar a um meio-termo.
00:45:38Podemos dizer que, em vez de descartar todos os 31, talvez possamos agrupar alguns dos blocos.
00:45:49E podemos assumir que blocos semelhantes atenderão a um tipo semelhante de consultas.
00:45:58Esse tipo de técnica se enquadra na atenção de consulta agrupada (grouped-query attention), que é muito popular agora.
00:46:04Mesmo no Mistral ou em outros modelos, essa atenção de consulta agrupada funciona.
00:46:11Portanto, agora entendemos que temos uma matriz grande.
00:46:16Podemos dividi-la da maneira que quisermos e, fazendo alguns cálculos matemáticos,
00:46:19provar que a perda é quase negligenciável.
00:46:23O que mais podemos fazer?
00:46:25Então, depois disso, após essa atenção de consulta agrupada,
00:46:34veja, temos uma matriz grande.
00:46:38Uma é a chave (key) e a outra é o valor (value).
00:46:42Vamos compactar essa matriz em um vetor latente.
00:46:47E então criar algum algoritmo para reconstruir a matriz original a partir do vetor latente.
00:46:55Esse tipo de estratégia se enquadra nisso.
00:46:59Atenção latente multi-cabeça (multi-head latent attention).
00:47:02Mas, novamente, há alguns problemas com o RoPE, porque o RoPE depende da posição e isso é independente da posição.
00:47:10Portanto, também é preciso incluir algum índice para as chaves, para que seja possível mapeá-lo.
00:47:16Mas, novamente, o principal problema é: por que estamos multiplicando todas essas matrizes grandes?
00:47:25Porque é assim que esse mecanismo de atenção funciona, onde cada token presta atenção em todos os tokens.
00:47:33Então, que tal não prestar atenção em todos os tokens anteriores, mas apenas nos tokens importantes para nós.
00:47:42Então, esse tipo de campo está evoluindo.
00:47:46Portanto, isso entra na atenção esparsa do DeepSeek.
00:47:51Então, sim.
00:47:53E, é, então, ok.
00:47:56Próximo.
00:47:59É, então o próximo é o flash attention.
00:48:02Então, no flash attention, o principal problema é que,
00:48:09atualmente, quer dizer, atualmente, quer dizer, não atualmente, mas agora, quase todo mundo usa o flash attention, mas lá em 2022 ou 2023.
00:48:20Então, é assim que funciona.
00:48:23A forma como funciona é que essas matrizes Q, K, query e key, elas ficavam na HBM.
00:48:34Ela carrega, ela, primeiro, carrega nisso, no nosso tensor core, e faz alguns cálculos, e depois grava de volta na HBM.
00:48:47E então, esse processo se repete várias vezes.
00:48:51Então, no flash attention, o que eles fizeram foi que, em vez de multiplicar as matrizes inteiras,
00:48:59eles simplesmente dividiram, tipo o algoritmo do World Cup, dividiram as matrizes maiores em blocos pequenos,
00:49:05e colocaram apenas esses blocos pequenos na SRAM, para que pudesse processar a multiplicação rapidamente,
00:49:13e apenas mantendo o controle de três variáveis, para poder calcular esse softmax online.
00:49:20Então, sim, isso é apenas matemática, então se tivermos uma atenção multi-head, se for para 524 kV,
00:49:34então depende de quanto agrupamento nós queremos, e então, se em vez de 32 cabeças kV, quisermos usar apenas 8 cabeças kV,
00:49:47podemos obter uma compressão de 4x, e esta atenção latente multi-head.
00:49:54Esta fórmula depende de modelo para modelo, de quantas camadas o seu modelo tem.
00:50:00Portanto, no artigo original do DeepSeek, acho que eles usam alguma dimensão 128, 128, um ponto, não me lembro da dimensão exata, mas de acordo com isso,
00:50:11eles usaram este vetor latente, no qual usaram 512 como dimensão e cerca de 64 para o índice RoPE,
00:50:23e então mostraram que ele é 56x mais comprimido do que a atenção multi-head.
00:50:32Ok.
00:50:33Sim, então este é o diagrama de trade-off, então aqui acho que não falamos sobre esta atenção linear ou Mamba.
00:50:50O principal problema é toda essa multiplicação de matrizes; no momento, todo mundo está usando atenção.
00:50:56Suponha que no futuro não queiramos usar atenção, em vez de gerar tokens sequencialmente, usar talvez modelos de difusão,
00:51:07onde podemos gerar tudo simultaneamente, então todos esses algoritmos também vão mudar.
00:51:14Mas aqui, acho que eles têm mais dois, um é a atenção linear e o outro é o Mamba.
00:51:19Portanto, de acordo com este slide, se não estivermos comprimindo nada, o MHA é apenas estarmos a paralelizar o processo.
00:51:29Portanto, não há perda de qualidade, então é bom, e depois esta grouped query attention, que acho que quase todos os modelos estão usando, tipo GQA e DSA.
00:51:42Sim.
00:51:43Acho que estamos fornecendo a mesma coisa no scorecard do mecanismo de atenção, então acho que este, a qualidade do MHA é boa, o throughput é ok.
00:51:56E para a grouped query attention, depende também do seu caso de uso, embora a qualidade seja quase semelhante à da atenção multi-head, o caso de uso também importa muito.
00:52:10Sim, a multi-query attention é apenas um extremo.
00:52:13Estamos, não sei porquê, mas estamos apenas a assumir que precisamos apenas de um bloco, e todas as queries vão atender a esses blocos menores.
00:52:24Portanto, a qualidade não é tão ótima para o MQA.
00:52:29E esta atenção latente multi-head, sim, se você tentou alguns destes modelos DeepSeek, acho que eles estão a fazer um ótimo trabalho em termos de qualidade, além disso, a janela deslizante.
00:52:44Portanto, todas estas são algumas técnicas que, sim, todas estas são algumas técnicas, como ajustar as janelas, todas essas coisas, e em vez de multiplicar tudo, a atenção linear diz apenas para resumir tudo primeiro e depois procurar nele, e depois o Mamba, que é apenas um modelo de espaço de estados, sim.
00:53:09Portanto, para as otimizações de modelos, também temos, tipo, dois notebooks aqui.
00:53:28Então, haverá, eu tenho que ir para isto.
00:53:35Ok, então para a quantização, como a demo, isto já foi executado? Não.
00:53:51Deixe-me executar isto.
00:53:54Ok, então estamos carregando o modelo, que é, tipo, um Mistral 7B.
00:54:10Portanto, este é, tipo, com a linha de base FP16.
00:54:20Espere.
00:54:21Isso executou?
00:54:21Espere.
00:54:22Isso executou?
00:54:23Ok.
00:54:24Então, levou, uh, dois milissegundos, executou.
00:54:27Isso executou?
00:54:28Ok.
00:54:29Então, sim, desta vez, ele está buscando aquele modelo com a precisão FP16.
00:54:35Ok.
00:54:36Então, levou, uh, dois milissegundos, executou.
00:54:40Isso executou?
00:54:41Ok.
00:54:42Então, sim, desta vez, ele está buscando aquele modelo com a precisão FP16.
00:54:47O Wi-Fi.
00:54:58Vai demorar um pouco.
00:55:03Ok.
00:55:08Sim, porque está baixando os pesos do Hugging Face.
00:55:14Hã?
00:55:17Sim, então o Colab está, tipo, rodando online.
00:55:22Sim.
00:55:23Porque precisa fazer a chamada de rede através do Hugging Face e, tipo, buscar.
00:55:30Não sei, tipo, mas está demorando para baixar, provavelmente.
00:55:35Ok.
00:55:36Ok.
00:55:37Ok.
00:55:38Ok.
00:55:39Ok.
00:55:40Portanto, aqui vemos, tipo, o tamanho da memória é, tipo, uns 15 GB, aproximadamente, com a precisão FP16.
00:56:00Estamos tentando fazer a compressão de 2x, como o Talmud falou, com o int8.
00:56:15Ok.
00:56:16Então, nós vemos, tipo, que o tamanho da sua memória agora é, tipo, 0,7, 0,5 GB.
00:56:21O que isso significa é que agora você tem mais memória para o seu KV crescer basicamente.
00:56:27Isso significa que você pode atender a um limite de contexto maior ou pode atender a mais usuários concorrentes lá.
00:56:36Portanto, se você fizer, tipo, o int 4, você está basicamente fazendo a compressão de 4x.
00:56:41Então, com a compressão de 4x, seria ainda menor.
00:56:45Seria, eu acho, em torno de 3 a 4 GB.
00:56:50Sim, 4,5 GB.
00:56:51E, sim.
00:56:52Então, isto é, espere.
00:56:53Portanto, este é apenas um gráfico básico de, tipo, estes são números teóricos.
00:57:09Nós não estamos fazendo, tipo, nenhum teste de throughput aqui.
00:57:12Mas, geralmente, você veria, tipo, que a sua memória aumenta.
00:57:15Portanto, você também teria, tipo, um throughput um pouco maior.
00:57:21De alguns dos benchmarks que estudamos, vimos, tipo, a compressão int 8.
00:57:26Ela tem, sim, um throughput menor.
00:57:32Ok.
00:57:33E depois há, tipo, uma demonstração sobre, tipo, os mecanismos de atenção.
00:57:42Portanto, para a atenção, ok.
00:57:45Eu tenho que executar isto.
00:57:58Ok.
00:57:59Então, executou.
00:58:02Ah.
00:58:03Espere.
00:58:04Por que diz que nenhuma GPU foi detectada?
00:58:09Deveria dizer que a GPU foi detectada.
00:58:18Ah.
00:58:19Ok.
00:58:29Espere.
00:58:30Espere.
00:58:30Espere.
00:58:50Isto é surpreendente.
00:58:57Acho que não está conseguindo detectar a GPU por algum motivo.
00:59:05Nós temos, tipo, uma GPU aqui.
00:59:11Ok.
00:59:12Deixe para lá.
00:59:14Sim.
00:59:14Portanto, mas a ideia básica aqui era mais, tipo, conforme você tenta avançar para comprimir a computação, usando diferentes mecanismos
00:59:26de atenção, como passar do multi-head para o grouped query attention e depois para o MLA.
00:59:33Você começará a ver algumas otimizações.
00:59:38Acho que ontem à noite estávamos fazendo alguns benchmarks.
00:59:43Eu queria corrigir esta parte.
00:59:45Portanto, não era, tipo, 56x.
00:59:48Eram 14x.
00:59:50Basicamente, a demo continha um erro de cálculo em que não multiplicou o número de camadas.
01:00:02Sim.
01:00:03Então, desculpas por isso.
01:00:04Portanto, este MLA é, tipo, uma economia de 14x em comparação com a sua atenção multi-head.
01:00:15Agora que entendemos os pontos problemáticos, as bases, um dos lados das otimizações, que são as otimizações de modelo, queremos falar sobre o que você pode fazer no lado do serving.
01:00:31Então, a primeira coisa é que vimos que, quando você executa um passo de decodificação simples, você está buscando os pesos do modelo e depois recalculando os vetores de chave e valor para todos os tokens anteriores.
01:00:50Mesmo que você já tenha computado esses vetores para todos os tokens.
01:00:55Portanto, há definitivamente muito desperdício de computação.
01:01:02E se você analisar a complexidade de tempo disso, ela resultará em O de N ao quadrado.
01:01:07E a maneira de resolver isso é um trade-off clássico com a memória.
01:01:12Você pode manter uma memória desses vetores em relação aos tokens e pode consultar essa memória.
01:01:19Portanto, essa memória era chamada de KVCache.
01:01:24E o fluxo se parece com algo assim.
01:01:27E então, com base neste KVCache, havia quatro otimizações que eram realmente possíveis.
01:01:35A primeira é sobre o paged attention.
01:01:42Então, qual é a diferença, qual é o problema hoje?
01:01:45Portanto, quando você envia vários solicitações como entrada para a GPU, essas solicitações estão em lote.
01:01:52A cada solicitação é alocada, digamos, um armazenamento de memória contínuo.
01:01:58Digamos, estou apenas dando um exemplo, digamos, 2 KV.
01:02:05No entanto, sua solicitação precisava apenas de, digamos, 1 KV.
01:02:11Portanto, há cerca de 50% de fragmentação de memória.
01:02:19E essa fragmentação basicamente leva ao desperdício de memória.
01:02:24Isso significa que havia espaço na memória onde você poderia ter atendido a mais solicitações, mas não pôde porque estava procurando por aquele bloco contínuo de memória.
01:02:36Portanto, foi tirada uma inspiração de como o sistema operacional funciona.
01:02:41Como se você mantivesse uma memória lógica e basicamente tivesse uma memória física.
01:02:47Portanto, na memória lógica, ainda pareceria que o vetor KV para cada token é contínuo.
01:02:59Mas ele estará mapeando para um endereço físico diferente.
01:03:06Então, isso realmente ajudou a economizar muita memória.
01:03:11E só foi possível porque eles consideram a memória como um conjunto de blocos.
01:03:18E você alocaria esses blocos dinamicamente conforme a solicitação precisar.
01:03:22Conforme novos tokens chegam e eles precisam desse tipo de memória.
01:03:27Outro recurso é quando você está enviando várias solicitações em lote,
01:03:39a GPU está aceitando essas solicitações.
01:03:42Mas ela não aceita o novo lote a menos que todas as solicitações naquele lote sejam concluídas.
01:03:49Portanto, o diagrama se parece mais com a atenção paginada.
01:03:52Mas aqui é mais sobre quando a GPU está disponível para pegar o próximo lote.
01:03:59Portanto, há um período de tempo em que a GPU fica realmente ociosa.
01:04:04E você quer resolver isso.
01:04:08E para isso, a ideia foi: ok, vamos fazer esse loteamento contínuo.
01:04:17Portanto, o loteamento contínuo também ajudou muito com a vazão, porque agora você pode despachar mais solicitações rapidamente.
01:04:24Garantindo sempre que a GPU esteja ocupada e não fique ociosa.
01:04:33Assim, você economiza nesse processamento.
01:04:36O terceiro é o cache de prefixo.
01:04:39Então, você se lembra que o cache KV ajudou a economizar o cálculo para uma única solicitação em vários tokens.
01:04:46Mas e se você tiver os mesmos tokens em várias solicitações?
01:04:53Como você basicamente economiza em relação a isso?
01:04:55Portanto, o cache de prefixo, que foi introduzido pelo VLLM, combate exatamente isso.
01:05:04E então o terceiro é, falamos sobre o quarto, na verdade.
01:05:10Falamos sobre quantizar o modelo, mas você também pode quantizar os pesos KV.
01:05:21Isso significa que agora você precisa de menos espaço para seus vetores de chave e valor.
01:05:28Isso significa que você pode atender mais vetores de chave e valor na memória.
01:05:32E isso significa que você pode atender a mais tokens.
01:05:34Isso significa que você pode atender a um limite de contexto maior.
01:05:37E isso significa que você pode manter uma melhor qualidade do modelo.
01:05:41E tudo isso já está presente no VLLM.
01:05:51Você realmente não precisa reinventar a roda.
01:05:56E você pode implantar este VLLM em produção e ver esse crescimento.
01:06:03Portanto, a seguir, temos um benchmark que realizamos.
01:06:08Este benchmark foi... deixe-me ver se eu tenho isso.
01:06:14Aqui.
01:06:17As demonstrações.
01:06:22Fazer este benchmark leva cerca de uma hora porque você precisa parar e reiniciar continuamente os servidores VLLM e carregar os modelos e tudo mais.
01:06:35Portanto, leva muito tempo para fazer os testes, mas eu realmente posso te dizer aqui o que estamos fazendo.
01:06:41Mantivemos o modelo o mesmo, como o MISTRAL 7B.
01:06:46E então temos o conjunto de perguntas de entrada que estamos enviando.
01:06:53Considere-os como os prompts.
01:06:56Em seguida, temos algumas funções auxiliares aqui, como verificar se o servidor está ativo ou não.
01:07:01Este servidor é o servidor VLLM.
01:07:04Depois, há funções auxiliares para obter as métricas do VLLM.
01:07:09E eu falarei sobre quais são essas métricas.
01:07:14Em seguida, há muitos benchmarks e tudo mais.
01:07:17E então você precisa medir o uso de KV e tudo o mais.
01:07:22Portanto, estas são as funções auxiliares.
01:07:24A linha de base é muito simples.
01:07:26Temos uma linha de base do Hugging Face.
01:07:29Esta é a forma bruta de enviar o texto para o LLM e receber a resposta de volta.
01:07:36Vemos alguns resultados aqui.
01:07:38Vimos que o Hugging Face tem uma taxa de transferência de cerca de 51 tokens por segundo.
01:07:44O tempo para o primeiro token foi de cerca de 54.
01:07:46E a latência entre tokens foi de 19.
01:07:49Tudo isso foi executado no H100.
01:07:56E então iniciamos um servidor VLLM padrão.
01:08:00Por padrão, o VLLM fornece atenção paginada, loteamento contínuo e cache KV.
01:08:08Portanto, essas três coisas estão presentes por padrão.
01:08:13E quando você tenta comparar esses benchmarks, vê que a vazão é quase 15 vezes maior.
01:08:21Você consegue servir mais tokens por segundo.
01:08:24O tempo para o primeiro token também aumenta.
01:08:34E a latência entre tokens diminui.
01:08:38E o uso de KV por usuários e por contexto com certeza aumenta.
01:08:43Agora, quando você aplica o cache de prefixo a ele.
01:08:51Com o cache de prefixo, você vê que a vazão aumenta ainda mais.
01:08:57Seu TTFT diminui.
01:08:59Sua latência entre tokens é aproximadamente a mesma.
01:09:02E o uso do cache KV em relação aos usuários diminui um pouco.
01:09:09Em relação ao contexto, não diminui.
01:09:12É aproximadamente o mesmo.
01:09:14Acho que isso também é aproximadamente o mesmo.
01:09:16Não é nada tão significativo.
01:09:19Quando você aplica a quantização KV além disso.
01:09:25Você vê que a vazão é quase semelhante.
01:09:33O tempo para o primeiro token é semelhante.
01:09:36A latência de tokens é semelhante.
01:09:39Mas o seu uso de KV realmente diminui.
01:09:42Isso acontece porque você quantizou o espaço de chave e valor.
01:09:49E há um conceito de decodificação especulativa sobre o qual o Tanmay vai falar.
01:09:54Portanto, quando você tenta fazer o benchmark deles, você também vê que há um pouco menos de uso de KV.
01:10:06Embora os resultados sejam aproximadamente os mesmos.
01:10:08Então, sim, no geral, estas são as métricas de forma geral.
01:10:21Provavelmente eu deveria diminuir o zoom.
01:10:25Ok.
01:10:26Não está.
01:10:27Diminuir o zoom.
01:10:28Não está funcionando.
01:10:29Ótimo.
01:10:30Então, sim, estes são os benchmarks do VLLM.
01:10:35É o padrão de produção de vocês, a propósito.
01:10:38Também compartilharemos aquela árvore de decisão quando formos falar sobre os outros motores.
01:10:48Então, sim, devemos falar sobre algumas das outras otimizações de inferência que podemos fazer além disso.
01:10:58E quais foram algumas das outras soluções que surgiram.
01:11:02Gostaria de convidar o Tanmay novamente.
01:11:07Ele vai falar sobre algumas dessas otimizações.
01:11:11Ah, desculpe.
01:11:12Me desculpe mesmo.
01:11:13Eu não habilitei os slides.
01:11:26Qual era o...?
01:11:27Ok.
01:11:28Ótimo.
01:11:29Perfeito.
01:11:30Qual deles?
01:11:31A decodificação especulativa.
01:11:32Sim.
01:11:33Obrigado, Harshal.
01:11:34Sim.
01:11:35Portanto, tudo isso é decodificação especulativa.
01:11:40Tudo isso são, como dizemos, diferentes sabores do mesmo refrigerante.
01:11:46Portanto, esta técnica entra na categoria de aceleradores de decodificação.
01:11:51A primeira, então estamos falando apenas desta decodificação especulativa, mas existem outras variantes, como auto-especulativa, Eagle, Medusa.
01:12:01Eu só gosto, eu acho, desta, o algoritmo Eagle.
01:12:05Então vamos começar com a decodificação especulativa.
01:12:06Ok.
01:12:07Ok.
01:12:08Então vamos começar com o que é a decodificação especulativa.
01:12:09O principal problema é que na arquitetura de transformadores, todos esses tokens são gerados sequencialmente, um por um.
01:12:26Que tal usar um modelo menor e deixar um modelo menor gerar talvez, digamos, quatro ou cinco tokens.
01:12:37E este modelo professor, ou podemos dizer, de acordo com o nosso algoritmo da Copa do Mundo, podemos chamar de árbitro.
01:12:43Portanto, o árbitro decidirá quantos tokens ele aceita.
01:12:48E esse loop continua funcionando.
01:12:51E nossa suposição é que existem certos domínios onde esse tipo de coisa vai funcionar.
01:12:59Como talvez na programação, onde quase não há criatividade.
01:13:05Cada código ou sintaxe é quase semelhante.
01:13:08Portanto, talvez isso possa ajudar.
01:13:10Mas, com base em testes pessoais, não achei essa decodificação especulativa útil.
01:13:18Mas outras técnicas, como a auto-decodificação especulativa, onde o modelo professor também tem uma cabeça auxiliar, fazem algo semelhante ao que o modelo base ou pequeno faz.
01:13:35Mas aí veio o EGLE, EGLE 1, 2, 3, não sei quantas versões existem, dizendo que, em vez de gerar tokens, vamos treinar um modelo pequeno e extrair recursos de uma das camadas principais para gerar esse recurso.
01:14:02Portanto, o EGLE é melhor em comparação com esses outros tipos de tecnologias.
01:14:10E outro é o MEDUSA, que basicamente diz para gerar todos esses tokens em paralelo.
01:14:17Ok, então aqui, aqui neste slide.
01:14:21Sim.
01:14:22O próximo slide.
01:14:24Ok.
01:14:25Ok.
01:14:26Ok, sim.
01:14:27Ok.
01:14:28Agora vamos falar sobre o cache de prefixo.
01:14:34Bem, não sei se as pessoas estão usando esse cache de prefixo estático ou não.
01:14:39Mas o problema principal do cache de prefixo é que às vezes digitamos e cometemos um pequeno erro.
01:14:47E esse cache de prefixo estático padrão pega um prompt e faz um hashing.
01:14:53E da próxima vez que o usuário fizer uma pergunta parecida, ele tentará comparar o hash.
01:14:58Então, se o hash for igual, em vez de recomputar todo o k e v, ele simplesmente pega do armazenamento.
01:15:09Mas vocês sabem que às vezes cometemos um erro ou mudamos uma palavra ou letra.
01:15:15Nesse caso, temos uma taxa de falhas de cache muito alta.
01:15:21É por isso que existe a árvore Radix.
01:15:25A árvore Radix está se tornando muito popular, também por causa dos agentes.
01:15:30Acho que quase todo mundo está usando agentes e a maior parte da computação ocorre durante o tempo de teste, na inferência.
01:15:38Onde continuamos fazendo o mesmo tipo de perguntas e prompts.
01:15:42Por exemplo: você é um engenheiro de software especialista, repetido 200 vezes.
01:15:48Esse tipo de loop continua acontecendo dentro dessas estruturas de agentes.
01:15:55Onde é necessário manter ou armazenar coisas semelhantes em uma árvore Radix.
01:16:03A árvore Radix é apenas uma versão avançada da árvore de prefixos onde recolhemos um nó se ele não tiver nenhuma ramificação.
01:16:17E para esse tipo de trabalho em que repetimos a mesma coisa sem parar,
01:16:24essa árvore Radix ajuda muito e o sglang usa esse tipo de algoritmo para o cache de prefixos.
01:16:35Ok, sim, aí tem outra coisa.
01:16:38Um é o TensorRT-LLM.
01:16:41Isso é muito confuso.
01:16:42Quando comecei, eu ficava confuso.
01:16:46O que é o TensorRT-LLM?
01:16:49Então, o TensorRT é apenas um SDK padrão.
01:16:55O TensorRT-LLM é apenas um motor de inferência.
01:16:59Assim como o vLLM e o sglang.
01:17:01Mas o problema é que ele está relacionado à NVIDIA.
01:17:05Eles otimizaram cada camada e cada problema.
01:17:10Como mencionei no algoritmo da Copa do Mundo, eles simplesmente desmontam tudo e otimizam tudo também a nível de hardware.
01:17:18Então, ok, próximo.
01:17:23Sim, para este workshop, também fizemos alguns benchmarks para ver qual é o melhor.
01:17:33Nossa configuração foi parecida com esta.
01:17:36Fizemos dois tipos de testes.
01:17:39O primeiro foi sem testes de agentes, onde apenas...
01:17:44Usamos o conjunto de dados ShareGPT e fizemos essas perguntas usando o vLLM e o sglang.
01:17:57Ok.
01:18:05Sim, ok.
01:18:07Deixe-me dar um zoom aqui.
01:18:12Ok, ótimo.
01:18:13Para este workshop, usamos o H100, e nosso primeiro teste foi apenas perguntar...
01:18:23Pegamos perguntas do ShareGPT e colocamos no vLLM e no sglang, e descobrimos que não há diferença estatística real entre qual é melhor.
01:18:34Ambos têm um desempenho quase...
01:18:37Ambos atendem a solicitações por segundo, TTFT e latência de forma semelhante.
01:18:43A única diferença foi observada durante a ramificação de agentes.
01:18:50O que fizemos foi fazer uma pergunta parecida: você é o melhor engenheiro de software do mundo.
01:18:59Então, resolva o problema de congestionamento de tráfego na cidade.
01:19:04Em seguida, passamos isso para o LLM.
01:19:08O LLM gera uma saída.
01:19:10Depois fizemos uma segunda rodada também.
01:19:13Assim que o LLM gera essa saída, na segunda rodada mencionamos especificamente que...
01:19:22deve revisar a proposta e dar notas de um a dez.
01:19:28Esses foram os dois turnos que fizemos, e esse loop continua se repetindo.
01:19:35O que descobrimos é que para esse tipo de fluxo de trabalho onde tudo é padrão, entram em cena os prompts e a engenharia de contexto.
01:19:47Portanto, se fizermos essa ramificação de agentes de forma adequada, acho que o SGLang é três a quatro vezes melhor.
01:19:54Mas, novamente, isso depende de diferentes configurações.
01:19:58Se você fizer isso, pode obter resultados diferentes.
01:20:02Ok.
01:20:03Sim.
01:20:04Então, acho...
01:20:06Nós enviamos para o GitHub?
01:20:08Sim.
01:20:09Ok.
01:20:10Sim.
01:20:11O PDF também está no Drive.
01:20:15É o mesmo link dos slides.
01:20:18Então, um breve resumo aqui.
01:20:22Em termos de vazão de carga de trabalho de API padrão, o vLLM e o SGLang seriam equivalentes.
01:20:31Portanto, se você não tem...
01:20:33Se você tem uma carga de trabalho padrão, vá de vLLM.
01:20:36De qualquer forma, é o padrão de produção.
01:20:38Mas o que o Tanmay também estava dizendo é que, quando você tenta criar cargas de trabalho de agentes, é aí que o SGLang realmente se destaca.
01:20:50E ele meio que oferece todos esses benefícios.
01:20:55Então, é isso.
01:20:58Mantenha o vLLM como padrão.
01:21:00Mas se você tiver cargas de trabalho de agentes, tente migrar para o SGLang.
01:21:05Caso não esteja satisfeito com a parte do vLLM.
01:21:09Ok.
01:21:10Deixe-me...
01:21:15Espera.
01:21:18Ok.
01:21:21E também tem o...
01:21:29Uma comparação feita no modelo de 120 bilhões.
01:21:33Como o GPT OSS de 120 bilhões.
01:21:36Este é um benchmark preparado pela PlayPy.
01:21:42Há um link para um blog aqui.
01:21:46Ah, legal.
01:21:48Ok.
01:21:49Sim.
01:21:50Eles fizeram um benchmark semelhante e incluíram o TensorRT-LLM nele.
01:21:57Com certeza, você sempre pode consultar esses benchmarks para entender qual atende melhor ao seu caso de uso.
01:22:05Como mencionamos sobre o TensorRT, eles tentam otimizar o lado do hardware também, obtendo o pico de desempenho.
01:22:16E em termos de escolha de motores, depois de decidir entre vLLM, SGLang e TensorRT, existem novos motores surgindo.
01:22:29O NVIDIA Dynamo, com certeza.
01:22:43Eles também servem para o roteamento de sessões de agentes.
01:22:49O Hugging Face está sempre aí.
01:22:51É uma opção simples.
01:22:53E tem o motor MSTAR proposto recentemente por Stanford.
01:23:00O NVIDIA Dynamo para modelos múltiplos.
01:23:05Com certeza vale a pena explorá-los.
01:23:08E para dar um resumo rápido, começamos com uma base.
01:23:15Tentamos descobrir qual modelo se adapta aos nossos casos de uso.
01:23:22Você pode escolher o DeepSeek.
01:23:27Evite escolher o Mistral 7B.
01:23:30Quero dizer, ele não é bom.
01:23:32Mas, enfim.
01:23:35Você escolhe seu modelo quando quer usar menos memória e tentar encaixar um modelo maior em uma memória menor.
01:23:44Para economizar nos custos de GPU.
01:23:47Então você pode aplicar a quantização.
01:23:51Depois, pode aplicar otimizações de atendimento usando o motor de inferência correto.
01:23:58Isso pode fornecer a vazão que você realmente deseja.
01:24:07E algo que você pode fazer depois de voltar para casa, já que não podemos cobrir todo o material aqui, é ler sobre algumas das informações de origem, como diferentes mecanismos de atenção e esses diferentes motores.
01:24:27Tente ler os diferentes benchmarks disponíveis online.
01:24:34Além disso, há muitos guias detalhados sobre as próximas fases, como aprender sobre estratégias de despejo de cache KV.
01:24:45O mundo está caminhando para a criação de um domínio separado de engenharia de cache KV.
01:24:50Portanto, é bom entender o que está acontecendo lá.
01:24:52Despejo de cache KV, compressão de cache, memórias híbridas.
01:24:57Há muitas soluções surgindo nessa área.
01:25:01Portanto, tente sempre se ater a essas bases, fundamentos ou princípios fundamentais.
01:25:08E tente ver qual solução resolve qual problema e se você realmente precisa resolver esse problema para o seu caso de uso.
01:25:17E há também a inferência distribuída de LLMs, que é outro ponto totalmente diferente.
01:25:26Você provavelmente precisaria de um workshop de duas horas lá também para ver todos os detalhes internos e fazer a prática.
01:25:40Sim, e isso é algo que estamos tentando propor para a sessão do AI Engineer em Nova York, que é mergulhar mais fundo nas seções avançadas de inferência de LLMs.
01:25:51Portanto, este workshop foi mais voltado para níveis iniciantes e intermediários.
01:25:55Portanto, neste formulário nós temos também o feedback, além do interesse.
01:26:02Se acharem que precisamos de certas melhorias em algumas seções, com certeza deixem esse feedback também.
01:26:09E se quiserem ver este workshop em Nova York, por exemplo, sintam-se totalmente à vontade para registrar o seu interesse.
01:26:22Hã?
01:26:24Ah, como é possível?
01:26:27Caramba.
01:26:32Deixa eu dar uma olhada.
01:26:37Certo.
01:26:38Hã?
01:26:39É.
01:26:40A URL funciona, né?
01:26:41É.
01:26:42Não o QR code?
01:26:43Certo.
01:26:44Provavelmente esqueci de vincular os dois.
01:26:45Beleza.
01:26:46Legal.
01:26:46É.
01:26:47Então, se puderem fornecer isso.
01:26:49Certo.
01:26:50Legal.
01:26:51É.
01:26:52Então, se puderem fornecer isso.
01:26:53Certo.
01:26:54É.
01:26:55Certo.
01:26:56Legal.
01:26:57É.
01:26:58Então, se puderem fornecer isso.
01:26:59Deixa eu só.
01:27:00Certo.
01:27:00Certo.
01:27:01Legal.
01:27:02É.
01:27:02Então, se puderem fornecer isso.
01:27:03Deixa eu só.
01:27:04Certo.
01:27:05Isso vai estar ótimo.
01:27:06Hum, e é, acho que gostaríamos de encerrar este workshop por aqui.
01:27:13E tenho certeza de que muitos de vocês devem ter várias perguntas.
01:27:14Então, podemos tirar todas elas assim, offline.
01:27:15Eh, podemos nos encontrar, eh, e podemos conversar sobre essas perguntas.
01:27:16É.
01:27:17Com certeza.
01:27:18Com certeza.
01:27:19Eh, obrigado a todos.
01:27:20Obrigado por participarem.
01:27:21Eh, acho que foi muito.
01:27:22Eh, obrigado a todos.
01:27:23Eh, obrigado a todos.
01:27:24Obrigado por participarem.
01:27:25Eh, obrigado a todos.
01:27:26Obrigado por participarem.
01:27:27Eh, acho que foi muito.
01:27:28Ah, tudo bem.
01:27:29Eh, tudo bem.
01:27:30Isso vai estar ótimo.
01:27:31Eh, e é, acho que gostaríamos de encerrar este workshop então.
01:27:33Eh, e é, acho que gostaríamos de encerrar este workshop então.
01:27:36E tenho certeza de que muitos de vocês devem ter várias perguntas.
01:27:39Então, podemos tirar todas elas assim, offline.
01:27:41Eh, podemos nos encontrar, eh, e podemos, eh, conversar sobre essas perguntas.
01:27:42É, com certeza.
01:27:43Eh, obrigado a todos.
01:27:44Eh, acho que foi muito significativo e todos vocês vieram até aqui.
01:27:49Eh, muito obrigado.
01:27:50É, obrigado.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기