// Praxis & Anwendung 26.10.2026 · 09:05 Uhr 6 Min. Lesezeit

DuoLM verlagert Teile der Empfehlung in die Offline-Verarbeitung

Mindverse News

KI-gestützt erstellt 4 Quellen Originalmeldung: huggingface.co Arbeitsweise

KI-generierte Illustration: DuoLM verlagert Teile der Empfehlung in die Offline-Verarbeitung — KI-generierte Illustration

Das Wichtigste in Kürze

DuoLM kodiert Artikelinhalte vorab in kompakte Vektoren und kombiniert sie im laufenden Betrieb mit Nutzerhistorie und Feedback. [1][2]
Ein spezialisierter Laufzeitpfad soll Mehrfachberechnungen für Artikel und Nutzerhistorien reduzieren; dazu gehören virtuelle Token-IDs, geteilte KV-Caches und CUDA-Graph-Wiedergabe. [2][3]
Die Autoren berichten für Amazon Books und Video Games eine Qualität nahe der eines Full-Text-Lehrermodells; auf einer H100 seien rund 26.400 Kandidatenbewertungen pro Sekunde erreicht worden. [1][2][3]
Die Ergebnisse stammen aus Benchmarks mit zwei Produktkategorien und definierter Hardware. Sie belegen weder eine gleichwertige Leistung in beliebigen Einsatzfeldern noch einen Vorteil in einer produktiven Live-Umgebung. [3][4]

// Inhalt · 7 Abschnitte

Ein anderer Zuschnitt für LLM-Empfehlungen
Encoder und personalisierter Ranker
Vektoren im Speicher statt voller Eingaben
Gemeinsame Nutzerhistorie, getrennte Kandidatenzweige
Benchmarkwerte und Vergleichsmaßstab
Was die Messungen nicht belegen
Einordnung für Produkt- und Plattformteams
Quellen

Ein anderer Zuschnitt für LLM-Empfehlungen

Sprachmodelle können Produkt- oder Inhaltsbeschreibungen zusammen mit bisherigen Interaktionen und Nutzerfeedback auswerten. Wird für jeden Kandidaten der vollständige Text erneut in ein Modell eingespeist, wächst jedoch der Online-Rechenaufwand. Bei einer Anfrage mit vielen möglichen Treffern kann das den Durchsatz begrenzen. Zugleich enthalten mehrere Kandidatenbewertungen dieselbe Nutzerhistorie, sodass Teile der Verarbeitung wiederholt anfallen können. [1][2][3]

Das Forschungsteam hinter DuoLM setzt deshalb an zwei Stellen an: Ein Modell erstellt wiederverwendbare Repräsentationen für Artikel, ein zweites bewertet diese im Kontext eines Nutzers. Ergänzt wird die Architektur durch einen Laufzeitpfad, der wiederholte Arbeit innerhalb und zwischen Anfragen begrenzen soll. Die Arbeit ist auf arXiv als Preprint veröffentlicht; die Leistungswerte sind Ergebnisse der dort beschriebenen Experimente und keine unabhängige Bestätigung. [1][2]

Die Artikelkodierung wird nach dem Training vorab berechnet und kann nutzerübergreifend wiederverwendet werden. [2][3]
Die Rangfolge entsteht weiterhin kontextabhängig: Der Ranker berücksichtigt Nutzerhistorie und Feedback, wenn er einen Kandidaten bewertet. [2][3]

Encoder und personalisierter Ranker

Der Encoder verarbeitet den Text eines Artikels und verdichtet ihn zu einem Vektor. Im beschriebenen Verfahren dient dafür der letzte verborgene Zustand am Ende der Texteingabe. Eine kontinuierliche Schnittstelle überführt den Vektor in eine einzelne Eingabe für den Ranker; sie normalisiert und skaliert die Repräsentation passend zu den nativen Einbettungen des Ranker-Modells. Damit ersetzt ein kompakter Vektor die vollständige Artikelbeschreibung im späteren Ranking. [3]

Der Ranker erhält die geordnete Historie einer Person, einschließlich der zugehörigen Artikelrepräsentationen und Feedbacktexte, sowie den Vektor des zu bewertenden Kandidaten. Aus dem letzten Modellzustand wird über einen gemeinsamen linearen Kopf ein einzelner Score berechnet. Die Kandidaten werden damit bewertet, nicht autoregressiv als Textantwort generiert. [3]

Beide Modelle werden gemeinsam trainiert. Eine beobachtete Zielauswahl liefert direkte Empfehlungssignale; zusätzlich erhält das kompakte System eine Lehrersupervision von einem eingefrorenen Modell, das vollständige Texte verarbeitet. Dessen Kandidatenpräferenzen werden als Verteilung auf die möglichen Treffer übertragen. Die Autoren beschreiben damit einen Kompromiss: Die Repräsentation soll kleiner und wiederverwendbar sein, während der Ranker weiterhin auf Nutzersignale reagieren kann. [2][3]

Vektoren im Speicher statt voller Eingaben

Nach dem Training werden die Artikelvektoren laut Arbeit vorab berechnet und in einer GPU-residenten Tabelle abgelegt. Virtuelle Token-IDs dienen als Verweise auf diese Einträge: Der Dienst kann Artikelkennungen und Feedback übergeben, statt für jede Anfrage ganze Vektoren oder vollständige Artikeltexte zu transportieren. Die virtuellen IDs sind dabei ein Zugriffsmechanismus auf kontinuierliche Repräsentationen und keine vom Modell erzeugten semantischen Artikelcodes. [3][4]

Für den Rating-Benchmark gibt die Arbeit eine Reduktion der durchschnittlichen Request-Payloads um mehr als 90 Prozent gegenüber der Übertragung vollständiger Vektoren an. Das ist eine Messung der Eingabegröße in diesem Versuchsaufbau, keine Aussage über eine entsprechende Senkung der gesamten Netzwerklast, der Gesamtkosten oder der Latenz in einer Produktionsarchitektur. [3]

Die Wiederverwendung ist nicht kostenlos: Die Vektoren müssen zunächst berechnet und anschließend verfügbar gehalten werden. Als technische Analyse ergibt sich daraus eine Betriebsaufgabe, die bei häufig geänderten Inhalten besonders relevant wäre: Ein System müsste bestimmen, wann eine gespeicherte Repräsentation aktualisiert wird und welche Version für das Ranking gilt. Die begleitende Analyse der Arbeit nennt Versionierung, inkrementelle Aktualisierung und Speicherbudget ausdrücklich als Implementierungsfragen. [4]

Gemeinsame Nutzerhistorie, getrennte Kandidatenzweige

Neben den Artikelvektoren soll DuoLM auch Rechenarbeit innerhalb einer Anfrage wiederverwenden. Bei mehreren Kandidaten wird die Nutzerhistorie zunächst als gemeinsamer Präfix verarbeitet. Der Ranker kann dann den daraus entstehenden Key-Value-Cache für die einzelnen Kandidatenzweige nutzen, statt die Historie für jeden Treffer separat vollständig vorzubereiten. [2][3]

Die Kandidaten bleiben dabei unabhängig: Eine speziell strukturierte Aufmerksamkeitsmaske erlaubt jedem Kandidaten den Zugriff auf den gemeinsamen Präfix und auf den eigenen Zweig, nicht aber auf andere Kandidaten. Zusammen mit passenden Positionskennungen soll dies die Einzelbewertung erhalten, obwohl mehrere Kandidaten in einem Lauf verarbeitet werden. Die Arbeit implementiert diesen Multi-Item-Scoring-Pfad auf SGLang. [3]

Ergänzend setzen die Autoren CUDA Graphs ein. Die Technik erfasst GPU-Operationen und deren Abhängigkeiten, damit der Laufzeitpfad sie wiederholt abspielen kann und weniger Aufwand für CPU-seitige Planung sowie Kernelstarts anfällt. Die drei Optimierungen setzen an unterschiedlichen Stellen an: virtuelle IDs am Datenzugriff, der geteilte Präfix an der wiederholten Historienberechnung und Graph-Wiedergabe am Ausführungs-Overhead. [2][3]

Benchmarkwerte und Vergleichsmaßstab

Die Autoren berichten Experimente auf den Kategorien Amazon Books und Amazon Video Games. Beim NDCG@10 erreicht DuoLM für Books 0,5586, verglichen mit 0,5440 für das Full-Text-Lehrermodell. Für Video Games liegen die Werte bei 0,5298 beziehungsweise 0,5313. Das kompakte Modell übertrifft den Lehrer demnach im Books-Versuch leicht und liegt im Video-Games-Versuch knapp darunter. Diese Ergebnisse stützen eine vergleichbare Qualität in den geprüften Einstellungen, nicht eine verlustfreie Kompression für beliebige Inhalte. [3][4]

Für den Durchsatz nennt die arXiv-Zusammenfassung rund 26.400 Kandidatenbewertungen pro Sekunde auf einer einzelnen H100 und ungefähr den 60-fachen Durchsatz des Lehrermodells mit vLLM und automatischem Prefix-Caching. Der Volltext führt den Vergleich detaillierter aus: Er nennt bis zu 60,1-mal gegenüber dem mit vLLM und bis zu 109,9-mal gegenüber dem mit SGLang betriebenen Lehrer. Die Bezugsgröße ist die Zahl bewerteter Kandidaten, nicht die Zahl vollständig abgearbeiteter Nutzeranfragen. [1][2][3]

Die begleitende Auswertung nennt für einen Versuch mit 100 Kandidaten pro Anfrage außerdem eine p99-Latenz von ungefähr 537 Millisekunden bei hoher Nebenläufigkeit. Solche Werte sind nur zusammen mit Hardware, Auslastung, Kandidatenzahl und Vergleichsimplementierung aussagekräftig. Zudem lässt sich der gemeldete Vorteil nicht allein einer effizienteren Inferenz-Engine zuschreiben: Der Vergleich umfasst sowohl eine andere Modellrepräsentation als auch einen speziell angepassten Serving-Pfad. [4]

Was die Messungen nicht belegen

Die vorliegenden Resultate konzentrieren sich auf zwei Produktkategorien und eine einzelne H100 als angegebene Hardwarebasis. Die Quellen beschreiben keinen Online-Versuch mit realen Nutzern und belegen keine Ergebnisse für andere Arten von Inhalten, stark veränderliche Beiträge oder beliebig lange Diskussionen. Die Übertragbarkeit auf andere Kataloge, Datenverteilungen oder Serving-Konfigurationen bleibt damit offen. [3][4]

Auch die Aufgabenstellung ist wichtig: DuoLM bewertet Kandidaten, die dem System bereits vorliegen. Aus den berichteten Werten folgt deshalb nicht, dass das Verfahren selbst eine große Menge möglicher Inhalte effizient auffindet oder die vorgelagerte Kandidatensuche verbessert. Ebenso ist unabhängiges Scoring nicht automatisch eine Optimierung für Vielfalt oder für Wechselwirkungen zwischen den Elementen einer Gesamtliste. [3][4]

Für einen belastbaren B2B-Vergleich müssten Unternehmen die Bedingungen der eigenen Pipeline einbeziehen. Dazu gehören die Zahl der Kandidaten pro Anfrage, die Länge und Wiederverwendbarkeit der Nutzerhistorie sowie die Kosten für Vorberechnung und Aktualisierung der Artikelvektoren. Als Analyse folgt daraus, dass ein hoher Kandidatendurchsatz allein weder eine geringere Gesamtlatenz noch niedrigere Betriebskosten garantiert; dafür wären Messungen des vollständigen Anfragepfads nötig. [3][4]

Einordnung für Produkt- und Plattformteams

DuoLM adressiert einen konkreten Engpass: Bei textreichen Empfehlungssystemen kann die vollständige Verarbeitung jedes Kandidaten teuer sein, während Inhalte und Nutzerhistorien teilweise wiederverwendbar sind. Die Arbeit verbindet deshalb Modellkompression mit Änderungen am Serving, statt Durchsatz allein aus einer kleineren Modellberechnung abzuleiten. Die gemeldeten Messungen zeigen, dass diese Kombination in den untersuchten Benchmarks relevant sein kann. [1][2][3]

Für Produktteams wäre der Ansatz vor allem dort prüfenswert, wo eine Anfrage viele Kandidaten enthält und Artikeltexte zwischen Nutzern unverändert bleiben. Ein Pilot sollte nicht nur die Rankingqualität auf einer Gesamtmetrik betrachten, sondern auch lange oder neue Artikel sowie eng umrissene Präferenzgruppen prüfen. Das ist eine Analyse der Architektur: Je stärker eine einzelne Vektorrepräsentation relevante Textdetails zusammenfasst, desto wichtiger wird eine Validierung in den Zielsegmenten. [3][4]

Für Plattformenteams liegt der Prüfbedarf ebenso im Laufzeitpfad. Neben Kandidatendurchsatz sollten Anfrage-Durchsatz und hohe Perzentile der Latenz erfasst werden; Cache-Nutzung, Historienvorbereitung und GPU-Ausführung sollten getrennt ausgewertet werden. Diese Messgrößen erlauben erst, die in DuoLM behaupteten Einsparungen mit den Engpässen einer konkreten Umgebung abzugleichen. Die Arbeit liefert damit einen technischen Entwurf und positive Benchmarkresultate, aber noch keinen Nachweis eines universellen Produktionsvorteils. [3][4]

Quellen

[1] Paper page - DuoLM: Fast and Effective Personalized Recommendation with Language Models — https://huggingface.co/papers/2610.24481 (abgerufen am 2026-10-26)
[2] [2610.24481] DuoLM: Fast and Effective Personalized Recommendation with Language Models — https://arxiv.org/abs/2610.24481 (abgerufen am 2026-10-26)
[3] (PDF) DuoLM: Fast and Effective Personalized Recommendation with Language Models — https://www.researchgate.net/publication/416345971_DuoLM_Fast_and_Effective_Personalized_Recommendation_with_Language_Models (abgerufen am 2026-10-26)
[4] DuoLM: Fast and Effective Personalized Recommendation with Language Models — Deep dive | Paper Daily — https://paper-daily.com/en/deep-readings/2610.24481.html (abgerufen am 2026-10-26)