Lors du sommet des CIO et dirigeants des entreprises numériques de l’État central des entreprises d’État de 2026, organisé par D1net pour l’automne (19e édition), Tang Anbo, directeur des solutions de flux à base de silicium, a participé au sommet et a présenté un discours sur le thème : « De “puissance de calcul” à “productivité Token” : l’infrastructure d’inférence et les pratiques ROI pour la mise en œuvre à grande échelle des grands modèles d’État central ». Voici les points clés du discours.
En ce moment, les applications d’IA se trouvent dans une phase précoce de croissance explosive, avec une consommation de Tokens qui augmente de manière exponentielle. Derrière cela, la structure du modèle évolue constamment et les mises à jour sont rapides ; en même temps, l’architecture de calcul se développe également. Entre les modèles et le calcul, il y a un processus d’itération mutuellement stimulant. Pour les entreprises, d’une part, elles doivent s’adapter à ces changements, et d’autre part, elles doivent proposer des services de modèles diversifiés pour leurs scénarios de business, tout en maîtrisant les coûts dans une limite raisonnable.
Le flux à base de silicium fait ce qui suit : il établit une couche de transformation entre la puissance de calcul et les tokens, en regroupant toutes les capacités de calcul sous une gestion unifiée ; grâce à un moteur de raisonnement développé en interne, les modèles fonctionnent plus rapidement et de manière plus efficace. Nous construisons des usines de tokens sur le cloud public, et nous aidons également les entreprises publiques et étatiques à créer leurs propres usines de tokens internes.
En bref, grâce à une ingénierie de raisonnement systématisée, il est possible d’assurer une adaptation multiple entre les modèles et la puissance de calcul. Sur cette base, le flux à base de silicium propose la formule centrale de productivité des tokens : Productivité des tokens = Capacité de production × Taux d’utilisation × Qualité de livraison. La capacité de production est déterminée par les capacités matérielles du chip et le niveau d’optimisation du modèle ; le taux d’utilisation s’obtient grâce à la gestion du trafic et l’ajustement intelligent de la puissance de calcul ; la qualité de livraison inclut la précision de la raisonnement du modèle, le taux de réussite de l’exécution des tâches telles que les appels aux outils, ainsi que la stabilité des services SLA nécessaires dans l’environnement de production.
De la gestion unifiée à l’exploitation basée sur des modèles, pour réaliser véritablement l’utilisation efficace de la puissance de calcul
De l’angle des activités et du trafic, nous avons conçu une architecture découplée à quatre niveaux. Le fonctionnement du modèle, son entretien, l’exécution de la raisonnement et l’organisation des capacités de calcul sont connectés entre eux, couvrant toutes les étapes de la vie du modèle, depuis sa mise en œuvre jusqu’à son service. La conception de cette architecture découplée par niveaux vise également à s’adapter aux infrastructures existantes des entreprises publiques et d’État, afin d’éviter une construction redondante ; si l’entreprise dispose déjà de capacités de développement interne, elle peut intégrer les systèmes existants, sans avoir besoin de tout reprendre à zéro, et peut ainsi compléter directement les compétences nécessaires par une « combinaison de capacités ».
Gateway de modèle : non seulement une entrée, mais aussi une plateforme de gestion de modèles.
Cette couche est directement en contact avec les utilisateurs des services de modèles, tels que les entreprises de molécules et les groupes affiliés. Toutes les invocations de grands modèles sont effectuées par cette couche pour les tâches de mesure, de facturation et d’authentification de base. Plus important encore, elle propose une variété de stratégies de planification et de routage : par exemple, en fonction des exigences de temps de réponse différents pour chaque scénario de service, les requêtes peuvent être routées vers les services de modèles correspondants, permettant ainsi que les services ne se perturbe pas mutuellement et garantissant à toutes les parties un SLA satisfaisant ; elle prend également en charge une planification flexible selon des objectifs variés tels que la priorité aux performances ou au coût.
Plateforme de service de modèles : livrer aux entreprises les meilleures pratiques de déploiement et d’opération.
Cette couche gère principalement, du point de vue opérationnel et de maintenance, les capacités liées au déploiement des modèles et aux entrepôts de modèles. Nous intégrons les bonnes pratiques de déploiement des modèles, permettant ainsi aux entreprises d’activer les modèles avec une seule touche, plutôt que de devoir effectuer à chaque fois une adaptation complète. Nous avons déjà adapté près de cent modèles, et de nouveaux modèles principaux continuent d’être adaptés, dans le but de permettre aux équipes métier d’utiliser les modèles immédiatement après leur installation.
Framework de raisonnement haute performance : optimisation itérative orientée vers des modèles et matériels spécifiques.
Nous collaborons en profondeur avec différentes entreprises de calcul puissant, et en fonction de modèles spécifiques et de capacité de calcul, nous développons des bibliothèques d’opérateurs et des bibliothèques de communication, afin de maximiser les performances du modèle sur le matériel correspondant. Par exemple, en collaboration avec Huawei Cloud, le service DeepSeek R1/V3 Token basé sur un chip national a été lancé pour la première fois dans l’industrie. De plus, des solutions de raisonnement ont été développées et optimisées ensemble pour le cluster hyper-nœud CloudMatrix, permettant une consommation de Decode par carte mère de plus de 1 920 tokens/s sur DeepSeek-R1 ; la mise en œuvre commerciale du service de modèle de grande taille Kimi-K2 basé sur le cluster C550 de MUXI a été présentée mondialement ; l’installation de DeepSeek-V3 sur le chip MTT S5000 de MooreThread a permis une consommation de Prefill par carte mère de plus de 4000 tokens/s et une consommation de Decode de plus de 1000 tokens/s.
En même temps, nos techniques de raisonnement évoluent également continuellement : à mesure que le contexte des tâches de traitement du modèle augmente et que la concurrence s’améliore, il est nécessaire d’optimiser en permanence les frameworks de raisonnement, tels que l’optimisation des opérateurs, l’optimisation des communications et la quantification du modèle. Parallèlement, en combinant la séparation PD ainsi que l’extraction hiérarchisée du cache KV, on améliore globalement les performances et la capacité de traitement du modèle.
Planification de la puissance de calcul : Gestion élastique des ressources de puissance de calcul.
Le planification flexible du calcul informatique est un élément clé pour réduire les coûts de raisonnement et améliorer l’efficacité de l’utilisation du calcul. Cependant, la planification du calcul rencontre souvent une difficulté : si elle est trop conservatique, elle peut rapidement atteindre son plein rendement ou même être surchargée ; si elle est totalement adaptée au pic de performance pendant la journée, cela entraîne un gaspillage de ressources à d’autres moments. Par conséquent, il est nécessaire à la fois de stratégies de scalabilité flexibles et de méthodes opérationnelles adaptées.
Par exemple, lorsque les entreprises publiques centrales fournissent des services de modèle aux différentes sociétés filiales, une tarification par temps peut être utilisée dans les transactions internes : le prix est fixé normalement pendant la journée, et un réduit est accordé la nuit, afin d’encourager certains services à fonctionner la nuit. Chaque service peut utiliser différents modèles, ce qui exige que la plateforme puisse ajuster dynamiquement les instances de modèle en fonction de plusieurs indicateurs tels que la file d’attente des demandes et les performances.
Exemple d’entreprise d’État centrale : passer de “l’location d’équipements” à “l’utilisation des services de modèles”
Nous avons servi une entreprise d’État groupée, qui comptait initialement environ 50 machines, fournissant des services aux filiales subordonnées. La manière de service initiale était très directe : chaque filiale demandait des machines et déployait les modèles dont elle avait besoin. En d’autres termes, il s’agissait de « louer des machines ».
Ainsi, quatre ou cinquante exemples de modèles ont été créés, mais le taux d’utilisation de la puissance de calcul globale est très faible. Certaines unités, après occuper les machines, ne déploient qu’un seul modèle ; certaines sont utilisées pendant la journée et non pas la nuit ; d’autres ne sont utilisées que quelques jours par semaine. Les machines sont occupées, mais aucune charge utile n’est générée de manière continue.
Nous collaborons en profondeur avec les clients pour réorganiser la situation actuelle : uniformisation des modèles et uniformisation de la puissance de calcul. Les modèles répétés sont regroupés en environ dix ; le système de distribution des ressources par machine est remplacé par des services de modèle Serverless, tous appelant l’API de manière uniforme, sans se soucier de l’endroit exact où les modèles sont déployés ou du machine qui les utilise.
Ainsi, avec environ 50 machines, il est possible de faire plus de choses. Par exemple, après utiliser une partie des machines pour héberger certains petits modèles existants, on peut libérer plusieurs machines pour déployer de nouveaux modèles à grandes paramètres, tels que GLM-5.2, DeepSeek-V4-Flash-0731, etc. Auparavant, ces modèles ne pouvaient pas fonctionner au sein du groupe. Mais en réalité, les nouveaux modèles à grandes paramètres sont très importants pour l’exploration des activités, car le seuil de la intelligence des modèles détermine également le seuil d’innovation des applications. Grâce à la convergence des modèles et à une gestion intensive de la puissance de calcul, nous avons déployé ces modèles, et en combinant l’optimisation des performances, plus de scénarios sont passés de “indisponibles” à “disponibles”, et de “pour être explorés” à “pour être massifs”.
En fait, la principale inquiétude de l’équipe de développement est la suivante : créer une exploration et un agent ne pose pas de problème, mais est-il possible de l’implémenter à grande échelle ? Faut-il être capable d’accepter davantage de requêtes ? Tout le monde se pose des questions. Après l’implémentation du nouveau modèle, lors des tests entre un seul et plusieurs concurrences, la vitesse de sortie globale reste généralement supérieure à 30 tokens/s. Par exemple, en programmation, dépasser 30TPS est une exigence essentielle pour obtenir une bonne expérience d’utilisation. Dans les tests comparatifs avec le même modèle, nous avons obtenu une amélioration de performance de 40 % à 100 %. Bien sûr, cela dépend des différentes longueurs d’entrée et de sortie, et les bénéfices réels ne sont pas identiques.
Dans l’ensemble, premièrement, la capacité de traitement du modèle a augmenté, deuxièmement, l’utilisation de la puissance de calcul a amélioré. En combinant ces deux facteurs, cela se reflète finalement dans le coût par million de Tokens, un indicateur que de nombreuses entreprises utilisent pour mesurer l’efficacité des services de raisonnement. Dans cet cas, le coût par million de Tokens d’un modèle Qwen initialement à plus de cent yuans a diminué à moins de dix yuans après la mise à jour. La baisse de coût est notable, mais le plus important est qu’elle a permis l’exploitation de davantage de scénarios de business qui étaient auparavant difficiles à mettre en œuvre.
Améliorer davantage le ROI, optimiser ensemble l'application et les infrastructures
Avec l’implémentation à grande échelle de l’Agent, nous avons également observé un problème : il existe une certaine déconnexion entre le niveau d’application et le niveau d’infrastructure. Auparavant, lors de la création d’applications, même si les développeurs étaient principalement responsables du frontend, ils avaient généralement une certaine compréhension des index de base de données et de l’optimisation SQL. Aujourd’hui, la stratification entre les applications de grandes modèles et l’infrastructure est plus évidente ; le côté application ne comprend pas nécessairement pleinement les mécanismes de raisonnement et de stockage en arrière-plan, ce qui affecte directement l’efficacité.
Par exemple, en matière de Coding, nous explorons ensemble avec les clients des optimisations dans ce domaine. L’ingénierie logicielle des entreprises publiques et étatiques ne consiste pas à écrire un application aujourd’hui et une autre démonstration demain, mais plutôt à des itérations continues sur plusieurs années. Le dépôt de code sera constamment mis à jour, les contributions de code et les builds quotidiens font partie d’un projet à long terme. La manière dont ces codes sont intégrés dans le contexte du modèle est très importante.
Si la construction du contexte n’est pas bien réalisée, chaque requête ne peut pas atteindre la cache, et l’entrée de dizaines de milliers de Tokens consomme une grande quantité de puissance de calcul. Mais si elle est bien construite, environ 90 % du contenu pourrait atteindre la cache, ce qui fait apparaître un écart d’efficacité. Par exemple, lorsque la cache n’est pas atteinte, le système peut supporter 100 concurrences simultanées ; après l’augmentation de la taux de récupération de la cache, il peut supporter 200 concurrences simultanées. Cette amélioration ne nécessite pas d’ajout de matériel, mais réduit les calculs redondants. Par conséquent, la construction du contexte lui-même doit être optimisée pour l’inférence.
D’un autre côté, il est possible de combiner DevOps pour l’optimisation. L’utilisation de la puissance de calcul présente des pics et des creux : pendant la journée, tout le monde utilise la puissance de calcul, tandis que les entrées dans les scénarios de codage sont longues. Si tous les code sont traités uniquement lors des requêtes en journée, puis stockés dans une mémoire cache, cela consommerait une grande partie de la puissance de calcul pendant les périodes de pic. Alors, est-il possible, lors du processus de construction quotidien le soir, d’utiliser des méthodes ingénierie pour pré-traitementer les modèles sur le dépôt de code et d’enregistrer les résultats en préférence KV Cache ? De cette manière, il n’est pas nécessaire de calculer à nouveau pendant la journée. Toutes ces approches ont une chance de améliorer davantage l’utilisation de la puissance de calcul. Mais cette capacité dépend également de nos explorations conjointes avec les parties concernées.
L’objectif du flux à base de silicium est d’explorer, en collaboration avec les entreprises publiques chinoises, davantage de scénarios d’implémentation de l’IA, afin de libérer une véritable capacité de calcul et une production élevée.
Lei Feng Network (compte public: Lei Feng Network) Lei Feng Network