Trois moteurs, trois défauts opposés
Prenez le même modèle, le même GPU, la même charge. Servez-le successivement avec vLLM, avec SGLang, puis avec TensorRT-LLM, sans toucher à un seul réglage. Vous obtiendrez trois comportements différents, et pas parce que le code des noyaux diffère. Parce que les trois équipes ont pris, sur la même question, des décisions contraires.
vLLM active le découpage du prefill Chunked prefill. Découpe le traitement d'un prompt entrant en morceaux insérés dans les itérations successives, au lieu de l'avaler d'un bloc. Évite qu'un long prompt gèle toutes les conversations en cours, au prix d'un traitement légèrement moins efficace que le prefill contigu. À ne pas confondre avec le prefill-first, qui priorise les prefills entiers. par défaut et lui donne un budget de 2 048 tokens par itération. Sa documentation ne cache pas ce que ça vise : cette valeur « est optimisée pour l’ ITL Inter-Token Latency. Intervalle entre deux tokens consécutifs d'une même réponse, ce que l'utilisateur perçoit comme la fluidité du flux. À distinguer du TPOT, qui est le temps de décodage total divisé par le nombre de tokens produits, donc une moyenne. Piège de mesure : certains harnais incluent le premier token dans le calcul, d'autres l'excluent, et leurs chiffres ne sont pas comparables. , et peut donner un débit inférieur à celui de l’ordonnanceur par défaut ». Autrement dit, elle protège le temps qui sépare deux tokens successifs, quitte à servir moins de monde.
SGLang active le même découpage, mais avec des morceaux de 8 192 tokens, soit quatre fois plus gros. Le mainteneur du projet l’a écrit noir sur blanc dans une discussion GitHub d’août 2024 : « nous avons choisi une taille de morceau de 8 192 pour favoriser le débit ». Décision inverse, assumée, argumentée.
TensorRT-LLM, lui, ne l’active pas du tout. Le paramètre existe, sa valeur par défaut est False, et il n’est même pas exposé en option de la commande de service : il faut éditer un fichier Python pour l’atteindre. Sa politique de capacité par défaut, GUARANTEED_NO_EVICT, garantit qu’une requête admise ne sera jamais mise en pause, quitte à former des lots plus petits que ce que la mémoire permettrait. Ni le débit, ni le temps entre tokens : ce qu’elle protège, c’est la prévisibilité.
Trois équipes compétentes, un même problème, trois défauts qui pointent dans des directions différentes. L’explication paresseuse serait que deux d’entre elles se trompent. La vraie explication est plus intéressante : elles n’arbitrent pas la même chose, et le compromis qu’elles règlent n’est pas celui qu’on croit.
Ce n’est pas un compromis entre débit et latence
L’intuition commune tient en une phrase : plus vous groupez de requêtes, plus vous servez de monde, plus chacun attend. Le débit et la latence tireraient dans des directions opposées, et régler un serveur d’inférence consisterait à placer un curseur entre les deux.
Cette description est fausse comme loi générale, et la réfutation vient de la technique fondatrice du domaine. Le batching continu Ordonnancement à l'itération : ajouter et retirer des requêtes du batch à chaque pas de génération, au lieu d'attendre qu'un batch entier se termine. Formalisé par Orca (OSDI 2022), popularisé par vLLM. Multiplie par 2 à 4 le débit d'un serveur d'inférence sous forte concurrence. Approfondir dans le glossaire , qui consiste à faire entrer et sortir les requêtes d’un lot à chaque itération au lieu d’attendre que le lot entier se termine, a été présenté en juin 2023 par un billet d’Anyscale dont le titre dit tout : vingt-trois fois plus de débit tout en réduisant la latence médiane. Les mesures publiées montrent une amélioration à tous les percentiles, aussi bien à une requête par seconde qu’à quatre. Pas un curseur déplacé : les deux métriques progressent ensemble.
Ce n’est pas un cas isolé. PagedAttention Algorithme introduit par vLLM qui gère le KV cache comme la mémoire virtuelle d'un système d'exploitation : par pages, sans exiger un bloc contigu par requête. Élimine la fragmentation interne et externe, permet de servir 2 à 4× plus de requêtes concurrentes sur la même VRAM. Approfondir dans le glossaire , en gérant le KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire par pages au lieu d’exiger un bloc contigu par requête, ramène le gaspillage mémoire sous les 4 %, ce qui autorise un lot plus grand sans rien coûter à la latence à charge constante. RadixAttention, chez SGLang, réutilise les préfixes déjà calculés, et ses auteurs le formulent explicitement : la technique « bénéficie à la fois au débit et à la latence, et réduit le calcul de prefill, donc diminue la latence du premier token ». FlashAttention Implémentation tile-by-tile de l'attention qui évite de matérialiser la matrice d'attention complète en HBM. Réduit drastiquement la consommation mémoire et accélère le calcul, particulièrement sur longs contextes. Trois versions (v1/v2/v3), chacune optimisée pour une génération de GPU. Approfondir dans le glossaire , les noyaux fusionnés et les graphes CUDA réduisent le coût fixe de chaque itération, ce qui profite à tout le monde.
Ces optimisations ont un point commun : elles déplacent la frontière de Pareto. Elles ne font pas glisser un point le long d’une courbe, elles déforment la courbe elle-même vers l’extérieur. Tant qu’il reste une optimisation de ce type à activer, parler d’arbitrage n’a pas de sens : vous avez simplement du travail en retard.
Le compromis existe pourtant, et il apparaît une fois ce travail fait. À matériel, modèle et pile logicielle figés, avec toutes ces techniques activées, il subsiste un arbitrage le long de la frontière. Le scheduler ne choisit pas la frontière. Il choisit où vous vous placez dessus.
Reste à savoir entre quoi et quoi. Et ce n’est pas entre le débit et la latence.
Ce qu’un token de prefill fait dans un lot de décodage
Descendons dans la boucle, parce que tout le reste en découle.
Un moteur d’inférence moderne ne raisonne pas en requêtes mais en budget de tokens par itération. À chaque passe avant, il dispose d’une enveloppe, disons 2 048 tokens, et il la remplit avec ce qu’il a sous la main. Une requête en cours de decode Phase de génération autorégressive d'un LLM : un token est produit à la fois en relisant les poids et l'état de contexte utile. À faible batch, ce trafic peut limiter le decode par la bande passante mémoire. Sa part dans le coût total dépend toutefois des longueurs d'entrée et de sortie, du batching et de la réutilisation du cache. Approfondir dans le glossaire y consomme exactement un token : celui qu’elle s’apprête à produire. Une requête qui vient d’arriver, elle, réclame la totalité de son prompt d’un seul coup, ce qui peut faire plusieurs milliers de tokens. Le découpage du prefill Phase initiale d'une inférence LLM : les tokens du prompt sont traités en parallèle pour construire l'état du contexte. Cette réutilisation augmente l'intensité arithmétique et peut rendre la phase limitée par le calcul ; le régime exact dépend du modèle, du batch, du contexte et du backend. Approfondir dans le glossaire sert précisément à ça : au lieu de faire attendre tout le monde pendant qu’on avale un prompt de 8 000 tokens, on le tranche et on glisse les morceaux dans les itérations successives.
Voici ce qui se passe alors, et c’est le cœur du sujet. Chaque token de prefill que vous insérez occupe une place dans l’enveloppe et rallonge le temps de l’itération. Or toutes les requêtes en cours de décodage attendent la fin de cette itération pour recevoir leur token suivant. Une seule requête entrante fait donc patienter l’ensemble des conversations déjà en cours. Le temps entre deux tokens se dégrade, pour tout le monde, à cause d’un prompt qui n’appartient à personne d’autre qu’au dernier arrivé.
Refusez d’insérer ces tokens, et vous obtenez le symptôme inverse. Les conversations en cours filent, leur cadence est régulière, mais le nouveau venu attend son tour dans la file. Son temps jusqu’au premier token s’allonge.
Voilà l’arbitrage réel. D’un côté le temps d’attente initial de celui qui arrive, de l’autre la régularité du flux de ceux qui sont déjà servis. Deux latences, pas un débit contre une latence. Et elles s’opposent parce qu’elles se disputent la même enveloppe.
La documentation de vLLM donne le sens de l’effet sans détour : une valeur plus petite du budget « obtient un meilleur ITL », une valeur plus grande « obtient un meilleur temps jusqu’au premier token ». Le même paragraphe recommande de dépasser 8 192 pour viser le débit. Trois objectifs, un seul paramètre, et le choix vous appartient.
La preuve la plus nette vient du papier qui a introduit la technique. Sarathi-Serve, présenté à OSDI en 2024, décompose l’effet de ses deux ingrédients et le résultat est contre-intuitif : le découpage du prefill pris isolément augmente le temps jusqu’au premier token, parce que traiter un prompt en morceaux est légèrement moins efficace que de l’avaler d’un bloc. Le batching hybride pris isolément, lui, augmente le temps entre tokens. Il faut combiner les deux pour obtenir un bon compromis. Chacun des deux leviers, seul, dégrade une des deux latences.
Sarathi observe un phénomène de même famille sur une tout autre configuration, sans qu’il s’agisse de la même mesure : sur un Llama-13B servi par un A6000, augmenter le nombre de tokens de prefill cesse d’apporter du débit au-delà de 512 tokens environ. Deux matériels, deux grandeurs, une corroboration d’ordre de grandeur et non une confirmation : il existe un point au-delà duquel remplir davantage ne rapporte plus.
Retenez donc la formulation complète, parce que la version courte est fausse : au-dessus du lot critique, chaque token de prefill inséré dans un lot en décodage améliore votre débit et dégrade le temps entre tokens de tous les autres utilisateurs du lot. En dessous, il ne fait presque rien.
Le prix affiché
Reste à savoir ce que coûte le déplacement le long de cette frontière. Les chiffres publics sur le sujet sont abondants et presque tous inutilisables, parce qu’une latence sans son modèle, son matériel, ses longueurs d’entrée et de sortie et son niveau de concurrence ne veut rien dire. Une table échappe à ce défaut.
| Concurrence | Temps jusqu'au premier token | Latence moyenne | Débit |
|---|---|---|---|
| 1 | 48 ms | 136 ms | 67 tok/s |
| 25 | 657 ms | 958 ms | 217 tok/s |
| 100 | 2 051 ms | 3 562 ms | 250 tok/s |
| 500 | 5 653 ms | 6 791 ms | 614 tok/s |
Regardez les deux facteurs séparément, parce que c’est là que l’article se joue. Entre le premier point et le dernier, le débit a été multiplié par 9. Le temps jusqu’au premier token, lui, a été multiplié par 117. Vous n’achetez pas votre débit au prix d’une dégradation proportionnelle de la latence : la dégradation court bien plus vite que le gain.
Deux réserves sur cette table. NVIDIA pose la première : elle est générée automatiquement, et les temps d’attente très élevés en haut de la courbe contiennent aussi de la file côté client, pas seulement du calcul serveur. La seconde est plus structurante pour notre sujet. Avec dix tokens de sortie seulement, cette table ne dit à peu près rien du temps entre tokens. Elle éclaire parfaitement un côté de l’arbitrage, celui de l’attente initiale, et laisse l’autre dans l’ombre. Nous n’avons pas trouvé de table publique qui documente les deux à la fois avec une configuration complète.
Ce que le découpage du prefill apporte face à ça se mesure en capacité de service à SLO Service Level Objective. Cible de qualité de service qu'un système se donne, par exemple un temps jusqu'au premier token sous 500 ms au 99e percentile. À distinguer du SLA, qui est l'engagement contractuel opposable : en inférence LLM, les SLO abondent et les SLA de latence sont quasi inexistants. tenu. Sarathi-Serve annonce 2,6 fois plus de capacité pour un Mistral-7B sur un A100, 3,7 fois pour un Yi-34B sur deux A100, et jusqu’à 5,6 fois pour un Falcon-180B sur huit A100 avec parallélisme de pipeline. Ces chiffres ne sont pas transportables ailleurs, mais leur ordre de grandeur dit l’essentiel : bien régler ce curseur ne rapporte pas quelques pourcents.
Ce que les trois équipes ont réellement décidé
Reprenons maintenant les trois défauts de l’ouverture, avec le mécanisme en tête.
| vLLM | SGLang | TensorRT-LLM | |
|---|---|---|---|
| Ordre de lot | Décodage d'abord | Prefill d'abord | Décodage d'abord |
| Découpage du prefill | Activé, budget 2 048 | Activé, morceaux de 8 192 | Désactivé |
| Saturation mémoire | Préemption par recalcul | Retrait puis recalcul | Aucune préemption |
| Ce qui est protégé | Cadence inter-token | Débit | Prévisibilité |
| Ordonnancement par priorité | Disponible, pas par défaut | Disponible, pas par défaut | Disponible, pas par défaut |
vLLM traite prompt et tokens générés de façon uniforme dans un ordonnanceur unique, avec un budget fixe qu’il répartit dynamiquement entre les requêtes. Il sert d’abord les requêtes déjà en cours, puis admet les nouvelles si le budget le permet. Son budget de 2 048 tokens laisse donc peu de place au prefill à chaque itération, ce qui protège la cadence des conversations en cours. Quand la mémoire sature, il préempte par recalcul plutôt que par transfert vers la mémoire hôte, au motif que recalculer coûte moins cher que déplacer dans cette architecture.
SGLang fait l’inverse à deux endroits. Il forme un lot de prefill dès qu’il le peut, avant de retomber sur du décodage, et ses morceaux de 8 192 tokens remplissent largement l’enveloppe. Il est aussi le seul des trois à réordonner sa file selon le cache : sa politique par défaut sélectionne le plus long préfixe déjà calculé, ce qui augmente le taux de réutilisation au prix d’un surcoût d’ordonnancement. Chez vLLM, un préfixe en cache réduit le coût d’une requête une fois admise, mais ne change pas son rang dans la file.
TensorRT-LLM, enfin, préfère ne rien promettre qu’il ne puisse tenir. En réservant à l’admission la mémoire nécessaire à la séquence complète, il garantit qu’aucune requête acceptée ne sera interrompue. Sa documentation présente l’alternative sans détour : « si l’objectif est de maximiser le débit, MAX_UTILIZATION devrait être essayé, en gardant à l’esprit que cela peut affecter la latence si des requêtes doivent être mises en pause ». Le débit maximal existe, il est à un flag de distance, et ce n’est pas le défaut.
Une précision de vocabulaire s’impose ici, parce qu’elle sépare ceux qui ont lu la documentation de ceux qui ont lu des billets de blog. Ce que vLLM appelle batching continu, l’écosystème NVIDIA l’appelle in-flight batching. Le terme « dynamic batching », chez Triton, désigne autre chose : un regroupement de requêtes en attente au niveau de la requête, exécuté ensuite jusqu’au bout, c’est-à-dire du batching statique à formation dynamique. Employer l’un pour l’autre se remarque tout de suite.
Un dernier point commun aux trois, et il compte : l’ordonnancement par priorité existe partout, et n’est le défaut nulle part. Les trois moteurs partent en premier arrivé premier servi, avec une priorité au décodage pour deux d’entre eux. Si vous avez des locataires ou des classes de trafic à traiter différemment, c’est un réglage explicite à activer, pas un comportement acquis.
Les défauts ne connaissent pas votre contrat de service
Il serait facile, arrivé ici, de conclure que ces défauts sont mal réglés. Ce serait injuste et faux. Chacun est un compromis généraliste, documenté, choisi par des gens qui savaient ce qu’ils sacrifiaient. Ce qu’aucun d’eux ne peut savoir, c’est ce que vous servez.
Reste à savoir vers quelle valeur pousser, et nous ne donnerons pas de fourchette. C’est délibéré. Celles qui circulent dans les guides d’éditeurs ne s’accordent pas entre elles sur le sens de l’effet : certaines présentent les gros budgets comme protecteurs de l’attente initiale, d’autres comme protecteurs de la cadence, et les deux lectures se retrouvent parfois dans des documents voisins. Publier une de ces tranches reviendrait à vous envoyer régler le mauvais bout.
Ce qui est solide, c’est la direction, et elle est documentée par les moteurs eux-mêmes. Un budget plus petit protège la cadence de ceux qui sont déjà servis et fait attendre celui qui arrive. Un budget plus grand fait l’inverse. Partez du défaut de votre moteur, mesurez vos deux latences séparément sous votre charge réelle, et déplacez le curseur du côté de celle qui viole votre objectif. Le désaccord entre les guides est d’ailleurs le meilleur argument possible en faveur de votre propre mesure.
Trois couches, pas une
Un article qui s’arrêterait là serait daté, parce qu’une partie de l’arbitrage a quitté le moteur.
La disaggregation prefill/decode, que nous avons suivie quand elle est sortie du papier, ne règle pas le compromis décrit plus haut : elle le supprime. En plaçant les deux phases sur des pools de GPU distincts, plus aucun token de prefill ne vient s’intercaler dans un lot de décodage, et l’interférence sur laquelle repose tout le mécanisme disparaît. DistServe annonce 7,4 fois plus de requêtes servies, ou un SLO 12,6 fois plus serré, en tenant la latence pour plus de 90 % des requêtes. Splitwise, chez Microsoft, mesure 1,4 fois plus de débit pour 20 % de coût en moins, ou 2,35 fois plus de débit à budget de puissance et de coût constant.
Une troisième couche s’ajoute au-dessus, celle du routage entre répliques. Le routeur de Dynamo, dont nous avons comparé le périmètre à celui d’Infera et de llm-d, choisit sa cible en combinant le recouvrement de préfixe déjà en cache et la charge de chaque instance, avec un poids réglable qui arbitre, lui aussi, entre le temps jusqu’au premier token et le temps entre les tokens. Le même compromis, remonté d’un étage.
Faut-il en conclure que le scheduler du moteur est devenu marginal ? La documentation de Dynamo répond elle-même, et sa franchise mérite d’être citée : « pour de nombreuses charges de chatbot standard ou de RAG modéré, le service agrégé reste le défaut le plus simple et souvent le meilleur ». La disaggregation se paie en transfert de cache entre étages, et une mesure tierce estime que ce transfert peut éroder 30 à 50 % du gain théorique quand le tissu réseau n’est pas à la hauteur.
Voilà donc où placer le curseur de cet article lui-même. Sur une flotte de plusieurs dizaines de nœuds à contexte long, l’arbitrage vit dans le routeur et dans la séparation des étages. Sur un déploiement co-localisé, c’est-à-dire la majorité de ce qui tourne aujourd’hui, il vit dans le budget de tokens de votre moteur. Et il ne faut pas confondre cet ordonnanceur-là avec celui du système d’exploitation : l’un décide quel token calculer à la prochaine passe, l’autre décide quel thread reçoit un cœur. Les deux comptent, ils ne règlent pas le même problème.
Personne ne vous garantit votre latence
Terminons par ce qui devrait rendre ce paramètre important à vos yeux.
Nous avons regardé ce que les fournisseurs d’inférence promettent contractuellement. Azure garantit 99,9 % de disponibilité mensuelle, et exclut explicitement la latence de son périmètre. AWS Bedrock ne s’engage que sur la disponibilité. Baseten écrit noir sur blanc 99,9 % de disponibilité système, la latence étant absente du contrat et le débit réduit explicitement exclu des motifs de crédit. Vertex AI annonce 99,5 % pour l’inférence Gemini en ligne. Together affiche 99 % de disponibilité. Groq, dont tout le positionnement repose sur la vitesse, ne promet dans ses termes publics que des « efforts commercialement raisonnables ». Anthropic ne publie pas de contrat de service.
Une seule exception publique existe, et elle est instructive. Le Scale Tier d’OpenAI affiche un engagement chiffré sur le débit : 99 % des requêtes au-dessus de 25 tokens par seconde, mesuré comme la latence moyenne par requête sur une base minute, agrégée sur le mois. Le tier standard, lui, n’a aucun engagement de latence.
Azure et AWS vendent bien de la latence prévisible, à travers des unités de débit provisionné facturées à l’heure. Mais lisez les documents : cette capacité réservée vit en dehors du contrat de service. Vous achetez une probabilité, pas une clause opposable.
Ce que ça signifie pour vous est simple. Votre engagement de latence, personne ne le tient à votre place. Il est tenu par le budget de tokens de votre moteur, par la façon dont votre routeur répartit les requêtes, et par votre décision de séparer ou non les deux phases. Ce sont trois réglages que personne n’a pris pour vous, et le premier des trois tient dans un entier.
La question qui vient ensuite est celle de la mesure. Aucun des chiffres cités ici n’est transportable sur votre charge, et deux harnais de mesure ne calculent pas la latence inter-token de la même façon : l’un exclut le premier token du calcul, l’autre l’inclut. Avant de régler quoi que ce soit, il faut savoir ce que l’on mesure. C’est un sujet à part entière, et nous y reviendrons.
Sources et méthode
Les montants en dollars sont convertis en euros au taux indicatif de 1 USD = 0,92 EUR (mi-2026). Les valeurs par défaut citées correspondent à l’état de juillet 2026 et changent d’une version à l’autre : vérifiez la vôtre avant d’agir. Aucun chiffre de latence n’est repris sans son modèle, son matériel, ses longueurs d’entrée et de sortie et son niveau de concurrence.
Faits vérifiés
Comportement des ordonnanceurs. Documentation vLLM sur l’optimisation, pour l’activation par défaut du découpage du prefill en V1, le budget max_num_batched_tokens, le sens de son effet sur l’ITL et le temps jusqu’au premier token, et la préemption par recalcul. Billet de sortie de vLLM V1 du 27 janvier 2025 pour la conception de l’ordonnanceur unifié. Documentation SGLang et discussion GitHub #1163 du 25 août 2024 pour la taille de morceau de 8 192, le budget de prefill de 16 384, la fusion prefill-décodage désactivée par défaut et les politiques de file sensibles au cache. Documentation TensorRT-LLM pour la désactivation par défaut du découpage, la politique GUARANTEED_NO_EVICT et son alternative MAX_UTILIZATION.
Déplacement de la frontière de Pareto. Billet Anyscale du 22 juin 2023 (Cade Daniel, Chen Shen, Eric Liang, Richard Liaw) pour le batching continu et l’amélioration simultanée du débit et de la latence médiane. Papier vLLM (PagedAttention, SOSP 2023) pour le gaspillage mémoire ramené sous 4 %. Papier SGLang (arXiv 2312.07104) pour l’effet de RadixAttention sur le débit et sur la latence du premier token.
Mécanisme et régime. Sarathi-Serve (OSDI 2024, arXiv 2403.02310) pour la décomposition des deux leviers, les gains de capacité de service (2,6× pour Mistral-7B sur un A100, 3,7× pour Yi-34B sur deux A100, jusqu’à 5,6× pour Falcon-180B sur huit A100) et les rendements décroissants au-delà d’environ 512 tokens de prefill sur Llama-13B et A6000. Austin et al., How to Scale Your Model (Google DeepMind, 2025, chapitre 7) pour la dérivation du lot critique.
Courbe débit-latence. Table de performance NVIDIA NIM pour le Nemotron Safety Guard Multilingual 8B sur A100 80 Go SXM en BF16, entrées de 500 tokens et sorties de 10, seule source trouvée publiant simultanément le modèle, le matériel, les longueurs, la concurrence, le temps jusqu’au premier token et le débit.
Réglage par rapport aux défauts. SCOOT (arXiv 2408.04323, section 5.2) pour les réductions de temps jusqu’au premier token et de temps par token de sortie obtenues par optimisation bayésienne sur deux applications réelles.
Couches supérieures. DistServe (OSDI 2024, arXiv 2401.09670) et Splitwise (ISCA 2024, arXiv 2311.18677) pour les gains de la disaggregation. Documentation NVIDIA Dynamo pour le routeur sensible au cache, le poids de recouvrement de préfixe et la recommandation en faveur du service agrégé sur les charges courantes.
Engagements de service. Pages contractuelles publiques d’OpenAI (Scale Tier), Microsoft Azure OpenAI, AWS Bedrock, Baseten, Google Vertex AI, Together et Groq, ainsi que l’absence de contrat de service public chez Anthropic.
Estimations crédibles
Le seuil d’environ 295 requêtes en décodage simultané en BF16 sur H100 est une dérivation analytique à partir du rapport entre la puissance de calcul et la bande passante mémoire, non une mesure sur une charge réelle. Il donne un ordre de grandeur de la bascule, pas un seuil à programmer. Le plafond de 512 tokens de prefill observé par Sarathi sur une autre configuration en est une corroboration d’ordre de grandeur, pas une confirmation : les deux mesures ne portent ni sur la même grandeur ni sur le même matériel.
Nous ne publions aucune fourchette de budget de tokens, sciemment. Les recommandations d’éditeurs que nous avons rassemblées se contredisent sur le sens de l’effet, certaines associant les gros budgets à une meilleure attente initiale et d’autres à une meilleure cadence. Seule la direction documentée par les moteurs eux-mêmes est reprise ici.
L’érosion de 30 à 50 % du gain de la disaggregation par le transfert de cache provient d’une mesure tierce et dépend entièrement du tissu réseau disponible.
Ce que nous n’avons pas pu établir
Le défaut réel de max_num_batched_tokens en service en ligne n’est pas tranché par une source officielle unique : la documentation héritée donne 2 048, les recommandations courantes et la documentation AMD donnent 8 192, et la valeur peut être calculée dynamiquement selon la mémoire disponible. Nous citons le sens de l’effet et la fourchette plutôt qu’une valeur.
Aucun coût de préemption chiffré officiel n’est publié par aucun des trois moteurs. Les valeurs qui circulent proviennent de papiers tiers ou de discussions de contribution.
La description ligne à ligne des boucles d’ordonnancement provient de sources dérivées du code plutôt que d’une lecture directe à la version courante. Nous nous en tenons au comportement documenté par les projets eux-mêmes.
Les gains annoncés par les constructeurs sur leurs propres plateformes sont mesurés sur des configurations optimisées et ne valent pas garantie de production.
