Faire tourner un modèle en local sur un Mac, c'est réglé depuis un moment. Ce qui l'est moins par contre, c'est de brancher un agent de code dessus, parce qu'à chaque reprise de session, le serveur doit malheureusement remouliner des dizaines de milliers de tokens de contexte avant de sortir le premier mot...

Ce calcul, ça s'appelle le cache KV, et la plupart des serveurs le gardent en mémoire. Du coup, quand le modèle se décharge, le cache part avec dans le grand vide...

C'est pourquoi oMLX a pris le parti d'écrire ce cache sur le disque, au format safetensors, car le contexte déjà envoyé une fois, prompt système et fichiers lus compris, se recharge depuis le SSD au lieu d'être recalculé, y compris après un redémarrage du serveur.

De son côté, LM Studio conserve lui aussi son cache MLX sur disque , mais dans un fichier temporaire qu'il efface quand le modèle se décharge. Les deux outils écrivent sur le disque, mais un seul conserve réellement son cache.

Côté raccordement, le serveur oMLX expose l'API OpenAI et l'API Anthropic ce qui permet par exemple à Claude Code de taper directement sur localhost. Et y'a même un tableau de bord qui nous dit quoi faire dans le terminal pour brancher Claude Code ou d'autres avec oMLX.

Sur oMLX, le cache disque est donc actif d'office et son plafond par défaut, parce qu'il en faut bien un, se calcule à 10 % de la capacité du disque qui l'héberge. Sur un SSD d'un téraoctet par exemple, ça fait cent gigaoctets qui peuvent partir en cache sans que personne n'ait rien demandé. Donc prévoyez un peu de place... Après rassurez-vous, ça se vide d'un clic sur un bouton dans le tableau de bord et la taille peut se régler.

Le deuxième piège est plus sournois puisqu'une installation par défaut via pip ne compile pas les kernels Metal, et les modèles GLM-5.2, MiniMax M3 et Qwen3.5 retombent alors sans prévenir sur un chemin générique... Donc je vous incite fortement à utiliser uniquement les DMG proposés qui contiennent déjà les kernels Metal compilés comme il faut.

Reste à savoir ce que ça donne vraiment dans un usage quotidien... Le cache attaque l'attente avant le premier mot mais pas la vitesse à laquelle les mots sortent ensuite donc tout dépend du modèle et de la machine que vous avez. Mais en tout cas, pour un usage avec des agents (coding par exemple), ce sera plus efficace d'utiliser oMLX que Ollama ou LMStudio.

Source : omlx.ai

Enfin !! Le compteur du projet de décompilation de GoldenEye 007 affiche dorénavant 208 fichiers traités sur 208, et cela pour les trois versions de la cartouche, japonaise et européenne comprises. Le dernier commit du dev KholdFuzion est d'ailleurs classe, puisqu'il porte le titre "*james bond will return. *".

Oh yeah !

Techniquement, le code C reconstitué ressort du compilateur sous la forme d'une ROM identique à celle de 1997, octet pour octet. C'est précisément ce que veut dire le mot "matching" dans ces projets. Ce n'est donc pas un jeu équivalent qui se comporterait pareil que le jeu d'origine... Non, c'est exactement le même binaire !

Après comme vous vous en doutez, le dépôt, lui, n'embarque pas tous les assets nécessaires à la compilation, pour des questions de droits d'auteur comme d'hab. Le README du projet nous explique ainsi qu'il faut posséder une copie du jeu, et que les scripts iront extraire ce qui manque de votre côté.

Après c'est pas cette recompilation qui fait que GoldenEye devient soudainement "moddable". En effet, il l'est depuis longtemps, via le GoldenEye Setup Editor de SubDrag, Wreck et Zoinkity, capable d'importer vos propres modèles 3D dans le jeu.

Ce qui change par contre, c'est que jusqu'ici on éditait des structures dans un binaire, alors que maintenant on modifie le moteur en C et on recompile. C'est le même chemin qu'avait pris ce bon vieux Duke Nukem Zero Hour l'an dernier .

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Et c'est d'ailleurs ce que fait KholdFuzion à côté, avec GoldenRecomp , qui recompile la ROM en exécutable PC natif. Avec ça, le jeu peut tourner sur un ordinateur. Apparemment, c'est plutôt stable, et le son est bon.

Mais toute l'interface multijoueur reste à faire, le ciel du barrage part en vrille parce que le moteur de rendu ne digère pas les commandes de dessin maison, et certaines armes tirent trop vite maintenant que tout tourne à 60 images par seconde. Ce n'est donc pas encore vraiment jouable.

Aucune release n'a été publiée à ce jour, ni même un tag, ce qui veut dire qu'on est encore loin d'un portage installable comme celui de Zelda 64 . Faudra compiler vous-même, après avoir "build" une ROM depuis la branche du projet conçue pour ça.

Dans le même style, n'oubliez pas l'existence de GoldenEye-Recomp de SunJaycy , qui lui, est déjà jouable avec du multijoueur en ligne, mais qui n'a rien à voir avec tout ça puisqu'il recompile la version Xbox 360 qui n'est jamais sortie, et pas la N64.

Bref, si vous attendiez un exécutable à lancer ce soir, ce n'est pas ce que vous aurez mais ce qui s'annonce ensuite est très prometteur !

Source