Comment une startup ML a réduit sa facture AWS de 22 000 $ en corrigeant la planification

Une startup spécialisée dans l'apprentissage automatique, composée de huit ingénieurs, a récemment réduit sa facture mensuelle d'infrastructure cloud de près de cinq mille dollars. L'équipe a réalisé ces économies non pas en réécrivant ses modèles d'inférence ou en changeant de types d'instances, mais en alignant son calendrier d'utilisation des GPU sur les schémas réels de demande des utilisateurs. Ce cas met en évidence comment la temporalité opérationnelle, plutôt que la seule efficacité architecturale, engendre des différences de coûts significatives dans les environnements cloud.

Ce qui s'est passé

La startup exploitait une API d'inférence en production servant du trafic réel, ce qui entraînait une facture AWS de 22 000 $ par mois. La majeure partie de ce coût provenait des ressources de calcul GPU utilisées pour l'inférence des modèles. Lorsqu'un consultant a examiné le compte, il s'attendait à trouver du matériel surdimensionné ou un code inefficace. Au lieu de cela, il a constaté que les types d'instances étaient bien adaptés à la charge de travail et que les taux d'utilisation pendant les heures actives étaient raisonnables. Il n'y avait aucun gaspillage technique évident dans l'architecture elle-même.

La cause profonde du coût élevé était temporelle, et non technique. L'analyse des journaux de trafic a révélé que quatre-vingt-dix pour cent de toutes les demandes des utilisateurs se produisaient entre 9 h et 23 h, heure de l'Est des États-Unis. La période nocturne était presque silencieuse, ne comprenant que des vérifications automatiques de santé et de petites tâches en arrière-plan. Malgré cette absence de demande, les instances GPU fonctionnaient à pleine capacité et à plein tarif vingt-quatre heures sur vingt-quatre. L'équipe avait maintenu le cluster à sa taille maximale la nuit parce que cela lui semblait plus sûr, entraînant huit heures d'utilisation quasi nulle chaque soir.

Pour remédier à cela, l'équipe a mis en œuvre un calendrier de réduction d'échelle. À 23 h (heure de l'Est), le cluster d'inférence réduit son échelle vers un état minimal chaud. Cet état est suffisant pour gérer les tâches en arrière-plan et répondre aux vérifications de santé, mais consomme beaucoup moins de ressources. À 8 h (heure de l'Est), avant l'afflux matinal de trafic, le cluster revient à sa pleine capacité. L'ensemble du changement n'a pris que deux jours pour être implémenté et testé en toute sécurité.

Détails clés

• La facture AWS mensuelle de la startup s'élevait à 22 000 $, principalement due aux coûts de calcul GPU pour l'inférence.
• L'analyse du trafic a montré que 90 % des demandes se produisaient entre 9 h et 23 h, heure de l'Est des États-Unis.
• Les instances GPU tournaient à pleine capacité 24h/24 et 7j/7, malgré huit heures de trafic utilisateur quasi nul chaque nuit.
• La solution consistait à réduire l'échelle vers un état minimal chaud à 23 h et à augmenter l'échelle à 8 h (heure de l'Est).
• La mise en œuvre a pris deux jours pour être testée et déployée sans modifier l'architecture sous-jacente ni les modèles.
• L'ajustement a permis des économies mensuelles de 4 800 $ en alignant l'allocation des ressources sur la demande réelle.

Contexte

Dans le cloud computing, en particulier avec des matériels spécialisés comme les GPU, les coûts sont souvent liés au temps de fonctionnement plutôt qu'au seul traitement actif. De nombreuses équipes ont tendance à maintenir les clusters à leur capacité maximale pour garantir une faible latence et une haute disponibilité, craignant que la réduction d'échelle n'introduise des risques ou des retards. Cette approche, souvent appelée « sur-provisionnement pour la sécurité », peut entraîner un gaspillage important lors des creux prévisibles du trafic.

Le FinOps, ou opérations financières, est la pratique de gestion des coûts cloud grâce à la collaboration entre les équipes d'ingénierie et de finance. Un principe fondamental du FinOps consiste à faire correspondre les dépenses à la valeur commerciale. Dans ce contexte, cela signifie veiller à ce que les ressources coûteuses ne tournent que lorsqu'elles servent activement les utilisateurs. Les politiques d'auto-scaling automatisées permettent aux équipes d'ajuster dynamiquement les ressources en fonction du temps ou de la charge, comblant ainsi le fossé entre fiabilité technique et efficacité financière.

Pourquoi c'est important

Pour les équipes qui gèrent leur propre infrastructure logicielle, ce cas illustre que l'optimisation des coûts ne nécessite pas toujours un refactoring complexe. Les ingénieurs se concentrent souvent sur l'efficacité du code ou l'indexation de base de données pour réduire les coûts, négligeant les calendriers opérationnels. Lorsque les schémas de trafic sont prévisibles, comme dans les applications B2B ayant des heures ouvrées distinctes, des politiques d'auto-scaling statiques peuvent laisser de l'argent sur la table. Reconnaître que la « sécurité » via une capacité constante de pointe a une pénalité financière directe est un changement d'état d'esprit crucial pour les responsables DevOps.

De plus, cette histoire souligne l'importance de la prise de décision basée sur les données dans la gestion de l'infrastructure. Sans analyser la distribution horodatée des demandes, l'équipe supposait que sa facture élevée était justifiée par une demande constante. En observant simplement quand les utilisateurs étaient réellement actifs, ils ont identifié une opportunité claire d'économies. Cette approche est applicable à de nombreux services auto-hébergés où la charge fluctue de manière prévisible, des outils internes aux API destinées aux clients.

Ce que vous pouvez faire

• Analysez les journaux de votre service pour identifier les fenêtres de trafic de pointe et hors pointe, en recherchant des motifs quotidiens ou hebdomadaires prévisibles.
• Examinez vos politiques d'auto-scaling actuelles pour voir si elles permettent des réductions d'échelle profondes pendant les périodes de faible trafic connues.
• Implémentez une configuration « état chaud » qui maintient les vérifications de santé essentielles et les workers en arrière-plan tout en réduisant les nœuds de calcul coûteux.
• Testez les événements de scaling dans un environnement de staging pour vous assurer que les temps de montée en charge n'impactent pas l'expérience utilisateur lors des pics de trafic.
• Mettez en place des alertes pour les pics de trafic inhabituels en dehors des fenêtres attendues afin de détecter les anomalies sans maintenir les ressources élevées en permanence.
• Revisitez régulièrement votre calendrier de scaling à mesure que le comportement des utilisateurs évolue, en veillant à ce que votre structure de coûts reste alignée sur la demande réelle.