Semi-conducteursVision industrielle →

Inspection visuelle de wafers 100 % on-prem

Reconstruction et stabilisation d'un pipeline de vision sur infrastructure GPU locale. Déblocage d'un POC abandonné pour saturation mémoire : sans cloud ni refonte MES.

×2,3

de débit d'inspection sur le même volume

−55 %

de temps de cycle par image

erreur GPU OOM après tuning

Contexte

Le problème

Goulot d'étranglement au contrôle manuel

Les opérateurs passaient les dossiers image par image via scripts ad hoc. Pas d'interface standard, pas de modèle homogène entre équipes.

GPU sous-exploité, batch en échec

Le matériel GPU sur le LAN fab était largement inactif : chaque tentative batch-32 terminait en OOM et forçait un retour au traitement unitaire.

7+ minutes par lot de 108 images

Trois wafers, 108 images : plus de sept minutes sur un run propre, avec retries en cas d'échec GPU.

Aucune piste d'audit conformité

Pas d'identifiant opérateur, pas de log terminal, pas de trace par image : les revues qualité n'avaient rien à exploiter.

Solution

Architecture déployée

Préparation

Découpage parallèle des tuiles

Split 10 parties, normalisation CHW sur CPU (Parallel.For). Préparation batch sans bloquer le thread GPU.

Inférence

TritonClientWrapper natif C++

DLL compilée contre le SDK Triton (gRPC++, protobuf). Remplace les appels HTTP REST depuis C# : latence et marshalling réduits. Batch-32 stable après tuning pool CUDA 2 Go et BFCArena ONNX.

Modèle

YOLOv8 ONNX : 6 classes de défaut

Rayures porteuse, rayures verticales, fissures, éclats, particules, autres marques. Seuil de confiance 0,7, bounding boxes sur images pleine résolution.

Sortie

JPEG, CSV, résumé audit

Traitement intégral sur le LAN fab. Dossier entrée → images annotées sortie. Aucun appel cloud. Journal par run pour revue qualité.

Résultats

Résultats observés

Mesurés en conditions de production sur le périmètre déployé.

62–66 s

Cycle par image

Contre 135–152 s avant optimisation : mesuré sur le même lot de référence.

~3,2 min

Temps lot 108 images

Contre 7+ minutes avec retries et fallback single-shot.

Batch-32

Succès au premier essai

Après réglage pool mémoire, instance unique et allocation ONNX BFCArena.

Air-gapped

Déploiement on-prem

Pas de refonte MES, pas d'outils développeur exposés au plancher. Production dès le premier déploiement.

Retour d'expérience

Ce qu'on en retient

Les échecs OOM viennent souvent du chemin d'appel (REST managé) et du pool CUDA mal dimensionné : pas du modèle lui-même.

Un wrapper gRPC natif vers Triton est rentable dès que le batch dépasse quelques images par seconde.

La traçabilité opérateur/terminal doit être conçue en même temps que le pipeline : pas en couche après coup.

Ne pas abandonner un POC GPU sans audit mémoire (fragmentation, nombre d'instances, stratégie d'allocation ONNX).

Le déploiement on-prem exige une UX opérateur aboutie : dossier in → dossier out, sans terminal de commande.

Démarrer

Un cas similaire sur votre site ?

Décrivez-nous le processus, les données disponibles et les contraintes de déploiement. Nous évaluerons la faisabilité sous 48h.

Discuter d'un cas similaire Domaine : Vision industrielle