• Wir stellen SilverTorch vor, eine Neuinterpretation von Empfehlungssystemen, die alle Abrufkomponenten für benutzergenerierte Inhalte in einer einheitlichen Architektur vereint.
• SilverTorch zeigt bis zu 23,7-mal höherer Durchsatz im Vergleich zu den State-of-the-Art-Ansätzen. Es zeigt außerdem eine 20,9-mal höhere Rechenkosteneffizienz im Vergleich zu einer CPU-basierten Lösung und verbessert gleichzeitig die Genauigkeit.
• Unser Forschungspapier, „SilverTorch: Ein einheitliches modellbasiertes System zur Demokratisierung groß angelegter Empfehlungen zu GPUs,”wird bei SIGIR in die vollständige Papierbahn aufgenommen 2026, enthält alle technischen Details.

---

Das Abrufsystem innerhalb der Empfehlungssysteme der Branche bestand aus zusammengefügten Mikrodiensten, mit uneinheitlich integrierten neuronalen Netzen. Unsere Empfehlung kann skaliert werden, um Menschen auf mehreren Plattformen zu bedienen. Der Abruf ist für die Eingrenzung von Millionen von Inhalten verantwortlich (z.B., Rollen und Fotos) bis zu Tausenden, bevor sie an Ranking-Systeme übergeben werden, alles in weniger als 100 Millisekunden.

Jedoch, Das auf Microservices basierende Design hatte strenge Einschränkungen hinsichtlich der Modellkomplexität und der Anzahl der bewerteten Kandidaten, Letztendlich wird die Qualität der Empfehlungen, die Menschen auf unseren Plattformen sehen, begrenzt.

Um diese Decke zu durchbrechen, Wir haben unser Retrieval-Ökosystem vollständig in ein einheitliches modellbasiertes System umgewandelt – SilverTorch.

SilverTorch arbeitet nach einem neuen Paradigma, das wir nennen Index als Vorbild. Wir haben unser Abrufsystem als einzelnes neuronales Netzwerk aufgebaut und drücken nun verschiedene Microservices als Modellmodule innerhalb dieses integrierten neuronalen Netzwerks aus. Unter Index als Modell werden frühere Microservice-basierte Elementindizes, die zum Abruf verwendet wurden, zu einem Tensor innerhalb des Modells. Wenn ein Benutzer seine App öffnet, Eine Anfrage durchläuft ein SilverTorch-Modell, führt alle wichtigen Abruffunktionen aus (Suche nach Artikeln, die den Interessen des Benutzers ähneln, Filtern nach Berechtigung, Neubewertung und Bewertung der Engagement-Wahrscheinlichkeit anhand mehrerer Benutzer-Engagement-Aktionen), und gibt eine Liste hochwertiger Content-Kandidaten zum Ranking zurück. Dieses neue Design ermöglicht es uns effektiv, die Komplexität der Modellierung und die Anzahl der bewerteten Kandidaten zu erhöhen, ohne die Grenze von unter 100 Millisekunden zu überschreiten.

SilverTorch makes retrieval significantly more efficient, Läuft im Maßstab, und ermöglicht bessere Empfehlungen.

• Höherer Durchsatz, geringere Gesamtbetriebskosten (Gesamtbetriebskosten). In einer End-to-End-Bewertung mit 80 Millionen Elementen, SilverTorch verarbeitete 23,7-mal mehr Anfragen pro Sekunde als eine starke traditionelle Multi-Service-Basislinie, die auf derselben Modellarchitektur aufbaute, bei gleichzeitiger Verbesserung der geschätzten TCO-Effizienz um das 20,9-fache.
• Im Maßstab bewährt. Die Ergebnisse zeigen, dass SilverTorch als wichtigstes Abrufsystem hinter den Feed- und Videoinhalten, die die Leute sehen, über eine Familie von Apps skalierbar ist.
• Bessere Empfehlungen. Durch die praktische Umsetzung neuronaler Reranking- und Multitasking-Bewertungen bei knappen Latenzbudgets, SilverTorch hat durchweg Verbesserungen der Abrufqualität ermöglicht, die unter einer Microservices-Architektur unpraktisch gewesen wären.

Übergang vom Microservice Mesh zu einem integrierten neuronalen Netzwerk

Das Microservice-Paradigma, das wir ersetzt haben

Der traditionelle Empfehlungsabruf ist als Netz aus Mikrodiensten aufgebaut. Wenn ein Benutzer eine Social-Media-Plattform öffnet, Die Anfrage trifft einen Orchestrator, der sich zu einem User-Tower-Modelldienst ausweitet (die eine Vektordarstellung der Interessen des Benutzers berechnet, sogenannte „Benutzereinbettung“), ein kombinierter Abholdienst (Hiermit werden Kandidatenelemente anhand ihrer Ähnlichkeit mit dem Benutzervektor und Eignungsregeln wie Sprache und Geografie gefunden und gefiltert), und ein Scoring-Service (Hier werden die Überlebenden eingestuft). Der Orchestrator führt die Ergebnisse zusammen und gibt sie weiter. Jeder Dienst verfügt über eine eigene Codebasis, oft in einer anderen Programmiersprache, mit eigenem Bereitstellungslebenszyklus.

Das funktionierte im CPU-Zeitalter gut. Doch mit der Zeit wurden die Retrieval-Systeme immer umfangreicher und ausgefeilter, Drei Probleme, die zu strukturellen Grenzen führen, die durch keine Optimierung auf Komponentenebene behoben werden können:

• Latenzverlust durch Datenbewegung. Jeder Sprung zwischen Diensten kostet Netzwerkumlaufzeit und Serialisierungsaufwand, Es verschlingt unser Abrufbudget von weniger als 100 Millisekunden, das eigentliche Berechnungen finanzieren sollte. Und weil Filterung, suchen, und Bewertung werden unabhängig voneinander entworfen, sie können nicht gemeinsam optimiert werden.
• Versionsinkonsistenz. Das User-Tower-Modell, der Artikelindex, und die Filterregeln werden jeweils in ihrem eigenen Rhythmus aktualisiert. Wenn das Benutzermodell Version 2 ausliefert, sich der Artikelindex jedoch immer noch auf Version 1 befindet, Das System fragt v1-Einbettungen mit v2-Benutzerdarstellungen ab – wodurch Qualitätslücken entstehen, die durch kein nachgelagertes Ranking behoben werden können.
• Isolierte Entwicklungsumgebungen. Maschinelles Lernen (ML) Ingenieure schreiben PyTorch. Infrastrukturingenieure schreiben C++. Verschiedene Veröffentlichungszyklen, verschiedene Testaufbauten, verschiedene mentale Modelle. Jede Verbesserung des Abrufs erfordert die Übersetzung einer Idee zwischen zwei Umgebungen – Wochen oder Monate pro Zyklus.

Optimierungen auf Komponentenebene wie Faiss-GPU Helfen Sie, indem Sie den jeweiligen Mikroservice schneller machen, aber sie lösen nicht die zugrunde liegenden strukturellen Grenzen. Die Architektur ist immer noch ein System von Diensten mit zwischen ihnen ausgetauschten Artefakten.

Der Wandel: Alle Komponenten sind Modellmodule

SilverTorch überdenkt das Paradigma von Grund auf. Anstatt ein Microservices-System zu entwerfen und darin neuronale Netze einzufügen, Wir beginnen mit dem neuronalen Netzwerk und entwerfen es nach außen. Wir nennen diesen Index Modell: Jede Abrufkomponente – der Artikelindex, Berechtigungsfilter, Bewertungsschicht und Benutzerturm – wird zu einem Tensor oder Operator innerhalb eines einzelnen PyTorch-Modells. Das bedeutet, dass ein Artefakt bereitgestellt werden muss, ein Vorwärtspass zum Laufen und eine Quelle der Wahrheit für das, was im System ist.

Im Inneren des Modells

Innerhalb dieses einzelnen neuronalen Netzwerks, Verschiedene Regionen des Netzwerks erledigen unterschiedliche Aufgaben. Ungefährer nächster Nachbar (ANN) suchen Regionen finden Artikel, die den Interessen des Benutzers am ähnlichsten sind, ohne jeden Artikel im Katalog zu überprüfen (Ein Bibliothekar, der die Bücher gut organisiert hat, geht nicht durch jedes Regal). Berechtigungsfilterung Regionen prüfen, ob jeder Kandidat angezeigt werden darf: richtige Sprache, richtiges Land, Richtige Inhaltsrichtlinie. Neuordnung mehrerer Aufgaben Regionen prognostizieren die Wahrscheinlichkeit mehrerer Engagement-Aktionen (wie, Aktie, Kommentar) auf einmal, Dann kombiniere sie zu einem zusammengesetzte Partitur. Einige Regionen werden von Ingenieuren handgeschrieben; andere werden durch Backpropagation Ende-zu-Ende trainiert. Aus Sicht der Laufzeit, Sie alle sind nn.Module – der Standardbaustein von PyTorch – und nicht voneinander zu unterscheiden.

Die Neugestaltung: Reine PyTorch-Module für jede Phase

Wie jede Komponente zuvor funktionierte

Vor SilverTorch, jedes Modul in der Produktionsabrufpipeline – ANN-Suche, Berechtigungsfilterung, neuronale Neuordnung, zusammengesetzte Bewertung – hatte eine bekannte klassische Implementierung, meist als eigenständige Dienste in C++ erstellt.

Modul	Klassische Umsetzung	Wo es läuft
ANN-Suche	FAISS	CPU- und GPU-Versionen
Berechtigungsfilterung	Invertierter Index	CPU- und GPU-Versionen
Neuronale Neuordnung	Eigenständiger Frühphasen-Ranking-Service	CPU- und GPU-Versionen
Zusammengesetzte Wertung	Regelbasierte Aggregation	Nur CPU

Diese Implementierungen sind ausgereift und kampferprobt, aber jeder ist ein eigenständiger Dienst mit seinen eigenen Datenstrukturen, Erinnerung, und Ausführungsmodell. Wir können sie verketten – ANN ausführen, Übergeben Sie dann die Ausgabe der Filterung – aber wir können sie nicht einfach implementieren Modulübergreifende Optimierungen wie „Wählen Sie zuerst die vielversprechendsten Cluster aus.“, Filtern Sie nur innerhalb dieser Cluster, dann werte nur die Überlebenden.“ Diese Ebene des Co-Designs erfordert, dass Module den Speicher gemeinsam nutzen, ein Ausführungsgraph, und einen Kompilierungsschritt.

Die reine PyTorch-Entscheidung

Um dieses Co-Design zu ermöglichen, Wir haben beschlossen, jedes Modul erneut zu implementieren reines PyTorch. Unter diesem Paradigma:

• Alle Daten werden als Tensoren ausgedrückt.
• Alle Logik ist Tensor-In, Tensor-Out.
• Jedes Modul ist ein nn.Module, das der Standardschnittstelle von PyTorch entspricht.
• Zur Ausführungszeit, Die ANN- und Bloom-Indexfiltermodule sind nicht von einem trainierten ML-Reranker zu unterscheiden – beide sind nn.Module, beide nehmen Tensoren auf und produzieren Tensoren.

Mit jedem Modul als nn.Module, Die Grenze zwischen ML-Engineering und Infrastruktur-Engineering löst sich auf – sie leben auf derselben Ebene, frei zusammengestellt und gemeinsam optimiert in einem einzigen PyTorch-Trainingsskript. Und weil sich das gesamte System auf ein einziges PyTorch-Modell reduziert, Wir können von der Arbeit der breiteren KI-Branche profitieren, PyTorch-Modelle schneller zu machen, wie PyTorchs eigene Torch.compile, die ein PyTorch-Modell automatisch in effizienteren GPU-Kernelcode umschreibt. Jeder Fortschritt in diesem Ökosystem verbessert die Bereitstellungsleistung von SilverTorch.

Die reine PyTorch-Entscheidung bedeutete nicht, dass Abrufkomponenten aus der CPU-Ära übernommen und in nn.Module verpackt wurden. Es zwang uns, Abrufprimitive in Formen zu überdenken, die für die GPU-Ausführung und den Modellgraphen selbst typisch sind. Bloom-Index-Filter und die Suche nach fusionierten Int8-ANNs sind zwei Beispiele. In beiden Fällen, Der Gewinn ergibt sich nicht aus der Portierung eines alten Dienstes in PyTorch, sondern durch die Neugestaltung des zugrunde liegenden Algorithmus rund um das GPU-Speicherverhalten, Tensor-Layout, und Ausführung innerhalb desselben Vorwärtsdurchlaufs. Das ist das grundlegende Spielbuch von SilverTorch: Sobald Abrufkomponenten in einem PyTorch-Modell leben, Mitgestaltung wird möglich, und dieses Co-Design ist es, das die Vorteile freisetzt.

Der Bloom-Indexfilter ist ein Beispiel dafür, wie SilverTorch den Abruf für GPUs neu gestaltet. In traditionellen Systemen, Die Filterung erfolgt normalerweise über einen invertierten Index, Dies ist auf CPUs effizient, auf GPUs jedoch schwieriger gut auszuführen. Das Problem besteht darin, dass bei der Empfehlungsfilterung häufig viele Artikelattribute gleichzeitig überprüft werden müssen, wie zum Beispiel Sprache, Standort, oder Zulassungsregeln, Außerdem kann die Länge von Posting-Listen je nach Attributen und Abfragen erheblich variieren, Dadurch entsteht ein Intra-Warp-Lastungleichgewicht und eine Warp-Divergenz auf GPUs. Threads, denen Shortlists zugewiesen wurden, werden frühzeitig inaktiv, während der Warp besetzt bleibt, bis die Spuren, die die längsten Listen verarbeiten, abgeschlossen sind.

SilverTorch ersetzt dies durch einen Bloom-Index, der direkt im Modell gespeichert wird. Jedes Element erhält bei der Veröffentlichung eine kompakte Signatur, und zum Zeitpunkt der Bereitstellung kann das Modell mithilfe einfacher Bitoperationen schnell prüfen, ob ein Element mit der Anforderung übereinstimmt. Dadurch wird die Filterung dichter, Parallel arbeiten GPUs gut, und weil das Filterergebnis bereits im Modell enthalten ist, Es kann ohne separaten Serviceaufruf direkt in die ANN-Suche einfließen.

Die Fused Int8 ANN-Suche folgt der gleichen Idee. Allzweck-ANN-Bibliotheken sind darauf ausgelegt, Objekte in der Nähe zu finden, Empfehlungssysteme benötigen jedoch mehr als eine kleine Suche nach dem nächsten Nachbarn. Sie müssen häufig einen viel größeren Kandidatenpool zurückziehen, damit spätere Phasen bessere Relevanzentscheidungen treffen können.

SilverTorch implementiert die ANN-Suche als Teil des Modells selbst neu. Es speichert Artikeleinbettungen im kompakten Int8-Format, Dadurch wird der Speicherverbrauch im Vergleich zum Normalverbrauch etwa halbiert 16 Bits, und führt die Suche mit einem fusionierten GPU-Kernel aus. Dies reduziert die Datenbewegung und macht die Abrufphase so kostengünstig, dass viel mehr Kandidaten zurückgegeben werden können, Geben Sie nachgelagerten Modellen mehr Raum, um die besten Empfehlungen zu finden. Unsere Int8-quantisierte ANN-Suche zeigt im Vergleich zu Brute-Force einen begrenzten Qualitätsverlust und verbessert gleichzeitig die Bereitstellungsleistung erheblich. Es gibt Spielraum für die Einstufung weiterer Elemente mit anspruchsvolleren Ebenen und verbessert die End-to-End-Abrufgenauigkeit, und der Algorithmus unterstützt große Top-K- und Sondenzahlen; in der Praxis, Wir beobachten keinen Retrieval-Recall-Verlust 64 Sonden und top-2048.

Vorteile – Was außerhalb des Systems angezeigt wird

SilverTorch liefert konkrete Wirkung in drei Dimensionen: Kosteneffizienz berechnen, Empfehlungsqualität, und technische Geschwindigkeit.

Berechnen Sie die Kosteneffizienz

Durch Verschieben der ANN-Suche, Berechtigungsfilterung, und zusammengesetztes Scoring auf der GPU und deren Kombination durch das Co-Design von SilverTorch, Wir bearbeiten weitaus mehr Anfragen pro Sekunde auf demselben Computer. Mehr Anfragen pro Sekunde bedeuten, dass weniger Maschinen für die gleiche Arbeitslast benötigt werden, und weniger Maschinen bedeuten geringere Rechenkosten pro Anfrage.

Nachfolgend finden Sie einen Vergleich der Produktionsabruf-Arbeitsbelastung von 80 Millionen Artikel, wobei der echte Produktionsverkehr auf jedem System mit dem gleichen Latenzbudget wiedergegeben wird:

Metrisch	FAISS-CPU	FAISS-GPU	SilverTorch
Rechenkosteneffizienz vs. CPU-Basislinie	Grundlinie	5.9×	20.9× (13.35× mit Neubewertung)
Maximaler Top-K	unbegrenzt (langsam)	2,048	100s von Tausenden
Neuronale Neuordnung	nicht unterstützt	nicht unterstützt	unterstützt
Multitasking-Bewertung	nicht unterstützt	nicht unterstützt	unterstützt

Der 13,35-fache Kosten-pro-Anfrage-Vorteil von SilverTorch ergibt sich aus mehreren Quellen: Der fusionierte Int8-ANN-Kernel ist 2,2-14,7-mal schneller als die Faiss-GPU; Der Bloom-Index ist 291-523-mal schneller als der CPU-invertierte Index; Das Probe-dann-Filter-Co-Design reduziert die Filterberechnung um das weitere 30-fache. Die Int8-Quantisierung im Modelldiagramm halbiert den Speicher im Vergleich zu Basislinien mit voller Genauigkeit, Nutzung der dp4a-Anweisungen der GPU, ohne messbaren Erinnerungsverlust.

Empfehlungsqualität

SilverTorch verbessert die Empfehlungsqualität, indem es den Abruf in eine viel breitere und ausdrucksstärkere Pre-Ranking-Phase verwandelt. In traditionellen servicebasierten Systemen, Der Abruf ist normalerweise auf einen relativ engen ANN-Ergebnissatz beschränkt, wird hauptsächlich durch einfache Einbettungsähnlichkeit bewertet, mit einer umfassenderen Relevanzmodellierung, die auf das späte Ranking verlagert wird.

SilverTorch hat die Kopffreiheit freigeschaltet. Indem Sie die ANN-Suche beibehalten, Filterung, und Scoring innerhalb eines Modells, es kann den Trichter erheblich erweitern. Anstatt nur eine kleine Gruppe von Kandidaten weiterzugeben, Es kann durch zusätzliche erlernte Relevanzebenen vor dem endgültigen Ranking ein bis zwei Größenordnungen mehr Kandidaten hervorbringen. Dadurch trägt der Abruf wesentlich zur Empfehlungsqualität bei, nicht nur ein schneller Schnittschritt.

Neuronale Neuordnung. SilverTorch führt eine auf einem neuronalen Netzwerk basierende Reranking-Schicht ein, die über die Skalarproduktähnlichkeit hinausgeht und eine umfassendere Benutzer-Element-Interaktionsmodellierung auf einen viel größeren Kandidatensatz anwendet. Diese Schichten können die Form von mehrschichtigen Perzeptronen annehmen, gestapelte Selbstaufmerksamkeit, oder strukturiertere Interaktionsmodelle wie eine Mischung aus Logits. Weil die Elementdarstellungen und Cross-Features im GPU-Speicher verbleiben und innerhalb desselben Modells ausgeführt werden, SilverTorch kann es sich leisten, diese anspruchsvolleren Ranking-Ebenen früher in der Pipeline anzuwenden, über weit mehr Kandidaten, als herkömmliche Retrieval-Systeme normalerweise können.

Multitasking-Bewertung. SilverTorch macht das Abrufen außerdem nativ multiobjektiv. Eine Bewertungsebene kombiniert Vorhersagen für verschiedene Benutzeraktionen in einer einzigen zusammengesetzten Bewertung, Daher erfolgt die Optimierung nicht mehr um ein grobes Ähnlichkeitssignal herum. Stattdessen, Es kann einen breiten Kandidatenpool anhand einer umfassenderen Vorstellung von Benutzerengagement bewerten, bevor das Ranking in der Spätphase beginnt. Das Ergebnis ist ein breiterer Trichter mit mehr Intelligenz darin – mehr Kandidaten überleben den frühen Abruf, und sie werden von anspruchsvolleren überprüft, Mehrzielbewertung vor der Weitergabe an die Endwertung.

Technische Geschwindigkeit

Schließlich, SilverTorch beschleunigt die Geschwindigkeit, mit der das Team Abrufverbesserungen entwickeln und versenden kann. Weil die gesamte Pipeline in einer PyTorch-Codebasis lebt, Ein Ingenieur, der an einer neuen Retrieval-Idee arbeitet, schreibt PyTorch und nur PyTorch. Es besteht keine Notwendigkeit mehr, einen Algorithmus aus einem Forschungsnotizbuch in einen C++-Dienst zu übersetzen, Koordination mit einem separaten Infrastrukturteam, und führen Sie einen mehrwöchigen Integrationszyklus durch. Der Zeitaufwand für die Erstellung und Veröffentlichung einer neuen Innovation sank von Wochen auf Tage.

Technik für Skalierung und Frische

SilverTorch wurde im Hinblick auf Skalierbarkeit und Indexaktualität entwickelt, um sicherzustellen, dass es ein umfangreiches Empfehlungssystem unterstützen und neu erstellte Inhalte nahezu in Echtzeit verteilen kann.

Hochskalieren und Herausskalieren

Unsere Strategie ist es erstmal hochskalieren. Wir holen das Beste aus der einzelnen Hochleistungs-GPU heraus, indem wir ihre Speicherhierarchie sorgfältig orchestrieren (On-Chip-SRAM, GPU-residentes HBM, Host-DRAM, Remote-DRAM) Die Daten befinden sich also in der Nähe des Ortes, an dem sie berechnet werden. Sobald wir eine einzelne GPU maximiert haben, Wir Skalierung innerhalb eines Hosts, Nutzen Sie die Vorteile von Verbindungen mit hoher Bandbreite zwischen GPU-Karten auf demselben Computer.

Wenn das neuronale Netzwerk die Kapazität eines einzelnen Hosts überschreitet, wir nutzen Dokumenten-Sharding: Teilen Sie den Artikelbestand auf (Videos, Beiträge, Fotos) über Hosts hinweg, als würde man den Katalog einer großen Bibliothek auf mehrere Zweigstellen aufteilen.

Für die sehr großen spärlichen Netzwerke innerhalb des Modells – Einbettungstabellen, die jedes Element und jedes Benutzermerkmal einem erlernten Vektor zuordnen – verwenden wir TorchRec, PyTorchs Bibliothek für Sparse-Table-Sharding. TorchRec verteilt diese Tabellen über HBM, GPU-Host-DRAM, und sogar Remote-CPU-Host-DRAM, Entkopplung der Bewegung spärlicher Daten von der Berechnung.

Index Frische

Mit Index als Modellmodul, Die Aufrechterhaltung der Indexaktualität entspricht der Aktualisierung der Modellgewichte eines neuronalen Netzwerks in der Produktion, im Maßstab, ohne das Modell offline zu nehmen.

SilverTorch entkoppelt die Aktualität vom gesamten Veröffentlichungszyklus des Modells Streaming-Updates. Da die Modellparameter basierend auf dem neuesten Training aktualisiert werden, Wir veröffentlichen das vollständige Modell regelmäßig als vollständigen Schnappschuss. Zwischen Veröffentlichungen, Ein kontinuierlicher Streaming-Dienst liest Echtzeitsignale – neue Elemente, aktualisierte Engagement-Funktionen, hat die Berechtigung geändert – und wendet gezielte Aktualisierungen vor Ort auf die spezifischen Tensoren im In-Memory-Modell an. Updates werden bereitgestellt, ohne die Bereitstellung zu unterbrechen und ohne dass das Modell erneut bereitgestellt werden muss.

Das Ergebnis zeigt sich in der Aktualität der empfohlenen Inhalte. Im Vergleich zu früheren Systemen machen Posts am selben Tag heute einen erheblichen Teil der Empfehlungen auf Social-Media-Plattformen aus.

Die Entwicklung von SilverTorch und was als nächstes kommt

SilverTorch ist eine Reise von einem System von Mikrodiensten mit integrierten neuronalen Netzen zu einem vollständig modellbasierten Empfehlungsabruf. Rückblickend fallen zwei Dinge auf: Der vollständige modellbasierte Abruf ist im Produktionsmaßstab realisierbar und effizient – Die Architektur durchbricht die Mauer zwischen Infrastruktur und Modellierung, und sie werden zu einer einheitlichen Praxis. Es ermöglicht auch eine bessere Benutzererfahrung – Funktionen wie Multi-Task-Scoring und neuronale Neubewertung, die frühere Systeme innerhalb des Latenzbudgets nicht ausführen konnten.

Die technischen Arbeiten durchliefen drei Phasen: Wir zuerst reproduziert jedes Baseline-Retrieval-Modul – ANN, Filterung, Bewertung – in PyTorch. Allein dieser Schritt brachte Vorteile durch einen Hochgeschwindigkeits-GPU-Speicher und eine Reduzierung der Datenbewegungen. Wir dann neu gedacht jedes Modul in einem PyTorch-nativen, GPU-nativ. Hierher kam der verschmolzene Int8 ANN- und Bloom-Indexfilter von SilverTorch, Entwickelt, um zu komponieren und nicht allein zu stehen. Endlich, Wir haben die Rückwärtsausbreitung für ausgewählte handgeschriebene Module aktiviert, damit dies möglich ist ausgebildet gemeinsam mit dem Rest des Modells.

Blick nach vorn

Index-as-Model ist das richtige Paradigma für die nächste Generation von Empfehlungssystemen, und es wird in Meta in verschiedenen Apps weit verbreitet. Da Empfehlungssysteme zunehmend große Sprachmodelle integrieren (LLMs) zum Verständnis der Benutzerabsicht und der Inhaltssemantik, Die Architektur von SilverTorch bietet einen natürlichen Integrationspunkt:

• Ein LLM kann wie ein weiteres Modul in SilverTorch eingesteckt werden – das System behandelt es genauso wie jede andere Komponente.
• Die LLM-basierte Elementgenerierung und die Filterung von SilverTorch verwenden dieselben GPU-parallelen Muster.
• Das Artikelwissen kann über dieselbe Streaming-Infrastruktur in Echtzeit aktualisiert werden.
• Das LLM und die herkömmliche Bewertung nutzen denselben GPU-Speicher – keine Datenverschiebung zwischen Diensten.

Zusamenfassend, Mit SilverTorch können wir LLM-Funktionen direkt in das Abrufmodell integrieren, anstatt sie als separaten Dienst zu orchestrieren, der daneben läuft. Diese engere Kopplung ist es, die die Systemobergrenze dafür anhebt, was LLM-basierte Empfehlungen im Produktionsmaßstab bewirken können.

Lesen Sie das Papier

Weitere technische Details, Sehen Sie, wie unsere Arbeit als vollständige Forschungsarbeit bei SIGIR akzeptiert wird 2026: „SilverTorch: Ein einheitliches modellbasiertes System zur Demokratisierung groß angelegter Empfehlungen zu GPUs.”

Danksagungen

Wir möchten den folgenden Personen und unseren Partnerteams in Meta für ihre Zusammenarbeit bei der Umsetzung dieses Systems danken.

Ryan Chang, Yijie Deng, Fei Ding, Eric Dong, Fan-Duo, Zheng Fang, Pawel Garbacki, Hui Geng, Kevin Greer, Max Gu, Ke Huang, Chirag Jain, Anna Jung, Eric Kim, Da Kuang, Xialu Li, Sam Lin, Ziqi Liu, Yiming Ma, Lei Mao, Xiaoheng Mao, Peter Park, Lanbo Sie, Fangcheng Sun, Jin Sun, Shuo Tang, Harry Tran, Alex Wang, Byron Wang, Jiazhou Wang, Liang Wang, Wenting Wang, Zhen Wang, Zheng Wei, Hong Wu, Peng Xia, Judy Xiang, Bi Xue, Lan Xue, Chao Yang, Shuguang Ye, Hongzhang Yin, Min Yu, Keke Zhai, Qianqian Zhang, Rui Zhang, und Yingjiao Zhao.

Rui Li, Qifan Wang, Shengzhi Wang, Yubo Wang, Yueming Wang, Jiaqi Zhai, Erheng Zhong, und das RecSys Modeling-Team.

Xinyao Hu, Yanzun Huang, Rui Jian, Mein Ni, Qunshu Zhang, Yuting Zhang, Yanli Zhao, und das Team der RecSys Foundation.

Bruce Deng, Congle Zhang, Luyi Guo, Min Li, Yang Liu, Kai Ren, Guoqiang Jerry Chen, Yimin Tan, Honghao Wei, Li Yu, Lu Zheng, und das Facebook-Team.

Fleischbehälter, Xianjie Chen, Mingze Gao, Abhishek Kumar, Zhengyu Su, Haotian Wu, und das Instagram-Team

Shujian Bu, Chenglin Lu, Rui Wang, und das Threads-Team.

Shiyan Deng, Lu Fang, Hongyi Jia, Xudong Ma, Lujia Zhang, und das AI Infrastructure-Team

Rongrong Hu, Shuyi Zheng, und das Meta AI-Team.