Créez des applications d’IA locales avec C++ et les exemples NVIDIA TensorRT RTX

Créez des applications d’IA locales avec C++ et les exemples NVIDIA TensorRT RTX

Exécuter des modèles d’IA sur votre propre machine est passé d’un passe-temps de niche à une véritable option d’ingénierie. Les GPU grand public et de station de travail disposent désormais d’assez de puissance de calcul pour servir de véritables charges de travail d’inférence, et la pile logicielle qui les entoure a mûri au point que « local » ne signifie plus « jouet ». Pour les développeurs qui veulent cette capacité dans une application native plutôt que dans un notebook Python, la combinaison de C++ et de NVIDIA TensorRT RTX est l’un des chemins les plus directs disponibles.

L’article du blog développeur NVIDIA Build Local AI Apps with C++ and NVIDIA TensorRT RTX Samples présente ce flux de travail : un runtime optimisé pour le matériel de classe RTX, plus un ensemble d’exemples qui montrent comment les pièces s’assemblent. Cet article développe ce point de départ en un guide pratique — ce que sont les exemples, ce dont vous avez besoin, comment installer et compiler, et comment passer d’un binaire de démonstration à quelque chose que vous pouvez livrer.

Une note sur la portée avant de commencer : les détails ci-dessous sont tirés de l’article du blog développeur NVIDIA référencé ci-dessus et du comportement général et documenté publiquement de la chaîne d’outils. Lorsqu’un chemin, une option ou un nom de paquet spécifique dépend de votre version du SDK ou de votre plateforme, cette dépendance est signalée plutôt que devinée.

Ce que les exemples TensorRT RTX vous apportent réellement

TensorRT RTX est un runtime destiné à l’inférence sur les GPU NVIDIA RTX. Les exemples qui l’accompagnent sont les implémentations de référence : de petits programmes ciblés qui démontrent la mécanique de chargement d’un modèle, de préparation à l’exécution, d’alimentation en entrée et de lecture de la sortie.

Cette dernière phrase compte plus qu’il n’y paraît. La majeure partie de la difficulté du travail d’inférence native ne réside pas dans les mathématiques — mais dans la plomberie :

• Déplacer correctement les tenseurs entre la mémoire hôte et la mémoire de l’appareil
• Gérer les tailles d’allocation et les durées de vie sans fuite
• Construire un moteur d’exécution optimisé pour le GPU spécifique sur lequel il s’exécutera
• Gérer la frontière de format entre un modèle entraîné et un artefact exécutable

Les exemples existent pour vous donner une réponse fonctionnelle à chacun de ces problèmes. Les lire est plus rapide que de dériver les mêmes réponses à partir de la seule référence d’API, car ils encodent l’ordre des opérations attendu par le runtime.

Ce que les exemples ne sont pas, c’est un produit fini. Ils sont généralement écrits pour la clarté plutôt que pour la robustesse : gestion minimale des erreurs, chemins codés en dur et hypothèses sur la forme des entrées. Traitez-les comme un modèle à forker, pas comme une bibliothèque à lier.

Pourquoi C++ est une couche pertinente pour l’IA locale

Python domine l’entraînement et l’expérimentation des modèles, et à juste titre. Pour le déploiement sur la machine d’un utilisateur, le calcul change.

Une application C++ n’embarque ni interpréteur, ni environnement virtuel, ni étape de résolution des dépendances à l’installation. Elle démarre vite, son empreinte mémoire est prévisible et elle s’intègre au code natif existant — outils de CAO, moteurs de jeu, pipelines multimédias, logiciels de contrôle industriel — sans pont de langage.

Il y a de vrais coûts, et il est honnête de les nommer. La configuration de build est plus complexe. La gestion de la mémoire est de votre responsabilité. Déboguer un crash dans un kernel GPU est plus difficile que lire une trace Python. Les exemples réduisent considérablement le premier coût, ce qui constitue sans doute leur principale valeur pratique.

Si votre objectif est un outil de bureau, un plugin ou un composant embarqué qui se trouve utiliser un réseau de neurones, C++ est le langage hôte naturel. Si votre objectif est d’itérer sur l’architecture du modèle, ce n’est pas le cas. Choisissez en conséquence.

Prérequis

Avant d’installer quoi que ce soit, confirmez que la machine respecte le socle minimal.

Matériel

• Un GPU NVIDIA RTX. TensorRT RTX cible le matériel de classe RTX, donc une carte de l’époque GTX n’est pas une cible prise en charge.
• Un pilote suffisamment récent pour votre version du SDK. Les versions du pilote et du runtime doivent être compatibles ; c’est la source la plus courante d’erreurs d’exécution déroutantes.
• Suffisamment de VRAM pour votre modèle. Une règle de planification approximative : poids plus activations plus espace de travail. Les grands modèles nécessitent de grandes cartes.

Logiciel

• Un compilateur compatible C++17 : MSVC sous Windows, GCC ou Clang sous Linux.
• CMake pour le système de build utilisé par la plupart des exemples.
• Le CUDA Toolkit, correspondant à la version attendue par votre build TensorRT RTX.
• Le SDK TensorRT RTX lui-même.
• Git, pour récupérer les sources des exemples.
• Python avec PyTorch, uniquement si vous devez exporter vous-même un modèle ONNX.

Connaissances

• À l’aise avec un terminal, la lecture d’erreurs de build et les concepts GPU de base tels que la mémoire de l’appareil. Aucune expérience préalable de TensorRT n’est requise, mais les exemples seront plus faciles à suivre si vous comprenez ce qu’est une forme de tenseur.

Installation étape par étape

La séquence ci-dessous est ordonnée délibérément : vérifier le GPU, installer CUDA, installer le SDK, récupérer les exemples, compiler, puis exécuter.

1. Vérifier le GPU et le pilote

Commencez par confirmer que le pilote voit la carte et indique une version de CUDA.

nvidia-smi

Cela affiche la version du pilote installée et la version maximale du runtime CUDA prise en charge par le pilote. Si cette commande échoue, arrêtez-vous ici et corrigez d’abord l’installation du pilote — rien en aval ne fonctionnera.

2. Installer le CUDA Toolkit

Installez une version du CUDA Toolkit qui correspond à l’exigence indiquée dans la documentation de votre SDK TensorRT RTX. Sous Linux, le dépôt de paquets NVIDIA fournit des méta-paquets :

sudo apt update && sudo apt install -y cuda-toolkit

Sous Windows, utilisez l’installateur du CUDA Toolkit et sélectionnez l’option d’installation personnalisée afin de pouvoir désélectionner les composants dont vous n’avez pas besoin, comme les anciens ensembles de pilotes.

Après l’installation, confirmez que le compilateur est dans votre PATH :

nvcc --version

3. Installer le SDK TensorRT RTX

Téléchargez le paquet SDK depuis la page de téléchargement pour développeurs de NVIDIA — un compte développeur NVIDIA est normalement requis. Décompressez-le dans un emplacement stable et notez ce chemin, car chaque étape ultérieure y fait référence.

sudo mkdir -p /opt/nvidia/tensorrt-rtx
sudo tar -xf tensorrt-rtx-*.tar.gz -C /opt/nvidia/tensorrt-rtx --strip-components=1

Le nom exact de l’archive et l’arborescence interne varient selon la version. Vérifiez le contenu de premier niveau après extraction avant de continuer.

Rendez les bibliothèques d’exécution détectables :

export TRT_RTX_ROOT=/opt/nvidia/tensorrt-rtx
export LD_LIBRARY_PATH=$TRT_RTX_ROOT/lib:$LD_LIBRARY_PATH

Ajoutez ces deux lignes à votre profil de shell si vous ne voulez pas les répéter à chaque session. Sous Windows, l’étape équivalente consiste à ajouter les répertoires bin et lib du SDK à PATH, et le répertoire d’inclusion à INCLUDE.

4. Obtenir les exemples

Les exemples sont fournis avec le SDK ou publiés sous forme de dépôt de sources dans l’organisation GitHub de NVIDIA. Récupérez-les avec Git :

git clone <samples-repository-url> tensorrt-rtx-samples
cd tensorrt-rtx-samples

Prenez l’URL du dépôt à partir de l’article du blog développeur NVIDIA ou de la documentation du SDK plutôt que d’une source secondaire ; les dépôts d’exemples sont parfois renommés ou consolidés entre les versions.

5. Configurer et compiler avec CMake

Configurez le build dans un répertoire séparé pour que l’arborescence des sources reste propre. Indiquez explicitement l’emplacement du SDK pour que CMake n’ait pas à le deviner :

cmake -S . -B build \
  -DCMAKE_BUILD_TYPE=Release \
  -DTENSORRT_ROOT=$TRT_RTX_ROOT

Le nom de la variable pour la racine du SDK diffère selon les ensembles d’exemples — certains utilisent TENSORRT_ROOT, d’autres attendent une variable d’environnement ou un fichier de configuration. Si CMake signale qu’il ne trouve pas TensorRT, inspectez le CMakeLists.txt de l’exemple pour connaître la variable exacte qu’il recherche.

Compilez :

cmake --build build --config Release --parallel

Sous Windows avec un générateur Visual Studio, spécifiez le générateur et la plateforme d’emblée :

cmake -S . -B build -G "Visual Studio 17 2022" -A x64 -DTENSORRT_ROOT=$env:TRT_RTX_ROOT
cmake --build build --config Release

6. Vérifier le build

Listez les binaires produits et confirmez que chacun répond à --help :

./build/bin/<sample_name> --help

Lisez attentivement la sortie d’aide. C’est la liste faisant autorité des options pour la version que vous avez compilée, et c’est la raison pour laquelle cet article évite délibérément de coder en dur les noms d’options ci-dessous.

Détails de configuration importants à l’exécution

Une fois les exemples compilés, trois préoccupations de configuration dominent.

Format de modèle. Les runtimes d’inférence natifs consomment généralement soit un graphe ONNX, soit un moteur sérialisé préconstruit. ONNX est l’entrée portable ; le moteur est l’artefact optimisé, spécifique au GPU. Si votre modèle est dans PyTorch, exportez-le :

import torch

model = torch.load("model.pth", map_location="cpu").eval()
dummy = torch.randn(1, 3, 224, 224)

torch.onnx.export(
    model,
    dummy,
    "model.onnx",
    input_names=["input"],
    output_names=["output"],
    dynamic_axes={"input": {0: "batch"}, "output": {0: "batch"}},
    opset_version=17,
)

Vérifiez le numéro d’opset par rapport à ce que votre runtime prend en charge. Un opérateur non pris en charge est un échec au moment du build, pas une dégradation gracieuse.

Portabilité du moteur. Un moteur sérialisé est généralement lié à l’architecture GPU et à la version du runtime sur lesquelles il a été construit. Construisez les moteurs sur la machine cible, ou construisez-en un par configuration cible. Mettre en cache les moteurs sur la machine d’un utilisateur au premier lancement est un modèle courant et évite de livrer une quantité d’artefacts équivalente à celle d’une ferme de build.

Précision. Les exécutions en FP16 et INT8 sont les leviers habituels pour le débit. Ils ne sont pas gratuits : la quantification peut modifier les résultats, et INT8 en particulier nécessite des données de calibration pour choisir judicieusement les échelles. Validez toujours la précision par rapport à une référence en pleine précision avant d’activer un chemin en précision réduite.

Exemples d’utilisation

Les exemples suivants montrent la forme du travail plutôt que des invocations exactes, car les noms d’options varient selon la version. Confirmez toujours avec --help.

Exemple 1 : exécuter un exemple fourni

Un exemple d’inférence typique prend un chemin de modèle et une entrée, puis écrit une sortie :

./build/bin/<inference_sample> \
  --model ./models/model.onnx \
  --input ./data/input.bin \
  --output ./data/output.bin

Si l’exemple attend un moteur préconstruit au lieu d’ONNX, il exposera probablement une étape de build distincte ou une option telle que --build-engine. Consultez le texte d’aide.

Exemple 2 : la structure d’un programme d’inférence minimal

Les exemples suivent tous à peu près le même squelette. Réduit à l’essentiel, ce squelette ressemble à ceci — considérez les noms comme des espaces réservés structurels et remplacez-les par les symboles réels des en-têtes du SDK que vous avez installés :

// Structure illustrative uniquement. Utilisez les vrais noms d'API de vos en-têtes
// TensorRT RTX installés et de l'exemple sur lequel vous basez votre code.
#include <iostream>
#include <vector>

int main(int argc, char** argv) {
    // 1. Créez le runtime et désérialisez (ou construisez) un moteur.
    //    C'est l'étape coûteuse ; faites-le une fois, pas à chaque inférence.
    auto engine = loadOrBuildEngine("model.onnx");

    // 2. Créez un contexte d'exécution. Les contextes sont peu coûteux et contiennent
    //    l'état par inférence ; un contexte par flux concurrent.
    auto context = engine->createExecutionContext();

    // 3. Allouez des tampons de l'appareil pour les entrées et sorties, dimensionnés à partir des
    //    descripteurs de tenseur du moteur plutôt que de nombres codés en dur.
    auto buffers = allocateBuffers(engine);

    // 4. Copiez les données d'entrée de l'hôte vers l'appareil.
    copyInputToDevice(buffers, "input.bin");

    // 5. Mettez le travail en file d'attente et synchronisez avant de lire les résultats.
    enqueue(context, buffers);
    synchronize();

    // 6. Copiez les sorties vers l'hôte et utilisez-les.
    writeOutputToHost(buffers, "output.bin");

    return 0;
}

La valeur des exemples est qu’ils remplissent chacune de ces six étapes avec du code fonctionnel, y compris les vérifications d’erreur et l’arithmétique de taille de tampon qu’il est facile de rendre subtilement incorrecte.

Exemple 3 : inférence par lots à partir d’une liste de fichiers

Pour un travail orienté débit, le modèle consiste à charger le moteur une fois et à boucler :

for f in ./data/*.bin; do
  ./build/bin/<inference_sample> --model ./models/model.onnx --input "$f" --output "${f%.bin}.out"
done

C’est très bien pour tester l’exactitude. Pour un vrai débit, préférez un processus unique qui regroupe les entrées par lots, car sinon le démarrage du processus et la désérialisation du moteur dominent. Le traitement par lots amortit les deux.

Notes sur les performances et la validation

Deux habitudes évitent la plupart des efforts inutiles.

Validez les résultats numériques avant d’optimiser. Exécutez votre modèle via l’exemple et via une implémentation de référence — PyTorch ou ONNX Runtime — sur des entrées identiques. Comparez avec une tolérance adaptée à la tâche. Ce n’est qu’une fois les sorties correspondantes que vous devriez commencer à ajuster la précision ou la taille des lots, sinon vous ne pouvez pas distinguer un bug d’exactitude d’un artefact de quantification.

Mesurez sur la cible. Les performances d’inférence dépendent du modèle de GPU, de la version du pilote, des limites de puissance et thermiques, de la taille des lots et de la forme des entrées. Des chiffres provenant d’une autre machine, ou d’un autre mode de précision, vous induiront en erreur. Construisez un petit harnais qui fixe la forme des entrées et rapporte la latence sur de nombreuses itérations, y compris les exécutions d’échauffement — la première inférence après la création du moteur n’est pas représentative.

Liste de vérification de dépannage

• Erreur d’exécution concernant des versions incompatibles. Votre pilote est plus ancien que ce que le SDK exige, ou votre CUDA Toolkit ne correspond pas. Revérifiez les deux par rapport aux notes de version du SDK.
• Bibliothèque introuvable au démarrage. LD_LIBRARY_PATH sous Linux, ou PATH sous Windows, ne contient pas le répertoire des bibliothèques du SDK.
• CMake ne trouve pas TensorRT. Indiquez explicitement la racine du SDK ou inspectez CMakeLists.txt pour connaître le nom de variable attendu.
• Le modèle ne se charge pas. Opérateur ou opset non pris en charge. Réexportez avec un opset pris en charge et vérifiez la liste des opérateurs.
• Les sorties sont erronées mais aucune erreur n’est levée. Les tailles de tampon, les formes de tenseur ou la disposition des entrées ne correspondent pas. Affichez les descripteurs d’entrée et de sortie du moteur et comparez-les à ce que vous fournissez réellement.
• Les performances sont moins bonnes que prévu. La première exécution inclut la construction du moteur ; les exécutions suivantes devraient être plus rapides. Vérifiez également que vous n’exécutez pas accidentellement sur CPU.

Conclusion

Le chemin entre un modèle entraîné et une application d’IA locale native est court si vous partez du bon endroit. Les exemples TensorRT RTX de NVIDIA fournissent ce point de départ : du code C++ fonctionnel qui démontre le cycle de vie du moteur, la gestion des tampons et le flux d’exécution que vous devriez sinon reconstruire à partir des premiers principes.

La séquence pratique est simple. Vérifiez votre GPU et votre pilote, installez un CUDA Toolkit et un SDK TensorRT RTX correspondants, récupérez les exemples, configurez avec CMake en pointant explicitement vers la racine du SDK, et compilez. Ensuite, lisez l’exemple le plus proche de votre cas d’usage, exécutez-le avec votre propre modèle ONNX et validez les sorties avant de toucher aux performances.

Les exemples sont une fondation, pas une application finie. Une gestion robuste des erreurs, la mise en cache des moteurs, la stratégie de traitement par lots et les décisions de quantification restent votre travail. Mais c’est le travail qui compte, et le code répétitif qui se trouve devant est exactement ce que les exemples suppriment. Pour les développeurs qui veulent faire tourner l’inférence sur leur propre matériel, au sein de leur propre logiciel natif, c’est un point de départ véritablement utile.

Le guide original et les exemples eux-mêmes sont liés depuis le blog développeur de NVIDIA : Build Local AI Apps with C++ and NVIDIA TensorRT RTX Samples.