Latence du premier Token réduite de 32.4 % ! Le grand coup de 是石科技 en ordonnancement de cluster, l'efficacité de l'inférence nationale encore améliorée

Par Yunzhong, depuis凹非寺 — 量子位 | Compte public QbitAI

Dans un cluster de GPU, la mise en file d'attente des requêtes et l'inutilisation des ressources peuvent se produire simultanément.

À l'occasion du congrès national 2026 de haute performance de la CCF, 是石科技 a lancé un nouveau produit :le cadre d'ordonnancement distribué TokenFleet, qui met l'accent sur le routage des requêtes, la coordination des capacités entre salles de données et la gestion des charges mixtes, en tentant d'augmenter le rendement effectif de la puissance de calcul existante.

Si l'on considère le service d'inférence comme une « usine nationale d'optimisation de Tokens », les GPU sont les équipements de production, les instances d'inférence sont les postes de travail, et les requêtes métier sont autant de commandes. TokenFleet a pour mission de faire correspondre les commandes à la capacité de production.

Avec le même lot d'équipements, des tâches différentes et des modes d'affectation différents produisent des temps d'attente et des rendements conformes différents. Un service à grande échelle exige de considérer conjointement ces arrangements de production.

TokenFleet se concentre sur le rendement effectif du cluster

Une fois les modèles déployés, le cluster doit en outre faire face simultanément à de multiples activités métier.

Plusieurs modèles partagent la puissance de calcul, et chaque locataire a ses propres exigences de niveau de service. Les dialogues courts exigent une réponse immédiate, le traitement de longs documents requiert davantage de calcul et de mémoire vidéo, et les tâches batch hors ligne ont des délais d'achèvement. Lorsque les services sont répartis sur plusieurs salles de données, il faut aussi considérer la coordination des capacités de chacune.

Une simple répartition peut créer de longues files d'attente sur certaines instances, tandis que la capacité d'autres emplacements n'est pas exploitée à temps. L'entrelacement des requêtes longues et des tâches batch ralentit les interactions en temps réel ; les dépassements de délai, les annulations et les calculs répétés consomment des ressources sans produire de livrables conformes.

TokenFleet, sous condition d'égalité entre qualité du modèle, exigences de service et budget de calcul, grâce àl'augmentation du rendement effectif en Tokens, réduit le coût unitaire du rendement effectif。

TokenPilot sélectionne les instances au sein d'un même pool de modèles, FleetMind gère la coordination des capacités entre salles de données, et SLOMax prend en charge l'admission des charges mixtes, la gouvernance des files d'attente et l'allocation des capacités : les trois technologies principales ont chacune leur rôle.

À qui attribuer la requête, quand la tâche entre en file d'attente, comment coordonner les capacités des salles de données — tout cela revient finalement au même indicateur : le rendement effectif en Tokens, achevés avec succès et conformes aux exigences de service.

TokenPilot calcule ensemble le bénéfice du cache et le coût de la file d'attente

Commençons par le choix de destination des requêtes. À quelle instance une requête doit-elle être envoyée ?

Une question-réponse brève et un long document, même s'ils comptent chacun pour une requête, peuvent différer fortement en calcul et mémoire vidéo consommés. Une répartition fondée uniquement sur le nombre de requêtes peine à équilibrer la charge réelle des instances.

Le cache ajoute un arbitrage à cette question. Les requêtes partageant le même long préfixe, si elles sont envoyées à une instance conservant le KV cache correspondant, peuvent réutiliser les résultats de calcul antérieurs, réduisant le Prefill, c'est-à-dire les calculs répétés lors du traitement du contenu d'entrée.

Mais les instances à fort taux de hit en cache peuvent aussi présenter de longues files d'attente. Quand toutes les requêtes convergent vers le même endroit, le temps de calcul économisé peut être perdu en attente.

Lors du choix de la destination, TokenPilotestime simultanément le bénéfice de réutilisation du cache et le coût de la file d'attente. Il estime la charge de travail en combinant taille d'entrée, budget de sortie et préfixes réutilisables, puis filtre et note les instances candidates en tenant compte des files d'attente, des Tokens en cours, de la pression sur le KV cache et de la latence prédite. Le budget de sortie est une contrainte et ne représente pas la longueur réelle de la sortie.

L'ordonnanceur compare ainsi le coût de traitement estimé des différentes instances pour déterminer si le calcul économisé par la réutilisation du cache compense l'attente supplémentaire.

Selon les données d'optimisation GLM5.3 fournies par 是石科技, dans les conditions de cluster de cartes graphiques et de charge testées, après adoption du routage à latence prédite,la latence du premier Token P95 a diminué de 32.4 % et la latence du premier Token P50 de 71.3 %。

△ Tableau 1 : résultats d'optimisation de la latence du premier Token par TokenPilot. Source des données : supports de présentation du congrès de 是石科技. Le taux d'amélioration est calculé selon (valeur de référence − valeur optimisée) ÷ valeur de référence ; une baisse de latence n'équivaut pas directement à une baisse de coût.

P50 reflète le niveau médian, P95 reflète le temps d'attente des requêtes en queue de distribution. Cet ensemble de données présente l'amélioration de la réponse dans les conditions mesurées ; le rapport coût-bénéfice doit encore être évalué en tenant compte du débit et de l'occupation des ressources.

FleetMind doit aussi calculer la capacité de service entre centres de données

Lorsqu'on élargit la perspective d'un seul pool de modèles à plusieurs centres de données, l'ordonnancement ajoute une couche de jugement de capacité.

Avoir des GPU inoccupés ne signifie pas nécessairement pouvoir accepter une tâche immédiatement. Que le modèle cible soit déployé, que les versions correspondent, que le point de terminaison de service soit prêt, ainsi que le temps nécessaire au transfert réseau, tout cela influence l'efficacité de la répartition de charge.

FleetMind s'intéresse à lacapacité de service réellement disponible des modèles. Dans la conception de TokenFleet, il agrège la disponibilité des modèles, la capacité en temps réel et l'état du réseau de chaque centre de données, choisit d'abord le centre de données d'exécution, puis le moteur de décision local de ce centre choisit l'instance d'inférence concrète.

Lorsqu'un centre de données en forte demande commence à faire la file, le système évalue si d'autres centres de données disposent de points de terminaison prêts pour la même version du modèle et s'ils disposent encore de capacité de service résiduelle, avant de juger s'ils peuvent accepter de nouvelles requêtes autorisant une exécution inter-régions.

La possibilité de décharger le trafic dépend d'abord du respect des contraintes de permissions et de localisation des données. L'intérêt de le faire exige en outre une comparaison globale de la latence de retour à la source, de l'attente en file, du calcul, des coûts de cache et de transmission.

La coordination des capacités opère aussi à différentes échelles de temps : à court terme, on ajuste la destination des nouvelles requêtes ; à long terme, les répliques de modèles et les emplacements de préchauffage, en combinant réservation de capacité, perception des plafonds de charge et repli automatique, afin de réduire les mauvais appariements de capacité.

△Figure 3 Cadre d'exécution inter-datacenters de FleetMind. Note : le site A est le point d'entrée métier et n'est pas compté dans le pool de capacité GPU ; le site B est le cluster existant, les sites C et D sont les datacenters d'extension.

TokenPilot et SLOMax ciblent les clusters existants, tandis que FleetMind vise l'extension vers de futurs datacenters de calcul supplémentaires. L'objectif de la coordination inter-datacenters est de faire porter la demande de pointe par des capacités dispersées conformes aux contraintes métier, afin de réduire les mauvais appariements de capacité et les réservations redondantes.

SLOMax organise la production selon les exigences de service

Les requêtes entrent dans un même cluster, mais leurs exigences de livraison diffèrent les unes des autres.

Les dialogues en temps réel tiennent au temps de réponse du premier Token et à la vitesse de génération continue ; les tâches à long contexte dépendent davantage de la capacité de traitement des entrées et de la capacité KV ; les tâches hors ligne par lots s'intéressent aux délais d'achèvement et au débit. Les placer dans une même file d'attente provoque facilement des conflits de ressources.

Les Prefill longs, la pression sur la capacité KV et les charges par lots peuvent tous comprimer les requêtes interactives. Les dépassements de délai, les annulations et les exécutions répétées font aussi qu'une partie du calcul ne se transforme pas en livraison effective.

SLOMax identifie la charge de travail en combinant la longueur d'entrée, le budget de sortie, le type de tâche et les objectifs de service des locataires, puis applique une admission par niveaux, un classement par pools et une coordination de la capacité. Il doit garantir la capacité interactive et contrôler la concurrence des requêtes longues et courtes ainsi que leurs interférences mutuelles.

△Figure 4 Cadre de files classées et de rétroaction de capacité de SLOMax. Note : la rétroaction des résultats sert à ajuster la capacité et l'admission ; le cadre ne présuppose aucune capacité de préemption des tâches en cours d'exécution.

Pour mesurer l'efficacité de cette ordonnance, TokenFleet prend comme objectif d'optimisation la production conforme aux critères.

Le Goodput, c'est-à-dire le débit de sortie conforme aux critères, calcule : le volume total de Tokens de sortie produits pendant toute la durée de test par les requêtes achevées avec succès et satisfaisant aux exigences de service convenues, divisé par la durée du test. Chaque catégorie de tâches nécessite de définir séparément ses seuils de conformité et de rapporter les résultats correspondants.

Le système renvoie à la stratégie d'ordonnancement les informations sur le débit conforme, les échecs, les annulations et les exécutions répétées, afin d'ajuster en continu l'admission et les proportions de capacité. Le niveau d'occupation des GPU et le débit total doivent être examinés conjointement avec la livraison finale conforme.

Dans l'exemple d'estimation de gains GLM5.3 fourni par Metastone, après adoption de l'ordonnancement coordonné avec contrôle de flux, le débit total de sortie a augmenté d'environ 1,5 %,et le débit de sortie conforme a augmenté d'environ 29,4 %, le taux de conformité passant d'environ 67 % à environ 86 %.

△Tableau 2 Exemple d'estimation des gains de débit de Tokens effectifs de SLOMax. Source des données : supports de présentation de la conférence de Metastone. Ce tableau est un exemple d'estimation de gains ; le taux de conformité reprend les valeurs arrondies du texte original, avec une variation d'environ 19 points de pourcentage.

Ces chiffres relèvent d'une estimation de gains, illustrant la structure de production que l'ordonnancement cherche à améliorer. Les gains réels doivent encore être validés en fonction des charges concrètes et des seuils de service.

À volume de production total égal, si l'on parvient à réduire les dépassements de délai, les annulations et les calculs répétés, il est possible de livrer davantage de Tokens conformes. SLOMax intègre ces résultats dans sa rétroaction pour ajuster l'allocation ultérieure des ressources.

L'efficacité des usines d'optimisation de Tokens nationales dépend aussi de l'ordonnancement

TokenFleet fait progresser l'optimisation des services d'inférence au niveau du cluster. La manière dont les performances des instances sont réparties entre les requêtes, et la façon dont les capacités de plusieurs datacenters participent au service, exigent que l'ordonnancement relie les ressources aux exigences métier.

Metastone (是石科技) est unopérateur tiers indépendant de capacités de calcul full-stack, non lié à un fabricant quelconque de grands modèles, qui offre à ses clients un servicede livraison de capacités de calcul full-stack couvrant le matériel, le réseau, l'ordonnancement, l'optimisation et l'exploitation。

. Forte d'une riche expérience issue de centres de calcul de niveau national, son SLA d'exploitation de clusters de calcul atteint plus de 99,95 %. À ce jour, Metastone a pris en charge plus de 20000P+ de ressources de calcul et exploite plus de 10 centres de supercalcul intelligent, dont 2 centres nationaux de supercalcul ; les membres de son équipe ont remporté 3 prix Gordon Bell et accumulé une expérience de services techniques full-stack pour des clusters de très grande échelle.

Autour de l'usine nationale d'optimisation de Tokens, Metastone affine en continu ses capacités logicielles par développement et usage internes, dans l'espoir de rendre les services d'inférence généraux et à haute fréquence plus économiques, et de faire valoir davantage les capacités de calcul nationales.

Le moteur d'inférence haute performance Meta-Infer, publié précédemment, visait à améliorer l'efficacité d'exécution de chaque instance d'inférence. TokenFleet, présenté cette fois, met l'accent surl'ordonnancement des clusters, en organisant des services à grande échelle par la répartition des requêtes, la coordination des capacités et la gouvernance des charges mixtes.

Pour que davantage d'activités puissent se permettre et bien utiliser les Tokens, il faut à la fois que le matériel fournisse la puissance de calcul et que le logiciel organise la production.

TokenFleet axe son optimisation ultérieure sur la manière dont chaque requête est attribuée et dont chaque unité de capacité est utilisée.

*Cet article est republié par 量子位 (QbitAI) avec autorisation ; les opinions exprimées appartiennent exclusivement à l'auteur original.