28 points par GN⁺ 2026-03-03 | 1 commentaires | Partager sur WhatsApp
  • Un outil qui, parmi des centaines de modèles et fournisseurs de LLM, trouve en une seule commande les modèles réellement exécutables sur la RAM, le CPU et le GPU de votre système
  • Il note chaque modèle selon la qualité, la vitesse, l’adéquation et le contexte, puis indique sa faisabilité d’exécution, avec prise en charge à la fois d’une TUI (interface terminal) et d’un mode CLI
  • Prend en charge les GPU multiples, l’architecture MoE, la quantification dynamique, l’estimation de vitesse et l’intégration avec des runtimes locaux (Ollama, llama.cpp, MLX)
  • Analyse pour chaque modèle le mode d’exécution (GPU, CPU+GPU, CPU) et le niveau d’adéquation (Perfect, Good, Marginal, Too Tight) afin de proposer la meilleure combinaison
  • Fournit aux développeurs qui veulent exploiter efficacement les LLM en local une automatisation du choix de modèle basée sur le matériel

Aperçu des principales fonctionnalités

  • llmfit est un outil en ligne de commande qui détecte les caractéristiques matérielles du système et évalue si un modèle LLM peut réellement être exécuté
    • Lit les informations de RAM, CPU et GPU pour calculer, pour chaque modèle, des scores de qualité, vitesse, adéquation et contexte
    • Les résultats sont affichés soit dans une TUI interactive, soit dans une CLI classique
  • Prend en charge les GPU multiples, le Mixture-of-Experts (MoE), la sélection de quantification dynamique, l’estimation de vitesse et l’intégration avec des runtimes locaux
  • Prend en charge Ollama, llama.cpp et MLX comme runtimes locaux, avec détection automatique des modèles installés et possibilité de téléchargement
  • Le mode Plan permet de calculer à rebours le matériel minimum et recommandé nécessaire pour un modèle donné
  • Fonctionne sur diverses plateformes, dont macOS, Linux, Windows et Ascend

Installation et exécution

  • Sur macOS/Linux, installation via brew install llmfit ou curl -fsSL https://llmfit.axjns.dev/install.sh | sh
  • Sur Windows, installation possible via cargo install llmfit
  • À l’exécution, la commande llmfit ouvre la TUI et affiche les spécifications du système ainsi que la liste des modèles
  • En mode CLI, divers sous-commandes sont disponibles comme llmfit --cli, llmfit fit --perfect -n 5, llmfit recommend --json

Fonctionnement

  • Détection matérielle : collecte des informations RAM, CPU et GPU à l’aide de sysinfo, nvidia-smi, rocm-smi, system_profiler, etc.
  • Base de données de modèles : récupère des centaines de modèles via l’API HuggingFace et les stocke dans data/hf_models.json
    • Inclut notamment les principaux modèles de Meta Llama, Mistral, Qwen, Google Gemma, Microsoft Phi, DeepSeek, IBM Granite, etc.
  • Quantification dynamique : parcourt les niveaux Q8_0 à Q2_K et sélectionne automatiquement la meilleure quantification possible dans la mémoire disponible
  • Estimation de vitesse : utilise une formule basée sur la bande passante mémoire GPU, (bandwidth_GB_s / model_size_GB) × 0.55
    • Table de bande passante intégrée pour environ 80 GPU
  • Analyse d’adéquation : évalue, pour les modes GPU, CPU+GPU et CPU, la faisabilité d’exécution et la marge mémoire disponible

Interface utilisateur

  • Touches de la TUI :
    • f pour le filtre d’adéquation, a pour le filtre de disponibilité, s pour changer le critère de tri
    • p pour entrer en mode Plan, d pour télécharger un modèle, t pour changer de thème
  • En mode Plan, il est possible de modifier la longueur de contexte, la quantification, la vitesse cible en tokens, etc., afin de calculer la VRAM/RAM/CPU nécessaire
  • Thèmes : 6 thèmes de couleur intégrés, dont Default, Dracula, Solarized, Nord, Monokai et Gruvbox

Runtimes et intégrations

  • Intégration Ollama : connexion à une instance Ollama locale ou distante (variable d’environnement OLLAMA_HOST) pour détecter les modèles installés et les télécharger
  • Intégration llama.cpp : télécharge les fichiers GGUF depuis HuggingFace dans le cache local et indique leur statut d’installation
  • Intégration MLX : prise en charge du cache de modèles et de la connexion serveur pour Apple Silicon
  • Intégration OpenClaw : grâce à la skill llmfit-advisor, l’agent OpenClaw peut automatiquement recommander et configurer des modèles adaptés au matériel

Gestion de la base de données de modèles

  • Génération automatique de la liste des modèles depuis l’API HuggingFace via le script scripts/scrape_hf_models.py
  • Mise à jour des données et reconstruction du binaire via la commande make update-models
  • Les modèles sont classés en catégories : généralistes, code, raisonnement, multimodal, chat, embeddings, etc.
  • Le cache des sources GGUF (data/gguf_sources_cache.json) conserve les chemins de téléchargement pendant 7 jours

Prise en charge des plateformes

  • Linux/macOS (Apple Silicon) : prise en charge complète
  • Windows : détection RAM/CPU et prise en charge des GPU NVIDIA via nvidia-smi
  • En cas d’échec de la détection GPU, l’option --memory= permet de définir manuellement la VRAM

Licence

  • Licence MIT

1 commentaires

 
GN⁺ 2026-03-03
Avis sur Hacker News
  • Ce projet a l’air assez sympa et utile, mais j’aimerais que ce soit un site web
    Faire tourner un exécutable, c’est un peu contraignant. Je pense que ce type de fonctionnalité peut tout à fait être implémenté sur le web

    • Cet outil dépend de la détection du matériel, donc il a des limites sur le web
      D’après la description sur GitHub, il faut lire au niveau système la quantité de RAM, le nombre de GPU et le type de backend (CUDA, Metal, etc.)
      À cause des contraintes de sandbox du navigateur, JavaScript ne peut pas accéder directement à ce type d’informations
      Pour en faire une version web, il faudrait que l’utilisateur envoie un rapport .spx sous macOS ou inxi sous Linux, ou bien qu’il sélectionne lui-même sa configuration matérielle
      Cette approche est moins pratique, mais elle a l’avantage de permettre de tester des combinaisons de matériel virtuelles
    • Hugging Face propose aussi une fonction similaire, mais il faut saisir les informations matérielles manuellement
      En réalité, je ne pense pas qu’il soit fréquent que quelqu’un fasse tourner des modèles locaux sans connaître son propre matériel
    • J’ai vu récemment un site appelé whatmodelscanirun.com, ça peut être une bonne référence
    • Hugging Face a déjà une fonctionnalité intégrée pour ça
    • Il existe aussi inferbench.com, un site de base de données communautaire sur les modèles LLM. On y partage la vitesse en tokens et des informations de configuration
  • Ce projet est vraiment excellent
    En réalité, il suffit surtout de connaître la taille du LLM et la bande passante mémoire
    Avec une formule simple, on peut déterminer si un modèle convient
    Par exemple, pour faire tourner un modèle 32B en 4bit, il faut au minimum 16 Go de VRAM
    Si on calcule tok/s = memory_bandwidth / llm_size, une RTX3090 (960GB/s) donne environ 60 tok/s
    Pour les modèles MoE, c’est le nombre de paramètres actifs qui détermine la vitesse
    En ajoutant environ 10 % de marge, on obtient une estimation réaliste

    • Le cache KV écrit peu de fois par token, donc il se swap facilement
      Si on charge les paramètres du modèle avec mmap, on peut monter en charge sans perte de performance tant qu’on a assez de RAM
    • C’est une bonne règle empirique. En revanche, dans la plupart des cas, la taille de la fenêtre de contexte fait augmenter l’usage de la RAM de façon exponentielle
    • Je ne connaissais pas cette formule, merci de l’avoir partagée
  • Visuellement, c’est réussi, mais Qwen 3.5 tourne bien sur ma machine alors que l’outil indique que c’est impossible
    Au final, ce genre d’outil semble surtout utile comme référence approximative
    Avec des optimisations personnalisées comme celles d’Unsloth, on peut en pratique faire tourner davantage de modèles
    Comme les modèles sortent à un rythme très rapide, la maintenance ne doit pas être simple non plus

    • Il est possible qu’il y ait en fait du swap entre le disque et la RAM
      Ce type d’approche peut réduire la durée de vie du disque à long terme
  • L’idée est bonne, mais les modèles recommandés sont un peu datés
    Sur mon MacBook Pro M4 (128 Go de RAM), il recommande Qwen 2.5 ou Starcoder 2

  • Comme plusieurs l’ont dit, ce serait mieux sous forme de site web plutôt que d’outil CLI
    Il suffirait de saisir dans un formulaire les specs CPU, RAM et GPU pour faire le calcul

  • Je ne comprends pas pourquoi il faut forcément télécharger puis exécuter quelque chose
    J’aimerais simplement renseigner la configuration via des menus déroulants et voir le résultat

  • Ça couvre bien la plupart des cas, mais pour des cas comme les iGPU AMD non pris en charge par ROCm, on peut les faire tourner en s’appuyant sur Vulkan
    Avec les réglages du pilote, on peut utiliser la RAM système comme de la VRAM, ce qui permet de charger des modèles normalement impossibles
    C’est particulièrement utile pour le layer offloading ou les modèles MoE quantifiés

  • Claude donne aussi des recommandations de modèles plutôt correctes si on lui fournit les specs de la machine

    • J’ai moi aussi demandé à Claude : « Quel est le meilleur LLM local que je peux faire tourner sur cet ordinateur ? » et il m’a recommandé un modèle déjà installé ainsi qu’un autre
      Je ne sais pas si les informations étaient à jour. J’ai testé sur la base d’Ollama et de LM Studio
  • J’utilise Claude ou Codex pour faire tourner en série plusieurs modèles avec Ollama, puis évaluer automatiquement les performances
    En une trentaine de minutes, on peut trouver le modèle adapté à son système

    • Je me demande si tu pourrais partager ce prompt