DuoLM acelera 60 veces las recomendaciones con LLM: 26 400 puntuaciones por segundo en un solo H100

Los sistemas de recomendación basados en grandes modelos de lenguaje chocan con un problema de aritmética. Para puntuar cientos de candidatos de un solo usuario hay que pasar por el modelo los textos completos de las descripciones junto con el historial, y la capacidad de procesamiento de los servidores se agota rápido. Los autores de DuoLM (Jiang Wu, Yutong Song, Hongbo Wang, Guanghe Cao y Jeff Lei Liang) proponen eliminar por completo ese trabajo repetido. En una sola GPU H100, su sistema calcula unas 26 400 puntuaciones de candidatos por segundo. Es aproximadamente 60 veces más rápido que el modelo maestro desplegado en vLLM con automatic prefix caching, con una calidad de recomendación comparable.

Dos modelos en lugar de un prompt largo

Un ranker LLM convencional recibe todo a la vez: el texto del objeto, el historial del usuario y sus reacciones. Para cada par «usuario–candidato» hay que procesar el texto de nuevo, aunque la descripción de un producto o de un vídeo no dependa del usuario.

DuoLM divide la tarea en dos partes. La primera es un codificador basado en un LLM, que lee la descripción del objeto y la comprime en una representación compacta. Este paso se hace offline, el resultado se guarda en caché y sirve para cualquier número de usuarios. La segunda es un ranker personalizado, también un LLM. Recibe las representaciones ya preparadas de los candidatos, el historial del usuario y su retroalimentación, y emite la recomendación.

Ambos modelos se entrenan de forma conjunta, end to end, con dos señales: las etiquetas de recomendación y la destilación desde un «experto», un modelo maestro que ve el texto completo. El codificador aprende a comprimir las descripciones de modo que la pérdida de información no perjudique al ranking final, y el ranker aprende a trabajar con la entrada comprimida.

Runtime: tokens virtuales y CUDA Graphs

Un modelo que en teoría ahorra cómputo puede perder en la práctica toda la ventaja por culpa de la sobrecarga. Por eso los autores describen no solo la arquitectura, sino también la parte de servidor, que funciona así:

• las representaciones de los objetos se almacenan directamente en la GPU y llegan al modelo mediante token ID virtuales: el ranker accede a los embeddings igual que a los tokens normales, sin copias innecesarias;
• varios candidatos de una misma solicitud comparten el cálculo del historial del usuario: su prefijo se calcula una sola vez, y no una por candidato;
• CUDA Graph replay reduce la sobrecarga del lanzamiento de kernels, algo importante cuando los propios cálculos son cortos.

En conjunto, el modelo y el runtime recortan el trabajo repetido en cada etapa del pipeline de recomendación.

Qué aportan 26 400 puntuaciones por segundo

Parámetros principales:

• arquitectura: un codificador LLM para representaciones compactas de los objetos y un ranker LLM personalizado;
• entrenamiento: end to end, con etiquetas de recomendación y destilación desde un modelo maestro con texto completo;
• inferencia: token ID virtuales, cálculo compartido del historial, CUDA Graph replay;
• hardware: una GPU H100;
• rendimiento: unas 26 400 puntuaciones de candidatos por segundo;
• aceleración: aproximadamente 60 veces respecto al modelo maestro en vLLM con automatic prefix caching;
• calidad: comparable a la del modelo maestro experto.

La comparación resulta interesante porque la referencia no es un despliegue ingenuo, sino vLLM con prefix caching, es decir, una pila ya optimizada. Incluso esta pierde por un orden de magnitud, porque almacena prefijos en caché pero no sustituye los textos largos de los objetos por vectores cortos.

Para los equipos que construyen recomendaciones con LLM, la conclusión es práctica. Si el catálogo cambia más despacio de lo que crece el tráfico (productos, artículos, vídeos, anuncios), tiene sentido convertir las descripciones en representaciones cacheables de antemano. Así, la parte online se reduce al trabajo con el historial del usuario, y el coste de puntuar cada candidato cae en un factor múltiple. A la vez, disminuye la carga sobre el parque de GPU: las mismas solicitudes se atienden con menos tarjetas.

Las limitaciones también están claras. La ganancia depende de la proporción de objetos que se reutilizan y de cuántos detalles conserve la representación comprimida. La calidad declarada se midió en benchmarks frente al modelo maestro, y no en un test A/B real con tráfico de producción. Aun así, el esquema de «codificador offline, ranker online y un runtime de servidor adaptado» parece reproducible: el código del proyecto está publicado en GitHub, y la diferencia de 60 veces puede comprobarse con datos propios sin reescribir toda la infraestructura.