Operando Sistemas de Inferência Distribuída em Larga Escala — Nishant Gupta e Naman Ahuja, Meta
AAI Engineer
Computing/SoftwareInternet Technology
Transcript
00:00:00Bom dia a todos. Bem-vindos à primeira palestra da Influence no último dia da Feira Mundial de Engenharia de IA.
00:00:17Meu nome é Nishan Gupta e hoje estou acompanhado pelo meu co-palestrante Naman Ahuja.
00:00:23Trabalhamos na construção da infraestrutura de eficiência, treinamento e influência na Meta.
00:00:27Hoje, vamos falar sobre como operar sistemas de inferência distribuída em escala.
00:00:32Como todos sabemos, a inferência não é mais apenas um artefato de pesquisa transformado em produto.
00:00:37É uma carga de trabalho de infraestrutura de hiperescala fundamental que está crescendo a um ritmo tremendo.
00:00:43O tráfego de inferência já supera o dos maiores microsserviços do mundo
00:00:47e a taxa de crescimento é a mais rápida de qualquer carga de trabalho que já vimos.
00:00:54Vamos voltar no tempo para cerca de 2008 e tentar comparar a era da IA com a era da nuvem.
00:01:00Por volta de 2008, a nuvem começou como ofertas de máquinas virtuais.
00:01:05A engenharia interessante era a virtualização.
00:01:07Então, com o tempo, o valor subiu na pilha, para os agendadores, Borg, Kubernetes, Mesos.
00:01:14Depois para malhas de serviço, para escalonadores automáticos e, em seguida, para várias plataformas construídas sobre eles.
00:01:18A camada de orquestração foi o que realmente capturou o valor e a complexidade.
00:01:24A IA está exatamente na mesma trajetória, mas comprimida nos últimos anos em vez de uma década.
00:01:30Começamos com modelos simples rodando em GPUs.
00:01:33Em seguida, vimos a evolução de frameworks de atendimento de modelos como vLLM, TGI, Triton, e agora estamos observando a camada de orquestração emergir em tempo real, abordando os desafios complexos de roteamento, gerenciamento de cache KV, desagregação de pré-preenchimento e decodificação, e multiplexação de vários modelos.
00:01:51Nesta próxima fase da era da IA, não se trata apenas dos melhores modelos, dos kernels ou das otimizações.
00:01:57Trata-se de todo o ecossistema.
00:01:58Trata-se do plano de controle e da orquestração, e é nisso que vamos nos concentrar nesta palestra.
00:02:06Então, vamos falar um pouco sobre a explosão da demanda agêntica.
00:02:09No atendimento web clássico, antes do início das cargas de trabalho de inferência de IA, a capacidade escalava de forma aproximadamente linear com os usuários, dependendo do tipo de carga de trabalho.
00:02:17O dobro de usuários significava na maioria das vezes o dobro de QPS, o dobro da frota de infraestrutura, caso não houvesse otimizações, e o planejamento de capacidade era basicamente um exercício de planilha.
00:02:28Neste novo atendimento agêntico, a capacidade escala com o número de usuários vezes o número de chamadas por usuário, vezes o número de tokens, que varia dependendo do modelo, das otimizações e do SKU de hardware que você possui.
00:02:40Um chatbot pode ter uma chamada de modelo por turno, o que agora está evoluindo para 10 a 20 em copilotos e 50 para agentes de pesquisa, e agora são milhares dessas chamadas para cargas de trabalho autônomas sem intervenção humana.
00:02:54A principal conclusão é que você não pode planejar a capacidade para agentes da mesma forma que fazíamos para microsserviços.
00:03:00Precisamos pensar em elasticidade e implementar agendamento consciente de carga de trabalho e controle de admissão.
00:03:08Agora, vamos tentar aprofundar um pouco nas diferenças, prós e contras, entre o atendimento de microsserviços tradicionais e o atendimento de inferência moderno nessas dimensões principais.
00:03:19O formato da requisição.
00:03:20Os microsserviços assumem requisições curtas e uniformes, ao passo que as requisições de LLM que estamos vendo em nossas cargas de trabalho podem variar de 50 tokens a 100.000 tokens, com perfis de computação vastamente diferentes entre os estágios de pré-preenchimento e decodificação.
00:03:33Quanto ao loteamento, as pilhas clássicas para microsserviços faziam agrupamento em lote principalmente na camada de balanceamento de carga, se é que o faziam.
00:03:40No entanto, o atendimento de LLMs exige loteamento contínuo em execução, caso contrário, a vazão desaba em uma ordem de magnitude ou mais.
00:03:48Estado.
00:03:49A maioria dos microsserviços clássicos era sem estado, quando não estamos falando da camada de armazenamento.
00:03:54No entanto, o atendimento de LLMs exige um enorme estado por requisição, o cache KV, que é muito caro de construir e ainda mais caro de descartar.
00:04:02Unidades de dimensionamento.
00:04:03Unidades de dimensionamento.
00:04:05Quando pensamos em microsserviços tradicionais, podíamos executá-los em CPUs baratas, em pods.
00:04:11No entanto, para a inferência moderna, precisamos executar em GPUs, que são 100 vezes mais caras, que demoram 10 vezes mais para serem adquiridas, e não podemos superdimensioná-las casualmente.
00:04:20Caso contrário, isso levará a um enorme desperdício.
00:04:23Modo de falha.
00:04:25Quando você pensa em microsserviços tradicionais, como a maioria de nós construiu nos últimos anos, podíamos reiniciar um host ou um pod mesmo se ele travasse.
00:04:34Podíamos reconstruir o estado, se necessário.
00:04:36No entanto, para a inferência de modelos, leva uma quantidade enorme de tempo para ir da inicialização fria à quente.
00:04:42E se uma GPU estiver no meio da decodificação, ela pode descartar milhares de tokens em andamento, o que pode levar ao acúmulo de filas.
00:04:50A conclusão é que o gargalo não é apenas o modelo.
00:04:53É a própria orquestração.
00:04:58Agora, como podemos ver nessas decisões ocultas por trás de um prompt, quando vamos para uma aplicação agêntica, ela exige uma série de etapas que acontecem nos bastidores.
00:05:06Temos que autenticar.
00:05:07Temos que escolher um modelo, dependendo do tipo de requisição.
00:05:09Temos que selecionar a região para onde vai.
00:05:11Temos que fazer o controle de admissão.
00:05:12Temos que fazer a consulta de cache.
00:05:14Temos que executar no GPU.
00:05:17Temos que fazer o loteamento.
00:05:18E há uma série de outras etapas envolvidas.
00:05:19E como podemos ver, de todas essas etapas, apenas uma etapa requer o modelo, que é o pré-preenchimento e a decodificação.
00:05:25Se for inferência desagregrada, ou mesmo se não for inferência desagregrada.
00:05:29As outras etapas exigem infraestrutura.
00:05:31A inteligência pode estar no modelo, mas a economia, a confiabilidade e a experiência do usuário estão todas na infraestrutura.
00:05:38E é por isso que muitas equipes de plataforma em várias empresas estão tendo muito mais impacto na qualidade e no sucesso do produto, muito mais do que antes.
00:05:50A maioria de nós nesta sala tem profunda experiência em uma, duas ou três camadas.
00:05:54Podemos possuir kernels ou otimizações de kernel.
00:05:57Podemos possuir o roteamento ou o próprio produto.
00:05:59Ou podemos estar operando a infraestrutura de GPU ou o próprio cluster.
00:06:03Mas muito poucos de nós operaram toda a pilha ou pensaram nela de ponta a ponta.
00:06:08Como você pode ver nessas camadas, elas não são novas.
00:06:11Elas existem há 20 anos ou mais.
00:06:13O que é novo é a combinação e o acoplamento entre elas.
00:06:18Uma decisão na camada de roteamento pode alterar a taxa de acerto de cache na camada do modelo, o que pode alterar a composição do lote, o que pode alterar a utilização da GPU, o que pode alterar a decisão de dimensionamento automático devido à mudança na utilização da GPU.
00:06:32Portanto, tudo está entrelaçado.
00:06:33Quando temos quaisquer regressões em nossas cargas de trabalho de inferência, não se trata apenas de entender o que aconteceu na camada de cache ou no controle de admissão.
00:06:41Precisamos pensar na pilha de cima a baixo.
00:06:43E quando vemos qualquer gargalo, é muito, muito importante entender em qual camada está esse gargalo para que possamos investir adequadamente.
00:06:54Agora, mergulhando um pouco mais fundo em como um prompt funciona, quando temos um prompt para qualquer aplicativo, seja para gerar uma imagem, seja para uma tarefa de pesquisa ou para uma orquestração multiagente complexa, mais ou menos, isso envolve várias destas etapas.
00:07:08O prompt vai para o gateway.
00:07:10Depois vai para o roteador, após o que ele faz a consulta de cache se a requisição já tiver sido vista antes.
00:07:17Em seguida, vai para os agendadores, que decidem em qual cluster de GPU ele deve rodar, em qual hardware.
00:07:22Pode ser em NVIDIA, AMD ou no seu chip de silício interno, que então vai para o tempo de execução de atendimento apropriado, vLLM, SGLang ou o que quer que estejamos usando.
00:07:30E então transmitimos a resposta de volta ao usuário de acordo com os perfis de SLO de tempo para o primeiro token e tempo entre cada token, enquanto garantimos que a vazão seja a desejada pelo usuário.
00:07:41Agora, como podemos ver, esta inferência se comporta como uma transação distribuída.
00:07:45Cada seta neste diagrama é um salto de rede.
00:07:47Cada um desses saltos pode tentar novamente.
00:07:50Pode expirar o tempo limite.
00:07:51Pode recorrer a uma alternativa.
00:07:53Pode até falhar.
00:07:54E cada um desses saltos terá SLOs, e está transmitindo de volta para o usuário.
00:08:00Portanto, se falhar, a semântica de falha parcial é muito mais difícil de lidar do que para uma chamada RPC normal.
00:08:06Pense no que acontece se já transmitimos 200 tokens de volta para o usuário e de repente um host de GPU é preempetivo devido a um evento de manutenção agendado ou planejado ou não planejado
00:08:15de manutenção.
00:08:16Não podemos simplesmente tentar novamente.
00:08:17Temos que pensar nisso de forma holística.
00:08:19É por isso que a confiabilidade, não podemos construir confiabilidade na borda.
00:08:23Ela precisa ser uma propriedade do plano de controle, porque o plano de controle é o único que vê todo o fluxo de trabalho.
00:08:31Agora, vamos falar sobre agendadores e algumas das otimizações e como podemos pensar sobre isso.
00:08:37Portanto, para os microsserviços tradicionais, costumábamos pensar no empacotamento de microsserviços tradicionais em três ou quatro dimensões.
00:08:43Poderia ser em redes sociais, memória de CPU ou em quatro domínios, dependendo se você está usando AWS ou seus próprios provedores de nuvem internos.
00:08:52Mas para inferência, o agendador precisa estar ciente de pelo menos sete eixos quando agendamos uma determinada requisição.
00:08:59Ele precisa estar ciente do tipo de GPU.
00:09:00Pode haver um número n de hardwares heterogêneos em seu cluster, H100 versus H100 versus B200, com diferentes topologias de rede.
00:09:09Ele precisa estar ciente da margem HBM, do estado do cache KV.
00:09:13Os pesos do modelo, se já estão carregados, se estão frios, ou se precisamos aquecê-los com uma inicialização a frio.
00:09:19Ele precisa estar ciente da prioridade do locatário.
00:09:21Pode haver um número n de locatários rodando nesse cluster multilocatário com diferentes perfis de SLO.
00:09:27Também precisamos estar cientes do contexto do fluxo de trabalho.
00:09:30Estamos no terceiro passo de raciocínio que já gastou X dólares, ou estamos nos estágios iniciais e podemos encerrar o fluxo de trabalho se estivermos superdimensionados?
00:09:39Também precisamos pensar no orçamento de latência, dependendo do tipo de aplicativo agêntico que estamos construindo.
00:09:44Portanto, isso nos leva à ideia de que devemos garantir a implementação de agendamento consciente de agentes.
00:09:49Devemos garantir que aloquemos um trabalho que termine no menor tempo e com o menor custo, em vez de simplesmente colocá-lo em uma GPU aleatória.
00:09:58Um exemplo concreto pode ser que o agendador precise estar ciente de que a requisição R está na etapa três de um fluxo de trabalho de cinco etapas,
00:10:05e que já gastou X mais Y dólares nas etapas um e dois.
00:10:09Portanto, se a etapa três falhar, todo o fluxo de trabalho será encerrado e teremos desperdiçado todos esses recursos de computação.
00:10:14É por isso que a orquestração consciente do fluxo de trabalho é muito, muito importante,
00:10:18porque ela mudará as decisões de admissão, a prioridade e a forma como tentamos novamente.
00:10:25Agora vamos falar sobre otimizações.
00:10:27Não vou me aprofundar muito em várias otimizações.
00:10:29Há muita pesquisa que já foi feita externamente, mas gostaria de compartilhar um framework,
00:10:34que pelo menos eu gosto de usar quando se trata disso, e podemos dividi-lo em quatro quadrantes.
00:10:40Primeiro, podemos evitar o trabalho?
00:10:42Ou seja, podemos ignorá-lo inteiramente por meio de cache, por meio de técnicas como cache de prefixo, cache de resposta, cache semântico?
00:10:48Segundo, podemos compartilhar o trabalho?
00:10:51Várias requisições podem compartilhar a computação por meio de loteamento?
00:10:54Pense em loteamento contínuo, pré-preenchimento de decodificação, pré-preenchimento em partes, decodificação especulativa.
00:10:59Terceiro, podemos afastar o trabalho?
00:11:01Podemos enviá-lo para um modelo mais barato ou mais perto do usuário?
00:11:05Principalmente por meio de roteamento, podemos encaminhá-lo para um modelo menor, uma região mais barata ou outras técnicas?
00:11:12E por último, podemos adiar o trabalho?
00:11:13Podemos esperar por um momento melhor por meio de controle de admissão e enfileiramento, o que exige compreender as classes de prioridade dessas solicitações e implementar um agendamento consciente de prazos?
00:11:25Agora, esse framework é muito poderoso porque se adapta a vários tipos de pilhas.
00:11:29Você pode estar usando VLM, SG-Lang ou TensorRT, mas cada técnica se encaixa em um desses quadrantes.
00:11:35Portanto, sempre que pensamos em qualquer otimização para o nosso modelo, precisamos comparar e contrastar com as técnicas anteriores
00:11:41e ver como tudo isso se integra.
00:11:47Agora, sempre que pensamos em escala, não basta apenas considerar o desempenho do modelo.
00:11:51Também temos que pensar nos custos e na economia.
00:11:54É aqui que se torna importante entender qual métrica estamos tentando otimizar.
00:11:58Porque o custo não é apenas o custo da GPU ou do modelo.
00:12:02Trata-se do custo de todos esses parâmetros, novas tentativas, armazenamento, falhas, rede e, claro, o custo operacional de desenvolvimento e tudo mais.
00:12:09O importante é entender qual é o principal indicador de desempenho do seu produto que agregará valor aos usuários.
00:12:17Portanto, não importa otimizar apenas o custo por token ou o custo por solicitação.
00:12:22Precisamos otimizar o custo por tarefa bem-sucedida, porque é isso que realmente importa para os usuários.
00:12:26E se você conseguir otimizar isso, o custo geral do produto diminui e os usuários ficam muito mais felizes.
00:12:36Agora vamos falar sobre confiabilidade, um pouco sobre confiabilidade e o que significa prevenir falhas em cascata.
00:12:43A história de uma falha nunca se resume a uma GPU ser preemptada ou ter morrido.
00:12:46O aspecto interessante é o ciclo de feedback que se segue.
00:12:49Portanto, uma GPU pode se degradar, a latência pode aumentar, o cliente tenta novamente, a profundidade da fila aumenta, as GPUs saudáveis vão saturar, o que resultará em mais novas tentativas e falhas regionais completas.
00:13:02Estas são as clássicas falhas em cascata, mas com um diferencial para uma aplicação gerativa: o cache KV.
00:13:09Não podemos simplesmente reiniciar ou redirecionar para um cluster diferente de qualquer maneira.
00:13:13Um pool frio precisa ser aquecido antes de poder absorver tráfego, período durante o qual o pool quente precisa assumir todas essas solicitações.
00:13:20É por isso que é importante projetar os disjuntores de fluxo de forma muito deliberada.
00:13:24Os disjuntores na camada de roteamento, o controle de admissão — que em vez de apenas enfileirar, faz o descarte de carga atrelado à profundidade da fila, e não apenas à utilização de CPU ou memória.
00:13:34E também temos que pensar em limites de novas tentativas, porque se não pensarmos em tudo isso, o custo pode escalar muito mais rapidamente.
00:13:43Agora vou passar a palavra para o meu co-palestrante Naman para falar sobre o restante da apresentação.
00:13:50Obrigado.
00:14:20Vou passar a palavra para o meu co-palestrante Naman.
00:14:22Vou passar a palavra para o meu co-palestrante Naman.
00:14:25Vou passar a palavra para o meu co-palestrante Naman.
00:14:26Vou passar a palavra para o meu co-palestrante Naman.
00:14:27Vou passar a palavra para o meu co-palestrante Naman.
00:14:28Vou passar a palavra para o meu co-palestrante Naman.
00:14:29Vou passar a palavra para o meu co-palestrante Naman.
00:14:30Vou passar a palavra para o meu co-palestrante Naman.
00:14:31Vou passar a palavra para o meu co-palestrante Naman.
00:14:32Vou passar a palavra para o meu co-palestrante Naman.
00:14:33Vou passar a palavra para o meu co-palestrante Naman.
00:14:34Vou passar a palavra para o meu co-palestrante Naman.
00:14:35Vou passar a palavra para o meu co-palestrante Naman.
00:14:36Vou passar a palavra para o meu co-palestrante Naman.
00:14:54Ok, isso funciona, eu acho.
00:14:57Desculpe pelo .
00:14:58Então, uma vez que a inferência atinge a escala de produção,
00:15:00ela começa a se parecer muito mais com um sistema distribuído.
00:15:03Não estamos mais apenas chamando um modelo.
00:15:06É mais como um problema clássico de sistema distribuído.
00:15:09Portanto, em sistemas distribuídos, falamos sobre filas, agendamento,
00:15:13auto-scaling, isolamento de falhas.
00:15:14Estas são algumas das dimensões.
00:15:16A inferência tem todos esses problemas,
00:15:18mas agora existem novas restrições.
00:15:20Em vez de apenas CPU e memória, temos CPU, HBM, cache KV,
00:15:25e custo por tarefa bem-sucedida.
00:15:27Portanto, a questão operacional passa a ser:
00:15:28como a plataforma sabe o que fazer a seguir?
00:15:31E é aí que a observabilidade entra em jogo.
00:15:34Não se trata apenas de painéis.
00:15:35Trata-se de como fornecer sinal de entrada para o loop de controle.
00:15:39Telemetria, métricas, análises; as análises impulsionam decisões,
00:15:43orientam problemas e mudanças de agendamento e roteamento,
00:15:45e finalmente, apenas repetimos o processo.
00:15:47Vou dar uma visão geral de quais são algumas métricas importantes.
00:15:50A primeira é o tempo até o primeiro token,
00:15:52que me diz quanto tempo realmente leva
00:15:56para obter a primeira resposta.
00:15:58Depois, temos a taxa de utilização,
00:16:00que me diz se a memória ou o processamento é o gargalo.
00:16:04Temos sucessos por dólar, o que nos diz
00:16:06se a plataforma está realmente entregando
00:16:08e funcionando de forma eficiente.
00:16:10E por fim, temos a latência de ponta a ponta
00:16:12que nos diz quanto tempo está sendo gasto
00:16:15em todo o caminho da solicitação.
00:16:19Há um compromisso essencial entre latência, custo e vazão.
00:16:22Você não pode simplesmente ter todos eles.
00:16:24É bastante análogo ao teorema CAP.
00:16:26Se eu aumentar o tamanho do lote,
00:16:28eu melhoro a vazão e a eficiência de custos,
00:16:31mas posso prejudicar a latência de cauda.
00:16:33Se eu usar decodificação especulativa,
00:16:35posso melhorar a latência, mas há algum processamento extra.
00:16:38Em última análise, sabe, aumentamos o custo por token.
00:16:41E por fim, posso usar um modelo simples, menor.
00:16:44Posso reduzir a latência e o custo,
00:16:45mas a resposta será de baixa qualidade.
00:16:48Em última análise, farei análise de falhas, realizarei novas tentativas,
00:16:50o que eleva o custo novamente.
00:16:52Portanto, cada decisão de atendimento move
00:16:54o sistema para algum ponto desse triângulo.
00:16:56E nosso trabalho é encontrar a configuração perfeita.
00:16:58Agora é apenas um problema de otimização.
00:17:03É para onde a indústria está caminhando agora.
00:17:05A inferência precisa de seu próprio plano de controle.
00:17:07Tudo o que discutimos — roteamento, loteamento, cache,
00:17:10agendamento, confiabilidade —
00:17:12não podem mais ser botões separados.
00:17:15Eles estão convergindo para uma camada lógica.
00:17:17Vamos chamá-la de plano de controle de inferência.
00:17:19Costumávamos gerenciar VMs antes em sistemas distribuídos.
00:17:21Tínhamos agendadores com auto-scaling.
00:17:23E tínhamos o Kubernetes, que transformou isso em um plano de controle.
00:17:27A inferência está passando pela mesma transição agora.
00:17:30Os modelos estão se tornando recursos.
00:17:32GPU, cache KV, token, latência, custo agora são agendados ao redor disso.
00:17:36O plano de controle decide quais modelos atendem a qual solicitação
00:17:40e como ela é loteada.
00:17:42Portanto, quer construamos essa camada internamente,
00:17:44usemos código aberto ou de um fornecedor,
00:17:46o design fundamental é assumir que essa camada existirá.
00:17:50Agora vamos discutir se algumas das lições operacionais
00:17:53que vivenciamos em infraestrutura de IA
00:17:55são aplicáveis aqui e como.
00:17:57A primeira lição é que os gargalos de infraestrutura
00:18:00geralmente aparecem antes dos gargalos de modelo.
00:18:02Em produção, muitas falhas podem ocorrer,
00:18:04mas podem ser apenas sobre agendamento e roteamento
00:18:07ou falhas de capacidade.
00:18:08Portanto, estas não estão relacionadas à inferência.
00:18:10Trata-se de problemas de infraestrutura.
00:18:12Depois, temos a elasticidade.
00:18:14Precisamos de elasticidade no sistema.
00:18:15Podemos ter mais GPUs, mas isso não resolverá realmente o problema.
00:18:18Estamos apenas escondendo o problema.
00:18:20Em seguida, nossa solução para a decisão de agendamento,
00:18:24supera a eficiência pura.
00:18:26A mesma frota pode entregar com alto desempenho,
00:18:28dependendo de como você está agendando
00:18:30ou de como está agrupando em lotes.
00:18:31Depois, temos os loops de controle, que superam o processo manual.
00:18:35A plataforma precisa detectar, sentir
00:18:37e se adaptar automaticamente ao sistema.
00:18:39Portanto, as principais conclusões: não otimize para tokens.
00:18:43Otimize para tarefas bem-sucedidas.
00:18:48Portanto, esta é uma mudança mais ampla com a qual quero deixá-los.
00:18:51A primeira fase da infraestrutura de IA tratava de modelos melhores.
00:18:54Investimos muito tempo melhorando nossos modelos,
00:18:56tornando-os mais inteligentes
00:18:58e surgindo com melhores benchmarks.
00:19:00A fase atual é sobre inferência mais rápida,
00:19:03menor latência, melhor processamento em lotes
00:19:05e melhor utilização de GPU.
00:19:08Mas a próxima fase é sobre orquestração.
00:19:10Isso significa que GPU, memória, cache e tudo o mais
00:19:13são apenas recursos,
00:19:14e eles precisam ser agendados e controlados.
00:19:17As equipes que entenderem isso desde cedo
00:19:19construirão a infraestrutura do futuro.
00:19:21Portanto, a ideia de encerramento é:
00:19:23a infraestrutura não é mais um problema de atendimento.
00:19:25É um problema de orquestração.
00:19:27Obrigado.
00:19:29Obrigado.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video