Méthodologie de benchmark des modèles vidéo IA : ce qu'il faut mesurer avant de choisir

Un benchmark de modèle de vidéo par IA doit comparer la latence, la cohérence du mouvement, le respect des prompts, les limites de format et le coût par seconde de sortie, en utilisant vos propres prompts et votre propre modèle de charge, et non une bande de démonstration du fournisseur. Cet article vous donne les dimensions à mesurer, les bases de référence du coût par seconde en 2026 pour les principales API vidéo, le code pour mesurer la latence et calculer le coût par programmation, ainsi qu'un moyen de mettre à l'échelle la revue humaine au-delà d'une poignée de clips.

Benchmark des modèles de vidéo par IA : points clés

• Le coût par seconde à des niveaux comparables (720p-1080p, réglages audio similaires) varie d'environ 9x entre le bas et le haut de la fourchette de l'instantané source ci-dessous : PixVerse V6 à 0,045 $/s (fal, 720p, sans audio) contre Veo 3.1 Standard à 0,40 $/s (Google, 720p-1080p, avec audio). Des écarts plus importants existent si vous incluez la 4K ou la tarification par token, mais ils ne sont pas directement comparables, voir les limitations.
• La latence n'est couverte dans aucun des documents de tarification des fournisseurs cités dans cet article. Considérez les affirmations sur le temps de génération comme non vérifiées jusqu'à ce que vous les mesuriez vous-même, et utilisez le modèle d'horodatage ci-dessous pour le faire.
• La revue humaine ne s'adapte pas linéairement au volume de test. Utilisez un système à deux niveaux : des contrôles techniques automatisés détectent gratuitement les échecs de format, puis un échantillon stratifié est soumis à une évaluation humaine.
• Les prix de la vidéo par seconde et par requête de TokenLab suivent approximativement les données économiques unitaires rapportées par les fournisseurs dans plusieurs cas (Hailuo, Veo), ce qui constitue une vérification utile avant d'engager des dépenses, comme le montre le tableau de recoupement ci-dessous.

Instantané source : Tarification des fournisseurs pour les API vidéo (2026)

Fournisseur	Modèle / Niveau	Métrique	Valeur	Source	Observé
Google	Veo 3.1 Standard, 720p/1080p, avec audio	$/s	0,40 $	Tarification Gemini API	09-07-2026
Google	Veo 3.1 Standard, 4K, avec audio	$/s	0,60 $	Tarification Gemini API	09-07-2026
Google	Veo 3.1 Fast, 720p, avec audio	$/s	0,10 $	Tarification Gemini API	09-07-2026
Google	Veo 3.1 Lite, 720p, avec audio	$/s	0,05 $	Tarification Gemini API	09-07-2026
PixVerse	V6, 720p, sans audio	crédits/s	9	Documentation plateforme PixVerse	09-07-2026
PixVerse (via fal)	V6, 720p, sans audio	$/s	0,045 $	fal PixVerse V6	09-07-2026
PixVerse (via fal)	V6, 1080p, avec audio	$/s	0,115 $	fal PixVerse V6	09-07-2026
MiniMax	Hailuo-2.3-Fast, 768p/6s	points	0,7	Tarification vidéo MiniMax	09-07-2026
MiniMax	Standard package	$/3 760 pts	1 000 $	Tarification vidéo MiniMax	09-07-2026
Runway	veo3, toutes résolutions	crédits/s	40 (0,40 $/s à 0,01 $/crédit)	Tarification Runway API	09-07-2026
Runway	seedance2, 480p/720p	crédits/s	36 (0,36 $/s)	Tarification Runway API	09-07-2026
Kling	developer API	$/unité	0,14 $ (base d'unité non confirmée pour le coût par seconde)	Tarification Kling dev	09-07-2026

Google indique également que les modèles Veo 3.0 sont obsolètes et leur arrêt est prévu pour le 30 juin 2026, avec une recommandation de migration vers les modèles Veo 3.1 Preview ou GA Agent Platform. Si vous êtes toujours sur Veo 3.0 en production, cette migration devrait figurer sur votre feuille de route avant cette date, source ci-dessus.

Tarification des modèles vidéo en direct TokenLab

Ce tableau inclut uniquement les modèles vidéo présents dans l'instantané de tarification en direct de TokenLab, observé le 07-07-2026.

Modèle TokenLab	Unité	Tarif	Notes
veo3.1	par_seconde	0,200000 $	Prix bloqué
veo3	par_seconde	0,200000 $	Prix bloqué
veo3.1-fast	par_seconde	0,080000 $	Prix bloqué
veo3-fast	par_seconde	0,080000 $	Prix bloqué
seedance-1.0-pro	par_token (sortie)	2,205882 $	Non directement comparable au $/s, voir limitations
seedance-1.0-pro-fast	par_token (sortie)	0,617647 $	Non directement comparable au $/s
seedance-1.5-pro	par_token (sortie)	1,176471 $	Non directement comparable au $/s
seedance-2.0	par_token (sortie)	6,764706 $	Non directement comparable au $/s
seedance-2.0-fast	par_token (sortie)	5,441176 $	Non directement comparable au $/s
seedance-2.0-mini	par_token (sortie)	3,382353 $	Non directement comparable au $/s
pixverse-c1	par_seconde	0,026471 $	Prix bloqué
pixverse-v5.6	par_seconde	0,030882 $	Prix bloqué
pixverse-v6	par_seconde	0,022059 $	Prix bloqué
hailuo-2.3	par_requête	0,280000 $	Prix bloqué
hailuo-2.3-fast	par_requête	0,190000 $	Prix bloqué
hailuo-2.3-pro	par_requête	0,490000 $	Prix bloqué
hailuo-2.3-standard	par_requête	0,280000 $	Prix bloqué

Source : Preuve de modèle/tarification en direct TokenLab, observée le 07-07-2026.

Comparez-les directement sur le répertoire des modèles TokenLab, qui filtre par fournisseur et type d'unité, ou sur la page de classement des modèles pour des comparaisons au niveau des spécifications avant d'exécuter votre propre jeu de tests.

Obtenez une clé API et exécutez le premier test dès aujourd'hui : créez une clé API TokenLab et appelez pixverse-v6 ou veo3.1-fast avec le même petit échantillon de prompt pour voir le coût et le taux de réussite des travaux côte à côte, avant de vous engager dans un lot de tests plus important.

Recoupement des prix TokenLab avec les données des fournisseurs

Les prix bloqués de TokenLab ne dérivent pas directement des prix catalogue des fournisseurs, car le routage, le volume et la marge entrent tous en ligne de compte. Mais vous pouvez vérifier la tarification TokenLab par rapport à l'économie unitaire des fournisseurs en utilisant l'instantané source ci-dessus. Il s'agit d'estimations basées sur des données publiques des fournisseurs, et non sur la base de coûts interne de TokenLab.

Comparaison	Estimation dérivée du fournisseur	Prix en direct TokenLab	Delta
Hailuo-2.3-Fast, 768p/6s	0,7 pts x (1 000 $ / 3 760 pts) = ~0,186 $	0,190 $ (par_requête)	~0,004 $, correspondance proche
Hailuo-2.3 standard, 768p/6s	1 pt x (1 000 $ / 3 760 pts) = ~0,266 $	0,280 $ (par_requête)	~0,014 $, correspondance proche
Veo 3.1, équivalent sans audio	Runway veo3.1 sans audio : 20 cr/s x 0,01 $ = 0,20 $/s	0,200000 $ (par_seconde)	correspondance exacte
Veo 3.1 Fast, 720p	Catalogue Google, avec audio : 0,10 $/s	0,080000 $ (par_seconde)	TokenLab ~20 % inférieur, inclusion audio non confirmée
PixVerse V6, 360p sans audio	Revendeur fal : 0,025 $/s	0,022059 $ (par_seconde, résolution non confirmée)	proche, niveau de résolution non indiqué dans la preuve TokenLab

Considérez chaque ligne comme une indication. Les prix catalogue des fournisseurs, les prix des revendeurs (fal, Runway) et les tarifs par point des forfaits MiniMax sont trois structures de tarification différentes, et aucune ne confirme exactement à quelle résolution, quel réglage audio ou quel niveau de SLA correspond le prix bloqué par seconde de TokenLab. Vérifiez les hypothèses exactes de résolution et d'audio dans le répertoire des modèles TokenLab avant de construire un modèle de coût qui suppose une correspondance exacte.

Ce qu'un benchmark de modèle de vidéo par IA doit mesurer

Les benchmarks de texte et de code sont notés de manière déterministe : est-ce qu'il compile, est-ce qu'il correspond à une référence. La génération de vidéo n'a pas de vérité terrain équivalente. Deux exécutions du même prompt sur le même modèle peuvent différer visiblement en termes de qualité de mouvement, donc un benchmark de modèle de vidéo par IA défendable doit combiner des contrôles techniques automatisés avec une revue humaine structurée sur cinq dimensions.

1. Latence et comportement de la file d'attente

Aucun document de tarification de fournisseur cité dans cet article n'indique la latence de génération typique ou dans le pire des cas. Cela n'est pas benchmarké dans cet ensemble de preuves, et vous ne devriez pas prendre pour argent comptant les affirmations de vitesse sur la page de démonstration d'un fournisseur. Mesurez-le vous-même :

async function timedGenerate(provider, generateFn, input) {
  const t0 = Date.now();
  let submittedAt = null;
  let completedAt = null;

  try {
    const job = await generateFn(input);
    submittedAt = Date.now();

    // interroger ou s'abonner selon le SDK du fournisseur ; enregistrer chaque changement d'état
    const result = await job.completed(); // vérifier l'API d'achèvement exacte selon la doc du fournisseur
    completedAt = Date.now();

    return {
      provider,
      queueMs: submittedAt - t0,
      generationMs: completedAt - submittedAt,
      totalMs: completedAt - t0,
      status: "success",
    };
  } catch (err) {
    return {
      provider,
      totalMs: Date.now() - t0,
      status: "error",
      errorType: err?.status || "unknown",
      message: err?.message,
    };
  }
}

Exécutez ceci sur 3-4 requêtes simultanées, pas une à la fois, et stockez les p50/p90/p99 par fournisseur, pas seulement une moyenne. Le comportement de la file d'attente sous concurrence est là où les fournisseurs divergent le plus et où les pages marketing ne disent rien.

2. Cohérence du mouvement et cohérence temporelle

Il n'existe aucun score numérique standard de l'industrie entre les fournisseurs dans les preuves utilisées pour cet article. Une solution pratique : générez le même prompt sur 3-4 modèles, supprimez les étiquettes, et demandez à 2-3 évaluateurs de classer indépendamment la permanence de l'objet, la dérive de l'arrière-plan et la plausibilité physique.

3. Respect du prompt

Notez le succès/échec par élément d'instruction (sujet, nombre, direction de la caméra, composition) plutôt qu'un seul chiffre de qualité. Testez des prompts courts (moins de 15 mots), des prompts moyens avec une instruction de caméra, et des prompts longs avec de multiples contraintes de composition. Cela vous donne une ventilation sur laquelle vous pouvez agir, par exemple un modèle qui gère bien les prompts simples mais abandonne la direction de la caméra sur les longs.

4. Résolution, durée et limites de format

Vérifiez ce que chaque API prend réellement en charge à votre niveau de tarification, et non la spécification principale :

• Résolution maximale au niveau par défaut vs niveau premium
• Durée maximale du clip par appel unique, et si l'extension nécessite un appel d'assemblage séparé
• Si la génération audio est une bascule séparée qui modifie le prix, comme c'est le cas pour Veo 3.1 (Google) et PixVerse V6 (docs PixVerse, fal)

5. Coût par seconde, normalisé

Les structures de tarification diffèrent selon les fournisseurs : MiniMax facture des déductions par forfait de points, PixVerse et fal facturent à la seconde selon la résolution et le réglage audio, Runway vend des crédits plats à la seconde, Google publie des tarifs directs à la seconde par niveau. Normalisez tout en $/s à une résolution et un réglage audio fixes avant de comparer, en utilisant le tableau d'instantané source ci-dessus comme points de référence de départ.

Calcul du coût par seconde à partir d'un travail de génération

Une fois que vous avez les métadonnées du travail (durée, résolution, fournisseur), calculez le coût directement au lieu d'estimer à partir d'une grille tarifaire :

function computeCost(job, rateTable) {
  const rate = rateTable[job.provider]?.[job.resolution]?.[job.audio ? "audio" : "noAudio"];
  if (!rate) {
    throw new Error(`Aucune entrée de tarif pour ${job.provider} à ${job.resolution}, audio=${job.audio}. Vérifiez la doc de tarification avant facturation.`);
  }
  return {
    provider: job.provider,
    durationSeconds: job.durationSeconds,
    costUsd: Number((rate * job.durationSeconds).toFixed(4)),
  };
}

Remplissez rateTable à partir du tableau d'instantané source ci-dessus, et non de mémoire ou d'une capture d'écran de la page d'accueil d'un fournisseur, et revérifiez-le chaque fois que vous relancez le benchmark, car les tarifs changent.

Demande d'une génération vidéo : ce qu'il faut vérifier avant de lancer

La page du modèle fal PixVerse V6 documente un appel JavaScript subscribe pour fal-ai/pixverse/v6/text-to-video acceptant prompt, resolution, duration, et generate_audio_switch. C'est l'étendue des preuves de charge utile disponibles ici. Un wrapper client minimal utilisant uniquement ces champs documentés, avec nouvelle tentative et gestion des erreurs :

import { fal } from "@fal-ai/client";

async function generatePixVerseVideo(prompt, resolution, durationSeconds, withAudio) {
  const maxRetries = 3;

  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    try {
      return await fal.subscribe("fal-ai/pixverse/v6/text-to-video", {
        input: {
          prompt,
          resolution,
          duration: durationSeconds,
          generate_audio_switch: withAudio,
        },
        logs: true,
      });
    } catch (err) {
      const status = err?.status || err?.response?.status;

      if (status === 429 || status === 503) {
        // limite de débit atteinte ou fournisseur surchargé, attendre et réessayer
        await new Promise((r) => setTimeout(r, 2000 * attempt));
        continue;
      }
      if (status >= 400 && status < 500) {
        // erreur client, ne pas réessayer aveuglément
        throw new Error(`Requête PixVerse rejetée : ${status} ${err.message}`);
      }
      if (attempt === maxRetries) {
        throw new Error(`La génération PixVerse a échoué après ${maxRetries} tentatives : ${err.message}`);
      }
    }
  }
}

Ceci n'est pas testé contre un schéma de réponse en direct dans cet ensemble de preuves. Avant une utilisation en production, vérifiez la configuration de l'authentification, la forme exacte de l'objet de réponse, le comportement de délai d'attente et les en-têtes de limite de débit dans les docs actuelles de fal et PixVerse. La génération vidéo est intrinsèquement une sortie multimodale (images plus piste audio optionnelle) ; les charges utiles de requête et de réponse multimodales exactes doivent être confirmées dans les docs officielles avant que vous ne construisiez une automatisation de facturation ou de revue par-dessus.

Automatisation de la revue humaine à grande échelle

La revue manuelle de centaines de clips générés ne passe pas à l'échelle. Une approche à deux niveaux maintient le temps humain sur les clips qui en ont réellement besoin :

Niveau 1 : validation technique automatisée (gratuit, déterministe)

• Travail terminé vs échoué vs délai dépassé
• La durée de sortie correspond à la durée demandée
• La résolution de sortie correspond à la résolution demandée
• Le fichier n'est pas corrompu ou de longueur nulle
• Pas de sortie d'image noire ou d'image unicolore (vérification de base de l'échantillonnage d'images)

Niveau 2 : revue humaine stratifiée (échantillonnée)

• Revue de 100 % des échecs de niveau 1 pour confirmer qu'il s'agit de vrais échecs, pas de faux positifs
• Revue d'un échantillon aléatoire de 10-15 % des réussites de niveau 1 pour la cohérence du mouvement et le respect du prompt
• Utilisez la même méthode de classement en aveugle par 2-3 évaluateurs décrite ci-dessus, notée par élément de rubrique

Un pré-filtre optionnel est un LLM capable de vision notant les images extraites pour des échecs grossiers (sujet brouillé, objet demandé manquant) avant la revue humaine. Des modèles tels que Gemini 3.5 Flash ou Claude Sonnet 5 prennent en charge l'entrée multimodale dans le catalogue actuel de TokenLab, mais il n'existe aucun benchmark de précision pour ce cas d'utilisation de triage spécifique dans les preuves utilisées pour cet article. Considérez tout score de triage automatisé comme un pré-filtre pour réduire le volume de revue humaine, et non comme un jugement de qualité final, jusqu'à ce que vous ayez mesuré son taux de faux négatifs par rapport à votre propre échantillon revu par des humains.

Une liste de contrôle pratique pour le benchmark

• Définissez votre cas d'utilisation (clips sociaux, démos de produits, actifs de jeu) et choisissez des prompts qui y correspondent
• Construisez un jeu de prompts fixe couvrant une complexité courte, moyenne et longue. Cet article utilise 20 prompts comme exemple de travail, pas un nombre optimal recherché ; aucune source de fournisseur ou académique dans cet ensemble de preuves ne spécifie une taille d'échantillon idéale, donc dimensionnez le vôtre selon votre budget de revue
• Exécutez chaque prompt sur chaque modèle candidat à la même résolution et au même réglage audio
• Enregistrez la latence (p50/p90/p99), le coût par seconde calculé à partir de la durée réelle du travail, et le taux de réussite du travail
• Exécutez la validation automatisée de niveau 1 sur 100 % des sorties, puis la revue humaine de niveau 2 sur les échecs plus un échantillon de 10-15 %
• Revérifiez la tarification avant chaque cycle de test. L'instantané SSOT de cet article expire sept jours après l'observation (observé le 07-07-2026, expire le 14-07-2026). Cette cadence est spécifique à la fenêtre d'expiration de cet instantané, pas une norme industrielle publiée, mais c'est un plancher raisonnable pour la fréquence à laquelle la tarification vidéo et la disponibilité des modèles devraient être revérifiées
• Recoupez les spécifications avec le répertoire des modèles TokenLab plutôt que de vous fier à la page marketing d'un seul fournisseur

Comparaison entre les fournisseurs et les couches de routage

Si vous routez entre plusieurs fournisseurs vidéo au lieu de vous engager envers une seule API, la même discipline s'applique à la couche de routage. La comparaison OpenRouter couvre comment la surcharge de routage et la sélection des fournisseurs peuvent affecter la latence et la cohérence des coûts, ce qui compte davantage pour les travaux vidéo étant donné leur durée par rapport à une complétion de texte.

Pour une comparaison pré-exécution entre les fournisseurs vidéo actuels utilisant cette même méthodologie, voir meilleurs modèles vidéo IA API 2026. Si vous évaluez également des modèles d'image dans le même pipeline, meilleurs modèles image IA API 2026 utilise une approche mixte comparable à plus petite échelle. Pour un travail de sélection de modèles adjacents, meilleurs modèles IA pour le codage 2026 applique une discipline de cadence de re-test similaire pour une charge de travail différente.

Limitations

• Aucun document de tarification de fournisseur cité ici n'indique la latence de génération typique en secondes ou millisecondes. Les chiffres de latence dans cet article sont limités à la méthode de mesure par horodatage, et non à des benchmarks publiés.
• Les prix TokenLab Seedance sont par token de sortie, et le taux de conversion token-vers-seconde n'est pas publié dans les preuves utilisées pour cet article. Ne convertissez pas la tarification par token Seedance en $/s sans confirmer le taux d'encodage avec TokenLab ou le fournisseur du modèle.
• La tarification développeur Kling est décrite en "unités" avec une référence de prix catalogue de 0,14 $ provenant d'un instantané de recherche, et non un tarif par seconde confirmé. Vérifiez le coût exact par seconde sur la page fournisseur de Kling avant de l'utiliser dans un modèle de coût.
• La valeur en dollars par crédit de la plateforme PixVerse n'est confirmée que par un bundle promotionnel Starter-pack (1 $ = 5 vidéos, 720p, 5s, sans audio). La tarification par crédit autonome en dehors de ce bundle n'est pas confirmée dans cet ensemble de preuves.
• Vidu est répertorié comme un exemple d'API vidéo actuelle mais n'a aucune preuve de tarification dans cet article. Vérifiez la tarification directement sur la page fournisseur de Vidu.
• Les comparaisons entre fournisseurs mélangent la tarification directe des fournisseurs (Google, MiniMax, PixVerse) avec la tarification des revendeurs (fal, Runway), qui peut inclure des majorations ou des remises sur volume non visibles à partir des prix catalogue seuls.
• Aucun benchmark de précision n'existe dans cet ensemble de preuves pour l'utilisation d'un LLM comme couche de triage de revue vidéo automatisée. Considérez-le comme un pré-filtre non vérifié.
• La taille du jeu de test de 20 prompts et la cadence de re-test de sept jours recommandées dans cet article sont des valeurs par défaut de travail choisies pour des raisons pratiques, et non des chiffres étayés par une étude publiée ou une recommandation de fournisseur. Ajustez les deux à votre propre capacité de revue et tolérance au risque.

FAQ

Sur quel modèle devrais-je commencer à tester sur TokenLab aujourd'hui ? Basé sur la tarification en direct de TokenLab (observée le 07-07-2026), pixverse-v6 (0,022059 $/s) et veo3.1-fast (0,08 $/s) se situent dans le bas de la fourchette du coût par seconde, tandis que veo3.1 et seedance-2.0 se situent dans le haut de la fourchette. Un premier test raisonnable consiste à exécuter un candidat à faible coût et un candidat à plus haute fidélité sur le même jeu de prompts fixe, en utilisant une clé API de tokenlab.sh/en/api-keys, avant de vous engager dans un contrat avec un seul fournisseur.

Comment mesurer réellement la latence par programmation ? Horodatez avant la requête, après la soumission du travail, et après l'achèvement terminal pour chaque appel, en utilisant le modèle montré ci-dessus. Stockez le temps de file d'attente et le temps de génération séparément, et suivez les p50/p90/p99 sur au moins quelques douzaines d'exécutions sous charge concurrente, pas un seul test séquentiel. Aucun fournisseur dans cet ensemble de preuves ne publie la latence typique, donc cette mesure doit être la vôtre.

Où obtenir les chiffres du coût par seconde ? Utilisez le tableau d'instantané source dans cet article comme référence de départ, recoupez avec la tarification en direct de TokenLab sur le répertoire des modèles, puis calculez le coût réel à partir de la durée réelle du travail en utilisant la formule montrée ci-dessus plutôt que de supposer un tarif forfaitaire, car les réglages de résolution et d'audio modifient le prix par seconde chez la plupart des fournisseurs.

Combien de prompts ai-je besoin pour un benchmark fiable ? Il n'existe aucune étude publiée dans cet ensemble de preuves spécifiant une taille de jeu de prompts optimale pour l'évaluation des modèles vidéo. Cet article utilise 20 prompts répartis sur une complexité courte, moyenne et longue comme point de départ pratique qui équilibre la couverture par rapport au temps de revue manuelle. Augmentez si votre cas d'utilisation a plus de variété de prompts, ou diminuez si vous faites un écran de premier passage rapide avant un test plus large.

Comment automatiser la revue humaine si je dois tester des centaines de vidéos ? Divisez-le en deux niveaux : contrôles techniques automatisés (correspondance de durée, correspondance de résolution, détection de fichier corrompu) exécutés sur chaque sortie gratuitement, puis revue humaine sur 100 % des échecs de niveau 1 plus un échantillon aléatoire de 10-15 % des réussites. Un triage d'images basé sur LLM peut réduire davantage le volume de revue humaine, mais n'a aucune précision mesurée dans cet ensemble de preuves, donc validez son taux de faux négatifs par rapport à un échantillon revu par des humains avant de vous y fier.

À quelle fréquence dois-je relancer ce benchmark ? Au minimum chaque fois que l'instantané SSOT du modèle de cet article expire, environ sept jours après l'observation (observé le 07-07-2026, expire le 14-07-2026). Cette fenêtre est liée à l'expiration de cet ensemble de preuves lui-même, pas à une recommandation industrielle indépendante. Les versions des modèles vidéo et les niveaux de tarification changent assez souvent pour qu'un benchmark exécuté au moment de l'évaluation puisse être obsolète en un trimestre.

Commencer

Créez une clé API TokenLab et exécutez un jeu de prompts fixe de cet article contre deux modèles candidats, un du niveau à faible coût (pixverse-v6, veo3.1-fast) et un du niveau à plus haute fidélité (veo3.1, seedance-2.0), en utilisant le code de latence et de calcul de coût ci-dessus. Vérifiez le répertoire des modèles pour les tarifs actuels avant de verrouiller un contrat de fournisseur.