Le dépôt openTPU réunit dans un même projet un simulateur Python de jeu d’instructions, un compilateur, un design SystemVerilog et des outils FPGA pour l’hôte. Ses auteurs déclarent avoir exécuté des modèles de langage sur une carte Inspur Kintex-7. Pour une personne qui développe des systèmes ML ou FPGA, le premier pas le plus accessible est une session de chat logiciel utilisant de vrais poids de modèle. Le transfert du même projet sur une carte exige un modèle de carte précis, des outils de compilation sous licence et une configuration Linux de l’hôte. Ce guide suit le dépôt au commit b9a3f3b du 7 octobre 2026 ; BIG CHANGE ne l’a ni installé, ni simulé, ni testé.

Le grand changement

  • Ce qui a changé : openTPU publie ensemble le jeu d’instructions de l’accélérateur, le simulateur, le compilateur, le RTL et l’intégration de la carte. Un ingénieur peut examiner le chemin qui mène d’une opération du modèle aux instructions simulées avant d’acquérir la carte compatible.
  • Pourquoi c’est important :Le simulateur documenté donne aux personnes qui apprennent le matériel un moyen concret d’étudier le design et d’exécuter un petit modèle de langage avec un logiciel hôte ordinaire. Le projet affirme que des agents IA ont contribué à produire la pile matérielle ; les artefacts consultables permettent d’examiner cette affirmation, tandis que les résultats annoncés sur la carte restent des mesures du projet lui-même.
  • À surveiller :Reproduire le résultat matériel dépend d’une carte Kintex-7, d’une compilation Vivado sous licence et d’une mise en service PCIe fonctionnelle. Le dépôt fournit des commandes et des autotests pour ce travail. Une exécution indépendante sur une révision figée permettrait de savoir avec quelle facilité d’autres ingénieurs peuvent la reproduire.

Figer la source et choisir la voie logicielle

Les étapes ci-dessous suivent le dépôt main au commit b9a3f3bc98e7f74808fd5650bf9db33eaf7b2c93, créé le 7 octobre. Le dépôt comporte un tag v0.5, mais ce guide utilise le commit figé plus récent, dont le README ajoute une section de validation avec Hugging Face. Le paquet Python se présente toujours comme la version 0.1.0 dans pyproject.toml ; ce numéro ne suffit pas à identifier l’instantané du code source. Le dépôt est sous licence Apache 2.0.

Il faut Python 3.10 ou une version ultérieure. Le paquet déclare numpy et textual ; le README installe séparément pytest, torch et transformers pour les tests et l’utilisation des modèles. Il montre la commande Hugging Face hf qui télécharge un checkpoint dans models/LFM2.5-230M . Avant le téléchargement, vérifiez que hf est disponible dans votre environnement Python. Le checkpoint est une entrée de la commande de chat, pas un modèle livré avec le code source. Le projet n’indique ni la taille totale du téléchargement, ni la mémoire requise sur l’hôte, ni une durée fixe du simulateur pour cette voie.

Depuis la racine du dépôt, la séquence documentée est la suivante :

Terminal
git clone https://github.com/FeSens/openTPU.git
cd openTPU
git checkout b9a3f3bc98e7f74808fd5650bf9db33eaf7b2c93
pip install -e .
pip install pytest torch transformers
python3 -m pytest -q
hf download LiquidAI/LFM2.5-230M --local-dir models/LFM2.5-230M
otpu-chat --model lfm2 --backend isa

Les commandes de checkout figent la révision examinée ; les commandes d’installation, de test, de téléchargement et de chat viennent du README. --backend isa sélectionne le simulateur Python de jeu d’instructions. La suite complète pytest comprend aussi des tests RTL qui nécessitent Verilator 5 ; une machine sans cet outil ne peut donc pas utiliser la suite entière comme test de réussite uniquement logicielle. Pour la plus petite exécution interactive documentée, le signal d’achèvement est un checkpoint LFM2.5-230M chargé, suivi d’une interface de chat qui accepte une invite et renvoie du texte du modèle. Les termes exacts de la réponse dépendent de l’invite et de l’échantillonnage. Le code source de la CLI de chat fournit aussi --plain pour un REPL de terminal et --prompt pour une réponse unique ; cette dernière option affiche la réponse et les statistiques du tour. Ce sont des interfaces documentées, pas des sorties observées par BIG CHANGE.

Le README cite Qwen3-0.6B, LFM2.5-230M et Qwen3.5-0.8B parmi les principaux choix de chat, ainsi que plusieurs modèles plus grands. Chacun nécessite son propre checkpoint dans le répertoire de modèles prévu ou un chemin explicite. La voie LFM2 ci-dessus est l’exemple de téléchargement de modèle le plus court du dépôt. Les résultats plus complets du README couvrent dix modèles sur la carte, dont Gemma 4 et des modèles qui nécessitent l’offloading d’experts ; certains utilisent plusieurs formats de poids. Ce tableau contient les mesures des auteurs, pas la promesse que chaque modèle fonctionne avec cette configuration LFM2 à une commande.

Ce que vérifie le simulateur

Le projet décrit un langage de kernel et un compilateur qui produisent des instructions pour son accélérateur. Le simulateur ISA Python exécute ces instructions ; le RTL SystemVerilog constitue l’implémentation matérielle. La présentation du système dans le README et opentpu/isasim.py permettent de suivre cette frontière. Lancer otpu-chat avec isa exerce l’inférence du modèle par la voie logicielle des instructions. Cela ne programme pas un FPGA et ne mesure pas le débit de la carte.

Les responsables indiquent que leur carte produit les mêmes tokens que le simulateur, bit pour bit, et fournissent un script de validation pour comparer certains essais sur l’appareil à une référence Hugging Face sur CPU. Le README figé décrit les invites par défaut, les comparaisons de tokens et de logits, ainsi qu’un essai sur carte le 7 octobre. Les rapports et le code permettent d’examiner ces contrôles. BIG CHANGE ne les a pas reproduits ; ils ne démontrent donc pas indépendamment la précision ou la vitesse.

Ce qui change avec la carte physique

Le manuel de la carte vise l’ Inspur YPCB-00338 avec un Xilinx Kintex-7 xc7k480t-ffg1156-2, deux canaux DDR3 de 2 Gio et une connexion PCIe à un PC hôte. La compilation Bitstream par défaut utilise Vivado 2026.1. Le manuel affirme que l’édition gratuite exclut cet appareil et suggère une licence payante ou une évaluation de 30 jours. La table des appareils AMD de 2026.1 contredit cette affirmation : Basic inclut tous les appareils Kintex 7.

Les options de licence actuelles d’AMD indiquent que Basic coûte 0 $, prend en charge Linux et se renouvelle gratuitement chaque année. La FAQ sur les licences précise que Basic nécessite tout de même un fichier de licence annuel valide ; l’évaluation distincte avec toutes les fonctions dure 60 jours. La table des fonctionnalités AMD 2026.1 indique que Basic permet la programmation JTAG, mais limite la simulation XSIM et certaines fonctions de débogage. Les niveaux payants supérieurs ajoutent des fonctions, et AMD affirme que les licences IP ne changent pas. BIG CHANGE n’a pas compilé openTPU avec Basic. Il faut vérifier les droits d’utilisation des outils et de la propriété intellectuelle pour ce flux Bitstream avant de le considérer comme gratuit. Le manuel estime que make bit prend de 1,5 à 3 heures selon la machine. Ni le manuel ni le tableau des niveaux AMD ne donnent le prix d’achat de cette carte ou le coût total d’une reproduction.

Une fois la carte et la chaîne d’outils obtenues, la voie documentée consiste à construire un bitstream dans boards/ypcb-00338, à programmer le FPGA par JTAG et à configurer l’hôte Linux. Le Makefile de la carte envoie la sortie de make bit vers build/vivado/otpu.bit. make program utilise openFPGALoader par défaut ; le manuel décrit aussi le gestionnaire matériel de Vivado. Un chargement JTAG ne persiste pas après un cycle d’alimentation.

Terminal
cd boards/ypcb-00338
make lint
make bit
make program

Les étapes matérielles ci-dessus viennent du manuel de la carte ; elles n’ont pas été testées ici. Sur l’hôte Linux, la liste de mise en service demande le paquet Python et le checkpoint, sudo otpu-setup pour installer le pilote XDMA et les règles de périphérique, un nouveau balayage PCIe après un chargement JTAG, puis otpu-setup --check. La documentation indique que cette dernière commande se termine avec succès et affiche « all in place » lorsque le pilote, la carte, la liaison, les nœuds de périphérique et le registre ID sont corrects. Ensuite, otpu-selftest vérifie la carte avant otpu-chat --backend board --model lfm2. Les diagnostics de la carte peuvent être enregistrés avec otpu-diag --json diag.json. Ces contrôles constituent des signaux concrets d’achèvement de la voie matérielle ; un chat ISA seul ne peut pas les remplacer.

Les chiffres de performance publiés demandent la même prudence. Le README rapporte, par exemple, 82,1 tokens par seconde en temps réel pour LFM2.5-230M avec des poids 4 bits et une tête int8 sur la carte des auteurs. La méthode utilise 64 tokens décodés de façon gloutonne après une invite de 512 tokens, et le tableau distingue les cycles de l’appareil du temps réel incluant l’hôte. Un autre hôte, bitstream, format de poids ou invite donne une mesure différente. Le message de commit du 7 octobre rapporte des qualifications supplémentaires sur la carte, mais reste une note des responsables. Les sources examinées pour ce guide ne comprennent pas de benchmark reproduit de façon indépendante.

Sources et lectures complémentaires

  • Dépôt openTPU au commit examiné, 7 octobre 2026. Le README fournit la présentation du système, les commandes du simulateur, la liste des modèles et les mesures sur carte rapportées par les auteurs. Ce sont des affirmations du projet ; BIG CHANGE n’a pas exécuté le dépôt.
  • Métadonnées du paquet Python et licence Apache 2.0. Elles établissent la version de Python, les dépendances déclarées, les points d’entrée CLI, la version du paquet et la licence du code source. Les checkpoints des modèles et Vivado ont des conditions et besoins distincts.
  • Manuel de mise en service de la carte et de l’hôte, consulté le 7 octobre 2026. Il précise la carte prise en charge, les étapes du bitstream, la configuration Linux, la programmation JTAG et les autotests. Ses indications sur la licence payante et l’évaluation de 30 jours contredisent les documents de licence AMD actuels pour 2026.1. Certains exemples historiques de bitstream concernent d’anciens builds ; pour reproduire le résultat, utilisez l’arbre figé et les instructions de build actuelles.
  • Disponibilité des appareils AMD Vivado 2026.1, UG973 et appareils et fonctions pris en charge, tous deux datés du 23 juin 2026, ainsi que les options de licence, consultées le 7 octobre. Ces documents placent tous les appareils Kintex 7 dans Basic gratuit, indiquent la prise en charge de Linux et JTAG, et présentent les limites de simulation et de débogage de Basic. La FAQ d’AMD sur les licences précise le fichier de licence annuel Basic et l’évaluation de 60 jours. La compatibilité de l’appareil ne vérifie pas à elle seule le flux bitstream complet du projet sous Basic.
  • CLI de chat et guide LFM2. Ils présentent le choix du backend, le chemin du modèle, le comportement des sorties interactives et ponctuelles, ainsi que l’exemple du petit checkpoint.
  • Le reportage de GIGAZINE du 7 octobre donne un contexte utile sur l’attention publique accordée au projet. Les détails de configuration et de performance de ce guide ont été vérifiés dans le dépôt, pas repris de ce reportage.