RAG sans base vectorielle, MoE de 300B sur mini-PC : le local se débrouille

Hillock : le RAG sans base vectorielle

Un développeur publie Hillock, un projet open source qui se passe de base vectorielle. À la place : SQLite et des hypervecteurs SIMD, le tout sous 1,2 Go de VRAM. L'extraction des faits relationnels passe par des bi-encodeurs légers et prend cinq secondes, sans mobiliser le LLM génératif.

Le raisonnement est double. D'abord ne pas consommer la VRAM du modèle principal, qui reste le poste le plus contraint quand on fait tourner un modèle en local. Ensuite limiter les hallucinations : la similarité cosinus, avance l'auteur, échoue souvent à rejeter les faux positifs — un passage proche par la distance mais hors sujet finit quand même dans le contexte envoyé au modèle.

L'argument porte donc sur deux ressources rares en local : la mémoire de la carte graphique, et la tolérance aux faux positifs d'un retrieval qui ne sait dire que « proche » ou « loin ».

300B sur 128 Go, 27B sur 16 Go

Le moteur Kyojin, construit sur ExLlamaV3 pour Strix Halo (gfx1151, ROCm), fait tenir deux modèles MoE de classe 300B chacun sur une seule machine de 128 Go. Les mesures, prises sur un Ryzen AI Max+ 395, donnent pour GLM-5.3-Flash (99,7 Go) 580 tok/s en prefill à 3,5K et 26 à 30 tok/s en décodage ; MiMo-V2.6-Flash-MOPD (105 Go) monte à 44 tok/s en code. Les poids de MiMo viennent d'une quantification maison, et le pack GLM mélange des tenseurs EXL3 publics de turboderp en 2,05 et 3,05 bpw.

Toujours sur r/LocalLLaMA, Ninfer 4080 place ISTA-DASLab-Qwen-3.8-27B-GSQ sur une RTX 4080 de 16 Go avec 100k de contexte. L'auteur annonce jusqu'à 2720 tok/s en préfill et 262 tok/s en génération, là où les variantes Ninfer 5090, 4090 et 3090 restaient hors de portée de cette classe de GPU. Le code est partagé sur GitHub. Le développeur revendique vingt ans d'ingénierie logicielle, mais aucune expérience en développement de kernels GPU.

Les deux projets visent des machines qu'on possède déjà plutôt que des clusters : 128 Go de mémoire unifiée d'un côté, une carte grand public de 16 Go de l'autre. Dans les deux cas, l'essentiel du travail se joue sur la quantification et les kernels, pas sur l'entraînement.

UnifoLM-WLA-1.0 : 6B pour 64 tâches

Côté robotique, Unitree Robotics présente UnifoLM-WLA-1.0, un modèle de fondation humanoïde de 6B paramètres, entraîné sur environ 2 500 heures de données issues de robots réels. Un seul modèle couvre 64 tâches : dix de corps entier et cinquante-quatre sur table, avec pincements parallèles ou deux mains dextres. La démonstration tourne sur le robot G1 — faire le lit, charger la machine à laver, plier du linge, trier des objets.

Le chiffre qui compte ici n'est pas la taille du modèle mais le nombre de tâches couvertes par un seul jeu de poids. 6B, c'est peu à l'échelle des MoE de 300B évoqués plus haut ; les 2 500 heures, elles, viennent de robots physiques et non de traces textuelles.

« Attends, je demande au modèle »

Un développeur raconte une revue de code récente : une PR d'environ 600 lignes générée, structurée et ouverte en moins de vingt minutes. Syntaxe propre, tests de base passés. Puis la question tombe sur un cas limite du gestionnaire de requêtes, et l'auteur répond : « Attends, je demande au modèle ».

Le fil contredit le discours des « 10x » : comprendre le système était le vrai goulot d'étranglement, pas la frappe. La revue portait moins sur la syntaxe que sur la capacité de l'auteur à expliquer ce que fait son code quand l'entrée ne ressemble plus à celle du test.

Et maintenant ?

Pris ensemble, ces dépêches décrivent un local qui avance sur deux fronts : descendre le coût matériel de l'inférence, et déléguer à des composants plus petits ce qu'on faisait porter au grand modèle. Kyojin et Ninfer 4080 poussent le premier, Hillock le second. La revue de code rappelle l'autre versant : la vitesse d'écriture n'a de valeur que si la compréhension suit, et aucun chiffre de tok/s ne dit qui, dans l'équipe, sait encore pourquoi le gestionnaire de requêtes se comporte ainsi.