Tobi, le créateur de la chaîne éponyme comme on dit, Game of Tobi, a publié une vidéo où Super Mario 64 tourne sur une Super Nintendo, avec la puce Super FX. Alors pour l'instant, seuls quelques niveaux fonctionnent, mais ils fonctionnent sur la VRAIE console !! Et ça c'est grâce à une cartouche flash compatible avec cette puce. Pour la petite histoire si vous n'en avez jamais entendu parler, cette puce SuperFX c'est en réalité
un coprocesseur conçu par Argonaut
qui équipait déjà Star Fox et Yoshi's Island (Alors ça vous revient les gamers grisonnants ??)
Hé je vous arrête tout de suite, ce n'est pas le jeu de la Nintendo 64 recompilé, non pour ça faudrait utiliser mon logiciel
Kompote
. En réalité, Tobi a écrit un moteur maison qui réutilise les assets d'origine, animations comprises. Ce moteur dessine donc l'image depuis l'arrière vers l'avant (ça s'appelle
l'algorithme du peintre
) plutôt que de passer par un Z-buffer classique (la mémoire qui retient la profondeur de chaque pixel). Il écarte aussi très agressivement tout ce qu'il peut ne pas dessiner et c'est vrai parfois trop, ce qui fait que ça réduit le niveau de détail des textures. C'est voulu par Tobi car les textures sont un énorme goulot d'étranglement !
Quoiqu'il en soit, Tobi trouve le résultat sympa car juste "reconnaissable" et est surtout content de Bob-omb Battlefield, l'un des niveaux de Mario 64 les plus hardus à faire tourner de façon fluide. En tout cas c'est un sacré challenge pour lui car les niveaux doivent tenir dans 2 Mo max. Il cherche donc comment réduire au max tout ça.
Maintenant, certains d'entre vous se sont peut-être demandé d'où sortait ce nom "Super Mario FX" ?
Eh bien Tobi reprend là une vieille rumeur qui raconte que Nintendo aurait préparé un premier Mario en 3D pour la Super Nintendo avec cette puce SuperFX, avant malheureusement de l'annuler pour en faire le Super Mario 64 qu'on connait tous ! Moi ce que j'ai pu trouver sur cette rumeur, c'est via
SNES Central
qui a fini par poser la question à Dylan Cuthbert, l'un des programmeurs de Star Fox qui
a expliqué
que Super Mario FX était en réalité le nom de code interne de la puce FX, et non celui d'un jeu. Bref, à vous de voir si vous préférez les faits à la rumeur plus romanesque ^^.
Maintenant si vous voulez jouer à sa version de Super Mario FX, il faudra patienter car rien n'est téléchargeable pour l'instant. Sniiiif ! En effet, Tobi veut publier le projet de façon à ce que chacun puisse le compiler avec sa propre copie de Super Mario 64, ce qui lui évitera de finir en octogone avec les avocats de Nintendo !
Vous glissez une app dans la corbeille du Mac, elle disparaît du dossier Applications, et vous pensez que c'est réglé ? Que vous êtes naïfs ! Hé oui, ce que vous ne savez pas, c'est que ses préférences, ses caches et son container restent bien présent dans votre ~/Library, parfois pendant des années, encombrant votre espace disque pour rien.
Hé bien s'occuper de tout ce merdier, c'est le job de
PureMac
, une app native codée en SwiftUI qui piste ces fichiers-là pour libérer des ressources sur votre mac. Elle croise l'identifiant du bundle, celui de l'équipe de développement, les entitlements et les métadonnées Spotlight, selon trois niveaux d'agressivité en fonction de ce que vous voulez ratisser.
Elle sait aussi prendre le problème dans l'autre sens puisque son chercheur de fichiers orphelins parcourt ~/Library pour retrouver les restes d'applications que vous avez virées il y a trois ans et dont plus rien ne vous rappelle l'existence.
Et si vous développez, il y a de quoi récupérer bien plus de place avec les DerivedData, les runtimes de simulateur Xcode, les couches Docker, les caches npm, yarn, pnpm et Homebrew. Bon, ça vous savez déjà le faire avec docker system prune, deux ou trois autres commandes, ou avec
Mole en ligne de commande
dont je vous ai déjà parlé. Mais l'intérêt ici, c'est de tout voir d'un coup avant d'arbitrer.
Côté données, il n'y a rien à surveiller puisque PureMac n'embarque aucune télémétrie ni appel réseau. Et la licence, c'est du 100% licence MIT, là où d'autres outils similaires comme Pearcleaner ajoute une Commons Clause qui en interdit la revente, que AppCleaner, lui, s'arrête à la désinstallation, ou encore que CleanMyMac nécessite d'acheter une licence.
Pour le faire tourner, il vous faut macOS 13 au minimum, et ça s'installe en une ligne avec brew install --cask puremac. Sinon, il y a un .dmg signé et notarisé à récupérer directement.
Par contre, sachez que ça réclame le l'accès complet au disque, soit la permission la plus large que macOS distribue, et il ne garde aucun journal des chemins qu'il a supprimés. Surtout que quand un fichier est supprimé, il l'est pour de bon, donc vérifiez bien les choses avant de les supprimer.
Le nettoyeur de caches, est également une opération sans retour. Alors pour un cache ça n'a pas d'importance, puisqu'il se régénèrera tout seul. Mais pour un reste dans ~/Library qui contenait, j'sais pas, par exemple une licence, un wallet crypto ou vos réglages, c'est une autre affaire.
Donc soyez TRÈS prudent et lisez bien les chemins d'accès vers les fichiers avant de cliquer pour les supprimer, histoire de pas faire de conneries.
Si vous avez un Mac Apple Silicon et que vous en avez assez de payer des tokens à chaque requête,
Rapid-MLX
vaut le détour. C'est un moteur d'inférence local maintenu par Raullen Chai, qui tape directement dans les kernels MLX d'Apple, sans repli sur llama.cpp ni couche Metal intermédiaire. Et si le nom vous dit vaguement quelque chose, c'est normal puisque c'est un fork de vLLM-MLX, le serveur de Wayner Barrios dont
je vous parlais en mai
. Rapid-MLX a juste pris un rythme de publication plus soutenu des deux.
Ce que ça vous donne, c'est donc un serveur HTTP qui parle le même langage que l'API d'OpenAI et celle d'Anthropic. Vos scripts, Cursor, Aider, LangChain ou Claude Code continuent de fonctionner, sauf qu'ils tapent sur votre machine au lieu d'un datacenter.
Donc je vous propose de voir ensemble comment installer ça.
Étape 0 : Vérifier que votre Mac est éligible
Le script d'installation contrôle plusieurs choses avant de lancer quoi que ce soit, et autant les connaître d'avance. Il faut une puce Apple Silicon et il n'y a pas de version Linux ni Windows, ni de support CUDA ou AMD.
Le script d'installation accepte encore macOS 13 Ventura, mais le vrai plancher est macOS 14 Sonoma. La formule Homebrew l'exige, et surtout MLX, la brique Apple sur laquelle tout repose, ne publie de paquets macOS que pour les versions 14, 15 et 26. Sur un Mac resté en Ventura, ça cassera donc à l'installation des dépendances, quel que soit le chemin choisi.
Dernier point à avoir en tête, c'est pensé pour votre machine à vous et pas pour un serveur. Vous n'y trouverez donc ni authentification multi-utilisateurs, ni quotas de requêtes.
Étape 1 : Installer Rapid-MLX
Le plus simple, c'est Homebrew :
brew install rapid-mlx
Si vous gérez déjà vos environnements Python vous-même, les autres chemins existent :
Il y a aussi un installeur en une ligne (curl -fsSL https://rapidmlx.com/install.sh | bash) qui détecte votre RAM et vous propose un modèle adapté. Il crée un venv isolé dans ~/.rapid-mlx/ et pose le binaire dans ~/.local/bin/. Un curl | bash reste un curl | bash. La formule Homebrew fait exactement le même boulot, donc l'installeur en ligne perd de son intérêt.
L'installation de base pèse dans les 460 Mo et la vision, l'audio et les embeddings sont des extras optionnels, vous les ajouterez seulement si vous en avez l'usage.
Étape 2 : Choisir un modèle qui tient dans votre RAM
C'est là que la plupart des gens se plantent, en chargeant un modèle trop gros et en concluant que "ça rame". Sur Mac, la RAM est unifiée, donc le modèle mange directement dans la mémoire que se partagent le CPU et le GPU.
Les paliers recommandés par le projet :
RAM
Modèle conseillé
8 à 23 Go
`qwen3.5-4b-4bit`
24 à 47 Go
`gpt-oss-20b-mxfp4-q8`
48 à 95 Go
`qwen3.6-35b-8bit`
96 Go et plus
`gpt-oss-120b-mxfp4-q8`
Le catalogue complet se liste avec la commande rapid-mlx models, et rapid-mlx info <alias> vous donne le profil détaillé d'un modèle. Si vous voulez sortir du catalogue maison,
le filtre matériel de Hugging Face
que je vous montrais fin juin fait exactement ce tri à votre place.
Pour utiliser un autre modèle que celui par défaut, il suffit de reprendre l'alias affiché par rapid-mlx models et de le passer en argument. Et si vous préférez télécharger les poids à l'avance, sans rien lancer, c'est le boulot de rapid-mlx pull, qui accepte aussi bien un alias du catalogue qu'un identifiant Hugging Face :
rapid-mlx pull qwen3.5-9b-4bit
Le modèle atterrit dans le cache Hugging Face de votre machine, et ensuite rapid-mlx chat qwen3.5-9b-4bit ou rapid-mlx serve qwen3.5-9b-4bit chargeront ce modèle-là. Le pull préalable reste facultatif, chat et serve téléchargent d'eux-mêmes ce qui manque, mais autant rapatrier les gigas tranquillement avant plutôt qu'au moment où vous voulez bosser.
Étape 3 : Vérifier que ça tourne
Avant de bricoler des intégrations, testez en direct :
rapid-mlx chat
Ça part sur qwen3.5-4b-4bit par défaut, télécharge les poids au premier lancement (comptez 2,5 Go) et vous lâche dans une interface (REPL). /help listera les commandes slash, et /exit vous permettra de quitter le chat.
Une subtilité qui évite de mal interpréter ce premier test, c'est que dans le chat, le raisonnement est coupé par défaut, histoire que le modèle ne vous déballe pas sa réflexion à l'écran. En mode serveur par contre c'est l'inverse, et ça change la vitesse ressentie du tout au tout. J'y reviens plus bas.
Étape 4 : Lancer le serveur
Le vrai intérêt, c'est le mode serveur :
rapid-mlx serve qwen3.5-4b-4bit
Vous récupérez un endpoint sur http://localhost:8000. Le test qui confirme que tout est en place :
Pointez n'importe quel client compatible OpenAI sur http://localhost:8000/v1 et c'est réglé. Cursor, Aider, LibreChat, Open WebUI, LangChain, tous marchent avec ce seul changement d'URL. Il y a aussi /v1/embeddings pour du RAG local et /v1/responses pour le Codex CLI.
Étape 5 : Brancher Claude Code dessus
C'est le morceau le plus intéressant du lot, et il tient en deux variables d'environnement. Serveur lancé d'un côté, puis dans un autre terminal :
ANTHROPIC_BASE_URL=http://localhost:8000 ANTHROPIC_API_KEY=not-needed claude
Attention quand même, l'URL de base doit être la racine, sans/v1 à la fin. Le SDK Anthropic ajoute /v1/messages tout seul, donc si vous mettez /v1 vous obtenez /v1/v1/messages et ça casse.
Depuis la 0.10.14, l'appel d'outils passe par une grammaire contrainte activée par défaut, donc plus besoin de bidouiller un --tool-call-parser à la main pour que les tool calls soient parsables. Pour du Claude Code sérieux, visez plutôt un gros modèle, la doc officielle recommande par exemple qwen3.6-35b-4bit en exemple.
Quand ça coince
Le réflexe à avoir avant de chercher ailleurs :
rapid-mlx doctor
Les trois pannes les plus courantes sont toujours les mêmes.
Débit décevant côté serveur, c'est le raisonnement : les Qwen 3.5 et 3.6 démarrent en mode réflexion, donc ils pensent à voix haute avant de répondre, et --no-think règle l'affaire.
Plantage mémoire, votre modèle est trop gros pour la RAM disponible, redescendez d'un palier ou prenez une quantification plus agressive. Appels d'outils qui arrivent en texte brut, la récupération automatique gère la plupart des cas, sinon vous forcez le parser correspondant à votre modèle.
Voilà, grâce à ça, votre Mac est maintenant un serveur d'IA super rapide ! Plus de facture au token, et vos prompts ne sortent plus de la pièce.