rapport ops:octet du mat\u00e9riel<\/a>. Prenons l’attention standard, sans optimisation, pour une t\u00eate de dimension Elle tient en trois lignes : calculer
Chaque ligne lit, calcule, \u00e9crit. En additionnant tous les mouvements m\u00e9moire, on obtient :<\/p>\n
<\/span> <\/span>Lecture pas \u00e0 pas : chaque terme est un nombre d’octets, avec 2 octets par valeur. Les trois termes en
C\u00f4t\u00e9 calcul, la somme des trois \u00e9tapes donne
<\/span> <\/span>Avec \n\t\t\t\n\t\t\t\tSur ce graphique, le point orange de l’attention en decode est loin \u00e0 gauche du trait pointill\u00e9 : tant qu’il y reste, ajouter de la puissance de calcul ne sert \u00e0 rien. Il faut d\u00e9placer moins d’octets, ou faire plus de calcul pour les m\u00eames octets.<\/figcaption><\/figure>\n\n\n\n\ud83d\udccc \u00c0 retenir<\/strong> Prefill, g\u00e9n\u00e9ration d’images et de vid\u00e9os sont limit\u00e9s par le calcul. Le decode est limit\u00e9 par la m\u00e9moire. Regrouper plusieurs requ\u00eates rend le decode moins limit\u00e9 par la m\u00e9moire : traiter un lot consomme plus de calcul pour le m\u00eame trafic m\u00e9moire.<\/p>\n<\/blockquote>\nLes noyaux d’attention : lire et \u00e9crire moins<\/h2>\n L’impl\u00e9mentation de base de l’attention \u00e9crit les matrices interm\u00e9diaires \n\t\t\t\n\t\t\t\t\u00c0 gauche, trois \u00e9tapes qui \u00e9crivent puis relisent S et P ; \u00e0 droite, un seul noyau qui les garde dans la m\u00e9moire rapide du GPU et n’\u00e9crit O qu’une fois. C’est l’id\u00e9e de FlashAttention.<\/figcaption><\/figure>\n\n\nFlashAttention est une s\u00e9rie de noyaux fusionn\u00e9s \u00e0 la main pour des GPU pr\u00e9cis : le code pour H100 diff\u00e8re de celui pour B200. Elle sert surtout aux op\u00e9rations limit\u00e9es par le calcul, comme le prefill ou la g\u00e9n\u00e9ration de vid\u00e9o. PagedAttention d\u00e9coupe le cache KV en blocs, les pages, accessibles par une table de correspondance : le cache peut vivre dans une m\u00e9moire fragment\u00e9e plut\u00f4t que dans un bloc contigu.<\/p>\n
Ni l’une ni l’autre ne change la complexit\u00e9 quadratique de l’attention. Les variantes algorithmiques, elles, la changent. L’attention \u00e0 fen\u00eatre glissante ne regarde que les
Pour les longues s\u00e9quences, le prefill par morceaux (chunked prefill<\/em>) d\u00e9coupe la grande entr\u00e9e en morceaux ex\u00e9cut\u00e9s en m\u00eame temps que le decode, selon les ressources disponibles, pour qu’une longue s\u00e9quence ne submerge pas le moteur.<\/p>\nLes six leviers de la couche d’ex\u00e9cution<\/h2>\n Toutes les techniques ci-dessous partagent un principe : plus tu ajoutes de contraintes au syst\u00e8me, meilleure est la performance. Elles se combinent, mais pas toujours harmonieusement, nous y reviendrons.<\/p>\n
Regrouper les requ\u00eates : le batching<\/h3>\n Un m\u00eame GPU peut traiter plus d’une requ\u00eate \u00e0 la fois. Le regroupement statique attend que le lot soit plein avant de d\u00e9marrer. Le regroupement dynamique d\u00e9marre quand le lot est plein ou quand un d\u00e9lai configur\u00e9 est \u00e9coul\u00e9. Le regroupement continu ins\u00e8re les requ\u00eates \u00e0 mesure que des places se lib\u00e8rent.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tDans le diagramme du bas, chaque requ\u00eate d\u00e9marre et finit ind\u00e9pendamment, sans l’attente commune des deux premiers. Les moteurs vLLM, SGLang et TensorRT-LLM regroupent ainsi au niveau du token (\u00ab en vol \u00bb pour TensorRT-LLM), ce qui minimise la latence face au regroupement statique.<\/figcaption><\/figure>\n\n\nLa taille de lot est un curseur : l’augmenter produit plus de d\u00e9bit global, mais la latence de chaque utilisateur se d\u00e9grade. Il faut donc tester plusieurs tailles de lot pour trouver le bon compromis pour ton mod\u00e8le, ton instance, ta cible de latence et ton budget.<\/p>\n
Quantifier : des nombres plus petits<\/h3>\n Les mod\u00e8les sont entra\u00een\u00e9s dans un format num\u00e9rique natif, le plus souvent BF16 ou FP16. La quantification apr\u00e8s entra\u00eenement convertit les poids et d’autres valeurs vers une pr\u00e9cision inf\u00e9rieure. Diviser la pr\u00e9cision par deux aide les deux phases : le prefill s’ex\u00e9cute sur des Tensor Cores de pr\u00e9cision inf\u00e9rieure qui offrent deux fois plus de FLOPS, et le decode charge deux fois moins de donn\u00e9es par valeur.<\/p>\n
Le gain r\u00e9el est moins beau que la th\u00e9orie, car travailler sur des donn\u00e9es quantifi\u00e9es ajoute un surco\u00fbt : descendre d’un niveau de pr\u00e9cision apporte en pratique 30 \u00e0 50 % de performance en plus pour les LLM.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tLe sch\u00e9ma montre la m\u00e9canique de base : on rep\u00e8re les bornes du tenseur, on met \u00e0 l’\u00e9chelle avec \n\t\t\t\n\t\t\t\tLe revers, ce sont les erreurs de pr\u00e9cision, qui s’accumulent. \u00c9l\u00e8ve au carr\u00e9 et au cube diff\u00e9rentes pr\u00e9cisions de \u03c0 : avec 3,14159 tu obtiens 9,869588 et 31,006198 ; avec 3,14, 9,8596 et 30,959144 ; avec 3, tu obtiens 9 et 27. Tout le travail de quantification consiste \u00e0 pr\u00e9venir ces erreurs et \u00e0 limiter leur effet sur la sortie finale.<\/p>\n
Tout ne se quantifie pas avec le m\u00eame risque. De la moins \u00e0 la plus sensible : les poids des couches lin\u00e9aires, les activations, le cache KV, puis l’attention, tr\u00e8s sensible, surtout des \u00e9quations comme le softmax.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tOn quantifie de gauche \u00e0 droite, avec prudence : le dernier encadr\u00e9, orange, est celui o\u00f9 les erreurs s’accumulent d’un token \u00e0 l’autre, puisque le calcul de chaque token s’appuie sur tous les pr\u00e9c\u00e9dents. Presque tous les sch\u00e9mas gardent donc le softmax dans sa pr\u00e9cision d’origine.<\/figcaption><\/figure>\n\n\nC\u00f4t\u00e9 formats, mieux vaut s’en tenir aux flottants : les entiers manquent de plage dynamique pour les charges sensibles \u00e0 la qualit\u00e9. Les flottants 8 bits (FP8, MXFP8) offrent g\u00e9n\u00e9ralement le meilleur compromis ; le FP4, surtout NVFP4, est prometteur.<\/p>\n
Deux voies existent : l’entra\u00eenement conscient de la quantification (des laboratoires publient ainsi GPT-OSS en MXFP4 ou Kimi K2 Thinking en INT4) et la quantification apr\u00e8s entra\u00eenement, la seule accessible quand on re\u00e7oit des poids termin\u00e9s. NVIDIA TensorRT Model Optimizer est un outil de r\u00e9f\u00e9rence, et ses sorties sont compatibles avec vLLM, SGLang et TensorRT-LLM.<\/p>\n
\n\u26a0\ufe0f Pi\u00e8ge<\/strong> La quantification est une \u00e9chelle, pas un choix binaire. Quantifie en FP8 plut\u00f4t qu’en FP4, ou seulement les poids, si la qualit\u00e9 ne peut pas \u00eatre risqu\u00e9e. Pour v\u00e9rifier, compare la perplexit\u00e9 avant et apr\u00e8s (on cherche une hausse minimale), puis un banc d’essai public ou, mieux, une \u00e9valuation propre \u00e0 ton domaine.<\/p>\n<\/blockquote>\nSp\u00e9culer : plusieurs tokens par passe<\/h3>\n Le decode est limit\u00e9 par la m\u00e9moire : \u00e0 lot faible ou mod\u00e9r\u00e9, le calcul reste au repos pendant que les poids sont lus. Le d\u00e9codage sp\u00e9culatif exploite ce calcul libre pour tenter de produire plusieurs tokens par passe avant dans le mod\u00e8le cible.<\/p>\n
Le m\u00e9canisme est commun \u00e0 tous les algorithmes : un sp\u00e9culateur propose un ou plusieurs tokens de brouillon, le mod\u00e8le cible les valide en une seule passe, accepte ceux qui co\u00efncident avec ce qu’il aurait g\u00e9n\u00e9r\u00e9, puis produit lui-m\u00eame un token de plus. On obtient \n\t\t\t\n\t\t\t\tRemarque la note du bas : d\u00e8s qu’un brouillon est rejet\u00e9, tous les suivants le sont aussi, ce qui favorise des s\u00e9quences courtes et fiables. Et le gain ne porte que sur le TPS, pas sur le TTFT.<\/figcaption><\/figure>\n\n\nPourquoi \u00e7a marche ? V\u00e9rifier est bien plus rapide que g\u00e9n\u00e9rer, comme une grille de sudoku : la r\u00e9soudre est difficile, contr\u00f4ler une grille termin\u00e9e est facile. Le gain d\u00e9pend de trois facteurs : le co\u00fbt d’un token de brouillon, la longueur de la s\u00e9quence de brouillon et le taux d’acceptation.<\/p>\n
Le taux d’acceptation chute avec la temp\u00e9rature (des distributions plus difficiles \u00e0 pr\u00e9dire) et varie avec le sujet trait\u00e9. Autre limite : la sp\u00e9culation n’aide qu’\u00e0 faible taille de lot, l\u00e0 o\u00f9 il reste des cycles de calcul ; \u00e0 lot \u00e9lev\u00e9, le calcul est satur\u00e9 et il faut la d\u00e9sactiver dynamiquement.<\/p>\n
Trois variantes s’appuient sur un mod\u00e8le de brouillon :<\/p>\n
\nBrouillon-cible<\/strong> : un petit mod\u00e8le de la m\u00eame famille g\u00e9n\u00e8re les brouillons, avec en r\u00e8gle g\u00e9n\u00e9rale au moins dix fois moins de param\u00e8tres. Simple \u00e0 mettre en place, mais au surco\u00fbt le plus \u00e9lev\u00e9.<\/li>\nMedusa<\/strong> : elle affine le mod\u00e8le cible pour lui greffer de deux \u00e0 quatre t\u00eates de d\u00e9codage suppl\u00e9mentaires. Peu utilis\u00e9e en production, elle a inspir\u00e9 EAGLE.<\/li>\nEAGLE<\/strong> : un mod\u00e8le de brouillon entra\u00een\u00e9 sur les \u00e9tats cach\u00e9s du mod\u00e8le, jusqu’\u00e0 huit tokens de brouillon avec un tr\u00e8s haut taux d’acceptation. C’est l’algorithme de r\u00e9f\u00e9rence pour un usage g\u00e9n\u00e9ral chez les ing\u00e9nieurs qui savent entra\u00eener ces t\u00eates.n-grammes<\/strong> fait sans mod\u00e8le de brouillon : elle construit pendant le prefill un dictionnaire de s\u00e9quences du texte d’entr\u00e9e. Elle d\u00e9passe dix tokens de brouillon, mais n’est efficace que quand la sortie ressemble \u00e0 l’entr\u00e9e, comme en compl\u00e9tion de code. Le d\u00e9codage anticip\u00e9 (Lookahead Decoding<\/em>) g\u00e9n\u00e9ralise l’id\u00e9e en produisant les n-grammes pendant l’inf\u00e9rence, au prix de calcul suppl\u00e9mentaire.<\/li>\n<\/ul>\nMettre en cache : ne pas refaire ce qui est fait<\/h3>\n Tous les moteurs utilisent le cache KV requ\u00eate par requ\u00eate : sans lui, il faudrait recalculer chaque valeur pr\u00e9c\u00e9dente de toute la s\u00e9quence pour chaque nouveau token. On peut en tirer plus en le r\u00e9utilisant d’une requ\u00eate \u00e0 l’autre.<\/p>\n
Prenons deux prompts de quatre tokens qui commencent par \u00ab Weather in \u00bb. Par d\u00e9faut, le moteur ex\u00e9cute le prefill sur les quatre tokens de chacun. Avec le cache de pr\u00e9fixe, il r\u00e9utilise le cache KV de la premi\u00e8re requ\u00eate et saute le prefill des deux premiers tokens de la seconde. Les API facturent moins cher les tokens d’entr\u00e9e \u00ab avec succ\u00e8s de cache \u00bb pour cette raison.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tSeul le pr\u00e9fixe commun, en bleu, est relu depuis le cache. M\u00eame le \u00ab ? \u00bb final, pourtant identique dans les deux requ\u00eates, est recalcul\u00e9, parce qu’il suit le premier token diff\u00e9rent.<\/figcaption><\/figure>\n\n\nLe cache de pr\u00e9fixe fonctionne du d\u00e9but de la s\u00e9quence jusqu’au premier token non r\u00e9p\u00e9t\u00e9. Si le tout premier token diff\u00e8re, il n’y a aucune \u00e9conomie, m\u00eame si tous les suivants sont identiques. Place donc les tokens nouveaux le plus tard possible dans le contexte : c’est ton ing\u00e9nierie de contexte qui d\u00e9termine les \u00e9conomies de TTFT.<\/p>\n
Les gains deviennent massifs l\u00e0 o\u00f9 de longues parties se r\u00e9p\u00e8tent : invites syst\u00e8me d’agents ou de chatbots, compl\u00e9tion de code, r\u00e9sum\u00e9 et questions-r\u00e9ponses sur documents, conversations \u00e0 plusieurs tours. Pour d\u00e9passer la limite du pr\u00e9fixe, des outils comme CacheBlend et LMCache prennent en charge des s\u00e9quences hors pr\u00e9fixe.<\/p>\n
Reste un probl\u00e8me : le cache KV occupe beaucoup de m\u00e9moire. On peut le d\u00e9charger de la VRAM vers d’autres stockages, par bande passante d\u00e9croissante : G1 (VRAM du GPU, de l’ordre du To\/s pour 10 \u00e0 100 Go), G2 (RAM de l’h\u00f4te, 10 \u00e0 100 Go\/s), G3 (SSD local, 5 \u00e0 10 Go\/s) et G4 (SSD en r\u00e9seau, de l’ordre du Go\/s pour des dizaines de To).<\/p>\n\n\n\n\t\t\t\n\t\t\t\tLa r\u00e8gle : les blocs les plus utilis\u00e9s restent \u00e0 gauche, dans la m\u00e9moire la plus rapide, les autres glissent vers la droite jusqu’\u00e0 ce qu’on en ait besoin. NVIDIA Dynamo prend en charge ce d\u00e9port avec KVBM, qui fournit des API pour d\u00e9placer des blocs de cache KV entre niveaux.<\/figcaption><\/figure>\n\n\nAvec plusieurs r\u00e9plicas, le routage doit lui aussi tenir compte du cache : un utilisateur en longue conversation doit atterrir autant que possible sur le m\u00eame r\u00e9plica pour obtenir un succ\u00e8s de cache. On parle de routage conscient du cache. Un cache global sur stockage r\u00e9seau G4 garantit en plus que les s\u00e9quences en cache ne sont pas perdues quand des n\u0153uds s’arr\u00eatent pendant la mise \u00e0 l’\u00e9chelle.<\/p>\n
Parall\u00e9liser : quand un GPU ne suffit plus<\/h3>\n Tous les LLM de pointe sont trop gros pour tenir sur un seul GPU en inf\u00e9rence par lots. Il ne suffit d’ailleurs pas de faire tout juste tenir les poids : le cache KV occupe souvent 80 % ou plus de la VRAM restante apr\u00e8s les poids. Avec quatre B200, soit 720 Go, on pourrait th\u00e9oriquement charger les poids de DeepSeek, mais il ne resterait aucune place pour le cache KV. Un n\u0153ud complet de huit B200 est n\u00e9cessaire pour un vrai trafic de production.<\/p>\n
Il existe trois formes de parall\u00e9lisme de mod\u00e8le :<\/p>\n
\nPipeline (PP)<\/strong> : les couches sont r\u00e9parties entre les GPU. Latence et usage m\u00e9diocres ; il n’est pas recommand\u00e9, sauf pour l’inf\u00e9rence multi-n\u0153uds.<\/li>\nTensoriel (TP)<\/strong> : les tenseurs de chaque couche sont r\u00e9partis. Les op\u00e9rations lourdes sont partag\u00e9es, mais il faut synchroniser les GPU. C’est g\u00e9n\u00e9ralement le meilleur choix pour une faible latence dans un seul n\u0153ud.<\/li>\nExperts (EP)<\/strong> : dans un mod\u00e8le MoE, chaque expert vit sur un GPU. Il faut du routage entre GPU, mais le d\u00e9bit est meilleur.<\/li>\n<\/ul>\n\n\n\n\t\t\t\n\t\t\t\tLe sch\u00e9ma associe chaque forme \u00e0 sa caract\u00e9ristique : latence m\u00e9diocre pour PP, latence minimale dans un n\u0153ud pour TP, d\u00e9bit \u00e9lev\u00e9 et multi-n\u0153uds possible pour EP. Dans un mod\u00e8le \u00e0 128 experts servi en EP8, chaque GPU h\u00e9berge 16 experts complets.<\/figcaption><\/figure>\n\n\nLe parall\u00e9lisme tensoriel doit \u00eatre ta strat\u00e9gie par d\u00e9faut. Mais les r\u00e9sultats de chaque couche doivent \u00eatre combin\u00e9s par une r\u00e9duction collective (all-reduce<\/em>) avant la couche suivante : sur des n\u0153uds \u00e9quip\u00e9s de NVLink et NVSwitch, ce surco\u00fbt de communication est minimis\u00e9. De nombreux d\u00e9ploiements m\u00ealent TP pour l’attention et EP pour la couche MoE parcimonieuse.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tRegarde l’ordre de grandeur d’\u00e9cart : NVLink atteint jusqu’\u00e0 1 800 Go\/s sur Blackwell et 900 Go\/s sur Hopper, alors qu’InfiniBand plafonne \u00e0 400 Gb\/s par carte r\u00e9seau. D\u00e8s que l’inf\u00e9rence sort d’un n\u0153ud, la communication devient le goulot.<\/figcaption><\/figure>\n\n\nSur InfiniBand, le TP exige trop de communication entre GPU. Deux options fonctionnent : pour les mod\u00e8les denses, du TP dans chaque n\u0153ud et du PP entre les n\u0153uds (TP8PP2) ; pour les MoE, le parall\u00e9lisme d’experts (EP16). Pour les MoE, TP8PP2 offrira g\u00e9n\u00e9ralement une latence plus basse par utilisateur, et EP16 un d\u00e9bit global plus \u00e9lev\u00e9.<\/p>\n
D\u00e9sagr\u00e9ger : s\u00e9parer prefill et decode<\/h3>\n Quand prefill et decode tournent sur le m\u00eame n\u0153ud sous fort trafic, ils se g\u00eanent : le prefill consomme du calcul, le decode de la m\u00e9moire, et avec de plus grands lots ils se disputent les ressources.<\/p>\n
La d\u00e9sagr\u00e9gation les s\u00e9pare en moteurs distincts, sur des GPU ou des n\u0153uds distincts. Le moteur de prefill prend la s\u00e9quence d’entr\u00e9e et g\u00e9n\u00e8re un cache KV en calculant le premier token ; il envoie le cache KV au moteur de decode par l’interconnexion mat\u00e9rielle ; le moteur de decode calcule tous les tokens suivants.<\/p>\n
Les vrais syst\u00e8mes ne comptent pas un moteur de chaque sorte. On note xPyD le nombre de moteurs de prefill et de decode : 5P3D signifie cinq moteurs de prefill et trois de decode au service d’un m\u00eame d\u00e9ploiement. Le nouveau goulot devient la taille de la file de prefill, et l’autre est le manque de cache KV sur les moteurs de decode sous forte charge, soulag\u00e9 par la quantification et le d\u00e9port du cache KV.<\/p>\n
\n\ud83d\udccc \u00c0 retenir<\/strong> Ces six leviers servent \u00e0 contourner un goulot. Le batching rend le decode moins limit\u00e9 par la m\u00e9moire, la quantification diminue les octets \u00e0 lire, la sp\u00e9culation produit plusieurs tokens par lecture des poids, le cache \u00e9vite de recalculer, le parall\u00e9lisme \u00e9tale poids et cache sur plusieurs GPU, la d\u00e9sagr\u00e9gation sp\u00e9cialise chaque phase.<\/p>\n<\/blockquote>\nQuel moteur pour appliquer tout \u00e7a ?<\/h2>\n Tu n’as pas \u00e0 r\u00e9impl\u00e9menter ces techniques : trois moteurs concurrents les int\u00e8grent. Ils offrent de bonnes performances pr\u00eates \u00e0 l’emploi et fonctionnent d’embl\u00e9e avec le regroupement continu ; ils prennent en charge quantification, d\u00e9codage sp\u00e9culatif, cache de pr\u00e9fixe, parall\u00e9lisme et d\u00e9sagr\u00e9gation. Les moteurs sont puissants parce qu’ils sont configurables : tu testes des combinaisons plut\u00f4t que de r\u00e9p\u00e9ter des impl\u00e9mentations routini\u00e8res.<\/p>\n
\n\n\n<\/th>\n vLLM<\/th>\n SGLang<\/th>\n TensorRT-LLM<\/th>\n<\/tr>\n<\/thead>\n \n\nPerformance<\/td>\n Bonne<\/td>\n Bonne<\/td>\n La meilleure<\/td>\n<\/tr>\n \nFacilit\u00e9 d’usage<\/td>\n Facile<\/td>\n Facile<\/td>\n Difficile<\/td>\n<\/tr>\n \nMod\u00e8les pris en charge<\/td>\n La plupart<\/td>\n La plupart<\/td>\n Certains<\/td>\n<\/tr>\n \nMat\u00e9riel<\/td>\n GPU, TPU<\/td>\n NVIDIA, AMD<\/td>\n NVIDIA seulement<\/td>\n<\/tr>\n \nLicence<\/td>\n Apache 2.0<\/td>\n Apache 2.0<\/td>\n Apache 2.0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nvLLM et SGLang sont plus g\u00e9n\u00e9ralistes et prennent en charge davantage de mod\u00e8les d\u00e8s le premier jour ; TensorRT-LLM a une courbe d’apprentissage plus raide mais atteint g\u00e9n\u00e9ralement la meilleure performance, en grande partie gr\u00e2ce aux noyaux \u00e9crits et fusionn\u00e9s \u00e0 la main par les ing\u00e9nieurs de NVIDIA. Pour orchestrer ces moteurs \u00e0 grande \u00e9chelle, NVIDIA Dynamo ajoute routage KV distribu\u00e9, d\u00e9sagr\u00e9gation et parall\u00e9lisme multi-n\u0153uds ; sans volume suffisant, il serait une surcharge inutile.<\/p>\n
Le voir tourner : DeepSeek sur huit GPU<\/h2>\n Reprenons notre fil rouge. Premi\u00e8re question : combien de GPU faut-il ? On estime le minimum en multipliant la pr\u00e9cision, le nombre de param\u00e8tres et l’allocation pr\u00e9vue pour le cache KV, puis on arrondit \u00e0 la taille d’instance sup\u00e9rieure. Le bloc suivant fait ce calcul pour DeepSeek en FP8 ; round_up<\/code> y d\u00e9signe cet arrondi vers la taille disponible suivante.<\/p>\n# Deciding GPU allocation for DeepSeek\nbits_precision = 8 # FP8 quantization\nparams = 671 # parameters in billions\nkv_cache_allocation = 1.8\nvram_required = (bits_precision \/ 8) * params * kv_cache_allocation\n# DeepSeek requires about 1200 GB of VRAM with this config\nb200_vram_available = [180, 360, 720, 1440]\nround_up(vram_required, b200_vram_available)\n# Serving DeepSeek in FP8 requires 1440 GB of VRAM (8xB200 GPUs)\n<\/code><\/pre>\nAvec 8 bits, 671 milliards de param\u00e8tres et un coefficient de 1,8 pour le cache KV, le calcul donne environ 1 200 Go ; on arrondit \u00e0 la taille d’instance suivante, 1 440 Go, soit huit B200. M\u00eame pour des mod\u00e8les de taille moyenne, on veut souvent plus que le minimum de GPU, pour permettre de plus grands caches KV et une meilleure latence par utilisateur.<\/p>\n
Deuxi\u00e8me question : quelle part de la m\u00e9moire r\u00e9server au cache KV ? Le moteur se r\u00e8gle. Voici l’extrait de configuration TensorRT-LLM qui fixe cette part.<\/p>\n
kv_cache_config.free_gpu_memory_fraction = 0.8\n# or any value 0.0 < n < 1.0\n<\/code><\/pre>\nCe r\u00e9glage r\u00e9serve au cache KV 80 % de la VRAM restante : sur un B200 de 180 Go dont 100 Go servent aux poids du mod\u00e8le et aux tampons, cela alloue 80 % des 80 Go restants, soit 64 Go. Une fois cette allocation remplie, et elle se remplit vite, il faut supprimer des caches KV enregistr\u00e9s, ce qui augmente la probabilit\u00e9 d’\u00e9chec de cache pour les requ\u00eates futures.<\/p>\n
Troisi\u00e8me question : comment lancer le serveur ? Avec vLLM, la commande vllm serve<\/code> active ici le parall\u00e9lisme d’experts et un parall\u00e9lisme tensoriel sur 8 GPU, et nomme le mod\u00e8le ds31<\/code> pour les clients.<\/p>\nvllm serve deepseek-ai\/DeepSeek-V3.1\n --enable-expert-parallel\n --tensor-parallel-size 8\n --served-model-name ds31\n<\/code><\/pre>\nAvec SGLang, la m\u00eame id\u00e9e se compl\u00e8te d’un d\u00e9codage sp\u00e9culatif EAGLE : on r\u00e8gle le nombre d’\u00e9tapes sp\u00e9culatives, le top-k d’EAGLE et le nombre de tokens de brouillon, avec un parall\u00e9lisme tensoriel sur 8 GPU.<\/p>\n
python3 -m sglang.launch_server\n --model-path deepseek-ai\/DeepSeek-V3-0324\n --speculative-algorithm EAGLE\n --speculative-num-steps 1\n --speculative-eagle-topk 1\n --speculative-num-draft-tokens 2\n --trust-remote-code\n --tp 8\n<\/code><\/pre>\nAvec TensorRT-LLM, la commande trtllm-serve<\/code> r\u00e8gle en plus la taille maximale de lot, les limites de tokens et de s\u00e9quence, la part de m\u00e9moire GPU r\u00e9serv\u00e9e au cache KV, et combine parall\u00e9lisme tensoriel et parall\u00e9lisme d’experts sur huit GPU.<\/p>\ntrtllm-serve deepseek-ai\/DeepSeek-R1-0528\n --host 0.0.0.0\n --port 8000\n --backend pytorch\n --max_batch_size 1024\n --max_num_tokens 3200\n --max_seq_len 2048\n --kv_cache_free_gpu_memory_fraction 0.8\n --tp_size 8\n --ep_size 8\n --trust_remote_code\n --extra_llm_api_options ${EXTRA_LLM_API_FILE}\n<\/code><\/pre>\nRetiens ce que ces trois commandes ont en commun : chaque option est un levier vu plus haut. Parall\u00e9lisme tensoriel et d’experts, sp\u00e9culation, taille de lot, part de VRAM du cache KV : optimiser un moteur, c’est avant tout r\u00e9gler ces param\u00e8tres.<\/p>\n
Savoir si \u00e7a a march\u00e9<\/h2>\n Optimiser sans mesurer ne m\u00e8ne nulle part. Distingue d’abord le temps d’inf\u00e9rence (le temps pass\u00e9 sur le GPU \u00e0 g\u00e9n\u00e9rer les tokens) de la mesure de bout en bout, qui inclut latence r\u00e9seau et file d’attente. Quand l’inf\u00e9rence est rapide mais que le bout en bout est lent, tourne-toi vers l’infrastructure plut\u00f4t que vers le mod\u00e8le.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tLa moyenne cache les requ\u00eates lentes : les temps de r\u00e9ponse forment une distribution asym\u00e9trique, et la moyenne d\u00e9passe la m\u00e9diane. On mesure donc des percentiles (P50, P90, P99), et la zone orange du graphique rappelle que ce sont ces 10 % de requ\u00eates les plus lentes que tes utilisateurs remarquent.<\/figcaption><\/figure>\n\n\nUn bon banc d’essai imite le trafic r\u00e9el et ne change qu’une variable \u00e0 la fois ; le profilage explique le pourquoi des chiffres. Pour les mod\u00e8les d’embedding quantifi\u00e9s, un contr\u00f4le simple compare la similarit\u00e9 cosinus des vecteurs de sortie du mod\u00e8le d’origine et du mod\u00e8le quantifi\u00e9 : 100 % signifie des vecteurs identiques, et il faut au moins 99 % pour \u00eatre en confiance.<\/p>\n
Pi\u00e8ges et limites<\/h2>\n Les techniques sont parfois symbiotiques, parfois incompatibles. Quantifier le cache KV all\u00e8ge un goulot de la d\u00e9sagr\u00e9gation, mais augmenter la taille de lot r\u00e9duit le calcul disponible pour la sp\u00e9culation. L’objectif est un ensemble \u00e9quilibr\u00e9 d’optimisations qui vaut plus que la somme de ses parties, et cela demande de l’exp\u00e9rimentation patiente : chez Baseten, un ing\u00e9nieur a essay\u00e9 77 configurations avant de trouver une solution peu \u00e9vidente qui doublait le TPS pour le mod\u00e8le d’un client.<\/p>\n
\n\u26a0\ufe0f Pi\u00e8ge<\/strong> Plus de contraintes donne une meilleure performance, mais plus de trafic permet plus d’optimisations. Un parall\u00e9lisme pouss\u00e9, un routage conscient du KV et une d\u00e9sagr\u00e9gation dynamique n’ont de sens qu’avec un grand nombre de GPU. \u00c0 faible trafic, ces outils ajoutent de la complexit\u00e9 sans rapporter.<\/p>\n<\/blockquote>\nQuelques autres limites \u00e0 garder en t\u00eate :<\/p>\n
\nR\u00e9duire la latence par la sp\u00e9culation impose de r\u00e9duire les tailles de lot, ce qui abaisse le d\u00e9bit et augmente le co\u00fbt.<\/li>\n Le cache de pr\u00e9fixe et la d\u00e9sagr\u00e9gation ne servent \u00e0 rien pour un mod\u00e8le d’embedding, qui traite ses tokens en parall\u00e8le.<\/li>\n Les moteurs compil\u00e9s ciblent un GPU pr\u00e9cis : pour ex\u00e9cuter un mod\u00e8le sur un B200, il faut compiler sur un B200. Un noyau choisi \u00e0 la main peut aussi perdre sa compatibilit\u00e9 en changeant de GPU.<\/li>\n<\/ul>\nSurtout, aucun r\u00e9glage ne remplace le choix du mod\u00e8le : \u00e0 mat\u00e9riel, ex\u00e9cution et architecture \u00e9gaux, un mod\u00e8le plus petit est plus rapide et moins cher. C’est la d\u00e9cision la plus importante, avant le moteur ou l’algorithme de sp\u00e9culation.<\/p>\n
![\"Boucle](\"https:\/\/www.ranksignal.fr\/wp-content\/uploads\/2026\/10\/b1_ch03_boucle_prefill_decode-scaled.png\")