De nombreux milliards ont été injectés dans l’industrie en ce qui concerne le développement de processeurs d’IA. Si vous deviez énumérer le nombre de processeurs d’IA actuellement en développement ou en production dans la grande variété de start-ups, alors ce nombre dépasse rapidement 50 et semble augmenter pour toujours. Chacune de ces entreprises vise à créer un produit convaincant pour répondre aux besoins de leurs clients potentiels, depuis les charges de travail d’inférence à petite échelle jusqu’à la formation à l’échelle de plusieurs centres de données. L’une de ces sociétés est Tenstorrent, dirigée par le PDG Ljubisa Bajic, qui a récemment embauché le célèbre concepteur de puces Jim Keller en tant que directeur technique. Jim était également le premier investisseur providentiel lorsque la société a démarré. Aujourd’hui, nous interrogeons ces deux personnes sur l’entreprise, le produit Tenstorrent et la direction des demandes d’accélérateurs d’apprentissage automatique.

Cette interview était quelque peu inattendue – il y a environ un mois, Jim Keller m’a contacté pour me demander si nous voulions l’interviewer avec Ljubisa à propos de l’entreprise. Nous avions souligné au début de l’année quand Jim a été embauché par Tenstorrent, et j’ai assisté à un certain nombre de présentations Tenstorrent par Ljubisa et son équipe, donc quelle que soit la société où Jim atterrit, elle retient beaucoup l’attention. Apparemment, mon nom a été recommandé pour une interview, et nous y voilà!

Nous avons en fait divisé l’interview en deux segments. Il s’agit de la première transcription d’entrevue de 90 minutes, sur le thème de Tenstorrent avec Ljubisa et Jim. Il y aura une deuxième interview de 90 minutes à suivre, sur le thème de Jim Keller, la semaine prochaine.


Ljubisa Bajic

PDG Tenstorrent


Jim Keller

Directeur technique Tenstorrent


Ian Cutress

AnandTech

Ljubisa Bajic est un vétéran de l’industrie des semi-conducteurs, travaillant intensivement dans la conception et le débogage VLSI, couplés à une vaste expérience en architecture d’accélérateurs et en logiciels. Ljubisa a passé une décennie chez AMD en tant qu’architecte ASIC à travailler sur la gestion de l’alimentation et la conception de DSP, avant un passage chez NVIDIA en tant qu’architecte senior, puis de retour chez AMD pendant quelques années à travailler avec Jim sur le matériel qui alimente le bilan d’AMD aujourd’hui. . Il a quitté AMD pour lancer Tenstorrent avec deux autres cofondateurs en 2016, a levé 240 millions de dollars en trois cycles de financement et créé trois générations de processeurs, dont la dernière est expédiée cette année. Au moins deux autres générations sont en route.

Jim Keller a souvent été décrit comme un ninja du matériel ou une rockstar des semi-conducteurs. Sa carrière est pleine de conceptions de silicium à succès, telles que les processeurs DEC Alpha, AMD K7 / K8, HyperTransport, les processeurs A4 / A5 d’Apple, la famille AMD Zen, la puce entièrement autonome de Tesla et quelque chose d’important chez Intel (probablement). Il siège maintenant en tant que directeur technique de Tenstorrent, travaillant sur les processeurs de nouvelle génération de la société pour 2023 et au-delà.

Tenstorrent est une société de conception et de logiciels de puces IA sans fabrique, ce qui signifie qu’elle crée et conçoit du silicium pour l’apprentissage automatique, puis utilise une fonderie pour fabriquer le matériel, puis travaille avec des partenaires pour créer des solutions (comme dans, puces + système + logiciel + optimisations pour ce client). Pour ceux qui connaissent cet espace, cela fait que l’entreprise ressemble à l’une des 50 autres entreprises du marché qui semblent faire la même chose. La division typique avec les sociétés de conception de puces IA sans usine pure-play est de savoir si elles se concentrent sur la formation ou l’inférence: Tenstorrent fait les deux et est déjà en train de finaliser son processeur de troisième génération.

IC: Qui ou qu’est-ce que Tenstorrent, selon vos propres mots?

KG: Tenstorrent est une start-up qui travaille sur de nouvelles architectures informatiques qui visent essentiellement à être le bon substrat pour exécuter des charges de travail d’apprentissage automatique. Des charges de travail plus lourdes en données ont émergé et ont pris le dessus, en particulier la scène informatique des centres de données, mais nous voulons également aller plus loin que cela.

IC: Jim, vous avez été le premier investisseur dans Tenstorrent – je me souviens que vous me l’avez dit il y a peu de temps, lorsque vous avez rejoint l’entreprise il y a cinq mois. Qu’est-ce qui vous a vraiment enthousiasmé et intéressé à propos de Tenstorrent?

JK: Je connais donc Ljubisa, et j’ai vu beaucoup de start-ups en IA. Quand j’étais chez Tesla, tout le monde venait nous parler et présenter leurs affaires, et il semblait y avoir une étrange collection d’idées étranges. [There were] des gens qui n’ont pas vraiment compris la totalité de la conception de puces, de la conception de logiciels, etc. Je connais Ljubisa – il a en fait travaillé sur des GPU dans de vraies puces et il a dirigé une équipe de logiciels, et il comprend en fait les mathématiques derrière l’IA, ce qui est une combinaison assez rare. En fait, je lui ai dit que je pensais que ce serait drôle s’il avait deux gars qui travaillent dans un sous-sol pendant un an, et donc je lui ai donné ce qu’on appelle le Angel Round de l’investissement, et ils l’ont fait. Vous étiez dans un sous-sol ou étiez-vous au-dessus d’un garage ou quelque chose comme ça?

KG: Nous étions dans un sous-sol!

JK: Vous étiez littéralement dans un sous-sol, et ils ont construit un prototype en utilisant un FPGA qui a réussi à faire le tour, puis cela l’a amené plus loin pour obtenir le premier tour du jour.

IC: Donc, le sous-sol de Toronto, pour autant que je sache, vous êtes basé à Toronto?

KG: Oui, c’était le sous-sol de ma maison, essentiellement le même sous-sol dans lequel je suis assis en ce moment. J’ai bouclé la boucle, cinq ans plus tard!

JK: Et l’autre chose que je lui ai dit – assurez-vous que tout ce que vous construisez a toujours un logiciel pour fonctionner dessus. Il y a eu un certain nombre d’efforts d’IA où ils ont construit une puce, puis ils ont dit «maintenant, nous allons créer le logiciel». Ils découvrent alors que l’interface matériel / logiciel est horrible et qu’il est difficile de faire en sorte que cela fonctionne. je pense [Tenstorrent] fait un travail intéressant à ce sujet.

Je parlais récemment à nos compilateurs et ils font la troisième réécriture de la pile logicielle, ce qui est en fait génial car le matériel est assez bon pour le logiciel. Ils ont eu des idées, et ils sont arrivés à un certain point, puis ils les ont réécrits. La nouvelle réécriture est en fait magnifique, ce que je pense que dans le monde des logiciels d’IA, il n’y a pas beaucoup de beaux logiciels d’IA qui parlent au matériel.

IC: Pour revenir à Ljubisa et au sous-sol – Tenstorrent a trois co-fondateurs, n’était-ce que vous trois à ces débuts?

KG: Donc, nous étions deux pendant les premiers mois, puis notre troisième co-fondateur nous a rejoints à peu près à ce moment-là, Jim a investi dans Tenstorrent, ce qui a rendu le tout un peu plus légitime, et un peu moins un tuyau. rêver. Donc, quelques mois plus tard, nous avons déménagé du sous-sol et avons obtenu un bureau qui était encore, très typique, un bureau très bas de gamme dans un mauvais quartier de Toronto avec des fusillades.

JK: Des fusillades à Toronto?

KG: Ouais, cherchez un mauvais quartier de la ville à Toronto! Nous étions là-bas pendant un moment, c’était très amusant rétrospectivement.

IC: Vous avez donc passé la meilleure partie d’une décennie chez AMD, un peu chez NVIDIA, pourquoi avez-vous décidé de vous lancer et de créer votre propre start-up?

KG: Eh bien, je voulais vraiment construire un ordinateur de nouvelle génération qui allait laisser une brèche sur la scène informatique. Le problème s’est matérialisé, à savoir l’apprentissage automatique. J’ai donc lancé Tenstorrent en 2016, et à ce moment-là, il était clair que c’était une charge de travail énorme, que cela allait être un bouleversement majeur, que cela allait être une révolution de qualité Internet dans notre espace commun.

Il est difficile de faire de grands départs par rapport à ce qui existe déjà dans les grandes entreprises. Cela en fait partie. L’autre partie était que, pour des raisons totalement indépendantes, j’ai décidé de passer à autre chose et de voir quoi faire. Vous avez mis les deux ensemble et à un moment donné, Tenstorrent a été conçu comme une idée. C’était très bancal au début, donc le premier ou les deux premiers mois, j’y ai pensé. J’étais très incertain que cela allait vraiment aller n’importe où, et ce qui l’a vraiment renversé, c’est que Jim a montré sa confiance dans l’idée. Il a montré sa confiance en ma capacité à faire une telle chose, vraiment d’une manière très réelle. Si Jim n’avait pas investi, je ne pense pas que nous serions vraiment allés de l’avant. J’aurais probablement continué à trouver un autre emploi.

IC: Vous vous êtes donc rencontrés tous les deux chez AMD, travaillant ensemble sur des projets. Je vais commencer par vous Jim, quelle a été votre première impression de Ljubisa travaillant avec lui?

JK: Ljubisa est un gars très imposant, donc nous sommes dans cette réunion et vous savez, tous ces ingénieurs ringards parlent et il y a Ljubisa qui dit que c’est ainsi que nous devrions faire les choses. Il a, disons, une personnalité assez forte et il a fait tout un tas de travaux pour améliorer l’efficacité énergétique des GPU. Quand il a proposé ce travail pour la première fois, il y a eu un peu de recul, puis il l’a lentement élaboré et il avait raison. Je pense que Raja Koduri lui a en fait dit plus tard qu’une grande partie de l’amélioration de la puissance / performance qu’ils ont obtenue provenait du travail qu’il a fait.

Ensuite, il a repris l’équipe de gestion de l’alimentation logicielle et de gestion du système, qui avait été en quelque sorte constituée de plusieurs groupes différents et qui n’était pas très fonctionnelle. Ensuite, il a fait une transformation assez importante de cela en termes de charte, mais aussi d’efficacité. Donc, je regardais en quelque sorte cela continuer.

Quand j’étais chez AMD, les produits qu’ils avaient (à l’époque) n’étaient pas très bons, et nous avons littéralement annulé tout ce qu’ils faisaient et restructuré les choses et créé un tas d’opportunités propres. Zen était, au plus haut niveau, littéralement un design épuré. Nous avons réinitialisé les flux CAO, Ljubisa réinitialisait la stratégie de gestion de l’alimentation et quelques autres choses, donc il était l’un de mes partenaires dans le crime en termes de changement de notre façon de faire. Je ne pense pas que vous étiez un senior fellow, j’ai trouvé les meilleurs seniors chez AMD, au moins je pensais qu’ils étaient les meilleurs, et ils ont travaillé pour moi. J’avais un petit gang, puis Ljubisa a rejoint ce gang, parce que tout le monde a dit qu’il était l’un des nôtres. C’était plutôt cool, et ensuite, ensemble, nous pourrions faire bouger n’importe quel problème technique parce que nous avions un assez bon alignement, donc c’était vraiment amusant.

IC: Même question pour toi Ljubisa. Jim est un nom bien connu dans l’industrie pour la conception de semi-conducteurs, et il est entré dans AMD en posant le marteau – pour tout déchirer et commencer une table rase. Quelle était votre impression de lui à ce moment-là?

KG: Sur mon deuxième graphique chez AMD, j’ai réintégré la société après avoir explicitement décidé que j’allais essentiellement appliquer toute l’énergie que j’ai pour réparer tout ce que je voyais, et ne rechigne à rien. J’ai rejoint cet état d’esprit et je ne connaissais pas Jim à l’époque. Mais assez rapidement, nous nous sommes croisés et il est devenu assez clair pour moi que seul, indépendamment de mon enthousiasme et de ma conception pour avoir beaucoup d’impact, il allait être difficile de contourner tous les obstacles que vous rencontrez généralement lorsque vous veulent affecter beaucoup de changements dans une organisation de cette taille.

Ma première impression était que Jim était essentiellement en train de faire du bulldozer (Ian: Ha!) à travers tout ce que vous pourriez caractériser comme n’importe quel type d’obstacle, que ce soit d’ordre organisationnel ou technique, comme littéralement chaque problème qui se poserait devant lui, il passerait juste dessus avec ce qui ne semblait pas être une sorte de ralentissement quoi que ce soit. Donc, étant donné ma disposition à ce qu’il faisait déjà, je pense que c’est finalement, au moins une partie, ce qui nous a amenés à nous aligner si rapidement et à entrer dans ce groupe que Jim vient de mentionner.

Je n’étais pas Senior Fellow, j’étais en fait un réalisateur – tout le monde à l’époque n’arrêtait pas de dire que personne ne comprend pourquoi je ne suis qu’un administrateur et pourquoi je ne suis pas un fellow ou un senior fellow. C’était un thème commun là-bas, mais je suppose que je m’intègre davantage à ces techniciens et ils ont dit qu’il y avait beaucoup de défis organisationnels à faire quelque chose de sérieux. Je pensais que c’était mieux [for me to be] positionné quelque part, vous avez un peu de portée dans les deux.

Pour moi, la plus grande impression initiale était que Jim a permis tout ce que je voulais faire, et fondamentalement reconnu et il l’a fait pour quiconque se trouvait sur son orbite. Il est extrêmement doué pour choisir les personnes qui peuvent faire des choses par rapport aux personnes qui ne le peuvent pas, puis leur donner essentiellement le soutien dont elles ont besoin pour le faire.

Lorsque nous avons commencé ensemble, il a commencé à me donner toutes sortes de conseils aléatoires. Une histoire que j’ai déjà mentionnée est que nous avons eu une réunion à Austin une fois, et que j’étais censé voler mardi matin. Je suis allé à l’enregistrement tôt et j’ai réalisé que j’avais réservé le billet une semaine plus tôt. Je ne suis donc jamais allé à l’aéroport, je n’ai jamais eu d’hôtel, je n’ai pas eu de vol. J’ai appelé Jim et j’ai dit: «Je dois acheter un autre billet et je ne peux pas passer par les systèmes de l’entreprise car je dois l’acheter maintenant et le vol est 6 heures du matin le lendemain». Alors il dit: «Ouais, tu devrais vraiment faire attention à ça – tu es un peu trop jeune pour ce genre de comportement!». J’ai reçu de lui toutes sortes de conseils de vie que j’ai sentis extrêmement utiles et percutants pour moi. J’ai changé des choses majeures dans ma façon de faire des choses qui n’ont rien à voir avec les ordinateurs et les processeurs basés sur l’entrée de Jim. Il a eu une énorme influence – ça a commencé avec le travail, mais ça va plus loin que ça.

IC: Corrigez-moi si je me trompe, mais pour le moment à l’intérieur d’AMD, cela ressemblait à Jim ou à l’autoroute?

JK: Je ne dirais pas ça! Le plus drôle, c’est que nous savions que nous étions en quelque sorte au bout du chemin – nos clients n’achetaient pas nos produits et les éléments de la feuille de route n’étaient pas bons. Je n’ai pas eu à convaincre beaucoup les gens à ce sujet. Il y avait quelques personnes qui ont dit « vous ne comprenez pas Jim, nous avons une opportunité de gagner 5% ». Mais nous étions partis par 2X, et nous n’avons pas pu rattraper [going down that route]. J’ai donc fait ce graphique qui résumait que notre plan était de «tomber un peu plus loin derrière Intel chaque année jusqu’à notre mort».

Avec Zen, nous allions nous rattraper en une génération. Il y avait trois groupes de personnes – un petit groupe le croyait (que Zen attraperait Intel en une génération); un groupe de personnes de taille moyenne qui pensaient que si cela arrivait, ce serait cool; puis un autre groupe qui croyait définitivement que c’était impossible. Beaucoup de ces gens ont ri, et certains d’entre eux ont en quelque sorte persévéré, malgré cette croyance. Il y avait beaucoup de dissonance cognitive, mais j’ai trouvé toutes sortes de gens vraiment enthousiastes.

Mike Clark était l’architecte du Zen, et j’ai fait cette liste de choses que nous voulions faire [for Zen]. J’ai dit à Mike que si nous faisions cela, ce serait génial, alors pourquoi ne pas le faire? Il a dit qu’AMD pouvait le faire. Ma réponse a été de demander pourquoi nous ne le faisons pas – il a dit que tout le monde dit que ce serait impossible. J’ai pris soin de cette partie. Ce n’était pas seulement moi, il y avait beaucoup de gens impliqués dans le Zen, mais il s’agissait aussi de mettre les gens à l’écart qui le bloquaient. C’était amusant – comme je l’ai déjà dit, la conception informatique doit être amusante. J’essaie d’exciter les gens sur ce que nous faisons. J’ai fait toutes sortes de choses folles pour sortir les gens de ce genre de désespoir décousu dans lequel ils tombaient.

IC: En parlant de plaisir, dans votre discussion ML à l’échelle, il y avait beaucoup de commentaires là-dessus parce que vous avez utilisé Comic Sans comme police.

JK: Un de mes amis a pensé que ce serait vraiment drôle, et pour être honnête, je ne savais pas vraiment pourquoi. Mais j’ai reçu beaucoup de commentaires à ce sujet. L’un des commentaires était que «Jim est si méchant qu’il peut utiliser Comic Sans». J’ai juste pensé que c’était amusant. C’était bien parce qu’ils ne m’ont pas dit à qui je présentais – je suis entré dans la salle et c’étaient tous des banquiers, des investisseurs et des bureaucrates d’université. Ils m’ont dit que c’était une discussion technique et je me suis dit « Oh, on y va! ».

IC: Le titre de votre exposé était «à déterminer», je pensais que c’était un peu comme une blague – «c’est l’avenir du calcul, alors appelons le discours à déterminer»?

JK: Je pense que cela aurait pu être une blague!

IC: Mais en parlant de quelque chose d’amusant, donc pour Tenstorrent en 2016. A l’époque, Jim travaillait sur Tesla, sur les trucs de conduite autonome – quand tu parlais à Ljubisa? A l’époque, Ljubisa avait-elle une vision concrète à ce moment-là? Y a-t-il quelque chose de plus que de savoir qui est Ljubisa, vous savez, qui vous a donné l’impulsion pour investir?

JK: Il y avait plusieurs choses. La première était que nous étions tous dans ce processus de découverte de la faible précision des mathématiques dont vous aviez besoin pour faire fonctionner les réseaux de neurones. Ljubisa avait mis au point une unité de calcul à virgule flottante à précision variable assez nouvelle qui était vraiment dense par millimètre. Il avait également une architecture de calcul et de données, puis comment il voulait l’interconnecter, ce que je trouvais plutôt cool. Il avait des idées assez fortes sur la façon dont cela fonctionnait. Pete Bannon et moi lui avons parlé plusieurs fois pendant que nous étions à Tesla. Le moteur que Ljubisa construisait était en fait plus sophistiqué que ce dont nous avions besoin (chez Tesla).

Pete était l’architecte du moteur IA de la puce Tesla, et c’est génial pour faire fonctionner Caffe – tout simplement incroyable. La moitié de l’équipe de compilation pour cette puce était Pete! C’est parce que, encore une fois, la correspondance matériel-logiciel était si bonne, et Caffe a produit un pseudo jeu d’instructions que vous avez modifié de manière triviale pour fonctionner sur le moteur d’IA. Ce que faisait Ljubisa était plus sophistiqué, pour exécuter de nombreux types de logiciels différents.

Ljubisa à l’époque visait déjà PyTorch je crois? C’était avant que PyTorch ne soit le vainqueur, à l’époque où TensorFlow menait à l’époque.

KG: À ce moment-là, PyTorch s’appelait encore Torch, et TensorFlow venait juste de commencer à être médiatisé. Donc Caffe était vraiment le framework dominant à l’époque et TensorFlow était à l’horizon, mais PyTorch n’était pas tout à fait à l’horizon.

JK: Caffe peut décrire des modèles plus complexes, en particulier lorsque vous vous entraînez, et le moteur que nous voulions chez Tesla n’avait pas besoin de le faire. Nous avons donc construit un moteur plus simple, mais Ljubisa était déjà parti pour les courses et il pouvait montrer des repères et montrer une bonne intensité de calcul. Les gars de Tenstorrent avaient une version piratée de leur logiciel qui faisait quelque chose d’utile. Il a prêté attention aux limites matérielles / logicielles même très tôt dans la conception, et j’ai pensé que c’était la clé.

KG: Nous avions une boîte que nous prenions et montrions à tout le monde en juin 2016. Elle exécutait des réseaux de neurones de bout en bout sur Caffe sur un FPGA et renvoyait des résultats, et donc ce n’était pas quelque chose qui pouvait se vendre mais cela montrait que pourrait fondamentalement aborder cette chose de bout en bout assez rapidement et que nous avions un tas d’idées. En fin de compte, il y avait tous nos points focaux clés, même maintenant, ou essentiellement ce que nous voulions dès le départ. Cela n’a pas été une énorme révolution dans la réflexion de haut niveau depuis lors, c’est plus simplement une quantité massive d’exécutions.

IC: Les dépenses actuelles de Tenstorrent commencent avec la conception initiale de preuve de concept de Jawbridge en 2019, avec six cœurs Tensix et une petite conception de 1,5 W, menant à une plus grande puce «  Grayskull  » avec 120 cœurs Tensix et PCIe 4. Grayskull est prêt à être expédié aux clients cette année. La plupart des start-up IA récentes n’ont pas fait connaître leurs conceptions de «  preuve de concept  », alors pouvez-vous expliquer pourquoi il était important d’avoir un suivi aussi rapide de cette première mini-puce à celle qui est actuellement en cours vendu?

KG: Il y avait deux raisons pour lesquelles nous avons procédé comme nous l’avons fait à notre feuille de route produit. L’une était purement la gestion des risques – c’était une nouvelle équipe, pas de flux existants, rien d’existant. Nous avons vraiment dû rincer le tuyau et construire quelque chose pour que toutes les 50 étapes que vous devez mettre en place pour le faire puissent être effectuées. Nous avons tout fonctionné et nous ne voulions pas courir le risque de couler une pile d’argent en cas d’erreur. L’autre motivation était que nous croyons profondément qu’il est important d’avoir la même architecture qui s’étend essentiellement des déploiements périphériques aux déploiements multi-puces et multi-ordinateurs dans le cloud. La principale raison pour laquelle nous pensons que vous avez besoin d’une architecture qui s’étend si largement est que lorsque vous vous évitez de parcourir un tas d’équations pour implémenter le réseau neuronal, vous vous lancez dans des choses plus sophistiquées comme la rareté du temps d’exécution ou le calcul dynamique ou tout ce qui essaie de s’éloigner de l’état d’esprit.

Sinon, il ne s’agit que de croquer un tas de multiplications, les mêmes multiplications à chaque fois, et vous vous heurtez naturellement à une dynamique de compatibilité. Imaginez donc que vous vous retrouvez dans une situation où vous entraînez quelque chose sur un GPU NVIDIA et que le matériel dispose d’une fonction de parcimonie 2X au cas où vous appliqueriez un certain ensemble de contraintes à vos données. Si vous n’avez pas de matériel compatible partout où vous le déployez, que ce soit dans un téléphone ou un appareil de périphérie, vous perdriez ce 2X. En termes de parcimonie, ce facteur 2X va tout simplement augmenter de toute façon, à notre avis.

Essentiellement, nous avons estimé que c’était un énorme avantage de pouvoir démontrer clairement que nous pouvons faire une puce d’un seul watt. Nous pouvons également faire une puce de 60 watts, et nous pouvons faire un centre de données rempli de nos puces connectées via Ethernet qui est également sur nos puces. Donc, quand vous regardez ce spectre, la puce à un watt était la plus facile à faire, donc vous savez, c’était un autre point en faveur de nous le faire. C’est une sorte de scénario de crawl-walk-run, mais qui montre tout le spectre.

JK: Vous savez, beaucoup de gens dépensent énormément d’argent lors de leur premier essai. Grayskull (la puce expédiée cette année aux clients) est notre puce de troisième génération – nous avions ce prototype dans un FPGA en tant que première génération, et la puce de test était notre deuxième. La société a appris une charge de merde à chaque étape, à la fois matérielle et logicielle. Cela se reflète dans la pile de logiciels, et notre équipe de logiciels est assez petite.

J’ai vu beaucoup d’entreprises d’IA qui ont récupéré une puce et leur plan a été que pour que cela fonctionne, elles doivent embaucher 300 logiciels. Cela signifie qu’ils n’ont pas vraiment de plan. Vous ne pouvez pas vraiment surmonter cette discordance dans la frontière matériel / logiciel avec des équipes énormes. Eh bien, à un certain niveau, vous pourriez, si vous pouvez lancer 1000 personnes, et certaines personnes le font. Ce n’est pas vraiment la bonne façon de procéder, et ce ne sera pas quelque chose que vous pourriez exposer à long terme aux programmeurs, car la complexité est si élevée que cela devient vraiment fragile et que les programmeurs ne peuvent pas voir comment le matériel fonctionne.

L’un des éléments clés de Linux, ainsi que des logiciels open-source et fonctionnant sous x86, est que les programmeurs peuvent programmer le matériel directement sur le métal. Ils pouvaient voir comment cela fonctionnait et c’était évident, c’était robuste et cela fonctionnait avec le temps. Pour le matériel d’IA trop fragile pour être exposé à la plupart des programmeurs. Pas tous les programmeurs, mais vous savez, les ninjas.

IC: La nature de l’IA est naturellement bifurquée entre l’entraînement et l’inférence, et la puce Greyskull est très présentée comme une conception d’inférence. Avec autant d’entreprises ciblant le marché de l’inférence, quel succès cela a-t-il été? Quel a été le taux de reprise entre les entreprises évaluant et les entreprises déployant?

JK: Nous avons commencé la production, mais il y a un délai à ce sujet. Notre plan démarre vraiment au troisième et quatrième trimestre de cette année. Nous avons parlé à tout un tas de personnes, et lorsque nous leur montrons les références, elles sont enthousiasmées. Il leur suffit de demander une boîte de matériel!

Lorsque nous pouvons l’exécuter et le faire, nous verrons le ramassage sur la distribution. Du côté des inférences, Ljubisa, quel était votre numéro? Je pense que nous aurions pu rendre la puce environ 20% à 30% plus efficace si ce n’était que de l’inférence. Ce delta est suffisamment petit pour que si vous allez déployer tout un tas de matériel d’IA, plutôt que d’avoir deux ensembles différents de matériel pour l’inférence et la formation, alors le delta d’efficacité est suffisamment petit pour maintenir la compatibilité entre les deux. Je pense que nous avons fait une bonne chose – Grayskull peut faire de la formation, il va très bien se comparer à ce sujet, et avec la prochaine génération qui suivra, nous aurons plus de réseau entre les puces afin que nous puissions évoluer plus grand et mieux. Mais ils sont fondamentalement la même architecture, ce qui permet de passer facilement à la dernière.


Grayskull dans PCIe

IC: Diverses puces d’IA visent la facilité de déploiement avec une installation de code simplifiée, des conceptions monocœur, des TOP de pointe ou des performances cohérentes du lot 1. Qu’est-ce qui fait du processeur Grayskull la puce d’inférence de choix pour les clients?

KG: Donc, purement sur des mesures techniques, je pense que cela se compare très bien aux autres options disponibles. La seule chose que Grayskull peut faire, que je pense qu’au moins la plupart des alternatives que je considère ne peuvent pas faire, est le calcul conditionnel. Cela permet une gestion dynamique de la parcimonie pour l’IA.

Donc, pour donner un exemple, si vous vous entraînez aujourd’hui, pour la plupart, personne ne peut utiliser la parcimonie du tout. La façon dont la parcimonie est utilisée est que vous entraînez généralement un modèle sans aucune hypothèse sur la parcimonie. Finalement, vous le post-traitez après coup, et vous faites beaucoup de poids pour le modèle zéro, et cela devient une sorte de modèle clairsemé pour l’inférence.

Nous pouvons donc utiliser la parcimonie à notre avantage durant formation. Par exemple, même pendant l’inférence, où la plupart des gens se concentrent sur ces poids, il y a un compromis entre le nombre que vous allez élaguer et faire des zéros par rapport au type de qualité qui vous restera. Nous pouvons exploiter la rareté des résultats intermédiaires, des activations, des éléments inconnus au moment de la compilation.

Enfin, nous sommes en mesure d’effectuer des tâches relativement programmatiques dans un graphe de calcul de réseau neuronal. Nous sommes très doués pour avoir un tas de multiplications ou de convolutions de matrices lourdes de type mathématique ou autre, mais s’il est suivi par un nœud qui fait quelque chose de complètement programmatique, nous pouvons le faire sur la puce. Notre conception n’est pas uniquement une question de densité mathématique, c’est une épée – elle permet une programmation plus générale. Chacun de nos cœurs contient un ensemble de moteurs RISC qui peuvent exécuter tout ce que vous voulez.

Nous croyons donc profondément qu’à mesure que les réseaux de neurones continuent d’évoluer, la parcimonie dynamique et le calcul conditionnel, ainsi que la programmation du graphe, vont devenir de plus en plus importants. Ceci est principalement dû au fait que le simple fait de mettre en place un tas de calculs coûteux a conduit à ce que les plus grands modèles aient la taille d’un centre de données, mais si vous n’évoluez pas avec l’intelligence, c’est un peu difficile à maintenir.

IC: En ayant ce calcul conditionnel dans chacun de vos cœurs, vous sacrifiez une zone de dé. Mais vous bénéficiez d’une plus grande flexibilité au sein de la pile de calcul au sein de l’application de modèle?

KG: Vous obtenez la flexibilité, certainement. L’ajout de la programmabilité n’est pas gratuit comme d’habitude, il y a donc un peu de sacrifice. Mais lorsque vous regardez les chiffres bruts, disons que la superficie de ces cœurs RISC par rapport au reste du bloc est inférieure à 5%. La consommation d’énergie est le même genre d’histoire. En fin de compte, si vous jouez correctement vos cartes, ce que vous payez ne doit pas être très visible dans la zone de dé de tout ce qui entre dans cette conception. Nous pensons que nous trouvons un bon équilibre.

IC: Quels secteurs verticaux ont été intéressés jusqu’à présent: fournisseurs de services cloud, gouvernement, commercial?

JK: Je pense qu’il y a une autre façon de voir les choses. Les trois grands domaines de l’IA aujourd’hui sont le traitement d’image, le traitement du langage et les moteurs de recommandation. Ensuite, il y a aussi ce passage des réseaux convolutifs aux réseaux de transformateurs. Tout le monde utilise les mêmes éléments de base. Ensuite, ce que nous avons remarqué, c’est que beaucoup de gens visent les gros hyperscalers, mais les hyperscalers ne les déploieront pas tant que vous ne pourrez pas leur vendre un million de pièces. Mais ils ne veulent pas acheter un million de pièces tant qu’ils n’ont pas vu une preuve de 100 000 pièces. Les clients qui veulent 100 000 unités veulent voir un déploiement de 10 000 unités.

Nous avons parlé à tout un tas de personnes, du haut vers le bas de la pile, et elles sont toutes intéressées. Ceux avec lesquels il est le plus facile de parler vont se déplacer le plus rapidement, comme les start-ups d’IA ou les laboratoires de recherche au sein de grandes entreprises qui possèdent leur propre logiciel. Ils comprennent leurs modèles et continuent de le faire. Notre objectif initial n’est pas d’obtenir un énorme contrat, mais de faire en sorte que 100 programmeurs utilisent notre matériel, le programment et vivent avec lui tous les jours. C’est là que je veux en venir à court terme, et c’est essentiellement notre plan initial.

Mais il s’agit d’un groupe de personnes assez diversifié à qui nous parlons. Il y a la foule autonome, les systèmes de contrôle, l’imagerie, le langage. Nous construisons ce moteur de recommandation sympa, qui a une carte supplémentaire et un ordinateur avec une énorme quantité de mémoire pour faire fonctionner ce modèle. C’est donc assez diversifié, mais nous recherchons des personnes agiles, par opposition à un secteur vertical en particulier.

IC: Jim a été cité comme disant que la conception de Tenstorrent était «l’architecture la plus prometteuse qui soit». Pouvez-vous nous éclairer sur ce que cela signifiait au moment où Jim a investi initialement? S’agissait-il davantage de la conception initiale d’inférence Grayskull, ou y avait-il une vision du processeur Wormhole (prochaine génération)?

JK: Je commencerais par notre flux. Nous avons une pile de compilateurs qui commence par PyTorch générant un graphique, puis le graphique est parallélisé en petits morceaux. Ces morceaux doivent se coordonner entre leurs calculs, puis ils exécutent les noyaux. C’est le flux de base que tout le monde fait. Ce que nous avons, c’est une très belle couche d’abstraction matérielle entre le matériel et le logiciel qui permet à tout cela de fonctionner, et c’est ce que j’aime vraiment.

[In the world of AI], si vous créez un très gros multiplicateur matriciel, le problème est que plus il est gros, moins il est économe en énergie car vous devez déplacer les données plus loin. Donc, vous ne voulez pas que le moteur soit trop gros, vous voulez qu’il soit suffisamment petit pour être efficace, mais vous ne voulez pas qu’il soit trop petit, car alors le bloc de données sur lequel il travaille n’est pas si intéressant . Nous avons donc choisi une assez bonne taille de ce que nous appelons notre processeur Tensix. Le processeur est assez programmable. C’est vraiment bon pour faire des calculs localement en mémoire, puis pour transférer les données de Compute Engine vers Compute Engine, d’une manière qui n’est pas désastreuse pour le logiciel.

J’ai vu des gens dire qu’ils avaient un moteur DMA, et vous écrivez tout ce code pour lui, mais ensuite ils finissent par passer toute leur vie à déboguer des cas de coin. [At Tenstorrent] nous avons une très belle abstraction dans le matériel qui dit (i) calculez, (ii) lorsque vous devez envoyer des données pour mettre les données dans le tube, (iii) lorsque vous le poussez dans le tube, l’autre extrémité le tire hors du tuyau. C’est très propre. Cela a abouti à une équipe de logiciels assez petite et à des logiciels que vous pouvez réellement comprendre.

Alors quand je dis que c’est prometteur, c’est parce qu’ils ont tout un tas de bonnes choses. Les moteurs de calcul sont de la bonne taille, il fait nativement multiplier et convolution matricielle (plutôt que d’écrire pour les threads), et il sait nativement comment communiquer les données autour. C’est très bon pour garder toutes les données sur puce. Nous sommes donc beaucoup plus efficaces sur la mémoire – nous n’avons pas besoin de HBM pour aller vite!

Ensuite, lorsque nous connectons plusieurs puces, la communication sur une seule puce par rapport à la communication de puce à puce n’est pas différente au niveau de la couche logicielle. Ainsi, bien que le transport physique des données soit différent sur puce avec un NOC par rapport à hors puce avec Ethernet, le matériel est conçu de telle sorte qu’il semble simplement envoyer des données d’un moteur à un autre moteur – le logiciel s’en fiche. La seule chose qui fait est le compilateur, qui sait que la latence et la bande passante sont un peu différentes entre les deux.

But again, the abstraction layers are built properly, which means you don’t have to have three different software stacks. If you write on a GPU, you have to be a CUDA programmer in the thread, then you have to coordinate within the streaming multiprocessor, then coordinate on the chip, then you have NVLink which is a different thing, and then you have the network which is a different thing. There are many different software layers in that model, and if you have 1000 people, or if that’s what you think is fun, that’s cool.

But if you just want to write AI software, you don’t want to know about all those different layers. We have a plan that actually will work.

We’re also doing some other interesting things. We are adding general-purpose compute as part of the graph and future products, and we’re looking at how to make it programmer-friendly. We’re also asking programmers want they want to do. I’ve done a lot of projects where you build the hardware, and then the software guys don’t like it because that’s not what they wanted. We are trying to meet the software guys where they are at, because they just want to write code. They also want to understand the hardware so they can drive it, but they don’t want to be tortured by it.

IC: One of the things when I speak to AI software companies is that when they go from a computation on-chip to a multi-chip approach, you have to break down the graph to be able to parallelize it across multiple chips. It sounds like in your design, or in the next-generation Wormhole design at least, you have 16 x 100 gigabit Ethernet connections per chip to connect to multiple chips. From what I understand here, the programmer’s perspective doesn’t change if they’re working on one Wormhole or 100,000? The compilation is done, and the software stack is still just the same?

JK: Yes! We’re actually building a 4U server box with 16 Grayskulls in it. For Greyskull we don’t have Ethernet but they’re connected with PCI Express Gen 4. The compiler can break down a graph across those 16 parts. The software doesn’t care if the transport is PCIe or Ethernet, but Ethernet is more scalable in a big system so we switched to Ethernet for our next generation more scalable part. But we’ll be able to take a training model, have it automatically compile down the software will do the graph, not the programmer.

IC: When you scale to multiple chips, there’s obviously going to be a latency penalty difference when you’re moving data between Tensix cores on-chip compared to off-chip. How does that factor into your design, and then from a software level, should the programmer care?

JK: Here’s the interesting thing about the computation. Matrix multiply is in general N3 computation over N2 elements – as the footprint of the computation gets bigger, the ratio of bandwidth goes down. We think we have the right ratio of bandwidth on Wormhole (next-gen 2022) so that the computation can be very effectively utilized on chips well as the 16 Ethernet ports that supports the communication between chips.

Then the problem comes down to the graph. As a solution designer, you have to think about how to decompose the problem and then how to coordinate it. That’s all handled by our software stack – the programmer doesn’t have to be involved in that. The programmer can think more about how they want their model to look, and the compiler takes care of how to get the best rate out on the chips.

IC: For both the current 2021 Grayskull chip and the future 2022 Wormhole chip, they’re kind of in this sort of 65 to 75 Watt boundary. As you scale out to 1000s of chips, the communication across the whole array becomes a major part of the power discussion, right? By contrast, if you were to have made 300-watt chips would you be able to keep more on die, and have less power would be wasted on communication. How do you marry the two between having a lower power chip, but a wider network array?

JK: We’re more limited by die size. The Grayskull and Wormhole chips are actually fairly large. They’re on GlobalFoundries 12 nm. They are about 650 to 700 square millimeters?

LB: 620 mm2 (for Grayskull) and 670 mm2 (for Wormhole).

JK: So for Grayskull, we have a 75-watt card. That’s the chip plus the DRAM and everything else on the card (so it’s not the chip that’s 75 watts). But we could also run it at 150 watts, at a higher frequency, at a higher voltage.

Then for the next generation beyond Wormhole, when we do a process node shrink, we’re raising the frequency quite a bit and the computational intensity goes up. We’re also shifting to a higher bandwidth interconnect. It’s a slightly higher power form factor, but it’s still less than the current GPU kind of roadmap.

One of the things we do is since we keep most of the memory traffic on-die we don’t need the high bandwidth memory, which has a high power cost. Then for the Ethernet stuff, you only use real power when you’re communicating. We can do some dynamic power management, such that if the network ports are all fully loaded we can slow down the core a little bit to keep it balanced. So the numbers on the quote spreadsheet all look pretty good.

You know reality is fun, because we go build this stuff and we’ll learn a lot. I’ve seen a lot as well, and I expect that we’ll get our ass kicked on a couple things. We’ll wish we’d done this or that different. But the design and simulations we have done look pretty good.

IC: Isn’t there always low-hanging fruit with every chip design though?

JK: Oh yeah, I’ve never done a project. Like I still remember, Dan (Dobberpuhl) and I were the architects of EV5, and when we were done it was the fastest microprocessor in the world. I was so embarrassed about what I did wrong [on that chip], I could barely talk about it. I knew every single problem. But they still put it in the Guinness Book of World Records. It’s a funny phenomenon, when you’re designing stuff, because you are intimate with the details – you talk about the cool stuff, but you know everything.

IC: The next generation Wormhole looks immense. You’ve called it a processor and a switch all in one, as the 16 x 100 GbE ports allow for seemingly unlimited scaling. The presentation at the Linley conference was quite impressive, showcasing 24 of these 75 W chips in a single rack unit, chip to chip enabled through 4 of those connections in a mesh, and then server to server with multiple terabits, and then rack to rack even more, while keeping the same native 100 GbE chip-to-chip connectivity regardless of location. What is the purpose of Wormhole?

LB: That’s a loaded question! It will depend a lot on the workload that you’re running, and the sort of prototypical ‘mega-workload’ of today are these transformer models, like GPT-3. GPT-3 is probably the most famous member of that family right now, and the way people tend to organize those is by a bunch of replicated modules. In these modules there are encoders and decoders, and they’re very similar. The model is a stack of these – a long stack of them. So for a model like that, you can really take the 2D mesh very, very far.

The questions that arise are whether the module or encoder fits on to your specific hardware architecture. So usually for most other architectures that we have been watching you want pretty high bandwidth communication within the encoder or within the decoder, and then the bandwidth needs on the boundary of these boxes are kind of more limited. So what has emerged are solutions where you will have a shelf which is like a 2U or a 4U, and you map one of these blocks onto them. Then there will be network communication between these computers, and they coincide with the edge boundaries there. So one of the messages we tried to give at Linley (the Linley Conference) was that the need to match the encoder or decoder module to a specific 2U/4U system is potentially detrimental. It’s a boundary that forces model designers to adopt a certain set of sizes in a certain model architecture in order to fit the machine.

So one of the things we did was to remove that boundary. We created a uniform grid, it’s really large, and you can basically place the entire pipeline onto that. There are no bandwidth cliffs, and there’s nothing that you really need to be super worried about as you are designing models. One of the big messages that the guys at Linley tried to give was that we’ve attempted to remove the constraints from the model designers for this. There has been a kind of artificial limit to one box per one module of your model which has emerged. So as long as the models don’t change the 2D mesh abstraction is likely to hold up pretty well. The models themselves are 2D-ish, and they’re kind of left to right with data flow, so you don’t see a lot of random connections skipping around from the beginning to the end of the model and so on. So as long as that holds the 2D mesh, it is a pretty good abstraction.

JK: You know, there’s a funny thing – your brain is, I just read this recently, your cerebral cortex is 1.3 square feet. And it’s essentially, it’s a flat thin layer but only six neurons high, but it’s built out of these columns of about 100,000 neurons, and it’s very uniform. So it’s a little 3D-ish. It’s very big in two dimensions, but only six deep in the other dimension. That’s been stable for, you know, hundreds of millions of years.

IC: But the brain has had hundreds of millions of iterations to get it to where it is today. There have also been hundreds of millions of iterations of getting it wrong.

JK: Yeah, that’s for sure! That’s why [at Tenstorrent] we’re iterating every year, and we’re going be at this for a while. It’s pretty cool. The mathematics right now is being formulated as 2D matrices, and the 2D mesh is natural for that, and the way the graph compilers partition stuff is pretty natural for us. The N3/N2 works in our favor.

But getting rid of the artificial boundaries, such as only having eight chips and you might only design for eight chips, whereas we’re building this really cool box with Wormhole, with a lot more chips in it. It has enough bandwidth that we can then make that as part of our mesh going forward. There are also trade-offs to think about, such as if or when one of the shelves breaks, and how do you repair it. Like, how do you want to build the mesh? People have lots of different opinions about that, and essentially at that level we’re flexible, but yeah, there’s something powerful about meshes. Then you have to do a lot of work on reliability and redundancy and rerouting, there are all kinds of interesting details on there.

IC: With the 2D mesh concept, it’s great that you bring up this six neuron high mini-3D model. Is there any desire or roadmap you think on AI compute to move to a more 3D style?

JK: It would be natural for us, because our Tensix cores are actually big enough that they could do the local 3D a little bit. So if somebody wanted to say they want a mesh to be a couple of layers deep, we could do that pretty naturally. For full three-dimensional, we’d have to really think about how the graph partition worked. But you can also plot a 3D thing onto a 2D thing.

IC: Where do you see Wormhole’s limits as the demands on AI grow? Localized SRAM, on-chip memory, compute-per-Tensix core, or bandwidth, or something else?

JK: That’s a pretty good question.

LB: As things stand, with today’s crop of workloads it is pretty well balanced. It’s somewhat difficult to predict what is the first parameter that we’re going to end up tweaking as things change. Between Wormhole and Grayskull, we’ve actually changed the mix of compute and memory in the newer core, so we have more memory per core, and we have more compute per core than before, as well as a little fewer cores per chip. Ultimately that was kind of driven by just literally measurements. What we see as we compile workloads has evolved between the two chips. Your point is definitely true and that workloads evolve, and the right balance of compute to memory to I/O bandwidth also is going to evolve, but what exactly is going to change first? It’s kind of hard to predict.

IC: In one of the diagrams in your recent Linley presentation Ljubisa, you have a rack of Wormholes, and then you have another rack of Wormholes, and the idea is that you span out multiple racks of Wormholes, all connected by 100 gigabit Ethernet. We’re talking 100s of connections server to server and rack to rack. At what point does the cost of the cables become more than the cost of the chips, because those cables are expensive!

LB: We’re not there yet! Jim made a funny remark when we reviewed our internal Wormhole system a couple of weeks back. In the Wormhole systems we don’t have any host processors, so there isn’t any Intel chip in there, or any AMD chip in there, running any kind of Linux. Jim looked at the BOM (bill of materials) cost for the machine and he goes ‘well, I guess we cut out the processor costs, but replaced it with cables’. [laughs] They’re a non-trivial piece of the cost at this point, but they’re still very far from reaching to the level (in cost) that the machine learning processors are at.

JK: That’s one reason why power density really matters. We’re building this really dense 4U box partly to save cables. It definitely matters. On the flip side, networking has gotten better! I remember when we’re struggling like crazy to get to 10 gigabit, and then 25 gigabits a second. We’ve raced through 50 gigabit, 100 gigabit, and 400 gigabit because of signal processing on the wires and just a whole bunch of technology innovation. Network bandwidth has gone up a lot, and it’s amazing that this layer two transport layer which worked at 100 megabits is still a pretty good answer at 400 gigabits. It’s a really interesting technology when you nail the abstraction layer. How far can go? I always joke that they must have changed the laws of physics, because I remember when 100 megabits was a pain, and now we have 400 gigabits.

IC: A few companies have been saying the future is along the integrated silicon photonics line, but the companies that are doing that have multi-billion dollar budgets. Is something like that viable for a start-up like Tenstorrent?

JK: Photonics has been the thing that ‘we’re going to have to go to in five years’ for 20 years. It’s another one of those interesting phenomena – it’s harder to build, especially when the pace of innovation on copper has been spectacular. The first version of photonics will be when is it better in the rack to use photonics than copper, not whether it has to go to the chip. The answer still depends on how far you’re going, and how much bandwidth you have. They’re starting to do the top of the rack mega pipes with photonics. But the wires in a rack are all copper, and the economics of the solution are really clear. It’s one of those static things. It’s like people said ‘Moore’s Law is dead in 10 years’. When I realized they’ve been saying that for 20 years, I decided to ignore it, or at some point investigate why people had that belief for such a long period of time. It’s actually biblical apocryphal stuff. The world is always going to end in 10 years, because that’s when the diminishing return curve runs out.

IC: So what is the future of Tenstorrent’s designs? You’re going from Grayskull in 2021 to Wormhole in 2021, to the gen after that – I think Jim alluded to more compute, to more networking and interconnect. What’s the direction here?

JK: We just announced with SiFive that we’re licensing their cores, and on the next generation we’re putting an array of processors in there. We’re doing it for three reasons. It enables local network stack kind of stuff, such as Smart-NIC behavior and some other things like that. These cores can also run general-purpose Linux, and so you might want to just locally compute some kind of data transformation while you’re using the Tensix cores. But the interesting thing from an AI perspective is that we can put bigger CPUs inside the compute graph on each chip. So as you’re computing some result, you may want to run a C program on that data, and it’s bigger than what the core can do locally, so we can give it to a bigger computer inside the same chip.

Again, it’s about how to give programmers what they want. They want to build models, they want to write code, and they want it all to work together. They don’t want to have this kind of archaic environment where there’s an accelerator and there’s a host and this world is Linux and this world is something else. There are lots of boundaries in AI software today. We’re trying to limit that kind of stuff. So we’re doing it by adding general purpose compute and making sure that all the pieces work really well together.

IC: Those are SiFive’s X280 RISC-V cores, with 512-bit vector extensions?

JK: Yeah, there’s a nice big vector unit and it has the right data types that we wanted for the computation. So you can send the dense 16 bits load over there, and it can compute it, and has the nice big vector unit. They (SiFive) are doing a lot of work to make sure that if you write reasonable vectorized code it will compile and run pretty well. Chris Lattner is over at SiFive now, and he’s one of the best compiler guys on the planet. So it gives us some confidence about where that software direction is going to go. I think RISC-V is really going to, well it’s already making huge inroads all over the place, but with the next generation stuff with big vector units and really great software, RISC-V is going to be pretty cool.

IC: Do you take a die area hit implementing these extra RISC V cores – is it significant?

JK: In our first one (post Wormhole), no. We basically have an array of processors, and we are going to put a column in of CPUs per chip. It’s not big, but it has a lot of general-purpose compute, and now part of what we’re doing is evolving our chip designs. We are also going to evolve our software stack, and we’re willing to do experiments. Because this is a really fast-changing field, we think this is an architecturally interesting direction to go.

IC: Is there any chance that part of your designs can be used as sort of like, a mix and match? Can you have a mesh of previous generation hardware connected to next-generation hardware. Has that ever come up? Or do you think customers in this space will just bulk change from one to the next?

JK: The software we are building is designed to be as compatible as possible. So if you like Grayskull, and then you go to Wormhole, you can build a 16 Wormhole chip machine that works pretty similarly (on the same software), but it scales better. Then when we go to the next chip, all that software you created is going to work, but then if you want to add more functionality you can do that too. If you want to add more functionality, you’re going to want the new one.

But computation intensity is going up, network bandwidth is also going up. So every year you need a new competitive product, but in a semiconductor world you tend to sell parts for 2-4 years, because as you go into production the costs come down. You have to have a pricing strategy. We expect to keep selling the first-generation and second-generation, they’re still good solid parts. But we’ll keep working on new features for the next round.

IC: Tenstorrent is currently partnered with GlobalFoundries for the first couple of chips, Grayskull and Wormhole. Is it still going with GlobalFoundries moving forward, or are you developing relationships with other foundries?

LB: We are developing relationships with other foundries, primarily due to the desire to do some chips in the future in even lower geometries than what we’ve been using.

IC: One of the issues with VC-funded AI companies is the lack of a sufficient roadmap, or the need to acquire funding for that roadmap. How should investors look at Tenstorrent from that perspective?

LB: Our roadmap has been kind of fairly static and consistent over the years. We’ve been able to predict what we’re going to do a few years out, and so far we’ve just been doing that. Luckily enough, we’ve also been able to acquire the funds that are needed to sustain it, so you could say that it’s been roughly split up into epochs. We talked about the basement thing and the office in the bad part of town and those kind of coincided with amounts of funding. After that, we moved into an actual proper working office, there was another epoch with another set of funding. That’s when we did our first chip, the test chip. So pretty much every chip has coincided with a round of funding, and in the first couple of years, they’ve coincided with a move as well.

We recently completed a fairly large round of funding, which we haven’t quite, you know, publicized just yet, in fact, I think this is the first public conversation we’re having about it (Tenstorrent has since announced a $200m funding round on May 20th). What I will say is that it completely enables our roadmap for a couple of years. It enables not only our next one, but a couple of our currently planned future chips. Essentially we’re in a place where we should be able to deliver everything we’re planning to deliver, and by that point, we’re hoping that it’s going to be self-sustaining.

JK: I’ll give you a number – we did a test chip and two production chips (Jawbridge and Grayskull) for $40 million total, and we have a great software team. The genesis of it is really interesting. We have people from the FPGA world, from AI and HPC, and the combination of their talents and insight plus the hardware/software match – it all means that our software team is way smaller than anybody else’s, and our software stack is way more effective and efficient. So that has saved us a boatload of money – we don’t have to announce that we’re hiring 300 software people to make our hardware work because we made good architectural choices, both at the software and at the hardware level. That has made us effective.

The smaller geometry chips are more expensive to do, by about 2X. So it’s going to raise our burn rate a bit. But we have a pretty good line-of-sight to being profitable on the money we’ve already raised, so we feel pretty good about that. That’s partly because we’ve been efficient so far, and we’re not carrying around big technical debt on software or hardware. I think that’s a pretty big difference from some other AI start-ups.

IC: Did bringing Jim on as CTO cause additional interest in the company? I mean, not only from the likes of us in the press but from potential investors or customers?

LB: Absolutely! I mean it’s exactly the same across the spectrum – Jim has a reputation of somebody who is both uniquely able to judge the quality of a technical solution, as well as understanding how you actually bring it out to customers to go sell it. He can go from a technical product or technical concept in an engineering proof-of-concept type story, to something that’s actually shipping in large volume. I mean it’s been a very binary thing, from zero to one, pretty much since Jim joined. We’ve been able to kind of get in the door much more easily at whole variety of places, not only the press, but investors and customers as well, for sure.

JK: I’ve worked at two start-ups, SiByte and then P.A. Semi.  I’ve met literally hundreds of customers, selling processors. They were both network processors, and selling into embedded markets. But I’ve covered a very diverse space. I have a lot of experience of meeting with people and figuring out what they’re actually doing, what they actually need, and then figuring out if we are doing that, and if we’re not doing that, why aren’t we doing it? Then think what should we do about it?

So it’s been fun – I don’t know how many people [I’ve talked to] since I’ve joined on, perhaps 30 to 40 different companies. They’re really diverse, you know, there’s the edge, the autonomous side, the datacenter people, there’s image processing, there’s big cloud computation. The space is really diverse. But they all come back to the same thing – compute intensity, the right amount of DRAM, the right amount of networking, and software that works. They really want to be able to do stuff.

We’re talking to a couple of big companies who are frustrated with the current closed ecosystem, and they are programming companies, so they want to be able to program the hardware. We’re also thinking that we want to program the hardware too, so what is the big problem? But there are lots of secrets in this business, so we’re telling them about how our stuff works, and we’re going to open up both the hardware and software specifications quite a bit. They are super excited about that, so we can get the door open, but the doors don’t stay open unless you have something to say.

IC: So is Tenstorrent big enough to have the scope to work with a few very specific customers on their very specific workloads for the hardware? A big thing about AI companies is essentially assisting their customers with the hardware and helping them program it to get the best out of it. Where does Tenstorrent sit there?

LB: There are two sides to that question. One is how much individual ‘support’ and customization we can sustain. The other one is more of a technical architectural question. [It comes down to] how resistant to the need to be customized for every given use case. When you peel the onion, that feeds all the way into hardware, and the software doesn’t exist in isolation. But it’s like Jim mentioned earlier, we have a fairly small team, partly because we really didn’t need a bigger team to do what we wanted, but also partly because big teams are actually hard. Managing a team of 300 people and effectively contributing to the same codebase is actually something that not too many people or places are capable of. So we tried very very hard, every step of the way, to make our software such that it can be maintained by a  small amount of people, while still meeting the goals that the world was in front of us.

One of the side effects is that there’s very little manual intervention when it comes to machine learning. If you bring in a neural network that we haven’t seen before, we have tried to make it so that the likelihood that we really need to do a bunch of manual tweaking is low. Then if we do need to do it, it’s easier. Like that it’s something we can get done in a couple of days, and not have a three-month burn on. I think we’ve materially succeeded there. So our software stack is pretty well structured, and pretty resilient to new workloads. It is also small – the volume of it is low. We’re talking about a 50,000 lines of code kind of product, not a 5 million one. That makes it a bit easier.

On the other hand, there is still a bunch of work to do for each customer. People usually want to integrate into existing software stacks, into solutions that span more than machine learning. For example, you have video coming in on a camera, and whoever wants to buy an inference engine for that video they want to integrate it into their pipeline. So they want video coming in over IP, decoding it, feeding it into us, decorating it with boxes, or conclusions, re-encoding it, potentially connecting to payment platforms, all sorts of ancillary stuff that’s completely unrelated to machine learning.

So for this sort of thing we are building up a team internally to support this sort of work. That’s kind of part of the solution, and we will certainly be able to sustain this kind of work with a few large customers. But in the long term you really need to build up an ecosystem of collaborators for this kind of thing. I don’t think even the heavyweight companies in this space actually pull all of this by themselves. Usually it’s a bit of an ecosystem-building exercise, and we have that in our plans, but it’s a step-by-step process. First you have to really crush the machine learning workloads, convince everybody that you’ve done that, and you have something great. Then you kind of throw a lot of effort into building an ecosystem, so all of that’s coming down the pipe.

JK: We want to scale the support end of it, not the core compiler side. If we do that part right, it should be a really good tight team. And I saw this at SiByte – there were three operating systems we had to support: the Cisco operating system, Linux and Wind River. Then we had to set the drivers on top of that, and once we nailed that picture, lots of different people could do all kinds of stuff. Because once the broad support package is there, they’re then adding their own software on top of that platform which was pretty straightforward. We had 100 customers with a small support team, but until we figured out the mechanics of the pieces, it seemed complicated, because everybody seems to want something different. But once we got the abstraction layer right in the right operating system and the right set of drivers, then a lot of people could do different things with it.

IC: Speaking of personnel, at AMD Jim was the boss and Ljubisa was part of Jim’s team. This time around, it’s Ljubisa that’s the CEO, and Jim’s the underling. How is that dynamic working? Is it better or worse? How does it come across day-to-day?

LB: That’s not an accurate portrayal of the way we have it set up! We’ve agreed to do this thing as partners for the most part. So Jim is certainly not an underling to me. In reality, if anything, you know, Jim’s somebody that’s senior to me in every way conceivable. So I think it’s cool that we’re doing this in partnership, but really if anybody’s kind of taking direction at points or ambiguities, it’s me.

JK: Ljubisa created Tenstorrent and his team, his original founders and then the core team are some really great people there. We talked a lot about what we should do, and you know, I think it would be absolutely great if we IPO and Ljubisa’s the CEO, and I’m supporting that 100%. We get along really good, we talk every day, and there are some things we divide and conquer. He’s been really focused on the software stack, and I’m focused on the next generation part. There’s a bunch of architectural features that we work on – we get together, we talk about it, and we say ‘you do this, I’ll do that’. So far, that’s been working really well. There’s some business stuff that I’ve been focused on a lot more, because I’m really interested in how this is going to go together and go to market. But yeah, and with investors we mostly both talk to them, then that’s pretty good, and we cover different areas. So you know, so far, so good.

IC: That’s actually quite good because it leads me onto asking Jim about what exactly what you’ve be doing at Tenstorrent so far. At the point you joined, Wormhole was already in the process of going to fabs, being taped out, or at least in the final stages of design. So in my mind you’re working on the next generation and the generation after that, but now you’re telling me you’re doing a lot of the business side as well?

LB: Jim’s a great sales guy. I always figured him to be a persistent dude, somebody that knows technology, but frankly I was surprised by his level of comfort in these meetings with customers.

JK: I was at two start-ups where we had a really good team, with a guy could get all the doors open. We had me that was talking about architecture, with a software guy, with a system board guy, we just had a team. We would go talk to people and go solve their problems, and when you do that, you learn a lot. The thing I like is ‘oh, that’s what you’re doing with our chip! Holy crap, we weren’t thinking about that at all!’.

I’ve been told at various points in my career to focus on that high-level picture of managing, but I always like to get into the details, because that’s where you learn everything, and then you integrate it together and then do something with it. So talking to customers is fun, especially if they’re smart and they’re trying to do something new, so I like to do that kind of stuff. I like to work in partnerships, you know, like Pete Bannon and I have been working together on and off for 30 years. We worked on the VAX 8800, EV5, we worked at P.A Semi and then Tesla, and Apple. Jesus, is that how many places [with Pete]! Dirk Meyer and I worked on at DEC and AMD together for years. You know, I play pretty well with others!

It’s only recently that I found myself being the VP. Raja Koduri and I worked together when he was at AMD, and I was at Apple. Then he came to Apple, and then I went to AMD, then he went back to AMD. He went to Intel, and then I went to Intel. So you know we worked on a whole bunch of projects together so I’m pretty used to, I would say, ‘intense’ intellectual collaboration. Then you find you’re sort of good at different things – like Dirk was way better at execution and details, and I would come up with crazy ideas. He would look at me like ‘I don’t know why you want to do that, but I’ll try it’. We had a lot of fun doing stuff. I wrote the HyperTransport spec, and the original spec was like 16 pages. I sent it to Dirk, and Dirk said ‘Jim, I know how you think – do you mind if I fill in a few details?’. Three days later I got a 60-page spec back that actually looked like something that a human being could read. He was 100% right, because he actually did know what people needed to see in a spec. So yeah, I like that kind of stuff, it’s really fun.

IC: I think you have cultivated that image of mad technical scientist – let’s try a bunch of stuff and somebody else can fill me in with the details, but let’s fill in a bunch of stuff. I mean how often these days do you find yourself in the nuts and bolts of the design versus that more sort of holistic roadmap?

JK: All the time.

IC: All the time?

JK: Yeah, I don’t want to go into too many details, but when I was at Intel, people were surprised a Senior VP was grilling people on how they manage their batch queue, or what the PDK is, or what the qualification steps were, or how long the CAD flows took to run, or what the dense utilization was in the CPU, or how the register file was built. I know details about everything, and you know I care about them, I actually really care. I want them to look good. A friend of mine said, if it doesn’t look good, it isn’t good. So when you look at the layout of a processor, or how something is built, it’s got to be great. You can’t make it great if you don’t know what you’re doing. It’s bad if somebody gives you like a five-level abstraction PowerPoint slide that said, things are going good, and we’re improving things by 3% per year – I’ve been in meetings where somebody said 5% better, and I said ‘better than what? Better than last year, or better than the best possible, or better than your first-grade project?’. They literally didn’t know what – they’d been putting 5% better on the slide for so long, they forgot what it was. So yeah, you have to get the details.

If you’re going to be in the technology business in any way, shape, or form, and you have to get to the details. I thought I was good at that, and then I met Elon Musk. Holy crap. For him the details started at atoms. Maybe lower, I don’t know. But like, what I thought was first principle thinking wasn’t close to his first principle thinking, and then I got my ass kicked seriously about doing that. But it was really great, I really like to do that. I hope that when I engage with engineering teams, they start to get that engineering is fun, and the details matter, and there’s an abstraction stack – there’s the high level, there’s the medium, and there’s a low level. Yes, you do need to know a lot about all of them, because then you can figure out how to fix things. You can’t fix something simple like ‘computer to slow’ – what are you going to do if it’s too slow? If you could go into 1000 details, there’s all kinds of stuff to do if you know the details.

IC: I’m surprised that people would wonder why you’re asking detailed questions about, register file and cache use and such, because this is stuff that you’ve been doing for so long. It kind of seems weird to me, it’s almost as if the person you were speaking to didn’t know who you were?

JK: Yeah, but the positions get associated with technical level. My team at Intel was 10,000 people, right, so you spend a lot of time on organization charts and budgets, and all kinds of admin, and then it’s easy to find yourself just doing that and saying you’ll hand off leadership for a project to this person or this person and that. But the problem is there’s so many things that are cross-functional – I want to know what the fab is doing, how does the PDK work, how does the library work, how does the IP team work, how does the SoC integration work, how does the performance model work, how does the software work. Then you find out that if you can’t deep dive into all those pieces, bad things happen.

My father worked in GE when Jack Welch ran GE, and he said Jack could go to any part of GE and within a day and get to the bottom of it. He got credited with a whole bunch of business innovation, but I heard from many people that Jack could get to the bottom of anything. I read his book Straight From the Gut years ago, and I thought, well, I’d like to be that kind of person you know – if I’m going to manage people, I’d like to be the kind of person to get the bottom of anything.

IC: It’s well known that you’ve been bouncing from company to company every few years….

JK: Nooo, that’s a myth!

IC: That is the general perception, so it have to ask, because Ljubisa alluded to your age earlier, as being more senior – is Tenstorrent your final home, as it were? When do you see yourself retiring?

JK: I’m going to be here forever, but I probably will have a few other things going on. And, you know, I was talking to some friends about a quantum qubit company, which I think is hilarious. Then I have a couple of other friends where we’ve been brainstorming on how to do a new kind of semiconductor start-up, that’s like a million times cheaper than the current stuff. There’s other stuff I’m interested in, but at Tenstorrent, our mission is to go build AI for everyone – programmable chips that people can actually use. That’s a many-year effort.

IC: So will you ever retire?

JK: I read a book somewhere that from retirement to death is 10 years, and I want to live to be 100, so I’ll retire at 90, I guess?

IC: You hear that Ljubisa, you’ve got Jim until he’s 90.

LB: That sounds great! It’s not a surprise, we haven’t discussed it, but if you ask me I would have said something similar.

JK: I like to do stuff – I snowboard with my kids, and I go kite surfing in Hawaii. I like to run and goof around. I’ve got stuff to do, but I like to work and I like technology, and it’s really interesting. It’s amazing, you know that periodically people think this day is the end of this, or the end of that, and holy cats you know the AI revolution is bigger than the internet. It’s going to change how we think about everything, how we think about programming, how we think about computing, how we think about graphics, images, all kinds of stuff. So yeah, it’s a really interesting time to be part of technology.

IC: Is there anything about Tenstorrent that you want people to know that hasn’t really been discussed anywhere?

JK: Well, we’re hiring. So if people want to! I really love engineers who would love to do stuff that are really hands-on. I hired a bunch of senior CPU guys, and the first thing they did is they started bringing up the DB infrastructure and building a model, and getting to the bottom of it. So you know if you want to manage a bunch of people and sit around making PowerPoints, please don’t apply to us. But if you’re a technologist and you want to be hands-on and do real work, that’s great. Or if you’re young and smart, you want to work hard and learn something from really good people, do it. How many people were on the team that built Grayskull? We built a 700-millimeter world-class AI chip with 15 people?

LB: C’est exact.

JK: It’s unbelievable. So if you want to learn how to build stuff, this would be a good place. So send us your resume. They finally prodded me to join LinkedIn. I don’t really know how that works, but they tell me that’s going to help me connect with people and hire.

IC: It really doesn’t!

JK: I don’t know! The thing I really like is it keeps saying ‘your network says you know this person’ – I was like I worked with him a couple years ago, and he was great. So I sent him a message, ‘hey, you want to come work with us?’ It’s been kind of fun, it’s like a little memory lane walk for me because of how the algorithm works. But yeah, I’m not a social media person at all. I just like to talk about things, and I think I’ve sent out like three tweets in my whole life. It’s pretty fun.

IC: You are in Toronto, Austin, and the Bay Area right now?

JK: That’s right, yeah, we did. We took a brand new office in Santa Clara. 10,000 square feet, it’s beautiful. We have an offer on a new office in Austin, which is going to be great. I like having a really nice place to work. When I go to work, I want it to look good. I still remember when I went to Apple, it was hilarious. They changed the font on one of the Mac manuals, so they repainted the fonts on all the signs around the campus to match. That attention to detail just cracks me up, but it was a really nice place to work and it was cool. So yeah, we have three offices, which are all going to be nice places to work.

Many thanks to Ljubisa, Jim, and Christine for their time.
Also thanks to Gavin Bonshor for the initial transcription.