ARPL veut que llama.cpp cesse de traiter tous les téléphones ARM de la même manière

ARPL a publié une implémentation de référence Android qui remet en question une hypothèse fondamentale des déploiements mobiles de llama.cpp. Jusqu’à présent, de nombreuses configurations ont traité des téléphones ARM pourtant très différents presque de la même façon.

Le projet lit les capacités du processeur et la topologie des cœurs à l’exécution. Il recommande ensuite des réglages de threads et corrige certains paramètres de contexte de llama.cpp. L’objectif est de proposer une seule build d’application qui s’adapte au téléphone sur lequel elle s’exécute.

Cette affirmation est importante, car le matériel Android varie bien au-delà de son étiquette commune ARM64. Un Snapdragon 8 Elite et un processeur milieu de gamme plus ancien exposent des instructions, des agencements de cœurs, des limites mémoire et des voies d’accélération différents.

Le développeur indique qu’ARPL détecte la prise en charge de SDOT, I8MM et SME2, puis ajuste l’exécution en fonction du matériel détecté. Il prend également en compte flash attention et la quantification du cache clé-valeur lors de la préparation du contexte llama.cpp.

Il ne s’agit toutefois ni d’une fonctionnalité intégrée en amont à llama.cpp, ni d’une étude de performances évaluée indépendamment. Le post public d’ARPL décrit une démonstration non commerciale testée sur une variante du Samsung Galaxy S25 Ultra.

Cette distinction définit le sujet. ARPL propose une couche d’adaptation à l’exécution plausible, tandis que les preuves nécessaires pour valider ses recommandations restent limitées.

ARPL déplace l’ajustement aux appareils vers l’exécution

Le changement central d’ARPL est simple : inspecter d’abord le téléphone, puis configurer llama.cpp au lieu d’appliquer partout un même préréglage.

La version publique inclut une application de référence Android conçue avec Kotlin et Jetpack Compose. Un pont Java Native Interface relie cette couche applicative au code natif C et C++ de llama.cpp.

Selon son développeur, ARPL remplit trois fonctions liées. Il détecte les extensions disponibles du jeu d’instructions, analyse la topologie CPU et modifie certains paramètres d’inférence.

Les extensions de l’architecture du jeu d’instructions ajoutent des opérations spécialisées au-delà du jeu d’instructions ARM64 de base. Pour les modèles de langage locaux, ces opérations peuvent accélérer les calculs matriciels et entiers courants.

SDOT fournit des instructions de produit scalaire signé qui peuvent faciliter le traitement de valeurs quantifiées. I8MM ajoute des opérations de multiplication matricielle entière conçues pour les charges de travail utilisant des données sur huit bits.

SME2 étend Scalable Matrix Extension d’Arm avec des capacités supplémentaires orientées matrices. Sa prise en charge ne peut pas être supposée de manière fiable au seul motif qu’une application s’exécute sur un système d’exploitation ARM64 moderne.

ARPL interrogerait des masques de bits HWCAP, que le système d’exploitation expose pour décrire les capacités du processeur. Android recommande officiellement getauxval() avec AT_HWCAP et AT_HWCAP2 pour ce type d’inspection à l’exécution.

Le guide sur les fonctionnalités CPU explique également une limite importante. Certains appareils plus anciens ont signalé leurs capacités de manière incorrecte, de sorte qu’un indicateur retourné ne constitue pas une garantie absolue.

Google maintient une bibliothèque distincte de fonctionnalités CPU comprenant des contournements spécifiques aux appareils pour des erreurs de signalement connues. Cet historique montre pourquoi la détection à l’exécution exige des vérifications défensives et des tests sur appareils réels.

La deuxième entrée d’ARPL est la topologie CPU. Les processeurs mobiles répartissent couramment les cœurs en clusters aux caractéristiques différentes de performances, d’efficacité, de fréquence et de comportement thermique.

Un simple nombre de cœurs ne rend pas compte de ces différences. Attribuer du travail à tous les cœurs en ligne peut créer une surcharge d’ordonnancement ou intégrer des cœurs plus lents dans une opération sensible à la latence.

La version publiée recommande donc un nombre de threads basé sur les clusters détectés plutôt que sur les seuls cœurs logiques totaux. Cette recommandation est transmise à llama.cpp via le pont natif.

La troisième fonction concerne la configuration du contexte. Le développeur affirme qu’ARPL peut corriger les réglages de flash attention et de quantification du cache KV en fonction du matériel disponible.

Flash attention réorganise le calcul de l’attention afin de réduire le trafic mémoire. Le cache KV stocke les clés et valeurs d’attention générées pour les tokens précédents, évitant des calculs répétés pendant la génération.

La quantification de ce cache peut réduire l’usage mémoire, mais la prise en charge par les backends et les compromis de qualité varient. Une configuration qui économise de la mémoire sur une voie d’exécution peut échouer ou ralentir une autre.

ARPL tente de placer ces choix derrière une politique tenant compte du matériel. Le développeur d’application demanderait une configuration adaptée plutôt que de maintenir une liste croissante de préréglages par appareil.

Cela change l’emplacement de la logique d’optimisation. Les indicateurs de compilation déterminent toujours quels kernels existent, mais la détection à l’exécution décide quelles voies disponibles paraissent appropriées pour le téléphone actuel.

ARPL n’ajoute pas comme par magie des instructions non prises en charge à un binaire existant. L’implémentation concernée doit déjà contenir des chemins de code compatibles et préserver une base sûre.

Cette distinction est essentielle. La détection peut sélectionner une capacité, mais elle ne peut pas remplacer les kernels, la prise en charge du compilateur, l’intégration du backend ou les tests de correction requis pour utiliser cette capacité.

Les téléphones ARM partagent une ABI, pas un profil de performances

La pression s’exerce sur les développeurs qui veulent un seul package Android sans accepter une unique configuration limitée au plus petit dénominateur commun.

L’interface binaire d’application ARM64 d’Android permet aux logiciels de cibler une vaste famille d’appareils. Cette couche de compatibilité simplifie la distribution, mais elle ne rend pas les systèmes sous-jacents uniformes.

Le système d’exploitation peut signaler le nombre de processeurs configurés et en ligne. Ces totaux ne disent pourtant presque rien des limites entre clusters, des relations de cache, de la fréquence soutenue ou du coût des passages entre clusters.

Le comportement thermique des appareils mobiles complique encore un réglage fixe du nombre de threads. Une configuration qui domine un benchmark court peut perdre en performances une fois l’appareil chauffé.

Les tâches d’arrière-plan, les politiques d’ordonnancement des fabricants, l’état de la batterie et la conception du refroidissement influencent également les résultats. Deux téléphones utilisant le même processeur peuvent donc se comporter différemment en inférence soutenue.

Le Snapdragon 8 Elite rend ce problème visible, car il associe le CPU Oryon de Qualcomm, les graphismes Adreno et l’accélération Hexagon. Chaque voie présente des contraintes d’intégration et de mémoire différentes.

llama.cpp documente désormais des options CPU, Adreno OpenCL et Hexagon pour les appareils Snapdragon. Son backend Snapdragon décrit toujours la voie Hexagon comme expérimentale.

Ce travail plus large sur les backends est distinct d’ARPL. Il montre que l’optimisation mobile dépasse la sélection d’une instruction CPU ou le comptage des cœurs.

Une application doit décider où s’exécutent les couches du modèle, quels formats mémoire chaque backend accepte et si les transferts de données annulent les gains théoriques d’accélération.

La version actuelle d’ARPL ne traite qu’une partie de ce système. Son développeur précise explicitement que le partitionnement hétérogène entre CPU, GPU et NPU est toujours en cours.

La version disponible se concentre plutôt sur la détection des instructions, les recommandations de threads CPU et les paramètres de contexte. Cette portée plus restreinte rend le projet plus facile à évaluer.

Elle évite aussi une conclusion trompeuse. ARPL n’est pas actuellement un ordonnanceur automatique qui répartit un modèle de langage sur tous les moteurs de calcul Snapdragon.

Sa valeur à court terme réside dans la réduction des incompatibilités évidentes. Un téléphone ancien ne devrait pas hériter d’hypothèses conçues pour un processeur plus récent doté d’instructions et de cœurs différents.

À l’inverse, un fleuron récent ne devrait pas toujours être limité à la configuration la plus sûre exigée par le plus ancien appareil pris en charge.

Les développeurs résolvent déjà ce problème au moyen de variantes de build, de listes d’appareils autorisés, de scripts de benchmark et de menus de configuration. Chaque approche a un coût.

Les variantes de build augmentent la complexité du packaging et des tests. Les listes d’autorisation vieillissent vite, notamment lorsque les fabricants commercialisent des modèles régionaux ou modifient le comportement thermique via des mises à jour logicielles.

Les contrôles manuels exposent une complexité aux utilisateurs, qui manquent souvent d’informations pour faire un choix éclairé. Les réglages par défaut statiques évitent cette charge, mais laissent des performances ou de la capacité mémoire inutilisées.

L’adaptation à l’exécution offre une autre voie. Un package peut collecter des signaux, sélectionner une politique prudente et conserver des solutions de repli lorsqu’une optimisation échoue.

Cette approche s’apparente à la négociation de capacités dans d’autres domaines des logiciels systèmes. Le programme demande ce que l’environnement prend en charge avant de s’engager dans une voie d’exécution spécialisée.

Pourtant, l’ajustement de l’inférence est plus difficile que de vérifier l’existence d’une instruction. La meilleure configuration dépend du modèle, de la longueur du prompt, de l’allocation du contexte, du backend et de la phase de la charge de travail.

Le traitement du prompt effectue un volume important de calculs parallèles sur les tokens d’entrée. La génération autorégressive produit les tokens séquentiellement et peut réagir différemment au nombre de threads ou au déport de calcul.

Un réglage qui améliore l’ingestion du prompt peut réduire la vitesse de génération. La meilleure réponse peut également changer à mesure que le contexte s’allonge et que le cache KV consomme davantage de mémoire.

Cela signifie que la politique d’ARPL a besoin de plus que de faits matériels. À terme, elle devra prendre des décisions tenant compte de la charge de travail ou proposer des réglages par défaut soigneusement choisis, qui se comportent correctement dans les cas courants.

Le projet met sous pression la configuration statique, car il révèle la quantité d’informations que ces préréglages ignorent. Il ne prouve pas encore qu’une politique unique à l’exécution puisse choisir systématiquement l’optimum.

Pourquoi davantage de threads peut ralentir llama.cpp

L’argument le plus solide d’ARPL est que les performances d’inférence mobile dépendent de la topologie, et non du plus grand nombre de threads signalé par un appareil.

Un CPU hétérogène ne se comporte pas comme un ensemble de travailleurs interchangeables. Les cœurs peuvent différer en fréquence, en accès au cache, en efficacité et en proximité avec d’autres ressources de calcul.

Ajouter un thread peut accroître le travail parallèle, mais cela ajoute aussi de la coordination. Les threads peuvent se disputer la bande passante mémoire, migrer entre les cœurs ou attendre un travail achevé sur un autre cluster.

L’inférence de modèles de langage sollicite fréquemment les mouvements de mémoire. Les poids quantifiés réduisent le stockage, mais le processeur doit toujours lire, décompacter et combiner de grands volumes de données.

Dès que la bande passante mémoire devient le facteur limitant, des threads supplémentaires ne garantissent pas un débit plus élevé. Ils peuvent ajouter de la surcharge sans fournir davantage de données utiles aux unités arithmétiques.

Des expériences communautaires illustrent ce problème, même si elles ne valident pas ARPL lui-même. Un test sur Snapdragon 8 Elite a utilisé le backend Adreno OpenCL de llama.cpp et comparé plusieurs configurations de threads CPU.

Le testeur a d’abord décrit six threads de cœurs de performance comme optimaux. Des mesures plus systématiques ont ensuite placé quatre threads épinglés légèrement devant durant la génération de tokens.

Dans l’expérience rapportée, quatre threads ont atteint 31,4 tokens par seconde lors d’un test de génération de 128 tokens. Six threads ont atteint 30,5 tokens par seconde avec une variation plus élevée.

Ces chiffres s’appliquent uniquement à cet appareil, ce modèle, cette build, ce pilote et cette configuration. Les mesures de threading restent des résultats communautaires plutôt que des tests indépendants standardisés.

Néanmoins, l’évolution de la propre conclusion du testeur soutient le postulat d’ARPL. Une configuration plausible peut cesser de paraître optimale lorsque les mesures incluent d’autres agencements de clusters.

Elle met aussi en évidence un risque pour les recommandations automatiques. Lire la topologie décrit le processeur, mais ne mesure pas directement la meilleure politique d’ordonnancement.

ARPL doit traduire des faits tels que l’appartenance à un cluster et les instructions disponibles en une recommandation de threads. C’est dans cette traduction que le jugement d’ingénierie intervient.

Une politique pourrait favoriser les cœurs hautes performances et éviter les cœurs économes pendant la génération interactive. Une autre pourrait utiliser davantage de cœurs pour le traitement du prompt, puis réduire le nombre de threads pour la génération.

Les conditions thermiques peuvent inverser ces préférences lors de sessions prolongées. Un téléphone mieux refroidi peut maintenir une configuration qui subit rapidement du throttling sur un appareil plus fin.

La planification Android limite également le contrôle qu’une application peut exercer sur le placement. L’affinité des threads peut orienter l’exécution, mais les politiques du système d’exploitation et les restrictions de l’appareil restent déterminantes.

Le benchmarking à l’exécution pourrait fournir un autre signal. Un court test de calibration pourrait comparer les configurations sur l’appareil réel avant d’en sélectionner une.

Cependant, la calibration retarde le démarrage, consomme de l’énergie et risque d’optimiser pour un test synthétique. Les résultats mis en cache peuvent devenir obsolètes après des mises à jour du système d’exploitation ou de l’application.

Une recommandation fondée sur des règles est plus rapide et plus prévisible. Elle exige également une vaste matrice de tests d’appareils pour démontrer que ses règles se généralisent.

C’est le mécanisme au cœur d’ARPL. La détection recueille des informations fiables, tandis que la politique transforme ces informations en réglages ayant des conséquences sur les performances.

La première partie s’appuie sur des interfaces Android établies. La seconde reste le composant du projet le moins vérifié de manière indépendante.

Cette séparation offre aux développeurs une manière utile d’évaluer le dépôt. Ils peuvent juger la précision de la détection sans accepter toutes les recommandations de réglage.

Ils peuvent également consigner la configuration choisie par ARPL à côté des résultats de benchmark. Cela révélerait si une recommandation améliore la vitesse de traitement des prompts, la vitesse de génération, l’utilisation mémoire et le comportement thermique durable.

Cette instrumentation compte davantage qu’un résultat phare isolé. Un tuner à l’exécution gagne la confiance lorsque ses choix restent explicables et réversibles.

Le réglage du contexte est l’endroit où les risques se cumulent

La sélection des threads est relativement circonscrite, mais les changements automatiques apportés au flash attention et aux formats de cache KV peuvent affecter la compatibilité, la mémoire et la qualité des sorties.

Le projet llama.cpp prend en charge de nombreux backends matériels. Sa documentation de compilation Android couvre la compilation native, tandis que la prise en charge plus large des fonctionnalités diffère selon les chemins CPU et accélérateurs.

Le guide de compilation Android confirme que les développeurs peuvent compiler le projet avec l’Android NDK. Il ne promet pas un comportement identique sur tous les téléphones.

Le flash attention peut réduire le trafic mémoire en calculant l’attention au moyen d’opérations par tuiles. Son intérêt dépend du backend, des formats de données pris en charge, de la longueur de séquence et des kernels disponibles.

La quantification du cache KV réduit la mémoire utilisée pour les clés et valeurs stockées. Cette économie peut permettre un contexte plus long ou laisser davantage de mémoire aux poids du modèle.

Elle peut aussi introduire du travail de déquantification et des changements numériques. Certaines combinaisons de formats exigent des kernels spécialisés, tandis que les combinaisons non prises en charge peuvent basculer vers une solution de repli ou échouer.

La matrice de fonctionnalités publique de llama.cpp répertorie le flash attention et la quantification du cache pour les principaux backends. La matrice montre également des domaines partiels ou incertains.

Cette surface de prise en charge mouvante crée une pression de versionnement pour ARPL. Une recommandation correcte pour une révision de llama.cpp peut devenir inutile ou incompatible après une modification en amont.

Les différences entre backends rendent les règles globales particulièrement dangereuses. Les chemins CPU, Vulkan, OpenCL et Hexagon ne prennent pas nécessairement en charge les mêmes types de cache ni les mêmes implémentations de l’attention.

Une expérimentation OpenCL de 2026 sur un Snapdragon 8 Elite a signalé l’ajout de chemins de cache quantifié à un fork Adreno. Son auteur a présenté ce travail comme une expérimentation plutôt que comme une contribution finalisée.

Pour un contexte de 64K dans cette configuration, le cache KV F16 signalé utilisait 1 054 MiB. Q4_0 et IQ4_NL auraient chacun utilisé 296 MiB.

Le même auteur a averti que les tests portaient sur des prompts simples, et non sur une évaluation rigoureuse de la précision en contexte long. L’expérimentation de cache quantifié démontre donc un potentiel, et non une fiabilité générale.

Elle montre aussi pourquoi une politique automatique est attrayante. Les utilisateurs ne devraient pas avoir à comprendre les kernels de backend simplement pour choisir un format de cache adapté à leur téléphone.

Cependant, masquer la complexité ne l’élimine pas. ARPL doit connaître le backend actif, les opérations prises en charge, l’architecture du modèle, la mémoire disponible et le contexte demandé.

Les seuls indicateurs d’ISA matériels ne peuvent pas répondre à toutes ces questions. Un processeur peut prendre en charge une instruction alors que le backend llama.cpp sélectionné ne l’utilise jamais.

De même, un téléphone peut exposer un GPU capable alors que son pilote, sa version d’Android ou son comportement mémoire rend un chemin spécifique peu fiable.

La description publique ne fournit pas de méthodologie complète de benchmark, de matrice d’appareils ni de spécification de gestion des échecs. Elle indique que les tests ont été effectués sur un Samsung S25 Ultra, modèle SM-S938B.

Un seul téléphone testé ne peut pas établir la compatibilité entre les appareils Snapdragon 8 Elite, encore moins avec les processeurs Qualcomm, MediaTek, Samsung ou Google plus anciens.

La licence PolyForm Noncommercial ajoute une autre contrainte. Elle autorise l’inspection et l’utilisation non commerciale selon ses termes, mais ne constitue pas une licence open source permissive classique.

Les équipes développant des applications commerciales devraient examiner ces termes avant d’intégrer le code. Elles pourraient à la place étudier l’approche et implémenter une couche de politique distincte.

La relation du dépôt avec l’amont reste également incertaine d’après l’annonce. Aucun élément ne prouve que les mainteneurs de llama.cpp ont adopté l’interface ou les recommandations d’ARPL.

Cela ne diminue pas sa valeur en tant que prototype. Cela limite en revanche la confiance avec laquelle les développeurs devraient considérer ses valeurs par défaut comme faisant partie de la plateforme llama.cpp.

Une intégration prudente rendrait chaque optimisation observable. Les journaux devraient enregistrer les fonctionnalités détectées, les threads choisis, les formats de cache, l’état du flash attention et les événements de repli.

Elle devrait aussi proposer un mode sécurisé qui désactive les changements de politique. Les utilisateurs et testeurs ont besoin d’une référence pour diagnostiquer les crashs, régressions ou sorties inattendues.

Enfin, les recommandations devraient être versionnées. Une politique liée à une révision précise de llama.cpp est plus facile à reproduire qu’une configuration silencieuse qui évolue au fil des mises à jour.

La promesse d’ARPL est l’automatisation sans réglage par appareil. Son défi immédiat consiste à prouver que cette automatisation reste prudente lorsque les informations sont incomplètes.

La détection à l’exécution s’oppose aux préréglages statiques d’appareils

Le principal affrontement n’oppose pas ARPL à une autre entreprise ; il oppose la détection des capacités à l’exécution à une configuration statique propre à chaque appareil.

Les préréglages statiques présentent un avantage majeur. Les développeurs peuvent évaluer un appareil connu, approuver une configuration et livrer exactement cette configuration.

Pour un parc matériel limité, cette approche peut être efficace. Une application d’entreprise déployée sur plusieurs appareils gérés peut ne pas nécessiter de politique générale à l’exécution.

Les préréglages facilitent également la reproduction des régressions. Les testeurs savent quels réglages doivent apparaître sur chaque téléphone pris en charge.

Leur faiblesse réside dans la maintenance. Les modèles Android se multiplient rapidement, les variantes régionales diffèrent et les mises à jour système peuvent modifier les pilotes ou le comportement de planification.

Le nom d’un appareil est aussi un indicateur imparfait de ses capacités. Des produits différents peuvent partager le même silicium, tandis que des produits aux noms marketing similaires peuvent contenir des composants différents.

La détection des capacités évite ce problème de nommage. Elle demande au système d’exploitation quelles fonctionnalités sont disponibles au lieu de les déduire d’une étiquette de modèle.

Cela donne à la détection à l’exécution une base plus solide pour la sélection de l’ISA. Cela réduit également la nécessité de mettre à jour une liste d’autorisation chaque fois qu’un nouveau téléphone apparaît.

La détection de topologie suit la même logique, mais exige davantage d’interprétation. Les informations de cluster décrivent une structure, tandis qu’une recommandation utile de threads dépend du comportement observé de la charge de travail.

Le réglage statique peut encoder ces observations pour chaque appareil testé. ARPL tente de les généraliser sous forme de règles qui fonctionnent avant qu’un appareil ne reçoive une attention individuelle.

Le meilleur système de production pourrait combiner les deux méthodes. La détection à l’exécution peut fournir le réglage par défaut, tandis que des dérogations vérifiées par appareil gèrent les exceptions connues.

Un tel système de dérogations n’invaliderait pas l’idée d’ARPL. Il reconnaîtrait que les rapports matériels Android et les comportements de performance comportent des cas limites.

Les propres recommandations de Google sur les fonctionnalités CPU vont dans le sens de ce modèle hybride. L’inspection HWCAP standard fournit le signal de base, tandis que les connaissances propres à l’appareil traitent les rapports erronés.

Une autre voie concurrente déplace l’exécution hors du CPU. Qualcomm et des contributeurs de llama.cpp développent des backends Adreno et Hexagon qui ciblent des processeurs spécialisés.

Le CPU Oryon de Qualcomm reste important, car certaines opérations de modèle restent sur le CPU. Le repli sur CPU fournit également une voie largement disponible lorsque les accélérateurs échouent.

Toutefois, un futur ordonnanceur qui répartirait le travail entre CPU, GPU et NPU ferait du nombre de threads une seule partie d’une décision plus vaste.

Le développeur d’ARPL identifie déjà le partitionnement hétérogène comme un travail inachevé. Cet aveu limite à juste titre les attentes envers la version actuelle.

Les propres outils de Qualcomm offrent une autre voie aux développeurs ciblant son matériel. GenieX, AI Hub et Qualcomm AI Runtime utilisent une intégration davantage spécifique au fournisseur.

llama.cpp répond à un objectif différent : l’inférence locale portable sur de nombreux systèmes et backends. ARPL cherche à préserver cette portabilité tout en extrayant davantage d’informations propres à l’appareil.

Cela crée un compromis persistant. Les runtimes de fournisseurs peuvent exposer des capacités spécialisées, tandis que les runtimes portables bénéficient de formats communs et d’une portée matérielle plus large.

ARPL se situe entre ces deux voies. Il conserve llama.cpp comme moteur d’inférence, mais fournit une couche adaptative conçue pour les téléphones ARM.

Cette position devient utile si la politique reste transparente. Un tuner opaque reproduirait l’opacité que les développeurs rencontrent souvent dans les piles de fournisseurs.

Un moteur de recommandation lisible peut au contraire documenter pourquoi un réglage a changé. Il peut également permettre aux mainteneurs en amont de contester les hypothèses à l’aide de données de benchmark.

La publication publique du projet crée un lieu concret pour cette discussion. Avant son adoption, il a besoin de contributions provenant d’appareils autres qu’un unique modèle phare Samsung.

Trois tests détermineront si ARPL se généralise

ARPL a désormais besoin de preuves que les capacités qu’il détecte conduisent à de meilleures décisions sur différents appareils, charges de travail et révisions de llama.cpp.

Le premier signal est une suite de benchmarks reproductible sur plusieurs appareils. Elle devrait inclure des modèles phares actuels, d’anciens téléphones haut de gamme et des processeurs de milieu de gamme de plusieurs fournisseurs.

Chaque appareil devrait comparer une référence llama.cpp neutre avec la recommandation d’ARPL. Les tests devraient rapporter le traitement des prompts, la génération de tokens, l’utilisation mémoire, l’énergie et le comportement thermique durable.

La suite doit séparer l’exécution CPU seule des chemins OpenCL, Vulkan et Hexagon. Mélanger les backends masquerait si les gains proviennent du réglage de topologie ou des changements d’accélérateur.

Les résultats devraient également inclure la variance entre exécutions répétées. Une légère amélioration moyenne importe moins lorsque la latence devient instable ou que le téléphone subit rapidement du throttling.

Si ARPL surpasse systématiquement des valeurs par défaut raisonnables sur cette matrice, sa politique générale gagnera en crédibilité. Des exceptions fréquentes soutiendraient une conception hybride avec des dérogations testées.

Le deuxième signal est le suivi de compatibilité avec llama.cpp en amont. Le projet évolue rapidement, notamment au niveau de la prise en charge des backends, des structures de contexte et des implémentations de cache.

ARPL a besoin de tests automatisés sur des révisions identifiées de llama.cpp. Ces tests devraient détecter lorsqu’un patch cible un paramètre supprimé ou sélectionne un format non pris en charge.

Une discussion en amont ou une interface acceptée renforcerait l’orientation du projet. Cela indiquerait que les mainteneurs considèrent la politique à l’exécution comme un problème partagé.

L'absence d'adoption en amont ne discréditerait pas automatiquement ARPL. Elle signifierait que les équipes applicatives devraient elles-mêmes assumer davantage de responsabilités d'intégration et de régression.

Le troisième signal concerne les progrès en matière de planification hétérogène. Un prototype utile devrait montrer comment les données de topologie CPU interagissent avec le déport des calculs vers le GPU ou le NPU.

Ce travail doit mesurer les transferts et la synchronisation, et non se contenter de confirmer que chaque processeur peut exécuter une opération de modèle. L'accélération mobile peut perdre de son intérêt lorsque les coûts de coordination deviennent prépondérants.

Une gestion claire des échecs sera tout aussi importante. Un ordonnanceur devrait prévoir un repli de manière prévisible lorsqu'un pilote rejette une opération ou qu'une allocation mémoire échoue.

Si ARPL produit ces trois signaux, il deviendra plus qu'une démonstration intéressante du Snapdragon 8 Elite. Il proposerait une architecture testable pour l'inférence Android adaptative.

Si les éléments disponibles restent limités à un seul téléphone et à des améliorations rapportées par les développeurs, les équipes devraient le considérer comme du code de recherche. Les techniques de détection pourraient néanmoins éclairer leurs propres implémentations.

Pour les développeurs qui évaluent cette publication aujourd'hui, l'étape pratique suivante consiste à effectuer une comparaison contrôlée. Consignez les paramètres retenus, conservez une référence fixe et testez les charges de travail réellement exécutées par les utilisateurs.

Les équipes devraient conserver ces observations avec les révisions de modèles, les détails des appareils et les paramètres de compilation. Une base de connaissances d'ingénierie consultable peut éviter que des résultats prometteurs ne deviennent des croyances impossibles à auditer.

La question générale n'est plus de savoir si les téléphones Android diffèrent suffisamment pour justifier une configuration adaptative. C'est clairement le cas.

La question est de savoir si la politique d'ARPL peut transformer une détection matérielle précise en choix llama.cpp systématiquement meilleurs. La réponse viendra de benchmarks transparents, d'un éventail d'appareils plus large et de tests de compatibilité en amont.