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

Nous avons adopté RunPod comme couche de calcul GPU, en utilisant leurs instances GPU à la demande 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 pour minimiser les démarrages à froid.

Architecture

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

Conception de l'infrastructure

Configuration des pods

• Sélection du GPU : Niveaux de GPU rentables sélectionnés par charge de travail, permettant des économies d'environ 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 des modèles et les fichiers de configuration
• Variables d'environnement : Configuration dynamique pour les points d'accès de flux, les clés API et les indicateurs de fonctionnalités

Stratégie d'instances chaudes

Au lieu de démarrer des pods à froid par requête, nous maintenons des instances chaudes pendant les heures de fonctionnement :

1. Mise à l'échelle planifiée — Les pods sont démarrés avant les heures de pointe, arrêtés pendant les heures creuses
2. Modèles préchargés — Les moteurs d'inférence sont 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, workers d'enregistrement
• 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 des horodatages : Synchronisation basée sur les 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 :

• On-Demand : Réduction d'environ 85 à 90 % du coût horaire de calcul GPU
• Spot Pricing : Économies supplémentaires de 50 % pour le traitement par lots non critique sur le cloud communautaire
• Arrêt programmé : L'arrêt/démarrage automatisé basé sur les heures de fonctionnement réduit davantage les coûts
• Right-Sizing : Sélectionner le niveau de GPU correspondant aux besoins réels en VRAM plutôt que de sur-approvisionner
• Distribution multi-pod : Répartir les flux sur des GPU plus petits et moins chers au lieu d'une seule grande instance

Flux de travail de déploiement

1. Build — Image Docker avec tous les modèles, dépendances et le code d'application
2. Push — L'image est poussée vers le registre de conteneurs
3. Deploy — L'API RunPod crée un pod avec le GPU, l'image et les montages de volume spécifiés
4. Configure — Les variables d'environnement sont définies pour le déploiement spécifique
5. Monitor — L'orchestrateur vérifie la santé du pod et commence à acheminer les requêtes d'inférence
6. Scale — Des pods supplémentaires sont 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 les images Docker pour un démarrage en moins de 30 secondes
3. API-Driven Scaling — 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. Spot Instance Fallback — Les charges de travail non critiques s'exécutent sur un cloud communautaire à prix réduit
6. Architecture inter-cloud — Le calcul GPU est découplé de l'infrastructure principale