Le récit dominant en IA depuis cinq ans est celui du scaling : plus de données et plus de calcul produisent de meilleurs modèles, de façon fiable et prévisible. Un article de position de l'Université de Zhejiang soutient que les deux intrants de cette stratégie s'épuisent, et que la voie de sortie n'est pas un nouvel algorithme d'entraînement. C'est un argument de redistribution. Les données et le calcul existent déjà. Ils sont simplement dans la poche des gens.
Deux murs. Les deux réels.
Les lois d'échelle ont suffisamment bien tenu pour que « il suffit d'entraîner un plus gros modèle sur plus de données » fonctionne comme stratégie de recherche crédible. L'article soutient que les deux intrants de cette stratégie s'épuisent.
Premier mur : épuisement des données. Les estimations actuelles situent le stock total de textes humains de haute qualité autour de 4 × 10¹⁴ tokens. Le plus petit modèle de LLaMA 3.1 a été entraîné sur 15 billions de tokens. Les projections suggèrent que la taille des jeux de données doit croître d'environ 2,4× par année pour suivre les exigences du scaling. Les chiffres ne tiennent plus après 2028, et possiblement dès 2026 si les pratiques de sur-entraînement se poursuivent. Les données synthétiques sont la solution de repli évidente, mais elles portent des pathologies connues : effondrement du modèle quand des modèles s'entraînent itérativement sur leurs propres sorties, qualité invérifiable en domaine ouvert et homogénéisation linguistique qui sous-représente l'expression culturelle et les usages peu fréquents.
Deuxième mur : monopolisation du calcul. L'entraînement de GPT-3 a exigé 10 000 GPU V100. GPT-4 aurait nécessité plus de 25 000 A100 pour un coût estimé au-delà de 100 M$. Grok 3 est allé plus loin encore. Cette infrastructure est désormais concentrée chez une poignée d'organisations, ce qui exclut de fait les institutions universitaires et les plus petites entreprises de la recherche fondamentale en IA. La loi de Moore ralentit, la capacité des fonderies à 5 nm et moins est réservée jusqu'en 2026, et le taux de croissance du calcul requis pour poursuivre le scaling (12,8× par année depuis 2022) dépasse la capacité de la chaîne d'approvisionnement physique à suivre.
| les murs | l'opportunité périphérie |
|---|---|
| Textes humains épuisés vers 2028. | 33,1 Eo de données de téléphones, cumul 5 ans (avant 2025). |
| Données synthétiques : risque d'effondrement et d'homogénéisation linguistique. | Privées, diversifiées, en temps réel, conformes à la réglementation. |
| Coûts de cluster GPU : plus de 100 M$ par entraînement frontière. | 9 278 EFLOPS de calcul collectif des téléphones (5 ans). |
| Capacité de fonderie réservée jusqu'en 2026 ; loi de Moore qui ralentit. | Les téléphones phares dépassent maintenant 2 TFLOPS chacun. |
| Calcul monopolisé par environ 5 organisations. | ~60 723 téléphones suffiraient à égaler la configuration de DeepSeek-v3. |
La solution proposée n'est ni un nouvel algorithme d'entraînement ni un meilleur pipeline de données synthétiques. C'est un argument de redistribution : les données et le calcul nécessaires pour franchir les deux murs existent déjà, sous la forme d'appareils en périphérie (téléphones intelligents, capteurs IoT, ordinateurs portables, objets connectés). Ils sont simplement fragmentés, privés et inexploités.
Ce que les appareils en périphérie ont réellement.
La contribution la plus frappante de l'article n'est pas une nouvelle technique. C'est une quantification : combien de données sont générées en périphérie et combien de calcul. Les auteurs font le calcul sérieusement et les résultats sont plus grands que la plupart des gens ne le supposent.
Pour mettre le chiffre de calcul en contexte : l'entraînement de DeepSeek-v3 a utilisé 2 048 GPU H100, chacun livrant environ 59,3 TFLOPS FP32. Une puce de téléphone phare en 2024 (classe iPhone 16) livre environ 2 TFLOPS. Si on pouvait les faire fonctionner en parallèle (un « si » de taille), il faudrait environ 60 723 téléphones pour égaler la configuration de calcul de DeepSeek.
# Calcul d'entraînement DeepSeek-v3 2 048 GPU × 59,3 TFLOPS = 121 446 TFLOPS # Puce de classe iPhone 16 tflops_par_telephone = ~2 # FP32 # Téléphones requis (parallèle idéal) telephones = 121 446 / 2 ≈ 60 723 appareils # Contexte livraisons_mondiales_2024 = ~1,24G unités configs_equiv_deepseek_an = ~20 000
Le qualificatif « en parallèle idéal » fait beaucoup de travail dans ce chiffre. L'entraînement distribué sur des appareils hétérogènes avec connectivité, matériel et disponibilité variables est un problème d'ingénierie non résolu. L'article est clair là-dessus. Mais l'argument brut des ressources tient : l'écart entre ce qui existe en périphérie et ce qui est utilisé est énorme.
Trois couches d'IA distribuée.
L'article passe en revue le paysage technique selon trois modes de déploiement de plus en plus ambitieux. Chacun est un domaine de recherche actif ; la contribution de l'article est de les cadrer comme une pile cohérente plutôt que comme des courants indépendants.
- Petits modèles de langage en périphérie (SLM)
La couche immédiate, pratique. Déployer des modèles compressés directement sur les appareils pour faire de l'inférence sans dépendre du nuage. Des architectures comme Mamba (complexité linéaire, inférence plus rapide que les Transformers), Hymba (têtes d'attention combinées à des têtes d'espace d'états) et xLSTM (LSTM modernisé avec portes exponentielles) sont conçues pour les environnements à mémoire contrainte. Un modèle de 770 M de paramètres utilisant distillation, quantification et spécialisation de domaine atteint 95 % de la performance d'un modèle 540 B sur des tâches précises, avec moins de 0,15 % du calcul. La série iPhone 16 fait tourner localement l'amélioration d'image en temps réel et la traduction multilingue à 2 TFLOPS.
statut · déployé aujourd'hui - Inférence collaborative
Distribuer l'inférence sur plusieurs appareils plutôt que sur un seul modèle sur un seul appareil. Quand un appareil ne peut pas faire tourner un modèle complet, un réseau d'appareils peut le faire collectivement : on découpe les couches, on transmet les activations, on agrège les résultats. Cela échange de la latence contre de l'accessibilité et permet de faire tourner de plus gros modèles sans infrastructure serveur centralisée. Le défi d'ingénierie principal est la topologie réseau et la gestion de la latence quand les appareils sont hétérogènes et sporadiquement disponibles.
statut · émergent - Entraînement fédéré
La couche la plus ambitieuse, et la moins résolue techniquement. Chaque appareil s'entraîne sur ses données locales et ne partage que des mises à jour de modèle (gradients ou deltas de poids) avec un agrégateur central, pas les données brutes. Cela permet de respecter des cadres comme le RGPD tout en utilisant les données périphériques pour l'entraînement. FedLLM et d'autres cadres similaires ont démontré le fine-tuning fédéré à une échelle significative. L'entraînement sur appareil est désormais faisable même sur des systèmes embarqués : des travaux récents atteignent jusqu'à 95 % de sparsité pour les opérations d'entraînement, et l'approche ElasticZO permet un entraînement en arithmétique entière uniquement avec une réduction mémoire d'environ 1,5×. Position de l'article : le pré-entraînement fédéré de grands modèles sur des populations d'appareils massives reste un problème ouvert, mais la trajectoire technique en fait une cible réaliste à moyen terme.
statut · encore un problème ouvert
Les deux problèmes non résolus qui comptent le plus.
L'article identifie deux défis techniques fondamentaux comme bloqueurs critiques de la vision d'entraînement distribué en périphérie. Ce ne sont pas des difficultés d'ingénierie à résoudre par incréments. Ce sont des problèmes de recherche qui exigent des percées conceptuelles.
01 · Fusion de modèles sur appareils hétérogènes
Les appareils en périphérie diffèrent énormément en mémoire, en calcul, en architecture et en connectivité. Un protocole d'entraînement qui fonctionne sur un iPhone 16 peut être incompatible avec un Android milieu de gamme ou un capteur IoT. L'apprentissage fédéré suppose typiquement une architecture de modèle partagée ; des populations d'appareils hétérogènes violent cette hypothèse. Comment agréger des mises à jour de modèle provenant d'appareils qui font tourner des variantes de modèle réellement différentes ? Comment empêcher les appareils les plus performants de dominer le signal de mise à jour ? Le problème reste non résolu à l'échelle envisagée par l'article.
02 · Partage de calcul sur appareils hétérogènes
Même si tous les appareils pouvaient entraîner le même modèle, coordonner une participation intermittente et à bande passante variable sur des millions d'appareils est un problème de systèmes sans solution propre. Les appareils se déconnectent, ralentissent sous contrainte thermique, varient selon l'état de la batterie et subissent des conditions réseau inégales. La stabilité d'entraînement en présence de retardataires et d'abandons (un problème connu en apprentissage profond distribué même avec du matériel fiable) devient dramatiquement plus difficile quand les participants sont des appareils personnels sans garantie de disponibilité et avec des charges concurrentes.
Il vaut la peine de les nommer clairement parce qu'ils sont l'écart entre les quantifications inspirantes de l'article et le système réellement déployé. Les données existent. Le calcul existe. Les protocoles pour les exploiter de façon fiable à grande échelle, pas encore. C'est un cadrage honnête, et l'article gagne en crédibilité en ne survendant pas la maturité du domaine.
Au fond, il s'agit de qui peut faire de l'IA.
Les arguments techniques de cet article sont intéressants. L'argument politique en dessous est plus important. Le paradigme de scaling actuel concentre la capacité de développement en IA chez environ cinq organisations à l'échelle mondiale. Tous les autres (toutes les universités, toutes les startups, toutes les institutions nationales de recherche sans accès à des clusters GPU à quatre chiffres) sont consommateurs des modèles que ces organisations choisissent de publier, aux conditions que ces organisations choisissent d'imposer.
L'argument du calcul distribué en périphérie est, fondamentalement, un argument sur la participation. Si les données et le calcul marginaux nécessaires à l'entraînement à l'échelle frontière peuvent être contribués par des appareils ordinaires faisant tourner des protocoles fédérés, alors la frontière n'est plus gardée par qui peut se payer le cluster. Les auteurs cadrent cela explicitement comme de la démocratisation de l'IA, un terme qui fonctionne souvent comme du marketing mais qui prend ici un sens technique précis : les intrants d'entraînement deviennent structurellement décentralisés.
Il y a des contre-arguments évidents. Coordonner des millions d'appareils hétérogènes produit du bruit, introduit de nouvelles surfaces d'attaque (empoisonnement, parasitage) et exige des mécanismes incitatifs qui n'existent pas encore. L'article reconnaît tout cela. L'argument environnemental coupe dans les deux sens : l'entraînement distribué en périphérie à grande échelle a sa propre empreinte énergétique, même si la consommation par appareil est faible.
Pour les équipes qui construisent des piles d'agents en production aujourd'hui, la pertinence à court terme se trouve dans la couche SLM. La trajectoire des modèles sur appareil avance plus vite que la plupart des horizons de planification le supposent. Une puce de téléphone à 2 TFLOPS qui peut faire de l'inférence locale sur 7 milliards de paramètres, sans latence d'API et sans données qui quittent l'appareil, change l'architecture d'une part significative des applications. Ce n'est pas une prédiction. Ça se produit déjà dans le haut de gamme grand public, et les projections de croissance de calcul de l'article suggèrent que ça se normalisera dans l'horizon de planification actuel.
Si vous voulez un deuxième regard sur la façon dont une architecture axée SLM changerait votre pile d'agents actuelle, le formulaire de contact est la voie la plus rapide. Nous faisons des revues de 30 minutes pour les piles d'agents en production, gratuitement.