LLM auf NVIDIA Jetson Orin: eingebettete KI, die in die main

#Warum ein Jetson Orin für ein LLM?

Ein Jetson Orin ist kein Mikrocontroller: Es handelt sich um ein System-on-Chip-Modul, das eine ARM-Cortex-CPU, eine NVIDIA-GPU mit CUDA- und Tensor-Kernen und einen gemeinsamen Arbeitsspeicher für beide kombiniert. Konkret greift die GPU direkt auf den System-RAM zu – es gibt keinen separaten VRAM. Ein geladenes LLM belegt daher den gemeinsamen Arbeitsspeicher, genau wie auf einem Mac mit Apple Silicon, und die Berechnung profitiert von der CUDA-Beschleunigung.

Das unterscheidet den LLM-Betrieb auf dem Jetson Orin grundlegend von KI auf einem Raspberry Pi: Während der Pi im reinen CPU-Betrieb an seine Grenzen stößt, überträgt der Orin die Berechnungen an die GPU und erreicht bei Modellen mit 3B bis 8B einen brauchbaren Durchsatz. Das alles bei einer Leistungsaufnahme von 7 bis 60 Watt, auch mit Batterie betreibbar, ohne lauten Lüfter oder Tower unter dem Schreibtisch.

Unabhängigkeit vom Netzwerk

Keine Abhängigkeit von der Cloud: Das Modell läuft direkt auf dem Gerät, auch auf einem mobilen Roboter oder an einem isolierten Standort ohne Verbindung.

Vorhersehbare Latenz

Kein Hin und Her über das Internet. Die Antwort hängt ausschließlich von der lokalen GPU ab, was für eine Echtzeit-Regelschleife wichtig ist.

Datenschutz

Die Daten von Sensoren, Kameras oder Mikrofonen verlassen das Gerät nie. Das ist für die Hausautomation und im medizinischen Bereich unverzichtbar.

CUDA-Ökosystem

Derselbe Software-Stack wie bei einer NVIDIA-Desktop-GPU: Ollama, llama.cpp, PyTorch und TensorRT funktionieren, müssen allerdings für ARM kompiliert werden.

#Jetson Orin Nano oder AGX: Welche Karte wählen?

Bei der Orin-Serie unterscheiden sich die Speicherkapazitäten um den Faktor 8, die Leistungsunterschiede sind noch deutlich größer. Für ein LLM ist der vereinheitlichte Arbeitsspeicher das entscheidende Kriterium: Er begrenzt die Modellgröße genauso wie der VRAM einer klassischen GPU. Hier sind die relevanten Größenstufen.

Orin Nano 8 GB

Der Einstieg (~40 TOPS). 8 GB vereinheitlichter Arbeitsspeicher, der mit dem System geteilt wird. Geeignet für 3B-Modelle in Q4 oder, wenn Sie Speicher freigeben, mit knappem Spielraum für ein 7B-Modell. Ideal für einen intelligenten Sensor oder einen eingebetteten Sprachassistenten.

Orin NX 8 / 16 GB

Die Mittelklasse (~70–100 TOPS). Die 16-GB-Variante bietet ausreichend Spielraum für 7B–8B-Modelle in Q4_K_M. Ein guter Kompromiss für mobile Robotik.

AGX Orin 32 GB

Embedded-Station (~200 TOPS). Führt ein 14B-Modell in Q4 mit Kontext oder mehrere kleine Modelle parallel aus (Vision + Sprache).

AGX Orin 64 GB

Das Spitzenmodell (~275 TOPS). Für 32B-Modelle in Q4 (~19 GB) ausgelegt, mit Reserven für den Kontext und andere Arbeitslasten. Das einzige Modell der Reihe, das auf einen ernsthaften Einsatz von 32B-Modellen abzielt.

#Voraussetzungen und Rolle von JetPack

Das gesamte Jetson-Ökosystem basiert auf JetPack, der Softwaredistribution von NVIDIA. Sie enthält Ubuntu (L4T, Linux for Tegra), die CUDA-Treiber, cuDNN, TensorRT und die GPU-Bibliotheken. Ohne korrekt geflashtes JetPack gibt es keine Beschleunigung: Alles würde ausschließlich auf der CPU laufen, wodurch der gesamte Nutzen der Platine verloren ginge.

Eine Jetson-Orin-Karte

Nano, NX oder AGX mit einem passenden Netzteil (der Nano nimmt bis zu 15 W auf, der AGX bis zu 60 W).

Schneller Datenspeicher

Eine microSD-Karte (UHS-I) für Tests mit dem Nano, aber eine NVMe-SSD wird dringend empfohlen: Die Modelle sind mehrere GB groß, und auf SD-Karten dauert das Laden entsprechend länger.

Ein Linux-Host-PC (Ubuntu)

Erforderlich, um AGX/NX über SDK Manager zu flashen. Das Nano Developer Kit lässt sich direkt mit einem SD-Karten-Image installieren.

JetPack 6.x

Der neuere Entwicklungszweig basiert auf Ubuntu 22.04 mit CUDA 12. Er ist die Zielplattform für einen modernen LLM-Stack (Ollama und llama.cpp, kompiliert für die ARM-SBSA-Architektur).

#1. JetPack flashen und CUDA prüfen

1. 01
   Image flashen

   Schreiben Sie für ein Orin Nano Developer Kit das offizielle SD-Image mit Balena Etcher auf eine Karte, setzen Sie diese ein, schließen Sie das Gerät an und folgen Sie dem Ubuntu-Assistenten. Verwenden Sie für ein AGX/NX den NVIDIA SDK Manager auf dem Host-PC, mit einem USB-C-Kabel und der Platine im Recovery-Modus.
2. 02
   Das System aktualisieren

   Aktualisieren Sie beim ersten Start die Pakete. Das ist auch der richtige Zeitpunkt, um fehlende JetPack-Komponenten zu installieren, falls Sie das SD-Image verwendet haben.
3. 03
   GPU und CUDA prüfen

   Prüfen Sie, ob CUDA vorhanden ist und das Modul erkannt wird. jtop (über das Paket jetson-stats installiert) bietet eine Echtzeitübersicht über GPU, RAM und Stromverbrauch – das Gegenstück zu nvidia-smi auf Jetson.

# Mettre à jour le système
sudo apt update && sudo apt upgrade -y

# Vérifier la version de CUDA fournie par JetPack
nvcc --version

# Installer jtop (moniteur GPU/RAM/conso pour Jetson)
sudo pip3 install -U jetson-stats
sudo systemctl restart jtop.service

# Lancer le moniteur temps réel
jtop

#2. Installieren von Ollama unter JetPack

Ollama ist der schnellste Weg zu einem ersten Modell. Das offizielle Installationsskript erkennt die ARM64-Architektur und die Jetson-GPU und richtet den systemd-Dienst ein. Nach dem Start lauscht der Daemon standardmäßig auf http://localhost:11434, genau wie auf einem Desktop-PC.

# Script d'installation officiel (détecte ARM64 + GPU Jetson)
curl -fsSL https://ollama.com/install.sh | sh

# Le service démarre automatiquement (systemd)
systemctl status ollama

# Tirer et lancer un modèle 3B adapté au Nano
ollama run granite4.2:3b

# Vérifier que le GPU est bien utilisé (pas CPU)
ollama ps

Für eine Benutzeroberfläche im Stil von ChatGPT fügen Sie Open WebUI als Container hinzu, der auf denselben Endpoint verweist. Beschränken Sie sich auf einem Nano mit 8 GB auf das Nötigste: Jeder Dienst beansprucht einen Teil des vereinheitlichten Speichers, der bereits für das Modell eingeplant ist.

#3. llama.cpp mit CUDA kompilieren

Ollama reicht für die meisten Anwendungen aus, aber das manuelle Kompilieren von llama.cpp ermöglicht eine präzise Kontrolle: Auswahl der genauen GGUF-Quantisierung, Einstellung der Anzahl der auf die GPU ausgelagerten Schichten und oft einige Tokens pro Sekunde mehr. Dies ist auch der Weg, wenn Sie die Engine in Ihre eigene Binärdatei für ein eingebettetes System integrieren möchten.

# Dépendances de build
sudo apt install -y build-essential cmake git libcurl4-openssl-dev

# Récupérer les sources
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

# Compiler avec CUDA activé (GGML_CUDA=ON)
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j$(nproc)

# Lancer l'inférence en déchargeant les couches sur le GPU (-ngl 99)
./build/bin/llama-cli -m modele-q4_k_m.gguf -ngl 99 -p "Bonjour"

#Welche Modelle laufen abhängig von der Speichergröße?

Es gilt dieselbe Regel wie bei Desktop-GPUs: Bei der Quantisierung Q4_K_M (dem besten Kompromiss zwischen Qualität und Speicherbedarf) rechnen Sie mit etwa 2 GB für ein 3B-Modell, 5 GB für ein 7B-Modell, 9 GB für ein 14B-Modell und 19 GB für ein 32B-Modell. Ziehen Sie auf Jetson den vom System belegten Speicher vom gesamten RAM ab, um Ihr tatsächlich verfügbares Speicherbudget zu ermitteln.

Orin Nano 8 GB

Granite 4.2 3B (~2,2 GB), Qwen 3.5 4B (~3,4 GB) oder Gemma 4 E2B (~4,3 GB) in Q4. Ein 8B-Modell (Granite 4.2 8B, ~5,3 GB) läuft, wenn Sie alle anderen Programme schließen, aber der Spielraum für den Kontext bleibt knapp.

Orin NX 16 GB

8B–9B-Modelle (Granite 4.2 8B, Qwen 3.5 9B) lassen sich in Q4_K_M mit Kontext komfortabel betreiben. Ein 24B-Modell (Mistral Small 24B, ~14 GB) passt in Q4 in den Speicher, lässt aber wenig Spielraum.

AGX Orin 32 GB

Ein 24B-Modell (Mistral Small, gpt-oss 20B) läuft problemlos, ebenso ein MoE-Modell mit 30–35B (Qwen 3.6 35B-A3B, ~23 GB). Genügend Platz, um ein Sprachmodell mit einem Vision-Stack zu kombinieren.

AGX Orin 64 GB

Ein MoE-Modell mit 30–35B in voller Qualität, ein 24B-Modell in Q8 oder mehrere gleichzeitig geladene Modelle. Die einzige Leistungsstufe, die ernsthaft auf große Modelle mit genügend Reserven ausgelegt ist.

#Stromverbrauch und Energiemodi

Der größte Vorteil des Jetson ist die Leistung pro Watt. Jede Karte bietet Leistungsmodi (Power Modes), die den Verbrauch begrenzen, indem sie mehr oder weniger CPU-Kerne aktivieren und den GPU-Takt drosseln. Sie werden mit nvpmodel gesteuert, und jetson_clocks erzwingt die höchsten im jeweiligen Modus zulässigen Taktfrequenzen.

# Lister les modes d'alimentation disponibles
sudo nvpmodel -q

# Basculer sur le mode le plus performant (index variable selon la carte)
sudo nvpmodel -m 0

# Verrouiller les fréquences au max du mode courant
sudo jetson_clocks

# Suivre conso, GPU et température en direct
jtop

Energiesparmodus

Beim Orin Nano begrenzt ein 7-W-Modus den Durchsatz stark, ermöglicht aber den Betrieb mit einer Batterie oder einer USB-C-Stromversorgung mit geringer Leistung. Geeignet für einen Sensor, der das Modell in Abständen abfragt.

Modus mit voller Leistung

Der MAXN-Modus schaltet die volle GPU-Leistung frei. Beim AGX Orin kann die Leistungsaufnahme 60 W erreichen: Planen Sie eine Kühlung mit aktivem Kühlkörper und eine ausreichend dimensionierte Stromversorgung ein.

Der Kompromiss bei eingebetteten Systemen

Viele Projekte laufen gut im Leistungsmodus mit 15–25 W: guter Durchsatz bei einem 3B–7B-Modell, gut beherrschbare Wärmeabfuhr und angemessene Akkulaufzeit.

#Anwendungsfall: Robotik und Smart Home

Der Jetson glänzt dort, wo ein LLM möglichst nah an der physischen Welt eingesetzt werden muss, ohne Cloud-Latenz oder Datenabfluss. Zwei Bereiche dominieren den Einsatz in eingebetteten Systemen.

Robotik (ROS 2)

Das LLM dient als Schnittstelle für natürliche Sprache: eine gesprochene Anweisung in eine Abfolge von Aktionen übersetzen, eine von der Kamera wahrgenommene Szene beschreiben, über eine Aufgabe nachdenken. Der Jetson führt sowohl die Wahrnehmung (Bildverarbeitung) als auch die Sprachverarbeitung auf derselben GPU aus.

Lokale Hausautomation

Ein Sprachassistent für zu Hause, der Home Assistant steuert, ohne jemals einen Cloud-Dienst zu nutzen. Das Modell interpretiert Anfragen in natürlicher Sprache und löst Automatisierungen aus – Mikrofon und Daten bleiben zu Hause.

Autonome intelligente Sensoreinheit

An einem abgelegenen Standort (landwirtschaftlich oder industriell) analysiert Orin Daten lokal und erstellt Zusammenfassungen in natürlicher Sprache, die nur übertragen werden, wenn eine Verbindung verfügbar ist.

Offline-Assistent im Feld

Technische Dokumentation, die per RAG abgefragt werden kann, in ein Fahrzeug oder Gerät integriert ist und ohne Netzwerk funktioniert.

#Im Vergleich zum Raspberry Pi: der echte Unterschied

Die Frage kommt immer wieder auf: Warum für einen Jetson bezahlen, wenn ein Raspberry Pi 5 ebenfalls Ollama ausführen kann? Die Antwort lässt sich auf ein Wort bringen: GPU. Der Pi hat keinen für die LLM-Inferenz nutzbaren Beschleuniger; alles läuft auf der ARM-CPU. Der Jetson hingegen lagert die Berechnungen auf CUDA-Kerne aus.

Beschleunigung

Pi 5: ausschließlich CPU, bei einem 3B-Modell mühsam nur wenige Tokens pro Sekunde. Jetson Orin: CUDA-GPU, ein um ein Mehrfaches höherer Durchsatz beim selben Modell und tatsächlich nutzbare 7B–14B-Modelle.

Speicher

Der Pi 5 ist auf 8/16 GB CPU-RAM begrenzt. Jetson bietet bis zu 64 GB gemeinsamen Speicher für CPU und GPU und ermöglicht damit Modelle, die auf dem Pi nicht ausführbar sind.

Preis

Der Pi kostet nur einen Bruchteil dessen, was der Jetson kostet. Der Preisunterschied ist real: Der Jetson lohnt sich, wenn Sie Durchsatz oder große Modelle benötigen, nicht für einen einfachen 1B-Bot.

Ökosystem

Der Pi ist vielseitig einsetzbar und communityorientiert; der Jetson ist auf eingebettete KI mit CUDA, TensorRT und NVIDIAs Robotik-Unterstützung (Isaac) ausgerichtet.

#Fehlerbehebung

Ollama bleibt auf der CPU

Die GPU wird nicht genutzt, wenn JetPack/CUDA nicht korrekt installiert ist oder wenn Sie ein generisches ARM-Image ohne Tegra-Unterstützung geflasht haben. Prüfen Sie nvcc --version und die GPU-Aktivität in jtop.

Out of memory beim Laden

Das Modell benötigt mehr vereinheitlichten Speicher, als nach Abzug des Systembedarfs verfügbar ist. Wechseln Sie zu einer kleineren Modellgröße (7B → 3B), zu einer aggressiveren Q4-Quantisierung oder beenden Sie die anderen Dienste.

Der Durchsatz bricht ein

Thermische Drosselung. Prüfen Sie die Temperatur in jtop, verbessern Sie die Kühlung oder wechseln Sie zu einem weniger energiehungrigen, aber stabilen nvpmodel-Modus.

Sehr langsames Laden des Modells

Modelle auf microSD gespeichert. Verschieben Sie ~/.ollama (oder Ihre GGUF-Dateien) auf eine NVMe-SSD, damit das Laden Sekunden statt Minuten dauert.

llama.cpp ignoriert die GPU

Die Option -ngl fehlt oder der Build wurde ohne CUDA erstellt. Kompilieren Sie erneut mit -DGGML_CUDA=ON und starten Sie mit -ngl 99.

# Le GPU est-il vu et actif ?
jtop

# CUDA est-il bien présent ?
nvcc --version

# Ollama utilise-t-il le GPU pour le modèle chargé ?
ollama ps

# Mode d'alimentation courant
sudo nvpmodel -q

#Weiterführende Informationen

Der Jetson nutzt denselben Software-Stack wie ein NVIDIA-PC. Diese Leitfäden ergänzen Ihr Embedded-Setup sinnvoll:

LLM auf Raspberry Pi 5: eingebettete lokale KI

Der direkte Vergleich im reinen CPU-Bereich, der hilfreich ist, um zwischen Pi und Jetson entsprechend Ihrem Projekt und Ihrem Budget zu entscheiden.

llama.cpp mit CUDA kompilieren

Zur Vertiefung der Kompilierung aus dem Quellcode und der GPU-Einstellungen, die sich auf die ARM-Architektur des Jetson übertragen lassen.

Quantisierung wählen (Q4, Q5, Q8, FP16)

Um den Speicherbedarf an den vereinheitlichten RAM Ihrer Orin-Karte anzupassen.