Le réseau, vu par le ML

Tu connais déjà 90 % de cette leçon

HTTP, TCP, les timeouts, les retries : rien de nouveau. Ce qui change en ML, c'est où ça fait mal. Un endpoint CRUD répond en 5 ms ; une inférence de modèle prend 50 ms à 5 s. À ces échelles, chaque choix réseau devient une décision produit.

La latence d'inférence domine tout

Décompose la latence d'un appel à un modèle en production :

client ── réseau (5-50 ms) ── file d'attente (0-500 ms!) ── inférence (20 ms-5 s) ── réseau retour

Deux différences majeures avec ton backend habituel :

1. La file d'attente : un GPU traite les requêtes par batch. Ta requête attend que le batch se remplisse (ou qu'un timer expire). C'est le dynamic batching : latence individuelle sacrifiée contre débit global.
2. La variance : l'inférence LLM génère token par token — la durée dépend de la longueur de la réponse. Ton p50 peut être excellent et ton p99 catastrophique.

HTTP/1.1, gRPC ou streaming ?

Le streaming SSE est devenu le standard de facto des API LLM (OpenAI, Anthropic) : tu connais text/event-stream ? Tu sais déjà servir un LLM.

Le réseau DANS l'entraînement

En entraînement distribué (plusieurs GPUs/machines), le réseau devient le goulot : à chaque étape, les gradients de chaque GPU doivent être agrégés (all-reduce). D'où les interconnexions exotiques (NVLink, InfiniBand) des clusters ML. Retiens l'idée : la bande passante entre GPUs limite la vitesse d'entraînement autant que les GPUs eux-mêmes.