ANEMLL - projet open source pour exécuter des LLM sur l’Apple Neural Engine

• Fournit un pipeline d’inférence LLM pouvant s’exécuter sur l’Apple Neural Engine (ANE)
• Permet une inférence on-device dans des applications Swift/C++ ou des apps iOS/macOS à partir de modèles Hugging Face
• La toute dernière version 0.3.0 Alpha inclut des outils pour convertir des modèles Hugging Face au format CoreML, une implémentation CLI d’inférence en Swift, des exemples d’apps iOS/macOS, du code de test Python et des outils de benchmark
• Prend en charge les modèles LLaMA 3.2 (1B / 8B) ainsi que Distilled DeepSeek R1 8B et DeepHermes 3B / 8B, avec une extension prévue à davantage d’architectures de modèles à l’avenir
• L’objectif est de fournir un framework flexible et simple permettant de convertir des modèles Hugging Face pour l’ANE

[GN⁺]

Avis sur Hacker News

• Quelqu’un se demande s’il y a eu un suivi concernant l’affirmation d’Apple selon laquelle les modèles optimisés pour l’ANE seraient « jusqu’à 10 fois plus rapides avec une consommation mémoire 14 fois plus faible »

  • MLX et llama.cpp ne prennent pas en charge l’ANE
  • llama.cpp explore cette idée
  • MLX, bien que créé par Apple, ne prend pas non plus en charge l’ANE

• Lors du lancement des laptops Snapdragon X, il avait été affirmé que le NPU serait utilisé pour les LLM

  • Certains ont cru les affirmations de Qualcomm, mais en pratique les modèles ne s’exécutent que sur le CPU
  • Le NPU n’est économe en énergie que pour les petits modèles, et n’est pas adapté aux gros modèles
  • Le support de Vulkan est le seul espoir

• Quelqu’un a eu l’impression que le Neural Engine était du silicium gaspillé

  • Il serait possible d’ajouter davantage de cœurs GPU et de basculer les API de traitement neuronal vers le GPU si nécessaire
  • La personne aimerait connaître des avis contraires

• Le principal avantage serait une consommation électrique nettement plus faible

  • D’après des benchmarks sur M1 Max et M4 Pro, le GPU est plus rapide mais consomme davantage
  • Les modèles ANE sont limités à 512 tokens, ce qui les rend encore difficiles à utiliser en production

• Le README ne contient pas l’information la plus importante

  • On aimerait savoir combien de tokens/s sont possibles par rapport à llama.cpp / MLX à quantification identique
  • Cela ne vaut la peine de changer de plateforme par défaut qu’en cas d’amélioration majeure

• Quelqu’un essaie de comprendre quel est le secret de cette technologie

  • On se demande si le point clé est la dépendance à coremltools, ou s’il existe d’autres techniques importantes

• La mémoire unifiée d’Apple fournit suffisamment de RAM pour exécuter de gros modèles qui nécessiteraient autrement plusieurs GPU

• Quelqu’un se demande si coreml utilise l’ANE

  • On se demande s’il existe, dans coreml, des goulots d’étranglement nécessitant un accès de bas niveau

• Quelqu’un se demande s’il y a un gain de performances pour la vitesse d’inférence sur les MacBook de la série M

  • On se demande si l’objectif principal est surtout de faire fonctionner l’inférence sur d’autres plateformes (iOS, etc.)
  • S’il existe un gain de performances, on aimerait voir une comparaison en tokens/s avec Ollama

• Le contrôle strict d’Apple sur l’ANE surprend

  • Certains espèrent voir un jour les gens pouvoir réellement l’utiliser
  • On se demande si les entreprises cachent la technologie pour garder le contrôle, ou s’il existe réellement de fortes raisons techniques