Socialify AI Engine
Développeur solo•Projet Personnel•Août 2025
Microservice IA stateless et optimisé GPU pour la classification de priorité des messages et la détection de contexte. Conçu avec FastAPI pour un scaling horizontal en production, avec inférence locale CUDA ou cloud via Groq.
Technologies
Contexte & Objectif
Construire un microservice de classification IA (priorité + contexte des messages) entièrement découplé de toute application cliente, pensé pour du scaling horizontal en production plutôt que comme une démo notebook — avec un vrai plan de repli si aucun GPU n'est disponible.
Objectifs techniques :
- Classification 3 classes en temps réel (low/medium/high) + détection de contexte sur 8 catégories
- Rester stateless pour permettre le scaling horizontal (plusieurs instances derrière un load balancer, sans état partagé)
- Fonctionner aussi bien avec un GPU CUDA local (BERT fine-tuné) que sans GPU du tout (repli automatique sur l'API cloud Groq)
Architecture & Choix Techniques
Un service FastAPI stateless : un modèle bert-base-uncased fine-tuné (repli sur DistilBERT si les poids personnalisés sont absents) tourne sur CUDA quand un GPU est présent ; sans GPU, le service bascule automatiquement sur l'API Groq (Mixtral-8x7B) sans changer le contrat de réponse côté appelant. Deux endpoints de prédiction (/predict, réponse complète ; /predict-message, format allégé pour l'intégration backend), plus /health, /gpu-status, /model-info et des métriques au format Prometheus. Conçu pour tourner en plusieurs répliques (un manifest Kubernetes fourni en spécifie 3, avec probes liveness/readiness) derrière un load balancer, sans base de données ni état partagé entre requêtes.
Le Processus
Détection de contexte — classification par mots-clés sur 8 catégories (travail, personnel, finance, achats, santé, voyage, éducation, social), volontairement simple plutôt que d'ajouter un second modèle juste pour ça.
Boucle de feedback — chaque prédiction est journalisée en JSONL avec un identifiant unique ; un endpoint /feedback permet de soumettre le bon label, et un script de surveillance déclenche un ré-entraînement automatique une fois un seuil de retours atteint (20+ entrées).
Double mode de déploiement — un Dockerfile avec support GPU (--gpus all) et un repli CPU/cloud piloté par une simple variable d'environnement (GROQ_API_KEY), donc la même image se déploie sur une machine avec carte NVIDIA ou sans.
Défis Techniques & Solutions
Défi — servir un modèle GPU en production sans dépendre d'un GPU disponible partout. Un déploiement tout-GPU serait fragile (coût, disponibilité). Solution : détection automatique au démarrage — le service utilise le modèle BERT local si un GPU CUDA est présent, sinon bascule de façon transparente sur l'API Groq (Mixtral), l'appelant recevant le même format de réponse dans les deux cas.
Défi — permettre au modèle de s'améliorer sans pipeline MLOps lourd. Solution : un cycle volontairement léger feedback → log JSONL → surveillance de seuil → ré-entraînement (des fichiers plutôt qu'une plateforme MLOps complète), mais qui ferme réellement la boucle prédiction → correction → amélioration.
Résultats & Impact
- Benchmarks documentés : ~45ms d'inférence et ~2 200 req/min sur une RTX 4090 (contre ~450ms / ~130 req/min en CPU seul)
- Précision constante à 91.2% quel que soit le GPU testé (RTX 4090 ou RTX 3080)
- Architecture stateless validée pour le scaling horizontal : manifest Kubernetes à 3 réplicas avec load balancer et probes liveness/readiness
- Service entièrement conteneurisé (image Docker Hub) avec repli cloud automatique, déployable sans carte GPU