Digest LinkedIn : un modèle d'agents de 24 Md qui tourne sur votre propre matériel, llm-d 1.0 apprend à Kubernetes à servir des agents, et Pichai chiffre la frontière
Le LFM2.5-24B-A2B de Liquid AI loge un MoE de 2,4 milliards de paramètres actifs sur les portables, llm-d de Google Cloud passe en 1.0 comme pile d'inférence native Kubernetes, et Sundar Pichai explique à Big Technology que les revenus du cloud passent après le calcul de frontière. Vérifié sur des sources primaires publiques.
Trois publications LinkedIn publiques des deux derniers jours, trois couches de la pile d'agents en mouvement simultané : un modèle assez petit pour faire tourner des agents sur votre propre matériel, la couche de service qui alimente un millier d'agents dans un centre de données, et le PDG de Google disant tout haut que les revenus du cloud passent après le calcul de frontière. Courtes citations, liens et mon avis. Rien ici ne vient du fil privé de quiconque.
En bref
Chaque élément a commencé comme une publication LinkedIn publique ; je n'ai pas pu ouvrir les publications elles-mêmes (LinkedIn exige une connexion), donc chaque élément ci-dessous est vérifié contre la source primaire publique qu'il désigne : la fiche modèle et le blog de lancement de Liquid AI, le blog Google Cloud et le dépôt llm-d, et la transcription de l'interview de Big Technology elle-même. Quand un chiffre vient du propre benchmark du fournisseur, l'élément le dit. Les déclarations de Pichai sont des propos d'interview, signalés comme tels. J'ai lu ces pages le 21 octobre 2026.
Karun Thankachan : LFM2.5-24B-A2B de Liquid AI, un MoE de 24 Md avec 2,4 Md de paramètres actifs pour des agents sur l'appareil
"LFM2.5-24B-A2B is a 24B-parameter reasoning model with only 2B active parameters, built for fast, private agents on-device."
La fiche modèle de Liquid AI, la page que la publication LinkedIn désignait. Fiche modèle · Blog de lancement · Publication originale
Mon avis : Les chiffres d'architecture de la fiche concordent avec les affirmations de la publication : 24,0 milliards de paramètres au total dont 2,45 milliards actifs par token, 40 couches (30 blocs de convolution courte doublement à portes plus 10 blocs d'attention GQA), 64 experts par bloc MoE avec routage top-4, un budget d'entraînement de 36 000 milliards de tokens, un vocabulaire de 128K et un contexte de 131 072 tokens. Le post-entraînement est un réglage fin supervisé plus deux étapes de distillation on-policy multi-domaines plus un apprentissage par renforcement agentique mené dans de vrais harnais d'agents (OpenClaw, Hermes Agent, Pi, OpenCode), donc le modèle est littéralement entraîné sur les outils et prompts système qu'il rencontrera. La fiche propose six formats : BF16 natif, FP8, GGUF, ONNX, MLX 4-bit et une variante draft pour le décodage spéculatif. L'honnêteté notable est dans le positionnement : Liquid dit clairement que le modèle n'est "pas recommandé pour les tâches riches en connaissances en solo" et doit être associé à la récupération, et son propre tableau le montre perdant face à Qwen3.6-35B-A3B sur GPQA (74,42 contre 83,69), SWE-Bench Verified (51,0 contre 66,2) et WebArena (26,75 contre 37,62) tout en gagnant les lignes agentiques d'usage d'outils (LiveClaw 48,09 contre 38,19, ToolSandbox 80,71 contre 75,02). C'est un organe d'appel d'outils, pas une encyclopédie - et c'est le bon compromis pour un modèle destiné à vivre dans un harnais. Les affirmations de vitesse sont des mesures du fournisseur : 184 tok/s sur Apple M5 Max et 114 sur Ryzen AI Max+ 395 (llama.cpp, Q4_K_M, contexte 4K), et plus de 21K tokens de sortie/s sur un seul B300 à forte concurrence. La licence est la LFM Open License v1.0 de Liquid : sans redevance, mais l'usage commercial exige que le chiffre d'affaires annuel de votre organisation reste sous un seuil de 10 millions de dollars - ce n'est donc pas une licence OSI et les grandes entreprises ont besoin d'un accord séparé. Tel qu'observé aujourd'hui, la fiche affiche environ 16,9K téléchargements le mois dernier et 538 mentions j'aime depuis le téléversement du 12 octobre.
Non vérifié : Tous les chiffres de benchmarks et de vitesse sont les propres exécutions de Liquid sur son harnais et son matériel ; je n'ai pas fait tourner le modèle. Le cadrage "compétitif avec un modèle ~50% plus gros" repose sur les lignes agentiques d'un seul tableau choisi par le fournisseur. Ni les données ni le code d'entraînement ne sont publiés - la fiche documente les étapes de la recette, pas les données.
Mark Lohmeyer : llm-d 1.0 passe en disponibilité générale, la pile native Kubernetes pour l'inférence distribuée
"Today at the PyTorch Conference, we released llm-d 1.0, an open-source, Kubernetes-native stack for distributed LLM inference."
Le blog Google Cloud, 20 octobre 2026, par Lohmeyer lui-même. Blog Google Cloud · Dépôt (Apache-2.0) · Publication originale
Mon avis : llm-d se place au-dessus de vLLM et SGLang et transforme une grappe de serveurs de modèles en un pool coordonné unique : routage conscient du cache de préfixes et de la charge, déchargement étagé du cache KV (RAM hôte, SSD, Google Cloud Managed Lustre), désagrégation prefill/decode orchestrée par le nouveau DisaggregatedSet, contrôle de flux multi-locataire et un processeur asynchrone qui exécute les tâches par lots dans la capacité excédentaire sans affamer le trafic interactif. Le récit du 1.0 vise directement le trafic d'agents : le routage conscient des sessions garde les tours d'un agent sur les répliques qui détiennent déjà son contexte, et le time-slicing laisse les rollouts RL partager les accélérateurs avec l'inférence, ce qui, selon Google, fait passer le taux d'utilisation des accélérateurs d'environ 40% à plus de 70%. Les chiffres du billet sont rapportés par le fournisseur mais précis : sur une charge de codage agentique sur TPU Ironwood, le routage conscient des préfixes plus le déchargement vers la mémoire hôte ont réduit le temps médian jusqu'au premier token de plus de 85% et multiplié le débit par 2,4 face à un Kubernetes Service ordinaire ; la plateforme Gemini de Google a doublé son taux de succès du cache de préfixes de 35% à 70% via GKE Inference Gateway ; un déploiement de 17 000 nœuds multi-régions a multiplié le débit par 2,9 sur trois grappes avec 99,9% de succès. Les citations clients nomment des usages réels : Snap rapporte 75-80% de succès du cache de préfixes, ZenteiQ revendique 4x de débit agrégé pour la génération de données synthétiques, et les ingénieurs inférence de Mistral disent appliquer des bandes de priorité entre leurs niveaux commerciaux avec. Le projet est un effort CNCF Sandbox cofondé par Red Hat, Google Cloud, IBM Research, CoreWeave et NVIDIA, avec plus de 500 contributeurs dans 25 organisations ; le dépôt est sous Apache-2.0 et affiche 4 917 étoiles et 870 forks tels qu'observés aujourd'hui. À noter ce que 1.0 signifie ici : API v1, haute disponibilité du routeur et mises à jour sans interruption - les parties ennuyeuses qui rendent une couche de service adoptable.
Non vérifié : Tous les chiffres de performance viennent de Google ou de ses partenaires, mesurés sur leurs charges et leur matériel ; je n'ai pas déployé llm-d. Les chiffres de la plateforme Gemini décrivent le trafic de production propre de Google, ce qui est un usage réel mais pas une évaluation indépendante.
Alex Kantrowitz : Sundar Pichai sur l'auto-amélioration récursive et la pénurie de calcul
"Our cloud business is at any given moment in time forgoing short-term revenues because we are making compute trade-offs to support frontier AI development."
L'interview de Big Technology, publiée le 20 octobre 2026, enregistrée au siège de Google à Mountain View. Tout dans cet élément est ce que Pichai a dit dans une interview - des affirmations d'une partie intéressée, pas des faits audités. Interview · Publication originale
Mon avis : Trois passages portent le poids. Sur l'auto-amélioration récursive, Pichai confirme la remarque de Sergey Brin selon laquelle le RSI a contribué au nouveau modèle Gemini 4 Argon, mais trace la ligne précisément : "aujourd'hui, dans un continuum, nous sommes assez loin de l'état final du RSI" - ce qui existe maintenant, ce sont "des agents aidant les chercheurs en IA de manière automatisée à travailler ensemble pour construire ces modèles". Sur la demande, il dit qu'Argon a traité presque 25 000 milliards de tokens dans ses 72 premières heures, environ trois fois la fenêtre de lancement de Gemini 3, et que Google est contraint en capacité pour le servir ; en interne, il attribue à Argon une augmentation de 30% des changelists et une diminution d'un tiers des rollbacks en quatre semaines. Sur la pénurie de calcul, interrogé sur la remarque d'Andy Jassy "épuisé jusqu'en 2028", il ne cille pas : un client demandant du calcul pour 2027 fait face à quelque chose d'"incroyablement difficile", tout en rejetant la comparaison avec la fibre noire - "Nous l'utilisons. Nous sommes contraints en capacité quotidiennement" - tout en concédant qu'une surcapacité est possible si l'un des "2 000 composants ou plus" (mémoire, électricité, électriciens, terrain) devient le goulot. Le cadrage que je trouve le plus révélateur est l'ordre de priorité qu'il énonce carrément : l'accès de DeepMind au calcul de frontière est "non négociable", l'activité cloud planifie autour de ce qui reste, et les revenus cloud sacrifiés sont simplement "déjà vrais". Pour les observateurs de la sécurité, sa réponse sur les incidents d'agents est la défense en profondeur - travail d'alignement plus surveillance en temps réel, sandboxing et, à terme, des standards intersectoriels avec des évaluateurs indépendants, "comme les contrôles financiers... des auditeurs indépendants".
Non vérifié : Ce sont les déclarations d'un PDG dans une interview amicale. Les volumes de tokens, les chiffres de changelists et de rollbacks et les affirmations de capacité sont les propres chiffres de Google sans confirmation externe ; l'évaluation du RSI est une position, pas une mesure.
Comment ce digest est produit
Les éléments sont sélectionnés dans des publications LinkedIn publiques par un scanner, puis chacun est vérifié contre la source primaire publique qu'il référence : la fiche modèle et le blog du fournisseur, le blog d'ingénierie et le dépôt, la transcription de l'interview. Les publications LinkedIn elles-mêmes exigent une connexion et n'ont pas été ouvertes ; les liens sont fournis pour référence. Aucun compteur d'engagement n'est utilisé, je n'ai pas contacté les auteurs, et rien ici ne vient d'un fil privé.
- https://huggingface.co/LiquidAI/LFM2.5-24B-A2B
- https://www.liquid.ai/blog/lfm2-5-24b-a2b
- https://cloud.google.com/blog/topics/ai-infrastructure/llm-d-1-0-an-open-source-stack-for-distributed-inference
- https://github.com/llm-d/llm-d
- https://www.bigtechnology.com/p/sundar-pichai-googles-frontier-imperative