🤖 AI

Transferable Latency Prediction for Fast LLM Screening on Heterogeneous Edge Devices

Ce document propose un cadre de prédiction de la latence sensible à l'exécution qui fusionne de manière adaptative des descripteurs de modèles statiques avec une télémétrie matérielle dynamique afin de permettre un criblage de déploiement de LLM précis et transférable sur des appareils de bord hétérogènes avec un calibrage minimal.

Auteurs originaux : Xiaolong Tu, Vinod K. Mishra, Venkat R. Dasari, Anu G. Bourgeois, Haoxin Wang

Publié 2026-07-27

📖 9 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Xiaolong Tu, Vinod K. Mishra, Venkat R. Dasari, Anu G. Bourgeois, Haoxin Wang

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayiez de choisir le jeu vidéo parfait à jouer sur une console portable. Vous avez une immense bibliothèque de jeux, allant de minuscules aventures de réflexion aux épiques rôles-jeux tentaculaires. Mais voici le hic : votre console est un peu capricieuse. Elle chauffe si vous jouez trop longtemps, sa batterie se décharge vite, et elle gère les différents jeux de manière étrange selon la façon dont vous la tenez ou l'heure de la journée. Si vous essayez de télécharger et de tester chaque jeu pour voir lequel fonctionne sans accroc, vous passeriez la journée entière à attendre les téléchargements, pour finalement découvrir que la moitié d'entre eux plantent ou rament. Vous avez besoin d'un moyen de deviner, rien qu'en regardant la description du jeu et l'humeur actuelle de votre console, lequel fonctionnera réellement. C'est exactement le problème auquel est confronté le monde de l'intelligence artificielle sur nos téléphones et nos petits gadgets.

Des scientifiques tentent de faire fonctionner des « Large Language Models » (LLM) — des cerveaux d'IA super intelligents capables d'écrire des histoires, de répondre à des questions et de résoudre des problèmes — directement sur nos appareils plutôt que d'envoyer des données vers de gigantesques serveurs dans le cloud. C'est excellent pour la confidentialité et la vitesse, mais c'est un cauchemar à prédire. Un modèle d'IA peut fonctionner parfaitement sur un téléphone mais se figer sur un autre, même si les téléphones semblent similaires. Pourquoi ? Parce que la vitesse d'une IA dépend d'un mélange chaotique de choses : la longueur de la question, la température du téléphone, le niveau de batterie restant, et même le logiciel spécifique utilisé pour faire tourner l'IA. Si nous ne pouvons pas prédire la vitesse à laquelle une IA fonctionnera avant de l'essayer réellement, nous gaspillons énormément de temps et d'énergie à tester des modèles qui pourraient échouer. C'est là que l'histoire de la « prédiction de l'avenir » entre en jeu.

La boule de cristal pour la vitesse de l'IA

Dans cet article, une équipe de chercheurs de la Georgia State University et de l'Army Research Laboratory a construit une « boule de cristal » pour la vitesse de l'IA. Ils appellent cela un cadre de prédiction de latence conscient du temps d'exécution (runtime-aware). Décomposons cela. « Latence » est juste un mot savant pour dire combien de temps quelque chose prend pour se produire. « Conscient du temps d'exécution » signifie que le système fait attention à ce qui se passe pendant que l'IA travaille, et pas seulement à ce à quoi l'IA ressemble sur le papier. Et « transférable » signifie que cette boule de cristal fonctionne même si vous passez d'un type de dispositif à un autre.

Les chercheurs ont réalisé que tenter de tester chaque modèle d'IA sur chaque dispositif est comme essayer de goûter toutes les saveurs de crème glacée du monde pour trouver sa préférée. C'est trop lent et trop coûteux. Au lieu de cela, ils voulaient un système capable de regarder un nouvel appareil et un nouveau modèle d'IA et de dire : « Hé, ce combo prendra probablement environ 10 secondes pour répondre ».

Comment fonctionne la boule de cristal

La recette secrète de leur système est qu'il ne se contente pas de regarder les faits statiques. Imaginez que vous essayiez de deviner la vitesse d'une voiture. Une estimation « statique » regarderait simplement la taille du moteur et le poids de la voiture. Mais une estimation « consciente du temps d'exécution » vérifierait également la météo, le trafic, et si le conducteur est endormi.

Le système des chercheurs fait deux choses à la fois :

Le chemin statique : Il regarde la « carte d'identité » de la configuration. Cela inclut la taille du modèle, le type de téléphone ou de gadget, et les paramètres.
Le chemin dynamique : Il surveille le « battement de cœur » de l'appareil pendant qu'il fonctionne. Il suit des éléments tels que la chaleur du processeur, la vitesse de rotation du processeur et la quantité de mémoire utilisée.

Le système divise le travail de l'IA en deux phases, comme une course en deux parties :

La phase de Préfill (Prefill Phase) : C'est le moment où l'IA lit votre question et rassemble ses pensées. C'est généralement un sprint rapide et intense.
La phase de Décodage (Decode Phase) : C'est le moment où l'IA écrit sa réponse, mot par mot. C'est un jogging plus long et régulier.

En traitant ces deux phases séparément et en mélangeant les informations de la « carte d'identité » avec les données du « battement de cœur », le système construit une prédiction beaucoup plus intelligente. Ils ont utilisé un mécanisme spécial de « fusion par porte » (gated fusion), qui est comme un feu de signalisation intelligent qui décide s'il doit écouter davantage les faits statiques ou les conditions de circulation en direct selon la situation.

La magie de la calibration

Voici le tour le plus important : le système n'est pas parfait dès le départ. Si vous l'entraînez sur un téléphone Pixel 8 et que vous essayez de l'utiliser sur un Pixel 8 Pro, il pourrait se tromper dans les chiffres car les deux téléphones sont légèrement différents.

Pour corriger cela, les chercheurs utilisent un ensemble de calibration. Considérez cela comme un rapide « essai routier ». Vous faites fonctionner l'IA sur le nouvel appareil juste quelques fois (peut-être de 6 à 20 fois) pour voir comment elle se comporte réellement. Le système utilise ensuite ces quelques résultats réels pour ajuster sa boule de cristal, alignant ses prédictions sur la réalité du nouvel appareil.

Les résultats de cette calibration sont spectaculaires. Sans elle, les prédictions du système sur le temps de « décodage » (écriture de la réponse) sur un Pixel 8 Pro étaient totalement erronées, avec un score (appelé $R^2$ ) de -1,085. C'est un score terrible, signifiant que la prédiction était pire qu'un simple hasard. Mais après une infime calibration, ce score a bondi à 0,927, ce qui est presque parfait. C'est comme prendre une photo floue et soudainement obtenir une image nette avec own quelques ajustements.

Test du système

L'équipe a testé son idée sur une variété de gadgets pour s'assurer qu'il ne s'agissait pas d'un coup de chance pour un téléphone spécifique. Ils ont utilisé :

Pixel 8 et Pixel 8 Pro : Les stars du spectacle, représentant les téléphones mobiles modernes.
Jetson Nano : Un petit ordinateur souvent utilisé pour les robots et les drones.
Orange Pi 5 Pro : Un petit ordinateur à carte unique.
RTX 3090 : Une carte graphique puissante que l'on trouve habituellement dans les PC de gaming haut de gamme.

Ils ont découvert que le même modèle d'IA pouvait être incroyablement rapide sur la grande carte de jeu (64,38 tokens par seconde) mais douloureusement lent sur le petit Orange Pi (8,42 tokens par seconde). Cela prouve que vous ne pouvez pas simplement deviner la vitesse en se basant sur le modèle seul ; vous devez connaître le dispositif.

Pourquoi cela compte : Le processus de sélection

Le but ultime n'est pas seulement de prédire la vitesse ; c'est de gagner du temps. Imaginez que vous ayez 100 modèles d'IA différents et que vous deviez choisir le meilleur pour votre téléphone spécifique. Sans ce système, vous devriez télécharger et tester les 100 modèles. Avec ce système, vous pouvez prédire la vitesse des 100 instantanément.

Les chercheurs utilisent ensuite une stratégie appelée optimisation de Pareto. C'est une façon sophistiquée de dire qu'ils cherchent le « point d'équilibre ». Ils veulent un modèle qui est à la fois rapide et intelligent. Si le Modèle A est plus lent que le Modèle B mais pas plus intelligent, le Modèle A est inutile. Le système filtre les mauvaises options et vous laisse une liste courte des meilleurs candidats à tester réellement.

Dans leurs tests, ce processus de sélection a réussi à maintenir les meilleurs modèles en lice. Par exemple, lors du passage d'un Pixel 8 Pro à un Pixel 8, le système a filtré la moitié des candidats mais a garanti que le meilleur d'entre eux était toujours présent.

Ce qu'ils ont trouvé (et ce qu'ils n'ont pas trouvé)

L'article suggère que cette méthode est un outil puissant pour rendre le déploiement de l'IA plus rapide et moins coûteux. Ils ont constaté que :

Les estimations statiques ne suffisent pas : Connaître la taille du modèle ne suffit pas pour savoir à quelle vitesse il fonctionnera sur un téléphone spécifique.
La calibration est la clé : On ne peut pas simplement copier-coller une prédiction d'un appareil à un autre ; il faut un peu de données réelles pour corriger la prédiction.
La phase est importante : Traiter la partie « lecture » et la partie « écriture » de l'IA différemment rend la prédiction beaucoup plus précise.

Cependant, les auteurs précisent avec prudence qu'il s'agit d'un point de départ. Leurs meilleurs résultats proviennent des téléphones Pixel, et bien qu'ils aient montré que leur système pouvait fonctionner sur d'autres appareils comme le Jetson et l'Orange Pi, ils n'ont pas encore effectué d'entraînement approfondi sur ces derniers. Ils ont également noté que parfois, sur les ordinateurs puissants, les petits modèles ne sont pas toujours plus rapides que les grands, une bizarrerie que leur système aide à expliquer.

En résumé, cet article propose une manière ingénieuse et flexible de deviner la vitesse à laquelle une IA fonctionnera sur votre gadget sans avoir à attendre des heures pour le savoir. Cela transforme un jeu de devinettes chaotique en une décision calculée et basée sur les données, nous aidant à obtenir les meilleures expériences d'IA sur nos appareils sans épuiser notre temps ou notre batterie.

Résumé technique : Prédiction de la latence transférable pour le filtrage rapide des LLM sur des dispositifs edge hétérogènes

Énoncé du problème

Le déploiement de modèles de langage de grande taille (LLM) sur des dispositifs edge hétérogènes (par exemple, téléphones mobiles, ordinateurs monocartes, GPU embarqués) est de plus en plus crucial pour les applications à faible latence, respectueuses de la vie privée et contraintes par la connectivité. Cependant, déterminer quel modèle est adapté à un dispositif spécifique sous des exigences de déploiement particulières reste un goulot d'étranglement systémique important.

Le défi central est que la latence d'inférence des LLM n'est pas déterminée uniquement par l'architecture statique du modèle ou les capacités matérielles. Au contraire, il s'agit d'une fonction complexe de :

Facteurs statiques : Architecture du modèle, échelle des paramètres, format de quantification et spécifications matérielles.
Facteurs dynamiques : Longueur du prompt, comportement de génération des tokens, régulation de la tension et de la fréquence (DVFS), utilisation du matériel, pression mémoire et étranglement thermique (thermal throttling).
Phases d'exécution : L'inférence des LLM se compose de phases distinctes de prefill (traitement du prompt et construction du cache KV) et de decode (génération autoregressive de tokens), qui présentent des caractitudes de latence et des comportements matériels différents.

Une solution directe — tester de manière exhaustive chaque modèle candidat sur chaque dispositif cible — est prohibitivement coûteuse en raison des coûts de configuration de l'exécution, de conversion du modèle, d'exécution et de collecte de télémétrie. Les prédicteurs de latence existants reposent souvent uniquement sur des caractéristiques statiques, échouant à capturer les comportements d'exécution spécifiques à la plateforme, les effets d'ordonnancement et les différences d'exécution dépendantes du backend. Par conséquent, il est nécessaire d'avoir un cadre de prédiction sensible au runtime et transférable capable de filtrer les modèles candidats avant l'exécution coûteuse sur le dispositif cible.

Méthodologie

L'article propose un cadre de prédiction de latence sensible au runtime conçu pour la sélection de LLM orientée vers le déploiement dans des environnements hétérogènes. Le système fonctionne via quatre étapes principales :

1. Représentation de la configuration

Chaque requête d'inférence est modélisée comme un tuple de configuration $c = (m, d, r, p)$ , où :

$m$ : Modèle préentraîné (famille, taille, quantification).
$d$ : Dispositif (profil matériel, capacités de télémétrie).
$r$ : Backend de runtime et paramètres de plateforme (par exemple, MLC-LLM, PyTorch, CPU/GPU/NPU).
$p$ : Configuration du prompt/tâche (longueur d'entrée, longueur maximale de génération).

2. Architecture du prédicteur à double voie

Le cadre utilise un prédicteur transférable doté de deux branches complémentaires fusionnées via un mécanisme de porte (gating) :

Voie statique : Encode les descripteurs stables (profil du dispositif, descripteur du modèle, configuration de déploiement) en un embedding statique ( $S$ ). Cela capture la compatibilité attendue avant l'exécution.
Voie dynamique : Traite les traces de télémétrie du runtime collectées lors du profilage. Crucialement, elle applique une modélisation sensible aux phases :
- Les traces de prefill sont alignées sous un temps de phase normalisé pour reconstruire les états matériels épars et par rafales (bursty).
- Les traces de decode préservent l'ordre temporel pour capturer le comportement autoregressif.
- Un encodeur temporel agrège ces éléments en un embedding dynamique ( $D$ ).
Fusion par porte (Gated Fusion) : Un réseau de porte léger calcule des poids adaptatifs ( $w_s, w_d$ ) pour fusionner $S$ et $D$ . Cela permet au modèle de s'appuyer davantage sur les informations statiques lorsque les configurations sont stables et davantage sur les données dynamiques lorsque les variations de runtime dominent.
Tête de régression : Produit la prédiction de la latence de prefill, de la latence de decode et de la latence totale.

3. Transfert et calibration

Pour gérer le déploiement inter-dispositifs, le système utilise un ensemble de calibration. Un petit nombre d'exécutions sur le dispositif cible sont mesurées pour corriger les biais spécifiques au dispositif. Cela aligne le prédicteur entraîné sur la source avec l'échelle de latence et le régime de fonctionnement du dispositif cible sans nécessiter un profilage exhaustif.

4. Filtrage basé sur Pareto

La latence prédite est combinée avec la précision du modèle (ou la qualité de la tâche) pour effectuer une optimisation de Pareto. Le système élimine les candidats dominés (ceux ayant une moins bonne latence et une qualité inférieure) afin d'identifier un ensemble compact de modèles Pareto-optimaux, équilibrant réactivité et qualité de sortie.

Contributions clés

Formulation : Définition de la prédiction de la latence des LLM comme un problème de configuration matériel-runtime-modèle-prompt, permettant la prédiction sur divers dispositifs, modèles, prompts et backends.
Architecture : Proposition d'un prédicteur transférable sensible au runtime qui intègre des descripteurs statiques et de la télémétrie dynamique, sépare les comportements de prefill/decode via une modélisation sensible aux phases, et utilise une fusion par porte pour une combinaison adaptative des embeddings.
Flux de travail : Conception d'un flux de travail de filtrage orienté déploiement qui utilise des prédictions calibrées pour filtrer les candidats avant l'exécution sur le dispositif cible, supportant l'analyse des compromis latence-qualité.
Validation : Construction et évaluation d'un pipeline de profilage multiplateforme sur des dispositifs mobiles Pixel, Jetson Nano, Orange Pi 5 Pro et un GPU de classe RTX 3090, validant la précision de la prédiction mobile et la couverture du profilage hétérogène.

Résultats expérimentaux

Le cadre a été évalué sur des appareils Pixel 8 et Pixel 8 Pro, avec une validation de profilage sur du matériel Jetson Nano, Orange Pi 5 Pro et de classe RTX 3090.

Prédiction intra-dispositif : Sur Pixel 8, le prédicteur complet a amélioré le $R^2$ de la latence totale de 0,953 à 0,960 et le $R^2$ de la latence de decode de 0,957 à 0,973 par rapport à une base de référence uniquement statique. Sur Pixel 8 Pro, il a considérablement amélioré le $R^2$ de la latence de prefill de -1,383 à 0,966.
Transfert inter-dispositifs : La calibration s'est révélée essentielle. Sans elle, les valeurs de $R^2$ de transfert étaient souvent négatives (ex: -0,974 pour le passage de Pixel 8 Pro $\to$ latence totale de Pixel 8). Avec la calibration, le $R^2$ est passé à 0,940.
Profilage hétérogène : Les résultats ont confirmé que la latence dépend fortement du dispositif et du runtime. Par exemple, le modèle SmolLM2-1.7B a atteint 64,38 tokens/s sur un GPU de classe RTX 3090 mais seulement 8,42 tokens/s sur un Orange Pi 5 Pro. De plus, sur l'RTX 3090, les modèles plus petits n'étaient pas toujours plus rapides, indiquant que l'overhead des kernels et le comportement de la mémoire peuvent dominer l'échelle du nombre de paramètres.
Études d'ablation : Ont confirmé que les descripteurs statiques seuls sont insuffisants pour le transfert inter-dispositifs et que la calibration est le facteur le plus critique pour stabiliser les prédictions. La modélisation sensible aux phases a apporté des bénéfices clairs pour la prédiction de la latence de prefill.
Efficacité du filtrage : Le prédicteur a réussi à réduire l'ensemble des modèles candidats (ratios de filtrage de 0,333 et 0,500 dans les scénarios testés) tout en préservant les meilleurs modèles réalisables.

Signification et revendications

L'article affirme qu'une prédiction sensible au runtime avec une calibration légère peut réduire considérablement le coût du profilage et soutenir le déploiement de LLM sensibles à la latence sur des plateformes edge hétérogènes.

Impact pratique : Le cadre résout le "goulot d'étranglement systémique" de la sélection de modèles en remplaçant le benchmarking exhaustif par un processus de filtrage prédictif.
Nécessité de la dynamique : Les résultats démontent que les modèles statiques seuls ne peuvent capturer l'interaction complexe entre le DVFS, l'étranglement thermique et l'ordonnancement du runtime qui dicte les performances des dispositifs edge.
Transférabilité : Le système démontre qu'un prédicteur entraîné sur des dispositifs sources peut se généraliser efficacement à des dispositifs cibles, à condition d'utiliser un petit ensemble de calibration pour aligner les échelles de latence.
Boucle de déploiement : Ce travail cadre la prédiction de latence non pas comme une tâche de régression isolée, mais comme une composante d'un système de déploiement en boucle fermée qui améliore itérativement les décisions avec des mesures limitées.

Les auteurs notent des limites, notamment le fait que les résultats de prédiction les plus complets sont basés sur le jeu de données mobile Pixel, tandis que les autres plateformes ont servi principalement à la validation du profilage. Les travaux futurs visent à étendre ce cadre pour considérer conjointement le débit (throughput), la mémoire et l'énergie en plus de la latence.