• Estamos apresentando o SilverTorch, uma reimaginação dos sistemas de recomendação que unifica todos os componentes de recuperação de conteúdo gerado pelo usuário sob uma arquitetura unificada.
• Programas SilverTorch rendimento até 23,7x maior em comparação com as abordagens de última geração. Ele também mostra 20,9x mais eficiência de custo de computação em comparação com uma solução baseada em CPU, ao mesmo tempo que melhora a precisão.
• Nosso artigo de pesquisa, “SilverTorch: Um sistema unificado baseado em modelo para democratizar recomendações em larga escala sobre GPUs,”aceito no full paper track no SIGIR 2026, contém detalhes técnicos completos.

---

O sistema de recuperação dentro dos sistemas de recomendação do setor consiste em microsserviços costurados, com redes neurais integradas inconsistentemente. Nossa recomendação pode ser dimensionada para atender pessoas em diversas plataformas. A recuperação é responsável por restringir milhões de peças de conteúdo (por exemplo, bobinas e fotos) até milhares antes de passá-los para sistemas de classificação, tudo em menos de 100 milissegundos.

No entanto, o design baseado em microsserviços tinha fortes restrições à complexidade do modelo e ao número de candidatos avaliados, em última análise, criando um limite para a qualidade das recomendações que as pessoas em nossas plataformas veem.

Para romper esse teto, reinventamos totalmente nosso ecossistema de recuperação em um sistema unificado baseado em modelo – SilverTorch.

SilverTorch opera sob um novo paradigma que chamamos Índice como modelo. Construímos nosso sistema de recuperação como uma única rede neural e agora expressamos diferentes microsserviços como módulos modelo dentro desta rede neural integrada. Em Índice como modelo, os índices de itens anteriores baseados em microsserviços usados ​​para recuperação tornam-se um tensor dentro do modelo. Quando um usuário abre seu aplicativo, uma solicitação flui através de um modelo SilverTorch, completa todas as funções críticas de recuperação (pesquisando itens semelhantes aos interesses do usuário, filtragem por elegibilidade, reclassificação e pontuação da probabilidade de engajamento em relação a diversas ações de engajamento do usuário), e retorna uma lista de candidatos a conteúdo de alta qualidade para classificação. Este novo design nos permite efetivamente aumentar a complexidade da modelagem e o número de candidatos avaliados sem quebrar a barra abaixo de 100 milissegundos.

SilverTorch makes retrieval significantly more efficient, funciona em escala, e permite melhores recomendações.

• Maior rendimento, menor custo total de propriedade (TCO). Em uma avaliação ponta a ponta de 80 milhões de itens, SilverTorch atendeu 23,7 vezes mais solicitações por segundo do que uma forte linha de base multisserviço tradicional construída na mesma arquitetura de modelo, ao mesmo tempo que melhora a eficiência estimada do TCO em 20,9×.
• Comprovado em escala. Os resultados mostram que o SilverTorch pode ser dimensionado para uma família de aplicativos como o principal sistema de recuperação por trás do feed e do conteúdo de vídeo que as pessoas veem.
• Melhores recomendações. Tornando prática a reclassificação neural e a pontuação multitarefa dentro de orçamentos de latência apertados, SilverTorch permitiu consistentemente melhorias na qualidade de recuperação que seriam impraticáveis ​​em uma arquitetura de microsserviços.

Mudando de malha de microsserviços para uma rede neural integrada

O paradigma de microsserviço que substituímos

A recuperação de recomendação tradicional é construída como uma malha de microsserviços. Quando um usuário abre uma plataforma de mídia social, a solicitação atinge um orquestrador, que se espalha para um serviço modelo de torre de usuário (que calcula uma representação vetorial dos interesses do usuário, chamada de “incorporação de usuário”), um serviço de recuperação combinado (que encontra e filtra itens candidatos com base na semelhança com o vetor do usuário e regras de elegibilidade, como idioma e geografia), e um serviço de pontuação (que classifica os sobreviventes). O orquestrador mescla os resultados e os entrega downstream. Cada serviço tem sua própria base de código, muitas vezes em uma linguagem de programação diferente, com seu próprio ciclo de vida de implantação.

Isso funcionou bem na era da CPU. Mas à medida que os sistemas de recuperação cresceram em escala e sofisticação, três problemas compostos em limites estruturais que nenhuma otimização em nível de componente pode resolver:

• Latência perdida na movimentação de dados. Cada salto entre serviços custa tempo de ida e volta da rede e sobrecarga de serialização, consumindo nosso orçamento de recuperação de menos de 100 milissegundos que deveria financiar a computação real. E porque a filtragem, procurar, e a pontuação são projetadas de forma independente, eles não podem ser otimizados em conjunto.
• Inconsistência de versão. O modelo da torre do usuário, o índice do item, e as regras de filtragem são atualizadas em sua própria cadência. Quando o modelo do usuário envia a v2, mas o índice do item ainda está na v1, o sistema consulta embeddings v1 com representações de usuário v2 – criando lacunas de qualidade que nenhuma classificação downstream pode recuperar.
• Ambientes de desenvolvimento isolados. Aprendizado de máquina (AM) engenheiros escrevem PyTorch. Engenheiros de infraestrutura escrevem C++. Diferentes ciclos de lançamento, diferentes configurações de teste, diferentes modelos mentais. Cada melhoria na recuperação requer a tradução de uma ideia entre dois ambientes – semanas ou meses por ciclo.

Otimizações em nível de componente, como Faiss-GPU ajude tornando o microsserviço específico mais rápido, mas não resolvem os limites estruturais subjacentes. A arquitetura ainda é um sistema de serviços com artefatos entregues entre eles.

A mudança: Todos os componentes são módulos de modelo

SilverTorch repensa o paradigma desde o início. Em vez de projetar um sistema de microsserviços e inserir redes neurais nele, começamos com a rede neural e projetamos externamente. Chamamos este Índice como Modelo: Cada componente de recuperação – o índice do item, filtro de elegibilidade, camada de pontuação e torre do usuário – torna-se um tensor ou operador dentro de um único modelo PyTorch. Isso significa um artefato para implantar, um passe para frente para executar e uma fonte de verdade para o que está no sistema.

Dentro do modelo

Dentro desta única rede neural, diferentes regiões da rede lidam com trabalhos diferentes. Vizinho mais próximo aproximado (ANN) procurar regiões encontram itens mais semelhantes aos interesses do usuário sem verificar todos os itens do catálogo (um bibliotecário que organizou bem os livros não anda em todas as prateleiras). Filtragem de elegibilidade regiões verificam se cada candidato pode ser mostrado: linguagem certa, país certo, política de conteúdo correta. Reclassificação multitarefa regiões prevêem a probabilidade de múltiplas ações de engajamento (como, compartilhar, comentário) de uma vez, depois combine-os em um pontuação composta. Algumas regiões são escritas à mão por engenheiros; outros são treinados de ponta a ponta por meio de retropropagação. Da perspectiva do tempo de execução, todos eles são nn.Module – o bloco de construção padrão do PyTorch – e indistinguíveis uns dos outros.

O redesenho: Módulos Pure PyTorch para cada estágio

Como cada componente funcionava antes

Antes do SilverTorch, cada módulo no pipeline de recuperação de produção - pesquisa de RNA, filtragem de elegibilidade, reclassificação neural, pontuação composta – tinha uma implementação clássica bem conhecida, construído principalmente como serviços autônomos em C++.

Módulo	Implementação clássica	Onde corre
Pesquisa de RNA	FAISS	Versões de CPU e GPU
Filtragem de elegibilidade	Índice invertido	Versões de CPU e GPU
Reclassificação neural	Serviço independente de classificação em estágio inicial	Versões de CPU e GPU
Pontuação composta	Agregação baseada em regras	Apenas CPU

Essas implementações são maduras e testadas em batalha, mas cada um é um serviço independente com suas próprias estruturas de dados, memória, e modelo de execução. Podemos encadeá-los – execute ANN, em seguida, entregue sua saída para filtragem - mas não podemos implementar facilmente otimizações entre módulos como “escolha primeiro os clusters mais promissores, filtrar apenas dentro desses clusters, então marque apenas os sobreviventes.” Este nível de co-design requer módulos para compartilhar memória, um gráfico de execução, e uma etapa de compilação.

A decisão pura do PyTorch

Para permitir esse co-design, tomamos a decisão de que cada módulo seria reimplementado em PyTorch puro. Sob este paradigma:

• Todos os dados são expressos como tensores.
• Toda lógica é tensor-in, saída do tensor.
• Cada módulo é um nn.Module que está em conformidade com a interface padrão do PyTorch.
• Na hora da execução, os módulos de filtro de índice ANN e Bloom são indistinguíveis de um reclassificador de ML treinado - ambos são nn.Module, ambos recebem tensores e produzem tensores.

Com cada módulo como um nn.Module, a fronteira entre a engenharia de ML e a engenharia de infraestrutura se dissolve – elas vivem na mesma camada, composto livremente e otimizado em conjunto em um único script de treinamento PyTorch. E porque todo o sistema se reduz a um único modelo PyTorch, podemos nos beneficiar do trabalho mais amplo da indústria de IA para tornar os modelos PyTorch mais rápidos, como o próprio torch.compile do PyTorch, que reescreve automaticamente um modelo PyTorch em um código de kernel de GPU mais eficiente. Cada avanço nesse ecossistema melhora o desempenho de serviço do SilverTorch.

A decisão pura do PyTorch não significou pegar os componentes de recuperação da era da CPU e agrupá-los em nn.Module. Isso nos forçou a repensar as primitivas de recuperação em formas nativas da execução da GPU e do próprio gráfico do modelo. Filtro de índice Bloom e pesquisa de RNA Int8 fundida são dois exemplos. Em ambos os casos, o ganho não vem da portabilidade de um serviço antigo para o PyTorch, mas de redesenhar o algoritmo subjacente em torno do comportamento da memória GPU, layout tensor, e execução dentro do mesmo passe para frente. Este é o manual fundamental do SilverTorch: uma vez que os componentes de recuperação residem dentro de um modelo PyTorch, co-design torna-se possível, e esse co-design é o que desbloqueia os ganhos.

O filtro de índice Bloom é um exemplo de como o SilverTorch redesenha a recuperação para GPUs. Em sistemas tradicionais, a filtragem geralmente é tratada por um índice invertido, que é eficiente em CPUs, mas mais difícil de funcionar bem em GPUs. O problema é que a filtragem de recomendações muitas vezes precisa verificar muitos atributos de itens de uma só vez, como a linguagem, localização, ou regras de elegibilidade, e as listas de postagem também podem variar drasticamente em comprimento entre atributos e consultas, criando desequilíbrio de carga intra-warp e divergência de warp em GPUs. Threads atribuídos a listas curtas tornam-se inativos antecipadamente, enquanto o warp permanece ocupado até que as pistas que processam as listas mais longas sejam concluídas.

SilverTorch substitui isso por um índice Bloom armazenado diretamente dentro do modelo. Cada item recebe uma assinatura compacta quando é publicado, e no momento da entrega o modelo pode verificar rapidamente se um item corresponde à solicitação usando operações simples de bits. Isso transforma a filtragem no tipo de denso, GPUs de trabalho paralelo são boas em, e porque o resultado do filtro já está dentro do modelo, ele pode fluir diretamente para a pesquisa de RNA sem uma chamada de serviço separada.

A pesquisa Fused Int8 ANN segue a mesma ideia. Bibliotecas RNA de uso geral são construídas para encontrar itens próximos, mas os sistemas de recomendação precisam de mais do que uma pequena pesquisa no vizinho mais próximo. Muitas vezes, eles precisam retirar um grupo muito maior de candidatos para que os estágios posteriores possam tomar decisões mais relevantes..

SilverTorch reimplementa a pesquisa de RNA como parte do próprio modelo. Ele armazena incorporações de itens em um formato Int8 compacto, que reduz o uso de memória aproximadamente pela metade em comparação com o típico 16 pedaços, e executa a pesquisa com um kernel de GPU fundido. Isso reduz a movimentação de dados e torna o estágio de recuperação barato o suficiente para retornar muito mais candidatos, dando aos modelos downstream mais espaço para encontrar as melhores recomendações. Nossa pesquisa de RNA quantizada Int8 mostra perda de qualidade limitada em comparação à força bruta, ao mesmo tempo que melhora significativamente o desempenho do serviço. Ele libera espaço para classificar mais itens com camadas mais sofisticadas e melhora a precisão da recuperação de ponta a ponta, e o algoritmo suporta grandes contagens de top-k e sondagens; na prática, não observamos nenhuma perda de recuperação de recuperação com 64 sondas e top-2048.

Benefícios – O que aparece fora do sistema

SilverTorch proporciona impacto concreto em três dimensões: calcular eficiência de custos, qualidade da recomendação, e velocidade de engenharia.

Eficiência de custos computacionais

Movendo a pesquisa da RNA, filtragem de elegibilidade, e pontuação composta na GPU e combiná-los por meio do co-design do SilverTorch, atendemos muito mais solicitações por segundo na mesma máquina. Mais solicitações por segundo significam menos máquinas necessárias para a mesma carga de trabalho, e menos máquinas significa menor custo de computação por solicitação.

Abaixo está uma comparação de uma carga de trabalho de recuperação de produção de 80 milhões de itens, com tráfego de produção real reproduzido em cada sistema sob o mesmo orçamento de latência:

Métrica	CPU FAISS	GPU FAISS	SilverTorch
Eficiência de custo computacional vs.. Linha de base da CPU	linha de base	5.9×	20.9× (13.35× com reclassificação)
Máximo k superior	ilimitado (lento)	2,048	100s de milhares
Reclassificação neural	não suportado	não suportado	suportado
Pontuação multitarefa	não suportado	não suportado	suportado

A vantagem de custo por solicitação de 13,35× do SilverTorch é composta de diversas fontes: O kernel Int8 ANN fundido é 2,2-14,7× mais rápido que Faiss-GPU; o índice Bloom é 291-523× mais rápido que o índice invertido da CPU; o co-design sonda-e-filtro corta a computação do filtro em mais 30×. A quantização Int8 no gráfico do modelo reduz a memória pela metade em comparação com linhas de base de precisão total, aproveitando as instruções dp4a da GPU, sem perda mensurável de recall.

Qualidade da recomendação

SilverTorch melhora a qualidade da recomendação transformando a recuperação em um estágio de pré-classificação muito mais amplo e expressivo. Em sistemas tradicionais baseados em serviços, a recuperação geralmente é restrita a um conjunto de resultados de RNA relativamente estreito, pontuado principalmente por similaridade de incorporação simples, com modelagem de relevância mais rica adiada para classificação em estágio final.

SilverTorch desbloqueado headroom. Mantendo a pesquisa da RNA, filtragem, e pontuação dentro de um modelo, pode ampliar o funil substancialmente. Em vez de entregar apenas um pequeno conjunto de candidatos a jusante, pode trazer de uma a duas ordens de magnitude mais candidatos por meio de camadas adicionais de relevância aprendida antes da classificação final. Isso faz com que a recuperação contribua significativamente para a qualidade da recomendação, não apenas uma etapa de poda rápida.

Reclassificação neural. SilverTorch introduz uma camada de reclassificação baseada em rede neural que vai além da similaridade de produto escalar e aplica uma modelagem de interação usuário-item mais rica a um conjunto de candidatos muito maior. Essas camadas podem assumir a forma de perceptrons multicamadas, autoatenção empilhada, ou modelos de interação mais estruturados, como mistura de logits. Porque as representações de itens e recursos cruzados permanecem na memória da GPU e são executados dentro do mesmo modelo, SilverTorch pode se dar ao luxo de aplicar essas camadas de classificação mais sofisticadas no início do pipeline, muito mais candidatos do que os sistemas de recuperação convencionais normalmente podem.

Pontuação multitarefa. SilverTorch também torna a recuperação nativamente multiobjetiva. Uma camada de pontuação combina previsões para diferentes ações do usuário em uma única pontuação composta, então a recuperação não é mais otimizada em torno de um sinal de similaridade grosseira. Em vez de, pode avaliar um amplo conjunto de candidatos em relação a uma noção mais rica de envolvimento do usuário antes do início da classificação do estágio final. O resultado é um funil mais amplo com mais inteligência dentro dele – mais candidatos sobrevivem à recuperação precoce, e eles são selecionados por mais sofisticados, pontuação multiobjetivo antes de passar para a classificação final.

Velocidade de Engenharia

Por último, SilverTorch acelera a rapidez com que a equipe pode criar e enviar melhorias de recuperação. Porque todo o pipeline reside em uma base de código PyTorch, um engenheiro trabalhando em uma nova ideia de recuperação escreve PyTorch e apenas PyTorch. Não há mais necessidade de traduzir um algoritmo de um caderno de pesquisa em um serviço C++, coordenar com uma equipe de infraestrutura separada, e execute um ciclo de integração de várias semanas. O tempo necessário para construir e publicar uma nova inovação caiu de semanas para dias.

Engenharia para escala e frescor

SilverTorch foi projetado tendo em mente a escalabilidade e a atualização do índice para garantir que ele possa suportar um sistema de recomendação em grande escala e distribuir conteúdo recém-criado quase em tempo real.

Aumentar e expandir

Nossa estratégia é escalar primeiro. Aproveitamos ao máximo a GPU única de alto desempenho orquestrando cuidadosamente sua hierarquia de memória (SRAM no chip, HBM residente em GPU, hospedar DRAM, DRAM remota) então os dados ficam perto de onde são computados. Depois de maximizarmos uma única GPU, nós expandir dentro de um host, aproveitando as interconexões de alta largura de banda entre placas GPU na mesma máquina.

Quando a rede neural excede a capacidade de um único host, nós usamos fragmentação de documento: dividir o estoque de itens (vídeos, postagens, fotos) entre hosts, como dividir o catálogo de uma grande biblioteca entre filiais.

Para redes esparsas muito grandes dentro do modelo - incorporando tabelas que mapeiam cada item e cada recurso do usuário para um vetor aprendido - usamos TorchRec, Biblioteca do PyTorch para fragmentação de tabelas esparsas. TorchRec espalha essas tabelas pela HBM, DRAM host da GPU, e até mesmo DRAM de host de CPU remoto, dissociando o movimento esparso de dados da computação.

Frescura do índice

Com índice como módulo de modelo, manter a atualização do índice equivale a atualizar os pesos do modelo de uma rede neural em produção, em escala, sem colocar o modelo offline.

SilverTorch separa a atualização do ciclo completo de publicação do modelo atualizações de streaming. À medida que os parâmetros do modelo são atualizados com base no treinamento mais recente, publicamos periodicamente o modelo completo como um instantâneo completo. Entre publicações, um serviço de streaming contínuo lê sinais em tempo real – novos itens, recursos de engajamento atualizados, elegibilidade alterada - e aplica atualizações direcionadas aos tensores específicos no modelo na memória. As atualizações chegam sem interromper a veiculação e sem reimplantar o modelo.

O resultado aparece na atualidade do conteúdo recomendado. As postagens no mesmo dia agora representam uma parcela significativa das recomendações nas plataformas de mídia social em comparação com os sistemas anteriores.

A evolução do SilverTorch e o que vem a seguir

SilverTorch é uma jornada de um sistema de microsserviços com redes neurais integradas a uma recuperação de recomendação completa baseada em modelo. Duas coisas se destacam em retrospecto: A recuperação completa baseada em modelo é viável e eficiente em escala de produção — a arquitetura derruba a barreira entre infraestrutura e modelagem, e eles se tornam uma prática unificada. Também desbloqueia uma melhor experiência do usuário — recursos como pontuação multitarefa e reclassificação neural que os sistemas anteriores não conseguiam executar dentro do orçamento de latência.

O trabalho técnico passou por três etapas: Nós primeiro reproduzido cada módulo de recuperação de linha de base - RNA, filtragem, pontuação - em PyTorch. Esta etapa por si só rendeu benefícios de memória GPU de alta velocidade e redução de movimentos de dados. Nós então repensado cada módulo em um nativo do PyTorch, Maneira nativa da GPU. É daí que veio o filtro de índice Bloom e Int8 ANN fundido do SilverTorch, projetado para compor em vez de ficar sozinho. Finalmente, habilitamos a propagação retroativa para módulos escritos à mão selecionados para que possam ser treinado juntamente com o resto do modelo.

Olhando para o futuro

Index-as-Model é o paradigma certo para a próxima geração de sistemas de recomendação, e é amplamente adotado no Meta em diferentes aplicativos. À medida que os sistemas de recomendação incorporam cada vez mais grandes modelos de linguagem (LLMs) para entender a intenção do usuário e a semântica do conteúdo, A arquitetura do SilverTorch fornece um ponto de integração natural:

• Um LLM pode ser conectado ao SilverTorch como apenas mais um módulo – o sistema o trata de forma idêntica a qualquer outro componente.
• A geração de itens baseada em LLM e a filtragem do SilverTorch usam os mesmos padrões paralelos à GPU.
• O conhecimento do item pode ser atualizado em tempo real através da mesma infraestrutura de streaming.
• O LLM e a pontuação tradicional compartilham a mesma memória GPU — sem movimentação de dados entre serviços.

Resumidamente, SilverTorch nos permite integrar recursos LLM diretamente dentro do modelo de recuperação, em vez de orquestrá-los como um serviço separado que fica ao lado dele. Esse acoplamento mais rígido é o que eleva o teto do sistema para o que a recomendação baseada em LLM pode fazer em escala de produção.

Leia o artigo

Para mais detalhes técnicos, veja nosso artigo aceito como artigo de pesquisa completo no SIGIR 2026: “SilverTorch: Um sistema unificado baseado em modelo para democratizar recomendações em larga escala sobre GPUs.”

Agradecimentos

Gostaríamos de agradecer aos seguintes indivíduos e às nossas equipes parceiras da Meta por sua colaboração para dar vida a este sistema.

Ryan Chang, Yijie Deng, Fei Ding, Eric Dong, Dupla de fãs, Zheng Fang, Pawel Garbacki, Hui Geng, Kevin Greer, Max Gu, Ke Huang, Chirag Jain, Ana Jung, Érico Kim, Da Kuang, Xialu Li, Sam Lin, Ziqi Liu, Yiming Ma, Lei Mao, Xiaoheng Mao, Parque Pedro, Lanbo Ela, Sol Fangcheng, Jin Sun, Shuo Tang, Harry Tran, Alex Wang, Byron Wang, Jia Zhou Wang, Liang Wang, Indo Wang, Zhen Wang, Zhen Wei, Hong Wu, Peng Xia, Judy Xiang, Bi Xue, Lan Xue, Chao Yang, Shuguang Ye, Hongzhang Yin, Min Yu, Keke Zhai, QianqianZhang, Rui Zhang, e Yingjiao Zhao.

Rui Li, Qi Fan Wang, Shengzhi Wang, Yubo Wang, Yueming Wang, Jiaqi Zhai, Erheng Zhong, e a equipe de modelagem RecSys.

Xinyao Hu, Yanzun Huang, Rui Jian, Meu Ni, QunshuZhang, Yuting Zhang, Yanli Zhao, e a equipe da Fundação RecSys.

Bruce Deng, Congle Zhang, Luyi Guo, Min Li, Yang Liu, Kai Ren, GuoqiangJerry Chen, Yimin Tan, Hong Hao Wei, Li Yu, Lu Zheng, e a equipe do Facebook.

Caixa de carne, Xianjie Chen, Mingze Gao, Abhishek Kumar, Zheng Yu Su, Haotiano Wu, e a equipe do Instagram

Shujian Bu, Chenglin Lu, Rui Wang, e a equipe Threads.

Shiyan Deng, Lu Fang, Hongyi Jia, Xudong Ma, Lujia Zhang, e a equipe de infraestrutura de IA

Rongrong Hu, Shuyi Zheng, e a equipe Meta AI.