NVIDIA erläutert TensorRT Edge-LLM auf DGX Spark und nennt eigene DSpark-Decoding-Messwerte

Ein NVIDIA-Tutorial vom 30. Oktober 2026 beschreibt die lokale Entwicklung von Edge-Anwendungen mit TensorRT Edge-LLM auf einem DGX Spark mit 64 GB. „Edge“ meint hier Anwendungen auf Geräten am Netzwerkrand und nicht ein als „führend“ bewertetes Modell. Das Beispiel verwendet das reine Textmodell Nemotron-3.5 Lightning 30B-A3B NVFP4. Mit dem Kommandozeilenwerkzeug trtedge lädt man das Modell, baut eine TensorRT-Engine, chattet im Terminal und stellt eine lokale API bereit. Der Artikel enthält eine von NVIDIA erstellte Leistungstabelle. Unsere Redaktion hat sie nicht unabhängig nachgemessen; sie gilt auch nicht automatisch für Bild-, Sprach- oder Robotikmodelle, die als weitere Möglichkeiten erwähnt werden.

Vorausgesetzt werden ein DGX Spark mit unterstützter Software, CUDA 13, TensorRT ab 10.16.1.11 innerhalb der 10.x-Reihe und Python 3.10 bis 3.12. NVIDIA gibt an, die Schritte mit TensorRT Edge-LLM 0.11.1 und TensorRT 10.16.1.11 getestet zu haben. Das Tutorial erstellt eine virtuelle Python-Umgebung mit Zugriff auf Systempakete, installiert die festgelegte Version samt server-Zusatz, prüft TensorRT und lädt die Runtime. Nicht passende Python-Bindings können den Start verhindern; der Text verweist dafür auf TensorRT-Installationshinweise. Die Befehle sind für das Gerät des Lesers gedacht und wurden von uns nicht ausgeführt.

Der erste trtedge-chat-Aufruf lädt das ausgewählte Modell herunter und baut die Engine. NVIDIA schätzt den Modell-Download auf rund 21 GB. Modelle und Engines liegen standardmäßig im Cache des Nutzers; spätere Starts verwenden bei passenden Einstellungen vorhandene Engines erneut. Die Beispielanfrage rechnet 25 °C in Fahrenheit um und zeigt 77 °F als Antwort. Das ist eine Funktionsvorführung und kein Test der Genauigkeit über verschiedene Aufgaben hinweg. Danach kann trtedge serve eine OpenAI-kompatible Chat-API an der lokalen Adresse 127.0.0.1 auf Port 8000 öffnen. Vor einer Streaming-Anfrage wird geprüft, ob die Health-Schnittstelle ready meldet. Durch die Loopback-Adresse bleibt der Tutorial-Server lokal, sofern der Betreiber die Netzwerkkonfiguration nicht ändert.

Optional wird der Server mit spekulativem DSpark-Decoding neu gestartet. Ein Entwurfsmodell schlägt Tokens vor, die das Hauptmodell gesammelt prüft; im Beispiel sind es drei vorgeschlagene Tokens. Das beschleunigt gegebenenfalls die Texterzeugung und hat nichts mit Stromerzeugung oder dem Austausch des Hauptmodells zu tun. Die Anzahl der Vorschläge kann für die jeweilige Last angepasst werden. Der Beitrag verspricht nicht, dass dieses Setup mit jedem Modell und jedem Embedded-Gerät funktioniert. Vor einer Übertragung vom Spark-Prototyp auf ein Zielgerät sind die Modellliste und die plattformspezifischen Anforderungen zu prüfen.

In seiner Tabelle für DGX Spark 64 GB nennt NVIDIA die mediane Zeit bis zum ersten Token und die mittlere Generierungsrate. Bei SpeedBench 1K stehen ohne DSpark 201,0 ms und 73,3 Tokens/s, mit DSpark 203,0 ms und 108,5 Tokens/s. SpeedBench 2K zeigt 329,5 ms und 72,8 Tokens/s gegenüber 331,6 ms und 105,3 Tokens/s. Bei HumanEval-Prompts sind es 98,1 ms und 73,4 Tokens/s gegenüber 98,7 ms und 126,9 Tokens/s. Die Generierungsrate enthält die Wartezeit auf das erste Token nicht. Die höhere Rate in der Tabelle bedeutet deshalb bei diesen Zeilen keinen kürzeren Median bis zum ersten Token.

Gemessen wurde auf DGX OS 7.6.0 mit Ubuntu 24.04.4, NVFP4, aktiviertem thinking, Batchgröße eins, einer gleichzeitigen Streaming-Anfrage und höchstens 128 Ausgabe-Tokens. Die mittleren Eingabelängen betrugen 1.153, 2.247 und 139 Tokens. NVIDIA meldet mit DSpark 27,9 GB maximalen gesamten Systemspeicher einschließlich Betriebssystem. Andere Modelle, Parallelität, Antwortlängen und Edge-Geräte können andere Werte liefern. Der praktische Nutzen liegt in einem dokumentierten Weg vom lokalen Chat zur lokalen App-API und in einer optionalen Decoding-Erprobung, deren Zahlen an das ausgewiesene Hersteller-Setup gebunden bleiben.