Ollama fonctionne désormais sur Apple Silicon avec MLX

 (ollama.com)
5 points par GN⁺ 2026-03-31 | 1 commentaires | Partager sur WhatsApp
  • Une version preview d’Ollama basée sur le framework Apple MLX a été publiée, avec des gains de performance grâce à l’architecture mémoire unifiée d’Apple Silicon
  • Grâce au GPU Neural Accelerator des puces de la série M5, le TTFT (temps jusqu’au premier token) et la vitesse de génération des tokens progressent tous deux
  • La prise en charge du format NVFP4 réduit les besoins en bande passante mémoire et en stockage tout en préservant la précision des modèles, et permet d’exécuter des modèles optimisés avec NVIDIA Model Optimizer
  • La réutilisation du cache et des politiques de cache intelligentes améliorent l’efficacité mémoire et la rapidité de réponse entre les conversations, tout en augmentant le taux de cache hit pour les prompts partagés
  • À l’avenir, la prise en charge sera étendue avec davantage de modèles et une fonction d’import de modèles personnalisés

Preview d’Ollama basée sur MLX sur Apple Silicon

  • Une nouvelle version preview d’Ollama, basée sur le framework MLX d’Apple, a été publiée
    • Elle permet d’exécuter plus rapidement sur macOS un assistant personnel (OpenClaw) ou des agents de code (Claude Code, OpenCode, Codex, etc.)
    • Elle améliore les performances en exploitant l’architecture mémoire unifiée d’Apple Silicon

  • Améliorations de performances sur Apple Silicon

    • Ollama fonctionne sur le framework de machine learning MLX d’Apple et exploite le GPU Neural Accelerator des puces M5, M5 Pro et M5 Max pour accélérer à la fois le TTFT (temps jusqu’au premier token) et la vitesse de génération des tokens
    • Lors d’un test du 29 mars 2026, le modèle Qwen3.5-35B-A3B d’Alibaba (quantification NVFP4) a été comparé à l’implémentation précédente d’Ollama (Q4_K_M)
    • Ollama version 0.19 a enregistré 1851 token/s en prefill et 134 token/s en décodage en exécution int4

  • Prise en charge de NVFP4

    • Le format NVFP4 de NVIDIA est pris en charge, ce qui permet à la fois de préserver la précision des modèles et de réduire les besoins en bande passante mémoire et en stockage
    • La cohérence des résultats est assurée entre les environnements d’inférence utilisant NVFP4 et les environnements de production
    • Il est possible d’exécuter des modèles optimisés avec le Model Optimizer de NVIDIA
    • D’autres niveaux de précision (precision) seront ajoutés selon la conception et les usages des partenaires de recherche et matériels d’Ollama

  • Améliorations du système de cache

    • La réutilisation du cache réduit l’utilisation mémoire entre les conversations et améliore le taux de cache hit lorsque des prompts système partagés sont utilisés
    • Des checkpoints intelligents ont été introduits pour réduire la charge de traitement des prompts et améliorer la vitesse de réponse
    • Une politique intelligente d’éviction du cache permet de conserver plus longtemps les préfixes (prefix) partagés, même lorsque d’anciennes branches sont supprimées

  • Comment démarrer

    • Télécharger Ollama 0.19
    • Le nouveau modèle Qwen3.5-35B-A3B a été ajusté avec des paramètres d’échantillonnage adaptés aux tâches de code
    • Un Mac avec au moins 32 Go de mémoire unifiée est requis
    • Exemples d’exécution :
      • Claude Code: ollama launch claude --model qwen3.5:35b-a3b-coding-nvfp4
      • OpenClaw: ollama launch openclaw --model qwen3.5:35b-a3b-coding-nvfp4
      • Dialogue avec le modèle: ollama run qwen3.5:35b-a3b-coding-nvfp4

  • Feuille de route

    • Prise en charge de davantage de modèles à venir
    • Ajout prévu d’une fonction d’import de modèles personnalisés basée sur les architectures prises en charge
    • Extension continue de la liste des architectures prises en charge

  • Remerciements

    • L’équipe des contributeurs MLX pour le développement du framework d’accélération
    • L’équipe NVIDIA pour la quantification NVFP4, l’optimisation des modèles, la prise en charge de MLX CUDA, l’optimisation d’Ollama et les tests
    • Les équipes GGML et llama.cpp pour la création du framework local et de la communauté
    • L’équipe Alibaba Qwen pour la mise à disposition du modèle open source et sa collaboration

À lire aussi

1 commentaires

 
GN⁺ 2026-03-31
Avis Hacker News

  • "apfel", que j’ai créé, est une CLI pour les foundation models locaux on-device d’Apple
    Il y a bien une surabondance de garde-fous avec une limite de contexte de 4k et même des blocages sur les descriptions de couleurs, mais le fait de pouvoir l’utiliser directement dans des scripts bash sans appel externe est vraiment puissant

    • Franchement, j’ai du mal à croire qu’Apple ait lancé le produit dans cet état
      J’en attendais beaucoup moi aussi, mais après l’avoir essayé, la déception a été grande. Au final, je trouve presque rassurant qu’Apple semble maintenant avoir complètement pivoté vers Gemini
    • Super projet. Tu envisages aussi une distribution via Homebrew ?

  • Je pense que les LLM on-device sont l’avenir
    La sécurité est renforcée, la consommation électrique est plus faible que dans les datacenters, et cela peut aussi atténuer le problème de la demande en inférence. La plupart des utilisateurs n’ont pas besoin des performances des modèles les plus avancés

    • La sécurité est meilleure, mais l’efficacité d’approvisionnement peut au contraire se dégrader
      Les datacenters sont presque 100 fois plus efficaces que les PC personnels grâce au batching des GPU et à leur taux d’utilisation élevé
    • Du point de vue des entreprises, un modèle centralisé en datacenter peut rester rationnel
      Cela dit, une approche hybride où un modèle local traite les requêtes simples et envoie les plus complexes vers le cloud semble prometteuse
    • J’expérimente en ce moment des modèles locaux sur un M4 MBP avec llama.cpp installé
      Il intègre une interface de style ChatGPT, pratique pour faire des tests rapides. Même avec 16 Go de RAM, certains modèles tournent plutôt bien
      Par exemple, Qwen 3.5 9B est très censuré, tandis que la version uncensored est à l’inverse presque trop permissive, ce qui rend la recherche d’un bon équilibre intéressante
    • Avec l’offloading sur SSD, on peut aussi faire tourner des modèles SOTA sur un PC grand public
      En revanche, la bande passante du SSD devient le goulot d’étranglement, donc plus il y a de RAM pour le cache, mieux c’est. Si on peut se permettre d’attendre les réponses, cela reste tout à fait pratique
    • Ça fait 5 ans que je tiens un journal numérique et j’anticipais cette évolution
      J’ai récemment créé une app graphRAG en combinant Qwen 3.5 4B et 27B, et le fait de séparer les petites tâches de la question-réponse fonctionne plutôt bien
      J’ai utilisé MLX, et je l’ai trouvé nettement plus rapide pour le traitement par lots de l’extraction d’entités

  • Ravi de voir que l’inférence Ollama sur Mac s’est nettement améliorée grâce à MLX
    En particulier, la fonction de cache KV sur SSD de omlx.ai a changé la donne
    Même si une session disparaît de la mémoire, il n’est pas nécessaire de refaire le prefill, et grâce à la vitesse de prefill du M5 Max, on peut consacrer plus de temps à la génération

  • Je fais tourner qwen 70b 4-bit avec llama.cpp sur un M2 Max 96 Go
    C’est suffisamment stable pour un usage quotidien. Avant, Ollama appelait llama.cpp via le shell, mais avec le passage natif à MLX, l’efficacité mémoire devrait s’améliorer
    J’ai l’intention de comparer avec la voie gguf sur les gros modèles

    • Je serais curieux de connaître la vitesse de génération en tokens par seconde
    • Au lancement initial, certains modèles GGUF ont été écrasés, ce qui a bloqué leur téléchargement sur les plateformes autres qu’Apple Silicon. J’espère que ce sera vite corrigé

  • Je me demande pourquoi on utilise encore Ollama
    Lemonade ou llama.cpp sont mieux optimisés et l’ergonomie est comparable

  • Je me demande s’il existe une alternative non-Mac capable de faire tourner des modèles locaux avec un niveau de performances comparable à celui d’un Mac

    • Pas vraiment au même niveau. Sur PC, il faut un GPU du niveau d’une 5090, mais en efficacité token par coût comme en efficacité énergétique, Apple Silicon est largement supérieur

  • Je me demande ce que ça donne par rapport au moteur d’inférence MLX optiq le plus récent
    optiq prend en charge la Turboquantization

  • Je suis curieux de voir la comparaison de performances entre llama.cpp et MLX

    • MLX est un peu plus rapide, mais utilise légèrement plus de RAM
      Malgré cela, dans la plupart des cas, le gain de vitesse vaut davantage le coup

  • J’attends le jour où, avec seulement 16 Go de RAM, on pourra faire tourner confortablement Claude Code avec un LLM local sur macOS

    • J’ai entendu dire qu’il fallait actuellement au moins 32 Go, mais je me demande à quel point on s’en rapproche en pratique