Contexte technique
J'adore ce genre de nouvelles, non pas pour le buzz, mais parce qu'elles ramènent rapidement l'implémentation de l'IA à la réalité. C'est simple : DeepSeek 4 Flash q2 tourne déjà en local sur des MacBook M5 avec 128 Go de RAM, et les tests en direct montrent environ 30 tok/s.
Pour un scénario local mono-utilisateur, ce n'est plus un gadget. Surtout si vous envisagez une automatisation par IA sans cloud, avec des données privées et une latence prévisible.
Ce qui a vraiment retenu mon attention : DeepSeek lui-même utilise jusqu'à 80 Go de mémoire. Le reste est consommé par des processus adjacents comme Claude Code, Codex et d'autres outils, qui peuvent facilement prendre 35 Go supplémentaires.
L'histoire ne concerne donc pas seulement le modèle, mais tout le stack de travail qui l'entoure. Sur le papier, vous avez 128 Go, mais en réalité, cette marge disparaît très vite si vous ne dédiez pas la machine presque exclusivement à l'inférence.
Autre nuance concrète : le tool calling n'est pas parfait, et le modèle oublie parfois de fermer les balises. Je ne considère pas cela comme un défaut cosmétique, mais comme un détail d'ingénierie, car c'est précisément ce qui casse les pipelines d'agents et les chaînes d'actions automatisées.
La bonne nouvelle, c'est que cela ressemble à un problème soluble au niveau des wrappers, de la validation et du post-traitement. La mauvaise, c'est qu'on ne peut pas s'y fier aveuglément « out-of-the-box » si votre logique de production dépend d'un format strict.
Ce que cela change pour l'entreprise et l'automatisation
J'en tire trois conclusions pratiques. Premièrement : le déploiement local de grands modèles sur Apple Silicon peut maintenant être discuté de manière réaliste, non plus comme une expérience, mais comme une intégration IA fonctionnelle pour les équipes qui privilégient la confidentialité et le contrôle.
Deuxièmement : le seuil matériel n'a pas disparu. Si vous n'avez pas 128 Go et de la discipline avec les processus en arrière-plan, la belle idée se transforme rapidement en une bataille pour la mémoire et une UX instable.
Troisièmement : les gagnants sont ceux qui ont besoin d'un assistant de code local, d'un agent interne ou du traitement de documents en privé. Les perdants sont ceux qui attendent une vitesse de cloud et une utilisation parfaite des outils sans ingénierie supplémentaire.
Chez Nahornyi AI Lab, nous analysons précisément ces cas concrets : où un modèle local est-il vraiment plus rentable qu'une API, comment construire une architecture IA sans coûts superflus, et comment sécuriser le tool calling pour que l'automatisation ne s'effondre pas sur des détails. Si vous envisagez un pipeline d'automatisation IA en local, nous pouvons sereinement évaluer votre stack et construire une solution sans devoir spéculer sur les forums.