Vous avez une carte Radeon dans le PC, et un logiciel boosté à l'IA qui refuse de se lancer ailleurs que sur de la NVIDIA ? Roooh c'est dommage ! Cet outil vous réclame probablement CUDA en dur et malheureusement, personne n'ira faire une version fonctionnelle pour votre carte AMD.

Alors on fait quoi ? On se roule en boule et on chiale ? Bah non, on installe CUDA-for-AMD-Windows comme des guerrier(e)s et on avance dans la vie !

Ce projet est assez unique puisqu'il n'écrit pas une seule ligne de traduction CUDA. En réalité c'est un jeu de scripts PowerShell qui monte la pile à votre place avec ZLUDA d'un côté, qui fait le travail de traduction depuis des années, et le HIP SDK d'AMD de l'autre, qui fournit les bibliothèques de calcul.

Car c'est justement ce qui manquait sous Windows. Le pilote Adrenalin vous donne le runtime, mais pour le reste de ROCm, demmerdez-vous entre un SDK officiel en retard et des compilations nocturnes buggées... Breeeeef.

Du coup, ce script d'installation fait ce tri pour vous. Il repère votre carte et son architecture gfx, vérifie que le pilote AMD et le HIP SDK sont là, télécharge une version précise de ZLUDA et, si votre programme en a besoin, LibTorch. Il compare les empreintes SHA-256 des archives, et finit en lançant le contrôle de ZLUDA sur votre machine. Une fois les prérequis AMD en place, ça tient ensuite en trois lignes :

git clone https://github.com/Speedstu/CUDA-for-AMD-Windows.git
cd CUDA-for-AMD-Windows
powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1

Prévoyez quand même de la place car ce bon vieux LibTorch pèse 2,66 Go à lui seul. Notez quand même qu'un -SkipLibTorch vous en dispensera si votre logiciel ne s'en sert pas. Après ça, vous lancez votre exécutable avec run-zluda.ps1, qui pose les DLL de compatibilité à côté de lui, met les bibliothèques HIP sur le PATH et passe la main à zluda.exe.

cuBLAS, cuBLASLt, cuSPARSE et cuFFT, sont donc bien redirigés vers rocBLAS, hipBLASLt et rocSPARSE, mais pas cuDNN...

En effet, le HIP SDK Windows stable ne fournit pas la pile IA complète de ROCm, celle qu'on a sous Linux, et les contrôles cuDNN de ZLUDA se plantent sans un backend compatible MIOpen. Donc si le logiciel que vous voulez lancer tape lourdement dans les convolutions, faudra vous arrêter là. NCCL, TensorRT ou une extension CUDA maison peuvent échouer aussi...

Bref, l'auteur ne promet rien de magique ni d'universel mais ça se tente quand même selon ce que vous voulez lancer.

Ajoutez à ça qu'une seule carte est validée, la Radeon RX 9060 XT, et qu'une seule appli est réellement passée de bout en bout. On est donc sur de l'hyper expérimental

Voilà, avant de vous lancer là-dedans, regardez si vous en avez vraiment besoin car AMD a fini par apporter un support officiel de PyTorch et du HIP SDK à Windows, avec les composants ROCm 7.2.1. Sa matrice de compatibilité indique que côté grand public, la RX 9060 XT justement, mais aussi les RX 9070, la RX 7900 XTX et la RX 7700 sont supportés. Si votre besoin c'est donc PyTorch, moi je prendrais cette route-là à votre place car elle est native.

À récupérer sur GitHub si vous avez un logiciel qui refuse de démarrer à cause de CUDA.

Source : Tom's Hardware

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 .

Dark Hours est à l'origine une petite web app qui vous dit ce qu'il y a à voir dans le ciel ce soir et si ça vaut le coup de mettre le museau dehors. Le développeur Terry Godier l'a construite avec l'aide de Claude et lancée début août mais au moment où j'écris ces lignes, elle n'existe plus... En effet, son site darkhours.io redirige maintenant vers DarkHours.app , un autre projet signé Miguel Beher et sous licence MIT.

C'est ce dernier qui a vu le problème, et je vais vous expliquer...

En fait, les 2 apps avaient non seulement le même nom, mais également les mêmes fonctions, et le même nom de domaine (à part le TLD). Quand Beher a signalé le souci à Godier , ce dernier a d'abord proposé de changer de nom et de différencier les fonctionnalités mais une heure plus tard il retirait tout, annulait l'app iOS qu'il préparait, et publiait un mea culpa où il parle de son "usage irresponsable de l'IA".

Et ce qui l'a décidé à tout stopper comme ça, c'est juste un bug. En effet, son application envoyait les gens observer les étoiles au milieu de champs perdus au Mexique, ou dans l'océan Pacifique et Beher avait exactement le même souci de son côté à ce moment-là (il l'a résolu depuis).

Alors se ressembler sur des fonctionnalités, ça arrive et ça ne me choque pas mais se ressembler jusque dans les bugs, là ça pique un peu beaucoup. Les procès en pompage IA, j'en ai déjà parlé , et ils se trompent souvent de coupable, et dans le cas de Godier, celui-ci n'a pas pompé le code du Dark Hours original. Non, il a juste développé son app avec Claude Code, sans se poser trop de question.

Pour lui, il est juste parti d'un code d'éphémérides qu'il a écrit en janvier mais comme Dark Hours est un projet open source, et bien ce qui s'est passé, c'est que son agent IA a récupéré de gros bouts de cette app, jusqu'à son nom pour en faire sa nouvelle app. Hé oui, la vie c'est facile quand on se repose sur le code des autres.

Dark Hours, le vrai

En effet, Claude Code, Codex et les autres sont des outils connectés. Ils lisent des pages, clonent des dépôts, fouillent GitHub quand ça les arrange, du coup, si votre demande ressemble à un truc qui existe déjà, et bien l'agent peut aller le consulter et s'en servir de modèle. Et même sans aller sur le net, comme les modèles ont été entraînés sur tout ce qui traîne publiquement sur le net, dépôts de code compris, il est capable de restituer une structure vue mille fois, sans même aller la chercher sur le net. Un peu comme les modèles de diffusion d'images qui reproduisent le style des artistes.

C'est pour ça que je trouve la mésaventure de Godier et Beher intéressante. Ça nous enseigne qu'il faut faire extrêmement attention quand on code avec l'IA. Pour limiter les risques qu'elle aille se servir dans du code libre, il faut donc indiquer expressément à l'agent de NE PAS récupérer le code source de projets open source, ne pas l'analyser, ne pas pomper du code ni les interfaces. Bref, lui dire qu'on part d'une page blanche...

C'est le même principe que celui de la clean room qui a permis à Compaq de cloner légalement le BIOS d'IBM, comme on peut le voir dans la série Halt and Catch Fire... On implémente les bonnes idées, mais jamais les lignes de code.

Anthropic, le concurrent direct d'OpenAI sur les modèles d'IA, a publié hier un billet de recherche qui a fait pas mal de bruit : son modèle Claude Mythos Preview a trouvé en 60 heures une faiblesse dans HAWK, un schéma de signature post-quantique que deux ans de relecture humaine n'avaient pas repérée.

La cryptographie post-quantique, ce sont ces nouveaux algorithmes conçus pour résister aux futurs ordinateurs quantiques, qui pourraient un jour casser une partie du chiffrement actuel. Le NIST, l'organisme américain qui normalise ces standards, organise depuis des années un concours public, et HAWK y concourt au troisième tour pour les signatures numériques, ce mécanisme qui prouve qu'un message vient bien de vous.

Sauf que voilà, ce que l'IA a réellement cassé, c'est HAWK-256, un paramètre de défi mis à disposition des chercheurs pour être attaqué, pas les versions HAWK-512 et HAWK-1024 pensées pour un usage réel. L'attaque fait passer le coût d'une récupération de clé de 2 puissance 64 à 2 puissance 38 opérations, de quoi diviser par deux la taille de clé effective sur un schéma qui n'est déployé nulle part.

Deuxième résultat mis en avant : une attaque 200 à 800 fois plus rapide que la meilleure méthode connue contre AES-128 réduit à 7 tours. AES, c'est le chiffrement le plus utilisé au monde, celui qui protège votre navigateur, vos sauvegardes ou votre disque dur.

Un tour, c'est une passe de brouillage des données, et AES-128 en enchaîne dix. Les cryptographes attaquent depuis toujours des versions volontairement raccourcies pour jauger la marge de sécurité du vrai chiffre, du coup 7 tours, c'est un exercice académique, rien de plus.

Même sur cette version affaiblie, l'attaque suppose de faire chiffrer environ 2 puissance 105 messages choisis par l'attaquant, une quantité de données que personne ne réunira jamais. Anthropic l'écrit noir sur blanc : aucun système en production n'est touché.

Le sujet est ailleurs. La technique contre AES, que le modèle a baptisée le pont de Möbius, est sortie de trois jours de travail quasi autonome pour environ 100 000 dollars de calcul, avant plusieurs centaines d'heures de vérification par des chercheurs humains, seuls capables de confirmer que l'attaque tient debout.

Anthropic a d'ailleurs prévenu les auteurs de HAWK dès juin et coordonné sa publication avec le NIST. Chez Keyfactor, une société spécialisée dans la gestion du chiffrement, on y voit la preuve que le processus d'évaluation fait son travail : mieux vaut découvrir ces faiblesses maintenant qu'une fois le standard déployé partout.

Une IA qui trouve toute seule des failles dans du chiffrement, c'est franchement impressionnant. Les titres qui enterrent déjà le chiffrement mondial, beaucoup moins.

Source : Anthropic

La startup chinoise Moonshot AI, que vous connaissez peut-être pour son assistant Kimi et qui compte Alibaba parmi ses soutiens, a publié hier sur Hugging Face les poids complets de Kimi K3, un modèle de 2 800 milliards de paramètres qui devient du même coup le plus gros jamais mis en libre téléchargement. Personne n'était jamais allé aussi loin.

Ces fameux poids, ce sont les milliards de réglages internes que le modèle a accumulés pendant son entraînement, et c'est précisément ce qu'il faut posséder pour faire tourner l'IA sur ses propres machines plutôt que de passer par les serveurs de l'éditeur.

Le fonctionnement est d'ailleurs intéressant. Le modèle est découpé en 896 blocs spécialisés dont seuls 16 s'activent à chaque requête, ce qui ramène le calcul réel autour de 50 milliards de paramètres et rend l'engin à peu près exploitable.

La fenêtre de contexte grimpe en plus à un million de tokens, ces fragments de texte qui servent d'unité de mesure aux IA, de quoi envoyer une dizaine de romans dans une seule et même conversation.

Sur les classements du moment, K3 vient se glisser juste derrière les meilleurs modèles fermés d'OpenAI et d'Anthropic, quand il ne passe pas carrément devant sur les tests de programmation, ce qui est quand même un drôle de résultat pour un modèle que n'importe qui peut récupérer gratuitement.

Sauf que voilà, récupérer est un grand mot : le téléchargement pèse 1,4 To, et il faut ensuite une machine capable de charger tout ça en mémoire, ce qui suppose environ huit serveurs remplis de cartes graphiques professionnelles et une facture à plusieurs millions de dollars. Personne ne fera donc tourner K3 dans son salon.

Et puis il y a la licence, un texte maison que Moonshot se garde bien d'appeler open source, et qui vise directement les gros hébergeurs : toute société qui revend l'accès au modèle et encaisse plus de 20 millions de dollars sur douze mois devra signer un accord commercial séparé avant de continuer.

Les très gros services, au-delà de 100 millions d'utilisateurs mensuels, doivent en plus afficher "Kimi K3" bien en vue dans leur interface. Du coup, les Amazon et autres Microsoft qui voudraient proposer le modèle à leurs clients passeront eux par la case négociation.

Pour tous les autres, l'API officielle est ouverte depuis mi-juillet, à 3 dollars le million de tokens en entrée.

Moonshot qui offre gratuitement son meilleur modèle au monde entier tout en gardant la main sur ceux qui pourraient en vivre, c'est de la générosité très bien calculée.

Source : Simon Willison

J'ai jamais fait construire de maison mais je crois savoir que dessiner le plan de sa maison en 3D, ça passe encore par un logiciel assez lourd à installer + une licence, sans oublier l'interface façon Micro Applications de 2003 (qui s'en souvient ??). C'est pourquoi Aymeric Rabot et Wassim Samad ont pris le problème autrement avec Pascal Editor, un éditeur de bâtiments 3D qui tourne simplement dans un onglet de navigateur. Et en plus, c'est gratuit, open source (licence MIT) et surtout sans inscription.

Vous tracez les murs à la souris, puis viennent les zones, les dalles, les plafonds et les toits. Les portes et les fenêtres sont paramétriques, posez-les sur une cloison, la découpe se fait toute seule en géométrie booléenne via three-bvh-csg. Le mobilier s'accroche au sol, au mur ou au plafond selon l'objet ( allez regarder cet exemple ! )

bHive, c'est une app Mac qui lit l'intérieur de vos fichiers au lieu de se contenter de leur nom, et qui sait maintenant répondre à des questions dessus. Vous lui demandez "qu'est-ce que dit mon bail sur la résiliation anticipée ?", elle va fouiller vos PDF et vous sortir la réponse en clair, tout ça en local sur votre machine, sans rien envoyer nulle part.

Vous pointez bHive vers des dossiers que vous avez déjà, et elle lit ce qu'il y a dedans. Vos documents, les PDF, les images dont elle fait l'OCR, et depuis la 2.0 l'audio et la vidéo, transcrits directement sur le Mac. Ensuite vous cherchez en décrivant ce que vous voulez, plutôt qu'en essayant de vous souvenir du nom que vous aviez collé au fichier. Rien ne bouge, rien n'est copié dans une bibliothèque, vos fichiers restent exactement où ils sont, ils sont tout simplement indexés dans un RAG.

La vraie nouveauté de cette version, c'est "Ask bHive". Vous posez une question, l'app trouve les fichiers concernés, les lit, et vous répond en langage clair. Elle vous montre alors quels fichiers elle a utilisés, donc vous pouvez les ouvrir et vérifier vous-même et surtout, quand elle ne sait pas, elle le dit, au lieu d'inventer un truc qui sonne juste. Ça paraît con dit comme ça, mais c'est avec ça que la plupart des assistants IA vous plantent.

Bon, moi, je n'en ai pas vraiment besoin de cet outil parce que j'ai mis en place mes propres RAG, mais je me dis que si j'avais trouvé ça avant, je ne me serais pas fait chier.

Côté moteur, tout tourne en local, et le modèle intégré à macOS marche tout de suite, donc vous n'avez rien à télécharger. Si vous voulez de la recherche plus fine, il y a bien sûr un modèle plus costaud à récupérer, de 515 Mo.

Il y a aussi une vue "santé de la bibliothèque", histoire que vous sachiez ce qui n'est pas cherchable et pourquoi. Fichiers déplacés, disque externe débranché, format illisible, OCR raté, éléments encore dans la file d'attente. En gros, un tableau de bord de confiance au lieu de vous laisser deviner si la recherche couvre vraiment tout. Vous pouvez aussi sauvegarder vos collections, tags et notes dans un fichier pour les restaurer plus tard.

Je vous avais déjà parlé de Cardinal , qui rend la recherche de fichiers instantanée sur Mac sauf que Cardinal cherche par nom, là où bHive lit ce qu'il y a à l'intérieur et sait vous répondre avec beaucoup plus de richesse. On est une gamme au-dessus selon moi.

Après, bHive 2.0 réclame macOS 26 et une puce Apple Silicon donc si vous êtes resté sur macOS 15 comme un homme de cro-magnon, vous devrez rester sur la vieille version 1.3.1 qui continue de tourner, mais sans toutes ces nouveautés... sniiif.

Voilà, c'est gratuit, et ça respecte vos données puisque tout reste en local.

À tester !

Frank Denis , c'est le monsieur qui fait tourner un bon morceau d'Internet sans que personne le sache : libsodium, dnscrypt-proxy, Pure-FTPd, c'est lui. Et dernièrement, il s'est attaqué aux agents de codage IA avec Swival , un outil pensé pour les petits modèles qui tournent en local sur votre machine.

Le truc de Frank c'est d'écrire du logiciel réputé incassable depuis 25 ans. Si vous chiffrez vos requêtes DNS, y'a des chances que ça passe par son dnscrypt-proxy , et si vous utilisez du chiffrement dans à peu près n'importe quelle app moderne, libsodium n'est jamais bien loin. Du coup, quand ce profil-là sort un agent de codage en Python, licence MIT, gratuit, je pense que ça vaut le coup de s'y arrêter 2 minutes.

Il a codé cela parce que les outils d'agentique existants l'ont sérieusement gonflé. C'est beau, c'est neuf, c'est lavé avec Mir Laine mais.... ça plante !! Et l'autre reproche qu'il leur fait c'est concernant la confidentialité. En effet, utiliser un agent, c'est forcément voir partir on ne sait où nos données personnelles... nos clés API, nos URLs internes, nos noms de projets... tout ça est allègrement bouffé par le fournisseur de modèle qui derrière s'en sert pour tout un tas de choses pas cool. C'est notamment pour cela que Swival embarque une option --encrypt-secrets qui détecte les credentials dans les messages et les chiffre avant qu'ils quittent votre machine. Une denrée rare chez les agents de codage, et ça c'est du pur Frank Denis !

Y'a aussi la gestion du contexte, qui est le gros morceau. Les agents classiques sont conçus pour des modèles frontière avec des fenêtres géantes. Sauf que votre LLM local, lui, doit souvent se débrouiller avec 32K de contexte, et là tout déborde très vite. Swival, lui, prend le truc à l'envers. Chaque sortie d'outil est plafonnée direct à la source : 50 Ko max par fichier lu, 100 résultats de grep, 100 entrées par listing. Et une fois que l'agent a fini de fouiller votre code, un système de snapshots vire ses 12 000 tokens de lectures pour les remplacer par un résumé de 200 tokens.

Et c'est pas fini. Rajoutez là-dessus une compaction automatique en 7 niveaux progressifs (du simple ménage au grand débarras), plus des notes de travail qui survivent à tout ça. Résultat, un agent qui tient des sessions à rallonge sans partir en vrille. La doc montre d'ailleurs Swival en train d'avaler une refactorisation multi-fichiers avec Qwen3-Coder-Next dans 32K sous LM Studio sans broncher...

Et pour brancher tout ça, vous avez le choix. 11 backends quand même ! LM Studio par défaut (zéro config, il repère tout seul votre modèle chargé), llama.cpp pareil, HuggingFace, OpenRouter, Google Gemini et Vertex AI. Envie de lourd ? ChatGPT Plus ou AWS Bedrock. Et pour les curieux, les Apple Foundation Models en expérimental, un provider générique compatible OpenAI (ollama, vLLM, mlx_lm.server...) et même une commande externe de votre choix.

Pour trouver un modèle qui tienne dans votre RAM, Hugging Face sait filtrer selon votre matos et une fois que vous avez fait votre choix, l'installation tient en une ligne (via uv, Python 3.13 minimum) :

uv tool install swival

Ensuite, il suffit de taper, par exemple : "Refactore la gestion d'erreurs de src/api.py" et l'agent se met au travail pour peu que vous ayez déjà un LMStudio ou un llama.cpp qui tourne avec un modèle chargé...

Ah j'oubliais, si vous êtes sous Mac vous pouvez même l'installer avec Homebrew :

brew install swival/tap/swival

Ensuite, au niveau des commandes, il y a aussi, par exemple, une commande /audit qui vous permet de faire de la chasse aux failles de sécurité dans votre code. Tout cela avec des agents isolés chacun dans des worktrees séparés et qui sont obligés de reproduire chaque bug avant de l'inscrire dans le rapport.

Et côté sécurité, vous avez deux sandboxes au choix. Soit Agent FS d'un côté (l'agent bosse sur une copie de vos fichiers, votre projet reste intact) ou nono (non, pas le petit robot) de l'autre (avec barrières au niveau du noyau, blocage réseau compris). Sans oublier la mémoire persistante entre vos sessions, le support MCP et un mode serveur pour interconnecter vos agents entre eux.

Voilà donc de quoi venir jouer dans la cour de ZCode côté z.ai et compagnie...

Voilà, je me suis dit que ça allait vous intéresser, donc si vous voulez zieuter le code, direction GitHub , sinon, toute la doc se trouve sur le site officiel .

Merci Friendly_0day pour le lien !