Anwendungen auf NVIDIA BlueField schneller entwickeln mit NVIDIA DOCA Agent Skills

Anwendungen auf NVIDIA BlueField schneller mit NVIDIA DOCA Agent Skills entwickeln

Auf einer DPU zu entwickeln ist nicht dasselbe wie auf einer Host-CPU zu entwickeln, und der Unterschied zeigt sich früh. Eine DOCA-Anwendung teilt sich üblicherweise auf zwei Ausführungsdomänen auf: eine hostseitige Steuerungsebene, die konfiguriert und überwacht, und DPU-seitige Logik, die auf den Arm-Kernen des BlueField läuft und den Netzwerk-Datapath berührt. Einen KI-Coding-Agenten dabei zu helfen, mit dieser Aufteilung umzugehen, ist schwieriger, als ihn auf eine Single-Process-Codebasis zu richten, weil der Agent Gerätekontext, SDK-Konventionen und eine Build-and-Deploy-Schleife gleichzeitig im Kopf behalten muss.

Der Developer-Blog-Beitrag von NVIDIA Build Applications on NVIDIA BlueField Faster with NVIDIA DOCA Agent Skills (veröffentlicht am 1. Oktober 2026) befasst sich direkt mit dieser Reibung. Dieser Artikel arbeitet aus dieser einen Primärquelle. Wo ich Workflow-Mechaniken beschreibe, die der Beitrag selbst nicht ausführt, kennzeichne ich sie als Interpretation oder als übliche DOCA-Praxis und nicht als Aussagen von NVIDIA.

Was die Quelle belegt

Die verifizierten Fakten sind schmal, und es lohnt sich, sie klar zu benennen, bevor irgendetwas darauf aufgebaut wird:

• NVIDIA veröffentlichte einen Developer-Blog-Beitrag mit dem Titel „Build Applications on NVIDIA BlueField Faster with NVIDIA DOCA Agent Skills“.
• Der Beitrag ist im NVIDIA Developer-Blog verfügbar.
• Das Thema ist die Beschleunigung der Anwendungsentwicklung auf NVIDIA BlueField mit NVIDIA DOCA Agent Skills.

Das ist die faktische Grundlage. Der Beitrag ist die kanonische Referenz für die konkreten Skills, die NVIDIA ausliefert, die genauen Formate und die Release-Versionen, auf die diese Skills abzielen. Alles Folgende, das beschreibt, wie man mit einem solchen Setup arbeitet, ist meine Synthese allgemeiner DOCA-Entwicklungspraxis und wird klar als Interpretation gekennzeichnet, wo es über die Ankündigung hinausgeht.

Warum sich BlueField-Entwicklung naiver Automatisierung widersetzt

Es folgt eine Interpretation, keine Aussage aus der Quelle.

Ein generischer Coding-Agent ist bei einer eigenständigen Bibliothek mit wohlbekannter API ziemlich gut. Die Arbeit mit BlueField durchbricht drei der Annahmen, die das möglich machen.

Erstens: zwei Domänen, ein Feature. Ein Flow-Offload-Feature ist selten auf einer Seite vollständig. Etwas auf dem Host muss das Gerät erkennen, einen DOCA-Kontext öffnen und Konfiguration übertragen. Etwas auf der DPU muss im Datapath auf diese Konfiguration reagieren. Ein Agent, der nur die Host-Hälfte generiert, erzeugt Code, der kompiliert und nichts Nützliches tut.

Zweitens: Hardware-Fähigkeit ist eine Laufzeit-Tatsache. Ob ein bestimmtes Offload, ein Verschlüsselungsmodus oder ein Queue-Primitiv verfügbar ist, hängt von der konkreten BlueField-Generation, der Firmware und der installierten DOCA-Version ab. Code, der annimmt, dass eine Fähigkeit vorhanden ist, schlägt zur Laufzeit statt zur Kompilierungszeit fehl – genau der Fehlermodus, den ein Agent ohne Feedback am schlechtesten diagnostiziert.

Drittens: Die Build-Schleife ist nicht `make && ./run`. Typischerweise cross-kompiliert man oder baut auf der DPU, deployt das Binary auf die Arm-Seite und beobachtet das Verhalten dann auf einem zweiten System. Jeder zusätzliche Sprung ist eine Stelle, an der die Annahmen eines Agenten über das Dateisystem, die Toolchain oder die Zielarchitektur still von der Realität abweichen können.

Agent Skills sind genau deshalb wichtig, weil sie dieses Kontextproblem angehen und nicht das Codegenerierungsproblem. Der Wert liegt nicht in einem klügeren Modell; er liegt in einem engeren, besser fundierten Modell.

Was „Agent Skills“ in der Praxis ändern

Dieser Abschnitt ist eine Interpretation, formuliert als Arbeitsmodell und nicht als Beschreibung von NVIDIAs Implementierung.

Das nützliche mentale Modell ist, dass ein Skill eine verpackte Einheit Domänenprozedur ist: wann man ihn verwendet, welche Vorbedingungen zu prüfen sind, welche Befehle oder APIs zu bevorzugen sind, wie Fehlersignaturen aussehen und wie man Erfolg verifiziert. Er ist eher ein Runbook, das ein erfahrener Ingenieur einer neuen Kollegin übergeben würde, als ein Prompt-Schnipsel.

Auf BlueField angewendet bedeutet das, dass ein Skill die Teile des Workflows kodieren kann, die ein Modell nicht allein aus dem Code ableiten kann:

• Die Discovery-Sequenz – wie man bestätigt, dass eine DPU vorhanden ist, welche Tools Fähigkeiten melden und wie „erwartete“ Ausgabe aussieht.
• Die Domänenaufteilung – welche Teile eines Features auf den Host und welche auf die DPU gehören.
• Der Verifikationsvertrag – wie ein bestandener Test für diese Klasse von Offload aussieht und wie stattdessen eine stille Fehlkonfiguration aussieht.
• Die Umgebungsinvarianten – die Annahmen zu Betriebssystem, Kernel und DOCA-Version, unter denen die Prozedur bekanntermaßen funktioniert.

Die praktische Konsequenz ist eine Verschiebung dessen, wie man Review-Zeit verbringt. Statt jede Zeile generierten Codes zu lesen und nach halluzinierten API-Aufrufen zu suchen, prüft man, ob der Agent die Vorbedingungen des Skills eingehalten hat. Das ist eine viel kleinere Oberfläche.

Anforderungen

Die folgenden Anforderungen sind generisch für eine DOCA-Entwicklungsumgebung. Genaue Versionen stammen aus NVIDIAs DOCA-Dokumentation und dem Blog-Beitrag, die für Ihr Release maßgeblich sind.

• Ein Hostsystem mit einer installierten NVIDIA BlueField DPU, die auf dem PCIe-Bus sichtbar ist.
• Eine unterstützte Linux-Distribution auf dem Host und ein Kernel, der zu dem passt, was Ihr DOCA-Release erfordert.
• Zugriff auf den DOCA-Software-Stack, installiert entweder aus NVIDIAs Paket-Repository oder mit dem entsprechenden DOCA-Installer, gemäß NVIDIAs offiziellen Installationsanleitungen.
• Eine Toolchain: ein C/C++-Compiler, cmake, pkg-config und git.
• Python 3 mit venv, wenn Sie die hostseitige Schleife skripten oder lokal eine Agent-Harness ausführen möchten.
• Netzwerkzugriff für die Paketinstallation und entsprechende Berechtigungen – die meisten Discovery- und Installationsschritte unten benötigen sudo.

Eine ausdrückliche Warnung: Kodieren Sie Paketnamen oder Repository-URLs aus einem Blog-Beitrag nicht fest in ein Provisioning-Skript. Die Paketbenennung ändert sich zwischen DOCA-Releases. Finden Sie stattdessen heraus, was Ihre Umgebung tatsächlich anbietet.

Schritt-für-Schritt-Installation

Die folgende Sequenz ist bewusst Discovery-first. Jeder Schritt fragt das System, was es hat, bevor irgendetwas darüber behauptet wird.

1. Bestätigen, dass das BlueField-Gerät vorhanden ist

Listen Sie NVIDIA/Mellanox-PCIe-Geräte auf dem Host auf.

lspci -nn | grep -i mellanox

Sie suchen einen Eintrag für einen Netzwerkcontroller. Eine BlueField DPU präsentiert sich als PCIe-Gerät mit einem eigenen Arm-Subsystem, daher wird das genaue Funktionslayout von einer einfachen NIC abweichen. Wenn nichts erscheint, hören Sie hier auf – keine noch so große SDK-Installation hilft, und der Agent würde gegen ein Phantomgerät arbeiten.

2. Hostumgebung erfassen

Erfassen Sie Betriebssystem und Kernel, damit Sie Ihre Skill-Definitionen an eine bekanntermaßen funktionierende Kombination binden können.

cat /etc/os-release
uname -srm

Bewahren Sie diese Ausgabe auf. Wenn der Agent Code erzeugt, der nur auf Ihrer Maschine fehlschlägt, ist dies das Erste, was Sie vergleichen.

3. Prüfen, ob DOCA bereits installiert ist

Fragen Sie die Paketdatenbank ab, statt ein sauberes System anzunehmen.

dpkg -l | grep -i doca || echo "no doca packages found via dpkg"

Suchen Sie dann nach einem Installationsverzeichnis, ohne den genauen Pfad Ihres Releases zu raten.

find / -maxdepth 4 -type d -name 'doca*' 2>/dev/null

4. Die Pakete ermitteln, die Ihr Repository anbietet

Dies ist der Schritt, der geratene Paketnamen ersetzt.

apt-cache search --names-only '^doca' | sort

Lesen Sie die Liste. Sie sagt Ihnen, welche DOCA-Komponenten Ihr konfiguriertes Repository enthält und indirekt, auf welcher Release-Linie Sie sich befinden. Gleichen Sie sie mit NVIDIAs offiziellem DOCA-Installationshandbuch ab, bevor Sie fortfahren.

5. Die benötigten DOCA-Komponenten installieren

Aktualisieren Sie den Index und installieren Sie dann die im vorherigen Schritt identifizierten Komponenten. Der folgende Platzhalter ist beabsichtigt – ersetzen Sie ihn durch den echten Namen aus Ihrer eigenen apt-cache search-Ausgabe.

sudo apt-get update
sudo apt-get install -y <doca-package-from-step-4>

6. Die Build-Toolchain installieren

Compiler und CMake werden für jede DOCA-Anwendung benötigt, die Sie oder der Agent schreiben.

sudo apt-get install -y build-essential cmake git pkg-config

7. Die DOCA-Abfrage- und Beispiel-Binärdateien finden

Fragen Sie statt der Annahme eines Toolnamens das installierte Paket, was es auf die Festplatte gelegt hat.

dpkg -L <doca-package-from-step-4> | grep -E '/(bin|sbin)/'

So finden Sie das Versionsabfrage-Dienstprogramm und die Beispielanwendungen für Ihr Release. Beispielanwendungen sind das beste Grundlagenmaterial, das Sie einem Agenten geben können, weil sie garantiert gegen Ihre installierten Header kompilieren.

8. Ein Projektgerüst erstellen

Richten Sie ein vorhersehbares Layout ein, damit der Agent einen stabilen Ort zum Schreiben und Lesen hat.

mkdir -p ~/bf-doca-lab/{src,skills,scripts,build}
cd ~/bf-doca-lab
git init

9. Eine Python-Umgebung für hostseitiges Skripting vorbereiten

Wenn Sie Discovery, Deployment oder Agent-Aufrufe skripten möchten, isolieren Sie die Abhängigkeiten.

cd ~/bf-doca-lab
python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip

Verwendungsbeispiele

Die folgenden Beispiele sind Muster, keine Spezifikation eines von NVIDIA bereitgestellten Formats. Betrachten Sie sie als anzupassendes Gerüst.

Beispiel 1: Einen Skill als geprüfte Prozedur kodieren

Ein Skill in dieser allgemeinen Form gibt dem Agenten Vorbedingungen und einen Verifikationsvertrag, nicht nur Anweisungen. Speichern Sie ihn unter skills/.

# skill: dpu-device-preflight

## Vorbedingungen
- Host hat eine auf PCIe sichtbare BlueField DPU
- DOCA-Pakete installiert und Abfrage-Tools auf PATH vorhanden

## Schritte
1. Bestätigen, dass die DPU auf dem PCIe-Bus aufgeführt ist.
2. Das DOCA-Release für diese Umgebung erfassen.
3. Bestätigen, dass die erforderliche Fähigkeit vom Abfrage-Tool gemeldet wird.
4. Wenn die Fähigkeit fehlt, STOP und melden. Keinen Code generieren.

## Verifikation
- Jeder Schritt erzeugt beobachtete Ausgabe, keine Annahme.
- Das Fehlen einer Fähigkeit ist ein gültiges, berichtbares Ergebnis.

Die Klausel „STOP und melden“ ist wichtiger, als sie aussieht. Sie verwandelt eine Klasse von Halluzination – das Erfinden eines Offloads, das die Hardware nicht unterstützt – in einen sauberen Fehler.

Beispiel 2: Eine deterministische Build-and-Test-Schleife

Geben Sie dem Agenten einen einzigen Befehl, der entweder besteht oder fehlschlägt, damit er sich nicht um einen kaputten Build herumerzählen kann.

#!/usr/bin/env bash
set -euo pipefail

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j"$(nproc)"
ctest --test-dir build --output-on-failure

Weil set -euo pipefail in Kraft ist, bricht jede fehlschlagende Stufe das Skript ab. Der Agent sieht einen Exit-Code ungleich null und das Ende des Logs, keinen mehrdeutigen Erfolg.

Beispiel 3: Ein hostseitiger Orchestrator, der beobachteten Zustand protokolliert

Diese Vorlage führt einen externen Befehl aus, erfasst seine Ausgabe und protokolliert sowohl den Befehl als auch das Ergebnis. Passen Sie die Befehlsliste an die Tools an, die Sie in Schritt 7 der Installation gefunden haben.

import logging
import subprocess

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(message)s",
)

def observe(cmd: list[str]) -> str:
    """Run a read-only discovery command and return its stdout."""
    logging.info("running: %s", " ".join(cmd))
    result = subprocess.run(
        cmd,
        capture_output=True,
        text=True,
        check=False,
    )
    if result.returncode != 0:
        logging.warning("command exited %d: %s", result.returncode, result.stderr.strip())
    return result.stdout

if __name__ == "__main__":
    for probe in (
        ["lspci", "-nn"],
        ["uname", "-srm"],
    ):
        output = observe(probe)
        print(output)

Die Read-only-Einschränkung ist beabsichtigt. Discovery-Befehle sind sicher unbeaufsichtigt auszuführen; Konfigurationsbefehle nicht, und ein Skill sollte die beiden Phasen ausdrücklich trennen.

Beispiel 4: Ein Prompt-Muster, das den Agenten geerdet hält

Wenn Sie den Agenten aufrufen, geben Sie die Skill-Datei, den Umgebungs-Snapshot aus Schritt 2 und die rohe Fehlerausgabe an. Ein kompaktes Muster:

Kontext:
- Skill-Datei: skills/dpu-device-preflight.md
- Umgebung: <füge /etc/os-release und uname-Ausgabe ein>
- Installiertes DOCA-Release: <füge Versionsausgabe ein>

Aufgabe:
Diagnostiziere, warum der Build in scripts/build-and-test.sh fehlgeschlagen ist.
Schlage einen Patch nur für die hostseitige Komponente vor.
Führe keine API-Aufrufe ein, die nicht in den installierten Headern vorhanden sind.

Erforderliche Ausgabe:
1. Grundursache, mit der Logzeile, die sie stützt.
2. Ein Unified Diff.
3. Der exakte Befehl zur Verifikation der Korrektur.

Die letzte Zeile ist die wichtige. Einen Verifikationsbefehl zu verlangen, schließt die Schleife und macht die Behauptung des Agenten testbar.

Offene Grenzen und was Sie selbst verifizieren sollten

Drei Dinge bleiben wirklich unsicher, und etwas anderes vorzugeben wäre irreführend.

Die Details von NVIDIAs Skills. Der Blog-Beitrag ist die maßgebliche Quelle dafür, welche Skills existieren, welches Format sie verwenden und auf welche Releases sie abzielen. Dieser Artikel gibt dieses Inventar nicht wieder.

Versionsdrift. DOCA-Paketnamen und Tool-Speicherorte ändern sich zwischen Releases. Die oben beschriebene Discovery-first-Installationssequenz ist darauf ausgelegt, diese Drift zu überstehen, aber sie kann nicht das Lesen der Release Notes ersetzen.

Performance-Behauptungen. Der Titel sagt „schneller“, und die Quelle rahmt die Arbeit als Beschleunigung der Entwicklung. Ich habe keine Geschwindigkeitssteigerungszahl, keinen Prozentsatz und keinen Benchmark behauptet, weil mir keiner bereitgestellt wurde. Wenn Sie eine Zahl für eine Entscheidung brauchen, führen Sie Ihre eigene Messung durch: Wählen Sie ein repräsentatives DOCA-Feature, bauen Sie es einmal mit Ihrem bestehenden Prozess und einmal mit dem Agent-plus-Skills-Workflow und vergleichen Sie die Engineering-Stunden bis zu einer funktionierenden, verifizierten Implementierung. Verstrichene Modellzeit ist hier nicht die Metrik, die zählt.

Fazit

Das Interessante an DOCA Agent Skills ist nicht, dass ein Agent DOCA-Code schreibt. Es ist, dass der Engpass in der DPU-Entwicklung schon immer Kontext war – Gerätefähigkeit, die Host/DPU-Aufteilung und eine Build-Schleife, die zwei Systeme umspannt. Skills verpacken diesen Kontext, damit ein Agent darin nützlich sein kann statt außerhalb davon plausibel.

Der praktische Weg ist kurz. Bestätigen Sie, dass die DPU am Bus ist, finden Sie heraus, was Ihre DOCA-Installation tatsächlich bietet, statt es anzunehmen, geben Sie dem Agenten die Beispielanwendungen und ein deterministisches Build-and-Test-Skript und verlangen Sie bei jeder vorgeschlagenen Änderung einen Verifikationsbefehl. Messen Sie dann das Ergebnis gegen Ihre eigene Baseline. So finden Sie heraus, ob „schneller“ in Ihrer Umgebung wahr ist – der einzigen Umgebung, die zählt.