Coûts et optimisation

Comprendre la structure des coûts

Le fine-tuning OpenAI engendre deux types de coûts : le coût d’entraînement, ponctuel, et le coût d’inférence, récurrent. Comprendre et optimiser ces coûts est essentiel pour un déploiement rentable. La distinction n’est pas seulement comptable : le premier se décide une fois, avant de lancer le job, et ne bouge plus ; le second vous suit tous les mois et croît avec votre trafic. Une équipe qui négocie âprement son coût d’entraînement tout en laissant filer un prompt de mille tokens sur cinq mille requêtes quotidiennes se trompe de combat.

Le coût d’entraînement

L’entraînement est facturé au nombre de tokens traités, et ce nombre dépend directement de deux grandeurs que vous maîtrisez : la taille de votre jeu de données et le nombre de passages effectués dessus.

Coût entraînement = tokens_totaux × nombre_epochs × prix_par_token_entrainement

La formule permet d’estimer la facture avant de lancer quoi que ce soit. La fonction suivante parcourt le fichier JSONL et approxime le compte de tokens à partir de la longueur des messages — l’estimation d’un token pour quatre caractères en français reste grossière, mais elle suffit à distinguer un job à quelques dollars d’un job à plusieurs centaines. Prenez l’habitude de la lancer systématiquement : une erreur de préparation qui triple votre jeu de données se voit immédiatement dans le résultat.

import json

def estimer_cout_entrainement(
    fichier_jsonl: str,
    n_epochs: int,
    prix_par_million_tokens: float
) -> dict:
    """Estime le coût d'entraînement avant de lancer le job."""
    total_tokens = 0

    with open(fichier_jsonl, "r") as f:
        nb_exemples = 0
        for ligne in f:
            nb_exemples += 1
            obj = json.loads(ligne)
            for msg in obj["messages"]:
                # Estimation grossière : 1 token ~ 4 caractères en français
                total_tokens += len(msg["content"]) // 4

    tokens_entrainement = total_tokens * n_epochs
    cout = tokens_entrainement * prix_par_million_tokens / 1_000_000

    return {
        "exemples": nb_exemples,
        "tokens_par_passage": total_tokens,
        "epochs": n_epochs,
        "tokens_total": tokens_entrainement,
        "cout_estime": f"{cout:.2f} $"
    }

resultat = estimer_cout_entrainement(
    "training_data.jsonl",
    n_epochs=3,
    prix_par_million_tokens=8.0  # vérifiez le tarif actuel
)

for k, v in resultat.items():
    print(f"{k} : {v}")

Le coût d’inférence

L’inférence est facturée par appel, au nombre de tokens en entrée et en sortie, et les modèles fine-tunés ont généralement un tarif légèrement supérieur au modèle de base. Ce surcoût unitaire fait souvent hésiter, à tort : il porte sur beaucoup moins de tokens, puisque le comportement autrefois décrit dans un long prompt système est désormais intégré au modèle. Le calcul ci-dessous met les deux scénarios côte à côte sur un mois de trafic identique, avec un prompt qui passe de 800 à 100 tokens face à des tarifs doublés. Modifiez les paramètres avec vos propres chiffres avant de conclure : sur un usage où le prompt était déjà court, l’arbitrage s’inverse.

def cout_mensuel(
    requetes_par_jour: int,
    tokens_input_moyen: int,
    tokens_output_moyen: int,
    prix_input_par_million: float,
    prix_output_par_million: float
) -> float:
    """Calcule le coût mensuel d'inférence."""
    requetes_mois = requetes_par_jour * 30
    cout_input = requetes_mois * tokens_input_moyen * prix_input_par_million / 1_000_000
    cout_output = requetes_mois * tokens_output_moyen * prix_output_par_million / 1_000_000
    return cout_input + cout_output

# Scénario : modèle de base avec long prompt
cout_base = cout_mensuel(
    requetes_par_jour=5000,
    tokens_input_moyen=800,    # long prompt système + question
    tokens_output_moyen=200,
    prix_input_par_million=0.15,
    prix_output_par_million=0.60
)

# Scénario : modèle fine-tuné avec prompt minimal
cout_ft = cout_mensuel(
    requetes_par_jour=5000,
    tokens_input_moyen=100,    # prompt court, comportement intégré
    tokens_output_moyen=200,
    prix_input_par_million=0.30,  # tarif FT plus élevé
    prix_output_par_million=1.20
)

print(f"Coût mensuel base : {cout_base:.2f} $")
print(f"Coût mensuel fine-tuné : {cout_ft:.2f} $")
print(f"Différence : {cout_ft - cout_base:+.2f} $")

Réduire les tokens d’entrée

Le principal levier d’économie avec un modèle fine-tuné est la réduction du prompt. Chaque instruction que vous parvenez à supprimer parce que le modèle l’a intégrée est un gain répété à chaque appel, jusqu’à la fin de vie du service. Le tableau ci-dessous donne les ordres de grandeur observés selon le degré d’intégration atteint.

Ne supprimez pas ces instructions d’un bloc en espérant que tout tienne. Retirez-les par groupes, en repassant votre jeu de test après chaque retrait : vous découvrirez que certaines règles ont été parfaitement apprises tandis que d’autres, moins représentées dans vos exemples, doivent rester dans le prompt.

Doser le jeu de données et les epochs

Plus de données donne un meilleur modèle, mais aussi un coût d’entraînement plus élevé, et le rendement décroît. Passer de cent à trois cents exemples change généralement beaucoup ; passer de mille à trois mille change peu, pour trois fois le prix. Entraînez plusieurs tailles, mesurez la qualité obtenue et rapportez-la au coût pour situer votre point d’équilibre.

def trouver_optimal(resultats_par_taille: dict):
    """Identifie la taille de dataset optimale."""
    print("Taille dataset | Score qualité | Coût entraînement")
    print("-" * 55)

    meilleur_ratio = 0
    taille_optimale = 0

    for taille, data in sorted(resultats_par_taille.items()):
        score = data["score"]
        cout = data["cout"]
        ratio = score / cout if cout > 0 else 0

        print(f"{taille:>14} | {score:>13.2f} | {cout:>17.2f} $")

        if ratio > meilleur_ratio:
            meilleur_ratio = ratio
            taille_optimale = taille

    print(f"\nTaille optimale : {taille_optimale} exemples")

Le choix du modèle de base pèse dans la même balance. Luna est moins cher que Terra, tant en entraînement qu’en inférence : commencez toujours par le modèle le moins cher et ne montez en gamme que si la qualité obtenue est insuffisante. Vérifiez au passage quels modèles sont éligibles au fine-tuning dans la documentation OpenAI — la liste évolue à chaque génération et ne recouvre jamais tout le catalogue. Reste le nombre d’epochs, puisque chaque passage supplémentaire multiplie mécaniquement le coût d’entraînement. Si 2 epochs donnent 95 % de la qualité de 4 epochs, le choix est vite fait.

Surveiller la dépense en production

L’estimation faite avant le lancement ne vaut que pour l’entraînement. En production, c’est le trafic réel qui commande, et il surprend souvent à la hausse. Un compteur alimenté à chaque appel, adossé à un budget mensuel, vous alerte avant que la facture ne vous l’apprenne. Le seuil de 80 % laisse le temps de réagir : réduire un prompt, plafonner la longueur des réponses ou basculer une partie du trafic vers un modèle moins cher.

class CostTracker:
    """Suivi des coûts en temps réel."""

    def __init__(self, budget_mensuel: float):
        self.budget = budget_mensuel
        self.depenses = 0.0
        self.appels = 0

    def enregistrer(self, tokens_input: int, tokens_output: int,
                    prix_input: float, prix_output: float):
        """Enregistre le coût d'un appel."""
        cout = (
            tokens_input * prix_input / 1_000_000 +
            tokens_output * prix_output / 1_000_000
        )
        self.depenses += cout
        self.appels += 1

        # Alerte si on approche du budget
        utilisation = self.depenses / self.budget * 100
        if utilisation > 80:
            print(f"ALERTE : {utilisation:.1f}% du budget mensuel utilisé")

    def rapport(self):
        """Rapport de consommation."""
        print(f"Appels : {self.appels}")
        print(f"Dépenses : {self.depenses:.2f} $")
        print(f"Budget restant : {self.budget - self.depenses:.2f} $")
        if self.appels > 0:
            print(f"Coût moyen par appel : {self.depenses / self.appels:.4f} $")

Justifier l’investissement

Reste à répondre à la question que votre direction posera tôt ou tard : au bout de combien de temps l’entraînement est-il remboursé ? Le calcul rapporte un coût ponctuel à un bénéfice mensuel, lequel additionne l’économie de tokens et la valeur que vous attribuez au gain de qualité. Ce second terme est le plus délicat, et il vaut mieux le laisser à zéro que de l’inventer : un amortissement démontré sur les seules économies mesurables emporte davantage la conviction qu’une projection généreuse.

def calculer_roi(
    cout_entrainement: float,
    economie_mensuelle: float,
    gain_qualite_valeur: float = 0
) -> dict:
    """Calcule le retour sur investissement du fine-tuning."""
    benefice_mensuel = economie_mensuelle + gain_qualite_valeur
    mois_amortissement = cout_entrainement / benefice_mensuel if benefice_mensuel > 0 else float("inf")

    return {
        "cout_entrainement": f"{cout_entrainement:.2f} $",
        "benefice_mensuel": f"{benefice_mensuel:.2f} $",
        "amortissement": f"{mois_amortissement:.1f} mois",
        "roi_annuel": f"{(benefice_mensuel * 12 - cout_entrainement) / cout_entrainement * 100:.0f}%"
    }

Points clés à retenir

• Estimez le coût d’entraînement avant de lancer le job
• Le principal levier d’économie est la réduction des tokens d’entrée
• Commencez par le modèle de base le moins cher (Luna) avant de monter vers Terra
• Surveillez les coûts en production avec des alertes de budget
• Calculez le ROI en incluant les gains de qualité et les économies de tokens