AesCode 8B : estimer le coût d’une tâche de génération de code esthétique

Pourquoi le coût par jeton ne suffit pas

Le coût de génération d’une page avec AesCode 8B ne se limite pas nécessairement aux jetons d’entrée et de sortie. Le modèle produit des artefacts visuels structurés en HTML et CSS, et le processus décrit par le projet comprend le rendu du résultat dans un navigateur ainsi que la vérification de propriétés du code et de la page. Si le résultat ne respecte pas les critères définis, une équipe peut aussi décider de le corriger ou de générer une nouvelle version.

Il est donc utile de distinguer le coût de l’inférence, celui de la vérification et celui des itérations. Dans un déploiement local, ces composantes peuvent mobiliser des ressources différentes : l’inférence peut utiliser un GPU, tandis que le rendu et certains contrôles peuvent mobiliser le processeur, la mémoire et le navigateur. Le coût dépend de la manière dont ces ressources sont affectées et de la politique de nouvelles tentatives.

La documentation d’AesCode décrit la méthode et ses vérificateurs, mais ne publie ni tarifs, ni latences par vérification, ni taux universel de réussite dès le premier essai. Les chiffres de ce guide sont des variables à renseigner pour effectuer vos propres calculs, pas des mesures d’AesCode 8B. Les résultats agrégés du projet ne correspondent pas non plus à la probabilité qu’une tâche donnée satisfasse tous les critères d’un produit.

Les composantes du coût

Une estimation utile distingue les phases du processus au lieu d’attribuer un coût unique à chaque génération. L’inférence comprend le traitement du prompt et la production du HTML et du CSS. Sa durée dépend notamment du matériel, de la configuration du modèle, de la longueur de l’entrée et du nombre de jetons générés.

La vérification décrite par le projet consiste à afficher le HTML dans un navigateur Playwright et à exécuter des contrôles déterministes. Ceux-ci portent notamment sur l’exécution, le texte, les limites des éléments, les données des tableaux et graphiques, la mise en page sémantique et les espaces blancs. Le dépôt documente le fonctionnement de ces contrôles, mais pas leur consommation de ressources ni leur latence par tâche.

L’itération intervient lorsque le processus nécessite une nouvelle génération ou une correction après la détection d’un défaut. Les équipes ne procèdent pas toutes de la même façon : certaines limitent le nombre de tentatives, d’autres ne corrigent que le code, et d’autres encore prévoient une revue humaine. Le coût moyen dépend de cette politique, des ressources consommées à chaque étape et des résultats observés sur des tâches représentatives.

Modèle de calcul et hypothèses

Pour estimer le coût de l’inférence par tentative, divisez le nombre de jetons générés par le débit effectif de génération. Vous obtenez ainsi une durée approximative. Si le coût du GPU est exprimé par heure, convertissez la durée dans la même unité et multipliez-la par le tarif ou le coût interne correspondant. Cette approximation ne représente pas à elle seule toute l’utilisation du système, notamment lorsque les requêtes sont simultanées ou que les ressources sont partagées.

La vérification doit être évaluée en fonction des ressources qu’elle utilise réellement. Si Playwright et les vérificateurs sollicitent le processeur, appliquer sans distinction un tarif horaire de GPU ne reflète pas nécessairement leur coût. Pour une estimation plus fidèle, mesurez et valorisez séparément chaque type de ressource. L’exemple de code conserve un tarif commun uniquement pour illustrer la structure du calcul.

Le facteur 1/p ne peut estimer le nombre moyen de tentatives que sous certaines hypothèses : les tentatives sont indépendantes, la probabilité de réussite reste constante et les tentatives se poursuivent jusqu’à la réussite, sans limite. Dans ces conditions, on calcule d’abord le coût combiné de l’inférence et de la vérification par tentative, puis on applique une seule fois le facteur attendu. Le taux de réussite au premier essai ne suffit pas, à lui seul, à démontrer que ces hypothèses sont respectées. Si les tentatives suivantes changent de stratégie, de coût ou de probabilité, ou si leur nombre est plafonné, il faut adapter le modèle.

def calculer_tco(tokens_sortie, jetons_par_sec, cout_gpu_heure, secondes_verif, taux_reussite):
    if jetons_par_sec <= 0 or cout_gpu_heure < 0 or secondes_verif < 0:
        raise ValueError("Les durées et les coûts doivent être valides")
    if not 0 < taux_reussite <= 1:
        raise ValueError("taux_reussite doit être compris entre 0 et 1")

    temps_inference = tokens_sortie / jetons_par_sec
    cout_inference = (temps_inference / 3600) * cout_gpu_heure
    cout_verification = (secondes_verif / 3600) * cout_gpu_heure
    facteur_iterations = 1 / taux_reussite

    return (cout_inference + cout_verification) * facteur_iterations

Exemple hypothétique : 100 présentations

Supposons, uniquement pour illustrer le calcul, une sortie moyenne de 5 000 jetons générée à 50 jetons par seconde, une vérification de 10 secondes par tentative et un coût de 2 USD par heure. L’exemple applique le même tarif à l’inférence et à la vérification pour simplifier ; il n’affirme ni que la vérification sollicite un GPU ni que ces valeurs correspondent à une installation réelle d’AesCode 8B.

Avec ces hypothèses, l’inférence dure 100 secondes et la vérification 10 secondes par tentative. Le coût combiné s’élève à 110/3600 × 2 = 0,061111 USD par tentative. Si l’on suppose également un taux de réussite de 80 %, des tentatives indépendantes, une probabilité constante et des tentatives illimitées jusqu’à l’acceptation, le facteur moyen est de 1/0,8 = 1,25. Le coût estimé par tâche acceptée est donc de 0,061111 × 1,25, soit environ 0,076389 USD. Pour 100 tâches, l’estimation atteint 7,64 USD.

Cet exemple ne correspond ni à un tarif ni à un résultat mesuré. Le résultat change si le débit, la durée de vérification, le coût des ressources, le taux de réussite ou la politique de nouvelles tentatives change. Sous ces hypothèses, le coût attendu varie en raison inverse de la probabilité de réussite ; il n’augmente pas de façon exponentielle.

Établir votre propre estimation

Une estimation opérationnelle doit reposer sur le même matériel, la même configuration et le même processus que ceux prévus pour le déploiement. Avant les mesures, définissez ce qu’est une tâche acceptée : par exemple, les exigences de contenu à respecter et les défauts visuels qui justifient un rejet. Sans critères stables, le taux de réussite ne permet pas de comparer les configurations de façon cohérente.

Consignez séparément l’inférence, le rendu et chaque vérification. Pour chaque tâche, notez les jetons d’entrée et de sortie, la durée et les ressources utilisées à chaque tentative, les défauts détectés et le nombre de nouvelles tentatives. Si le processus limite leur nombre, autorise des corrections partielles ou prévoit une revue humaine, intégrez ces règles au calcul au lieu de supposer que le même processus est répété jusqu’à la réussite.

Un jeu de tests doit représenter les prompts, les images de référence et les types de pages attendus dans l’application. Un petit test peut fournir une première approximation, mais son taux de réussite ne garantit pas les résultats d’autres tâches. La complexité, la charge simultanée, la configuration du navigateur et le matériel peuvent modifier aussi bien la durée que le coût.

Portée des résultats et limites de l’estimation

L’évaluation publiée du projet rapporte des résultats agrégés pour 300 échantillons d’infographies, avec trois générations par prompt et sans sélection entre les générations. Ces métriques décrivent les performances sur le benchmark et ses dimensions d’évaluation ; elles ne constituent pas un taux général de réussite au premier essai pour toute application, tout prompt ou tout critère d’acceptation. Elles ne démontrent pas non plus qu’une page ayant passé les contrôles déterministes est prête à être livrée sans examen visuel.

Le dépôt décrit le rendu avec Playwright, six vérificateurs déterministes et des canaux d’évaluation visuelle. Il ne publie ni le coût ou la durée de chaque vérification, ni la consommation de processeur ou de GPU par tâche, ni un taux universel de réussite initiale. La configuration employée pour une évaluation ne permet pas non plus de déduire à elle seule la mémoire nécessaire ou les performances sur un autre matériel.

Le résultat du calcul doit donc être interprété comme une estimation conditionnée par les mesures et les hypothèses retenues. Distinguer les coûts du GPU et du processeur, expliciter la politique de nouvelles tentatives et utiliser des critères d’acceptation reproductibles facilitent la comparaison entre déploiements ; cela ne garantit pas que le coût ou la qualité resteront les mêmes si le matériel, la charge ou les prompts changent. »

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.