speaker-diarization-community-1 est le successeur libre de speaker-diarization-3.1, l'un des pipelines de diarisation les plus téléchargés de Hugging Face. Il entre au classement Radar ce matin avec 5,4 M de téléchargements sur le mois et 2,8 k likes, d'après la fiche. La question pour un compte rendu de réunion en français n'est pas « est-il meilleur » mais « sur quel corpus ».
\n\nIl prend un fichier audio mono à 16 kHz (le stéréo est moyenné, les autres fréquences sont rééchantillonnées) et renvoie, pour chaque segment, un locuteur anonyme et ses bornes de temps. On peut fixer le nombre de locuteurs (num_speakers=2) ou l'encadrer (min_speakers, max_speakers). Il tourne sur CPU par défaut ; le GPU est un simple pipeline.to("cuda"). La fiche annonce quatre changements par rapport à la 3.1 : une meilleure attribution et un meilleur comptage des locuteurs, une sortie « exclusive » où aucun segment ne se chevauche, un usage hors ligne simplifié après clonage du dépôt, et un hébergement optionnel chez pyannoteAI.
La sortie exclusive est le point utile pour nous. Une transcription (Whisper, parakeet) donne des mots horodatés ; une diarisation classique donne des plages qui se recouvrent quand deux personnes parlent en même temps. Avec output.exclusive_speaker_diarization, chaque instant n'a qu'un locuteur, ce qui permet d'aligner les deux listes par simple comparaison d'horodatages, sans règle d'arbitrage à écrire. La fiche précise que cette fonction est « rétroportée » de leur modèle commercial precision-2.
La licence passe de MIT (3.1) à CC-BY-4.0 : attribution obligatoire, usage commercial permis. Le dépôt reste à accès restreint (« gated ») : il faut un compte Hugging Face, accepter les conditions et fournir un token. La fiche ne donne aucune vitesse ni aucune consommation mémoire ; la 3.1 non plus.
\nLes taux d'erreur de diarisation (DER, plus bas est mieux) sont publiés sur douze corpus, dans la configuration la plus sévère : pas de tolérance aux bornes, parole superposée comptée, aucune aide manuelle. Les chiffres sont ceux de l'éditeur, datés de septembre 2025.
\n| Corpus | 3.1 | community-1 | precision-2 (cloud) |
|---|---|---|---|
| AMI (micro-casque) | 18,8 | 17,0 | 12,9 |
| AMI (micro de table) | 22,7 | 19,9 | 15,6 |
| AliMeeting | 24,5 | 20,3 | 15,2 |
| DIHARD 3 | 21,4 | 20,2 | 14,7 |
| VoxConverse | 11,2 | 11,2 | 8,5 |
| REPERE (TV française) | 7,9 | 8,9 | 7,4 |
Sur AMI, le corpus de réunions de référence, le gain est de 1,8 à 2,8 points. Sur REPERE, seul corpus francophone du tableau, community-1 recule d'un point par rapport à la 3.1. La fiche le reconnaît sans l'expliquer. Pour des réunions en français, ce point n'est donc pas tranché par les chiffres de l'éditeur. La troisième colonne montre aussi la stratégie de pyannote : le modèle libre progresse, le modèle payant garde 1,5 à 5,5 points d'avance.
\n\nNemotron-3-Diarization, cité le 11 octobre comme complément de parakeet, compte 72 k téléchargements contre 5,4 M ici : l'écosystème (exemples, intégrations, tutoriels) est du côté de pyannote. La 3.1 reste disponible, sous MIT, avec 6,9 M de téléchargements ; elle demeure le choix si la licence CC-BY pose problème ou si le corpus REPERE est représentatif de vos enregistrements. Côté transcription, la chaîne locale reste la même : whistle (17 Mo) ou parakeet-redux (178 Mo, 25 langues) pour les mots, pyannote pour les voix.
\n\npip install pyannote.audio (la fiche indique la compatibilité avec la version 4.x).Pipeline.from_pretrained("pyannote/speaker-diarization-community-1", token=...), puis appeler le pipeline sur un WAV mono 16 kHz. Un ProgressHook affiche l'avancement.output.exclusive_speaker_diarization et l'aligner sur les horodatages de la transcription.À surveiller : une mesure indépendante sur du français conversationnel, et une version de pyannote.audio qui publierait enfin les temps de traitement sur CPU.
", "date_published": "2026-10-14T08:20:00+02:00", "tags": [ "diarisation", "pyannote", "audio", "compte rendu de réunion", "CPU", "CC-BY-4.0", "transcription" ] }, { "id": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-14-code-flash-next-coder-elague.html", "url": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-14-code-flash-next-coder-elague.html", "title": "Qwen3.8-Flash-Next élagué : ISTA-DASLab fait tenir un modèle de code de 177 B dans 32 Go", "summary": "ISTA-DASLab retire la moitié des experts de Qwen3.8-Flash-Next et quantise le reste à 3,5 bits : 29,6 Go résidents, 75,6 sur SWE-bench Verified d'après la fiche, contre 82,8 pour la base de 354 Go. C'est un modèle de code de première classe à la portée d'une station de travail, pas encore d'un portable.", "content_html": "Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF est une version de Qwen3.8-Flash-Next, le gros MoE de 177 B d'Alibaba, dont ISTA-DASLab (IST Austria) a retiré la moitié des experts avant de quantiser le reste à 3,5 bits. Le fichier résident pèse 29,6 Go ; la fiche annonce 75,6 sur SWE-bench Verified, contre 82,8 pour la base en BF16 qui pèse 354 Go. La fiche le présente comme exécutable sur un seul accélérateur de 32 Go.
\n\nQwen3.8-Flash-Next compte 48 couches de 512 experts, dont 10 actifs par token. La version « Coder » n'en garde que 256 par couche, choisis par la méthode RCO (une optimisation sous contrainte de budget, un budget exact par couche, décrite dans un article de mai 2026) avec des données de calibration orientées code, appel d'outils et vision. Les poids conservés sont ensuite quantisés par GSQ (article d'avril 2026) à 3,5 bits. La fiche parle d'un débit effectif de 1,89 bit par paramètre du modèle d'origine. Elle précise que l'usage généraliste est mieux servi par les versions non élaguées, et que l'élagage s'adresse au code, aux agents et au raisonnement spatial sur image.
\nUn détail compte pour la mémoire : le dépôt contient deux fichiers. Le premier (29,6 Go) est le transformeur et doit être en mémoire. Le second (28,8 Go) est une table n-gram servant au décodage, que llama.cpp peut lire sur disque par mmap sans la charger. D'où « 32 Go d'accélérateur » et non 58 Go.
| Benchmark | Base BF16 (354 Go) | Coder GSQ-RCO (29,6 Go résidents) | Conservé |
|---|---|---|---|
| SWE-bench Verified | 82,8 | 75,6 | 91 % |
| LiveCodeBench v6 | 87,4 | 86,3 | 99 % |
Ces deux chiffres sont ceux des auteurs, obtenus « à effort de raisonnement xhigh », et aucun autre modèle n'est comparé. La perte sur SWE-bench (7 points) est bien plus marquée que sur LiveCodeBench (1 point) : les tâches longues d'agent de code, avec navigation dans un dépôt, souffrent davantage de l'élagage que la résolution d'exercices isolés. La fiche ne donne ni longueur de contexte, ni paramètres d'échantillonnage, ni date de publication ; les métadonnées affichent 117 B de paramètres, le texte 176,9 B pour la base. Une mention de 8 Go de VRAM avec un moteur tiers (Strata) est un retour d'utilisateur, non vérifié. Licence Apache 2.0, héritée de la base ; 679 k téléchargements sur le mois et 377 likes.
\n\nLe même laboratoire publie la version non élaguée en quatre tailles, de 66 à 84 Go au total, dont 38 à 55 Go résidents ; sa fiche annonce 86,3 à 86,9 sur LiveCodeBench, soit l'équivalent de la version Coder, mais avec un besoin mémoire presque double. C'est donc l'élagage, pas la quantisation, qui fait passer sous 32 Go. Pour un PC de bureau, les deux alternatives vues ces derniers jours restent plus accessibles : Mellum 2.1 en GGUF tient en 8,1 Go avec 47 sur SWE-bench Verified d'après sa fiche, et Qwen3.8-27B GSQ-RCO tient en 8 à 12 Go. Le Coder 177 B se place entre les deux : trop gros pour un portable, à la portée d'une station avec une carte de 32 Go.
\n\nollama run hf.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF:IQ1_M (le tag IQ1_M est celui du Hub ; il ne reflète pas les 3,5 bits réels des poids).llama-server avec le premier fichier en argument ; la fiche fournit la commande et recommande le chargement différé de la table n-gram.À surveiller : une évaluation indépendante sur SWE-bench, la longueur de contexte réelle en llama.cpp, et une éventuelle version élaguée de Qwen3.8-27B par la même méthode, qui ramènerait ce type de modèle sur un portable.
", "date_published": "2026-10-14T08:20:00+02:00", "tags": [ "génération de code", "GGUF", "MoE", "élagage d'experts", "quantisation", "SWE-bench", "llama.cpp", "ISTA-DASLab" ] }, { "id": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-14-local-qwen-sans-refus-gguf.html", "url": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-14-local-qwen-sans-refus-gguf.html", "title": "Qwen3.8-27B « sans refus » : ce que valent les GGUF de huihui et OrcaSAQ-2 pour un usage professionnel", "summary": "Deux dérivés « abliterated » de Qwen3.8-27B entrent au classement, l'un à 2,2 M de téléchargements ; une seule des deux fiches mesure la perte due à la quantisation, aucune celle due à l'abliteration. Pour traiter des documents ou coder, le GGUF Unsloth d'origine reste le bon point de départ.", "content_html": "Deux GGUF « sans refus » de Qwen3.8-27B entrent au classement ce matin : Huihui-Qwen3.8-27B-abliterated-GGUF, 2,2 M de téléchargements sur le mois, et OrcaSAQ-2-Cyber-27B-Uncensored-GGUF, 23 k. Ils illustrent le constat de la Veille du jour : huit des trente entrées des rangs 31 à 60 sont des dérivés « uncensored » ou « abliterated ». Avant d'en installer un, il faut savoir ce qu'on y gagne et ce qu'on y perd.
\n\nL'« abliteration » consiste à repérer, dans les activations du modèle, la direction qui déclenche les refus, puis à la soustraire des poids de certaines couches. Aucun réentraînement, aucune donnée nouvelle. La fiche huihui parle elle-même d'une « implémentation brute, preuve de concept ». Elle précise les couches modifiées (17 à 52 ou 22 à 52 selon la série) et indique que les composants vision et MTP ne sont pas touchés. OrcaRouter part d'un point de contrôle abliteré, puis applique sa propre quantisation « sensible à la précision », dont la méthode n'est pas divulguée. Les deux conservent le mode réflexion et l'appel d'outils de la base ; OrcaSAQ-2 retire l'encodeur vision (texte seul) et annonce un contexte de 262 k tokens.
\n\nOrcaRouter publie une mesure de fidélité : sur WikiText-2 (16 k tokens), divergence KL moyenne de 0,020 et 94,4 % d'accord sur le premier token par rapport au BF16, perplexité en hausse de 0,8 %, pour un fichier de 15,7 Go au lieu de 54,7. Vitesse annoncée : 20,5 tokens par seconde sur une carte, 27,6 avec le brouillon DFlash2, pour 14,9 à 18,1 Go de VRAM. Ces chiffres sont ceux de l'éditeur et mesurent la perte due à la quantisation, pas celle due à l'abliteration : aucun benchmark de capacité (code, raisonnement, appel d'outils) n'est donné. Les 98 % sur CyberGym affichés sur la page concernent un autre modèle de la même maison. Le dépôt est à accès restreint (« gated »).
\nLa fiche huihui ne publie aucune mesure : ni divergence, ni perplexité, ni taux de refus. Elle liste une trentaine de fichiers, de 6,6 Go (TQ1_0) à 54,7 Go (BF16), avec des variantes « _L » où les tenseurs modifiés restent en Q8_0, d'où des tailles inhabituelles (un Q2_K_L de 17,2 Go, plus gros qu'un Q4_K_S de 15,6 Go). La série ternaire exige un fork de llama.cpp. L'avertissement est explicite : filtrage de sécurité « significativement réduit », usage déconseillé en production ou en public, revue manuelle recommandée. L'en-tête indique Apache 2.0.
\n\n| Dépôt | Modification | Fidélité mesurée | Taille Q4 (≈) | Licence |
|---|---|---|---|---|
| unsloth/Qwen3.8-27B-GGUF | aucune (quantisation seule) | non publiée sur la fiche | 16,5 Go (UD-Q4_K_M) | Apache 2.0 |
| Huihui abliterated | refus retirés | aucune | 16,6 Go (Q4_K_M) | Apache 2.0 |
| OrcaSAQ-2 Cyber | refus retirés + quantisation mixte | KL 0,020 (quantisation) | 15,7 Go (unique) | Apache 2.0 |
| Underdog-Saluki | ajustement pour agents | aucune | 7,9 Go | Apache 2.0 |
Pour les usages de ce site (extraction de documents, classification, agents outillés, code), un contrat, une facture ou un journal d'erreurs ne déclenchent normalement pas de refus du modèle d'origine. Le gain d'un modèle abliteré y est donc faible, et la perte n'est pas mesurée. Le seul cas où la question se pose est celui que cible OrcaRouter : l'analyse de journaux d'attaque par une équipe de sécurité autorisée. Même là, la fiche renvoie la responsabilité des garde-fous à celui qui déploie. Le GGUF Unsloth, 6,5 M de téléchargements, reste le point de départ.
\n\nollama run hf.co/unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_M, et constituer un jeu de 20 requêtes représentatives de vos tâches.ollama run huihui_ai/Qwen3.8-abliterated ou le GGUF OrcaSAQ-2 après acceptation des conditions), avec les mêmes paramètres (température 1,0, top_p 0,95, top_k 20 en mode réflexion).À surveiller : une mesure indépendante de ce que l'abliteration coûte en raisonnement et en appel d'outils sur Qwen3.8-27B, qui manque toujours trois semaines après la sortie du modèle.
", "date_published": "2026-10-14T08:20:00+02:00", "tags": [ "Qwen3.8-27B", "GGUF", "abliterated", "uncensored", "llama.cpp", "Ollama", "quantisation", "local" ] }, { "id": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-13-agents-d3-decision-index.html", "url": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-13-agents-d3-decision-index.html", "title": "d3 : vLLM Semantic Router prend la tête du Decision Index, JEV-35B et Lightning 4B descendent en taille", "summary": "L'équipe vLLM Semantic Router publie d3, un modèle de décision de 27 B dont la fiche annonce 65,5 au Decision Index public, devant pplx-decider (61,6). En trois jours, AutoTrust (JEV-35B, 3 B actifs) et H2O.ai (Lightning 4B) ajoutent deux modèles du même type, et la taille utile descend jusqu'à 4 B.", "content_html": "L'équipe vLLM Semantic Router publie d3, un modèle de décision de 27 B dont la fiche annonce 65,5 au Decision Index public, devant pplx-decider (61,6), traité hier. En trois jours, AutoTrust avec JEV-35B et H2O.ai avec H2O-Lightning-4B ajoutent deux modèles du même type, et la taille utile descend jusqu'à 4 B.
d3 est un dérivé de Qwen3.8-27B, publié sous Apache 2.0. La fiche compte 26,1 B de paramètres, dont 0,46 B pour l'encodeur de vision. Il ne génère pas de texte : on lui soumet un état (texte ou JSON, plusieurs images PNG, JPEG ou WebP, plusieurs vidéos MP4, WebM, MOV ou MKV) et des questions typées (choix, oui/non, score), et il renvoie une probabilité par réponse. C'est le même principe que clef, pplx-decider ou d1, avec la vidéo en plus. Les images sont lues jusqu'à 1,6 mégapixel, les vidéos à 2 images par seconde, 32 images au plus.
Le chiffre mis en avant est 65,45 sur la suite publique du Decision Index 0.3 ; le tableau détaillé donne 64,7 sur la version 0.3.1, les deux sections ne concordent donc pas tout à fait. Le gain annoncé sur le modèle précédent (Decision 2.0, 27 B) est de 8,5 points. Sur la vision, la fiche affiche 71,6 contre 70,6 pour pplx-decider ; sur la vidéo, 77,4 au Perception Test, marqué « évaluation interne ». Plusieurs résultats visuels sont signalés comme des reconstructions approximatives, et les scores des concurrents viennent du tableau de bord public, pas d'une mesure refaite. Autrement dit : tout est auto-déclaré, et le Decision Index communautaire n'a pas encore confirmé le 65,5.
Côté matériel, la fiche ne donne aucun minimum de mémoire. Les latences (55 ms en texte, 273 ms avec image, 553 ms avec une vidéo de 10 s) sont mesurées sur un AMD MI325X, une carte de centre de données. Aucun GGUF n'est listé, et l'usage passe par Transformers 5.17 avec trust_remote_code et un appel model.system_one(...). Aucune langue n'est indiquée. Pour un test sur PC, ce n'est pas le candidat du jour.
| Modèle | Taille | Score annoncé | Matériel indiqué | Entrées |
|---|---|---|---|---|
| d3 | 27 B dense | Decision Index 65,5 (public) | non précisé, mesuré sur MI325X | texte, images, vidéos |
| JEV-35B | 35 B MoE, 3 B actifs | Decision Index 59,7 (NVFP4 : 59,2) | BF16 72 Go (GPU 80 Go) ; NVFP4 25,6 Go (GPU 32 Go) | texte, images |
| H2O-Lightning-4B | 4 B (5 B affichés) | JevBench v1.6.1 : 72,5 ; 88,7 % sur 231 items texte | 7 quantisations llama.cpp / Ollama / LM Studio | texte, 4 images au plus |
| pplx-decider v1.1 | 27 B dense | Decision Index 61,6 | 49 Go en BF16 (vu le 12/10) | texte, images |
JEV-35B, base Qwen3.5-35B-A3B, dépasse JEV-27B-VL sur 24 des 37 benchmarks de sa fiche, avec une latence médiane de 204 ms sur B200. La fiche est franche sur ses faiblesses : connaissances et raisonnement (GPQA 0,360, HLE à 0), anglais surtout, et elle recommande encore JEV-27B-VL pour les jeux. H2O-Lightning-4B, base Qwen3.5-4B, ne cite pas le Decision Index mais un autre classement, JevBench, où il annonce 72,5 en composite ; les deux ne sont pas comparables. Son argument est ailleurs : 29 ms par décision sur une RTX PRO 4500, 7 quantisations, et une étude de seuils de routage utile en production. Au seuil 0,9, la fiche annonce 53,1 % de questions escaladées, 98,5 % de bonnes réponses sur le reste et 0,7 % de réponses confiantes mais fausses. Plus de 99 % des données d'entraînement sont en anglais.
/v1/systemone.À surveiller : la confirmation du 65,5 de d3 par le tableau de bord communautaire, l'apparition de GGUF pour d3 et JEV-35B, et surtout les premiers chiffres en français, absents des trois fiches.
", "date_published": "2026-10-13T08:21:00+02:00", "tags": [ "modèle de décision", "Decision Index", "d3", "JEV-35B", "H2O-Lightning-4B", "vLLM", "routage", "agents" ] }, { "id": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-13-documents-lightonocr-3-grounding.html", "url": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-13-documents-lightonocr-3-grounding.html", "title": "LightOnOCR-3 : l'OCR de LightOn passe sur Qwen3.5, avec boîtes et graphiques convertis en tableaux", "summary": "LightOn, éditeur parisien, publie LightOnOCR-3 en deux tailles, 4 B et 0,8 B, sous Apache 2.0. La fiche du 4 B annonce 86,3 sur olmOCR-bench et ajoute un mode « grounding » qui renvoie, pour chaque bloc de la page, un type et une boîte.", "content_html": "LightOn, éditeur parisien, publie LightOnOCR-3 en deux tailles, 4 B et 0,8 B, sous Apache 2.0. La fiche du 4 B annonce 86,3 sur olmOCR-bench et ajoute un mode « grounding » qui renvoie, pour chaque bloc de la page, un type et une boîte : de quoi relier un tableau extrait à sa position dans le PDF d'origine.
LightOnOCR-3 est un OCR de bout en bout : une image de page en entrée, du markdown en sortie, sans pipeline de détection séparé. Le 4 B passe sur l'architecture vision-langage Qwen3.5 ; le 0,8 B est affiné depuis Qwen3.5-0.8B-Base. Deux prompts seulement sont dans la distribution d'entraînement. Le prompt vide donne la transcription markdown. Le prompt grounding ajoute, devant chaque bloc, un label parmi 16 types (texte, titre, tableau, graphique, formule, etc.), un suffixe « + » pour les blocs qui continuent une colonne, et une boîte en coordonnées normalisées de 0 à 1000. Dans ce mode, les images reçoivent une courte description et les graphiques sont convertis en tableaux HTML de données. La fiche prévient que toute autre instruction est hors distribution, et que le modèle tourne avec le mode de réflexion désactivé.
Les scores du 4 B sont olmOCR-bench 86,3 (Arxiv Math 91,1, Old Scans Math 89,1) et ParseBench 75,1 en moyenne ; les autres colonnes ne sont pas lisibles dans le texte de la page, et aucun tableau comparatif avec d'autres OCR n'y figure. Ces chiffres sont auto-déclarés. Le 0,8 B n'a aucun score publié : il est présenté comme « rapide et efficace », sans mesure de débit chiffrée, ni pour lui ni pour le 4 B. Hugging Face affiche 5 B de paramètres pour le modèle nommé 4 B, et 0,9 B pour le 0,8 B, sans explication. Aucune langue n'est listée pour le 4 B ; les métadonnées du 0,8 B ne mentionnent que l'anglais. Pour un éditeur français, c'est le point à tester en premier. Le mode grounding coûte environ 25 % de tokens en plus (1 433 contre 1 158 par page en moyenne). La fiche référence 13 quantisations pour llama.cpp, Ollama, LM Studio et Jan, sans nommer le format. D'après la page de liste, le 4 B cumule 3,2 k téléchargements et 76 likes depuis le 6 octobre.
| Modèle | Taille | Sortie | Score annoncé | Licence | En local |
|---|---|---|---|---|---|
| LightOnOCR-3-4B | 4 B (5 B affichés) | markdown, boîtes, graphiques en tableaux HTML | olmOCR-bench 86,3 | Apache 2.0 | 13 quantisations |
| LightOnOCR-3-0.8B | 0,9 B | idem | aucun | Apache 2.0 | GPU léger, pas de quantisation listée |
| Youtu-Parsing-Omni | 5 B | JSON (mise en page, tableaux OTSL, LaTeX, Mermaid, audio) | OmniDocBench 97,0 | propre | GPU requis |
| TeleOCR | 1,2 B | OCR, tableaux, formules, mise en page | voir fiche | Apache 2.0 | GGUF |
Les trois ne sont pas mesurés sur le même banc : olmOCR-bench d'un côté, OmniDocBench de l'autre. Ce que LightOn apporte, c'est la licence Apache 2.0 et une sortie markdown avec boîtes, plus simple à relire qu'un JSON complet ; ce que Tencent apporte, c'est la structure (OTSL, Mermaid) et l'audio. TeleOCR reste le plus petit des trois à proposer des GGUF.
vllm serve lightonai/LightOnOCR-3-4B --trust-remote-code, réflexion désactivée, puis envoyer l'image seule (prompt vide) ou avec grounding.À surveiller : un résultat chiffré en français, des quantisations pour le 0,8 B, et une reproduction indépendante du 86,3.
", "date_published": "2026-10-13T08:21:00+02:00", "tags": [ "OCR", "LightOn", "LightOnOCR-3", "grounding", "olmOCR-bench", "PDF", "Apache 2.0", "documents" ] }, { "id": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-13-local-gguf-officiels-mellum.html", "url": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-13-local-gguf-officiels-mellum.html", "title": "GGUF officiels : Mellum 2.1 tient en 8 Go, MiniCPM-V 4.7 et d1-3B livrent aussi leur version locale", "summary": "JetBrains publie les GGUF officiels de Mellum 2.1, son MoE de code à 2,5 B actifs : 8,1 Go en Q4_K_M, contexte 131 k, une commande Ollama. La même semaine, OpenBMB (MiniCPM-V 4.7) et Liquid AI (d1-3B) livrent eux-mêmes la version quantisée.", "content_html": "JetBrains publie les GGUF officiels de Mellum 2.1, son MoE de code à 2,5 B actifs : 8,1 Go en Q4_K_M, contexte 131 k, une commande Ollama. La même semaine, OpenBMB livre MiniCPM-V 4.7 avec ses GGUF et Liquid AI publie d1-3B-GGUF : les éditeurs n'attendent plus la communauté pour sortir la version locale.
Le modèle d'origine, Mellum2.1-12B-A2.5B-Thinking, compte 64 experts dont 8 actifs par token, sous Apache 2.0, et écrit son raisonnement dans des blocs <think>. D'après la page de liste, sa fiche annonce 47 sur SWE-bench Verified et 82 sur LiveCodeBench ; la page GGUF, elle, ne publie aucun benchmark de capacité et renvoie au modèle d'origine. Elle donne en revanche ce que les GGUF communautaires donnent rarement : une mesure de fidélité par quantisation.
| Fichier | Taille | Divergence KL vs BF16 | Même premier token |
|---|---|---|---|
| BF16 | 24,3 Go | référence | référence |
| Q8_0 | 12,9 Go | 0,008 | 96,1 % |
| Q6_K | 10,9 Go | 0,020 | 93,9 % |
| Q4_K_M (recommandé) | 8,1 Go | 0,075 | 88,0 % |
| MXFP4_MOE | 7,0 Go | 0,115 | 85,6 % |
Ces mesures sont faites sur Wikitext-2 avec un contexte de 512 tokens, donc sur du texte, pas sur du code, et sur un contexte court. En Q4, 12 % des premiers tokens diffèrent de la version complète : à vérifier sur une tâche de code réelle avant d'en faire son agent du quotidien. Paramètres recommandés : température 0,6, top_p 0,95, top_k 20. La base compte 20,6 k téléchargements ; la page en affiche 7,8 k sur le mois.
MiniCPM-V 4.7 35B-A3B est le premier MoE de la série, sous Apache 2.0, avec un LLM issu de Qwen3.6 et un encodeur SigLIP2 qui compresse les tokens visuels par 4 ou par 16. La fiche liste FP8, int4, AWQ, GPTQ, GGUF pour CPU, un modèle de brouillon « DSpark » pour le décodage spéculatif, et une présence sur Ollama. Elle annonce plus de 13 tokens par seconde sur un iPhone 17 Pro Max et un score global supérieur à Qwen3.6 35B-A3B en mode Instruct, mais les chiffres ne sont présentés qu'en images : aucun score OCR ou DocVQA n'est lisible dans le texte, et la mémoire requise n'est pas indiquée. Des guides OCR, PDF et grounding sont fournis. Le petit frère MiniCPM-V-4.7-1B n'a pas pu être lu ce matin : sa page ne répond pas.
d1-3B-GGUF apporte le modèle de décision de Liquid AI, vu le 11 octobre, en 1,67 Go (Q4_K_M), 2,87 Go (Q8_0) ou 5,4 Go (BF16), sous licence LFM 1.0, à relire avant tout usage commercial. L'intérêt est ailleurs : llama.cpp expose directement un point d'entrée /v1/systemone qui accepte un état (texte, JSON, images en base64) et des questions typées. Aucun benchmark sur la page GGUF ; la base compte déjà 16,8 k téléchargements.
Jusqu'ici, la version locale venait de la communauté : Underdog-Saluki (Qwen3.8-27B en 7,9 Go, 242 k téléchargements) ou les Swift-Qwen3.8 vus le 11 octobre. Ces versions arrivent vite, mais sans mesure de fidélité, avec des noms de fichiers variables et parfois des modifications non documentées. Un GGUF d'éditeur apporte trois choses : le modèle de chat et la quantisation sont alignés, la perte est chiffrée, et le serveur de référence est supporté le jour de la sortie. Le revers : les éditeurs ne publient pas toujours les plus petites tailles, et les chiffres de perte restent les leurs.
ollama run hf.co/JetBrains/Mellum2.1-12B-A2.5B-Thinking-GGUF:Q4_K_M. Avec llama.cpp, ramener --ctx-size à 32 768 plutôt que 131 072 si la mémoire manque, et filtrer les blocs <think> côté application.llama-server -hf LiquidAI/d1-3B-GGUF:Q4_K_M, puis un curl sur http://127.0.0.1:8080/v1/systemone avec un ticket et trois questions typées.À surveiller : un GGUF officiel pour d3 et JEV-35B, la fiche du MiniCPM-V-4.7-1B, et des mesures de fidélité sur du code plutôt que sur Wikitext.
", "date_published": "2026-10-13T08:21:00+02:00", "tags": [ "GGUF", "Mellum 2.1", "JetBrains", "MiniCPM-V 4.7", "d1-3B", "llama.cpp", "Ollama", "local" ] }, { "id": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-12-agents-pplx-decider-perplexity.html", "url": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-12-agents-pplx-decider-perplexity.html", "title": "pplx-decider v1.1 : Perplexity prend la tête du Decision Index, JEV-27B-VL garde l'image", "summary": "Perplexity publie pplx-decider-v1.1-27b, un modèle de décision dérivé de Qwen3.8-27B qui ne génère aucun texte et renvoie une probabilité par option. Sa fiche annonce 61,6 au Decision Index, devant Jev (57,9), pendant que JEV-27B-VL d'AutoTrust reste premier du tableau vision.", "content_html": "Perplexity publie pplx-decider-v1.1-27b, un modèle de décision dérivé de Qwen3.8-27B qui ne génère aucun texte et renvoie une probabilité par option. Sa fiche annonce 61,6 au Decision Index, devant Jev (57,9), pendant que JEV-27B-VL d'AutoTrust reste premier du tableau vision.
\nUn modèle de décision ne rédige pas de réponse. On lui donne un texte, éventuellement des images, et une question fermée avec ses options : « facturation », « support » ou « ventes » pour router une demande. Il renvoie une probabilité par option en une seule passe avant. Pas de JSON à réparer, un coût d'inférence prévisible.
\npplx-decider-v1.1 reprend le tronc Qwen3.8-27B et remplace la tête de génération par une tête de décision (un fichier readout.safetensors de 255 × 5 120). La fiche précise une particularité : les couches d'attention complète fonctionnent en mode non causal, chaque token « voit » tout le contexte, comme dans un encodeur. L'entrée est limitée à 8 192 tokens, texte et images compris ; les entrées trop longues sont rejetées plutôt que tronquées. Les images sont ramenées à 512 × 512 pixels au plus pour reproduire les conditions d'évaluation.
Perplexity publie un tableau du Decision Index en cinq catégories. La v1.1 obtient 61,56 au global, contre 56,4 pour la v1 et 57,9 pour Jev. Le gain vient des catégories Language (69,5), Retrieval (61,3) et Knowledge (48,2) ; sur Tools, la v1.1 recule légèrement (78,9 contre 79,3 pour la v1). Ces chiffres sont auto-déclarés. La fiche renvoie au Space Jev Decision Index, dont nous n'avons pu lire que la description, pas le tableau.
\nTrois points pratiques. Les poids pèsent environ 49 Go en BF16 : il faut un GPU de 80 Go ou une quantisation. La fiche ne décrit aucun GGUF officiel ; l'arbre du modèle liste trois quantisations communautaires, sans détail. Enfin, la fiche parle d'un accès Hugging Face authentifié : un jeton peut être nécessaire au téléchargement. Les langues couvertes ne sont pas précisées.
\nQuatre familles partagent désormais le même format d'entrée-sortie. JEV-27B-VL repose sur la même base Qwen3.8-27B, mais garde un tronc intact et ajoute un adaptateur LoRA : il peut donc aussi générer du texte (« System 2 »), accepte jusqu'à 256 k tokens et expose une route /v1/decide dans vLLM. Sa fiche le place premier du Decision Index Vision (69,8, évaluation communautaire du 7 octobre) avec une erreur de calibration de 0,019. Elle précise aussi que la tête de décision n'a été entraînée que sur du texte : les décisions sur image sont zero-shot.
| Modèle | Base | Taille | Entrées | Decision Index (fiche) | Poids | Licence |
|---|---|---|---|---|---|---|
| pplx-decider-v1.1-27b | Qwen3.8-27B | 27 B | texte, image | 61,6 (texte) | ≈ 49 Go BF16 | Apache 2.0 |
| JEV-27B-VL | Qwen3.8-27B + LoRA | 27 B | texte, image, génération | 69,8 (vision) | ≈ 52 Go BF16 | Apache 2.0 |
| clef-omni | Qwen3-Omni-30B-A3B | 30 B, 3 B actifs | texte, image, audio, vidéo | non publié | ≈ 64 Go BF16, 8 quantisations | Apache 2.0 |
| d1-omni-600M | LFM2 | 0,6 B | texte, image, audio 30 s | 15,95 (calcul Liquid AI) | F32, tourne sur CPU | LFM 1.0 |
Deux remarques. clef-omni est le seul à accepter l'audio et la vidéo, mais sa fiche ne publie pas de score Decision Index global, seulement des benchmarks internes (MMLU 92,7 %, 60,2 % d'actions exactes sur un flux de factures). d1-omni-600M est le seul qui tourne sur CPU ; son score de 15,95, calculé par Liquid AI avec le scorer officiel et non soumis au tableau, donne la mesure de l'écart avec les 27 B. Le choix dépend donc du matériel disponible plus que du classement.
\nlm_head complet, ce qui complique les conversions habituelles.--max-num-seqs 8 (obligatoire selon la fiche, sinon les probabilités sont fausses), puis pplx-decider via son script autojev.model en Python 3.12, et comparer sur les mêmes lignes.À surveiller : l'inscription de pplx-decider au tableau communautaire, et l'arrivée d'une version quantisée qui le rendrait exploitable sous 80 Go.
", "date_published": "2026-10-12T08:16:00+02:00", "tags": [ "modèle de décision", "Perplexity", "pplx-decider", "JEV-27B-VL", "Decision Index", "Qwen3.8-27B", "routage", "calibration" ] }, { "id": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-12-documents-youtu-parsing-omni.html", "url": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-12-documents-youtu-parsing-omni.html", "title": "Youtu-Parsing-Omni : Tencent transforme pages, tableaux et audio en un seul JSON", "summary": "Tencent publie Youtu-Parsing-Omni, un modèle de 5 B qui convertit une page de document, un graphique, un organigramme, un fichier audio ou une vidéo en un seul bloc JSON structuré. Sa fiche annonce 97,0 sur OmniDocBench v1.6, au niveau des meilleurs OCR spécialisés, mais il exige un GPU et porte une licence propre.", "content_html": "Tencent publie Youtu-Parsing-Omni, un modèle de 5 B qui convertit une page de document, un graphique, un organigramme, un fichier audio ou une vidéo en un seul bloc JSON structuré. Sa fiche annonce 97,0 sur OmniDocBench v1.6, au niveau des meilleurs OCR spécialisés, mais il exige un GPU et porte une licence propre.
\nLes outils de parsing documentaire produisent en général du Markdown. Youtu-Parsing-Omni renvoie du JSON : chaque élément de la page arrive avec son type, son ordre de lecture et sa boîte englobante sur une grille de 0 à 1 000. Les tableaux sont décrits en OTSL, un format compact convertible en HTML ; les formules en LaTeX ; les graphiques en Markdown ; les organigrammes en Mermaid. Pour l'audio et la vidéo, le même JSON contient la transcription et des horodatages au format HH:MM:SS.
\nLe modèle repose sur un encodeur unique, Youtu-Omni-Encoder, et un décodeur Youtu-LLM. La fiche décrit trois étapes de post-entraînement : affinage supervisé, apprentissage par renforcement guidé par le schéma de sortie, puis distillation. Huit tâches sont exposées par un paramètre --task : document, image naturelle, graphique, organigramme, figure géométrique, audio, vidéo naturelle, vidéo riche en texte.
Sur OmniDocBench v1.6, la fiche donne 96,96 au global, avec un TEDS tableaux de 96,79 et une distance d'édition texte de 0,027. Dans le même tableau, PaddleOCR-VL-1.6 (0,9 B) obtient 96,34, MinerU2.5-Pro (1,2 B) 95,75 et Gemini-3-Pro 92,91. À titre de comparaison, TeleOCR (1,2 B) annonce de son côté 96,87 : un écart de 0,1 point, chacun mesuré par ses auteurs. Sur OmniParsingBench, le benchmark multimodal créé pour l'occasion, le modèle fait 75,08, derrière Gemini-3-Pro (77,44), et se présente comme le meilleur à poids ouverts. Sur la chimie (ChemOCR) et les partitions musicales, il fait jeu égal ou légèrement moins bien que les spécialistes.
\nPlusieurs réserves. Le rapport technique est annoncé « à venir » dans l'en-tête alors que la rubrique actualités le dit publié ; le code d'évaluation est marqué « TBD ». Les langues couvertes ne sont pas précisées : rien n'indique le niveau en français. La licence « youtu-parsing » est un texte propre dont nous n'avons pas lu les clauses ; il faut le faire avant tout usage en entreprise. Le format PDF n'est pas cité : la fiche travaille sur des images de pages. Enfin, l'inférence exige un GPU CUDA et trust_remote_code=True, c'est-à-dire l'exécution de code livré avec le modèle ; la fiche recommande d'épingler une révision précise. Aucune VRAM minimale n'est donnée ; la configuration vLLM publiée fixe un contexte de 65 536 tokens et 70 % de la mémoire GPU.
| Youtu-Parsing-Omni | TeleOCR | |
|---|---|---|
| Taille | 5 B | 1,2 B |
| Entrées | pages, graphiques, audio, vidéo | pages |
| Sortie | JSON (OTSL, LaTeX, Mermaid, boîtes) | texte, OTSL, LaTeX, layout |
| OmniDocBench v1.6 (fiche) | 96,96 | 96,87 |
| Langues annoncées | non précisées | chinois, anglais |
| Licence | youtu-parsing (propre) | Apache 2.0 |
| Local sans GPU | non | GGUF communautaires (llama.cpp, Ollama) |
Le choix est clair pour un PC de bureau : TeleOCR tourne en GGUF et sa licence est permissive. Youtu-Parsing-Omni vise une station ou un serveur, et apporte en échange la sortie JSON unifiée et les modalités audio et vidéo. Pour tester sur des documents réels, le jeu bharat-government-documents repéré ce matin ne conviendra pas : d'après sa fiche, il contient 65 k textes déjà extraits de sites administratifs indiens (40 Go, droits par source), pas de scans.
\nvllm-plugin-vita-omni indiqués par la fiche, puis lancer le serveur compatible OpenAI avec --max-model-len 65536.document, enregistrer le JSON, convertir les tableaux OTSL en HTML et compter les cellules fausses sur deux tableaux par page.À surveiller : la publication du rapport technique et du code d'évaluation, le texte de la licence, et une éventuelle quantisation qui ramènerait le modèle sous 16 Go de VRAM.
", "date_published": "2026-10-12T08:16:00+02:00", "tags": [ "OCR", "parsing documentaire", "Youtu-Parsing-Omni", "Tencent", "JSON", "OmniDocBench", "TeleOCR", "tableaux" ] }, { "id": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-12-local-embeddinggemma-2-gguf.html", "url": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-12-local-embeddinggemma-2-gguf.html", "title": "EmbeddingGemma 2 : la recherche sémantique multilingue tient en 176 Mo sur un PC", "summary": "Google publie EmbeddingGemma 2, un modèle d'embeddings de 0,74 B qui place texte, images, audio et vidéo dans le même espace vectoriel, et Unsloth le décline en GGUF à partir de 176 Mo. Pour une recherche documentaire locale, sans serveur ni API, c'est une brique à essayer.", "content_html": "Google publie EmbeddingGemma 2, un modèle d'embeddings de 0,74 B qui place texte, images, audio et vidéo dans le même espace vectoriel, et Unsloth le décline en GGUF à partir de 176 Mo. Pour une recherche documentaire locale, sans serveur ni API, c'est une brique à essayer.
\nUn modèle d'embeddings transforme un texte (ou une image) en un vecteur de nombres. Deux contenus proches de sens donnent des vecteurs proches : c'est la base de la recherche sémantique et du RAG. EmbeddingGemma 2 totalise 740 M de paramètres selon sa fiche : un tronc texte de 130 M, un « embedder » de 140 M, un encodeur vision de 170 M et un encodeur audio de 300 M. On peut ne charger qu'une partie : 270 M pour le texte seul, 440 M avec les images, 740 M pour tout.
\nLes vecteurs font 768 dimensions, mais le modèle est entraîné en « Matryoshka » : on peut les tronquer à 512, 256 ou 128 dimensions, puis les renormaliser, pour diviser le stockage par six. Le contexte atteint 8 192 tokens, partagés entre modalités (environ 29 images ou 327 secondes d'audio). La fiche annonce plus de 100 langues couvertes et 140 à l'entraînement ; le français n'est pas cité nommément.
\nLes résultats sont ceux de Google DeepMind, sans vérification tierce mentionnée. Sur MTEB multilingue v2, la fiche donne 61,36, contre 61,15 pour la première version : le gain en texte pur est faible. Le progrès est net sur le code (78,68 contre 68,76) et sur les nouvelles modalités : 57,28 en recherche d'images (MMEB v2), 67,84 sur les documents visuels (VisDoc). La troncature coûte peu : 61,17 en 512 dimensions, 60,41 en 256, 57,89 en 128.
\nTrois points à vérifier. La licence, d'abord : l'en-tête affiche Apache 2.0 mais le lien pointe vers un document « gemma_4_license » ; la base Radar l'enregistre comme licence Gemma. À lire avant un usage professionnel. Ensuite, le modèle exige des préfixes de tâche : task: search result | query: pour une requête, title: none | text: pour un document ; les oublier dégrade les résultats. Enfin, la fiche déconseille le float16 (risque de valeurs NaN) et recommande bfloat16 ou float32. Aucun chiffre de mémoire n'est donné.
La fiche Google ne mentionne ni GGUF, ni ONNX, ni MLX, mais son arbre compte 62 quantisations tierces. Celle d'Unsloth est la plus téléchargée (59 k en un mois d'après la page de liste). Elle ne couvre que la partie texte (0,3 B) : pas d'images ni d'audio en GGUF pour l'instant.
\n| Variante | Précision | Taille |
|---|---|---|
| UD-Q4_K_XL | 4 bits | 176 Mo |
| UD-Q5_K_XL | 5 bits | 210 Mo |
| UD-Q6_K_XL | 6 bits | 249 Mo |
| Q8_0 | 8 bits | 310 Mo |
| BF16 / F16 | 16 bits | 558 Mo |
Le Space embeddinggemma-2-webgpu montre l'autre voie : on dépose images, vidéos, sons ou textes, les embeddings sont calculés dans le navigateur via WebGPU, et une requête retrouve les médias correspondants. Rien ne quitte le poste. Sa page ne détaille ni la pile technique ni les prérequis ; un navigateur compatible WebGPU est à prévoir.
\nollama run hf.co/unsloth/embeddinggemma-2-GGUF:UD-Q4_K_XL, ou llama-server -hf unsloth/embeddinggemma-2-GGUF:UD-Q4_K_XL pour obtenir un point d'accès local.SentenceTransformer("google/embeddinggemma-2") et encoder avec prompt_name="SearchQuery" pour les questions et prompt_name="Document" pour les textes.À surveiller : la clarification de la licence et l'arrivée d'une quantisation qui embarque les encodeurs image et audio, condition pour une recherche multimodale vraiment locale.
", "date_published": "2026-10-12T08:16:00+02:00", "tags": [ "embeddings", "EmbeddingGemma 2", "GGUF", "recherche sémantique", "RAG", "Matryoshka", "WebGPU", "multilingue" ] }, { "id": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-12-tendances-semaine-en-bref.html", "url": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-12-tendances-semaine-en-bref.html", "title": "La semaine en bref : la décision typée s'impose, Qwen3.8-27B se compresse", "summary": "Premier bilan hebdomadaire du Radar, bâti sur les deux éditions disponibles. Les modèles de décision deviennent une catégorie à part entière, et Qwen3.8-27B sert de socle à la moitié des nouveautés qui tournent en local.", "content_html": "Premier bilan hebdomadaire du Radar, bâti sur les deux éditions disponibles (la base a démarré le 11 octobre). La ligne est déjà nette : les modèles de décision deviennent une catégorie, et Qwen3.8-27B sert de socle à la moitié des nouveautés qui tournent en local.
\nEn trois semaines, Cloudflare (clef, clef-flash, clef-omni), Convai (laya), Liquid AI (d1-3B, d1-omni-600M), Fastino (GLiNER2.5-Decide), AutoTrust (JEV-27B-VL) et Perplexity (pplx-decider-v1.1-27b) ont publié ou mis à jour un modèle qui répond à une question fermée par des probabilités, sans générer de texte. Tous se mesurent au même Decision Index communautaire et au jeu typed-decisions (1,6 k lignes, dont des factures). JEV-27B-VL ouvre le classement du jour avec un score Radar de 84.
\nSept des quinze premières entrées du classement du jour sont des dérivés de Qwen3.8-27B : Saluki (7,9 Go, appel d'outils conservé), Swift (58 % de tokens de réflexion en moins), Ternary-Bonsai-2, le GGUF GSQ-RCO d'ISTA et le GGUF d'Unsloth ; OrcaSAQ-2 (12,3 Go) suit un peu plus loin. Les deux décideurs 27 B de la semaine en sont issus aussi. Point de vigilance relevé par la Veille : des licences « ouvertes sous condition de chiffre d'affaires » apparaissent sur certains dérivés.
\nTeleOCR (1,2 B, Apache 2.0, GGUF communautaires) reste la référence pour un PC. Tencent ajoute Youtu-Parsing-Omni (5 B, GPU requis), qui produit un JSON unifié pour pages, tableaux, audio et vidéo. Les petits décideurs (GLiNER2.5-Decide, d1-omni-600M) couvrent le tri et le routage en amont.
\nparakeet-redux tient en 178 Mo pour 25 langues dont le français, sur CPU. En face, le corpus yodas3 (plus de 1,1 million d'heures, 100 langues et plus, CC-BY 3.0) fournit de quoi évaluer ou affiner, avec environ 102 k lignes en français d'après la fiche de liste.
\nEmbeddingGemma 2 (0,74 B) arrive avec un GGUF Unsloth de 176 Mo et une démo WebGPU qui calcule tout dans le navigateur. Côté code, JetBrains publie Mellum2.1-12B-A2.5B-Thinking : 12 B dont 2,5 B actifs, Apache 2.0, GGUF officiels annoncés mais pas encore en ligne.
\nClassement des éléments créés depuis sept jours, généré le 12 octobre à 7 h 30. Le delta compare au rang de la veille ; « nouveau » signale une première entrée.
\n| Rang | Élément | Score | Likes | Téléchargements | Delta |
|---|---|---|---|---|---|
| 1 | Swift-Qwen3.8-27B-GGUF | 77 | 406 | 189 k | +1 |
| 2 | Underdog-Saluki-27B-1.0 | 75 | 327 | 109 k | +2 |
| 3 | Swift-Qwen3.8-27b | 74 | 583 | 19,1 k | 0 |
| 4 | embeddinggemma-2-GGUF | 73 | 259 | 59,3 k | +1 |
| 5 | Qwen3.8-27B-Coder390 (nerkyor) | 73 | 241 | 56,5 k | +1 |
| 6 | d1-3B | 70 | 301 | 10,8 k | +2 |
| 7 | typed-decisions | 70 | 163 | 38,5 k | 0 |
| 8 | Fable-5.1-Max-Reasoning-Filtered-10000x | 69 | 304 | 5,3 k | +2 |
| 9 | GLiNER2.5-Decide | 69 | 167 | 14,8 k | 0 |
| 10 | d1-omni-600M | 66 | 105 | 10,5 k | nouveau |
Lecture : les quantisations de Qwen3.8-27B dominent par les téléchargements, les modèles de décision par le nombre d'entrées (quatre sur dix). Les likes restent modestes partout, signe d'une période encore jeune pour ces sorties.
\nÀ surveiller la semaine prochaine : les GGUF officiels de Mellum 2.1, une quantisation de pplx-decider, et la première comparaison indépendante entre TeleOCR et Youtu-Parsing-Omni sur des documents en français.
", "date_published": "2026-10-12T08:16:00+02:00", "tags": [ "semaine en bref", "modèles de décision", "Qwen3.8-27B", "GGUF", "OCR", "transcription", "embeddings", "classement" ] }, { "id": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-11-audio-parakeet-redux.html", "url": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-11-audio-parakeet-redux.html", "title": "parakeet-redux : la transcription en 25 langues tient désormais en 178 Mo", "summary": "Moondream publie une version à poids ternaires du parakeet de NVIDIA. Le français y est, le CPU suffit, et l'horodatage par mot est inclus. Le taux d'erreur monte un peu : la question est de savoir si c'est acceptable pour des comptes rendus de réunion.", "content_html": "parakeet-redux est une version à 1,58 bit (poids ternaires) du modèle parakeet-tdt-0.6b-v3 de NVIDIA. Le fichier passe de 1,2 Go à 178 Mo, pour 25 langues dont le français, sous licence CC-BY-4.0. Sur huit cœurs x86, la fiche annonce 113 fois le temps réel : une heure de réunion transcrite en une trentaine de secondes, sans GPU.
\nLes chiffres sont publiés et honnêtes. En anglais, le taux d'erreur de mots passe de 6,26 % à 6,55 %. En français (FLEURS), il passe de 4,81 % à 7,71 % : c'est l'écart le plus visible. Avec du bruit de fond, l'original tient mieux (6,72 % contre 9,04 %). En moyenne sur toutes les langues, le modèle compressé fait pourtant légèrement mieux (10,56 % contre 11,62 %).
\nPour un flux en français, Whistle (17 Mo) reste la référence de l'ultra-léger, et le parakeet original reste plus précis. parakeet-redux se place entre les deux : plus de langues et des horodatages, dans un format qui évite le GPU. Associé à Nemotron-3-Diarization pour savoir qui parle, il forme une chaîne complète de compte rendu de réunion entièrement locale.
\nLe test à faire : un enregistrement réel de trente minutes, transcrit par les trois modèles, puis une relecture des passages techniques. Si l'écart de 3 points de WER ne touche que des mots courants, la version compressée suffit.
", "date_published": "2026-10-11T08:20:00+02:00", "tags": [ "transcription", "ASR", "français", "CPU", "poids ternaires", "parakeet", "Whistle" ] }, { "id": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-11-documents-gliner-decision.html", "url": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-11-documents-gliner-decision.html", "title": "Trier des documents sans générer un mot : GLiNER2.5-Decide rejoint la vague des modèles de décision", "summary": "Fastino publie un classifieur de 340 millions de paramètres qui répond à plusieurs questions typées en un seul appel, sur CPU. Quatrième acteur en trois semaines sur un créneau qui intéresse directement le traitement documentaire.", "content_html": "Depuis trois semaines, une famille de modèles se détache sur Hugging Face : les modèles de décision. Au lieu de produire un texte, ils renvoient une réponse typée (oui ou non, un choix parmi une liste, une note sur une échelle) accompagnée d'une probabilité calibrée. Cloudflare a ouvert le bal avec Clef et Clef-Flash, Convai a suivi avec Laya (0,4 B, numéro 1 des likes sur trente jours), Liquid AI avec d1-3B en version multimodale. Fastino complète la série avec GLiNER2.5-Decide.
\nGLiNER2.5-Decide est un fine-tune de gliner2-large de 340 millions de paramètres, sous licence Apache 2.0. On lui donne un passage de texte et une ou plusieurs questions : une question fermée, un choix multiple, une échelle ordinale, une étiquette multi-label. Il répond à toutes en un seul appel, sans raisonnement intermédiaire ni texte libre. La fiche annonce 60,2 % de précision moyenne sur le benchmark maison « fast-decisions », évalué en anglais. Le modèle tourne sur CPU via la bibliothèque gliner2, ce qui le place dans la même catégorie d'usage que Laya.
Pour les textes non anglais, Fastino renvoie vers GLiNER2.5-multi-Decide (287 M), étiqueté multilingue. Le français n'y est pas évalué explicitement : c'est le premier point à vérifier.
\nLe tri de courriers, de procès-verbaux ou de fiches de non-conformité se résume souvent à quelques décisions : à traiter ou à archiver, urgent ou non, quel service, quelle criticité. Un LLM génératif sait le faire, mais il est lent, coûteux et difficile à calibrer. Un modèle de décision répond en quelques millisecondes, sur une machine sans GPU, et fournit une confiance exploitable pour router les cas douteux vers un humain.
\nLa communauté s'est d'ailleurs dotée d'un premier jeu d'évaluation neutre : typed-decisions, 1 600 décisions réparties en quatre domaines, dont un sous-ensemble invoice_processing (traitement de factures). C'est le terrain idéal pour comparer GLiNER2.5-Decide, Laya, d1-3B et Clef-Flash sur des cas proches du réel.
\ngliner2, charger la variante multi-Decide, et lui soumettre une vingtaine de documents déjà classés à la main avec deux questions : « À traiter ? » (oui/non) et « Urgence » (0 à 5).Le point de vigilance reste la langue : si la variante multilingue décroche sur le français, d1-3B (multimodal, 3 B) ou Clef-Flash (9 B) restent les options locales les plus solides, au prix d'un GPU.
", "date_published": "2026-10-11T08:20:00+02:00", "tags": [ "décision typée", "classification", "CPU", "GLiNER", "Laya", "Clef", "documents" ] }, { "id": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-11-local-qwen38-27b-compresse.html", "url": "https://clauzelfamille-dot.github.io/radar-ia/articles/2026-10-11-local-qwen38-27b-compresse.html", "title": "Qwen3.8-27B en 8 à 12 Go : trois façons de faire tourner un agent sur un PC", "summary": "Saluki, OrcaSAQ et Swift compressent ou raccourcissent le même modèle socle. Tour d'horizon de ce que chacun sacrifie, et d'une licence à lire avant de déployer.", "content_html": "Avec 17 400 likes et 6,8 millions de téléchargements, Qwen3.8-27B est le modèle socle de la rentrée. En BF16 il pèse 54 Go, hors de portée d'un PC. Trois dérivés apparus ces dix derniers jours visent le même objectif : garder ses capacités d'agent (appel d'outils, mode réflexion, long contexte) dans un format qui tient sur une carte grand public.
\nUnderdog-Saluki-27B-1.0 (Conway Research) ramène le modèle à 7,9 Go en quantisation IQ2 avec entraînement, en annonçant l'appel d'outils intact. C'est le choix pour une carte de 8 Go ou un portable. Le prix se paie en finesse de raisonnement sur les tâches longues, ce que la fiche ne cache pas.
\nOrcaSAQ-2-27B applique une quantisation mixte à 3,21 bits par poids en moyenne : 12,3 Go, contexte de 262 000 tokens, appel d'outils et mode réflexion conservés, licence Apache 2.0. La fiche annonce une perplexité à +0,02 % du BF16 et un SWE-bench Verified à 70. Ces chiffres sont auto-déclarés, mais l'ordre de grandeur est cohérent avec ce que fait ISTA-DASLab sur le même modèle. Sur une carte de 16 Go, c'est l'option à essayer en premier pour un agent local.
\nSwift-Qwen3.8-27b ne compresse pas : c'est un adaptateur LoRA qui pénalise les marqueurs de « sur-réflexion ». Résultat annoncé : 58 % de tokens de réflexion en moins, une vitesse multipliée par 1,95, et une qualité stable sauf sur AIME (98,7 à 94). Une version GGUF existe. Attention à la licence : « Swift Open License v1.0 », gratuite sous un million de dollars de chiffre d'affaires annuel, licence Enterprise au-delà. Pour un usage en entreprise, ce n'est pas un modèle ouvert au sens habituel.
\n| Dérivé | Poids | Ce qu'il garde | Licence |
|---|---|---|---|
| Saluki | 7,9 Go | Appel d'outils | Ouverte |
| OrcaSAQ-2 | 12,3 Go | Outils, réflexion, 262 k de contexte | Apache 2.0 |
| Swift | Comme l'original (GGUF disponibles) | Tout, en réfléchissant moins | Sous conditions de CA |
La tendance de fond est claire : la quantisation sous 3 bits avec entraînement devient la norme du local, et Qwen3.8-27B en est la plateforme. Prochaine étape à surveiller : les mêmes techniques appliquées aux modèles de 9 B, qui tiendraient alors en moins de 4 Go.
", "date_published": "2026-10-11T08:20:00+02:00", "tags": [ "Qwen3.8-27B", "quantisation", "GGUF", "appel d'outils", "agents locaux", "licence" ] } ] }