Skill de Microservice d'Inférence DeepStream SOP

Cette compétence guide les assistants de codage IA dans la construction, l'extension et le débogage du Microservice d'Inférence DeepStream SOP (Standard Operating Procedure) NVIDIA — un pipeline accéléré par GPU pour la détection d'actions temporelles et la surveillance de conformité SOP basée sur VLM sur des flux vidéo industriels.

Référence de dépôt : https://github.com/NVIDIA/sop-monitoring-blueprints/tree/main/microservices/sop-inference-bp Code de référence local : répertoire sop-inference-bp/ (à partir d'un clone local du dépôt)

Modèles

Agnostique aux modèles aux deux étapes d'inférence — permutable via variable d'environnement (et répertoire Triton pour GEBD).

« GEBD » = slot Étape-1 permutable ; « DDM » = l'architecture par défaut (termes utilisés de manière interchangeable).

Le chunking est sélectionnable par requête (§ 2) : le ddm-net par défaut utilise GEBD ; uniform produit des chunks de longueur fixe et contourne l'Étape-1 GEBD (§ 3, § 6). La fenêtre temporelle DDM est configurable via FRAMES_PER_SIDE / SEQUENCE_BATCH (§ 4, § 5), avec TensorRT optionnel (§ 5).

Aperçu de l'Architecture

S'exécute dans un conteneur Docker (nvds-action-sop) aux côtés d'un conteneur Kafka. Diagramme complet : references/sop_architecture.svg.

Flux de données à travers le pipeline SOPVideoProcessor en 4 étapes (par requête) :

Sources d'entrée                 Conteneur Docker : nvds-action-sop
─────────────────                ──────────────────────────────────────────────────
Fichiers vidéo ─┐                Serveur FastAPI (port 8300)
Flux RTSP ──────┤── base64/     ├─ /v1/chat/completions → SOPProcessManager
Caméra Basler ──┘   fichier/      │
                    rtsp/          │ ModelInitializer : VLM d'abord, puis pipeline DDM fictif
                    caméra         │ 4 pools de threads : cv(32), clip(32), vlm(64), vlm_req(64)
                                   │
                                   ▼ SOPVideoProcessor (par requête)
                                   ┌────────────────────────────────────────────────┐
                                   │ Étape 1 : Pipeline DeepStream (GPU)            │
                                   │   Source → nvstreammux → tee1                  │
                                   │    ├─[inference] queue1 → nvdspreprocess       │
                                   │    │  → nvinferserver (Triton CAPI + DDM)      │
                                   │    │  → InferOutputTensorParser → score_queue  │
                                   │    ├─[frames]  queue3 → nvvideoconvert         │
                                   │    │  → capsfilter → appsink                   │
                                   │    │  → DecodedFrameRetriever → frame_queue    │
                                   │    └─[RTSP out] queue → convert → enc H.264    │  (optionnel, § 18)
                                   │       → rtppay → udpsink → RTSPServer (§ 18)   │  opt-in uniquement
                                   │              │ scores de limites               │
                                   │              ▼                                 │
                                   │ Étape 2 : Post-traitement Clip                 │
                                   │   Détection de limites → segmentation chunk    │
                                   │              │ images vidéo + timestamps        │
                                   │              ▼                                 │
                                   │ Étape 3 : Inférence VLM                        │
                                   │   VLM embarqué (Cosmos Reason 1/2)             │
                                   │   Échantillonnage d'images à VLM_FPS → classif │
                                   │              │ étiquettes d'actions            │
                                   │              ▼                                 │
                                   │ Étape 4 : Vérificateur SOP                     │
                                   │   Validation de séquence → manquantes/mal ord. │
                                   │              │ résultats chunk                 │
                                   │              ▼                                 │
                                   │         final_queue                            │
                                   └────────────────────────────────────────────────┘
                                          │
Sortie                                    ▼
──────                             ┌─────────────────┐
Flux SSE (chat.completion.chunk)   │ Messages Kafka   │
Sans streaming (chat.completion)   │ (JSON/Protobuf)  │
Métriques Prometheus (/v1/metrics) └────────┬────────┘
                                            ▼
                                   Conteneur Docker : kafka
                                   (apache/kafka:3.7.0)

Index des Sections

Chaque section est un fichier autonome dans references/ — charger uniquement ce que votre tâche nécessite.

Pour l'évaluation de bout en bout, lire d'abord § 12 ; charger build/test/curl/latency/camera/Kafka au besoin.

§ 18 est opt-in — générer uniquement quand l'utilisateur demande explicitement la sortie RTSP ; sinon ignorer § 18 et les règles RTSP_* ci-dessous.

Cartographie des Fichiers Clés

La cartographie complète source-vers-cible se trouve dans skill_14_implementation_checklist.md :

• Fichiers copiés textuellement depuis references/ (algorithmes non triviaux — détection de cycles, prétraitement qwen_vl_utils, API DeepStream IOptions, sources protobuf) avec la justification par fichier.
• Fichiers copiés comme modèles adaptables (Dockerfile, compose.yaml, config Triton et model.py, ddm_net.py, config émulation Pylon, etc.).
• Fichiers générés à partir des sections de compétence — chacun annoté avec les règles critiques ci-dessous que la génération doit suivre exactement.

Les fichiers de config (nvds_preprocess_template.txt, nvds_inference_template.txt, vlm_prompts.txt) sont utilisés tels quels depuis configs/.

Quand skill_06b est chargée, lire configs/actions.json depuis la racine du projet et exécuter le flux de génération § 6b-G pour produire nvds_action_detector/missing_number_detector.py. Si configs/actions.json est absent ou invalide, revenir à copier le fichier de référence.

Règles Critiques

Le détail complet de chaque règle se trouve dans le fichier de référence skill_NN_*.md lié.

Les quatre règles RTSP_* ci-dessous s'appliquent uniquement quand la fonctionnalité optionnelle sortie streaming RTSP (§ 18) est demandée. Elles ne s'appliquent pas au build par défaut — les ignorer si l'utilisateur n'a pas demandé la sortie RTSP.

| RTSP_OUTPUT_TAPS_TEE1 | La branche sortie RTSP se lie depuis le tee1 existant (ajouté après le lien d'inférence principal) uniquement quand rtsp_port est présent. | skill_18_rtsp_streaming_output.md | | RTSP_LEAKY_QUEUE_TINY | Queue branche RTSP doit avoir leaky=2 + cap minuscule (max-size-buffers=2) pour prévenir contre-pression et épuisement pool NVMM. | skill_18_rtsp_streaming_output.md | | RTSP_KEYINT_MAX_30 | Encodeur H.264 RTSP doit définir key-int-max=30 (et B-frames désactivés) pour permettre recherche en aval. | skill_18_rtsp_streaming_output.md | | RTSP_ENCODER_FALLBACK | Sélectionner encodeur H.264 logiciel/matériel basé sur SW_ENCODER avec fallback MJPEG. | skill_18_rtsp_streaming_output.md |