---
title: Le paysage des modèles ouverts à la mi-2026
description: "Qwen3.8, Kimi K3, GLM-5.2, MiniMax M3, DeepSeek V4 : panorama des
  modèles open-weight fin 2026 et pourquoi l'attention linéaire hybride change
  la donne."
date: 2026-06-14T00:00:00.000Z
dateModified: 2026-08-24T00:00:00.000Z
author:
  name: Antoine Michéa
  url: https://sobercloud.fr/
  sameAs:
    - https://altilink.eu/
tags:
  - llm
  - modeles
  - moe
  - qwen
  - deepseek
  - attention-lineaire
section: Référence
canonical: https://sobercloud.fr/decouvertes/paysage-modeles-ouverts-2026/
---

# Le paysage des modèles ouverts à la mi-2026

Fin 2026, le paysage des modèles ouverts s'est structuré autour de **deux** sparsités, pas d'une seule. La première, le Mixture-of-Experts, n'active qu'une fraction des paramètres par token — elle est désormais partout. La seconde est plus récente et change davantage l'économie de l'inférence : l'**attention linéaire hybride**, qui remplace l'essentiel des couches d'attention quadratique par des couches à état récurrent. Voici notre lecture du terrain, mesures à l'appui sur notre propre infrastructure.

## La tendance de fond : la sparsité partout

Le constat structurant de 2026, c'est la généralisation de trois techniques qu'on détaillait encore comme des nouveautés il y a un an :

- le **MoE** pour ne réveiller qu'une fraction des paramètres par token ;
- la **Multi-head Latent Attention (MLA)** pour comprimer le cache KV ;
- la **Multi-Token Prediction (MTP)** et l'**attention clairsemée** pour accélérer le décodage et le contexte long.

Ces briques ne sont pas des secrets de laboratoire : elles sont publiées et présentes dans les moteurs open source. C'est ce qui explique que des modèles très différents convergent vers la même physionomie.

## La vraie rupture de 2026 : l'attention linéaire hybride

L'attention classique coûte cher deux fois : en calcul (quadratique avec la longueur) et surtout **en mémoire**, puisqu'il faut conserver un cache KV proportionnel au nombre de tokens. C'est ce cache, et non les poids, qui plafonne le contexte servable sur une carte donnée.

Les modèles de fin 2026 attaquent le problème à la racine en ne gardant qu'une minorité de couches d'attention complète, le reste passant en **attention linéaire à état récurrent** : un état de taille *constante* remplace un cache qui grandit à chaque token. Qwen3.8 emploie du **Gated DeltaNet (GDN)**, Kimi K3 une variante maison (**KDA**) ; les moteurs d'inférence exposent désormais ces deux familles explicitement.

L'effet est spectaculaire sur le terrain. Sur notre Qwen3.8-27B, **16 couches sur 64 seulement** font de l'attention complète : le cache KV retombe à **32 Kio par token en FP8**, contre plus de 40 Kio pour un dense classique de la génération précédente — et c'est précisément ce qui nous permet de servir **185 000 tokens de contexte sur une seule carte de 32 Go**, spéculation comprise.

La contrepartie est réelle et peu documentée : un état récurrent **ne se découpe pas** comme un cache KV. Réutiliser le préfixe d'une conversation (le *prefix caching*) exige de sauvegarder l'état de ces couches aux points de reprise, ce qui consomme de la mémoire et se paie en contexte ou en parallélisme. Nous détaillons cet arbitrage, chiffres en main, dans [Le cache KV expliqué](/decouvertes/cache-kv/).

## Les familles qui comptent

| Modèle | Type | Total | Actifs / token | Publié |
|---|---|---|---|---|
| **Qwen3.8-27B** (dense hybride GDN) | Dense | 27B | 27B | août 2026 |
| **Qwen3.6-35B-A3B** | MoE | 35B | **3B** | avril 2026 |
| **Gemma 4** (Google) | Dense + MoE (12B à 31B, A4B) | — | — | 2026 |
| **GLM-5.2** | MoE | ~744B | ~40B | juillet 2026 |
| **Kimi K3** | MoE, attention linéaire KDA | ~1 T | ~32B | août 2026 |
| **MiniMax M3** | MoE | ~428B | — | juillet 2026 |
| **DeepSeek V4 Pro / V4 Flash** | MoE, attention clairsemée | — | — | juin 2026 |

Quelques lectures de ce tableau :

- **Qwen3.8-27B** est notre cheval de bataille depuis août 2026. C'est un **dense**, et son retour en grâce mérite une explication : l'attention linéaire hybride lui rend le contexte long abordable, tandis que les quantifications 4 bits matérielles (voir plus bas) effacent une partie de son handicap de bande passante. Le MoE **Qwen3.6-35B-A3B** reste servi sur notre nœud à mémoire unifiée, où il garde l'avantage — l'arbitrage est détaillé dans [Dense ou MoE sur Strix Halo](/decouvertes/dense-vs-moe-strix-halo/). Il n'existe pas, à ce jour, de déclinaison MoE en 3.8 : les deux générations cohabitent donc chez nous, chacune sur le matériel qui lui convient.
- **Gemma 4** continue de « frapper au-dessus de son poids » : d'excellentes performances pour des tailles modestes, ce qui en fait un candidat sérieux quand la mémoire est comptée.
- **GLM-5.2** et **Kimi K3** illustrent l'autre extrême : des MoE géants (jusqu'au trillion de paramètres) qui, grâce à la sparsité, n'activent qu'une poignée de milliards de paramètres par token. Ils demandent beaucoup de **capacité** mémoire pour stocker les experts, mais une bande passante seulement modérée — exactement le profil que servent bien les plateformes à mémoire unifiée généreuse.
- **DeepSeek V4** pousse l'efficacité du contexte long : attention clairsemée et coût par token nettement réduit, pour des contextes de l'ordre du million de tokens. La déclinaison **V4 Flash** reprend la même architecture avec une empreinte mémoire bien moindre — nous l'avons testée, et le verdict n'a pas été celui attendu : voir [Logiciels d'inférence](/decouvertes/logiciels-inference/).
- **MiniMax M3** complète le tableau des grands MoE ouverts publiés cet été.

## Capacité contre bande passante : le bon matériel a changé

Cette bascule vers les gros MoE redéfinit ce qu'est une bonne machine d'inférence. Un MoE géant n'a pas besoin de la bande passante d'un GPU datacenter ; il a besoin de **place pour loger ses experts**. C'est ce qui propulse les architectures à mémoire unifiée — Apple Silicon, APU AMD Strix Halo, et les nouvelles plateformes Grace + Blackwell à 128 Go de mémoire partagée — comme terrain naturel de l'inférence locale.

On retrouve ici l'arbitrage qu'on développe dans [Choisir son matériel](/decouvertes/choix-du-materiel/) : sur un MoE, ce qui compte n'est pas le nombre de paramètres totaux mais le nombre de paramètres **actifs** par token, et la capacité à tous les loger en mémoire.

## Ce qu'on en garde pour une infra sobre

La leçon est cohérente avec notre ligne : la qualité brute des modèles fermés reste légèrement devant, mais **l'ingénierie qui rend l'inférence efficace est ouverte**. MoE, MLA, sparse attention, quantification — tout est disponible. Pour qui veut servir des LLM performants sur du matériel modeste, sans dépendre d'une API ni d'un marché mémoire sous tension (voir [Pénurie de mémoire 2026](/decouvertes/penurie-memoire-2026/)), le paysage mi-2026 n'a jamais été aussi favorable.

Notre production sert aujourd'hui **Qwen3.8-27B** sur deux matériels très différents : quantifié en **NVFP4** sur une carte Blackwell, et en GGUF sur un APU à mémoire unifiée — le même modèle, deux économies. Le MoE Qwen3.6-35B-A3B reste en service là où la capacité prime sur la bande passante. C'est un point d'équilibre entre qualité, débit et empreinte mémoire, qu'on réévalue à chaque nouvelle famille — et qu'on documente, y compris quand la mesure contredit l'intuition.

## Pour aller plus loin

- [Comprendre les LLM open source](/decouvertes/comprendre-les-llm-open-source/)
- [Dense ou MoE sur Strix Halo](/decouvertes/dense-vs-moe-strix-halo/)
- [Benchmarks LLM : lire les scores sans se faire piéger](/decouvertes/benchmarks-llm/)
- [Pénurie de mémoire 2026](/decouvertes/penurie-memoire-2026/)