Lokale KI-Apps mit C++ und NVIDIA TensorRT RTX Samples erstellen

Lokale KI-Apps mit C++ und NVIDIA TensorRT RTX Samples erstellen

KI-Modelle auf dem eigenen Rechner auszuführen, hat sich von einem Nischenhobby zu einer echten Engineering-Option entwickelt. Consumer- und Workstation-GPUs bieten inzwischen genug Rechenleistung, um echte Inferenz-Workloads zu bedienen, und der Software-Stack drumherum ist so ausgereift, dass „lokal“ nicht mehr „Spielzeug“ bedeutet. Für Entwickler, die diese Fähigkeit in einer nativen Anwendung statt in einem Python-Notebook wollen, ist die Kombination aus C++ und NVIDIA TensorRT RTX einer der direktesten verfügbaren Wege.

Der NVIDIA-Developer-Blogbeitrag Build Local AI Apps with C++ and NVIDIA TensorRT RTX Samples führt in diesen Workflow ein: eine für RTX-Hardware optimierte Laufzeitumgebung plus eine Reihe von Samples, die zeigen, wie die Teile zusammenpassen. Dieser Artikel erweitert diesen Ausgangspunkt zu einem praktischen Walkthrough – was die Samples sind, was Sie brauchen, wie Sie installieren und bauen und wie Sie von einer Demo-Binärdatei zu etwas gelangen, das Sie ausliefern können.

Ein Hinweis zum Umfang, bevor wir beginnen: Die folgenden Details stammen aus dem oben referenzierten NVIDIA-Developer-Blogbeitrag und aus allgemeinem, öffentlich dokumentiertem Toolchain-Verhalten. Wo ein konkreter Pfad, ein Flag oder ein Paketname von Ihrer SDK-Version oder Plattform abhängt, wird diese Abhängigkeit benannt, statt geraten zu werden.

Was die TensorRT RTX Samples Ihnen tatsächlich bieten

TensorRT RTX ist eine Laufzeitumgebung für Inferenz auf NVIDIA RTX GPUs. Die Samples, die damit einhergehen, sind die Referenzimplementierungen: kleine, fokussierte Programme, die die Mechanik des Ladens eines Modells, seiner Vorbereitung für die Ausführung, der Eingabe von Daten und des Zurücklesens der Ausgabe demonstrieren.

Dieser letzte Satz ist wichtiger, als er aussieht. Die meiste Schwierigkeit bei nativer Inferenzarbeit ist nicht die Mathematik – es ist die technische Infrastruktur:

• Tensoren korrekt zwischen Host-Speicher und Gerätespeicher zu bewegen
• Zuordnungsgrößen und Lebensdauern zu verwalten, ohne Leaks zu verursachen
• Eine Ausführungs-Engine zu bauen, die auf die spezifische GPU abgestimmt ist, auf der sie laufen wird
• Die Formatgrenze zwischen einem trainierten Modell und einem ausführbaren Artefakt zu behandeln

Die Samples existieren, um Ihnen für jedes dieser Probleme eine funktionierende Antwort zu geben. Sie zu lesen ist schneller, als dieselben Antworten allein aus der API-Referenz abzuleiten, weil sie die Reihenfolge der Operationen kodieren, die die Laufzeitumgebung erwartet.

Was die Samples nicht sind, ist ein fertiges Produkt. Sie sind typischerweise auf Klarheit statt auf Robustheit ausgelegt: minimales Fehlerhandling, hart codierte Pfade und Annahmen über die Eingabeform. Behandeln Sie sie als Vorlage zum Forken, nicht als Bibliothek zum Linken.

Warum C++ eine sinnvolle Schicht für lokale KI ist

Python dominiert Modelltraining und Experimente, und das zu Recht. Für die Bereitstellung auf dem Rechner eines Nutzers ändert sich die Rechnung.

Eine C++-Anwendung bringt keinen Interpreter, keine virtuelle Umgebung und keinen Schritt zur Abhängigkeitsauflösung zur Installationszeit mit. Sie startet schnell, ihr Speicherbedarf ist vorhersagbar, und sie integriert sich ohne Sprachbrücke in bestehenden nativen Code – CAD-Tools, Game-Engines, Media-Pipelines, industrielle Steuerungssoftware.

Es gibt echte Kosten, und es ist ehrlich, sie zu benennen. Die Build-Konfiguration ist aufwendiger. Speicherverwaltung liegt in Ihrer Verantwortung. Das Debuggen eines Absturzes in einem GPU-Kernel ist schwieriger als das Lesen eines Python-Tracebacks. Die Samples reduzieren den ersten Aufwand erheblich, was wohl ihr hauptsächlicher praktischer Wert ist.

Wenn Ihr Ziel ein Desktop-Tool, ein Plugin oder eine eingebettete Komponente ist, die zufällig ein neuronales Netz verwendet, ist C++ die natürliche Host-Sprache. Wenn Ihr Ziel ist, an der Modellarchitektur zu iterieren, dann nicht. Wählen Sie entsprechend.

Voraussetzungen

Bevor Sie irgendetwas installieren, vergewissern Sie sich, dass der Rechner die Basisvoraussetzungen erfüllt.

Hardware

• Eine NVIDIA RTX GPU. TensorRT RTX zielt auf RTX-Hardware; eine Karte aus der GTX-Ära ist daher kein unterstütztes Ziel.
• Ein Treiber, der neu genug für Ihre SDK-Version ist. Treiber- und Laufzeitversionen müssen kompatibel sein; dies ist die häufigste Quelle verwirrender Laufzeitfehler.
• Ausreichend VRAM für Ihr Modell. Eine grobe Planungsregel: Gewichte plus Aktivierungen plus Arbeitsbereich. Große Modelle brauchen große Karten.

Software

• Einen C++17-fähigen Compiler: MSVC unter Windows, GCC oder Clang unter Linux.
• CMake für das von den meisten Samples verwendete Build-System.
• Das CUDA Toolkit in der Version, die Ihr TensorRT RTX Build erwartet.
• Das TensorRT RTX SDK selbst.
• Git, um die Sample-Quellen abzurufen.
• Python mit PyTorch, nur wenn Sie selbst ein ONNX-Modell exportieren müssen.

Kenntnisse

Vertrautheit mit einem Terminal, dem Lesen von Build-Fehlern und grundlegenden GPU-Konzepten wie Gerätespeicher. Vorherige TensorRT-Erfahrung ist nicht erforderlich, aber die Samples sind leichter zu verfolgen, wenn Sie verstehen, was eine Tensorform ist.

Schritt-für-Schritt-Installation

Die folgende Abfolge ist bewusst geordnet: GPU überprüfen, CUDA installieren, SDK installieren, Samples holen, bauen, dann ausführen.

1. GPU und Treiber überprüfen

Bestätigen Sie zunächst, dass der Treiber die Karte erkennt und eine CUDA-Version meldet.

nvidia-smi

Dies gibt die installierte Treiberversion und die maximale CUDA-Laufzeitversion aus, die der Treiber unterstützt. Wenn dieser Befehl fehlschlägt, hören Sie hier auf und reparieren Sie zuerst die Treiberinstallation – nichts nachgelagert wird funktionieren.

2. CUDA Toolkit installieren

Installieren Sie eine CUDA-Toolkit-Version, die der in Ihrer TensorRT RTX SDK-Dokumentation angegebenen Anforderung entspricht. Unter Linux stellt NVIDIAs Paket-Repository Metapakete bereit:

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

Verwenden Sie unter Windows den CUDA-Toolkit-Installer und wählen Sie die benutzerdefinierte Installationsoption, damit Sie Komponenten abwählen können, die Sie nicht benötigen, etwa ältere Treiberpakete.

Bestätigen Sie nach der Installation, dass der Compiler in Ihrem Pfad liegt:

nvcc --version

3. TensorRT RTX SDK installieren

Laden Sie das SDK-Paket von NVIDIAs Developer-Downloadseite herunter – ein NVIDIA-Developer-Konto ist normalerweise erforderlich. Entpacken Sie es an einen stabilen Ort und notieren Sie diesen Pfad, da jeder spätere Schritt darauf verweist.

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

Der genaue Archivname und das interne Verzeichnislayout variieren je Release. Prüfen Sie nach dem Entpacken den Inhalt der obersten Ebene, bevor Sie fortfahren.

Machen Sie die Laufzeitbibliotheken auffindbar:

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

Fügen Sie diese beiden Zeilen zu Ihrem Shell-Profil hinzu, wenn Sie sie nicht in jeder Sitzung wiederholen möchten. Unter Windows besteht der entsprechende Schritt darin, die Verzeichnisse bin und lib des SDK zu PATH und das Include-Verzeichnis zu INCLUDE hinzuzufügen.

4. Samples beziehen

Die Samples werden zusammen mit dem SDK ausgeliefert oder als Quellcode-Repository in NVIDIAs GitHub-Organisation veröffentlicht. Rufen Sie sie mit Git ab:

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

Nehmen Sie die Repository-URL aus dem NVIDIA-Developer-Blogbeitrag oder der SDK-Dokumentation statt aus einer sekundären Quelle; Sample-Repositories werden zwischen Releases gelegentlich umbenannt oder zusammengelegt.

5. Mit CMake konfigurieren und bauen

Konfigurieren Sie den Build in einem separaten Verzeichnis, damit der Quellbaum sauber bleibt. Geben Sie den SDK-Speicherort explizit an, damit CMake nicht raten muss:

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

Der Variablenname für das SDK-Stammverzeichnis unterscheidet sich zwischen Sample-Sets – einige verwenden TENSORRT_ROOT, andere erwarten eine Umgebungsvariable oder eine Konfigurationsdatei. Wenn CMake meldet, dass es TensorRT nicht finden kann, sehen Sie in der CMakeLists.txt des Samples nach, nach welcher exakten Variable es sucht.

Bauen:

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

Geben Sie unter Windows mit dem Visual-Studio-Generator Generator und Plattform vorab an:

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

6. Build überprüfen

Listen Sie die erzeugten Binärdateien auf und bestätigen Sie, dass jede auf --help reagiert:

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

Lesen Sie die Hilfeausgabe sorgfältig. Sie ist die maßgebliche Liste der Flags für die von Ihnen gebaute Version, und das ist der Grund, warum dieser Artikel im Folgenden bewusst darauf verzichtet, Flag-Namen hart zu codieren.

Konfigurationsdetails, die zur Laufzeit wichtig sind

Sobald die Samples kompilieren, dominieren drei Konfigurationsaspekte.

Modellformat. Native Inferenz-Laufzeitumgebungen verwenden im Allgemeinen entweder ein ONNX-Diagramm oder eine vorgefertigte serialisierte Engine. ONNX ist der portable Input; die Engine ist das optimierte, GPU-spezifische Artefakt. Wenn Ihr Modell in PyTorch vorliegt, exportieren Sie es:

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,
)

Prüfen Sie die Opset-Nummer gegen das, was Ihre Laufzeitumgebung unterstützt. Ein nicht unterstützter Operator ist ein Fehler zur Build-Zeit, keine sanfte Degradierung.

Engine-Portabilität. Eine serialisierte Engine ist im Allgemeinen an die GPU-Architektur und die Laufzeitversion gebunden, mit der sie gebaut wurde. Bauen Sie Engines auf dem Zielrechner oder bauen Sie eine pro Zielkonfiguration. Engines beim ersten Lauf auf dem Rechner eines Nutzers zwischenzuspeichern ist ein gängiges Muster und erspart es, eine ganze Build-Farm voller Artefakte auszuliefern.

Präzision. FP16- und INT8-Ausführung sind die üblichen Hebel für Durchsatz. Sie sind nicht kostenlos: Quantisierung kann Ergebnisse verschieben, und insbesondere INT8 erfordert Kalibrierungsdaten, um Skalen sinnvoll zu wählen. Validieren Sie die Genauigkeit stets anhand einer Referenz mit voller Präzision, bevor Sie einen Pfad mit reduzierter Präzision aktivieren.

Verwendungsbeispiele

Die folgenden Beispiele zeigen die Form der Arbeit statt exakter Aufrufe, da Flag-Namen je Release variieren. Prüfen Sie immer mit --help.

Beispiel 1: Ein mitgeliefertes Sample ausführen

Ein typisches Inferenz-Sample nimmt einen Modellpfad und eine Eingabe und schreibt dann eine Ausgabe:

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

Wenn das Sample eine vorgefertigte Engine statt ONNX erwartet, wird es wahrscheinlich einen separaten Build-Schritt oder ein Flag wie --build-engine anbieten. Sehen Sie im Hilfetext nach.

Beispiel 2: Die Struktur eines minimalen Inferenzprogramms

Alle Samples folgen ungefähr demselben Skelett. Auf das Wesentliche reduziert sieht dieses Skelett so aus – betrachten Sie die Namen als strukturelle Platzhalter und ersetzen Sie sie durch die tatsächlichen Symbole aus den SDK-Headern, die Sie installiert haben:

// Nur zur Veranschaulichung der Struktur. Verwenden Sie die echten API-Namen aus Ihren installierten
// TensorRT RTX-Headern und dem Sample, auf dem Sie Ihren Code aufbauen.
#include <iostream>
#include <vector>

int main(int argc, char** argv) {
    // 1. Runtime erstellen und eine Engine deserialisieren (oder bauen).
    //    Das ist der teure Schritt; einmal ausführen, nicht pro Inferenz.
    auto engine = loadOrBuildEngine("model.onnx");

    // 2. Einen Ausführungskontext erstellen. Kontexte sind günstig und halten den
    //    Zustand pro Inferenz; ein Kontext pro nebenläufigem Stream.
    auto context = engine->createExecutionContext();

    // 3. Gerätepuffer für Ein- und Ausgaben allokieren, dimensioniert anhand der
    //    Tensor-Deskriptoren der Engine statt anhand fest codierter Zahlen.
    auto buffers = allocateBuffers(engine);

    // 4. Eingabedaten vom Host auf das Gerät kopieren.
    copyInputToDevice(buffers, "input.bin");

    // 5. Die Arbeit einreihen und synchronisieren, bevor Ergebnisse gelesen werden.
    enqueue(context, buffers);
    synchronize();

    // 6. Ausgaben zurück auf den Host kopieren und verwenden.
    writeOutputToHost(buffers, "output.bin");

    return 0;
}

Der Wert der Samples liegt darin, dass sie jeden dieser sechs Schritte mit funktionierendem Code füllen, einschließlich der Fehlerprüfungen und der Puffergrößen-Arithmetik, die leicht subtil falsch gemacht werden kann.

Beispiel 3: Batch-Inferenz aus einer Dateiliste

Bei durchsatzorientierter Arbeit ist das Muster, die Engine einmal zu laden und dann zu schleifen:

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

Das ist für Korrektheitstests in Ordnung. Für echten Durchsatz bevorzugen Sie einen einzelnen Prozess, der Eingaben batcht, da andernfalls Prozessstart und Engine-Deserialisierung dominieren. Batching amortisiert beides.

Hinweise zu Leistung und Validierung

Zwei Gewohnheiten verhindern die meiste verschwendete Mühe.

Validieren Sie die Numerik, bevor Sie optimieren. Führen Sie Ihr Modell mit dem Sample und mit einer Referenzimplementierung – PyTorch oder ONNX Runtime – auf identischen Eingaben aus. Vergleichen Sie mit einer für die Aufgabe angemessenen Toleranz. Erst wenn die Ausgaben übereinstimmen, sollten Sie mit der Optimierung von Präzision oder Batch-Größe beginnen; andernfalls können Sie einen Korrektheitsfehler nicht von einem Quantisierungsartefakt unterscheiden.

Messen Sie auf dem Zielsystem. Inferenzleistung hängt von GPU-Modell, Treiberversion, Leistungs- und Thermikgrenzen, Batch-Größe und Eingabeform ab. Zahlen von einem anderen Rechner oder aus einem anderen Präzisionsmodus führen in die Irre. Erstellen Sie einen kleinen Harness, der die Eingabeform fixiert und Latenz über viele Iterationen berichtet, einschließlich Warm-up-Läufen – die erste Inferenz nach der Engine-Erstellung ist nicht repräsentativ.

Checkliste zur Fehlerbehebung

• Laufzeitfehler wegen inkompatibler Versionen. Ihr Treiber ist älter, als das SDK erfordert, oder Ihr CUDA Toolkit passt nicht. Prüfen Sie beides erneut anhand der SDK-Release-Notes.
• Bibliothek beim Start nicht gefunden. LD_LIBRARY_PATH unter Linux oder PATH unter Windows enthält nicht das Bibliotheksverzeichnis des SDK.
• CMake findet TensorRT nicht. Geben Sie das SDK-Stammverzeichnis explizit an oder sehen Sie in CMakeLists.txt nach dem erwarteten Variablennamen.
• Modell lässt sich nicht laden. Nicht unterstützter Operator oder Opset. Exportieren Sie mit einem unterstützten Opset neu und prüfen Sie die Operatorliste.
• Ausgaben sind falsch, aber es wird kein Fehler ausgelöst. Puffergrößen, Tensorformen oder Eingabelayout stimmen nicht überein. Geben Sie die Ein- und Ausgabe-Deskriptoren der Engine aus und vergleichen Sie sie mit dem, was Sie tatsächlich einspeisen.
• Leistung ist schlechter als erwartet. Der erste Lauf enthält den Engine-Build; nachfolgende Läufe sollten schneller sein. Vergewissern Sie sich außerdem, dass Sie nicht versehentlich auf der CPU ausführen.

Fazit

Der Weg von einem trainierten Modell zu einer nativen, lokalen KI-Anwendung ist kurz, wenn Sie an der richtigen Stelle beginnen. NVIDIAs TensorRT RTX Samples bieten diesen Ausgangspunkt: funktionierender C++-Code, der den Engine-Lebenszyklus, die Pufferverwaltung und den Ausführungsablauf demonstriert, die Sie andernfalls aus ersten Prinzipien rekonstruieren müssten.

Die praktische Abfolge ist unkompliziert. Überprüfen Sie GPU und Treiber, installieren Sie ein passendes CUDA Toolkit und TensorRT RTX SDK, holen Sie die Samples, konfigurieren Sie mit CMake unter expliziter Angabe des SDK-Stammverzeichnisses und bauen Sie. Lesen Sie dann das Sample, das Ihrem Anwendungsfall am nächsten kommt, führen Sie es mit Ihrem eigenen ONNX-Modell aus und validieren Sie die Ausgaben, bevor Sie die Leistung anfassen.

Die Samples sind ein Fundament, keine fertige Anwendung. Robustes Fehlerhandling, Engine-Caching, Batching-Strategie und Quantisierungsentscheidungen bleiben Ihre Arbeit. Aber genau diese Arbeit zählt, und der Boilerplate, der davorsteht, ist genau das, was die Samples entfernen. Für Entwickler, die Inferenz auf ihrer eigenen Hardware in ihrer eigenen nativen Software laufen lassen wollen, ist das ein wirklich nützlicher Ausgangspunkt.

Der ursprüngliche Walkthrough und die Samples selbst sind im NVIDIA-Developer-Blog verlinkt: Build Local AI Apps with C++ and NVIDIA TensorRT RTX Samples.