Utilisation et tarification du cloud
Capacité de l'appareil et solution de repli
—
économies mensuelles par rapport à une approche hybride sur appareil en cloud pur—% d'économies
—référence de cloud pur / mois
—hybride total / mois
Répartition des coûts
| Élément de campagne | Inférences / mois | Coût / mois |
|---|
| Base de référence purement cloud (100 % cloud, pas sur l'appareil) | — | — |
| — utilisateurs cloud uniquement (non compatibles avec l'appareil) | — | — |
| — solution de secours dans le cloud pour les utilisateurs disposant de capacités sur l'appareil | — | — |
| = Facture cloud hybride | — | — |
| + Coût d'installation amorti sur l'appareil | — | — |
| = Coût mensuel total hybride | — | — |
Seuil de rentabilité sur le coût d'installation unique
—
Comment cela se connecte à d'autres outils
Deux calculateurs déjà présents sur ce site évaluent une décision similaire mais structurellement différente. Le Calculateur de coût d'auto-hébergement et d'API et le Calculateur LLM auto-hébergé vs API les deux modèles côté serveur auto-hébergement : louer votre propre GPU ou instance cloud et y exécuter vous-même l'inférence, par rapport au paiement d'un fournisseur par jeton ou par appel. Dans les deux cas, le coût est toujours celui d'un serveur quelque part avec une vraie facture d'hébergement, un seul que vous contrôlez au lieu de celui d'un fournisseur. Cette calculatrice modélise à la place côté client l'inférence sur l'appareil s'exécutant directement sur le matériel téléphonique de l'utilisateur final : pas de serveur à louer, un coût marginal par inférence effectivement nul une fois le modèle livré, et un goulot d'étranglement complètement différent : pas d'heures GPU, mais quelle fraction de vos utilisateurs possède des appareils suffisamment performants et à quelle fréquence même ces appareils doivent encore recourir au cloud. Si vous hésitez entre louer un boîtier GPU et payer une API cloud, utilisez les calculatrices auto-hébergées ; si vous décidez d'expédier un modèle quantifié dans votre application mobile elle-même, c'est celui qui correspond à cette forme de coût.
Lire les chiffres
Avec les valeurs par défaut : 100 000 utilisateurs actifs mensuels, 50 inférences par utilisateur et par jour, 0,001 $ par inférence cloud, une version unique de 40 000 $ sur l'appareil, 60 % des utilisateurs sur des appareils compatibles, un taux de repli du cloud de 5 % sur ces utilisateurs capables, amorti sur 12 mois - la base de référence du cloud pur s'élève à 150 000 $/mois. Le passage à l'hybride ramène la facture cloud résiduelle à 64 500 $/mois (60 000 000 d'inférences provenant d'utilisateurs cloud uniquement plus 4 500 000 inférences de secours d'utilisateurs capables), ajoute environ 3 333 $/mois en coût de configuration amorti et aboutit à un total hybride proche de 67 833 $/mois, soit une économie d'environ 82 167 $/mois, soit environ 55 % de réduction sur la base de référence du cloud pur. Le coût d'installation de 40 000 $ lui-même atteint le seuil de rentabilité en moins d'un demi-mois à ce volume, car les dépenses mensuelles dans le cloud qu'il détourne (environ 85 500 $/mois) éclipsent presque immédiatement le coût de construction unique. Ce calcul change rapidement à petite échelle : exécutez les mêmes entrées sur 5 000 utilisateurs au lieu de 100 000 et le seuil de rentabilité s'étend jusqu'à environ 20 fois plus longtemps – environ 9,4 mois au lieu de moins d'un demi-mois – parce qu'il n'y a tout simplement pas suffisamment d'inférences détournées par mois pour récupérer rapidement le coût de construction. Branchez le véritable MAU de votre application, et non un objectif ambitieux, avant d'engager un budget d'ingénierie dans une version sur l'appareil.
Comment fonctionne cette calculatrice
Le Calculateur d'inférence IA Edge/sur appareil et d'API Cloud calcule d'abord une référence de cloud pur : inférences par utilisateur et par jour × utilisateurs actifs mensuels × 30, au prix de votre tarif cloud par inférence : c'est ce que vous paieriez sans aucun modèle sur appareil. Il divise ensuite votre base d'utilisateurs par pourcentage de capacité sur l'appareil en utilisateurs compétents et utilisateurs cloud uniquement. Les utilisateurs cloud uniquement génèrent une facture cloud complète pour chacune de leurs inférences, puisque leurs appareils ne peuvent pas du tout exécuter le modèle local. Les utilisateurs dotés de capacités sur appareil exécutent principalement l'inférence localement à un coût marginal effectivement nul, sauf pour un pourcentage de repli dans le cloud de leurs requêtes (trop complexes, batterie faible, démarrage à froid avant la fin du téléchargement du modèle local ou résultat local peu fiable) qui sont toujours facturées par rapport à l'API cloud.
Délibérément, cette calculatrice fait pas chiffrez le calcul sur l'appareil, l'épuisement de la batterie ou l'empreinte de stockage elle-même - cela traite le coût marginal d'une inférence locale comme nul une fois le modèle expédié. Il s'agit d'une simplification réaliste pour les petits modèles bien quantifiés fonctionnant sur des puces phares modernes, où le coût incrémentiel de la batterie et du calcul par inférence est négligeable à côté d'une facture d'API cloud. Il sous-estime le coût réel des très gros modèles intégrés ou des appareils plus anciens/bas de gamme, où la limitation thermique, l'épuisement de la batterie et la pression de stockage sont des coûts réels (bien qu'ils soient difficiles à évaluer en dollars) qui méritent d'être pesés séparément. Les inférences résiduelles relatives au cloud uniquement et au cloud de secours sont résumées dans un facture de cloud hybride, alors le coût de configuration unique sur l'appareil (ingénierie, quantification, expédition) est divisé par la fenêtre d'amortissement que vous avez choisie et ajouté en haut pour obtenir le coût mensuel total hybride. En comparant cela avec la référence du cloud pur, vous obtenez les économies mensuelles et le pourcentage d'économies, tout en divisant le coût de configuration par le mensuel les dépenses cloud qu'il détourne (cloud pur moins facture de cloud hybride, en ignorant l'amortissement) donnent l'autonomie seuil de rentabilité en mois — la rapidité avec laquelle la construction unique est rentabilisée grâce aux seules économies réalisées dans le cloud.
Questions fréquemment posées
Pourquoi l'inférence sur l'appareil a-t-elle un coût unique au lieu d'un coût par inférence comme les API cloud ?
Parce que la partie coûteuse de l’inférence sur l’appareil consiste à la construire, pas à l’exécuter. Quantifier un modèle jusqu'à une taille adaptée à un téléphone, le convertir au format Core ML ou TensorFlow Lite / NNAPI, le tester sur tous les niveaux d'appareils et l'expédier dans le binaire de l'application ou en tant qu'actif téléchargeable est un projet d'ingénierie fixe avec un prix fixe, payé une fois, qu'un utilisateur ou dix millions d'utilisateurs finissent par l'exécuter. Une API cloud facture à la place par requête, car le temps GPU du fournisseur représente un véritable coût marginal pour chaque appel. Une fois que le modèle sur l'appareil est quantifié et expédié, exécuter une inférence supplémentaire sur le propre téléphone d'un utilisateur ne coûte pratiquement rien au propriétaire de l'application au-delà d'un morceau de batterie et de calcul de l'utilisateur - pas de serveur, pas de facture par appel - ce qui est exactement ce qui transforme le coût d'installation unique en quelque chose qui mérite d'être amorti sur des mois plutôt que de dépenser par appel.
Que se passe-t-il si mon pourcentage de capacité sur l'appareil est faible : est-ce que l'appareil cesse d'en valoir la peine ?
Oui, et cette calculatrice est conçue pour montrer exactement où se trouve cette ligne. À mesure que le pourcentage de capacités sur appareil diminue, une plus grande partie de votre base d'utilisateurs retombe dans le compartiment cloud uniquement, de sorte que la facture mensuelle résiduelle de cloud remonte vers la référence de base du cloud pur tandis que vous payez toujours pour amortir le coût de configuration en plus - à un pourcentage de capacité suffisamment faible, l'approche hybride peut coûter plus que ce que le cloud pur aurait jamais eu, pas moins. L'autre levier tout aussi important est le volume total d'inférence : le même coût de configuration qui s'amortit en moins d'un mois pour 100 000 utilisateurs actifs mensuels peut prendre plusieurs mois, voire ne jamais atteindre le seuil de rentabilité au cours de la durée de vie d'un produit, pour quelques milliers d'utilisateurs, car il n'y a tout simplement pas assez d'inférences détournées de la facture cloud pour récupérer le coût de construction. Avant d'engager un budget d'ingénierie pour une construction sur appareil, il vaut la peine de brancher votre MAU réelle et votre meilleure estimation réelle de la capacité de l'appareil plutôt que de supposer que les économies diminuent de manière linéaire.
Pourquoi y a-t-il toujours une facture cloud, même pour les utilisateurs travaillant sur un appareil ?
Parce que la capacité sur l’appareil n’est jamais tout ou rien dans la pratique. Même sur un téléphone entièrement capable d'exécuter le modèle local, une partie des requêtes doivent encore être envoyées vers le cloud : une requête trop complexe ou trop éloignée de la portée du modèle local pour qu'une version compressée sur l'appareil puisse être correctement gérée, une situation de batterie faible ou de limitation thermique dans laquelle le système d'exploitation restreint le calcul sur l'appareil, une fenêtre de démarrage à froid avant la fin du téléchargement de l'actif du modèle local après l'installation ou la mise à jour, ou simplement une inférence locale qui revient avec un faible niveau de confiance et nécessite une revérification d'un modèle cloud. ça. Ce calculateur modélise cela sous la forme d'un pourcentage de repli sur le cloud appliqué uniquement aux requêtes des utilisateurs compatibles sur l'appareil, en plus de la facture cloud complète encore due par les utilisateurs dont les appareils ne peuvent pas du tout exécuter l'inférence sur l'appareil - de sorte que l'élément de ligne cloud résiduel dans le total hybride n'est jamais nul, même à des taux de capacité des appareils très élevés.
En quoi est-ce différent du calculateur LLM vs API auto-hébergé déjà présent sur ce site ?
Le calculateur auto-hébergé vs API et le calculateur auto-hébergé LLM vs API déjà présents sur ce modèle d'auto-hébergement côté serveur : louer votre propre instance GPU ou cloud box et y exécuter l'inférence vous-même, par rapport au paiement d'un fournisseur cloud par jeton ou par appel - la forme du coût dans les deux cas est toujours un serveur quelque part avec une facture d'hébergement, juste la vôtre au lieu de celle d'un fournisseur. Ce calculateur modélise quelque chose de structurellement différent : une inférence côté client sur l'appareil exécutée directement sur le matériel téléphonique de l'utilisateur final, où il n'y a pas de serveur à louer et où le coût marginal par inférence est effectivement nul une fois le modèle livré. Ce qui remplace la facture d'hébergement ici, c'est un coût d'ingénierie unique pour construire et quantifier le modèle, amorti sur des mois, plus un plafond plafonné sur le montant des dépenses cloud que vous pouvez réellement détourner - défini par la fraction de vos utilisateurs possédant des appareils suffisamment performants et à quelle fréquence même ces appareils doivent encore recourir au cloud.