Développez plus rapidement des applications sur NVIDIA BlueField avec les compétences d’agent NVIDIA DOCA

Développez des applications sur NVIDIA BlueField plus rapidement avec les NVIDIA DOCA Agent Skills

Développer sur un DPU n'est pas la même chose que développer sur un CPU hôte, et la différence apparaît tôt. Une application DOCA se répartit généralement sur deux domaines d'exécution : un plan de contrôle côté hôte qui configure et supervise, et une logique côté DPU qui s'exécute sur les cœurs Arm du BlueField et touche le datapath réseau. Obtenir qu'un agent de codage IA aide sur cette répartition est plus difficile que de le pointer vers une base de code monoprocessus, car l'agent doit garder en tête à la fois le contexte du périphérique, les conventions du SDK et une boucle de compilation et de déploiement.

L'article du blog des développeurs NVIDIA Build Applications on NVIDIA BlueField Faster with NVIDIA DOCA Agent Skills (publié le 1er octobre 2026) aborde directement cette friction. Cet article s'appuie sur cette unique source primaire. Lorsque je décris des mécanismes du flux de travail que l'article lui-même ne détaille pas, je les identifie comme une interprétation ou comme une pratique DOCA standard plutôt que comme des affirmations de NVIDIA.

Ce que la source établit

Les faits vérifiés sont limités, et il vaut la peine de les énoncer clairement avant de construire quoi que ce soit par-dessus :

• NVIDIA a publié un article de blog pour développeurs intitulé « Build Applications on NVIDIA BlueField Faster with NVIDIA DOCA Agent Skills ».
• L'article est disponible sur le blog NVIDIA Developer.
• Le sujet est l'accélération du développement d'applications sur NVIDIA BlueField à l'aide des NVIDIA DOCA Agent Skills.

C'est le socle factuel. L'article est la référence canonique pour les compétences spécifiques que NVIDIA fournit, les formats exacts impliqués et les versions de release ciblées par ces compétences. Tout ce qui suit et décrit comment travailler avec une telle configuration est ma synthèse de la pratique générale du développement DOCA, clairement identifié comme interprétation lorsque cela dépasse l'annonce.

Pourquoi le développement BlueField résiste à l'automatisation naïve

Ce qui suit est une interprétation, pas une affirmation de la source.

Un agent de codage générique se débrouille raisonnablement bien sur une bibliothèque autonome avec une API bien connue. Le travail sur BlueField brise trois des hypothèses qui rendent cela possible.

Premièrement, deux domaines, une fonctionnalité. Une fonctionnalité de délestage de flux (flow-offload) est rarement complète d'un seul côté. Quelque chose sur l'hôte doit découvrir le périphérique, ouvrir un contexte DOCA et pousser la configuration. Quelque chose sur le DPU doit réagir à cette configuration dans le datapath. Un agent qui ne génère que la moitié hôte produit du code qui compile et ne fait rien d'utile.

Deuxièmement, la capacité matérielle est un fait d'exécution. La disponibilité d'un délestage, d'un mode de chiffrement ou d'une primitive de file d'attente donnés dépend de la génération spécifique de BlueField, du firmware et de la version de DOCA installée. Le code qui suppose qu'une capacité est présente échouera à l'exécution plutôt qu'à la compilation, ce qui est exactement le mode de défaillance qu'un agent diagnostique le moins bien sans retour d'information.

Troisièmement, la boucle de compilation n'est pas `make && ./run`. Vous compilez généralement en croisé ou compilez sur le DPU, déployez le binaire côté Arm, puis observez le comportement sur un second système. Chaque saut supplémentaire est un endroit où les hypothèses d'un agent sur le système de fichiers, la chaîne d'outils ou l'architecture cible peuvent diverger silencieusement de la réalité.

Les Agent Skills comptent précisément parce qu'ils s'attaquent à ce problème de contexte plutôt qu'au problème de génération de code. La valeur n'est pas un modèle plus intelligent ; c'est un modèle plus étroit et mieux ancré.

Ce que les « Agent Skills » changent en pratique

Cette section est une interprétation, présentée comme un modèle de travail plutôt que comme une description de l'implémentation de NVIDIA.

Le modèle mental utile est qu'une compétence est une unité empaquetée de procédure de domaine : quand l'utiliser, quelles préconditions vérifier, quelles commandes ou API privilégier, à quoi ressemblent les signatures d'échec et comment vérifier le succès. Cela ressemble davantage à un runbook qu'un ingénieur expérimenté confierait à un nouveau collègue qu'à un extrait de prompt.

Appliqué à BlueField, cela signifie qu'une compétence peut encoder les parties du flux de travail qu'un modèle ne peut pas déduire du code seul :

• La séquence de découverte — comment confirmer qu'un DPU est présent, quels outils rapportent la capacité et à quoi ressemble une sortie « attendue ».
• La répartition des domaines — quelles parties d'une fonctionnalité appartiennent à l'hôte et lesquelles appartiennent au DPU.
• Le contrat de vérification — à quoi ressemble un test réussi pour cette classe de délestage, et à quoi ressemble à la place une mauvaise configuration silencieuse.
• Les invariants d'environnement — les hypothèses de version d'OS, de noyau et de DOCA dans lesquelles la procédure est connue pour fonctionner.

La conséquence pratique est un changement dans la façon dont vous passez votre temps de revue. Au lieu de lire chaque ligne du code généré en chassant les appels d'API hallucinés, vous le passez à vérifier si l'agent a respecté les préconditions de la compétence. C'est une surface bien plus petite.

Prérequis

Les prérequis ci-dessous sont génériques pour un environnement de développement DOCA. Les versions exactes proviennent de la documentation DOCA de NVIDIA et de l'article de blog, qui font autorité pour votre version.

• Un système hôte avec un DPU NVIDIA BlueField installé et visible sur le bus PCIe.
• Une distribution Linux prise en charge sur l'hôte, et un noyau correspondant à ce que votre version de DOCA exige.
• Un accès à la pile logicielle DOCA, installée soit depuis le dépôt de paquets de NVIDIA, soit depuis l'installateur DOCA pertinent, en suivant les instructions d'installation officielles de NVIDIA.
• Une chaîne d'outils : un compilateur C/C++, cmake, pkg-config et git.
• Python 3 avec venv si vous avez l'intention de scripter la boucle côté hôte ou d'exécuter un harnais d'agent localement.
• Un accès réseau pour l'installation des paquets, et les permissions appropriées — la plupart des étapes de découverte et d'installation ci-dessous nécessitent sudo.

Une mise en garde à énoncer explicitement : ne codez pas en dur des noms de paquets ou des URL de dépôt provenant d'un article de blog dans un script de provisionnement. Le nommage des paquets change entre les versions de DOCA. Découvrez plutôt ce que votre environnement offre réellement.

Installation étape par étape

La séquence ci-dessous est délibérément orientée découverte d'abord. Chaque étape demande au système ce qu'il possède avant d'affirmer quoi que ce soit à son sujet.

1. Confirmer que le périphérique BlueField est présent

Listez les périphériques PCIe NVIDIA/Mellanox sur l'hôte.

lspci -nn | grep -i mellanox

Vous recherchez une entrée de contrôleur réseau. Un DPU BlueField se présente comme un périphérique PCIe avec son propre sous-système Arm, donc la disposition exacte des fonctions différera d'une simple carte réseau. Si rien n'apparaît, arrêtez-vous ici — aucune installation de SDK n'aidera, et l'agent travaillera contre un périphérique fantôme.

2. Enregistrer l'environnement hôte

Capturez l'OS et le noyau afin de pouvoir épingler vos définitions de compétences à une combinaison connue comme valide.

cat /etc/os-release
uname -srm

Conservez cette sortie. Lorsque l'agent produit du code qui échoue uniquement sur votre machine, c'est la première chose que vous comparez.

3. Vérifier si DOCA est déjà installé

Interrogez la base de données des paquets plutôt que de supposer que le système est propre.

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

Cherchez ensuite un répertoire d'installation, sans deviner le chemin exact utilisé par votre version.

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

4. Découvrir les paquets exposés par votre dépôt

C'est l'étape qui remplace les noms de paquets devinés.

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

Lisez la liste. Elle vous indique quels composants DOCA votre dépôt configuré contient et, indirectement, sur quelle ligne de version vous vous trouvez. Vérifiez-la par rapport au guide d'installation DOCA officiel de NVIDIA avant de continuer.

5. Installer les composants DOCA dont vous avez besoin

Mettez à jour l'index, puis installez les composants identifiés à l'étape précédente. L'espace réservé ci-dessous est intentionnel — remplacez-le par le vrai nom issu de votre propre sortie apt-cache search.

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

6. Installer la chaîne d'outils de compilation

Le compilateur et CMake sont nécessaires pour toute application DOCA que vous ou l'agent écrirez.

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

7. Localiser les binaires d'interrogation et d'exemple DOCA

Au lieu de supposer un nom d'outil, demandez au paquet installé ce qu'il a mis sur le disque.

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

C'est ainsi que vous trouvez l'utilitaire d'interrogation de version et les applications d'exemple pour votre version. Les applications d'exemple sont le meilleur matériel d'ancrage que vous puissiez confier à un agent, car elles sont garanties de compiler contre vos en-têtes installés.

8. Créer un squelette de projet

Mettez en place une disposition prévisible afin que l'agent ait un endroit stable pour écrire et lire.

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

9. Préparer un environnement Python pour le scripting côté hôte

Si vous prévoyez de scripter la découverte, le déploiement ou l'invocation de l'agent, isolez les dépendances.

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

Exemples d'utilisation

Les exemples ci-dessous sont des motifs, pas une spécification d'un format fourni par NVIDIA. Considérez-les comme un échafaudage à adapter.

Exemple 1 : encoder une compétence comme procédure vérifiée

Une compétence de cette forme générale donne à l'agent des préconditions et un contrat de vérification, pas seulement des instructions. Enregistrez-la sous skills/.

# skill: dpu-device-preflight

## Préconditions
- L'hôte a un DPU BlueField visible sur PCIe
- Les paquets DOCA sont installés et les outils d'interrogation sont présents dans le PATH

## Étapes
1. Confirmer que le DPU est énuméré sur le bus PCIe.
2. Enregistrer la version de DOCA pour cet environnement.
3. Confirmer que la capacité requise est rapportée par l'outil d'interrogation.
4. Si la capacité est absente, ARRÊTEZ et signalez-le. Ne générez pas de code.

## Vérification
- Chaque étape produit une sortie observée, pas une supposition.
- L'absence d'une capacité est un résultat valide et signalable.

La clause « ARRÊTEZ et signalez » compte plus qu'il n'y paraît. Elle convertit une classe d'hallucination — inventer un délestage que le matériel ne prend pas en charge — en un échec propre.

Exemple 2 : une boucle de compilation et de test déterministe

Donnez à l'agent une seule commande qui réussit ou échoue, afin qu'il ne puisse pas contourner par un récit une compilation cassée.

#!/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

Comme set -euo pipefail est actif, toute étape en échec interrompt le script. L'agent voit un code de sortie non nul et la fin du journal, pas un succès ambigu.

Exemple 3 : un orchestrateur côté hôte qui journalise l'état observé

Ce modèle exécute une commande externe, capture sa sortie et journalise à la fois la commande et le résultat. Adaptez la liste des commandes aux outils que vous avez trouvés à l'étape 7 de l'installation.

import logging
import subprocess

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

def observe(cmd: list[str]) -> str:
    """Exécute une commande de découverte en lecture seule et renvoie sa sortie standard."""
    logging.info("exécution : %s", " ".join(cmd))
    result = subprocess.run(
        cmd,
        capture_output=True,
        text=True,
        check=False,
    )
    if result.returncode != 0:
        logging.warning("la commande a quitté avec le code %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)

La contrainte de lecture seule est délibérée. Les commandes de découverte peuvent être exécutées sans surveillance ; les commandes de configuration non, et une compétence doit séparer explicitement les deux phases.

Exemple 4 : un modèle de prompt qui garde l'agent ancré

Lorsque vous invoquez l'agent, fournissez le fichier de compétence, l'instantané de l'environnement de l'étape 2 et la sortie brute de l'échec. Un modèle compact :

Contexte :
- Fichier de compétence : skills/dpu-device-preflight.md
- Environnement : <collez la sortie de /etc/os-release et de uname>
- Version de DOCA installée : <collez la sortie de version>

Tâche :
Diagnostiquer pourquoi la compilation dans scripts/build-and-test.sh a échoué.
Proposer un correctif uniquement pour le composant côté hôte.
Ne pas introduire d'appels d'API qui ne sont pas présents dans les en-têtes installés.

Sortie requise :
1. Cause racine, avec la ligne de journal qui la soutient.
2. Un diff unifié.
3. La commande exacte pour vérifier le correctif.

La dernière ligne est la plus importante. Exiger une commande de vérification ferme la boucle et rend l'affirmation de l'agent testable.

Limites ouvertes et ce qu'il faut vérifier vous-même

Trois choses restent véritablement incertaines, et prétendre le contraire serait trompeur.

Les spécificités des compétences de NVIDIA. L'article de blog est la source faisant autorité pour savoir quelles compétences existent, quel format elles utilisent et quelles versions elles ciblent. Cet article ne reproduit pas cet inventaire.

La dérive des versions. Les noms de paquets DOCA et les emplacements des outils changent entre les versions. La séquence d'installation orientée découverte ci-dessus est conçue pour survivre à cette dérive, mais elle ne peut pas remplacer la lecture des notes de version.

Les affirmations de performance. Le titre dit « plus rapidement », et la source présente le travail comme une accélération du développement. Je n'ai avancé aucun chiffre d'accélération, aucun pourcentage ni aucun benchmark, car aucun ne m'a été fourni. Si vous avez besoin d'un chiffre pour une décision, faites votre propre mesure : choisissez une fonctionnalité DOCA représentative, construisez-la une fois avec votre processus existant et une fois avec le flux de travail agent-plus-compétences, puis comparez les heures d'ingénierie jusqu'à une implémentation fonctionnelle et vérifiée. Le temps écoulé du modèle n'est pas la métrique qui compte ici.

Conclusion

Ce qui est intéressant avec les DOCA Agent Skills, ce n'est pas qu'un agent écrive du code DOCA. C'est que le goulot d'étranglement dans le développement DPU a toujours été le contexte — la capacité du périphérique, la répartition hôte/DPU et une boucle de compilation qui s'étend sur deux systèmes. Les compétences empaquettent ce contexte afin qu'un agent puisse être utile à l'intérieur de celui-ci plutôt que plausible en dehors.

Le chemin pratique est court. Confirmez que le DPU est sur le bus, découvrez ce que votre installation DOCA fournit réellement au lieu de le supposer, donnez à l'agent les applications d'exemple et un script de compilation et de test déterministe, et exigez une commande de vérification avec chaque modification proposée. Mesurez ensuite le résultat par rapport à votre propre référence. C'est ainsi que vous découvrez si « plus rapidement » est vrai dans votre environnement, qui est le seul environnement qui compte.