Xiaohongshu accélère l'indexeur d'attention sparse : DoSA divise par deux le TTFT

Le réseau social chinois Xiaohongshu (RedNote) s'est attaqué au goulot d'étranglement qui apparaît une fois l'attention sparse déployée. L'équipe Dots a mis au point la méthode DoSA : lors des tests, elle a filtré en amont environ 97% des candidats de l'indexeur, sans modifier le Top-K final et, selon le titre de la publication de Jiqizhixin, elle a divisé par deux la latence du premier token (TTFT) sur un contexte d'environ 1M tokens.

Où se cache le goulot d'étranglement

L'attention sparse réduit le calcul de la façon suivante : chaque requête ne regarde pas tous les tokens précédents, mais seulement les K plus pertinents. Un module léger distinct, l'indexeur, les sélectionne. Il évalue chaque paire « requête — token » et retient les meilleures. L'attention principale devient alors peu coûteuse, mais l'indexeur continue de parcourir tout le contexte. Son coût croît de façon quadratique avec la longueur de la séquence, et à un million de tokens, c'est lui qui finit par dicter le temps de traitement du prompt. Cette architecture est notamment utilisée par les modèles de la famille DeepSeek V3.2, avec leur indexeur « éclair » (lightning indexer).

C'est sur le premier token que le problème se remarque le plus. Pendant la phase de prefill, l'indexeur doit parcourir l'intégralité du long prompt, et l'utilisateur attend sa réponse plus longtemps qu'il ne le voudrait.

Comment fonctionne DoSA

Le texte intégral de l'article dont nous disposons est tronqué ; nous rapportons donc les détails d'implémentation d'après la description des auteurs. DoSA calcule pour les candidats une borne supérieure et une borne inférieure du score. Cette opération est peu coûteuse comparée au calcul exact. La logique de ce filtrage est simple : si la borne supérieure d'un candidat est inférieure à une borne inférieure qui garantit déjà une place parmi les K premiers, ce candidat n'entrera pas dans le Top-K. Inutile alors de calculer son score exact.

La propriété essentielle est que la méthode n'approxime pas le résultat : elle produit le même ensemble de tokens qu'un parcours exhaustif. La formule « 提速不降智 » (« plus rapide sans perte d'intelligence ») est donc ici pertinente : la qualité du modèle ne devrait pas dépendre de l'accélération, puisque la sélection des tokens ne change pas.

Ce que l'on sait des tests

• Environ 97% des candidats ont été écartés avant même le calcul exact des scores.
• Le résultat du Top-K coïncide avec celui de l'algorithme d'origine.
• Le contexte utilisé lors des tests était d'environ 1M tokens.
• La latence du premier token a été environ divisée par deux (d'après le titre de la publication).

Plusieurs données manquent dans le fragment disponible : le nom du modèle (le texte s'interrompt sur « Dots3… »), le matériel, la taille de batch, les valeurs absolues de latence et la répartition du gain entre les différentes étapes. Le chiffre « divisée par deux » correspond à une configuration précise, et on ne peut pas le transposer à d'autres stacks sans vérification. La part de candidats filtrés dépend vraisemblablement des données : plus la distribution des scores est marquée, plus les bornes sont efficaces.

Côté pratique

Pour les équipes qui servent des modèles à contexte long et à attention sparse, DoSA présente un intérêt : il accélère l'inférence sans réentraînement et sans risque de modifier le comportement du modèle. Comme la sélection des tokens reste la même, les tests de régression de qualité devraient passer sans changement. C'est un argument de poids pour la production, où tout écart dans les sorties exige une vérification à part.

La première chose à faire est de mesurer la part du temps de prefill que représente l'indexeur dans votre stack. Si elle est significative entre 128K et 1M tokens, la méthode apportera un gain. Si l'essentiel du temps est absorbé par la partie MoE ou par les transferts de données entre GPU, l'effet sera plus modeste. Il convient aussi d'attendre un code ouvert ou un rapport technique : au niveau des kernels CUDA, le surcoût du calcul des bornes peut changer sensiblement le bilan final.

Pour Xiaohongshu elle-même, c'est aussi une question d'économie. Plus le traitement des longs prompts coûte peu, plus il est facile de maintenir dans le produit des scénarios à grand contexte : recherche dans les fils, analyse de documents, chaînes d'agents.