Performances et benchmarking de l'accélérateur d'IA

L'évaluation du matériel d'IA à utiliser avec les grands modèles de langage (LLM) comme charge de travail principale nécessite une approche cohérente et indépendante du fournisseur. Ce guide décrit une méthodologie permettant de comparer les performances des puces d'accélérateur d'IA de différents fournisseurs tels que NVIDIA, AMD, Googleet AWS. Les principes et la méthodologie sont adaptables à n'importe quelle puce ou charge de travail d'IA, mais les exemples se concentrent sur une association courante dans le secteur : les processeurs graphiques (GPU) NVIDIA et les Tensor Processing Units (TPU) Googleexécutant des charges de travail LLM.

Les modèles sont généralement optimisés pour une plate-forme matérielle spécifique. Par conséquent, l'évaluation des performances du modèle seul ne suffit pas à comprendre les capacités du matériel. Lorsque vous évaluez des puces d'accélérateur pour les LLM, tenez compte de trois dimensions clés : le microbenchmarking, l'analyse roofline et le benchmarking de modèle pour l'entraînement et l'inférence.

Les microbenchmarks et les analyses roofline sont essentiels pour comprendre les capacités et le potentiel d'une plate-forme d'accélérateur donnée. Une fois ces informations connues, l'analyse comparative des modèles pour l'entraînement et l'inférence permet de comparer les charges de travail réelles sur différents processeurs et de déterminer si l'architecture du modèle est optimisée pour une plate-forme spécifique.

Dimensions de performances

Nous suggérons aux évaluateurs de réfléchir aux performances selon trois dimensions afin de mieux comprendre un système d'accélérateur donné :

  • Microbenchmarking : le fait de disposer des spécifications matérielles les plus élevées ne signifie pas que les applications peuvent réellement les utiliser. Vous pouvez utiliser le microbenchmarking pour évaluer l'impact des opérations en virgule flottante par seconde (FLOPS), de la mémoire à haut débit (HBM) et de la bande passante réseau sur les performances des charges de travail réelles.
  • Analyse Roofline : l'utilisation optimale du matériel peut être entravée par la bande passante mémoire ou la vitesse de calcul. Vous pouvez utiliser un modèle roofline et l'intensité opérationnelle (IO) de différents composants système pour voir dans quelle mesure le matériel et les charges de travail sont adaptés les uns aux autres. Une combinaison de microbenchmarks et de rooflines fournit une évaluation théorique de ce que le matériel sélectionné peut accomplir pour différents types de charges de travail.
  • Benchmarking des modèles : le benchmarking des charges de travail d'entraînement et d'inférence pour mesurer les jetons par seconde par puce (TPS/puce) vous permet d'évaluer le même modèle sur différentes plates-formes. Si les résultats initiaux diffèrent de l'analyse de microbenchmarking et de roofline, cela indique qu'un travail logiciel supplémentaire est nécessaire pour atteindre les rooflines précédemment identifiées. Par exemple, cela peut impliquer de modifier les stratégies de sharding ou d'utiliser des noyaux personnalisés.

N'oubliez pas que l'évaluation comparative des modèles est une approche ponctuelle pour un modèle, une échelle et une plate-forme donnés. Les utilisateurs expérimentés tiennent également compte des tendances du secteur (comme l'architecture des modèles), des microbenchmarks et des résultats roofline lorsqu'ils évaluent les performances.

Conception conjointe de modèles et de matériel

Les évaluations des performances doivent tenir compte de l'architecture du modèle dans le contexte du matériel testé. Les modèles conçus de manière efficace sont souvent co-conçus pour une plate-forme matérielle spécifique afin d'exploiter les nuances spécifiques de la plate-forme. Par conséquent, ces modèles peuvent ne pas utiliser pleinement d'autres plates-formes, ni même différentes générations de la même plate-forme. Par exemple, un modèle conçu pour les GPU NVIDIA Hopper peut ne pas utiliser pleinement les GPU AMD ou NVIDIA Blackwell.

Cette considération est particulièrement importante lorsque vous passez d'une plate-forme matérielle à une autre qui peut avoir des capacités différentes, car un modèle conçu pour une plate-forme peut nécessiter des modifications de configuration, des modifications logicielles ou les deux pour atteindre des performances optimales sur une autre plate-forme. Il est essentiel de comparer les modèles optimisés pour valider les affirmations marketing des fournisseurs concernant les performances théoriques maximales et mesurer les résultats concrets. Le cabinet d'analystes indépendant SemiAnalysis note : "Comparer les FLOPS théoriques ne donne qu'une partie de l'histoire. Ce qui compte, ce sont les FLOPS effectifs, car les nombres maximaux ne sont presque jamais atteints dans les charges de travail réelles."

Exemple : le défi gpt-oss-120B

Une erreur courante dans les benchmarks consiste à évaluer un modèle sur du matériel pour lequel il n'a pas été conçu. Le modèle à pondération ouverte gpt-oss-120B d'OpenAI est un exemple qui montre pourquoi l'architecture du modèle doit être étroitement associée au silicium cible. L'exemple suivant montre que la conception conjointe du modèle est essentielle et doit avoir lieu tôt dans le processus.

Le modèle gpt-oss-120B utilise une dimension de tête d'attention de 64. Bien que cela soit la norme pour de nombreux modèles optimisés pour les GPU, cela crée une inadéquation architecturale pour les accélérateurs TPU. Les TPU tels que Trillium et Ironwood sont optimisés pour les dimensions de matrice qui sont des multiples de 256 afin de saturer complètement leurs unités de multiplication matricielle (MXU). Étant donné que la dimension de l'en-tête (64) n'est pas optimisée pour les TPU, l'exécution de gpt-oss-120B sur un système TPU entraîne une diminution du nombre de jetons par seconde (TPS) et de l'utilisation des FLOPS du modèle (MFU). Le matériel gaspille effectivement des cycles d'horloge et de l'énergie en remplissant l'espace restant avec des zéros pour s'adapter à ses grilles d'exécution de 256 x 256.

L'utilisation de gpt-oss-120B comme benchmark pour les TPU peut signaler à tort une faible capacité matérielle alors qu'en réalité, elle reflète une incompatibilité de l'architecture logicielle. Pour évaluer précisément le "plafond " d'un accélérateur, testez-le avec des modèles conçus pour sa géométrie spécifique. Par exemple, les modèles avec des dimensions de tête de 128 ou 256, comme Gemma 4. Vous pouvez améliorer les performances de ce modèle avec des noyaux personnalisés qui évitent le remplissage de zéros et "remplissent" plutôt l'unité MXU, ce qui nécessite une expertise et n'atteint pas le même niveau de performances que sur les GPU. Vous pouvez également modifier les dimensions de l'en-tête pour les optimiser davantage pour les TPU, mais cette modification invalide les pondérations de modèle existantes, ce qui nécessite un réentraînement.

Principes de benchmarking

Pour fournir des évaluations équitables et durables, tenez compte des principes suivants pour les benchmarks sur les accélérateurs :

  • Concentrez-vous sur les performances par euro dépensé : certains fournisseurs se concentrent sur les performances brutes d'un seul chip, mais les performances au niveau du système par euro dépensé sont plus représentatives du coût total de possession (TCO) et de la valeur globale. Si le chip A est 20 % plus performant et 50 % plus cher que le chip B, les évaluateurs doivent reconnaître les gains de performances par euro du chip B. Tenez également compte des performances par watt dans le coût.
  • Représenter les charges de travail d'IA modernes : se concentrer sur les modèles populaires basés sur les transformateurs, les grands clusters et les derniers frameworks, tout en tenant compte des tendances du secteur. Par exemple, le passage du secteur à des modèles MoE (Mixture of Experts) plus clairsemés rend plus difficile l'optimisation complète des FLOPS tout en exigeant une bande passante de bissection plus élevée des réseaux.
  • Assurez-vous de répondre aux exigences des développeurs : tenez compte des performances, de la flexibilité et de l'évolutivité pour différentes charges de travail (entraînement, ajustement et diffusion) sur une gamme de LLM et d'autres modèles.
  • Choisissez des modèles et des outils indépendants des fournisseurs : sélectionnez des modèles et des moteurs qui s'exécutent sur plusieurs accélérateurs pour faciliter les évaluations multi-accélérateurs. Par exemple, utilisez des modèles ouverts tels que Qwen et Gemma, ainsi que des moteurs d'inférence Open Source qui s'exécutent sur des GPU et des TPU, tels que vLLM. Évitez les piles PyTorch/CUDA spécifiques au matériel. Pour les benchmarks d'entraînement de modèles, les frameworks spécifiques aux fournisseurs (comme MaxText pour les TPU et Megatron pour les GPU) sont les plus utiles lorsque les modèles sont constants sur toutes les plates-formes.
  • Conception conjointe de modèles : les utilisateurs expérimentés conçoivent conjointement leurs modèles pour tirer le meilleur parti de la plate-forme matérielle. Ne vous attendez pas à ce qu'un modèle entraîné sur le chip A ait de bonnes performances "prêtes à l'emploi" sur le chip B.
  • Tenez compte de l'ensemble du système matériel : certains accélérateurs peuvent annoncer des performances élevées dans un domaine comme les FLOPS. Toutefois, les goulots d'étranglement dans d'autres domaines, comme la bande passante mémoire, peuvent limiter considérablement les capacités de l'accélérateur. D'autres aspects du système à prendre en compte sont les spécifications des puces, la mise en réseau des puces et l'architecture scale-out.
  • Fiabilité du matériel et des logiciels : les interruptions lors d'opérations d'entraînement à grande échelle ou d'inférence critiques peuvent être extrêmement coûteuses. De même, un accélérateur d'IA n'est utile que si le logiciel qui s'exécute dessus l'est aussi. Une pile logicielle fiable et éprouvée à grande échelle est essentielle pour maximiser la valeur.

Microbenchmarks

Dans le contexte de l'analyse comparative des accélérateurs, le microbenchmarking isole des composants matériels spécifiques tels que les cœurs de calcul, la mémoire et les interconnexions pour mesurer leurs limites absolues sans l'interférence de piles logicielles complexes. De nombreux fournisseurs mettent en avant les "FLOPS de pointe sur une seule puce", mais l'IA dans le monde réel est un problème de systèmes distribués. Le microbenchmarking vous aide à déterminer si une puce est simplement puissante de manière isolée ou si elle est conçue pour l'échelle du centre de données.

Utilisez le microbenchmarking pour mesurer les performances maximales du matériel et découvrir les limites réelles du système, indépendamment de l'architecture du modèle. Le microbenchmarking est particulièrement utile pour évaluer les accélérateurs par rapport à des cas d'utilisation et des architectures de modèles futurs ou indéterminés.

Pour microbenchmark efficacement les accélérateurs, évaluez les éléments suivants :

Benchmark Explication
Utilisation de la multiplication matricielle générale dense (GEMM) Exécutez des noyaux GEMM hautement optimisés sur différentes précisions pour mesurer la puissance de calcul mathématique brute et soutenue des unités de calcul de base de l'accélérateur.
Streaming de mémoire à haut débit (HBM) Exécutez des microbenchmarks de bande passante mémoire pour mesurer les vitesses de lecture, d'écriture et de copie soutenues de la mémoire intégrée de l'accélérateur. Les architectures qui maintiennent un rapport octets/FLOP sain empêchent les cœurs de calcul de rester inactifs.
Collectifs distribués (all-reduce et all-gather) Exécutez des tests de communication collective standardisés sur des milliers de puces pour mesurer la dégradation de la bande passante et de la latence du réseau à mesure que le cluster évolue.
Débits de transfert hôte à appareil (H2D) et appareil à hôte (D2H) Transférez de grands flux de données continus entre la mémoire système du processeur hôte et l'accélérateur pour mesurer les taux de transfert sur le bus PCIe ou l'interconnexion personnalisée.
Limitation thermique et consommation d'énergie soutenues Exécutez une boucle GEMM à utilisation maximale en continu pendant 48 heures tout en surveillant la consommation électrique au niveau du rack pour évaluer la stabilité thermique soutenue et l'efficacité énergétique réelle.

Exemple de comparaison de microbenchmarks

Voici une comparaison illustrative entre deux puces, où une puce A hypothétique peut sembler meilleure qu'une puce B hypothétique, mais être moins performante en pratique :

Nom du benchmark Résultat du test du chip A Spécification du chip A Rapport entre le test et la spécification Résultat du test du chip B Spécifications du chip B Rapport entre le test et la spécification
Mise en réseau de puce à puce 800 Gbit/s 1 000 Gbit/s 80 % 850 Gbit/s 900 Gbit/s 94,4 %
gemm/peakTOPS 1 800 TFLOPS 2 500 TFLOPS 72 % 1 800 TFLOPS 2 000 TFLOPS 90,0 %
Bande passante de la mémoire 6 000 Gbit/s 8 000 Gbit/s 75 % 6 500 Gbit/s 7 500 Go/s 86,7 %
Hôte vers appareil 58 Gbit/s/puce 70 Gbit/s/puce 82,9 % 60 Gbit/s par puce 65 Gbit/s par puce 92,3 %
De l'appareil à l'hôte 55 Gbit/s par puce 70 Gbit/s par puce 78,6 % 55 Gbit/s par puce 65 Gbit/s par puce 84,6 %

Analyse de la ligne de toit

Une analyse roofline (ou modèle roofline) peut vous fournir une visualisation pour analyser l'intensité opérationnelle (OI) de différents composants du système et la façon dont des conceptions spécifiques conviennent à des plates-formes spécifiques.

Le débit d'un accélérateur d'IA est limité par trois facteurs principaux :

  1. Capacité de calcul : débit mathématique maximal du chip (FLOPS).
  2. Bande passante mémoire : débit auquel les données peuvent être transférées vers ou depuis la mémoire à haut débit (HBM) locale du chip.
  3. Bande passante du réseau : débit auquel les données peuvent être partagées entre plusieurs puces à l'aide du réseau de puces lors de l'entraînement ou de l'inférence distribués. Par exemple, le taux de transfert d'ICI (pour les TPU) ou de NVLink (pour les GPU).

Pour en savoir plus sur les rooflines, consultez Tout savoir sur les rooflines.

Le graphique roofline standard se compose de deux axes :

  • Axe X (intensité opérationnelle) : l'intensité opérationnelle est le rapport entre le travail de calcul (FLOPS) et le trafic mémoire (octets transférés), exprimé en FLOPS par octet. Il représente la quantité de calcul effectuée pour chaque octet de données récupéré de la mémoire.
  • Axe Y (performances atteignables) : les performances atteignables sont exprimées en FLOPS par seconde. Il représente le débit de calcul réel atteint.

Graphique du modèle roofline montrant comment les performances maximales du matériel sont limitées par la bande passante mémoire et la capacité de calcul

Le "plafond" est formé de deux lignes sécantes représentant les maximums matériels :

  1. Toit incliné (lié à la mémoire) : performances atteignables = bande passante mémoire maximale × intensité opérationnelle. Sur cette ligne, les performances sont strictement limitées par la vitesse à laquelle les données peuvent être transmises aux unités de calcul.
  2. Le plafond (limité par le calcul) : performances atteignables = capacité de calcul maximale. Sur cette ligne, les données sont fournies assez rapidement pour que les unités de calcul fonctionnent à leur capacité maximale.

Le point où ces deux lignes se croisent est appelé point de crête. Il définit l'OI minimal requis par une charge de travail pour atteindre l'utilisation maximale du matériel.

Dans l'image précédente, l'algo 1 se trouve dans la partie du graphique intitulée "lié à la mémoire" et n'utilise pas pleinement les unités de calcul. En revanche, l'Algo 2 présente un OI plus élevé et se trouve dans la partie du graphique intitulée "compute bound" (limité par le calcul). Pour optimiser l'algorithme 1, un utilisateur essaierait de le modifier afin qu'il effectue plus de calculs avec moins de mouvements de données (en augmentant l'intensité opérationnelle) pour déplacer les performances vers la droite, vers le point de crête.

Exemples de charges de travail à faible et à forte intensité d'E/S

  • Intensité opérationnelle HBM faible (limitation par la mémoire) : charges de travail telles que les opérations élément par élément (fonctions d'activation comme ReLU ou GeLU), la normalisation des couches et le décodage autorégressif (inférence avec taille de lot = 1).
  • Intensité opérationnelle HBM élevée (limite de calcul) : charges de travail telles que les GEMM ou les réseaux de neurones convolutifs à grands lots. La multiplication matricielle réutilise les données récupérées de nombreuses fois (en multipliant les lignes par les colonnes). L'intensité opérationnelle est donc très élevée et les charges de travail se situent sous le plafond de calcul plat.

Benchmarking des modèles

Le benchmarking de modèle mesure les performances réelles du modèle. Les benchmarks d'entraînement et d'inférence vous permettent de comparer les performances des modèles populaires à un moment précis.

Le tableau suivant compare les insights que vous pouvez obtenir à partir du benchmarking de modèles pour les charges de travail d'entraînement et d'inférence :

Insight Charges de travail d'entraînement Charges de travail d'inférence
Échelle Tests à plus grande échelle (plus de 10 000 puces, jusqu'à plus de 100 000 pour les modèles les plus grands). Fournit des informations sur les charges de travail distribuées, la surcharge de communication et les limites de mise en réseau au niveau du cluster. Souvent des tests plus petits (1 à 64 puces ou plus). Fournit des informations sur la façon dont la plate-forme gère les utilisateurs simultanés et la mise à l'échelle rapide sous charge.
Performances Souvent plus lié au calcul. Mesure les jetons traités par seconde et par puce, ainsi que l'utilisation des FLOP du modèle (MFU). Sensible à la latence. Mesure le délai avant le premier jeton (TTFT), la latence entre les jetons et le nombre total de jetons générés par seconde et par utilisateur.
Latence Latence d'E/S et d'interconnexion qui met en évidence les goulots d'étranglement du stockage lors du chargement de grands ensembles de données et la latence du réseau entre les nœuds lors des mises à jour synchrones des gradients. Latence de réponse de bout en bout qui met en évidence les délais d'attente, la latence des points de terminaison et les temps d'attente visibles par l'utilisateur.

Analyse comparative de l'entraînement

Pour déterminer l'efficacité réelle du matériel et du réseau, vous devez normaliser les performances selon une métrique unique et comparable pour tous les accélérateurs : jetons par seconde par puce (TPS/puce), tout en conservant une architecture de modèle spécifique et représentative constante. En suivant le comportement des TPS/chip lorsque vous augmentez la taille d'un cluster, vous découvrirez la "taxe de scaling" cachée du système.

Pour normaliser les performances avec le coût des accélérateurs, divisez ensuite les TPS/chip par le coût de chaque chip pour obtenir les TPS/chip/$, qui deviennent un autre point de comparaison.

Pour chaque modèle comparé, évaluez les éléments suivants :

Benchmark Explication
Mesurer les TPS/puce et les TPS/puce/$ de référence

Exécutez le modèle cible sur le plus petit cluster viable. Enregistrez le débit d'entraînement global (nombre total de jetons traités par seconde) et divisez-le par le nombre de puces pour établir le TPS/puce de référence. Divisez par le coût de l'accélérateur pour obtenir les TPS/chip/$.

Vous pouvez également observer l'utilisation des FLOP du modèle (MFU) pendant l'entraînement pour mesurer le rapport entre le débit observé et le débit maximal théorique. Cela permet de comprendre à quel point les performances matérielles sont proches du benchmarking. Toutefois, il ne fournit pas une comparaison de puce à puce aussi utile que les TPS/puce.
Évaluer la dégradation de la mise à l'échelle Faites évoluer le cluster à 256, 1 024 et 4 096 puces, en exécutant exactement le même modèle. Recalculez le TPS/chip à chaque échelle.
Tenir compte du débit utile

Les TPS/chip bruts n'ont d'importance que si le modèle apprend réellement. Calculez le débit utile pour mesurer le taux de calcul utile qui fait progresser directement l'état d'entraînement d'un LLM, en excluant explicitement le temps et l'énergie gaspillés en raison de défaillances matérielles, d'arrêts du réseau ou de récupérations de points de contrôle.

Lorsque vous évaluez des accélérateurs d'IA à grande échelle, le bon débit fournit une image plus réaliste de votre retour sur investissement que le débit théorique brut, car il révèle l'efficacité avec laquelle le matériel maintient les performances dans des clusters réels sujets aux pannes.

Le tableau suivant liste les modèles recommandés pour le benchmarking de l'entraînement :

Taille Architecture Modèle Explication
Petite (8 milliards) Dense Llama 3.1 8B Llama 3 est un modèle standard, populaire auprès des normes de benchmarking telles que MLPerf depuis plusieurs années.
Moyen (70 B) Dense Llama 3.1 70B Llama 3 est un modèle standard, populaire auprès des normes de benchmarking telles que MLPerf depuis plusieurs années.
Grande (671 milliards) MoE DeepSeek-V3 671B DeepSeek-V3 a établi une nouvelle norme en termes de taille et de performances en 2025, et est bien optimisé sur de nombreuses plates-formes multichips.

Exemple : Normalisation des performances par euro

Prenons l'exemple d'une comparaison de benchmarks entre Chip_A, Chip_B et Chip_C, où vous avez exécuté des benchmarks d'entraînement pour des modèles courants afin d'évaluer les performances en TPS. Vous examinez ensuite le ratio des performances de Chip_A par rapport à celles de Chip_B et Chip_C pour le même modèle :

Benchmark TPS de Chip_A en tant que fraction du TPS de Chip_B TPS de Chip_A en tant que fraction du TPS de Chip_C
Petit et dense : Llama 3.1 8B 0.82 0,62
MoE : Mixtral 8x7B 0.72 0.55
Grand et dense : Llama 3.1 405B 0,77 0.61
Large MoE : DeepSeek-V3 0,85 0,62
Valeur moyenne 0.79 0,60

D'après les données du tableau précédent, les performances de Chip_A représentent en moyenne 0,79 fois celles de Chip_B et 0,60 fois celles de Chip_C. Sans plus d'informations, la conclusion serait que Chip_C est supérieur.

Toutefois, si le composant A coûte 100 $, le composant B 180 $et le composant C 200 $, la normalisation des performances par euro dépensé (perf/$) modifie le résultat :

Benchmark Chip_A perf/$ en tant que fraction de Chip_B perf/$ Chip_A perf/$, exprimé sous forme de fraction de Chip_C perf/$
Petit et dense : Llama 3.1 8B 1,48 1.24
MoE : Mixtral 8x7B 1,30 1.10
Grand et dense : Llama 3.1 405B 1,39 1.22
Large MoE : DeepSeek-V3 1,53 1.24
Valeur moyenne 1.42 1.20

Si vous comparez les performances/prix, le Chip_A dépasse le Chip_B de 42 % en moyenne et le Chip_C de 20 % en moyenne.

Analyse comparative de l'inférence

L'entraînement représente des dépenses d'investissement initiales massives, mais le déploiement (et donc l'inférence) représente des dépenses opérationnelles à long terme. Un nombre de TPS/chip plus élevé signifie que vous avez besoin de moins de serveurs physiques pour prendre en charge les mêmes charges de travail opérationnelles, ce qui réduit considérablement la consommation d'énergie et l'empreinte des centres de données.

Lors de l'inférence, l'objectif est de maximiser le débit sans enfreindre les exigences de latence afin de garantir une expérience utilisateur réactive. En standardisant l'évaluation des TPS/chip pour un modèle fixe, vous pouvez comparer directement les performances sur différents chips.

Lorsque vous comparez l'inférence, normalisez les performances en calculant les TPS/chip/$:

Benchmark Explication
Établir le SLA de latence

Commencez par définir un SLA strict pour l'expérience utilisateur. Par exemple, une latence de queue prévisible (P99) de 100 millisecondes. Mesurez l'expérience utilisateur en termes de réactivité à l'aide du TTFT (moins de 500 ms) et du TPOT (temps par jeton de sortie).
Augmenter la taille du lot Augmentez progressivement le nombre de requêtes simultanées (taille de lot) par rapport au matériel. À mesure que la taille du lot augmente, le débit augmente, mais la latence finit par se dégrader.
Enregistrer le nombre maximal de TPS soutenus/puce

Arrêtez-vous lorsque le matériel ne respecte pas le contrat de niveau de service de latence au 99e centile. Enregistrez le débit total du système pour cette taille de lot exacte, puis divisez-le par le nombre de puces. Il s'agit de la valeur de votre TPS/chip.

Notez que certains accélérateurs à usage général ont du mal à gérer la latence de queue (pics aléatoires dans le temps de traitement) sous des charges de traitement par lot élevées, ce qui oblige les opérateurs à les exécuter à des utilisations plus faibles pour satisfaire les utilisateurs.

Assurez-vous de mesurer les deux phases distinctes de préremplissage (liées au calcul) et de décodage (liées à la bande passante mémoire).
Calculer le coût total de possession par millier ou million de jetons Divisez le coût amorti du capital et de l'énergie d'un chip par son TPS/chip maximal soutenu. Cela permet de traduire le benchmark technique en métrique financière, révélant ainsi le coût réel.

Le tableau suivant liste les modèles recommandés pour le benchmarking de l'inférence :

Taille Architecture Modèle Explication
Petite (8 milliards) Dense Llama 3.1 8B Llama 3 est un modèle standard, populaire auprès des normes de benchmarking telles que MLPerf depuis plusieurs années.
Moyen (70 B) Dense Llama 3.1 70B Llama 3 est un modèle standard, populaire auprès des normes de benchmarking telles que MLPerf depuis plusieurs années.
Grande (480 milliards) MoE Qwen3 Coder 480B Qwen3 480B est un modèle de codage OSS de premier plan.

Étapes suivantes