Resumo Técnico: xGR: Atendimento de Recomendação Generativa Eficiente em Escala

1. Definição do Problema

Sistemas de Recomendação Generativa (GR), que utilizam Grandes Modelos de Linguagem (LLMs) para prever interações usuário-item, enfrentam desafios de atendimento únicos que diferem significativamente do atendimento de conversação padrão de LLMs:

• Desajuste de Carga de Trabalho: Diferente dos LLMs conversacionais que geram respostas longas para prompts curtos, o GR processa sequências de histórico de usuário longas (prompts) para produzir saídas curtas de comprimento fixo.
• Sobrecarga de Beam Search: O GR requer larguras de feixe (beam widths - BW) e valores de Top-K grandes para garantir a diversidade e a precisão da recomendação. Isso leva a pools massivos de candidatos (ex: $128 \times 128$ ou $512 \times 512$), tornando as operações de ordenação e filtragem computacionalmente caras.
• Ineficiência de Memória: Sistemas de atendimento de LLM existentes (ex: PagedAttention) tratam cada feixe como uma sequência independente. Isso causa o carregamento redundante do contexto do prompt compartilhado (cache KV) para cada feixe e exige o cópia de blocos custosa quando as sequências dos feixes se ramificam, levando à fragmentação de memória e saturação de largura de banda.
• Geração de Tokens Inválidos: Devido ao vasto espaço combinatório de IDs de tokens, muitas sequências geradas não correspondem a itens do mundo real. Filtrar esses itens inválidos dinamicamente introduz latência, enquanto o armazenamento prévio de máscaras cria um overhead de memória ingerenciável.
• Latência de Agendamento: Modelos de GR são frequentemente menores que LLMs gerais, tornando o sistema altamente sensível a overheads não computacionais, como agendamento no lado do host e sincronização, que podem dominar o orçamento de latência (SLOs estritos exigem latência P99 dentro de ~200ms).

2. Metodologia: O Sistema xGR

Os autores propõem o xGR, um sistema de atendimento dedicado projetado para reconstruir o pipeline de GR através de três componentes estreitamente acoplados: xAttention (nível de operador), xBeam (nível de algoritmo) e xSchedule (nível de sistema).

2.1 xAttention: Otimizações de Nível de Operador

O xAddress os gargalos de memória e computação no mecanismo de atenção:

• Cache KV Separado: O xGR desacopla o cache KV em componentes Compartilhados e Não Compartilhados. O cache Compartilhado armazena o contexto do prompt (histórico do usuário) computado uma única vez durante a fase de prefill. O cache Não Compartilhado armazena apenas os tokens gerados dinamicamente para cada etapa de decodificação. Isso elimina o carregamento redundante do contexto do prompt entre os feixes.
• Gerenciamento de Granularidade de Token: Ao contrário do gerenciamento baseado em blocos (ex: PagedAttention), o cache Não Compartilhado é gerenciado no nível do token. Isso evita o overhead de alinhar comprimentos de sequência a tamanhos de bloco e elimina a necessidade de cópia física de blocos quando os feixes se ramificam.
• Computação em Estágios: A computação da atenção é dividida em três estágios: Compartilhado, Não Compartilhado e Fusão (Merging).
  • Os estágios Compartilhado e Não Compartilhado computam pontuações de atenção locais e estatísticas (máximos/somas) de forma independente.
  • O estágio de Fusão aplica OnlineSoftmax para combinar os resultados.
  • Este design permite o paralelismo de pipeline entre unidades de hardware (Grupos de Cores), fundindo operações de BatchMatmul e Softmax para maximar a utilização do hardware.
• Atualizações In-Place: Para gerenciar o cache Não Compartilhado sem cópias extras, o xAttention usa uma estratégia de ordenação híbrida com índices diretos para realizar atualizações de blocos in-place, prevenindo riscos de leitura antes da escrita.

2.2 xBeam: Otimizações de Nível de Algoritmo

O xBeam otimiza o processo de beam search para reduzir custos de ordenação e filtragem:

• Restrição de Caminho Válido: Para evitar a geração de itens inválidos (sequências de tokens que não mapeiam para produtos reais), o xBeam emprega um mecanismo de filtragem baseada em máscara. Ele utiliza um vocabulário de itens válidos pré-construído para gerar máscaras.
  • Armazenamento Híbrido Denso/Esparso: Para as etapas iniciais de decodificação com muitos candidatos, as máscaras são armazenadas densamente e pré-geradas. Para etapas posteriores com menos candidatos, as máscaras são armazenadas esparsamente e atualizadas in-place, minimizando a latência de geração em tempo de execução.
• Terminação Antecipada de Ordenação: O beam search envolve a seleção de sequências Top-K de um grande pool. Como as log-probabilidades dentro de um feixe são inerentemente ordenadas, o xBeam utiliza um min-heap global e uma estratégia de terminação antecipada. Se a log-probabilidade de um nó folha for inferior ao mínimo do heap, a travessia para aquele ramo para imediatamente, evitando operações de ordenação desnecessárias.
• Reuso de Estrutura de Dados: Em vez de alocar nova memória para cada nova sequência candidata, o xBeam reutiliza estruturas de dados de sequências descartadas, reduzindo o overhead de alocação/desalocação.

2.3 xSchedule: Otimizações de Nível de Sistema

O xSchedule gerencia o pipeline multinível para maximizar o paralelismo e a sobreposição:

• Hierarquia de Três Camadas: O sistema emprega uma hierarquia de scheduler, engine e worker para permitir a sobreposição entre batches, dentro de batches e dentro de requisições individuais.
• Sobreposição Host-Device: Fluxos de controle (ex: despacho de kernel) e transferências de dados (ex: geração de máscara e transferência H2D) são sobrepostos com computações do lado do dispositivo (ex: forward pass do modelo).
• Execução Baseada em Grafo: As operações do lado do dispositivo são capturadas em um grafo estático e enviadas em lote, reduzindo o overhead de lançamento de kernel e a intervenção da CPU.
• Batching Dinâmico e Multi-Stream: O xSchedule ajusta os tamanhos de batch com base na capacidade de tokens e nas restrições de SLO. Ele também emprega uma estratégia multi-stream para processar batches concorrentemente, garantindo que a menor pegada computacional dos modelos de GR não leve à subutilização do acelerador.

3. Principais Contribuições

1. Análise de Carga de Trabalho: Uma análise abrangente das características da carga de trabalho de GR, identificando que a fase de decodificação no GR é computacionalmente pesada devido ao beam search, ao contrário da suposição de que o prefill é o custo dominante nos LLMs padrão.
2. Otimização de Operador (xAttention): Introdução de um mecanismo de atenção em estágios com gerenciamento de cache KV separado, eliminando acesso redundante à memória e cópia de blocos.
3. Otimização de Algoritmo (xBeam): Desenvolvimento de um algoritmo de beam search apresentando restrições de caminho válido, terminação antecipada de ordenação e reuso de estrutura de dados para minimizar o overhead de ordenação e filtragem.
4. Otimização de Sistema (xSchedule): Um pipeline de atendimento redesenhado utilizando sobreposição host-device, execução baseada em grafo e paralelismo multi-stream para maximizar o throughput sob restrições estritas de latência.
5. Implantação em Produção: O sistema foi implantado em produção por mais de seis meses, atendendo centenas de milhões de usuários com latência P99 abaixo de 200ms, mesmo a dezenas de milhares de requisições por segundo (RPS).

4. Resultados Experimentais

Experimentos foram conduzidos em datasets do mundo real (Amazon Review e JD Trace) usando NPUs Ascend e GPUs NVIDIA H800, comparando o xGR contra baselines de última geração (vLLM e xLLM).

• Throughput: Sob restrições estritas de latência P99 (≤200ms), o xGR alcança pelo menos 2.89× mais throughput que o melhor baseline (xLLM) em modelos Qwen e 8.05× em modelos OneRec.
• Escalabilidade: À medida que a largura do feixe aumenta (ex: de 128 para 512), os baselines experimentam crescimento não linear de latência e falham em cumprir os SLOs. O xGR mantém um aumento de latência relativamente suave, demonstrando escalabilidade robusta.
• Eficiência de Memória: O xGR reduz significativamente a pegada de memória. Com uma largura de feixe de 512, o xGR consome ~10.6GB comparado aos 46.3GB do xLLM. Ele desacopla o uso de memória do comprimento da sequência, mantendo o baixo uso de memória mesmo com contextos de entrada longos (3k tokens).
• Eficiência de Kernel: O xAttention reduz a latência de kernel em aproximadamente 6.6× e aumenta o throughput computacional em 7× comparado ao PagedAttention. Ele transforma a carga de trabalho de orientada à memória (93.4% de tempo de ocupação no pipeline de memória para baselines) para orientada ao cálculo (~52% de tempo de ocupação para xGR).
• Portabilidade: Os ganhos de desempenho são consistentes tanto em NPUs Ascend quanto em GPUs NVIDIA, validando a portabilidade arquitetural do sistema.

5. Significância e Alegações

O artigo afirma ser o primeiro trabalho a reconstruir de forma abrangente o paradigma de atendimento de GR, abrangendo otimizações desde operadores até algoritmos e arquitetura de sistema.

• Mudança de Paradigma: Ele desafia a noção de que sistemas de atendimento de LLM padrão são suficientes para GR, destacando as características únicas de "prompt longo, saída curta" e "alta largura de feixe" que exigem tratamento especializado.
• Viabilidade de Produção: O sistema não é meramente teórico; ele está implantado em um ambiente de alta concorrência (JD Company), provando sua capacidade de lidar com padrões de tráfego do mundo real e SLOs estritos.
• Otimização Holística: O artigo enfatiza que melhorias de hardware sozinhas (ex: GPUs mais rápidas) são insuficientes para resolver os desafios de atendimento de GR. Em vez disso, um redesenho completo do sistema abordando gerenciamento de memória, algoritmos de busca e agendamento é necessário para desbloquear o potencial total da Recomendação Generativa.