Janas : exécuter des modèles LLM plus volumineux que la RAM en streamant les experts du disque
Sommaire
En bref
- Janas-LLM, un outil en C sans dépendances externes, permet d'exécuter des modèles de mixture-of-experts massifs (jusqu'à 80 milliards de paramètres) sur des machines aux ressources limitées en chargeant les poids depuis le disque SSD.
- Sur un laptop 32 GB (Intel Core Ultra 9 185H), Janas atteint 37 tok/s sur Qwen3-Next-80B contre 2,8 tok/s avec llama.cpp.
- L'outil reste en développement précoce, sans API stable, et fonctionne actuellement sur Linux et Windows x86-64.
Ce que dit la source
L'auteur présente Janas-LLM comme une solution pour exécuter des modèles LLM très volumineux sur des machines grand public sans GPU performant. La thèse centrale : en streamant les experts depuis un NVMe SSD plutôt que de les charger entièrement en RAM, on contourne les limites de mémoire tout en bénéficiant d'une vitesse de lecture disque suffisante (5.7 GB/s sur NVMe moderne). Les benchmarks affichent des gains significatifs par rapport à llama.cpp, notamment sur les opérations de lecture de prompt (62 tok/s vs 16 tok/s pour Qwen3-Next-80B de 48 GB sur 32 GB de RAM), ce qui suggère un meilleur exploitation du cache GPU et de la bande passante disque.
- Janas est écrit en C pur sans dépendances externes au-delà de la libc ; conception délibérément allègère pour maximiser la portabilité
- Les modèles de mixture-of-experts (MoE) permettent d'activer seulement certains experts par token, réduisant ainsi la charge effective en mémoire et disque
- Le cache d'experts en RAM persiste entre les requêtes : les experts fréquemment consultés restent chargés, limitant les re-lectures disque
- Benchmarks sur Qwen3-Next-80B (48 GB) : 37 tok/s en génération avec Janas contre 2,8 avec llama.cpp ; 62 tok/s en lecture de prompt vs 16
- Le projet est en développement précoce : API instable, changements fréquents, testé sur une seule machine (Debian 13, Intel Core Ultra 9 185H, Arc GPU intégré, SSD NVMe 5.7 GB/s)
- Comportement agressif : remplit toute la mémoire libre, lit le disque à pleine vitesse avec O_DIRECT, peut causer des ralentissements ou rendre l'interface graphique non réactive sous charge
- L'outil dispose de garde-fous : `--cache <GiB>` limite la mémoire, `JANAS_GPU=0` désactive le GPU, Ctrl-C et Ctrl-D offrent des sorties d'urgence
- Fonctionnalités rapportées : modèles pré-convertis au format .jns, téléchargement automatique depuis Hugging Face, interface interactive `janas-chat`
Dans les commentaires
Débat partagé. Si certains louent l'émergence d'une écologie open source diversifiée d'outils d'inférence locale, d'autres questionnent la nouveauté réelle face aux capacités de llama.cpp (éventuellement améliorées), et pointent l'absence de généralisation. Peu de friction technique majeure, surtout de la curiosité en attente de stabilité et de validation multi-hardware.
- Plusieurs commentateurs relèvent que llama.cpp offre des capacités similaires depuis des années : l'un affirme que ce type de projet réapparaît régulièrement, questionnant la différenciation réelle.
- Des critiques sur les modèles testés : pourquoi Qwen3 et pas Qwen 3.8 ? L'absence de modèles plus récents ou plus petits crée du doute sur la couverture réelle de l'outil.
- Strata est cité comme une alternative existante, déjà capable de streamer Qwen3.8-Flash-Next, ramenant le projet à une reimplementation potentielle.
- Stabilité hardware préoccupante : un commentateur documente des réinitialisations de driver GPU déclenchées par OOM lors du chargement de poids, un problème évidemment non résolu.
- Sur le plan pratique, l'outil teste uniquement sa machine de développement (Intel Core Ultra 9 185H, Mesa 26.1.6, DDR5) ; CPU AMD, GPU discrets, disques plus lents et configurations RAM différentes n'ont jamais été essayés.
- Inquiétude sur la capacité à maintenir l'interface graphique réactive : un utilisateur rapporte que des projets d'inférence LLM mal gérés tuent facilement le desktop en saturant le swap.
- Demandes de synthèse : constat que plusieurs projets similaires existent déjà, créant besoin d'un guide comparatif ou d'une fusion de leurs meilleures caractéristiques plutôt que de nouvelles réimplementations.
- L'enthousiasme est tempéré par une vision pragmatique : 62 tok/s est suffisant pour un usage personnel local, mais l'outil reste très expérimental et non prêt pour une utilisation stable en production.
Alternatives citées : Llama.cpp (référence historique pour l'inférence locale quantifiée, moins performant sur MoE selon ces benchmarks), Strata (déjà capable de streamer Qwen3.8-Flash-Next), éventuellement des approches réseau-distribuées mentionnées par un commentateur.
Notre lecture
Janas illustre un mouvement réel : l'outillage open source local pour LLM se diversifie. Les performances affichées sur mixture-of-experts sont probantes (3x à 13x plus rapides que llama.cpp sur les gros modèles testés). Cependant, l'outil reste expérimental, testé sur une seule machine, instable (réinitialisations GPU documentées), et sans API stable. Pour les développeurs et curieux sous Linux x86-64 avec NVMe rapide, c'est intéressant à essayer localement. Pour une adoption plus large ou une utilisation professionnelle, il faudra attendre validation multi-hardware, stabilité proven, et surtout clarification de ce qui le différencie vraiment de llama.cpp ou Strata au-delà des benchmarks de ce lab unique. À surveiller, mais pas d'action DSI immédiate : c'est du prototyping, pas un remplacement.