CanIRun.ai — Mon ordinateur peut-il exécuter des modèles d’IA ?

 (canirun.ai)
40 points par GN⁺ 2026-03-14 | 1 commentaires | Partager sur WhatsApp
  • Un outil web permettant de vérifier quels modèles d’IA une machine locale peut réellement exécuter
  • Il estime les performances matérielles via l’API WebGPU du navigateur, et les résultats peuvent différer des spécifications réelles
  • Pour chaque modèle, il affiche notamment les besoins mémoire, la vitesse de traitement des tokens, la longueur de contexte et une note d’exécution (S~F)
  • Il inclut les principaux modèles open source et commerciaux comme Qwen, Llama, Gemma, Mistral, DeepSeek, GPT-OSS
  • Il permet d’évaluer rapidement la faisabilité d’une exécution locale de l’IA et peut servir de référence utile pour les développeurs et les chercheurs

Présentation du service

  • CanIRun.ai est un site web qui permet d’explorer les modèles d’IA pouvant être exécutés en local
    • En ouvrant le site dans leur navigateur, les utilisateurs peuvent consulter la liste des modèles compatibles en fonction des performances de leur système
    • Les résultats sont estimés via l’API WebGPU et peuvent différer des performances réelles du matériel
  • Chaque modèle est classé selon une note de performance (S~F), ce qui permet de comprendre intuitivement sa faisabilité d’exécution et son efficacité

Système de notation des modèles

  • Les notes sont réparties en S, A, B, C, D, F, S correspondant à l’exécution la plus fluide
    • Exemple : sur une NVIDIA GeForce RTX 4070 12GB
    • Qwen 3.5 9B, Llama 3.1 8B, entre autres, sont affichés en S(90/100) et peuvent s’exécuter de manière fluide
    • Phi-4 14B est noté A(70/100) et « fonctionne bien »
    • GPT-OSS 20B, Mistral Small 3.1 24B, entre autres, sont notés D(34~39/100) et considérés comme « presque impossibles à exécuter »
    • D’autres modèles comme Gemma 3 27B, Qwen 3 32B et la plupart des modèles de 27B et plus sont indiqués en F(0/100) comme « trop lourds »

Sources des données et base technique

  • Les données des modèles sont collectées depuis llama.cpp, Ollama et LM Studio
  • Chaque page de modèle affiche en détail des éléments comme l’utilisation mémoire, la longueur de contexte, la vitesse des tokens et le type d’architecture (Dense/MoE)

Intérêt pratique

  • Fournit une référence concrète aux développeurs, chercheurs et utilisateurs open source qui souhaitent exécuter directement des modèles d’IA en local
  • Aide à définir une stratégie adaptée de choix et de déploiement des modèles en comparant leur taille et leur efficacité face aux performances GPU
  • Son fonctionnement dans le navigateur permet un test immédiat sans installation, ce qui constitue l’un de ses principaux atouts

À lire aussi

1 commentaires

 
GN⁺ 2026-03-14
Avis sur Hacker News

  • J’ai consacré énormément de temps ces deux dernières années à expérimenter avec des modèles locaux
    Les petits modèles, comme qwen3.5:9b par exemple, étaient très adaptés à l’usage d’outils locaux, à l’extraction d’informations et aux applications embarquées
    Pour le code, des outils cloud comme Google Antigravity, gemini-cli ou Anthropic Claude étaient plus efficaces
    J’ai passé plus de 100 heures à expérimenter une configuration locale avec Emacs et Claude Code, mais je ne la recommande pas aux utilisateurs ordinaires
    À la place, je pense que le vrai point d’équilibre consiste à bien maîtriser des petits modèles locaux embarqués et pratiques

    • Je recommande vivement qwen3.5:9b
      Ce modèle est petit, mais ses capacités de raisonnement multimodal sont excellentes, et son système de raisonnement interne (CoT) est stable
      J’ai été particulièrement impressionné par sa nouvelle structure de compromis entre VRAM et taille de contexte — il peut traiter 100K tokens avec 1,5 Go de VRAM, ce qui permet des conversations longues ou le traitement de documents même sur une RTX 3060
    • J’ai essayé qwen3.5 pour des outils locaux, mais les résultats n’étaient pas très bons
      Un chatbot Discord qui fonctionnait bien avec GPT-OSS-120B avait avec Qwen un problème où il imitait les appels d’outils sans les exécuter réellement
      Au final, j’ai séparé les usages : Qwen pour les images, GPT pour les conversations générales
    • J’ai utilisé qwen3.5 9b, mais le taux d’hallucination était élevé
      Lors de l’exploration locale de dépôts de code, 30 à 50 % des résultats inventaient des noms de fichiers ou de fonctions erronés
      Après vérification avec KimiK2, la plupart étaient faux. Les petits modèles sont intéressants, mais il faut faire attention à leur fiabilité
    • Je me demande comment les gens intègrent concrètement les petits modèles dans leur workflow
      J’expérimente avec ollama sur un MacBook Pro M4 (128 Go de RAM), mais je n’ai pas encore trouvé de flux satisfaisant
    • Je me demande si une combinaison avec un grand modèle pour la planification et un petit modèle local pour écrire le code peut être pertinente
      J’aimerais réduire ma dépendance à Claude Code ou Codex

  • Ce site semble estimer les performances des modèles à partir de leur bande passante mémoire et de leur taille
    Mais les modèles MoE (comme GPT-OSS-20B) n’utilisent pas tous leurs paramètres à chaque token, donc ils peuvent générer des tokens plus vite sur le même matériel
    GPT-OSS-20B a 3,6B de paramètres actifs, donc il tourne à une vitesse comparable à un modèle dense 3~4B, tout en exigeant en VRAM la taille complète du modèle 20B
    Côté intelligence, il est évalué au niveau d’un modèle dense d’environ 8,5B

    • En pratique, les performances des modèles que j’ai testés sur mon portable Strix Halo étaient bien meilleures que prévu
      Pour les modèles MoE, il faut calculer la bande passante mémoire en se basant uniquement sur les paramètres actifs
    • Ce calcul semble basé sur la taille totale du contexte
      Mais en usage réel, un contexte plus petit suffit souvent
      llama-fit-params de llama.cpp est utile dans ce genre de situation
    • La documentation l’explique clairement
      Pour un modèle MoE comme Mixtral 8x7B, seuls environ 12,9B sur 46,7B sont activés
      On obtient donc à la fois la qualité d’un grand modèle et la vitesse d’un petit, mais le modèle complet doit malgré tout rester chargé en mémoire
      documentation de canirun.ai
    • Il y a toutefois une légère imprécision
      La vitesse de génération de tokens est similaire, mais la vitesse de prefill est plus lente sur les gros MoE
      De plus, avec le speculative decoding, un petit modèle dense peut gagner jusqu’à 3x en vitesse, alors qu’un modèle MoE n’en tire presque aucun bénéfice

  • Des tentatives comme TFA ou llmfit sont intéressantes, mais ce qui me frustre, c’est qu’il est difficile de savoir quel modèle offre la meilleure qualité sur mon matériel
    Par exemple, Qwen 3.5 27B Q6 @ contexte 100k fonctionne bien, mais la liste de recommandations met en avant l’ancien Qwen 2.5
    Pour moi, au-delà de 50 tok/s, c’est suffisant, donc j’aimerais pouvoir trier selon la qualité

    • La question est trop large
      Par exemple, pour « modèle open de qualité pour le code avec 8 Go de VRAM, 32 Go de RAM, t/s ≥ 30 et contexte ≥ 32K », ce serait Qwen2.5-Coder-7B-Instruct
      Pour « recherche web avec 24 Go de VRAM et 32 Go de RAM », ce serait Qwen3-30B-A3B-Instruct-2507
      Pour « embeddings RAG avec 40 Go de VRAM et 128 Go de RAM », ce serait Qwen3-Embedding-8B
      En clair, il faut des recommandations de modèles précises selon le matériel
    • Je me demande quel est le rapport coût/efficacité de l’exécution locale ($/Mtok)
      Hors coût de l’électricité, c’est presque gratuit, mais la vitesse et la qualité sont inférieures
      Est-ce que la préférence pour le local vient simplement de la confidentialité des données ?
    • Ce problème est vraiment difficile, et moi aussi j’y travaille depuis plus d’un an
      Dès qu’on essaie d’optimiser la qualité et l’allocation des ressources en tenant compte de plusieurs appareils et modèles en même temps, la complexité explose
      Pour l’instant, j’ai fini par faire un compromis en choisissant simplement le plus gros modèle quantifié
    • Au fond, un LLM n’est qu’une calculatrice spécialisée
      Il n’a pas besoin d’être exact comme une calculatrice classique, et comme les objectifs des créateurs du modèle et de l’utilisateur diffèrent, il est difficile de prévoir le résultat souhaité

  • Ça ressemble simplement à une version web de llmfit
    lien GitHub de llmfit

    • Exact. Mais llmfit est bien plus utile, car il détecte automatiquement les ressources système
    • Merci pour le lien. C’est en réalité bien plus utile que le site web
      Sur mon MBP M2 Max (96 Go de RAM) aussi, il indique que la plupart des LLM locaux tournent bien
      J’ai été surpris par le nombre de modèles exécutables en local

  • Comme alternative plus légère à Docker ou Python, je recommande une stack Rust+Wasm
    projet LlamaEdge

  • Il a bien détecté ma RTX 6000 Pro Max-Q (96 Go de VRAM), mais l’interface l’affiche comme une carte de 4 Go
    En plus, il ne prend pas en compte les modèles quantifiés et ne montre que les modèles en pleine résolution
    Il y a des améliorations à faire

  • La liste des GPU mobiles est insuffisante, et il ne semble pas comprendre des stratégies comme le partage de mémoire CPU ou le déchargement du cache KV
    Mon système est affiché comme Arc 750 (2 Go de RAM partagée), alors qu’en réalité c’est une RTX1000 Ada (6 Go de GDDR6)
    Qwen3 Coder Next, Devstral Small, Qwen3.5 4B, etc. fonctionnent très bien presque en temps réel
    Les modèles plus grands sont plus lents, mais il n’y a pas de problème de manque de tokens

  • C’est une idée sympa
    Cela dit, j’utilise une M3 Ultra (256 Go de RAM) et les options s’arrêtent à 192 Go
    J’aimerais aussi pouvoir choisir un modèle et comparer les performances selon le processeur

    • Dommage qu’Apple ait abandonné le modèle 512GiB

  • C’est la première fois que je réalise que mon navigateur fournit automatiquement des informations matérielles au site web

    • En pratique, ce n’est pas totalement exact
      Le site pense que j’ai un iPhone 19 Pro, alors qu’en réalité j’ai un iPhone SE de 1re génération
    • Sur les versions récentes de Librewolf, l’accès à WebGL demande une autorisation
      J’imagine que c’est comme ça qu’il détecte le matériel
    • Ce type d’information est souvent utilisé pour le fingerprinting du navigateur
      Les navigateurs axés sur la vie privée fournissent des informations aléatoires
    • Je suppose que si les compagnies aériennes pratiquent des prix différents selon l’OS, c’est probablement via ce genre de méthode

  • Je trouve étrange qu’il n’y ait apparemment aucune différence de performance entre les puces M4 et M5
    La taille de la mémoire ne semble pas non plus influencer les performances sur les grands modèles
    Globalement, cela donne l’impression d’être basé sur des estimations plutôt que sur des données réelles, donc il faudrait afficher clairement « ESTIMATE »