MicrocosmWorksInnover et Architecturer le Cosmos Numérique
À proposContact
MicrocosmWorksInnover et architecturer des cosmos numériques

Fournir des solutions informatiques qui comptent. Nous sommes passionnés par la technologie, la sécurité et aidons les entreprises à croître grâce à une infrastructure informatique fiable et innovante.

[email protected]
+91 7011868196
New Delhi, India

Hub de Croissance IA

Hub IAInnovation pour les startupsAccélérateur d'entreprise

Solutions

Toutes les solutionsApplications de bien-être et de fitnessPlateforme vidéo IADéveloppement d'agents IA

Ressources

PerspectivesGuides de l'industriePlans d'utilisationModèles d'architectureÉtudes de cas

Entreprise

À propos de nousContactNotre travail

Services

Consultation numériqueInfrastructure cloudDéveloppement SaaSDéveloppement IATechnologie vidéo
Développement ERPPersonnalisation ZohoDéveloppement OdooIntégration SalesforceDéveloppement CRM personnalisé
Intégration QuickBooksSolutions IoTDéveloppement Blockchain
Consultation en cybersécuritéSupport IT - L3

© 2026 MicrocosmWorks. Tous droits réservés.

Politique de confidentialitéConditions d'utilisation
Retour aux Études de Cas
GPU InfrastructurePublié June 22, 2026 · Mis à jour June 22, 2026

On-Off Scaling Pattern pour les charges de travail d'AI et de traitement vidéo

Une plateforme de traitement vidéo basée sur l'AI devait gérer des charges de travail très variables — de zéro tâche pendant les heures creuses à des centaines de tâches concurrentes de traitement vidéo et d'inférence AI pendant les périodes de pointe — sans payer pour des ressources GPU et de calcul inactives.

Discutez de Votre Projet
on-off-pattern-ai-video-processing.webp
GPU Infrastructure
Domain
10
Technologies
5
Key Results
Delivered
Status

Le Défi

Les charges de travail d'AI et de traitement vidéo sont intrinsèquement irrégulières et coûteuses :

  • Les instances GPU sont coûteuses qu'elles traitent des tâches ou qu'elles soient inactives
  • L'encodage vidéo, la transcription et l'inférence AI exigent des profils de ressources différents
  • Le rapport crête-creux était de 50:1 — plus de 200 tâches pendant les pics, quasi-nul pendant la nuit
  • L'auto-scaling traditionnel était trop lent (démarrage à froid de 5 à 10 min) pour les requêtes utilisateur sensibles au temps
  • L'infrastructure fixe provisionnée pour les pics entraînait plus de 80 % de gaspillage pendant les heures creuses

Notre Solution

Nous avons mis en œuvre un On-Off scaling pattern — une architecture hybride où les ressources de calcul sont provisionnées juste-à-temps pour les charges de travail actives et entièrement désallouées lorsqu'elles sont inactives, avec des warm pools pour les tâches sensibles à la latence et des cold pools pour les tâches batch.

Architecture

  • Job Queue : File d'attente de tâches basée sur une base de données avec classification des priorités
  • Orchestrator : Service gérant le cycle de vie des ressources et le routage des tâches
  • GPU Workers (AI) : Pods GPU Cloud pour l'inférence (détection d'objets, transcription, détection de locuteur)
  • CPU Workers (Vidéo) : VMs Cloud pour l'encodage et le rendu vidéo
  • Warm Pool : Instances pré-initialisées pour les tâches sensibles à la latence (démarrage < 30s)
  • Cold Pool : Instances à la demande pour le traitement batch/en masse (démarrage de 2 à 5 min acceptable)

Implémentation du On-Off Pattern

États du cycle de vie des ressources

Les ressources suivent un cycle de vie défini : de l'état entièrement désalloué (coût zéro), en passant par le provisionnement et le "warming" (chargement des modèles, contrôles de santé), aux états prêt et en traitement, puis à travers une fenêtre de "cooldown" avant de revenir à l'état désalloué.

Stratégie de Warm Pool

Pour le traitement sensible à la latence (initié par l'utilisateur, résultats attendus en quelques minutes) :

  • Maintenir un minimum de warm pool d'instances pendant les heures de bureau
  • Pré-charger les modèles AI au démarrage des conteneurs
  • Router les tâches entrantes vers les instances warm en premier
  • Scaler d'autres instances warm lorsque la profondeur de la queue dépasse un seuil
  • Un minuteur de cooldown configurable maintient les instances actives entre les tâches sporadiques

Stratégie de Cold Pool

Pour le traitement batch (tâches en masse de nuit, ré-encodages non urgents) :

  • Zéro instance en cours d'exécution par défaut
  • La Job Queue déclenche le provisionnement lorsque des tâches batch sont soumises
  • Instances optimisées pour le traitement en masse, privilégiant le débit à la latence
  • Terminer immédiatement après l'achèvement du batch
  • Utiliser des instances spot/préemptibles pour des économies de coûts significatives

Classification et Routage des tâches

Les tâches sont automatiquement classifiées par priorité et par type, puis routées vers le pool approprié :

  • Les tâches AI initiées par l'utilisateur de haute priorité sont routées vers les warm GPU pools
  • Les tâches en temps réel critiques sont routées vers des instances dédiées toujours actives
  • Les tâches d'encodage de priorité moyenne sont routées vers des warm ou cold CPU pools
  • Les tâches batch de basse priorité sont routées vers des instances cold spot/préemptibles

Logique de l'Orchestrator

Déclencheurs de Scale-Up

  • La profondeur de la queue dépasse un seuil configurable
  • Le temps d'attente moyen dépasse le SLA pour le niveau de priorité
  • Montée en puissance planifiée avant les heures de pointe connues
  • Déclenchement manuel via l'API admin pour les pics de trafic anticipés

Déclencheurs de Scale-Down

  • Aucune tâche traitée pendant la durée de la fenêtre de cooldown
  • Réduction planifiée après les heures de pointe
  • Toutes les tâches en file d'attente terminées sans nouvelles soumissions
  • Seuil de coût atteint pour la période de facturation

Santé et Récupération

  • Sondes de santé régulières sur toutes les instances actives
  • Les instances non saines sont remplacées automatiquement
  • Les tâches échouées sont remises en queue avec un compte de tentatives et routées vers une instance différente
  • Dead letter queue pour les tâches dépassant le nombre maximal de tentatives

Impact sur les coûts

Le On-Off pattern a permis une réduction des coûts d'environ 70% par rapport à une infrastructure fixe toujours active, en éliminant le calcul inactif pendant les heures creuses, en dimensionnant correctement les ressources par type de tâche, et en tirant parti des instances spot pour les charges de travail batch.

Fonctionnalités clés

  1. Coût d'inactivité nul — Ressources entièrement désallouées lorsqu'elles ne traitent pas de tâches
  2. Warm Pools — Instances pré-initialisées pour les charges de travail sensibles à la latence
  3. Cold Pools — Provisionnement à la demande pour les tâches batch au coût le plus bas
  4. Classification des tâches — Routage automatique basé sur la priorité, le type et les exigences de latence
  5. Fenêtres de Cooldown — Le délai d'inactivité configurable empêche le scale-down prématuré entre les rafales
  6. Support Spot/Preemptible — Les tâches batch sont routées vers des instances à prix réduit pour des économies significatives
  7. Santé et Récupération — Remplacement automatique des instances non saines avec remise en queue des tâches
  8. Scaling Planifié — Anticiper les modèles de trafic connus avec des règles de provisionnement basées sur le temps

Résultats

Réduction des coûts : ~70% d'économies par rapport à une infrastructure fixe toujours active
Latence : < 30 secondes de démarrage à froid pour les instances warm pool
Fiabilité : L'auto-récupération et la remise en queue des tâches ont maintenu un taux d'achèvement des tâches de 99,5 % et plus

Stack Technologique

Node.jsMongoDBRunPod APICloud VM APIsDockerFastAPIFFmpegRedisJob QueueCron Scheduling

caseStudyDetail.more Études de Cas

Découvrez plus de nos implémentations techniques

GPU Infrastructure

Utiliser RunPod pour une inférence d'AI évolutive et rentable

Une plateforme d'analyse vidéo basée sur l'AI avait besoin d'une capacité de calcul GPU haute performance pour la détection d'objets et l'inférence en temps réel sur plusieurs flux vidéo simultanés, sans le coût prohibitif de serveurs GPU dédiés fonctionnant 24h/24 et 7j/7.

Lire l'Étude de Cas
AI Accounting

Traitement de factures assisté par l'IA avec OCR et intégration QuickBooks

Une entreprise de taille moyenne, traitant des centaines de factures fournisseurs chaque mois, devait éliminer la saisie manuelle des données en extrayant automatiquement les données des factures à l'aide de l'IA/OCR et en les synchronisant directement dans QuickBooks pour la tenue de livres et le suivi des paiements.

Lire l'Étude de Cas

Prêt à Transformer Votre Entreprise ?

Discutons de la façon dont nous pouvons appliquer des solutions similaires à vos défis.

Contactez-NouscaseStudyDetail.viewAllCaseStudies
Flexibilité : Différents niveaux GPU/CPU pour différents types de tâches ont optimisé le coût par tâche
Évolutivité : A géré plus de 200 tâches concurrentes pendant les pics avec zéro infrastructure pré-provisionnée pendant les heures creuses
Video Encoding

Insertion d'annonces côté client (CSAI) avec analyse des marqueurs SCTE-35 et intégration de lecteurs multiplateformes

Une plateforme de streaming vidéo devait implémenter l'insertion d'annonces côté client (CSAI) sur les applications web, mobiles et de télévision connectée — permettant des expériences publicitaires personnalisées au niveau de l'appareil avec un support complet d'interaction publicitaire (superpositions cliquables, bannières complémentaires, boutons de saut) que l'insertion côté serveur ne peut pas offrir.

Lire l'Étude de Cas

Questions fréquemment posées

MicrocosmWorks a développé le modèle de mise à l'échelle on-off pour les charges de travail qui présentent des pics prévisibles de traitement intensif en GPU suivis de longues périodes d'inactivité, où l'auto-scaling traditionnel gaspille de l'argent en maintenant une capacité minimale pendant les périodes d'inactivité. Au lieu de maintenir des instances chaudes en cours d'exécution, le modèle provisionne l'infrastructure GPU à la demande lorsqu'un travail de traitement arrive, exécute la charge de travail et met fin complètement à l'infrastructure une fois terminé, atteignant un coût quasi nul pendant les périodes d'inactivité.

MicrocosmWorks a réduit les temps de démarrage à froid à moins de 60 secondes en pré-construisant des images de conteneurs optimisées avec tous les poids de modèles AI et les dépendances intégrés, stockées dans un registre géographiquement proche de la région de calcul. La couche d'orchestration utilise le provisionnement prédictif pour les charges de travail planifiées, démarrant l'infrastructure 2-3 minutes avant la demande prévue, et pour les charges de travail imprévisibles, le système met en file d'attente les tâches et envoie des notifications de début de traitement afin que les utilisateurs sachent que leur requête est en cours de traitement.

MicrocosmWorks a documenté des réductions de coûts de 70 à 90 % pour les clients dont les charges de travail de traitement vidéo par AI s'exécutent 2 à 6 heures par jour, par rapport au maintien d'instances GPU 24h/24 et 7j/7. Les économies proviennent du fait de ne payer que pour le temps de traitement réel, plus quelques minutes de frais généraux de démarrage et d'arrêt, et le modèle est particulièrement efficace pour les flux de travail tels que le traitement vidéo par lots nocturne, le transcodage à la demande ou l'analyse AI déclenchée par événement, où l'utilisation est intrinsèquement intermittente.

Oui, MicrocosmWorks a implémenté une architecture de type fan-out au sein du on-off pattern qui provisionne plusieurs workers GPU en parallèle lorsque de grandes tâches par lots (batch jobs) arrivent, distribue les fichiers vidéo entre les workers à l'aide d'une job queue, et arrête tous les workers une fois le lot terminé. Le système suit la progression par vidéo et gère les échecs vidéo individuels avec une retry logic sans bloquer le reste du lot, et consolide les résultats dans un emplacement de sortie unique pour une consommation en aval.

MicrocosmWorks implémente des architectures de mise à l'échelle on-off à des tarifs de développement de 25 à 45 $/heure, avec une implémentation prête pour la production, comprenant l'orchestration des tâches, le provisionnement de l'infrastructure, la surveillance et la gestion des défaillances, généralement livrée en 3 à 5 semaines. L'investissement en développement se rentabilise généralement en 1 à 2 mois grâce aux seules économies de coûts GPU, en particulier pour les organisations qui exécutent actuellement des instances GPU toujours actives qui restent inactives plus de 50 % de la journée.