Alors que les grands modèles de langage (LLM) passent des prototypes expérimentaux aux charges de travail de production, le goulot d'étranglement se déplace souvent du calcul GPU vers l'E/S réseau. Dans les scénarios de service à haut débit, une configuration standard du noyau Linux est rarement suffisante. Cet article explore les couches d'infrastructure critiques — spécifiquement les réglages TCP et la topologie réseau — qui déterminent si votre modèle sert les requêtes en millisecondes ou en secondes.
Le goulot d'étranglement de la pile TCP dans le service IA
L'inférence LLM se caractérise par des connexions de longue durée pour les réponses en streaming et des requêtes petites et fréquentes pour le traitement par lots. La pile TCP par défaut est conçue pour le trafic web général, et non pour les exigences nuancées de l'inférence IA. Les paramètres clés doivent souvent être ajustés pour empêcher la phase de « Slow Start » d'impacter la latence et pour maximiser le débit sur les liens à haute bande passante et haute latence.
D'abord, nous devons optimiser les tailles des tampons de réception et d'envoi. De grands tampons permettent à l'interface réseau d'absorber les rafales de trafic, empêchant la perte de paquets et les retransmissions ultérieures. Pour un lien de centre de données typique, ces valeurs doivent être nettement supérieures aux valeurs par défaut.
# /etc/sysctl.conf
# Activer le réglage automatique pour les réseaux à haut débit
net.ipv4.tcp_window_scaling = 1
# Augmenter les tailles de tampon à 16 Mo (la valeur standard est souvent de 128 Ko à 1 Mo)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 87380 16777216De plus, activer tcp_fastopen peut réduire la latence de configuration de la connexion pour les requêtes répétées, ce qui est crucial pour les services basés sur une API où les clients maintiennent des connexions persistantes.
Topologies réseau : Comprendre la couche physique
Le réglage logiciel ne peut pas corriger les limitations physiques. Dans les clusters LLM, en particulier ceux utilisant une inférence distribuée ou vLLM, la topologie réseau entre le client et le serveur GPU est d'une importance capitale. Évitez de router le trafic d'inférence à travers des commutateurs spine-leaf si cela introduit des sauts inutiles. Visez plutôt une topologie Clos qui minimise le nombre de commutateurs traversés.
Pour les configurations multi-nœuds, envisagez d'utiliser RDMA (Remote Direct Memory Access) sur Ethernet Converged (RoCE) ou InfiniBand. Le RDMA contourne entièrement la pile réseau du noyau, permettant au GPU de lire les données directement depuis la carte réseau. Cela réduit la surcharge CPU et la latence jusqu'à 50 % par rapport aux piles TCP/IP standard.
# Exemple : Configuration de RoCE sur une carte réseau Linux
# Assurez-vous que le PFC (Priority Flow Control) est activé pour prévenir la perte de paquets
sudo ethtool -K eth0 roce on
sudo ip link set dev eth0 type ipvlan mode l2
# Vérifier la capacité RoCE
sudo ethtool --dump-regset eth0 | grep roceOptimisations au niveau de l'application
Au-delà du noyau et du matériel, le réglage au niveau de l'application joue un rôle significatif. Lors de l'utilisation de frameworks comme vLLM ou TGI (Text Generation Inference), activez le regroupement continu (continuous batching). Cela permet au serveur d'empaqueter plusieurs requêtes dans un seul passage avant (forward pass), maximisant ainsi l'utilisation du GPU tout en maintenant une latence faible pour les requêtes individuelles.
De plus, assurez-vous que votre équilibreur de charge HTTP est configuré pour des connexions de longue durée. Si vous utilisez Nginx ou HAProxy, augmentez le proxy_read_timeout pour tenir compte des temps de génération variables des LLM. Une expiration prématurée est une source courante d'erreurs de réponse partielle dans les services LLM de production.
Conclusion
Optimiser l'inférence LLM ne consiste pas seulement à acheter des GPU plus rapides ; cela nécessite une vision holistique de l'ensemble du chemin de la requête. En ajustant les paramètres du noyau TCP, en exploitant le RDMA pour la communication intra-nœud à faible latence et en configurant les équilibreurs de charge pour des sessions de longue durée, vous pouvez réduire considérablement le temps jusqu'au premier jeton et la latence globale. Commencez par la couche réseau, mesurez votre base de référence et itérez. La différence entre une expérience utilisateur saccadée et une expérience fluide est souvent cachée dans ces fichiers de configuration.