1er aoûtLe 9e salon technique Meet AI Compiler, organisé par HyperAI, s'est conclu avec succès à Zhongguancun, Pékin.Ce salon a rencontré un vif succès, comme toujours, grâce aux présentations éclairantes d'experts du secteur. Il a réuni des responsables techniques d'entreprises et d'instituts de recherche de premier plan, tels que l'Académie d'intelligence artificielle de Pékin, l'équipe TileRT, Tencent, Huawei Ascend et Zhiyuan Innovation, afin de partager des analyses approfondies sur les technologies de pointe, les optimisations sous-jacentes, les écosystèmes open source et les cas d'application dans le domaine de la compilation d'IA. Ce fut un véritable festin technique pour les développeurs et les professionnels présents.

sur place,Ma Lingxiao, membre clé de l'équipe TileRT, a présenté en détail les derniers développements de TileRT, intitulés « La vitesse est intelligence : exploration informatique et conception collaborative pour l'inférence de grands modèles à très faible latence ».De l'évolution des compilateurs d'IA et de l'architecture d'exécution à la co-conception modèle-système, en passant par les résultats d'intégration et les cas pratiques avec de nombreuses entreprises et communautés technologiques de premier plan telles que Z.AI, Xiaomi MIMO et vLLM, la présentation détaille la pile logicielle pour le calcul de grands modèles avec une latence ultra-faible.

HyperAI a compilé et résumé le discours sans en altérer le sens original. Voici la transcription du discours.

La vitesse d'inférence est devenue un avantage concurrentiel essentiel dans les scénarios d'IA à forte valeur ajoutée.

ChatGPT a vu le jour fin 2022 et début 2023, démontrant des capacités étonnantes. Cependant, avec le recul, les premiers modèles se sont principalement révélés utiles dans des domaines comme la messagerie instantanée et l'accompagnement, leur valeur réelle étant bien inférieure à leur coût de calcul. La vitesse de traitement des grands modèles devait simplement suivre celle de la lecture humaine. À cette époque, l'accent était mis sur le débit global du système, et non sur la vitesse de traitement du modèle.

De fin 2025 à aujourd'hui, en moins d'un an, l'émergence d'agents de programmation comme Claude Code a révélé des capacités insoupçonnées sous-jacentes aux modèles à grande échelle, notamment en contribuant réellement à améliorer la productivité. Dans ce cas précis, comparé au coût de la puissance de calcul, il a généré une valeur pratique supérieure. Par conséquent,Nous avons récemment constaté une forte augmentation de la demande en puissance de calcul, ce qui reflète directement le besoin de débit élevé.

Compte tenu de cette tendance de développement, et à mesure que les capacités des modèles augmentent, ces derniers participeront inévitablement à des tâches plus automatisées, telles que les usines à IA, la prise de décision quantitative et les projets de contrôle des risques en temps réel. Dans ce scénario, le modèle deviendra lui-même sa propre sortie, créant ainsi un flux de travail automatisé par l'IA. À ce stade,Plus le modèle est rapide, plus son efficacité est élevée. La vitesse maximale du modèle deviendra un facteur déterminant de la productivité et de l'expérience utilisateur.

Les dernières nouvelles du secteur confirment elles aussi, les unes après les autres, les spéculations ci-dessus :

* Fin 2025, Nvidia a acquis Grop pour une somme considérable afin d'étendre ses capacités d'inférence à haute vitesse ;

* En février 2026, Anthropic a lancé Claude Fast, une version haute vitesse de cette technologie.

* Au cours du même mois, OpenAI, en collaboration avec Cerebras, a lancé GPT-Codex-Spark ;

* En mai, Cerebras a annoncé avoir atteint une vitesse d'inférence de près de 1 000 TPS pour un modèle de niveau 1T grâce à une technologie de puce au niveau de la plaquette.

* De plus, il y a seulement deux ou trois semaines, OpenAI s'est associé à Cerebras pour permettre à son modèle phare le plus avancé, GPT-5.6-Sol, d'offrir un service d'inférence à haute vitesse de 750 TPS.

La mise à l'échelle au temps de test (TTS) est en fait le principal moyen d'améliorer les performances du modèle.Dans un intervalle de temps donné, par exemple 10 secondes, un service d'inférence de modèle plus lent (50 jetons/s) ne peut générer que 500 jetons de réflexion. En revanche, si la vitesse d'inférence passe de 50 à 1 000 jetons/s, il en générera 10 000. Il est donc indéniable que, dans le même intervalle de temps, une inférence plus rapide se traduira par une meilleure intelligence du modèle.

Vous vous demandez peut-être pourquoi privilégier la vitesse alors qu'il existe de nombreuses façons d'implémenter la synthèse vocale, comme Best-of-N, qui permet d'obtenir une intelligence supérieure grâce au simple traitement par lots ? Cela nécessite d'analyser en détail le fonctionnement de la synthèse vocale.Si on la considère à la fois en termes de profondeur et de largeur,Bien que les tâches de synthèse vocale puissent atteindre leurs objectifs par traitement par lots, ce modèle fonctionne en mode séquentiel, considérant une longue chaîne de raisonnement ou une série d'étapes d'exécution d'agents. Ceci est impossible avec le traitement par lots, et la profondeur du traitement séquentiel ne peut être atteinte qu'au prix d'une vitesse d'inférence extrêmement rapide.

Prenons l'exemple d'une trajectoire de test SWE-bench, plus précisément des statistiques de trajectoire SWE-smith. La trajectoire d'exécution réelle montre qu'elle comporte en moyenne 30 étapes d'exécution du modèle, générant 10 000 jetons. À une vitesse de 50 jetons/s, cela prendrait environ 200 secondes, soit plus de 3 minutes. Cependant, si la vitesse du modèle est augmentée à 1 000 jetons/s, la tâche peut être accomplie en seulement 10 secondes. L'expérience sera alors radicalement différente.À vitesse normale, les utilisateurs pourraient être interrompus par le temps d'attente, mais si l'opération ne prend que quelques secondes, ils bénéficieront d'un processus interactif en temps réel.

De plus, examinons d'autres scénarios. Par exemple, le trading quantitatif à haute fréquence exige généralement un retour d'information de l'ordre de 10 millisecondes, les appels vocaux en temps réel peuvent nécessiter un retour d'information de l'ordre de la centaine de millisecondes, et le contrôle des risques financiers peut également exiger un retour d'information de l'ordre de la seconde. Par conséquent, le délai de retour d'information dans ces scénarios d'interaction en temps réel se situe approximativement entre quelques secondes et 10 secondes. Si ces seuils temporels ne peuvent être respectés, le modèle ne peut être correctement mis en œuvre dans ces situations.

Par conséquent, nous allons pousser la vitesse de raisonnement à ses limites.D’une part, nous espérons permettre un plus grand nombre de scénarios d’application ; d’autre part, nous espérons également permettre la génération d’une intelligence de modèle plus performante.

Atteindre une vitesse maximale grâce à une approche collaborative des algorithmes, des systèmes et du matériel.

Alors, comment maximiser la vitesse de décodage d'un modèle ? Cela dépend en fait de trois facteurs.Le premier point concerne les performances du matériel lui-même.En tenant compte de la puissance de calcul, de la bande passante et de l'interconnexion, elle détermine la limite supérieure de la vitesse de décodage ;Le second point concerne l'efficacité du système logiciel.Autrement dit, comment optimiser les performances offertes par le matériel ;Troisièmement, l'algorithme.Par exemple, en réduisant les calculs et l'accès à la mémoire grâce à la quantification, ou en utilisant des méthodes telles que le décodage spéculatif, il est possible de générer davantage de jetons à partir d'un seul calcul direct.

Commençons par examiner l'efficacité du système.Partant des principes fondamentaux, il subsiste un écart important entre la vitesse réelle d'inférence de modèles et la limite théorique maximale offerte par le matériel. Ceci s'explique par le fait qu'outre le calcul lui-même, des surcoûts fixes surviennent lors de l'exécution, tels que le démarrage du noyau, la planification, la synchronisation et la communication. À mesure que les performances matérielles s'améliorent, ces surcoûts deviennent de plus en plus prépondérants et constituent progressivement des goulots d'étranglement majeurs pour l'inférence à faible latence.

Il existe déjà de nombreuses technologies permettant de réduire ces surcharges fixes, telles que CUDA Graph et PDL. CUDA Graph réduit principalement la surcharge liée au lancement du noyau, tandis que PDL permet à deux noyaux d'établir des dépendances et des pipelines à l'avance, mais ne permet en réalité qu'un chevauchement d'un seul saut. Pour atteindre des performances optimales, cela est loin d'être suffisant. Il est nécessaire d'aller plus loin et de dépasser les limites d'exécution définies par le noyau lui-même, tout en décentralisant davantage la granularité de l'ordonnancement.Cela permet aux fonctions de calcul, d'accès à la mémoire et de communication, initialement séparées par des noyaux différents, de se chevaucher davantage.

En réalité, la fusion de noyaux n'est pas un concept nouveau ; de nombreuses recherches ont été menées depuis l'ère des réseaux de neurones profonds. Nous avons précédemment réalisé une série d'études sur des problématiques telles que l'ordonnancement inter-opérateurs, la génération de noyaux, l'accès mémoire, le flux de contrôle dynamique, le calcul à faible précision et le pipeline logiciel, notamment avec Rammer, Roller, Welder, Cocktailer, Ladder et PipeThreader.Progressivement, une capacité de compilation a été développée, allant de l'optimisation au niveau du graphe à une exécution fine au niveau des tuiles.Elle a été validée sur différents matériels et dans des scénarios réels.

Cependant, ces capacités ne peuvent pas être directement transférées à l'inférence de modèles de grande taille.Comparée aux DNN traditionnels, l'ère LLM présente trois nouveaux défis :L'amélioration des performances matérielles accentue l'importance des coûts fixes tels que la planification et la communication ; le routage MoE, le calcul clairsemé et les mécanismes de décodage spéculatif augmentent le dynamisme d'exécution ; et l'augmentation de la taille des modèles favorise la collaboration entre cartes et entre machines. Par conséquent, les systèmes de compilation orientés LLM doivent gérer simultanément l'exécution fine, la planification dynamique et la collaboration distribuée.

Face à ces défis,L'idée centrale de TileRT est de ne plus considérer le noyau comme la limite fondamentale de la planification logicielle, mais de dépasser cette limite, de décomposer l'exécution en une granularité plus fine et de réorchestrer le calcul, l'accès à la mémoire et la communication d'un point de vue global.

Examinons d'abord le processus d'ordonnancement du framework existant. Pour un modèle complexe, il est généralement décrit sous forme de graphe de calcul, puis déployé sur le matériel pour une exécution opération par opération, noyau par noyau. Chaque noyau possède son propre processus de démarrage, de calcul et de synchronisation, et ses limites restreignent les possibilités de chevauchement entre les différentes étapes.

TileRT vise précisément à abolir cette frontière. En décomposant les calculs au sein du noyau en tâches plus fines au niveau des tuiles, le logiciel peut réorganiser l'ordre d'exécution au-delà des frontières existantes entre les noyaux, permettant ainsi aux calculs, accès mémoire et communications suivants, qui satisfont déjà leurs dépendances, de démarrer plus tôt et de former un pipeline plus compact. Concrètement, il ne s'agit pas simplement de fusionner plusieurs noyaux en un noyau plus grand, mais plutôt de lever les limitations du noyau en matière d'espace d'ordonnancement, permettant ainsi un chevauchement plus important qu'auparavant.

TileRT utilise des études de cas réels pour valider la faisabilité de sa technologie.

TileRT commence par représenter le modèle sous forme de graphe de flux de données, puis génère un micro-noyau au niveau des tuiles. Il effectue ensuite une compilation et une planification fines pour générer le moteur d'exécution. Ce moteur orchestre les calculs, les accès mémoire et les communications, et répartit les tâches entre les différentes unités matérielles afin d'exploiter pleinement les performances du dispositif.

Grâce à cette méthodologie, TileRT a déjà été validé dans des services de production réels. En mai dernier, nous nous sommes associés à l'équipe Zhipu GLM pour lancer le service d'inférence haute vitesse GLM-5.1-HighSpeed.Elle a atteint une vitesse de production de 400 jetons/s.L'optimisation Sparse Attention pour GLM-5.1 en est un exemple représentatif. Alors que les architectures Tensor Parallels traditionnelles utilisent généralement différents GPU pour exécuter la même logique de calcul, TileRT la répartit entre différents nœuds de calcul hétérogènes : un GPU gère l'indexation Sparse, la sélection des K premiers éléments et le routage, tandis que les sept autres GPU prennent en charge les tâches gourmandes en calcul telles que MLA et Attention. La communication, la réduction et la synchronisation sont également intégrées au pipeline au niveau des tuiles. Ceci permet aux différentes étapes d'adopter des méthodes de mise à l'échelle plus adaptées à leurs caractéristiques spécifiques, réduisant ainsi les calculs redondants et les temps d'attente liés à la synchronisation. Sans MTP, la vitesse de génération est d'environ 300 jetons/s pour les séquences courtes et d'environ 200 jetons/s pour les séquences longues. Avec MTP-3 activé et une longueur de réception moyenne de 3,2, la vitesse de génération peut dépasser 600 jetons/s pour les séquences courtes et environ 400 jetons/s pour les séquences longues.

Si nous voulons des vitesses encore plus élevées, nous devons également optimiser l'efficacité de sortie de chaque octet de jeton.Pour optimiser le nombre de jetons par octet, deux aspects sont à prendre en compte :D'une part, nous voulons générer plus de jetons par étape, nous pouvons donc utiliser MTP ou des schémas de décodage spéculatifs plus agressifs comme DFlash ou DSpark ; d'autre part, nous pouvons réduire la quantité de données requises par jeton en utilisant certaines méthodes de quantification pour réduire la quantité de données.

En juin, nous avons collaboré avec l'équipe Xiaomi MiMo pour concevoir le modèle et le système basés sur cette idée.En matière de quantification, le module Expert du MoE de MiMo-V2.5-Pro représente la majorité des paramètres du modèle. Par conséquent, seul ce module est quantifié à l'aide de la QAT FP4, tandis que les autres modules conservent leur précision d'origine. Les tests de performance montrent que les performances globales du modèle quantifié sont proches de celles du modèle FP8 original, tout en réduisant considérablement sa taille et la pression sur la mémoire. Pour le décodage spéculatif, DFlash utilise la prédiction parallèle au niveau des blocs, générant un ensemble de jetons candidats à chaque passage, lesquels sont ensuite vérifiés uniformément par le modèle principal, réduisant ainsi la surcharge séquentielle du décodage autorégressif traditionnel.

Ces modèles sont utilisés pour l'optimisation collaborative avec le système.MiMo-V2.5-Pro-UltraSpeed a finalement atteint une vitesse de génération de plus de 1000 jetons/s pour les modèles 1T sur un seul nœud 8-GPU à usage général.Plus important encore, ce résultat ne repose pas sur des puces d'inférence dédiées au niveau de la plaquette ou autres, démontrant ainsi que, grâce à une collaboration suffisante entre le modèle et le système, les GPU à usage général peuvent même surpasser les vitesses d'inférence extrêmes auparavant réservées au matériel dédié. Ce résultat montre qu'à mesure que les performances du système approchent les limites du matériel, les gains de vitesse ne dépendent plus uniquement du moteur d'inférence, mais nécessitent une évolution conjointe de la structure du modèle, du système de compilation et des méthodes d'exécution matérielles.

Bien entendu, la simple recherche d'une vitesse de décodage extrême ne suffit pas. Un service de modélisation à grande échelle véritablement utilisable requiert également des API compatibles avec OpenAI, la planification des requêtes, la mise en cache des préfixes, les appels d'outils et des capacités opérationnelles éprouvées. Si l'ensemble du système de service devait être reconstruit uniquement pour intégrer un moteur de décodage haute vitesse, les coûts d'ingénierie seraient prohibitifs. Par conséquent,Nous nous sommes associés à la communauté vLLM pour permettre à TileRT de se concentrer sur le décodage à faible latence tout en tirant parti de l'écosystème vLLM mature.

La séparation du préremplissage et du décodage constitue une base solide pour cette solution. Grâce à cette dissociation, le décodage peut devenir un moteur d'exécution modulaire. Dans la solution conjointe TileRT et vLLM, le préremplissage, la planification des requêtes, le préremplissage par blocs, le cache de préfixes et les API de service restent fournis nativement par vLLM. Seules les requêtes exigeant une vitesse de génération élevée pour un seul utilisateur sont traitées par le pool de décodage TileRT. Ceci préserve l'intégralité des fonctionnalités de l'écosystème vLLM tout en offrant les performances de décodage à très faible latence de TileRT.

Dans sa mise en œuvre, TileRT se connecte exclusivement via l'interface Connector exposée de vLLM, sans nécessiter de modification ni de duplication de vLLM, ni d'intrusion dans ses Workers internes. La couche de routage marque les requêtes sensibles à la latence, et le connecteur TileRT n'accepte que celles-ci ; les autres requêtes suivent le chemin de traitement natif de vLLM. Les deux pools de décodage peuvent partager le même service Prefill de vLLM. L'état généré par Prefill est transmis au nœud de décodage correspondant via des moteurs de transport tels que NIXL ou Mooncake, et exécuté en parallèle avec les processus Prefill suivants.

Par conséquent, au sein d'un même déploiement, les requêtes sensibles à la latence, telles que les agents temps réel et le codage interactif, peuvent être acheminées vers TileRT ; les requêtes classiques visant une forte concurrence et un débit global élevé continuent d'être traitées par le moteur de décodage natif vLLM. Les deux voies offrent la même API compatible avec OpenAI, et le passage d'un service à l'autre ne nécessite qu'un ajustement de la stratégie de routage.Cela permet à TileRT et vLLM de former une architecture de service d'inférence hétérogène véritablement coexistante, où chacun tire parti de ses atouts.

L'écosystème TileRT se développe progressivement.

Actuellement, TileRT prend en charge plusieurs modèles et plusieurs déploiements d'écosystèmes :

À la fin de l'année dernière, nous avons publié le prototype d'adaptateur pour DeepSeek v3.2, capable d'atteindre une vitesse d'inférence de 500 TPS.

En mai de cette année, nous avons lancé avec Zhipu une version haute vitesse de GLM-5.1, atteignant des services d'inférence de 400 à 600 TPS ;

En juin de cette année, nous avons collaboré avec Xiaomi MIMO pour réaliser une percée de 1000 TPS pour la première fois pour un modèle de niveau 1T, battant ainsi le record mondial de vitesse d'inférence ;

Par la suite, nous nous sommes associés à MIND LAB pour lancer la première plateforme prenant en charge l'inférence multi-LoRa à haute vitesse, permettant la production d'interfaces utilisateur en temps réel en moins de 5 secondes ;

Enfin, en collaboration avec la communauté vLLM, nous avons publié une solution de déploiement PD hétérogène coexistante et séparée, qui ne nécessite aucune modification et prend en charge la compatibilité de l'écosystème.

Enfin, voici les dernières nouveautés concernant la communauté Tile-AI. La communauté Tile-AI est un écosystème logiciel que nous avons repensé à partir de Tile, spécifiquement pour les grands modèles et les nouvelles architectures matérielles, notamment le célèbre TileLang. TileScale est un framework de programmation et de compilation conçu pour les architectures distribuées, y compris les architectures de cœur distribuées intégrées.Cela inclut également les interconnexions entre puces, entre puces et entre machines. Nous avons unifié et abstrait cette structure distribuée multicouche dans la description de Tile et conçu un cadre de travail approprié. TileRT est le moteur d'inférence permettant d'atteindre les vitesses extrêmes décrites précédemment.

De plus, nous avons récemment lancé TileFoundry et TileOPs. TileFoundry est un framework basé sur l'IA pour la génération automatique d'opérateurs, et son résultat est TileOPs, une bibliothèque d'opérateurs TileLang pour les grands modèles. Parallèlement, nous nous apprêtons également à publier TileSight, un modèle d'analyse de performance destiné principalement à la modélisation des performances au niveau des tuiles, offrant ainsi des indications pour l'optimisation des performances des programmes au niveau des tuiles et l'analyse exploratoire de l'architecture.