Développeur Cherche des Conseils d'Architecture pour Servir des Modèles d'Embedding, de Reclassement et Zero-Shot sur 8 Go de VRAM

Aperçu du problème

Un développeur crée un service unifié de graphe de connaissances/RAG pour un agent de codage local qui s'exécute dans un seul conteneur Docker via FastAPI. Le système fonctionnait correctement au départ sous Windows (WSL), mais le passage à Linux natif a révélé de graves problèmes de limites de mémoire lors des tests de stress.

Contraintes matérielles et de modèles

Matériel :

• 8 Go de VRAM (GPU portable)
• ~16 Go de RAM système (les limites de Docker sont rapidement atteintes, généralement seulement ~6 Go de libre lorsque les modèles sont chargés)

Stack de modèles :

• Embedding : nomic-ai/nomic-embed-text-v2-moe
• Reranking : BAAI/bge-reranker-base
• Classification : MoritzLaurer/ModernBERT-large-zeroshot-v2.0 (utilisé pour classer des paires de texte en 4 relations : dépendance, expansion, contradiction, sans rapport)

Défis techniques

Le développeur ne peut pas tronquer agressivement le texte car il alimente ces modèles avec des morceaux de code et du texte naturel et doit traiter des séquences longues et variables.

Problèmes spécifiques rencontrés :

• Latence vs. OOM : L'utilisation de torch.cuda.empty_cache() pour garder le GPU propre provoque des pics de latence à 18-20 secondes par requête en raison des synchronisations du pilote. Le retirer provoque un OOM instantané du GPU lorsque des requêtes concurrentes surviennent.
• Explosion de la RAM système (Linux Exit 137) : L'utilisation du pipeline Hugging Face ("zero-shot-classification") a provoqué un gonflement massif de la RAM CPU. Sans troncature, le pipeline génère d'énormes matrices de combinaisons en mémoire avant de les envoyer au GPU, ce qui entraîne l'arrêt instantané du conteneur par le noyau Linux.
• Pics de VRAM : cudnn.benchmark = True mettait en cache des espaces de travail pour chaque longueur de séquence unique, drainant 3 Go de VRAM libre en quelques secondes lors des tests de stress.

Implémentation actuelle

Le développeur a une configuration pure Python/FastAPI avec les solutions de contournement suivantes :

• Contournement du pipeline HF et écriture d'une boucle d'inférence NLI manuelle pour ModernBERT
• Utilisation de asyncio.Lock() pour forcer une exécution en série (un seul modèle utilise le GPU à la fois)
• Utilisation d'une désallocation déterministe (del inputs + gc.collect()) via des tâches en arrière-plan FastAPI

Cette approche est meilleure mais reste instable lors d'un test de stress de 3 minutes.

Questions pour la communauté

Le développeur recherche des conseils sur :

• Alternatives de modèles : Des modèles plus petits/rapides qui maintiennent une haute précision pour le Zero-Shot NLI et le Reranking, mieux adaptés à un environnement de 8 Go
• Architectures préconstruites : A précédemment examiné infinity_emb mais a eu du mal à intégrer une logique de classification NLI à 4 voies personnalisée sans double chargement de modèles. Envisage TEI (Text Generation Inference), TensorRT, ou d'autres solutions optimisées pour les modèles Encodeur
• Stratégie de service : Modèles de conception standard pour héberger 3 modèles de transformateurs sur un seul GPU grand public sans qu'ils n'empiètent sur la mémoire les uns des autres