LLM Primer VI — Introduction de la série & index
Tournée chapitre par chapitre de LLM Primer VI : Mettre à l'échelle les systèmes IA — le volume qui traite l'inférence LLM comme une discipline d'ingénierie où bande passante mémoire, ordonnancement et signes du dollar se rencontrent.
Pourquoi cette série existe
Un H100 loué entre quatre et huit dollars de l'heure délivre 989 TFLOP/s de calcul BF16. Un utilisateur seul, générant une seule réponse en temps réel contre un modèle 70B sur cette puce, consomme environ 0,34 pour cent de ce calcul. La puce est inactive à 99,7 pour cent — non parce que la charge est faible, mais parce qu'elle est limitée par la bande passante mémoire et que les unités de calcul n'ont rien à faire pendant que la HBM leur fait défiler les poids. L'ingénierie d'inférence est la discipline qui trouve du travail pour ces unités inactives. C'est une discipline du batching, de la comptabilité du cache KV, de la quantification, du décodage spéculatif, de l'ordonnancement, puis finalement de la plateforme, de l'orchestration et du coût. Chaque technique de ce volume est une variation du même mouvement : convertir le gâchis lié à la bande passante en débit sans casser la latence que l'utilisateur ressent réellement.
À qui s'adresse ce livre
Ingénieurs plateforme, SRE et architectes d'infrastructure qui portent l'inférence LLM à l'échelle — celles et ceux qui reçoivent l'alerte quand la latence grimpe, dont la ligne budgétaire est le parc GPU, et qui doivent expliquer à la finance pourquoi la facture du mois dernier a doublé par rapport au précédent. Le livre s'adresse aussi aux ingénieurs ML qui ont entraîné le modèle et doivent maintenant le servir, et aux ingénieurs backend qui se retrouvent soudain les plus proches d'un spécialiste d'inférence dans leur équipe. Le livre suppose de l'aisance avec les systèmes distribués et les conteneurs ; il ne suppose pas de familiarité préalable avec les entrailles des GPU ni avec le motif mémoire du transformer. Ces éléments sont construits depuis les premiers principes.
Comment le lire
Les seize chapitres se répartissent en six parties. Les chapitres 1–2 nomment la charge — la boucle autoregressive et le cache KV. Les chapitres 3–4 parcourent le silicium qui la fait tourner, des H100 au LPU de Groq. Les chapitres 5–6 parcourent les compressions côté modèle — quantification, élagage, distillation — qui rétrécissent le fardeau de la bande passante. Les chapitres 7–9 parcourent les techniques de runtime — batching, KV paginé, décodage spéculatif — qui cachent le temps mort. Les chapitres 10–13 parcourent la pile de service — moteurs, plateformes, désagrégation, autoscaling — qui transforme ces techniques en un service. Les chapitres 14–16 parcourent l'argent : économie du token, auto-hébergement contre API, et les mouvements de réduction de coût qui composent. Les chapitres peuvent être lus dans l'ordre ou attaqués par thème, mais le cadrage centré sur les mécanismes dépend des chapitres 1 et 2.
La tournée en 16 chapitres
Entre le 23 avril et le 8 mai, la tournée publie un chapitre par jour. Chaque article distille les trois idées clés du chapitre en une lecture d'environ cinq minutes, le chapitre du livre fournissant les exemples travaillés, le code et les encadrés « En clair ».
- 23 avril — Chapitre 1 — La mécanique de la génération de tokens. La boucle autoregressive, préremplissage contre décodage, et pourquoi un utilisateur seul laisse un H100 inactif à 99,7 pour cent.
- 24 avril — Chapitre 2 — Le défi du cache KV. La formule de mémoire, les arbitrages MHA/GQA/MQA, et pourquoi l'allocation naïve détruit la concurrence.
- 25 avril — Chapitre 3 — GPU de centre de données pour l'IA générative. H100, H200, B200, L40S, MI300X — lus comme des profils de bande passante et de VRAM, non de FLOPs.
- 26 avril — Chapitre 4 — Silicium spécialisé et ASIC pour l'IA. Le LPU de Groq, Inferentia2, TPU v5p/v6 et Gaudi 3 — où les ASIC gagnent et où ils perdent.
- 27 avril — Chapitre 5 — Démystifier la quantification. Pourquoi FP16 → INT4 quadruple le débit, et ce que font vraiment AWQ, GPTQ, SmoothQuant et GGUF.
- 28 avril — Chapitre 6 — Élagage et distillation des connaissances. La sparsité 2:4 sur Hopper et comment les étiquettes douces d'un professeur deviennent un modèle élève plus petit.
- 29 avril — Chapitre 7 — Stratégies de batching avancées. Du batching statique au batching continu au niveau itération, et la dette que le batching continu crée.
- 30 avril — Chapitre 8 — Gestion nouvelle génération du cache KV. PagedAttention, éviction H2O, InfiniGen et l'économie du cache de préfixe.
- 1er mai — Chapitre 9 — Décodage spéculatif. Brouillon, vérification, et l'arithmétique du moment où la spéculation paye — EAGLE, Medusa, MTP.
- 2 mai — Chapitre 10 — La couche moteur LLM. vLLM, TensorRT-LLM, SGLang, TGI, Ollama, et comment choisir un moteur sur le mécanisme plutôt que sur le benchmark.
- 3 mai — Chapitre 11 — La couche plateforme et orchestration. Ray Serve, KServe, BentoML, Triton — quelle plateforme correspond à quelle culture d'exploitation.
- 4 mai — Chapitre 12 — Service désagrégé et Kubernetes. Séparer préremplissage et décodage entre pools de GPU, et les primitives Kubernetes qui l'expriment.
- 5 mai — Chapitre 13 — Autoscaling et atténuation du démarrage à froid. Pourquoi HPA est le mauvais scaler pour les LLM, et comment KEDA, Knative et CRIU composent des démarrages à froid sous cinq secondes.
- 6 mai — Chapitre 14 — Économie du token et tarification des API. Pourquoi la sortie est facturée plus cher que l'entrée, et comment les tokens de raisonnement invisibles surprennent la facture.
- 7 mai — Chapitre 15 — API serverless vs infrastructure dédiée. Le calcul du seuil de rentabilité, plus la ligne d'ingénierie plateforme que la plupart des équipes sous-estiment.
- 8 mai — Chapitre 16 — Stratégies de réduction des coûts en production. Routage, compaction du contexte, API batch et cache sémantique — les mouvements qui composent.
À propos du livre et de la série
La série LLM Primer compte sept volumes écrits par Sho Shimoda, publiés sur Amazon KDP et lus chapitre par chapitre ici sur le blog RECEIPTROLLER. La série soutient que construire avec les LLM est une discipline système, et que cette discipline s'apprend mieux en parcourant chaque couche de la pile dans une prose centrée sur les mécanismes, plutôt que sous forme de liste à cocher. Le Volume VI est le volume d'infrastructure — celui qui répond, couche par couche, à la question de ce qui doit être vrai du matériel, du runtime et de la plateforme pour qu'une fonctionnalité LLM survive au trafic réel et à une revue financière.