Ce que ces modèles font

L'« 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.

Ce que les fiches annoncent et ce qu'il faut vérifier

OrcaRouter 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 »).

La 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.

Comment les situer

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.

Comment les essayer, si vous y tenez

1. Installer d'abord la référence : ollama 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.
2. Charger la variante abliterée dans le même outil (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).
3. Comparer les sorties deux à deux : si aucune requête du jeu n'était refusée par la référence, l'écart ne peut être que négatif ou nul.
4. Ne jamais exposer ces variantes à des utilisateurs externes sans filtre en amont.

À 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.

Mellum 2.1 en GGUF : ce que la fiche donne

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.

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 et d1-3B : deux autres livraisons directes

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.

Face aux GGUF communautaires

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.

Comment l'essayer

1. Mellum, sur un PC avec 16 Go de RAM ou une carte de 12 Go : 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.
2. d1-3B : 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.
3. MiniCPM-V 4.7 : passer par Ollama ; la fiche ne donne pas la taille des GGUF, prévoir au moins les 3 B actifs en mémoire vive plus le reste des experts sur disque ou en RAM.
4. Comparer Mellum Q4_K_M et Q6_K sur une même tâche de dépôt (ajouter un test, corriger un bug) et noter les écarts : c'est la seule façon de savoir ce que valent les 12 % de tokens perdus.

À 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.

Ce que fait le modèle

Un 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.

Les 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.

Ce que la fiche annonce, et ce qu'il faut vérifier

Les 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.

Trois 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é.

Les versions GGUF et la démo navigateur

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.

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.

Comment l'essayer

1. Installer la version GGUF : ollama 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.
2. En Python, charger SentenceTransformer("google/embeddinggemma-2") et encoder avec prompt_name="SearchQuery" pour les questions et prompt_name="Document" pour les textes.
3. Constituer un lot de 200 documents internes en français (comptes rendus, procédures), indexer en 256 dimensions, puis noter si les 10 premiers résultats de 20 questions sont pertinents. Refaire la mesure en 768 dimensions pour voir si la troncature coûte quelque chose sur votre corpus.
4. Pour les scans et schémas, tester la version complète (740 M) en bfloat16 : c'est elle qui indexe les images.

À 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.

Saluki : 7,9 Go, le plus petit

Underdog-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.

OrcaSAQ-2 : 12,3 Go, le plus fidèle

OrcaSAQ-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.

Swift : moins de réflexion, pas moins de poids

Swift-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.

Lequel choisir

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.