Mac M6, Kepler, MoE à 1,75 bit : le local avance par les bords

Le Neural Engine d'un Mac Mini M6, avec 192K de contexte

ANEMLL Forge 0.2.1 fait tourner Qwen3.8-27B sur le Neural Engine d'un Mac Mini M6 doté de 32 Go de mémoire, avec un contexte qui grimpe jusqu'à 192K. La mécanique repose sur deux ajouts : un cache K/V en INT8, soit la moitié du FP16, et un drafter plus petit qui partage la tête de sortie du modèle cible. Gain annoncé : 0,86 Go d'ANE économisé, à vitesse égale.

Les débits, eux, dépendent franchement du contenu produit : 35 à 62 tok/s en JSON, 18 à 32 en code, 10 à 17 en prose. Le prefill suit la même pente, avec 260 tok/s en contexte court contre 62 tok/s quand on remplit les 192K. Autrement dit, la fenêtre géante se paie, et le type de sortie attendu pèse autant que la machine.

Kepler : un fork pour ne pas jeter les vieux GPU

Un développeur publie un fork de llama.cpp dédié aux vieux GPU NVIDIA Kepler et aux cartes antérieures à Ampere. L'objectif assumé n'est pas la performance brute mais la prolongation : faire tourner le logiciel sur du matériel qu'on n'upgrade plus, plutôt que de le mettre au rebut. Le blocage se situait à l'initialisation ; des correctifs sur le type de calcul cuBLAS débloquent le lancement sur du cc35-50, qui échouait jusqu'ici.

La démonstration tient sur Qwen3.6-35B-A3B en Q8_0 avec quatre Tesla K40c : on passe d'un démarrage impossible à 35 tps, puis environ 55 tps une fois les CUDA graphs activés. Des chiffres qui ne rivalisent pas avec du matériel récent, mais qui transforment un parc inutilisable en banc d'essai fonctionnel.

DeepSeek-V4.1-Flash-1017 descend à 1,75 bit par poids

ISTA publie trois GGUF quantifiés de DeepSeek-V4.1-Flash-1017, un MoE clairsemé de 763,2 milliards de paramètres (6 experts actifs sur 384 par couche) et 1M de contexte. Les builds IQ1_M, IQ2_XXS et IQ2_XS descendent entre 1,75 et 2,25 bits par poids, pour des fichiers de 120,7 à 155,2 Go.

Détail malin côté téléchargement : un fichier Engram de 110,6 Go, identique pour tous les builds, ne se récupère qu'une seule fois. Et chaque build tourne sur un seul GPU de 12 Go avec Strata. À ces niveaux de quantification, la place gagnée ne se discute pas ; la fidélité du modèle, elle, est le paramètre qu'on accepte de bouger.

Kimi : poids ouverts, entraînement filtré

Latent Space relaie la sortie de Kimi 3.1 Pro (104BA-2.8T), un modèle à poids ouverts que la newsletter range dans la catégorie de Fable-5.1. L'écart avec les modèles fermés tomberait ainsi à environ un mois. Une API Pro Highspeed est aussi annoncée, avec un débit 2 à 3 fois supérieur — la newsletter prenant toutefois ses distances avec l'annonce.

En parallèle, la publication open weight de Kimi K3.1 ne contient plus les données d'entraînement portant sur les cyberattaques. D'après l'extrait partagé sur r/LocalLLaMA, ce retrait s'explique avant tout par les nouvelles restrictions chinoises à l'export, auxquelles s'ajoute une prudence croissante face à la multiplication des exploits en cybersécurité.

Les deux mouvements ne se contredisent pas : les poids s'ouvrent, mais le contenu de l'entraînement se trie de plus en plus avant publication.

Et maintenant ?

Le fil commun de ces sorties n'est pas la performance brute mais la gestion de contraintes : quelques bits de moins par poids, un cache K/V divisé par deux, un GPU de génération ancienne qu'on débloque à coups de correctifs cuBLAS. L'inférence locale se construit moins sur des modèles toujours plus gros que sur l'art de les faire tenir là où ils ne devaient pas passer. Ce que Kimi rappelle en creux : la disponibilité des poids ne dit rien de ce qu'ils contiennent.