Mobilidade Vertical: Inferência do MVP a Cargas de Trabalho de Trilhões de Parâmetros — Sitanshu Gupta, CoreWeave

PortuguêsالعربيةDeutschEnglishEspañolFrançaisहिन्दी日本語한국어Русский中文
AAI Engineer
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00Boa tarde a todos. Sou o Sitan Shu, da Corvi. Vou falar sobre mobilidade
00:00:19vertical. É um título bem extravagante que pensamos, mas basicamente vou
00:00:26falar sobre a plataforma de inferência que temos na Corvi, a qual estamos construindo para servir
00:00:30modelos pequenos e grandes e vários tipos de cargas de trabalho. Uma breve apresentação sobre mim: eu entrei
00:00:38na Corvi há cerca de quatro meses, liderando toda a parte de inferência por lá. E antes disso,
00:00:44eu gerenciava tudo no AWS Annapurna Labs para treinamento e, antes disso, inferência
00:00:49e treinamento na Sambanova. Então tenho bastante experiência nessa área específica. O que
00:00:56vou apresentar a vocês é como funcionam os modelos de consumo
00:01:00que temos e, a partir disso, como definimos como a plataforma deveria ser para que
00:01:04não precisemos ficar mudando a plataforma e sigamos fazendo melhorias na estrutura
00:01:09que temos para servir inferência, e como e por que o desempenho desempenha um papel tão importante
00:01:14nisso. Acho que um pouco disso pode ser em comum com o tópico anterior que foi discutido
00:01:20aqui. Modelos de consumo. Temos, em geral, dois grandes modelos de consumo. Um é o serverless,
00:01:29onde os clientes podem entrar, os consumidores podem entrar, sem se preocupar em gerenciar o
00:01:35hardware por conta própria, sem se preocupar em gerenciar clusters, orquestração ou qualquer outra coisa.
00:01:40Existe uma API, existe uma interface de usuário, você entra, paga por token e seu modelo é servido.
00:01:47O ponto principal aqui é o tipo de modelos que servimos no catálogo, que é a variedade de
00:01:54modelos que o cliente poderá explorar. Vou falar sobre o dedicado e depois volto para o serverless,
00:02:01porque há algo único no lado do serverless. O serviço de inferência dedicada que oferecemos
00:02:05é mais voltado para clientes que querem saber exatamente qual hardware vão usar e executar,
00:02:11mas a implantação do modelo também depende deles. Eles usam nosso serviço, usam nossas camadas de orquestração,
00:02:18mas a implantação do modelo depende deles. O desempenho do modelo também depende deles, desde que forneçamos
00:02:25na plataforma a capacidade e os ajustes para disponibilizar esses recursos. Voltando ao serverless,
00:02:30uma das partes interessantes aqui é que modelos serverless costumam ter o problema do vizinho barulhento,
00:02:38onde, se digamos que todos estejam requisitando o mesmo modelo ao mesmo tempo, você pode ter muito tempo de espera (timeout),
00:02:43dependendo de quanta capacidade eu tenho por trás. Então outro recurso que temos no lado do serverless
00:02:48é o que chamamos de vazão provisionada (provisioned throughput). Como cliente, se você conhece seu perfil de tráfego
00:02:55e puder nos informar sobre isso, podemos reservar isso especificamente para você,
00:03:00nos bastidores. Você ainda não precisa se preocupar em qual hardware exatamente o modelo está rodando,
00:03:04desde que sua vazão e seus SLAs sejam mantidos.
00:03:07Esse é outro ponto no lado do serverless, e ainda é cobrado por token,
00:03:12mas você sabe que não enfrentará o problema do vizinho barulhento ali.
00:03:19Deixe-me resumir rapidamente alguns tipos diferentes de cargas de trabalho, formatos de carga que temos,
00:03:27que estamos observando, e a proporção entre eles está mudando continuamente, embora a de agentes
00:03:32esteja muito alta. Cargas de agentes e chat são bem parecidas, super altas em comprimento de sequência de entrada
00:03:39e tipicamente muito baixas em comprimento de sequência de saída. Mas a maior diferença entre agentes e
00:03:43chat é o fato de que as mútilplas interações (multi-turns) em agentes exigem latência super baixa versus em chats, pois quando
00:03:50você recebe a resposta do usuário, precisa ler a resposta e então responder a ela. Então existem
00:03:56existem diferenças ali. E essa grande diferença no final se converte em algo
00:04:01relacionado ao gerenciamento de KVCache. Mas ambas são em tempo real, e outra carga de trabalho em tempo real é
00:04:09a de voz e vídeos, que têm streaming contínuo e são super sensíveis à latência. Na parte de agentes
00:04:16e chat, os requisitos são em grande parte do ponto de vista de vazão, não tanto de latência, mas voz e vídeo
00:04:23em tempo real são totalmente sensíveis à latência. Quanto ao processamento em lote (batch), é onde os SLAs são super
00:04:32flexíveis. Eles chegam a segundos e minutos, às vezes para alguns clientes até mesmo a horas.
00:04:37Eles dizem: “Vou enviar, me dê capacidade para 10 a 12 horas de carga e vou mandar o que puder,
00:04:44processe quando puder”. Essas cargas em lote, a forma como entram em cena aqui para
00:04:52decidir, desculpe, ser o requisito para algumas das escolhas de design que fazemos na arquitetura... Imagine
00:04:59esses quatro tipos diferentes de formatos de carga de trabalho. Na dimensão do tempo, você tem que saber equilibrar
00:05:04as características para encaixá-las e aproveitar ao máximo a infraestrutura subjacente.
00:05:12Vou dar uma visão geral de como nossa arquitetura está estruturada agora. E vou guiá-los um pouco pelo
00:05:19fluxo de requisição aqui. Tanto para serverless quanto para dedicado, se olharem para o lado direito da
00:05:24tela, verão que, do lado da plataforma, você acessará a camada de controle (control plane) para ter suas
00:05:31suas autorizações, limites de taxa e uso sejam rastreados, etc. Para que você possa ser cobrado adequadamente.
00:05:37E observabilidade para garantir que não estamos violando os SLAs assinados,
00:05:45certo? Na plataforma subjacente, mostrei em um nível muito alto que temos esses diferentes
00:05:52mecanismos de inferência: VLLMs, SGLangs e TensorRT-LLM, mas há bastante detalhe aqui que vou abordar.
00:06:00E abaixo disso, o que estou tentando mostrar aqui em verde são vários componentes de hardware.
00:06:09Portanto, a plataforma precisa ser capaz de compartilhar e distribuir a carga de trabalho
00:06:15entre várias gerações diferentes dessas GPUs, especificamente GPUs NVIDIA
00:06:21que utilizamos, certo? Então, vejamos alguns exemplos aqui. Digamos que a requisição venha do
00:06:31lado do cliente por meio de apps, notebooks ou agentes, certo? Ela chega ao gateway.
00:06:36Assim que chega ao gateway, como mencionei sobre o plano de controle, passa por autenticação,
00:06:42etc., e então segue para o modelo serverless ou dedicado. No caso do serverless,
00:06:48o pagamento é por token, então o uso de tokens seria monitorado aqui — não os tokens exatos,
00:06:53mas apenas o consumo, pois mantemos políticas de retenção zero de dados (ZDR).
00:06:59Dependendo de ser multi-tenant ou provisionado, se for provisionado, sabemos que
00:07:05o roteador subjacente precisa direcionar a requisição às implantações explícitas dos clientes
00:07:12com throughput provisionado. Para clientes multi-tenant, existem implantações separadas.
00:07:17O roteador aqui é extremamente importante, pois é responsável por
00:07:26fazer escolhas de roteamento conscientes do KV cache. Por que isso é importante? Porque, como mencionei ao
00:07:31discutir os perfis de carga de trabalho, os casos de uso baseados em agentes costumam exigir sequências de entrada muito longas,
00:07:39e a maior parte dessa extensão de entrada, cerca de 80 a 90 por cento, dependendo da empresa
00:07:44ou dos clientes, é idêntica para várias requisições diferentes.
00:07:51Portanto, não faz sentido recalcular ou refazer a fase de pre-fill para isso.
00:07:57A fase de pre-fill exige muito processamento e é muito dispendiosa, por isso quanto mais você acertar o cache,
00:08:04mais você economiza. É por isso que o preço dos tokens em qualquer lugar traz um valor específico para
00:08:11tokens de entrada e um valor muito mais barato para tokens de entrada cacheados. O cache se torna fundamental
00:08:18aqui. A forma de dividir o hardware depende totalmente das escolhas feitas na
00:08:26plataforma, e nós oferecemos a capacidade de fazer ambas as coisas: desagregar o pre-fill e o decode se o
00:08:31caso de uso exigir, ou não fazê-lo, já que essa desagregação de pre-fill e decode nem sempre é barata para todo tipo de uso.
00:08:41Vejamos outro fluxo de requisição. Vamos ver o que acontece no caso de um cliente dedicado.
00:08:48Um cliente dedicado também passará pelos gateways configurados para ele com o devido isolamento.
00:08:55A cobrança não é baseada em tokens, mas sim no uso de cada GPU por hora.
00:09:03É um gateway privado para evitar o problema de vizinhos barulhentos, impedindo que outros acessem.
00:09:09A lógica do roteador é a mesma, garantindo que requisições muito semelhantes aproveitem ao máximo o cache.
00:09:18E dependendo da implantação que o cliente fizer em suas GPUs dedicadas,
00:09:24ele pode decidir se deseja desagregar o pre-fill e o decode. Ele pode escolher qual
00:09:29mecanismo usar: VLLM, SG-Lang ou TensorRT-LLM. E considerando o volume de capacidade reservado,
00:09:35o cliente pode optar por ter apenas uma implantação capaz de escalar
00:09:42por todo o cluster ou manter múltiplos modelos e várias implantações diferentes.
00:09:47Um detalhe que quero destacar sobre o roteador aqui é o fato de que
00:09:54há suporte para capacidade heterogênea entre diferentes zonas e regiões.
00:09:59É um desafio considerável fazer o balanceamento de carga nesse cenário.
00:10:04Assim, a ordem de prioridade que costumamos adotar é primeiro a localidade do KV cache e, em seguida, o fallback para a menor carga.
00:10:16É isso. Outro fluxo de requisição que gostaria de abordar aqui,
00:10:21e que talvez seja um pouco difícil de ver no diagrama, é o fluxo de trabalho em lote (batch).
00:10:25No fluxo em lote, o que fazemos é aproveitar a capacidade subjacente do cliente —
00:10:31suponha o mesmo cliente de inferência dedicada: durante o dia nos EUA, ele executa cargas em tempo real,
00:10:37e do final da tarde à noite, ele quer rodar processos em lote. Essa mesma capacidade pode,
00:10:43após determinado horário, ser agendada para rodar as tarefas em lote. Oferecemos a capacidade via API para definir quando aumentar
00:10:51e quando reduzir a escala. Conforme o cronograma, se nos indicarem que é hora de reduzir,
00:10:56reduziremos a escala e a liberaremos para o processamento em lote durante a noite.
00:11:05Acho que já falei bastante sobre otimizações no lado do KV cache, mas gostaria de reforçar um
00:11:10pouco mais, pois este é um dos pontos mais interessantes. Quanto mais acertarmos no cache,
00:11:19você vai evitar o custo do pre-fill, que é a parte mais cara aqui.
00:11:26Reaproveitar o KV cache em vários turnos diferentes nas suas cargas de trabalho de agentes, entre os turnos também há
00:11:31muito pre-fill semelhante no tamanho da sequência de entrada.
00:11:38Pense nas cargas de trabalho de chat, onde o descarregamento do KV cache também se torna extremamente importante,
00:11:43porque, com as cargas de chat, temos muita latência entre os diferentes turnos,
00:11:49as interações que nós, como usuários, enviamos. Mas se eliminarmos completamente o que tínhamos em nossa conversa específica,
00:11:57na próxima vez que fizermos uma pergunta no mesmo chat, vai demorar um pouco mais.
00:12:02Então, em vez de simplesmente eliminar e refazer o pre-fill do zero, as técnicas
00:12:08utilizadas são... talvez estejamos usando as nossas próprias, mas externamente conhecemos o LMcache e o Mooncakes.
00:12:17O que fazemos é descarregar o KV cache para um armazenamento de alta largura de banda
00:12:21para podermos armazenar muitos desses pre-fills, de modo que, quando a requisição correspondente chegar
00:12:28para aquela conversa específica, ela possa ser carregada imediatamente na HBM.
00:12:37Em relação às alavancas de desempenho, eu só gostaria de mencionar algumas alavancas que já
00:12:41discutimos, como a PD DSAG, mas a quantização e a decodificação especulativa são outras, e como
00:12:48escolher cuidadosamente os graus de paralelização e as estratégias é algo realmente muito importante.
00:12:54Duas das maiores alavancas com as quais temos trabalhado são a quantização para NVFP4 e a decodificação especulativa.
00:13:01Oferecemos o recurso em que, se o cliente tiver seu conjunto de dados e quiser que treinemos especuladores
00:13:07para seus conjuntos de dados para melhores taxas de aceitação, o que, em última análise, tornará o throughput de saída
00:13:12significativamente maior, nós também disponibilizamos isso. Mas isso acontece de forma assíncrona. Recebemos os dados de forma assíncrona,
00:13:20treinamos os especuladores de forma assíncrona e depois os implantamos nos ambientes dos clientes,
00:13:26se for isso o que eles desejam. Vocês podem ver três capturas de tela aqui. Eu as publiquei a partir do
00:13:32trabalho do último mês que alguns membros da minha equipe realizaram. Como podem ver, chegamos
00:13:39rapidamente ao topo do ranking no Kimi 2.6, 2.7, e esses dados são da Artificial Analysis.
00:13:46E voltando à sessão anterior, podemos confiar nisso? É por isso que, para o GLM, eu trouxe os resultados
00:13:52do OpenRouter. Quando a Artificial Analysis executa os benchmarks, eles testam cargas de trabalho muito específicas.
00:13:58O OpenRouter representa o tráfego real de usuários, e vocês podem ver, no lado do OpenRouter, o Weights & Biases. O
00:14:05nome da marca é diferente, mas Weights & Biases é basicamente a Curvi. Nós compramos o Weights & Biases
00:14:09há cerca de um ano. Vocês podem ver que a velocidade que temos em nossa implantação aqui é muito próxima
00:14:16da que a Fireworks oferece como Fireworks Fast, certo? Mas as técnicas subjacentes que estamos usando são
00:14:21o que eu mais quero enfatizar aqui para a otimização do desempenho. Isso se torna crítico porque,
00:14:27em última análise, o que você quer entregar ao cliente — o que nós queremos entregar ao cliente — é um benefício de custo-benefício.
00:14:36Um breve resumo: uma plataforma única é o que venho tentando enfatizar, é o que estou tentando mostrar.
00:14:44Dois modelos de consumo diferentes, serverless e dedicado para clientes; e, no serverless,
00:14:49também descrevi dois modelos de consumo diferentes: pago por uso e throughput reservado, se isso for importante para você;
00:14:53e, por fim, a consolidação dos ganhos por meio de otimizações de desempenho na pilha.
00:15:01Isso é tudo. Muito obrigado, pessoal.

핵심 요약

Uma plataforma unificada de inferência maximiza o custo-benefício e reduz a latência ao alternar dinamicamente entre cargas serverless, dedicadas e em lote, usando roteamento consciente de KV cache, descarregamento de memória e decodificação especulativa.

하이라이트

  • A infraestrutura de inferência suporta dois modelos principais de consumo: serverless (cobrado por token) e dedicado (cobrado por GPU/hora).

  • Cargas de trabalho de agentes exigem sequências de entrada longas, onde de 80% a 90% dos dados de entrada são idênticos entre requisições, tornando o cache de KV indispensável.

  • A otimização de custos e desempenho depende da prevenção da fase de pre-fill, que representa a etapa mais cara do processamento de inferência.

  • O roteador do sistema prioriza a localidade do KV cache antes de fazer o fallback para a menor carga entre zonas e regiões heterogêneas.

  • Técnicas de descarregamento de KV cache para armazenamento de alta largura de banda garantem respostas rápidas em interações de chat multi-turn sem ter de reprocessar o pre-fill do zero.

  • A plataforma oferece treinamento assíncrono de modelos especuladores personalizados para conjuntos de dados de clientes, aumentando a taxa de aceitação e a vazão de saída.

타임라인

Modelos de consumo: Serverless versus Dedicado

  • O modelo serverless elimina a gestão de hardware e cobra estritamente pelo número de tokens consumidos.
  • O serviço dedicado garante isolamento total de hardware com cobrança fixa por GPU/hora.
  • A vazão provisionada no serverless impede o efeito de vizinho barulhento ao reservar capacidade dedicada sob demanda.

A arquitetura de inferência atende a diferentes necessidades de clientes por meio de opções flexíveis de alocação de recursos. No modelo serverless, o consumidor acessa uma API direta mantendo políticas de retenção zero de dados (ZDR). Para evitar latências geradas pelo tráfego simultâneo de múltiplos clientes no serverless multi-tenant, a vazão provisionada reserva capacidade pré-definida sem perder a facilidade de cobrança por token. O modelo dedicado transfere o controle de implantação e otimização para o cliente, garantindo privacidade via gateways isolados.

Perfis de carga de trabalho e requisitos de latência

  • Aplicações de agentes e chat demandam longas sequências de entrada e curtas sequências de saída.
  • Sinais em tempo real como voz e vídeo exigem sensibilidade extrema à latência e streaming contínuo.
  • Cargas de trabalho em lote operam com SLAs flexíveis de horas e preenchem horários de menor tráfego.

Cada formato de carga impõe desafios distintos sobre a infraestrutura subjacente. Agentes diferem do chat tradicional por requererem baixíssima latência entre múltiplos turnos de interação contínua, o que afeta diretamente o gerenciamento de memória. Cargas de lote possuem grande margem de tempo de processamento, permitindo que a infraestrutura reaproveite a capacidade ociosa de clusters dedicados durante períodos Noturnos.

Arquitetura da plataforma e roteamento consciente de KV Cache

  • O roteador inteligente direciona as requisições com base na localidade do KV cache para reuso de pre-fill.
  • A desagregação das fases de pre-fill e decode é configurável conforme a necessidade do caso de uso.
  • O balanceamento de carga suporta hardware heterogêneo entre diferentes zonas e regiões.

A camada de controle gerencia autorizações, limites de taxa e observabilidade de SLAs antes de enviar as requisições aos mecanismos de inferência como VLLM, SGLang ou TensorRT-LLM. Como a fase de pre-fill consome a maior parte dos recursos computacionais, o roteador prioriza nós que já possuem o cache armazenado para trechos de entrada idênticos. Caso o cache local não esteja disponível, o tráfego é direcionado para a menor carga disponível no cluster.

Técnicas avançadas de otimização de memória e desempenho

  • O descarregamento de KV cache para armazenamentos de alta largura de banda preserva conversas ativas.
  • A quantização para NVFP4 e a decodificação especulativa impulsionam a velocidade de geração de tokens.
  • Treinamentos assíncronos de especuladores adaptam a inferência ao conjunto de dados específico do cliente.

A persistência eficiente do KV cache evita o reprocessamento caro do contexto durante pausas em conversas de chat. Ao transferir os dados do cache para um armazenamento de alta velocidade e trazê-los de volta à HBM quando necessário, o sistema reduz o custo computacional. A aplicação de quantização NVFP4 combinada com modelos especuladores treinados de forma assíncrona eleva a taxa de aceitação de tokens e garante velocidades de saída competitivas nos benchmarks globais.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기