Hugging Face Endpoints : plus de 547 $ malgré les creux

Un Inference Endpoint dédié peut coûter plus de 547 $ par mois alors que son modèle reste sans requête entre les pointes : la tarification de Hugging Face chiffre à 547,50 $ un scénario de 730 heures avec un GPU à 0,50 $/h, une réplique permanente et deux autres actives 15 minutes chaque heure. La réplique permanente représente 365 $ de ce total, qu’elle traite ou non des requêtes pendant les périodes creuses.

Pour prévoir la facture, multipliez le tarif horaire de l’instance par les heures cumulées de toutes les répliques. Calculez séparément la capacité minimale, présente même lorsque le trafic s’interrompt, et les répliques ajoutées pendant les pointes. Une baisse des requêtes ne réduit le coût que lorsque le nombre de répliques facturées diminue.

Construire le calcul à partir des minutes facturables

Commencez par choisir l’instance adaptée au modèle et relevez son tarif pour le fournisseur et la région retenus. Le prix est affiché à l’heure, mais le coût des ressources est calculé à la minute, pendant leur initialisation comme pendant leur exécution. La durée des requêtes seules ne suffit donc pas : une réplique disponible entre deux appels continue d’accumuler du temps facturable.

Dans une feuille de calcul, créez une ligne pour chaque période où le nombre de répliques est constant. Notez la durée en minutes, le nombre de répliques et le tarif horaire, puis appliquez tarif horaire × minutes × répliques ÷ 60. Additionnez les lignes pour obtenir le total. Si le minimum reste stable tout le mois, son coût se calcule directement par « tarif × heures du mois × répliques minimales » ; ajoutez ensuite les heures de chaque réplique supplémentaire.

Le mois de 730 heures utilisé ici est une hypothèse de calcul, à remplacer par la durée de la période que vous budgétez. Pour l’AWS CPU intel-spr x2, le tableau tarifaire affiche 0,067 $/h, alors que l’exemple mensuel CPU figurant sur la même page utilise 0,064 $/h. Les prévisions CPU ci-dessous retiennent le tarif du tableau pour l’instance nommée ; mélanger ces deux taux fausserait le résultat.

Trois profils de trafic, du CPU au GPU

Comparaison du coût mensuel calculé pour une réplique CPU et une réplique GPU sur Hugging Face Inference Endpoints.

Ces profils sont des prévisions conditionnelles, pas des mesures de trafic. Ils isolent la part due au matériel, au minimum de répliques et au temps passé au-dessus de ce minimum.

CPU disponible en continu. Avec une instance AWS CPU intel-spr x2 à 0,067 $/h, un minimum et un maximum d’une réplique coûtent 0,067 × 730 = 48,91 $ pour le mois hypothétique. Une nuit sans requête ne change rien tant que cette réplique reste active. Ce profil convient au calcul d’un service qui doit pouvoir répondre sans attendre un démarrage.
GPU à usage intermittent. Supposons un GPU à 0,50 $/h, un minimum de zéro et 120 heures cumulées de réplique facturable : le calcul donne 60 $. Les 120 heures sont une hypothèse qui inclut les démarrages, le traitement et les périodes où la réplique reste active après la dernière requête. Si ces périodes durent plus longtemps que prévu, la facture augmente même si le nombre de requêtes reste identique.
GPU avec pointes régulières. Dans le scénario chiffré plus haut, la réplique minimale coûte 0,50 × 730 = 365 $. Deux répliques supplémentaires présentes pendant un quart du temps ajoutent 0,50 × 182,5 × 2 = 182,50 $, pour un total de 547,50 $. Allonger les pointes ou maintenir davantage de répliques accroît la seconde partie de la facture.

Régler le minimum et le plafond de répliques

Le minimum fixe à la fois la capacité immédiatement disponible et le coût de base. Le maximum limite les répliques que l’autoscaling peut ajouter lors d’une forte charge ; pour estimer l’exposition financière, calculez aussi ce que coûterait une période prolongée à ce plafond. Ce maximum doit rester compatible avec le trafic à servir : le réduire uniquement pour tenir un budget peut laisser des requêtes en attente.

Le guide d’autoscaling de Hugging Face décrit notamment un seuil d’utilisation CPU ou GPU de 80 % par défaut, une évaluation de la montée chaque minute et une descente plus lente avec stabilisation. Une pointe de requêtes et la période pendant laquelle des répliques supplémentaires restent actives n’ont donc pas nécessairement la même durée. Pour affiner la prévision, utilisez les minutes de présence des répliques, puis confrontez cette hypothèse au comportement du service déployé.

Passer à zéro sans promettre une réponse immédiate

Une réplique de Hugging Face Inference Endpoints reste disponible pendant la plage de service, puis une requête attend son redémarrage après le passage à zéro.

Quand les plages de trafic sont prévisibles, une programmation quotidienne peut garder une réplique minimale pendant les heures de service et autoriser le passage à zéro hors de cette plage. Le réglage à zéro n’éteint pas forcément l’endpoint à l’instant où la plage se termine : il prévoit un délai d’inactivité avant l’arrêt. La feuille de calcul doit inclure ce délai et toute période durant laquelle une réplique reste active après la dernière requête.

Une fois l’endpoint passé à zéro, aucune réplique ne continue d’accumuler du coût de calcul. La requête suivante provoque toutefois un démarrage à froid qui peut prendre plusieurs minutes selon le modèle ; pendant l’initialisation, le proxy peut renvoyer le code 503. Le client peut prévoir cette attente, notamment au moyen de l’en-tête X-Scale-Up-Timeout, ou le service peut conserver une réplique pendant les plages où la rapidité de la première réponse compte.

Le choix dépend ainsi du coût des heures maintenues disponibles et du délai que l’application accepte après une période creuse. Un trafic faible ne suffit pas à lui seul pour choisir zéro réplique : quelques appels espacés peuvent maintenir la capacité active, puis subir malgré tout un démarrage à froid après une interruption plus longue.

Vérifications avant la mise en production

Vérifiez que l’instance choisie offre assez de mémoire pour le modèle et peut être sélectionnée dans la région voulue. Relevez ensuite le tarif affiché, le minimum, le maximum, la stratégie d’autoscaling et, si vous utilisez une programmation quotidienne, les plages horaires et le délai de passage à zéro. Établissez une prévision pour le trafic ordinaire et une autre pour une pointe soutenue ; la différence montre la part du budget exposée à la montée en charge.

Après le déploiement, remplacez les durées supposées par les périodes réellement passées à chaque nombre de répliques. Avant de lancer l’endpoint, vérifiez aussi la facturation du compte : les conditions d’accès à Inference Endpoints exigent un moyen de paiement valide pour l’utilisateur ou son organisation. Vous disposerez ainsi d’un budget calculé sur la configuration que le compte peut effectivement déployer.