DuoLM acelera recomendações com LLM em 60 vezes: 26 400 avaliações por segundo em uma única H100

Sistemas de recomendação baseados em grandes modelos de linguagem esbarram na aritmética. Para avaliar centenas de candidatos para um único usuário, é preciso passar pelo modelo os textos completos das descrições junto com o histórico, e a capacidade de processamento dos servidores se esgota rápido. Os autores do DuoLM — Jiang Wu, Yutong Song, Hongbo Wang, Guanghe Cao e Jeff Lei Liang — propõem eliminar por completo o trabalho repetido. Em uma única placa H100, o sistema calcula cerca de 26 400 avaliações de candidatos por segundo. Isso é aproximadamente 60 vezes mais rápido que o modelo professor implantado em vLLM com automatic prefix caching, com qualidade de recomendação comparável.

Dois modelos em vez de um prompt longo

Um ranker LLM convencional recebe tudo de uma vez na entrada: o texto do item, o histórico do usuário e as reações dele. Para cada par "usuário — candidato", o texto precisa ser processado de novo, embora a descrição de um produto ou de um vídeo não dependa do usuário.

O DuoLM divide a tarefa em duas partes. A primeira é um encoder baseado em LLM. Ele lê a descrição do item e a comprime em uma representação compacta. Esse passo acontece offline, o resultado fica em cache e serve a qualquer número de usuários. A segunda é um ranker personalizado, também um LLM. Ele recebe as representações prontas dos candidatos, o histórico do usuário e o feedback, e devolve a recomendação.

Os dois modelos são treinados em conjunto, end to end. Há dois sinais de treinamento: os rótulos de recomendação e a destilação de um "especialista", o modelo professor, que enxerga o texto completo. O encoder aprende a comprimir as descrições de modo que a perda de informação não prejudique o ranking final, e o ranker aprende a trabalhar com a entrada comprimida.

Runtime: tokens virtuais e CUDA Graphs

Um modelo que, em teoria, economiza computação pode perder esse ganho com facilidade por causa do overhead na prática. Por isso, os autores descrevem não só a arquitetura, mas também a parte de servidor. Ela funciona assim:

• as representações dos itens ficam armazenadas diretamente na GPU e entram no modelo por meio de token IDs virtuais — o ranker acessa os embeddings da mesma forma que acessa tokens comuns, sem cópias desnecessárias;
• vários candidatos dentro de uma mesma requisição compartilham o cálculo do histórico do usuário: o prefixo é calculado uma vez, e não para cada candidato;
• o CUDA Graph replay reduz o overhead de lançamento de kernels, o que importa quando os próprios cálculos são curtos.

Juntos, o modelo e o runtime reduzem o trabalho repetido em cada etapa do pipeline de recomendação.

O que representam 26 400 avaliações por segundo

Principais parâmetros do trabalho:

• arquitetura: encoder LLM para representações compactas dos itens e ranker LLM personalizado;
• treinamento: end to end, com rótulos de recomendação e destilação de um professor que vê o texto completo;
• inferência: token IDs virtuais, cálculo compartilhado do histórico, CUDA Graph replay;
• hardware: uma GPU H100;
• throughput: cerca de 26 400 avaliações de candidatos por segundo;
• ganho de velocidade: aproximadamente 60 vezes em relação ao professor em vLLM com automatic prefix caching;
• qualidade: comparável à do modelo professor especialista.

O que torna a comparação interessante é que a referência não é uma execução ingênua, e sim o vLLM com prefix caching — ou seja, uma stack já otimizada. Mesmo assim, ela perde por uma ordem de grandeza, porque cacheia prefixos, mas não substitui os textos longos dos itens por vetores curtos.

Para equipes que constroem recomendações com LLMs, a conclusão é prática. Se o catálogo muda mais devagar do que o tráfego cresce (produtos, artigos, vídeos, anúncios), faz sentido converter as descrições antecipadamente em representações cacheáveis. Assim, a parte online se resume ao trabalho com o histórico do usuário, e o custo de ranquear um candidato cai várias vezes. Ao mesmo tempo, isso alivia a carga sobre o parque de GPUs: as mesmas requisições são atendidas com menos placas.

As limitações também são claras. O ganho depende da proporção de itens reutilizados e de quanto a representação comprimida preserva os detalhes. A qualidade declarada foi medida em benchmarks, em relação ao professor, e não em um teste A/B ao vivo com tráfego de produção. Ainda assim, o esquema em si — encoder offline, ranker online e um runtime de servidor feito sob medida — parece reproduzível: o código do projeto está publicado no GitHub, e é possível verificar a diferença de 60 vezes com dados próprios sem reescrever toda a infraestrutura.