Pour l'inférence de LLM à proximité de l'utilisateur, il y a rarement des serveurs « lourds » prêts à l'emploi. Il s'agit généralement d'un mélange d'appareils Edge, de passerelles et de nœuds fog avec différentes quantités de mémoire et de puissance de calcul. Déployer un modèle comme s'il tenait toujours sur un seul appareil, c'est fermer les yeux sur la réalité : soit le modèle ne tient pas, soit il fonctionne avec des latences inacceptables, soit il laisse inutilisées des ressources coûteuses. Le framework E2LLM propose une voie plus pragmatique pour cela.
Pourquoi le scénario classique ne convient pas
Les approches traditionnelles de service des LLM partent souvent du principe que le modèle entier vit sur une seule machine. Dans le cloud, cela fonctionne généralement, mais dans un environnement Edge/Fog, les nœuds sont plus faibles et plus hétérogènes. Certains appareils peuvent avoir assez de mémoire pour les poids, mais pas assez de puissance pour les calculs ; d'autres, au contraire, sont rapides mais avec une capacité limitée. Si l'on essaie simplement de « répartir » le modèle sur tous les appareils disponibles, des problèmes de coordination, de communication et d'utilisation commencent à apparaître.
En pratique, trois choses sont nécessaires en même temps :
- une faible latence prévisible,
- une utilisation économe des ressources,
- un coût de déploiement raisonnable.
Elles entrent en conflit les unes avec les autres, il faut donc un compromis, pas une optimisation à sens unique. E2LLM est construit autour de ce compromis.
Répliques et rôles : comment E2LLM contourne les limites
L'idée clé d'E2LLM n'est pas de diviser un seul modèle entre tous les nœuds, mais de regrouper les appareils en répliques. À l'intérieur de chaque réplique, une copie complète du modèle est stockée, puis elle est distribuée entre les membres du groupe à l'aide du parallélisme de modèle. Cela semble être un gaspillage de mémoire, mais en réalité, cette duplication améliore la tolérance aux pannes et permet de traiter plusieurs requêtes en parallèle.
Ensuite, la connaissance du fonctionnement de l'inférence LLM entre en jeu. Elle comporte deux phases avec des profils de charge différents : le prefill, lorsque le modèle traite activement les tokens d'entrée et construit le cache d'attention, et le decode, lorsqu'il génère les tokens de sortie. Ces phases nécessitent des ressources différentes : le prefill est sensible à la puissance de calcul de pointe, le decode à la bande passante mémoire et à la latence de transfert de données.
Au lieu d'obliger chaque groupe à faire les deux, E2LLM attribue des rôles spécialisés aux répliques. Certaines deviennent des répliques de prefill et traitent plus rapidement les requêtes entrantes, d'autres deviennent des répliques de decode et sont responsables d'une génération fluide. Cette séparation permet de ne pas gaspiller de ressources sur la phase « inadaptée » au matériel spécifique.
Comment les groupes d'appareils sont formés
On ne peut pas simplement prendre les premiers appareils venus et les appeler une réplique. E2LLM décide d'abord quels nœuds méritent d'être regroupés. Pour cela, un algorithme génétique est utilisé : il explore les variantes de clusters et les améliore progressivement, en se basant sur la performance finale du système.
Une fois le cluster défini, il faut comprendre comment découper le modèle entre les participants. C'est là qu'intervient la programmation dynamique : elle cherche une stratégie de partitionnement qui minimise les « goulots d'étranglement » lors du transfert de données entre les appareils. En d'autres termes, le niveau supérieur s'occupe de sélectionner la composition des répliques, et le niveau inférieur de la découpe optimale du modèle pour la configuration matérielle spécifique.
Ce que cela apporte en pratique
Les auteurs ont testé l'approche par rapport à la solution de base Splitwise, qui sépare également prefill et decode, mais fonctionne de manière moins flexible avec des environnements hétérogènes. Les expériences ont montré qu'E2LLM s'adapte bien aux changements de charge de travail. Cela est particulièrement visible lorsque les longueurs des tokens d'entrée et de sortie diffèrent fortement : par exemple, des requêtes courtes arrivent, mais des réponses longues sont nécessaires, puis la charge change brusquement.
Sous forte charge, la nouvelle approche réduit le temps d'attente moyen de plus de 50 % par rapport à Splitwise. Cela signifie que les utilisateurs attendent moins souvent en file pour la génération, et que les appareils Edge/Fog eux-mêmes travaillent de manière plus réfléchie, au lieu d'essayer de servir uniformément les deux phases de l'inférence.
Conclusion
E2LLM montre que pour un lancement efficace de LLM en périphérie, ce n'est pas seulement la puissance d'un appareil individuel qui compte, mais aussi la manière dont les appareils sont regroupés et répartis en rôles. La duplication du modèle complet au niveau des répliques, combinée à la séparation prefill et decode, est un compromis assumé : il faut parfois sacrifier de la mémoire, mais en échange, le système gagne en performance stable et en latences réduites.
Le principal enseignement pour les scénarios appliqués : dans un environnement hétérogène, il ne faut pas essayer de faire tenir tout le modèle dans un seul nœud ou de le répartir uniformément sur tous. Il faut constituer des groupes spécialisés à partir du matériel disponible et décider ensuite, au sein de ces groupes, comment répartir les calculs. C'est ainsi que l'inférence LLM devient réellement pratique en dehors des grands clusters cloud.
