Édition Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Comment vérifier l’exécution sur GPU d’une réécriture d’UDF Spark

> Une démarche pratique pour tester une UDF Spark, choisir SQL, cuDF ou CUDA, repérer un repli vers CPU et mesurer le résultat dans un pipeline GPU.

By BIG CHANGE Editorial

Published: 2026-10-14T02:55:41.136Z
Updated: 2026-10-14T02:55:41.136Z
Canonical: https://bigchange.ai/blog/spark-udf-gpu-rewrite-verification-guide

![Conceptual charcoal illustration of a generic rackmount server with a tray pulled partly forward, showing four finned modules inside.](https://bigchange.ai/api/media/file/spark-gpu-server-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. Generic server hardware; no NVIDIA product, Spark interface or measured result is depicted.

Une fonction définie par l’utilisateur exécutée sur CPU peut interrompre une requête Apache Spark autrement accélérée par GPU. Le plugin cuDF ne peut généralement pas traduire une UDF arbitraire : il transforme les colonnes en lignes, exécute la fonction sur CPU, puis reconvertit le résultat en colonnes. [Le guide NVIDIA du 13 octobre](https://developer.nvidia.com/blog/rewrite-apache-spark-udfs-gpu-acceleration-ai-agents/) décrit des compétences agentiques pour réécrire une UDF en Spark SQL, en fonction colonne `RapidsUDF` ou en fonction `RapidsUDF` avec CUDA. Pour un ingénieur data, la question est de savoir si la réécriture produit les mêmes réponses, reste sur GPU dans le plan concerné et améliore le travail réel.

Ce guide repose sur la documentation. BIG CHANGE n’a pas exécuté ces compétences, testé une UDF ni mesuré une charge Spark.

## Le grand changement

- **Ce qui change :** NVIDIA a publié un flux agentique par étapes pour générer des tests d’UDF, convertir une fonction, évaluer la conversion, comparer les versions CPU et GPU et éventuellement optimiser une implémentation cuDF.
- **À qui cela s’adresse :** Aux ingénieurs qui disposent d’un pipeline Spark RAPIDS/cuDF compatible GPU et d’une UDF CPU précise qui l’interrompt.
- **À vérifier :** Des résultats identiques sur des cas limites représentatifs, un plan sans le repli CPU ciblé et des performances reproductibles au niveau du travail sur le matériel prévu.

## Avant de commencer

Sélectionnez une UDF que vous êtes autorisé à partager avec l’agent de programmation. Gardez les identifiants, lignes d’entrée sensibles et jeux de données propriétaires hors de l’invite, sauf autorisation pour l’agent et son environnement. Fournissez le code de l’UDF, son enregistrement et son appel, les schémas pertinents, le comportement attendu pour les valeurs nulles et les erreurs, ainsi qu’un petit jeu de test autorisé. Notez le plan et le temps du travail Spark actuel pour disposer d’une référence.

Le [README des compétences](https://github.com/NVIDIA/cudf-spark/tree/cb8150b7ee4b07863bb6b267f28885def24b177e/skills) constitue le point de départ versionné du flux. Il demande Maven et un JDK pour compiler les UDF, plus une pile Spark/RAPIDS/cuDF/CUDA compatible et un GPU. Consultez le [guide actuel de compatibilité du plugin](https://docs.nvidia.com/cudf-spark/latest/getting-started/overview.html) pour vérifier votre distribution Spark, version Scala, pilote, build CUDA et GPU avant toute installation. Un GPU cloud est une autre possibilité, avec facturation de l’instance et du stockage par le fournisseur. L’agent ou le modèle peut aussi coûter. Le README fournit un squelette de projet et des exemples, mais ne prouve ni la compatibilité ni les performances de votre cluster.

## Réécrire et vérifier une fonction

1. **Fixez d’abord le comportement d’origine.** Demandez à l’agent d’utiliser `udf-gen-test` sur l’UDF choisie, puis inspectez vous-même les tests générés. Ajoutez des cas du contrat : valeurs nulles, chaînes ou collections vides, entrées mal formées, limites, précision numérique, ordre et erreurs, selon le cas. Exécutez l’UDF d’origine sur ces cas. Le résultat attendu est une suite de tests de référence réussie, pas encore une réécriture. L’exemple NVIDIA de fonction de température renvoie explicitement null pour une entrée nulle ; sa réécriture SQL n’est utile que si ce comportement tient aussi avec vos types et paramètres Spark.
2. **Choisissez la cible prise en charge la plus simple.** Pour une logique exprimable en Spark SQL ou DataFrame, demandez `udf-convert-to-sql`. Cela expose l’expression au planificateur Spark et peut permettre au plugin de remplacer certaines opérations par leurs équivalents GPU. Si SQL n’exprime pas proprement la logique requise, demandez `udf-convert-to-cudf` : son `RapidsUDF.evaluateColumnar` reçoit des vecteurs de colonnes GPU et compose des opérations cuDF. Réservez `udf-convert-to-cuda` aux logiques nécessitant un noyau personnalisé via JNI, lorsque le surcroît de réalisation et d’entretien se justifie. Ce sont des options à évaluer, pas une promesse que chaque opération tourne sur GPU.
3. **Examinez la conversion avant de l’accepter.** Comparez la version réécrite à l’originale et exécutez les deux sur les mêmes cas approuvés. Le dépôt propose aussi `udf-judge-conversion` pour une revue distincte des lacunes de test et erreurs de conversion. Vérifiez types, propagation des valeurs nulles, arrondis, exceptions, ordre et ressources. Pour cuDF, inspectez la durée de vie des colonnes et scalaires temporaires ; l’ [exemple Scala du tutoriel](https://developer.nvidia.com/blog/rewrite-apache-spark-udfs-gpu-acceleration-ai-agents/) utilise des ressources à portée limitée et renvoie la colonne résultat. Des tests générés réussis sont utiles, mais une personne doit juger s’ils couvrent le contrat.
4. **Inspectez le plan d’exécution.** Exécutez la requête modifiée avec le plugin cuDF et inspectez le plan ainsi que les diagnostics RAPIDS pour l’opérateur visé et les conversions proches. L’ [aperçu du plugin](https://docs.nvidia.com/cudf-spark/latest/getting-started/overview.html) NVIDIA indique que les opérations SQL non prises en charge repassent sur Spark CPU. Si l’UDF ou les opérateurs voisins restent sur CPU dans le plan, trouvez l’expression ou le type non pris en charge et revoyez la cible. Conservez les plans avant/après avec le résultat des tests. Une classe nommée `RapidsUDF` ne prouve pas que tout le travail reste sur GPU.
5. **Comparez le travail réellement prévu.** Utilisez `udf-benchmark` pour comparer les implémentations avec les mêmes entrées, taille de cluster, configuration et méthode de mesure. Notez la durée, la taille des entrées, l’équivalence des sorties et les ressources CPU/GPU. Répétez pour repérer les effets de démarrage, cache ou contention. Si une version cuDF correcte est lente, le dépôt propose `udf-optimize-cudf` pour la profiler et la réviser ; relancez les vérifications de justesse et de plan après chaque changement. Le résultat attendu est une comparaison reproductible, même si la réécriture perd.

## À quoi ressemble une réussite

La proposition est prête pour une revue de code ordinaire lorsque les sorties de l’UDF respectent son comportement documenté sur les cas approuvés, que le plan ne contient plus le repli CPU ciblé et qu’un benchmark représentatif montre un gain de bout en bout. Si un contrôle échoue, gardez l’originale, réduisez la réécriture à l’expression fautive et recommencez cette étape. Une différence de sens prime sur un benchmark plus rapide ; un plan inchangé ne prouve pas le parcours GPU visé.

NVIDIA rapporte un exemple de production où une UDF avec cuDF a réduit le temps opérateur de **274,55 à 12,78 heures** sur 600 milliards de lignes. Ce sont les temps opérateur rapportés par le fournisseur pour cette charge, pas une prévision pour une autre UDF ou un travail complet. L’affirmation générale de 22x doit se lire dans ce contexte. Capacité GPU, transferts, opérations non prises en charge, revue du code et frais cloud peuvent changer le résultat de votre pipeline.

## Sources et lectures complémentaires

- [Blog technique NVIDIA, 13 octobre 2026](https://developer.nvidia.com/blog/rewrite-apache-spark-udfs-gpu-acceleration-ai-agents/) : explique le repli CPU, les choix SQL/cuDF/CUDA, les quatre étapes et l’unique exemple de performance cité par l’entreprise. Les chiffres sont rapportés par le fournisseur.
- [Compétences NVIDIA cuDF Spark, révision épinglée](https://github.com/NVIDIA/cudf-spark/tree/cb8150b7ee4b07863bb6b267f28885def24b177e/skills) : point d’entrée versionné du squelette et des compétences. Notre méthode n’a pas pu accéder à la page GitHub épinglée ; les détails ont été recoupés avec le tutoriel et le README accessible sur la branche principale.
- [Présentation du plugin cuDF pour Apache Spark](https://docs.nvidia.com/cudf-spark/latest/getting-started/overview.html) : informations actuelles de configuration et compatibilité, avec la règle que les opérations non prises en charge s’exécutent sur Spark CPU. Vérifiez la compatibilité de la version avant l’implémentation.

## Sources

- [Blog technique NVIDIA, Comment réécrire les UDF Apache Spark pour l’accélération GPU avec des agents IA](https://developer.nvidia.com/blog/rewrite-apache-spark-udfs-gpu-acceleration-ai-agents/) — Tutoriel principal et exemple de charge rapporté par le fournisseur.
- [Compétences NVIDIA cuDF Spark, révision épinglée](https://github.com/NVIDIA/cudf-spark/tree/cb8150b7ee4b07863bb6b267f28885def24b177e/skills) — Révision épinglée attribuée ; récupération impossible à cause d’un échec du cache Web. Détails recoupés avec le tutoriel et le README principal accessible.
- [Compétences NVIDIA cuDF Spark, README principal](https://github.com/NVIDIA/cudf-spark/tree/main/skills) — README actuel et modifiable pour les noms des compétences et les prérequis.
- [Présentation du plugin cuDF pour Apache Spark](https://docs.nvidia.com/cudf-spark/latest/getting-started/overview.html) — Documentation actuelle sur le repli et la compatibilité ; vérifiez-la pour la version déployée.