Aller au contenu
BOLINI.IO / VEILLE IA ÉDITION Nº 003

SIGNAUX

jeudi 22 octobre 2026 8 entrées ≈ 7 min

Veille IA quotidienne — ce qui compte, sans le bruit.

Ce matin

Une équipe de recherche en calcul distribué rapporte qu’un agent outillé — base de connaissances, squelette d’implémentation, vérification Lean — a découvert A-greement, un protocole de consensus qui réduit la latence moyenne d’un magasin clé-valeur géo-distribué de 12,2 % en écriture et 33,3 % en lecture face au meilleur baseline. Ailleurs : deux RCE critiques dans PHP, trouvées par des modèles et divulguées dans la panique, un vocabulaire reconstruit qui coupe 77 % du coût d’inférence d’un petit modèle, et une perte qui affiche 0,0 tout en exécutant un programme arbitraire dans le backward de PyTorch.

À la une

Un agent vérifié en Lean découvre un protocole de consensus plus rapide que l’état de l’art

A-greement est un protocole de consensus pour machines à états géo-répliquées, obtenu avec AI-greement, un harnais qui combine une base de connaissances conceptuelle sur les protocoles, un squelette d’implémentation modulaire et un cadre de vérification Lean avec définitions de sûreté et preuves réutilisables. Sur six déploiements à 5 ou 9 réplicas, il réduit la latence moyenne d’un magasin clé-valeur géo-distribué de 12,2 % sur une charge à dominante écriture et de 33,3 % sur une charge à dominante lecture face au baseline le plus rapide, et l’égale en lecture seule. Les auteurs indiquent que la formalisation Lean a révélé plusieurs vulnérabilités non documentées dans des protocoles existants, et soutiennent que les experts humains restent nécessaires avant, pendant et après la recherche.

Pourquoi ça compte Le gain ne vient pas du modèle mais du harnais : base de connaissances, squelette exécutable et vérificateur formel sont ce qui transforme un agent de code en outil de recherche capable de produire un résultat réfutable plutôt qu’un patch plausible.

arXiv cs.DC 22 oct. Recherche source primaire ↗

[01] Labo

Deux RCE critiques dans PHP, trouvées par des modèles et divulguées dans la panique

OpenAI raconte la coordination qui a mené aux correctifs publiés le 21 octobre sur toute la branche PHP 8.x : Calif a identifié une faille critique avec GPT-5.6 Sol dans le cadre de Patch the Planet, Wiz l’a trouvée indépendamment, et les mainteneurs de PHP ont mené le correctif avec Cloudflare, Wiz et les agences gouvernementales américaines. Le laboratoire publie un cadre de réponse en cinq étapes pour les failles critiques de logiciels très répandus, et un vérificateur de version PHP distribué comme skill Codex. Selon OpenAI, l’IA frontière a trouvé ces failles avant les attaquants ; la fondation PHP rapporte de son côté que les identifiants CVE ont fuité le 20 octobre avec un score CVSS erroné de 10,0 (le score réel est 9,2), que la pré-annonce a été avancée à 19 h 30 UTC et la sortie déplacée du 22 au 21 octobre, et que des exploits circulaient dès la nuit du 20.

Pourquoi ça compte Le maillon faible n’est plus la détection mais la fenêtre de divulgation : entre la découverte en août et le patch, ce sont les fuites, pas les correctifs, qui ont fixé la vitesse d’exploitation — d’où l’intérêt de mesurer son délai de redéploiement plutôt que sa capacité à trouver des bugs.

OpenAI· 21 oct. · source ↗

[02] Outils

Un vocabulaire spécialisé coupe 77 % du coût d’inférence d’un petit modèle

Dharma-AI reconstruit le tokenizer plutôt que le modèle : son correcteur automatique de dissertations portugaises, bâti sur Qwen3-4B, passe d’un vocabulaire de 151 669 entrées à 64 767, et ses réponses de 350 à 101 tokens en moyenne. Sur 500 requêtes exécutées sur une RTX 5090 avec vLLM, le coût mesuré baisse de 77,0 % et le score du banc d’évaluation monte de 0,703 à 0,810. La méthode choisit les tokens selon le coût et non la fréquence — dans ce cas, un token généré coûte 7,4 fois un token lu —, et les auteurs précisent que le papier est encore en relecture, donc les chiffres peuvent changer.

Pourquoi ça compte Le tokenizer est un levier de coût fixé avant le premier pas d’entraînement, et un token économisé en sortie vaut 7,4 tokens économisés en entrée : pour un modèle spécialisé, retoucher le vocabulaire est parfois plus rentable que changer de modèle.

Hugging Face· 21 oct. · source ↗

[03] Recherche

La mise en forme que les convertisseurs jettent rend les agents documentaires confiants et faux

Sur 76 documents de politique réels, la tâche consiste à retrouver les exigences que l’auteur a signalées, vérifiées contre les propriétés OOXML du fichier par un matcher déterministe sans juge LLM. Un pipeline qui ignore la mise en forme s’effondre de F1 micro 0,690 à 0,150 avec docling et 0,075 en texte brut, et l’écart se reproduit sur six modèles de réponse de deux fournisseurs, cinq Claude et GPT-5.6. L’ablation localise la perte sur deux indices seulement, le surlignage (+0,302) et la couleur (+0,262), quand le gras, l’italique, le monospace et le barré restent à ±0,003 ; 32,8 % de 6 460 documents portent une couleur ou un surlignage délibéré, 10,3 % sur une obligation.

Pourquoi ça compte Quand un agent documentaire se trompe, la cause est souvent l’ingestion et non le raisonnement : mesurer la conservation des indices de mise en forme avant d’accuser le modèle évite de payer un modèle plus gros pour un problème de convertisseur.

arXiv cs.CL· 21 oct. · source ↗

[04] Outils

AMD branche ses noyaux MI350 dans PyTorch, jusqu’à 3× en bout de chaîne sur vLLM

FlyDSL devient un backend optionnel de PyTorch sur les GPU AMD MI350 : GEMM dense et groupé, attention fusionnée, GEMM à échelle MXFP8 et MXFP4, RMSNorm et TopK passent par les API d’opérateurs existantes, sans noyau personnalisé dans l’application, et torch.compile compare FlyDSL à ATen et Triton puis mémorise le plus rapide par charge. Les gains annoncés sont de 1,10× en GEMM BF16 dense, 1,58× et 1,68× en MXFP8 et MXFP4, 1,20× en GEMM groupé, 1,17× à 3,66× en RMSNorm et 4,82× en TopK à petit K. En A/B complet sur vLLM, la requête accélère de 1,13× en BF16, 2,04× en MXFP8 et 3,01× en MXFP4, selon le modèle et la concurrence.

Pourquoi ça compte Les chiffres dépendent du triplet forme, format de quantification et noyau, donc l’arbitrage reste à refaire sur son propre trafic : ce qui change, c’est qu’il se fait désormais dans torch.compile au lieu d’un fork de noyaux.

PyTorch· 21 oct. · source ↗

[05] Outils

TorchTitan ajoute un RL qui garde un seul modèle, du pré-entraînement jusqu’à vLLM

TitanRL conserve la même définition de modèle du pré-entraînement jusqu’à l’intérieur de vLLM, là où la plupart des piles RL maintiennent deux implémentations à garder alignées, avec des rollouts asynchrones où génération et entraînement montent en parallèle. Un mode invariant par lot rend les log-probabilités du trainer et du générateur identiques bit à bit sur les configurations on-policy supportées, donc l’écart entre les deux est exactement zéro à chaque pas. Côté performance, DeepSeek V3 671B en MXFP8 atteint 5 324 tokens/s/GPU sur 256 GB300, FlexShard réduit le temps d’optimiseur jusqu’à 79 % sur 256 H100 et le pas d’entraînement de Llama 3 405B jusqu’à 20 %, et le nouveau module de checkpoint fait tomber le blocage moyen de 841,2 ms à 34,1 ms sur 512 H100.

Pourquoi ça compte La dérive entre les poids qui génèrent et ceux qui sont mis à jour est un bug notoirement difficile à attribuer ; un mode bit-identique la transforme en invariant testable, ce qui rend le budget de débogage disponible pour l’algorithme.

PyTorch· 21 oct. · source ↗

[06] Analyse

Une perte qui affiche 0,0 peut exécuter un programme arbitraire dans le backward

L’auteur exploite le désaccord entre l’arithmétique IEEE 754 et la différentiation symbolique : h(u) = (2^30 + u) − 2^30 vaut 0 en forward sur le GPU mais a une dérivée de 1 aux yeux du moteur d’autograd. Un terme de régularisation peut donc s’afficher à 0.0 à chaque itération, dans les logs comme dans TensorBoard, tout en imposant le gradient choisi ; avec le pas d’apprentissage η, forcer v(θ) = (θ − F(θ))/η transforme une étape de SGD en mise à jour déterministe, ici une génération de Game of Life, sans toucher au checkpoint, à l’architecture ni au jeu de données.

Pourquoi ça compte Vérifier le hash d’un safetensors et lire le modeling_*.py ne suffit plus dès lors qu’une dépendance de perte est du code exécuté avec les mêmes droits que l’entraînement : la défense tenable est l’isolation d’exécution, pas la revue de code.

Elements of a Vector Space· 21 oct. · source ↗

[07] Labo

Granite Speech 5.0 : 5,06 % de WER moyen en anglais, en Apache 2.0

IBM publie granite-speech-5.0-2b, successeur de 4.1-2b à taille égale : transcription en anglais, français, allemand, espagnol, portugais et japonais, traduction depuis et vers l’anglais dans ces langues plus l’italien et le mandarin, entraînement sur 390 000 heures d’audio public complété de données synthétiques. Selon IBM, le modèle se classe deuxième des modèles open-weight sur le WER moyen anglais des jeux courts de l’Open ASR Leaderboard, à 5,06 %, avec des listes de biais allant jusqu’à 2 000 termes et une F1 de capitalisation entre 89,7 et 99,5 selon les jeux. Il sort sous Apache 2.0 avec le support de Transformers, vLLM, llama.cpp et mlx-audio, et deux modèles de la collection sont révisés : un 470M Turbo CTC multilingue pour le débit, un 2B-plus pour l’attribution des locuteurs.

Pourquoi ça compte Un 2B sous Apache 2.0 avec biais par mots-clés couvre une chaîne de transcription d’entreprise sans API externe ; le point à vérifier soi-même reste le français, dont les chiffres ne sont pas détaillés dans le billet.

Hugging Face· 21 oct. · source ↗

Sources balayées chaque matin

Sélection à la main dans un flux automatique : les liens pointent toujours vers la source primaire, jamais vers un agrégateur.