Auteur : SemiAnalysis
Traduction : Deep潮 TechFlow
Lecture approfondie de Shenchao : Les données de test du premier puce d'inférence développée en interne par OpenAI, Jalapeño, ont été révélées ; son efficacité énergétique dépasse directement le dernier flagship d'NVIDIA, Blackwell, et se rapproche de la prochaine génération Rubin. Pour les entreprises d'IA confrontées à des goulets d'étranglement énergétique dans leurs centres de données, cette puce pourrait réécrire la carte du marché du calcul. Toutefois, il reste à déterminer si cette première génération de puces pourra véritablement remettre en question l'écosystème CUDA d'NVIDIA.
Comparez le coût total de possession, le débit par mégawatt et les détails épicés de vos ASIC internes avec Rubin et Jalapeño
Au cours des deux dernières années, OpenAI a secrètement développé « Jalapeño », une puce d'inférence dont les détails viennent d'être révélés sur Hot Chips. Des rumeurs selon lesquelles le chip avait réussi son flux de fabrication circulaient déjà depuis un moment. Mais maintenant, nous avons accès aux détails. OpenAI nous a invités à examiner la puce, à entrer dans son laboratoire pour vérifier son authenticité, et à effectuer des tests de performance avec notre kit InferenceX.
En juin de cette année, OpenAI a annoncé un projet de puce en partenariat avec Broadcom, conçu dès le départ pour l'inférence des LLM. Le travail de conception a commencé au milieu de l'année 2024, et il n'a fallu qu'environ 16 mois, depuis le recrutement initial de l'équipe jusqu'à la fabrication, pour réaliser ce cycle de développement ASIC extrêmement rapide.
Les puces de première génération n'ont généralement pas de compétitivité, mais OpenAI a fait l'inverse : sur plusieurs des meilleurs modèles open source, elle a surpassé tous les processeurs NVIDIA, AMD et Google que nous avons testés, se plaçant en tête du secteur. OpenAI réussit grâce à une conception extrêmement optimisée entre logiciel et matériel. De manière surprenante, OpenAI n'a pas concentré ses efforts sur un seul aspect spécifique de l'inférence de modèles, mais a plutôt visé à créer une puce universelle offrant des performances élevées dans tous les scénarios.
Cet article approfondira les détails architecturaux, logiciels et les résultats de performance de Jalapeño sur InferenceX.

Une puce d'inférence universelle
Tout le monde dit que la puce d'OpenAI est spécialement conçue pour les modèles d'OpenAI, mais c'est faux : OpenAI a développé une puce universelle dédiée à l'inférence IA.
La timeline est folle. Cela confirme que l’affirmation « accélérer la conception de puces avec l’IA » est vraie. Même si la timeline est rapide, OpenAI a investi énormément d’argent, pris des décisions de conception pragmatiques et dispose d’une équipe très forte, donc ce n’est pas surprenant.
Vu uniquement les spécifications, c'est immédiatement un concurrent sérieux :

Et en utilisant le HBM4, il est suffisamment puissant pour être comparé aux GPU phares de NVIDIA et AMD :

De nombreux médias ont suivi les commentaires informels d'OpenAI, affirmant que ce puce optimiserait leurs modèles d'une manière que d'autres puces ne peuvent pas atteindre. C'est faux. Jalapeño est une puce de raisonnement universelle capable d'exécuter divers modèles et charges de travail, y compris notre benchmark InferenceX — que nous avons exécuté en laboratoire avec les ingénieurs d'OpenAI. En guise de blague, OpenAI nous a même montré son fonctionnement sur Doom, un jeu porté sur leur puce uniquement à l'aide de prompts Codex.
Voici nos résultats les plus importants en termes de performance par watt, mesurés en débit de tokens par mégawatt de consommation totale. Jalapeño domine largement tous les autres puces. Tout cela sans utiliser la prédiction multi-token (MTP), tandis que les autres puces du graphique sont configurées à leur meilleur niveau pour leur SKU respectif, avec MTP activé.

Jalapeño dépasse Blackwell en performance par watt dans presque tous les scénarios, sans optimisation spécifique pour un point particulier de la courbe. Il excelle non seulement dans les scénarios à faible latence, mais aussi dans les scénarios à haut débit. Une comparaison plus équitable consiste à examiner les résultats de prédiction par token : Jalapeño dépasse largement chaque concurrent. Dans les scénarios à faible concurrence, Jalapeño offre une interactivité remarquable, atteignant plus de 700 tokens par utilisateur et par seconde sur le modèle DeepSeek R1 avec une concurrence de 1.
Incroyablement, tout cela est réalisé avec une prédiction de token unique (STP), sans décodage par conjecture ni séparation pré-remplissage-décodage. Outre DeepSeek R1, nous avons observé d'autres modèles, notamment Kimi-K2.5 et GPT-OSS, qui atteignent environ 1 400 tokens par utilisateur par seconde. Pour tous les modèles, nous avons confirmé que les résultats de Jalapeño sur GSM8k sont équivalents à ceux obtenus sur des puces NVIDIA.
Voici quelques points à noter. Tout d'abord, toutes les données proviennent d'OpenAI. Nous avons vérifié personnellement le fonctionnement d'InferenceX dans notre laboratoire, mais nous n'avons pas exécuté l'intégralité du jeu de tests InferenceX, ni vu les résultats d'AgentX. AgentX est notre jeu de tests privilégié pour comparer les performances des puces, car ses jeux de données, avec leurs contextes extrêmement longs et leurs caractéristiques multi-itérations, reflètent le comportement du cache sous des charges de travail de production réelles. Un framework qui performe bien sur 8k1k pourrait obtenir de moins bons résultats sur AgentX, car les charges de production réelles mettent à l'épreuve des composants tels que les routeurs, les mécanismes de cache de préfixe, la gestion du cache et l'infrastructure de déchargement. Les tests 8k1k en une seule itération ne couvrent pas ces éléments. Pour en savoir plus, consultez notre article sur AgentX.
AgentX - InferenceXv3 : Le mur de protection CUDA tient-il encore dans l'inférence d'agents ?
Deuxièmement, nous pensons que la comparaison avec Blackwell est incomplète et un peu injuste. Le véritable adversaire de Jalapeño est le chip Rubin, qui utilise également le HBM4. Les systèmes Vera Rubin ont déjà commencé à être livrés aux clients, tandis que le Jalapeño d'OpenAI n'est encore qu'un échantillon de développement et nécessite encore un certain temps avant la production de masse.
Ainsi, les performances devraient véritablement être comparées à celles de Rubin, et non de Blackwell. D’une certaine manière, nous nous attendions déjà à ce que des puces personnalisées comme Jalapeño dépassent Blackwell. Le rapport performance/watt de la Vera Rubin NVL72 est 5,4 fois supérieur à celui du GB200 NVL72, comme nous l’avons mentionné dans notre article d’analyse des déclarations de performances d’NVIDIA et de CoreWeave publiées le mois dernier. Nous comparerons ultérieurement les performances de Jalapeño avec celles de Vera Rubin en juillet.
Vera Rubin NVL72 contre GB200 NVL72 ? Analyse du TCO et de l'architecture
Troisièmement, les modèles testés ne sont pas à la pointe de l'open source. NVIDIA et AMD ont déjà publié les résultats de modèles plus grands via AgentX, tels que DeepSeek V4 Pro et Kimi K3. Plus un modèle est grand et récent, plus il est complexe de le faire fonctionner sur de nouveaux processeurs. Toutefois, le modèle exécuté par OpenAI sur Jalapeño n'est pas petit.
Analyse des performances
L'objectif de conception d'OpenAI est la performance par watt. La raison est simple : OpenAI est actuellement limité par l'électricité des centres de données, et non par le budget ou l'espace des salles serveurs, ce qui rend le nombre de tokens par mégawatt crucial. À Computex 2026, Jensen Huang a déclaré que la performance par watt, la fiabilité et la longévité sont les caractéristiques fondamentales des futurs GPU. Il a déclaré mot pour mot : « Si vous avez 1 gigawatt d'électricité, alors le débit par watt est votre revenu. » Il a également souligné qu'il n'a aucun sens de choisir une architecture sous-optimale simplement parce que le processeur est moins cher.

NVIDIA a également souligné ce point lors de la présentation Vera à Hot Chips 2026, en présentant le même graphique des revenus : « Les centres de données d'aujourd'hui sont limités par l'électricité. » L'électricité est cruciale et génère des revenus.
Les opérateurs ne peuvent pas facilement obtenir davantage de mégawatts. Les échelles de temps pour augmenter les GPU et pour accroître la capacité du réseau électrique sont très différentes. La capacité électrique des centres de données est limitée par de nombreux facteurs, tels que les interconnexions utilities, les infrastructures, la capacité de refroidissement et la conception des UPS/générateurs de secours. Les retards du réseau électrique dépassent fréquemment les progrès du matériel et de la construction, ce qui stimule la demande de capacité électrique « après compteur » : c’est-à-dire la construction locale de turbines à gaz et de générateurs sur site. Ces capacités se situent après le compteur utility et ne dépendent pas du réseau public, permettant ainsi aux opérateurs d’alimenter leurs installations sans attendre l’interconnexion au réseau ni les mises à niveau des utilities. C’est précisément la raison pour laquelle xAI repose fortement sur une capacité après compteur pour Colossus 2, alors que sa connexion réelle au réseau électrique est largement en retard. Pour plus d’informations, consultez notre modèle énergétique.
Comme indiqué dans notre publication X, tok/s/MW peut être simplifié en nombre de tokens par joule. Puisque le watt équivaut au joule par seconde, tok/s/MW représente l'efficacité du système et sa capacité à convertir l'énergie en tokens.

À cet égard, Jalapeño surpasse même Rubin. Le débit de jetons par mégawatt STP d’OpenAI Jalapeño dépasse les résultats MTP de Vera Rubin. Ce résultat a été publié par NVIDIA et CoreWeave en juillet. Il surpasse également largement les résultats MTP du GB200 prévus pour 2025. Comme mentionné dans notre article sur Vera Rubin, la comparaison entre VR et les résultats du GB200 en 2025 est justifiée, car les deux se trouvent à un stade initial similaire. En outre, comparer avec le GB200 de 2025 permet de maintenir une maturité logicielle constante. Selon cette logique, nous comparons trois jeux de résultats : le dernier résultat de Vera Rubin de juillet 2026, les résultats du GB200 en 2025 et les résultats actuels de Jalapeño. Cette comparaison est très pertinente, car il s’agit des meilleures données publiques disponibles sur Rubin. De plus, OpenAI a fait fabriquer son propre puce après Rubin. À la fois OpenAI et Rubin sont encore à un stade immature, donc leurs performances continueront d’améliorer.

En ce qui concerne les performances / le coût total de possession, Vera Rubin et Jalapeño sont à égalité. Chaque dollar génère presque le même nombre de tokens de sortie. Toutefois, comme mentionné précédemment, les résultats de Jalapeño n'utilisent pas la décodage spéculatif, tandis que ceux de Vera Rubin en font usage. Le décodage spéculatif permet de réduire le coût par token d'environ 3 à 5 fois. Une fois que Jalapeño implémentera le décodage spéculatif, son efficacité coûts-bénéfices pour la fourniture de tokens sera supérieure. Bien sûr, une partie de l'avantage en TCO provient du fait d'éviter les marges élevées de NVIDIA pour adopter les marges plus faibles (mais toujours élevées) de Broadcom. Mais ce n'est pas la seule raison. Par exemple, les projets d'ASIC IA de Meta et Microsoft ont bénéficié de plus de temps mais n'ont pas réussi à être mis en œuvre. Cela indique que le coût n'est qu'une partie de l'équation. Pour une analyse complète du TCO de Jalapeño, consultez le modèle SemiAnalysis AI Cloud TCO.

Sur le plan architecturale, OpenAI a choisi de ne pas séparer le pré-remplissage (prefill) et le décodage (decode) sur des pools de puces distincts. Le modèle de brouillon et le modèle principal partagent les mêmes puces et la même structure d’interconnexion. Ce concept de conception sacrifie une partie de l’efficacité théorique pour gagner en praticité opérationnelle. Son objectif est que la composition de la charge de travail évolue avec le temps. Par exemple, le rapport entre les entrées, les écritures de cache, les lectures de cache et les tokens de sortie a considérablement changé. Ce changement s’est produit après notre passage à trois ères de modèles : connaissance, raisonnement et agents, comme discuté dans notre article récent. Par conséquent, fixer à l’avance des quantités dédiées à des puces hétérogènes pour le pré-remplissage et le décodage entraînerait une inefficacité croissante avec le temps. OpenAI a donc opté pour des pools homogènes dans cette architecture, en s’efforçant de faire en sorte que les puces performent bien sur toutes les tâches.
Et c’est effectivement ce qu’il a accompli. Sur Kimi K2.5 (basé sur le modèle Cursor Composer 2.5), Jalapeño atteint près de 700 tok/s/utilisateur. Cette vitesse est plus de 9 fois supérieure à celle du deuxième meilleur processeur, à 100 tok/s/utilisateur.

Sur GPT-OSS, c’est une autre écrasante victoire. Le débit d’interaction par mégawatt de Jalapeño est presque deux fois supérieur au point de débit maximal du GB200, et plus de 50 fois supérieur au point de concurrence 1 du GB200. Les points Jalapeño à plus haute concurrence utilisent l’EP8.

Ces résultats sont impressionnants ! Mais nous devons être exigeants : il s'agit uniquement de 8k1k, avec une difficulté de fine-tuning bien moindre, et sans données d'exécution AgentX. Comme mentionné dans notre article sur AgentX, les charges de travail à plusieurs tours et avec un long contexte exercent une pression accrue sur de nombreux aspects de la pile d'inférence, comme le routeur et le cache de préfixes. Pour performer efficacement sur des charges de travail d'agents, davantage d'optimisations sont nécessaires. Pour en savoir plus, consultez l'article sur AgentX.
AgentX - InferenceXv3 : Le fossé CUDA peut-il encore résister dans l'inférence d'agents ?
Spécifications et architecture détaillées
Tous ces résultats proviennent de la étape A0 de Jalapeño, seulement 9 mois après le lancement du projet. Mais l'étape B0 est déjà en fabrication dans les usines de puces ! L'optimisation de l'étape B0 améliore les performances par watt d'environ 25 % par rapport aux puces A0 précédentes. Plus précisément, l'étape B0 atteint 13,4 PFLOPs en MXFP4 sur une puce de taille de masque unique. Cette puce est fabriquée selon le procédé TSMC N3P. À titre de comparaison, une seule puce de calcul Rubin atteint 17,5 PFLOPs en NVFP4 dense sur une taille similaire et au même nœud.
Étant donné que le TDP de Jalapeño n'est que de 700 W, contre 900 à 1150 W par puce de calcul pour Rubin, cette performance est d'autant plus impressionnante. Puisque Jalapeño est conçu pour l'inférence et non pour l'entraînement, OpenAI n'a pas besoin d'augmenter le TDP pour maximiser les FLOPs. Cela est compréhensible. Mais quel que soit le cas, les résultats ci-dessus indiquent que Jalapeño offre un pic théorique de FLOPs considérable.
En comparaison directe avec d'autres accélérateurs, Jalapeño offre la bande passante HBM par watt la plus élevée ainsi que la plus haute performance FLOPs par watt, un niveau comparable à une configuration Rubin Max-Q de 1800 W.

Jalapeño intègrera le HBM4 et deviendra l'un des premiers processeurs à adopter cette technologie, après Nvidia et AMD, et même avant les projets TPU et Trainium existants. L'un des principes clés de l'architecture de Jalapeño est d'exploiter pleinement la bande passante HBM ; renoncer à un HBM de niveau supérieur contredirait donc cet objectif. Cela permet d'atteindre une bande passante mémoire de 15,4 To/s par package, dépassant ainsi tous les autres accélérateurs actuellement commercialisés utilisant le HBM3E. Une bande passante de 15,4 To/s indique que le HBM4 de Jalapeño atteint une vitesse de pin de 10 Gbps, légèrement supérieure aux 9,6 Gbps du HBM4 dans Rubin de Nvidia. Le HBM est très probablement fourni par Samsung.

OpenAI a terminé le jalonnement de Jalapeño en novembre 2025, plus précisément un jalonnement de conception CoWoS, et non uniquement une puce supérieure. Neuf mois après le jalonnement de novembre 2025 et seulement trois mois après le débogage sur silicium réel, OpenAI a déjà obtenu d'excellents résultats avec Jalapeño. Cela est d'autant plus impressionnant compte tenu du fait que l'équipe a commencé depuis zéro sur la pile logicielle.
En parallèle, le premier lot de CoWoS de Rubin a été terminé en octobre 2025, un mois plus tôt, mais les seuls résultats précoces que nous avons actuellement proviennent des échantillons d'ingénierie de CoreWeave. Nvidia n'a pas autorisé les tests et la publication de benchmarks comme OpenAI, ce qui indique que son logiciel de puce n'est pas encore mature. Étant donné qu'OpenAI a pu faire fonctionner rapidement de nouveaux modèles sur ses propres puces, le fossé CUDA pourrait avoir disparu.
Ils sont encore loin d'être optimisés, et nous pouvons constater que Jalapeño fournit globalement de meilleures données. Nous ne pensons pas que le matériel Nvidia soit moins bon, mais que le débogage logiciel de Jalapeño a progressé plus rapidement que celui de Nvidia. Cela illustre la puissance de la conception coopérative matériel/logiciel, qui constitue le domaine principal où les équipes ASIC des laboratoires de pointe surpassent les fabricants de puces commerciales plus matures. De manière contre-intuitive, commencer à zéro pourrait également bénéficier à OpenAI, car cela lui permet de prendre des décisions d'architecture entièrement nouvelles, sans être limité par la compatibilité ascendante ou les anciennes versions logicielles.
Bien que OpenAI dispose déjà d'un prototype Jalapeño, la production de masse est actuellement prévue pour augmenter progressivement en 2027, avec la majorité de la production prévue pour la fin de l'année prochaine. Pour plus de détails sur le nombre d'unités et le prix moyen, consultez le modèle SemiAnalysis Accelerator.
On peut dire qu’OpenAI Jalapeno est un véritable ASIC à grande échelle.
Par rapport à la chronologie de Rubin, la vitesse de Jalapeño est incroyablement rapide. Comme indiqué précédemment, malgré un démarrage plus précoce, les résultats de Jalapeño surpassent ceux de Rubin.

Architecture Jalapeño
Sur le plan de l’architecture, le moteur matriciel de ce puce utilise le format numérique MXFP et une matrice pulsatile avec poids persistants, similaire à un TPU. Toutefois, contrairement au TPU direct, il prend en charge des formes/dimensions plus petites, ce qui évite les chutes de performance abruptes liées aux multiplications matricielles avec des formes incompatibles sur des matrices pulsatives plus grandes.
Il comprend également un noyau scalaire 64 bits et des noyaux vectoriels FP32/INT32. OpenAI a également intégré une conception redondante au niveau du plateau, ainsi qu'une récupération de rendement intégrée au niveau des noyaux et des canaux. Ils affirment que l'assistance par l'IA dans la conception du puce a réduit la surface SIMD de 8 % et la surface du moteur matriciel de 10 %. Bien qu'ils n'aient pas précisé les conditions spécifiques de procédé/tension/température (PVT), ils ont mentionné que le module assisté par l'IA améliore le timing et la consommation d'énergie par rapport au module initial.
La conception de l'architecture Jalapeño se concentre sur l'élimination des transferts mémoire pour le KVCache et les poids, ainsi que sur la réduction de la latence et des surcharges fixes, afin de s'approcher davantage de la puissance de calcul et de la bande passante maximales d'origine par rapport à d'autres accélérateurs, même avec de petits lots ou de petites formes.
Les cœurs et les HBM sont divisés en plusieurs tranches, chaque tranche de cœur ayant une vue locale à faible latence sur sa propre tranche HBM. La synchronisation entre les tranches est effectuée via un réseau collectif dédié à haut débit. Cette structure mémoire minimaliste confère à Jalapeño un avantage potentiel considérable par rapport aux GPU, dont l'accès à la mémoire doit traverser un système mémoire complexe, générant des latences plus élevées qui doivent être amorties ou masquées sur de grandes tailles.
Ce choix est faisable car, en plaçant soigneusement les poids et les KV, la synchronisation entre les cœurs peut être limitée à des communications à haut débit limitées et connues, telles que la communication de parallélisme tensoriel pouvant être chevauchée avec le calcul.

En outre, un autre NoC universel est utilisé pour la communication générale et l'accès au réseau étendu. Globalement, OpenAI réalise une importante réduction de la consommation d'énergie et obtient une amélioration significative des performances grâce à un NOC et un sous-système mémoire simplifiés par rapport à Nvidia et Google.

Au niveau fondamental, OpenAI décrit un cœur out-of-order (OoO) doté d'un cache L1. Cela diffère fortement du modèle observé dans d'autres accélérateurs, qui utilisent généralement des mémoires tampons gérées par le logiciel, souvent accompagnées d'un support DMA asynchrone. L'argument ici est que cela permet à Jalapeño d'éviter les coûts fixes, tels que les latences de synchronisation, qui, sur d'autres accélérateurs (comme les GPU), doivent être masqués ou amortis en augmentant la charge de travail par cœur, rendant ainsi plus difficile l'approche de la bande passante ou de la puissance brute maximale.
Le coût est que Jalapeño dépend donc d’un bon préchargement pour garantir que les demandes mémoire arrivent à temps, ce qui est plus difficile à prédire et à raisonner. Toutefois, avec Codex pour obtenir des traces détaillées dans un bon cadre, il est possible de trouver le noyau optimal avec le meilleur préchargement pour une forme donnée, presque sans intervention humaine. Nous pensons que c’est précisément la raison pour laquelle OpenAI a pu déployer si rapidement DeepSeek R1, Kimi K2.5 et GPT-OSS.
Le noyau prend également en charge des dimensions de matrice « plus petites », ce qui (selon leur taille) devrait le rendre plus universel sur différents modèles et dimensions de lot, et moins sensible aux problèmes d'alignement des dimensions matricielles, au coût de remplissage et à l'inefficacité du partitionnement. Par exemple, les puces TPU, Trainium et Etched possèdent des matrices de pulsation très grandes, nécessitant peut-être de grands lots ou des dimensions de modèle exactement divisibles pour éviter l'inefficacité du partitionnement.
Avec Jalapeño, OpenAI se concentre sur l'élimination des délais fixes dans le système afin de s'approcher autant que possible des performances roofline dans toutes les régions de la courbe de Pareto. Théoriquement, cela pourrait apporter un avantage relatif par rapport aux GPU à plusieurs points de fonctionnement :
La performance maximale pour l'inférence à faible latence et en petits lots est bien supérieure à celle des GPU. Les GPU sont limités par des coûts fixes tels que la latence de démarrage, la latence de barrière et la latence du système mémoire.
Même avec des lots volumineux ou des contextes longs, il y a un potentiel pour s'approcher davantage du roofline matériel.
Cela s'accompagne d'un avertissement : même si une performance maximale théorique existe, les noyaux réels peuvent être plus difficiles à faire atteindre cette performance. Par conséquent, sa méthode semble être :
Design maximum upper performance for all workloads shapes
Laissez Codex accomplir le travail fastidieux et trouver le noyau permettant d'atteindre cette limite.
L'équipe OpenAI a lancé une charge de travail InferenceX sur Jalapeño, avec un temps de cycle extrêmement rapide.
Nous sommes donc optimistes à propos de cette méthode.
Si Jalapeño réussit, cela enverra un signal fort.
L'obsession de l'industrie pour les modèles de programmation et les compilateurs universels parfaits sera brisée par les modèles IA de pointe.
OpenAI écrit le noyau Jalapeño comme s'il écrivait en assembleur.
Chaque noyau contient du code optimisé à la main, environ 3000 lignes pour certaines parties.
Prise en charge de la vérification de validité et des sanitizers personnalisés.
Les travaux initiaux du noyau impliquaient une intervention humaine, et n'étaient pas entièrement automatisés.
Puis passage à une version interne plus évoluée de Codex.
OpenAI prévoit de vendre cette version aux clients professionnels.
Le moteur de service interne s'appelle « Teacup ».
Il est intéressant de noter qu'OpenAI n'avait auparavant aucune implémentation interne du noyau MLA.
Jusqu'à ce qu'ils effectuent un benchmark de DeepSeek avec InferenceX.
Codex peut écrire si rapidement un noyau utilisable et efficace sans nécessiter l'intervention de l'équipe d'ingénierie des noyaux.
Cela démontre la capacité de développement du pipeline logiciel.
OpenAI utilise Gluon pour programmer Jalapeño.
Gluon est le langage de programmation interne d'OpenAI.
Gluon est construit sur Triton et conserve le modèle de programmation SPMD (Single Program Multiple Data) de Triton.
But it exposes the underlying programming abstraction.
Par exemple, pour les GPU NVIDIA, il propose une API qui mappe les instructions PTX.
Incluant les instructions MMA, les instructions TMA, le mécanisme mbarrier, etc.
L'abstraction la plus unique fournie par Gluon est la mise en page.
En général, la disposition définit la correspondance entre les ressources matérielles et les éléments du tenseur.
Par exemple, le 5e registre de Warp 9 correspond à l'élément tensoriel de la 6e ligne et de la 7e colonne.
L'abstraction de disposition de Gluon repose sur des Linear Layouts.
C'est une algèbre de disposition inventée par OpenAI.
Linear Layouts formalise mathématiquement ce qu'est une disposition.
Et fournir des outils pour la disposition des opérations.
Cela prend en charge de nombreuses fonctionnalités, telles que des conversions de disposition prouvées correctes.
Optimal memory swizzling.
Dans le modèle de programmation de Jalapeño, chaque programme Gluon est mappé sur un thread persistant.
We believe this suggests that Jalapeño is suitable for persistent kernel programming patterns.
Chaque programme s'exécute sur plusieurs tuiles, avec la répartition du travail effectuée par le programmeur, et non par le planificateur matériel.
OpenAI a mentionné TensorInfo.
C'est une abstraction d'un schéma de codage explicite.
Ceci pourrait être un ensemble de mises en page conçu pour Jalapeño.
Il sera piloté par Linear Layouts.
Enfin, chaque cœur dispose d'une unité de préchargement de données et de désappariement hors ordre.
Par exemple, l'utilisateur peut programmer l'attente des données préchargées.
Ces données sont verrouillées par un sémaphore.
Ironie du sort, des modèles OpenAI comme GPT 5.6 Sol fonctionnent actuellement sur des GPU NVIDIA.
Ils sont utilisés pour concevoir des puces, constituant une véritable menace pour le fossé CUDA.
Les GPU de NVIDIA alimentent en temps réel le potentiel successeur.
En comparant sur différentes périodes, nous pouvons également observer la vitesse de développement de Jalapeño.
En moins de deux semaines, le débit de certains scénarios d'interaction a augmenté de plus de 2 fois.
Chaque tarball que nous avons reçu de l'équipe Jalapeño contient un monde merveilleux.

Non seulement les performances du noyau ont été améliorées, mais l'équipe Jalapeño a activé TP32 en 8 jours.
Étendre la configuration TP8 précédente au-delà d'un seul système pour réaliser une configuration complète à niveau de rack pour exécuter de grands modèles.
This development speed is indeed impressive.

Pour vérifier les performances avant de les exécuter sur du matériel réel, OpenAI dispose également d'un simulateur appelé « chilisim ».
Sa précision est inférieure à 5 % sur le matériel réel, avec un bus trace de largeur fixe.
La capacité de suivi est limitée sur A0, mais considérablement améliorée sur B0.
Cela pourrait être dû aux données réelles d'exploitation des puces A0.
L'ingénieur a démontré l'exécution du modèle interne via Codex CLI.
Il est surnommé « Raiku » ou « 5.3 Codex Spark », avec un TPOT de 1,2 ms.
L'équipe a également montré une démonstration écrite par Codex s'exécutant directement sur la puce.
Inclut Doom à 36 FPS et une simulation de dynamique des fluides FP32.
Aussi la visualisation par glissement de souris « Liquid Light ».

En ce qui concerne les modèles, la solution interne megakernel d'OpenAI porte le surnom « gigakernel ».
Il est construit autour d'un seul megakernel qui boucle sur l'appareil pour réduire la charge CPU et le temps de démarrage.
L'équipe continue d'affiner la stratégie de calcul pendant les tests.
Une attention particulière est portée à la coordination de l'utilisation de 1 million de rollouts.
Faut-il utiliser Disagg ? C’est la question.
Nous avons précédemment mentionné qu'OpenAI n'a pas utilisé la séparation prefill-decode sur ces puces.
Cela nous a surpris, car les performances des GPU NVIDIA et AMD ont significativement bénéficié de PDD.
Même sur du matériel homogène.
Découvrons pourquoi l'équipe Jalapeño a agi ainsi.
Lorsque la charge de travail est fixe, la séparation prefill-decode semble attrayante.
Prefill et decode exercent des pressions différentes sur le matériel.
Assignez chaque phase à un pool optimisé séparément pour améliorer l'efficacité sous un rapport entrée/sortie choisi.
Mais le trafic de production ne maintiendra pas ce ratio.
La longueur des séquences d'entrée/sortie, la concurrence, le taux de命中 du cache, le taux d'acceptation de la spéculation et les objectifs de latence varient tout au long de la journée.
Une fois que les appareils sont répartis entre les pools prefill et decode, une demande excessive de prefill laisse les puces decode inactives et entraîne une file d'attente de requêtes.
Mais trop de demandes de décodage ont l'effet inverse.
Les opérateurs doivent continuellement prédire les séparations correctes et réserver une capacité de secours des deux côtés.
Et rééquilibrer un système dont le ratio idéal change constamment.
Dans le système unifié, certaines ressources peuvent être sous-utilisées à des étapes spécifiques.
Mais chaque appareil peut toujours être utilisé pour servir la prochaine demande.
Dans un système séparé, un ensemble de puces peut rester inutilisé simplement parce qu'il appartient à un pool incorrect.
L'utilisation locale semble meilleure, mais l'utilisation globale peut être très faible.

La séparation détruit également la localité.
Le worker de préremplissage génère un grand cache KV nécessaire immédiatement par le worker de décodage.
Le système doit transmettre cet état à travers le réseau pour que la génération puisse continuer.
Cela augmente la consommation de bande passante, la synchronisation, la file d'attente et un autre domaine de défaillance.
Le coût augmente également avec la longueur de la séquence d'entrée, car le cache KV croît.
Cependant, éviter le déplacement de KV est principalement une optimisation de la consommation d'énergie et de la latence.
Déplacer certaines KV peut améliorer l'utilisation du matériel, au prix d'une consommation d'énergie et d'une latence par requête plus élevées.

Les clusters interchangeables peuvent transférer des capacités entre les demandes sensibles à la latence et les lots orientés débit.
Le partitionnement fixe laisse le matériel inutilisé lors des variations de la combinaison de trafic.
De plus, le changement de la longueur du contexte modifie l'équilibre entre l'attention et le FFN.
Tout rapport de matériel fixe n'est efficace que près du point de conception.

Les mêmes contraintes s'appliquent à la décodage spéculatif. Le modèle brouillon doit fournir des tokens candidats au validateur avec une latence extrêmement faible. Séparer les deux en pools dédiés distincts transforme la boucle de décodage étroitement couplée en un protocole distribué. La communication et la coordination supplémentaires pourraient absorber la latence économisée par le modèle brouillon. Seule la co-localisation des deux modèles sur le même appareil et une structure à faible latence permet de préserver la localité qui rend le décodage spéculatif pertinent.

Cependant, dans les endroits où la demande est suffisamment grande, stable et prévisible, le découplage reste avantageux, notamment lorsque les GPU traditionnels nécessitent des lots volumineux et des batches progressifs pour atteindre un bon débit. Mais ce n'est pas un déjeuner gratuit.
Du japonais à l’indien (du légèrement épicé au très épicé) : Katsu, Vindaloo et Chana — comment ces plats épicés forment-ils un système de support ?
Le système Jalapeño est composé au niveau des unités de rack d'un rack hôte CPU et d'un rack ASIC. Le rack hôte accueille 16 plateaux CPU hôtes appelés « Katsu ». Chaque Katsu correspond à l'un des 16 plateaux ASIC situés à droite, appelés « Vindaloo ». Chaque hôte est équipé de deux processeurs AMD EPYC de la gamme Turin, avec 1,5 To de DRAM, 2x E1.S et 2x SSD M.2 par rack. Chaque plateau est également doté d'un réseau avant de 400 G (2x200 G). Chaque plateau Katsu est connecté à chaque plateau Vindaloo via 8 câbles PCIe DAC externes. Ces câbles sont routés horizontalement à l'avant du rack. La conception système a été réalisée en collaboration avec Celestica.
Le rack ASIC est composé de 16 plateaux Vindaloo et de 8 plateaux d'extension switch (6 locaux + 2 globaux), nommé « Chana ». Chaque plateau Vindaloo contient 8 ASIC Jalapeño, soit un total de 128 ASIC Jalapeño par rack. Les ASIC sont connectés aux plateaux switch Chana via un backplane en câble cuivre, similaire à l'Oberon de Nvidia. La topologie d'extension est divisée en domaines locaux et globaux. Le domaine local couvre les 128 ASIC au sein du rack. Le domaine global relie jusqu'à 16 racks ou 2 048 ASIC. Nous expliquerons plus en détail la bande passante et la topologie ci-dessous.
La puissance de la baie de serveurs latérale est d'environ 50 kW (31 kW en production), tandis que les baies ASIC consomment 130 kW. L'ensemble du système à double baie consomme environ 160 kW. En termes de consommation énergétique, cela équivaut à peu près à une baie double largeur GB300.

OpenAI peut connecter jusqu'à 2 048 Jalapeño XPU au sein d'un seul réseau étendu. Ce réseau étendu est composé de deux domaines. Le domaine local relie tous les 128 XPU d'un rack via une backplane. Le domaine global utilise un mélange de câbles en cuivre et d'interconnexions optiques pour relier les 2 048 XPU répartis sur 16 racks. Chaque rack contient 8 plateaux d'interrupteurs Chana. Les 6 interrupteurs Chana centraux sont utilisés pour le domaine local, chacun équipé d'un ASIC d'interrupteur Tomahawk 6 de 102,4 T. Les 2 interrupteurs Chana situés en haut et en bas sont dédiés au domaine global. Nous pensons qu'il s'agit probablement de 2 interrupteurs Tomahawk 6 de 102,4 T chacun, pour un total maximal de 204,8 T par plateau d'interrupteurs.
Dans la région locale, 128 puces Jalapeño offrent une bande passante unidirectionnelle de 4,8 Tb/s par XPU. Elles sont connectées en mode tout-à-tout à 6 ASIC Tomahawk 6 de 102,4 Tb/s. Cela équivaut à 48 paires différentielles (DP) mâle-femelle par XPU. Au total, 6 144 paires DP de câbles passifs en cuivre sont utilisées pour l’extension locale.
Dans le domaine global, 16 baies contenant un total de 2 048 XPU sont connectées par une combinaison de backplanes en cuivre, d’interrupteurs électriques 204,8 T TH6, de modules optiques de 1,6 T et d’interrupteurs de circuits optiques. La bande passante unidirectionnelle du lien global pour chaque XPU est de 1,6 Tb/s. Chaque XPU dispose de 16 paires différentielles (DP) de connecteurs mâle et femelle pour la connexion backplane entre le XPU et l’interrupteur global. Chaque plateau d’interrupteur global contient 2 ASIC, dont la bande passante sortante est répartie entre les dispositifs optiques de la backplane et de l’avant.
Entre les domaines local et global, le nombre de connecteurs backplane par baie est de 64 paires DP par XPU. Au total, 8 192 paires de câbles passifs en cuivre par baie.
Le domaine global utilise une architecture rail pure, composée de 8 rails au sein du domaine global. Nous pensons qu'OpenAI route les liens optiques dans le domaine global à l'aide d'intercommutateurs optiques (OCS) installés sur chaque rack. La bande passante globale de 1,6 Tb/s de chaque XPU atteint le plateau d'interconnexion global via un backplane en cuivre, puis quitte l'intercommutateur via des modules optiques de 1,6 T situés sur le panneau avant. Ces signaux entrent d'abord dans un intercommutateur optique passif, puis quittent le rack. Cela permet d'étendre la taille du domaine à 2 048 XPU, répartis sur 16 racks contenant chacun 128 XPU.

Étant donné que le réseau étendu ne représente qu’environ 10 % du coût total du système, cette flexibilité offre une option précieuse pour des modèles futurs de 10 à 20 billions de paramètres ou des fenêtres de contexte de 2 à 4 millions de tokens. En ce qui concerne le déploiement, OpenAI collabore avec neocloud. Elle a également collecté des données de fiabilité avec ses partenaires de centre de données il y a un mois, tout en optimisant le temps de déploiement du quai au rack.
Étape suivante
Ensuite, nous aborderons l'avenir de Jalapeño, dont le premier token de production est sur le point de voir le jour. Le prochain objectif est de 100 MW ; les principaux défis résident dans le matériel : leur capacité à produire, à déployer et à exploiter des centres de données, ainsi qu'à gérer la surveillance et la résilience. Le logiciel est déjà validé, et avec un modèle interne, tout avantage logiciel initial peut facilement être rattrapé. Derrière le mur d'abonnement, nous examinerons l'impact sur les entreprises de puces telles que NVIDIA, AMD et Cerebras, qui ont signé des contrats avec OpenAI pour les prochaines années.
Nous couvrons également la production, la quantité et le calendrier des puces de prochaine génération dans le modèle Accelerator.
La partie suivante est un contenu payant ; en raison de problèmes de permissions, aucune traduction supplémentaire n'a été effectuée, mais les informations précédentes reflètent déjà suffisamment les défis d'OpenAI pour les puces NVIDIA. Pour les joueurs intéressés par le secteur des puces et le cours de NVIDIA, ces informations offrent une référence fraîche et solide.
