Tirer parti de RunPod pour l'inférence AI évolutive et rentable

Nous avons adopté RunPod comme couche de calcul GPU, en utilisant leurs instances GPU à la demande (on-demand) et spot pour exécuter les charges de travail d'inférence AI à une fraction des coûts GPU cloud traditionnels, avec une architecture d'instances "chaudes" (warm-instance) pour minimiser les démarrages à froid (cold starts).

Architecture

• Calcul : Pods GPU RunPod pour les charges de travail d'inférence, avec le niveau de GPU sélectionné par charge de travail
• Orchestration : Orchestrateur FastAPI sur le cloud principal gérant les pods RunPod
• Réseautage : Tunnels sécurisés entre l'infrastructure principale et les instances RunPod
• Stockage de modèles : Images Docker pré-construites avec des modèles intégrés pour un démarrage rapide
• Surveillance : Vérifications de santé (health checks) et redémarrage automatique pour la disponibilité des pods

Conception de l'infrastructure

Configuration des pods

• Sélection GPU : Niveaux de GPU rentables sélectionnés par charge de travail, permettant des économies de ~85-90 % par rapport aux instances GPU équivalentes des principaux fournisseurs de cloud
• Modèles Docker : Conteneurs personnalisés avec des modèles AI préchargés pour l'inférence
• Stockage persistant : Volumes réseau pour les poids de modèle et les fichiers de configuration
• Variables d'environnement : Configuration dynamique pour les points d'accès des flux (stream endpoints), les clés API et les indicateurs de fonctionnalité (feature flags)

Stratégie d'instance "chaude"

Au lieu de démarrer les pods à froid (cold-starting) à chaque requête, nous maintenons des instances "chaudes" (warm instances) pendant les heures d'ouverture :

1. Mise à l'échelle planifiée — Pods démarrés avant les heures de pointe, arrêtés pendant les heures creuses
2. Modèles préchargés — Moteurs d'inférence chargés au démarrage du conteneur, prêts immédiatement
3. Sondes de santé — L'orchestrateur surveille régulièrement les pods RunPod pour vérifier leur état de préparation
4. Récupération automatique — Les pods défectueux sont automatiquement remplacés via l'API RunPod

Communication inter-cloud

• Cloud principal : Serveurs API, bases de données, travailleurs d'enregistrement (recording workers)
• Cloud GPU (RunPod) : Inférence AI, détection d'objets, suivi
• Flux de données : Les images vidéo sont envoyées du cloud principal à RunPod pour l'inférence ; les résultats de détection sont renvoyés via WebSocket
• Synchronisation d'horodatage : Synchronisation basée sur le PTS pour gérer le décalage d'horloge entre les clouds

Optimisation des coûts

Le modèle de tarification de RunPod a permis des économies significatives par rapport aux instances GPU équivalentes des principaux fournisseurs de cloud :

• À la demande (On-Demand) : Réduction de ~85-90 % du coût horaire de calcul GPU
• Tarification Spot : Économies supplémentaires de 50 % pour le traitement par lots non critique sur le cloud communautaire
• Arrêt planifié : L'arrêt/démarrage automatisé basé sur les heures d'ouverture réduit davantage les coûts
• Dimensionnement approprié (Right-Sizing) : Sélection du niveau de GPU correspondant aux besoins réels en VRAM plutôt que le sur-provisionnement
• Distribution multi-pod : Répartition des flux sur des GPU plus petits et moins chers au lieu d'une seule grande instance

Flux de travail de déploiement

1. Construction (Build) — Image Docker avec tous les modèles, dépendances et le code de l'application
2. Push — Image poussée vers le registre de conteneurs
3. Déploiement (Deploy) — L'API RunPod crée un pod avec le GPU, l'image et les montages de volume spécifiés
4. Configuration (Configure) — Variables d'environnement définies pour le déploiement spécifique
5. Surveillance (Monitor) — L'orchestrateur vérifie la santé du pod et commence à acheminer les requêtes d'inférence
6. Mise à l'échelle (Scale) — Pods supplémentaires lancés via l'API lorsque la charge augmente

Fonctionnalités clés

1. Réduction significative des coûts — 85-90 % d'économies par rapport aux instances GPU équivalentes des principaux fournisseurs de cloud
2. Conteneurs pré-construits — Modèles intégrés dans des images Docker pour un démarrage en moins de 30 secondes
3. Mise à l'échelle pilotée par API — Création/destruction programmatique de pods basée sur la demande
4. Support multi-GPU — Plusieurs niveaux de GPU disponibles en fonction des exigences de la charge de travail
5. Repli sur instances Spot — Les charges de travail non critiques s'exécutent sur le cloud communautaire à prix réduit
6. Architecture inter-cloud — Le calcul GPU découplé de l'infrastructure principale