RAG Agentique : le noyau CUDA révolutionne l'efficacité GPU

RAG Agentique : le noyau CUDA révolutionne l'efficacité GPU

GPU-Resident Top-K pour RAG Agentique

En maintenant la boucle de récupération sur le GPU, nous éliminons le coût de transfert PCIe et saturons pleinement la bande passante de la mémoire de l'appareil. Ce noyau de 343 lignes dédié à la récupération Top-K en CUDA, ainsi que l'oracle CPU et la suite de benchmarks, démontrent que le cycle de retour standard de RAG Agentique — qui consiste à faire rebondir les requêtes à travers le bus PCIe — est le tueur silencieux de votre pipeline. En gardant la recherche de similarité sur la mémoire de l'appareil, cette architecture atteint un gain de 8,6x par rapport aux bases de référence optimisées sur CPU, même sur une GTX 1080 vieille de 7 ans.

Ceci est la Partie 3 de la série « Inference Agentique de Qualité Production ». Chaque partie élimine un type de travail redondant dans un pipeline LLM agentique. La Partie 1 a supprimé le pré-remplissage redondant. La Partie 2 a éliminé l'attente redondante — comment plusieurs micro-agents partagent un GPU par découpage temporel. La Partie 3 (cet article) maintient la récupération RAG sur le GPU avec un noyau CUDA Top-K personnalisé. La Partie 4 persiste l'état de l'agent à travers les transferts afin que le prochain agent n'ait jamais le problème de démarrage à froid.

Le problème

Dans RAG agentique, chaque appel d'outil nécessitant un contexte déclenche une recherche de similarité. Un pipeline par défaut envoie l'embedding de la requête du GPU vers Python, laisse le CPU évaluer N lignes du corpus et choisir les meilleurs K, puis renvoie la réponse. Ce cycle de retour est le coût silencieux. Le calcul est correct ; le voyage en est le prix. Nous savons tous que le voyage n'est jamais bon marché, peu importe où vous voulez aller (jeu de mots intentionnel !)

La solution simple

Téléchargez le corpus dans la VRAM une fois, puis maintenez le scoring de similarité, la sélection Top-K et l'étape de fusion sur l'appareil. Seul l'embedding par requête (D flottants) et les K résultats traversent le PCIe.

Les résultats

Sur la même GTX 1080 utilisée dans les Parties 1 et 2, le chemin résident GPU exécute le saut de récupération jusqu'à 8,57x plus vite qu'une base de référence brute-force sur CPU. À K=8, il remporte toutes les 15 configurations de balayage (N ∈ {10k, 50k, 100k, 500k, 1M}, D ∈ {384, 768, 1024}) avec des gains allant de 2,43x à 8,57x. À K=32, il gagne sur 13 des 15 configurations, atteignant un pic à 7,76x. À K=100 — où le sélecteur V1 reste intentionnellement simple — le CPU gagne sur 14 des 15 configurations. Cette dernière phrase est la partie honnête (Eh bien, même si j'avais menti, vous auriez facilement pu le remarquer).

Le point clé

Les gains ne sont pas des gains de « noyau magique ». Ce sont des gains de « nous avons arrêté d'envoyer le corpus vers la RAM hôte sans raison ». C'est également exactement le type de décision « mesurer de nombreux candidats, rapporter uniquement les meilleurs K au consommateur » qu'une station de base 5G et votre téléphone prennent toutes les quelques millisecondes depuis que le retour CSI est devenu une réalité.

Résumé

Le RAG agentique par défaut traite le GPU comme une boîte de service et la récupération comme une préoccupation Python. Chaque appel d'outil envoie l'embedding de requête D→H, permet au CPU de calculer N produits scalaires, de trier les candidats, de choisir les K meilleurs, et d'envoyer les indices et scores H→D. Pour un agent qui appelle un magasin vectoriel dix fois par étape de raisonnement, ce cycle de retour est le coût dominant — ni le modèle, ni l'embedding, c'est le voyage. CUDA-TopK-Retrieval garde le corpus sur l'appareil, exécute le scoring + le Top-K partiel par bloc + une fusion multi-voies entièrement sur le GPU, et expose une petite API d'orchestrateur en C++ (upload_corpus_rowmajor une fois, search_resident par requête). Les octets touchant l'hôte par requête se réduisent à un embedding de longueur D en amont et 2K résultats en aval. Sur une GTX 1080, à travers un balayage de 45 configurations, le chemin résident GPU bat la base de référence de cycle de retour CPU sur toutes les 15 configurations K=8 (de 2,43x à 8,57x, atteignant un pic à N=1M, D=1024) et sur 13 des 15 configurations K=32 (les deux pertes se produisent aux plus petites N=10k pour D=384 et D=768, où le cycle de retour lui-même est déjà bon marché ; les gains K=32 pour de grands N grimpent à 7,76x). À K=100, le noyau V1 reste délibérément simple — tri à bulles à voie unique par bloc avec une fusion sérielle — et le CPU gagne sur 14 des 15 configurations ; ce plafond est le punchline honnête de l'article et une mise en place propre pour la Partie 4.

Modèle mental de l'architecture

agent.embed(query) → cudaMemcpy H→D (D flottants) → row_dot_scores_kernel → partial_topk_block_kernel (P blocs) → merge_partial_topk_kernel → cudaMemcpy D→H (K indices + K scores)

Vue d'ensemble de la récupération CUDA TopK

1. Une confession : chaque étape RAG dans votre agent est un petit voyage PCIe

Dans la Partie 2 de cette série, nous avons réussi à isoler la boucle d'inférence de notre agent LLM, maintenant la génération de tokens rapide et efficace sur l'appareil. Nous avons conçu un système qui évite les blocages. Mais dès que nous donnons à cet agent un outil pour rechercher une base de connaissances externe — le cœur de tout pipeline de Récupération-Augmentée Génération (RAG) — nous détruisons silencieusement toute cette performance durement acquise et nous frappons un mur. Si vous avez déjà connecté un pipeline « agentique » à un magasin vectoriel via un récupérateur Python, voici ce qui se passe réellement à chaque appel d'outil (avec un peu de dramatisation intentionnelle) :

• Vous : « Agent, trouve-moi les cinq morceaux les plus pertinents pour ‘comment puis-je réclamer une déduction sous la section 80C ?’ »
• Agent : « Bien sûr. Embedding la requête sur le GPU. ✅ »
• Agent : « Maintenant, en renvoyant l'embedding de la requête vers l'hôte. »
• (cudaMemcpy D→H, ~1 024 flottants) Récupérateur Python : « Compris. Boucle NumPy. Produit scalaire N fois. argpartition. Top-5. »
• (Le CPU évalue des centaines de milliers de lignes de corpus, une ligne à la fois, pendant qu'un GPU de 9 TFLOP regarde) Récupérateur Python : « Terminé. Voici les indices et les scores. »
• Agent : « Cool. Je les renvoie maintenant au GPU. »
• (cudaMemcpy H→D, 10 nombres) Agent : « Prêt. Quelle était la question déjà ? »

L'agent dispose d'un GPU parfaitement fonctionnel. Le corpus est assis dans 4 Go de la VRAM. L'embedding de la requête était déjà sur le GPU — nous venons de le générer là. Et ensuite, à chaque saut de récupération, nous renvoyons la requête vers l'hôte, effectuons une similarité brute-force dans NumPy / FAISS sur CPU / une boucle écrite à la main, et renvoyons la réponse.

Conclusion

Le compteur d'utilité de votre GPU : passe la plupart de l'étape de récupération inactif. Votre bus PCIe : reçoit un entraînement qu'il n'a pas signé. La latence d'appel d'outil de votre agent : dominée par quelque chose qui n'est ni le modèle ni l'embedding. C'est la blague.

C'est aussi le secret sale de chaque démo RAG agentique qui évolue au-delà de la phase « dix morceaux en mémoire ». Le saut de récupération rebondit à chaque fois sur le GPU et revient, et plus le corpus est grand, plus le coût est élevé. Sur un million de lignes d'embeddings de 1024 dimensions, le cycle de retour seul — pas même le scoring, oui, juste le cycle de retour — consomme la majeure partie du budget de l'étape de récupération elle-même.

CUDA-TopK-Retrieval est ce qui se passe lorsque vous décidez que le cycle de retour est optionnel et que vous préférez écrire 343 lignes de CUDA plutôt que de laisser l'agent passer ses vacances à travers la RAM hôte chaque fois qu'il souhaite un voisin.