Quels modèles tournent réellement sur MLX

Première question : y a-t-il un fichier safetensors ?

MLX charge des safetensors. Pas du GGUF, pas des .bin PyTorch, pas de l'ONNX, pas du GGML.

C'est de loin la déception la plus fréquente, et la raison en est que l'essentiel du matériel sur « l'exécuter en local » ne parle pas du tout de MLX : il parle de llama.cpp, dont le conteneur GGUF n'est pas interchangeable avec les safetensors. GGUF est le conteneur de llama.cpp ; il transporte ses propres schémas de quantisation et ses propres métadonnées, et le lire signifierait implémenter ce conteneur. Un modèle publié uniquement en GGUF ne tourne pas sur MLX, et aucune configuration au monde n'y change rien.

Le raccourci pratique : cherchez une version du modèle chez mlx-community. Cette organisation republie des modèles convertis en safetensors MLX, en général dans plusieurs quantisations, et s'il en existe une, c'est presque toujours la bonne chose à télécharger.

Un dépôt qui ne contient que pytorch_model.bin est également hors jeu, ce qui surprend parce que les poids sont « là ». Un exemple réel : BAAI/bge-m3 ne publie que des poids PyTorch, donc il ne se charge pas — et la raison est le format, pas l'architecture, qui, elle, est prise en charge.

Deuxième question : que dit model_type ?

Ouvrez le config.json du dépôt — Hugging Face l'affiche dans le navigateur — et cherchez model_type. Cette chaîne décide quelle implémentation lit les poids, et si rien ne l'implémente, le modèle ne se charge pas.

Deux choses méritent d'être sues à propos de cette chaîne, parce que toutes deux mènent à des conclusions fausses.

Les alias existent. mistral est un autre nom de llama du point de vue de l'implémentation : l'architecture a la même forme, donc un modèle Mistral tourne partout où llama tourne, alors que rien dans le nom ne le laisse deviner. La bibliothèque de MLX tient une table de correspondance pour cela, et c'est elle qu'il faut consulter plutôt qu'une liste tapée par quelqu'un.

Les modèles de vision se cachent derrière des noms de modèles de texte. gemma3 et qwen2_5_vl ont un model_type qui ressemble à celui d'un modèle de texte, et vérifier l'architecture en premier laisse passer un modèle de vision. Les signaux fiables sont ailleurs dans le dépôt : un preprocessor_config.json, un bloc vision_config dans le config.json, ou un nom contenant _vl, vision, llava ou paligemma. Cherchez-les avant de regarder la famille.

Troisième question : comment est-il quantisé ?

Les modèles MLX quantisés portent dans config.json un bloc quantization avec le nombre de bits et la taille de groupe. Quatre bits est le cas courant et fonctionne bien ; huit bits coûte plus de mémoire et reste plus proche de l'original.

Le piège ici s'appelle quantisation par tenseur. Certains éditeurs quantisent différents tenseurs à différentes précisions et consignent cela sous forme de table dans la configuration plutôt que comme un réglage unique. Un moteur qui applique une seule quantisation à tout le modèle lira ces poids avec le mauvais nombre de bits — et cela n'échoue pas bruyamment. Cela produit des nombres faux d'une manière qui ressemble encore à du texte.

Un exemple réel qui trébuche là-dessus : Qwen3.8-27B-Uncensored-OptiQ-4bit. Le nom dit quatre bits ; la configuration dit autre chose pour certains tenseurs.

Quatrième question : la configuration déclare-t-elle quelque chose d'exotique ?

Trois champs provoquent une fausseté silencieuse plutôt qu'un échec net, et c'est pourquoi un moteur soigneux les refuse au lieu de deviner.

rope_scaling décrit comment l'information de position est étirée pour atteindre un contexte plus long. default, llama3 et yarn sont les schémas couramment implémentés. Autre chose signifie que les positions seront calculées autrement que la façon dont le modèle a été entraîné, et la sortie sera plausible et dégradée plutôt que visiblement cassée.

À savoir sur YaRN en particulier : lorsqu'il déclare mscale_all_dim, il met aussi à l'échelle l'attention et pas seulement les fréquences. Manquer cela ne produit pas d'erreur : cela produit des logits tous décalés du même facteur, si bien que le classement paraît encore sensé alors que les valeurs ne le sont pas.

sliding_window limite jusqu'où l'attention remonte. Et voici le piège, un beau : Qwen2.5 déclare sliding_window: 131072 puis pose use_sliding_window: false. Une vérification qui ne lit que le premier champ rejette un modèle parfaitement sain. Il faut lire les deux.

layer_types apparaît sur les modèles qui mélangent des sortes d'attention selon les couches. Autre chose que l'attention complète sur chaque couche signifie que le modèle attend un comportement qu'une implémentation simple ne fournit pas.

Cinquième question : est-ce que ça rentre ?

MLX tourne sur le GPU, et sur Apple Silicon le GPU partage la mémoire avec tout le reste. Le plafond n'est pas le chiffre de RAM inscrit sur la boîte : c'est l'ensemble de travail que Metal recommande, et il est plus bas. Sur une machine de 24 Go, cela est revenu à 23347 Mo — et c'est le plafond pour tout, pas seulement pour les poids.

Une estimation grossière qui tient : les poids sur le disque sont proches de la mémoire qu'ils occupent, et une invite longue coûte nettement plus par-dessus. Mesuré sur un petit llama, le pic de mémoire avec une invite de 4096 jetons valait 1,68× les poids. Doubler la taille des poids est un chiffre de planification sûr.

Ainsi, un modèle en quatre bits dont les fichiers totalisent 8 Go veut environ 16 Go disponibles pour être à l'aise avec de longues invites — ce qui, sur une machine de 16 Go, signifie que c'est la seule chose que vous faites tourner.

Lire une fiche de modèle sans se faire abuser

Les fiches sont écrites par des gens contents de leur modèle, ce qui est légitime, et elles ne sont pas écrites pour vous dire s'il se chargera. Trois habitudes aident.

Ignorez le nombre de paramètres dans le nom et regardez la taille des fichiers. « 7B » vous renseigne sur l'architecture, pas sur ce que vous allez télécharger. Le même modèle 7B existe en 15 Go de poids sur 16 bits, en 8 Go sur 8 bits et en 4 Go sur 4 bits, et le nom est identique dans les trois cas. La liste des fichiers est le chiffre honnête.

Ignorez entièrement les tableaux de benchmarks pour cet usage. Ils ne disent rien du format, et un modèle qui obtient de bons scores et ne se charge pas obtient zéro sur votre machine.

Regardez ce que le dépôt contient réellement plutôt que ce que la fiche décrit. Il arrive souvent qu'une fiche décrive le modèle d'origine alors que le dépôt héberge une conversion, ou l'inverse. Les fichiers n'ont pas d'opinion.

Quand la réponse est « pas encore »

Il existe une réponse intermédiaire entre « tourne » et « ne tourne pas », et elle mérite d'être comprise parce que beaucoup de modèles atterrissent là.

La bibliothèque de MLX implémente bien plus de cent architectures. Un moteur donné en implémente moins — Runlix en implémente six — et l'écart n'est un défaut d'aucun côté : une architecture traduite doit être vérifiée contre une référence avant qu'on puisse lui faire confiance, et c'est la vérification qui prend le temps.

Il vaut donc la peine de consulter deux listes au lieu d'une : les architectures propres au moteur, et celles de la bibliothèque. Une famille qui figure dans la seconde et pas dans la première est pas encore — connue, traduisible, en attente de vérification. Une famille qui ne figure dans aucune est une autre histoire : aujourd'hui personne ne l'exécute sur MLX, et attendre un moteur n'y change rien.

Ce que rien de tout cela ne vous dit

Tout ce qui précède porte sur le fait que les poids se chargent et produisent des nombres. Cela ne dit rien sur la qualité du modèle, sur la façon dont il parle votre langue, sur ce que sa licence autorise, ni sur le fait que la quantisation lui ait coûté quelque chose qui compte pour votre tâche.

La quantisation en quatre bits, en particulier, n'est pas gratuite. C'est en général un bon échange, et sur les petits modèles ce ne l'est parfois pas — plus le modèle est petit, plus chaque bit faisait un travail. Si un modèle en quatre bits vous déçoit, essayer la version en huit bits du même modèle est une expérience moins coûteuse que d'en changer.

La version courte

Avant de télécharger, vérifiez cinq choses, dans cet ordre :

1. safetensors présents — sinon, arrêtez ;
2. ce n'est pas un modèle de vision — vérifiez d'abord preprocessor_config.json et vision_config, parce que le nom ne vous le dira pas ;
3. model_type est implémenté — en vous souvenant que les alias existent et que mistral veut dire llama ;
4. la quantisation est un réglage, pas une table par tenseur ;
5. rope_scaling, sliding_window et layer_types sont ordinaires — et lisez les deux champs de la fenêtre glissante.

Pourquoi « je ne sais pas » est une vraie réponse

Chacune de ces vérifications peut rester sans conclusion : le dépôt peut ne pas répondre, ou n'avoir aucun config.json. La tentation est de deviner, parce qu'un verdict paraît plus utile qu'un haussement d'épaules.

Il ne l'est pas. Un moteur qui devine quand il ne peut pas savoir finira par deviner faux, avec assurance, et vous passerez la séance de débogage sur la mauvaise hypothèse. Ne pas savoir mérite d'être dit à voix haute.

Runlix effectue ces vérifications pour vous, sur la ligne, avant le téléchargement — avec la raison écrite à côté du verdict, y compris quand la raison est qu'il n'a pas pu savoir. Mais ce qui compte, ce sont les vérifications, pas l'outil : ce sont cinq questions posées à un fichier que n'importe qui peut lire, et les connaître vaut mieux que n'importe quelle application qui y répond à votre place.