L’IA locale n’est plus un jouet. Ce n’est pas non plus ChatGPT sans cloud

Une entreprise ne peut pas envoyer certaines données à un service externe. Elle possède des rapports, des dossiers ou des documents internes qu’elle souhaite classer, résumer ou convertir en informations structurées. La question revient de plus en plus souvent : peut-on installer un modèle d’IA sur notre propre ordinateur et y effectuer ce travail ?

La réponse honnête est moins confortable. Pour une tâche bien délimitée —classer des documents, extraire des champs ou préparer un premier résumé—, elle peut être oui. Pour installer un « ChatGPT privé » capable de presque tout traiter avec la même qualité et la même vitesse sur un portable ordinaire, elle est généralement non.

Entre ces deux extrêmes, le territoire ne cesse de s’élargir. Exécuter un modèle en local ne garantit ni qu’il soit assez bon, ni qu’il réponde assez vite, ni que le système soit conforme à la réglementation. Mais une machine de laboratoire n’est plus indispensable pour obtenir un résultat utile.

Cette frontière évolue rapidement. Des modèles qui auraient semblé immenses il y a peu tiennent désormais, une fois quantifiés, sur un GPU grand public. D’autres, de quatre à douze milliards de paramètres, accomplissent sur un portable des tâches documentaires précises qui ont une réelle valeur pour une entreprise.

Deux machines annoncées par Apple en août illustrent bien l’étendue de ce terme. Le Mac mini M6 propose jusqu’à 32 Go de mémoire unifiée ; le Mac Studio M5 Ultra, jusqu’à 512 Go et 1,2 To/s de bande passante mémoire. Tous deux sont présentés comme des machines d’IA sur l’appareil, mais ils ne répondent pas à la même classe de problème. Le premier permet de travailler avec de petits et moyens modèles. Le second peut conserver en mémoire des modèles de plusieurs centaines de milliards de paramètres. La comparaison montre pourquoi « exécuter l’IA en local » reste une description trop imprécise pour fonder une décision d’architecture.

La question n’est plus de savoir si l’IA peut fonctionner en local. Il faut demander quelle tâche, avec quel taux d’erreur, sur quelles données et à quelle vitesse.

Ce que signifie réellement exécuter un modèle en local

Pendant l’entraînement, un modèle apprend des millions ou des milliards de valeurs numériques appelées poids. Ils sont le résultat de son apprentissage : de petits ajustements numériques qui, combinés, déterminent sa réponse à une entrée. Entraîner un modèle généraliste demande toujours une infrastructure immense. L’inférence est autre chose : elle consiste à charger ces poids déjà appris et à les utiliser sans réentraîner le modèle.

Lorsque nous téléchargeons un modèle à poids ouverts et l’ouvrons avec llama.cpp, Ollama ou LM Studio, l’inférence peut se dérouler entièrement sur notre machine. Le texte n’a pas à transiter par les serveurs de l’éditeur. Pour un essai, l’expérience ressemble à l’installation d’une application : on télécharge un programme, on choisit un modèle et on commence à dialoguer.

Il faut toutefois distinguer trois déploiements souvent regroupés sous le terme local :

• sur l’appareil, lorsque le modèle fonctionne sur le portable ou le téléphone d’une personne ;
• sur site, lorsqu’il fonctionne sur un serveur contrôlé par l’organisation ;
• dans un cloud privé, lorsque l’infrastructure est distante mais isolée et exploitée selon les conditions de l’entreprise.

Tous trois peuvent éviter l’envoi des données vers une API publique, sans offrir les mêmes garanties. Une application locale peut conserver l’historique, télécharger des composants, transmettre de la télémétrie ou synchroniser des dossiers vers une sauvegarde externe. Le modèle peut se trouver au bureau alors que l’OCR, la base vectorielle ou l’observabilité restent à l’extérieur.

L’inférence locale décrit l’endroit où le modèle s’exécute, pas tout le trajet des données.

Exécuter un modèle ne rend pas le processus viable

Pour évaluer un processus fondé sur l’inférence locale, il faut séparer trois conditions :

1. Le modèle et le contexte requis tiennent-ils dans l’infrastructure contrôlée ?
2. La latence et la concurrence sont-elles acceptables pour le processus ?
3. Le résultat atteint-il le seuil de qualité et d’erreur exigé par la tâche ?

Remplir la première condition prouve seulement que le modèle peut être chargé. Cela ne prouve pas que le système sera utile.

La première peut être estimée. Un modèle de 27 milliards de paramètres occupe environ 54 Go si l’on réserve 16 bits —16 chiffres binaires— à chaque poids. La quantification économise de l’espace en représentant ces valeurs avec moins de détail. C’est un peu comme arrondir des millions de nombres : le modèle rétrécit en échange d’une certaine perte de précision. À 4 bits, le calcul théorique tombe à environ 13,5 Go, même si le fichier réel et l’exécution demandent davantage.

Qwen 3.8 27B illustre bien ce changement. Ses poids d’origine occupent 55,6 Go. Une version Q4 —quantifiée à environ quatre bits par poids— utilisée par Simon Willison pèse environ 17 Go et peut analyser des images, générer du code et demander à d’autres outils d’exécuter des actions. Cela ne signifie pas qu’elle fonctionne avec 17 Go de mémoire totale : l’application, le système d’exploitation, les calculs intermédiaires et le contexte ont eux aussi besoin d’espace.

La fenêtre de contexte mérite une attention particulière. C’est la quantité de texte que le modèle peut garder à l’esprit pour répondre, mesurée en tokens : les fragments de mots dans lesquels il découpe le texte. Un modèle peut annoncer 128 000 ou 256 000 tokens sans pouvoir les exploiter raisonnablement sur un portable. À mesure que la conversation grandit, il doit réserver plus de mémoire pour conserver ces fragments et met plus de temps à lire toute l’entrée. Le contexte maximal de la fiche technique n’est pas le contexte opérationnel du système.

La latence et la capacité à servir plusieurs requêtes dépendent beaucoup de la bande passante mémoire. La capacité détermine si les poids tiennent ; la bande passante, la vitesse à laquelle le processeur peut les lire. C’est la différence entre la taille d’une bibliothèque et la rapidité avec laquelle on peut en sortir les livres. Pendant la génération, la machine doit déplacer sans cesse une grande partie des poids. Un GPU doté d’une mémoire rapide répond donc généralement bien mieux qu’un CPU, même si les deux ont une capacité suffisante. La mémoire unifiée d’Apple Silicon et de certains processeurs AMD permet au CPU et au GPU de partager la même réserve ; un GPU NVIDIA dédié est souvent plus rapide, mais limité par sa propre mémoire, la VRAM.

llama.cpp permet aussi de répartir le modèle entre CPU et GPU. Cela peut servir pour un essai, mais lire les poids depuis la RAM à travers le bus réduit la vitesse et peut invalider le résultat si le processus exige des réponses interactives ou plusieurs requêtes simultanées.

Ces ordres de grandeur aident à déterminer le type d’essai pertinent dans chaque environnement :

Mémoire disponible dans l’environnement	Modèles quantifiés qui tiennent généralement	Ce que cela permet d’évaluer
16 Go, sans GPU dédié	2B–8B ; 12B avec des réglages serrés	Classification, extraction simple et viabilité d’un flux hors ligne. Les documents longs peuvent être lents sur CPU.
32 Go de RAM ou de mémoire unifiée	8B–14B confortablement ; 20B–27B avec compromis	Qualité sur des documents réels, RAG —retrouver d’abord les passages pertinents dans la documentation interne— et sorties structurées, avec une concurrence limitée.
GPU avec 12–16 Go de VRAM	8B–14B entièrement sur GPU ; certains MoE autour de 20B	Latence interactive et contexte modéré. Un 27B exige en général plus de quantification ou un déchargement vers le CPU.
GPU avec 24 Go de VRAM	20B–32B en 4 bits	Si une classe plus capable réduit suffisamment les erreurs pour justifier sa latence et son coût d’exploitation.
64–128 Go de mémoire unifiée ou plusieurs GPU	70B et certains MoE plus grands avec quantification agressive	Robustesse, contexte et tâches complexes dans une infrastructure dédiée, avec des performances très dépendantes de l’architecture.
192–512 Go de mémoire unifiée ou serveur multi-GPU	Modèles de plus de 100B et grands MoE quantifiés	Une limite technique de station de travail, pas un point de départ pour concevoir un processus d’entreprise.

Des machines compactes dotées de 128 Go de mémoire unifiée, comme NVIDIA DGX Spark ou les systèmes à base de Ryzen AI Max+ 395, chargent des modèles bien plus grands. NVIDIA annonce jusqu’à 200B paramètres et AMD a montré des modèles de 128B. C’est une démonstration de capacité mémoire, pas une promesse d’expérience interactive : charger un modèle de 100B et vouloir l’utiliser toute la journée restent deux problèmes différents.

La nouvelle gamme Apple aide aussi à séparer capacité et vitesse. Le Mac mini M6 offre jusqu’à 32 Go et 170 Go/s ; le M5 Pro dans le même format atteint 64 Go et 307 Go/s. Le Mac Studio M5 Ultra monte à 512 Go et 1,2 To/s. Une puce plus récente ne supprime pas la limite physique : si les poids ne tiennent pas, ils ne tiennent pas. Apple a annoncé ces machines le 25 août 2026 et commencera à les livrer le 22 septembre ; les chiffres du M5 Ultra restent donc, pour l’instant, des spécifications constructeur et non des retours indépendants d’utilisateurs.

La même capacité demande de moins en moins d’infrastructure

Le nombre de paramètres n’est plus une mesure suffisante de l’intelligence. La qualité des données, l’architecture, le post-entraînement, l’apprentissage par renforcement et la capacité à consacrer davantage de calcul à une requête difficile comptent aussi.

La génération du modèle est tout aussi importante. L’AI Index de Stanford propose une comparaison parlante : en 2022, le plus petit modèle dépassant 60 % sur MMLU comptait 540B paramètres. En 2024, Phi-3 Mini atteignait ce seuil avec 3,8B, soit une réduction d’un facteur 142. MMLU ne représente pas le travail réel d’une entreprise, mais le déplacement de la frontière est significatif.

Une analyse d’Epoch AI estime que les progrès algorithmiques ont divisé par deux, environ tous les huit mois, le calcul nécessaire pour atteindre un niveau donné sur les modèles de langage préentraînés. L’incertitude est importante et une grande part du progrès total vient toujours de davantage de données et de calcul. Cela explique néanmoins pourquoi comparer un modèle 8B actuel à un 8B vieux de deux ans apporte peu.

L’efficacité progresse de plusieurs façons :

• de meilleures données et un meilleur post-entraînement valorisent chaque paramètre ;
• la quantification réduit mémoire et bande passante, avec une perte variable selon le modèle et la tâche ;
• les architectures mixture of experts divisent le modèle en groupes spécialisés et n’en consultent que certains pour chaque token, même si tous doivent rester chargés ;
• la génération spéculative fait proposer plusieurs tokens par un mécanisme léger, puis les fait vérifier par le modèle principal ;
• les programmes qui exécutent les modèles exploitent mieux les GPU, la mémoire unifiée et les NPU, des puces consacrées à l’accélération des opérations d’IA ;
• les modèles spécialisés renoncent à tout savoir faire pour résoudre une fonction précise avec moins de ressources.

Les MoE créent une confusion supplémentaire. gpt-oss-20b possède 21B paramètres au total mais en utilise environ 3,6B pour générer chaque token. Il travaille avec une partie du modèle à la fois, mais doit conserver l’ensemble en mémoire : son fichier de poids quantifié occupe toujours 12,8 Go et OpenAI situe la mémoire minimale autour de 16 Go. Google explique la même chose pour Gemma 4 26B A4B : 4B sont utilisés par token, mais les 26B doivent rester chargés pour choisir rapidement quels groupes interviennent.

Quelles tâches méritent un essai

Les benchmarks, tests standardisés qui permettent de comparer les modèles, aident à éliminer des options et à détecter les progrès. Ils disent moins bien si un système extraira correctement vingt champs de nos rapports, conservera le même format de sortie sur 10 000 documents ou saura s’abstenir lorsqu’une information manque.

Les usages réels dessinent une frontière irrégulière :

Classe approximative de modèle	Tâches raisonnables pour un essai	Risques à mesurer
2B–4B	Classification, reformulation, extraction simple, autocomplétion, commandes locales et tâches très répétitives	Instructions longues, ambiguïté, raisonnement en plusieurs étapes et fidélité sur de longs documents
8B–14B	Résumés, extraction structurée, brouillons, RAG, questions sur la documentation, scripts d’analyse et vision simple	Longs flux d’outils, exceptions rares et décisions exigeant une expertise fiable
20B–32B	Assistant général compétent, code sur des dépôts délimités, vision, outils et analyse en plusieurs étapes	Agents prolongés, vitesse sur matériel modeste et fiabilité des meilleurs systèmes hébergés
70B ou plus	Davantage de robustesse sur des tâches ouvertes et complexes	Coût, latence, exploitation et toujours la possibilité d’erreurs convaincantes

Ces bandes se chevauchent. Un 4B spécialisé peut battre un 27B généraliste sur une classification. Un grand modèle mal quantifié, utilisant le mauvais template ou trop peu de contexte peut être moins bon qu’un petit modèle bien servi.

Les modèles actuels permettent d’ancrer ces fourchettes, pas de contourner l’évaluation.

Gemma 4 12B demande, selon Google, environ 6,7 Go pour les poids Q4 avant contexte et runtime. Il accepte texte, image et audio, et Google montre l’analyse locale de fichiers via des scripts Python sur une machine avec 16 Go. Cela prouve qu’un prototype multimodal tient sur du matériel courant ; pas qu’il respectera notre schéma, nos outils et nos exceptions avec la fiabilité requise.

gpt-oss-20b tient dans environ 16 Go, ne traite que le texte et cible le raisonnement, les sorties structurées et les outils. Son architecture MoE le rend relativement léger en calcul. Il peut convenir à des processus contrôlés, mais il lui faut une intégration qui implémente les outils : télécharger les poids n’ajoute ni recherche, ni exécution de code, ni accès aux fichiers.

Qwen 3.8 27B constitue une référence utile pour la classe 20B–32B. Multimodal et sous licence Apache 2.0, il tient, quantifié à environ 17 Go, sur un GPU de 24 Go ou une machine avec assez de mémoire unifiée. Dans les essais de Willison, il a inspecté un dépôt, construit et testé un utilitaire, localisé des objets dans des images et piloté un agent de code, à 15–30 tokens par seconde —une mesure de la vitesse d’apparition de la réponse, pas de son intelligence. Ces résultats montrent une capacité réelle ; la fiabilité du processus doit encore être mesurée sur nos cas.

DeepSeek V4 Flash illustre l’extrême opposé : une démonstration technique qui dépend d’un matériel, d’une quantification et d’un runtime très précis. C’est un MoE de 284B paramètres au total, environ 13B actifs par token, avec une fenêtre de contexte annoncée d’un million de tokens. Une quantification MLX expérimentale à 2,44 bits occupe 92,8 Go et a atteint environ 32 à 36 tokens par seconde avec un contexte court sur un MacBook Pro M5 Max de 128 Go, mais avec une perte sensible face au modèle hébergé. Les versions proches de quatre bits pèsent environ 150 à 170 Go. Il ne s’agit donc pas d’un modèle local par défaut, mais d’un cas qui montre jusqu’où une station de travail peut aller aujourd’hui.

Ces deux exemples représentent des décisions différentes que l’expression « IA locale » tend à confondre.

Les retours de la communauté sont tout aussi instructifs. Certains décrivent des flux de dizaines d’appels d’outils sur une RTX 3090. D’autres le placent plus près d’un bon modèle hébergé de milieu de gamme que des systèmes de pointe et trouvent des erreurs importantes dans son code. Cette variabilité vient précisément des tâches, prompts, quantifications, runtimes et outils différents que notre propre évaluation doit fixer.

Le seul test décisif pour une entreprise reste une batterie interne de cas réels, y compris les cas rares et les erreurs coûteuses.

Exemple : analyser des rapports médicaux sans les sortir de l’organisation

Imaginons que l’objectif ne soit pas de diagnostiquer, mais de convertir des rapports hétérogènes en champs révisables : date, spécialité, médicaments, examens et antécédents mentionnés.

Un prototype peut consister à déposer un PDF dans une application locale et à demander un résumé. Un système opérationnel doit séparer les responsabilités. D’abord, un OCR transforme en texte les pages qui ne contiennent qu’une image ; ensuite, le modèle renvoie les champs en JSON, un format structuré que le reste du logiciel peut lire et valider :

document
   ↓
OCR et extraction de texte locaux
   ↓
modèle local → JSON + extraits justifiant chaque champ
   ↓
validations déterministes
   ↓
révision humaine des erreurs et cas incertains
   ↓
système de référence de l’organisation

Le système doit autoriser le modèle à renvoyer null lorsqu’une valeur est absente et exiger l’extrait source. Dates, codes et formats sont ensuite validés par des règles conventionnelles qui produisent toujours le même résultat à partir de la même donnée. Les cas douteux sont dirigés vers une révision à partir de contrôles externes, pas de l’assurance avec laquelle le modèle formule sa réponse. Un échantillon représentatif permet de mesurer la précision et surtout les faux négatifs : des informations présentes dans le rapport que le système n’a pas détectées.

Un modèle 8B ou 12B peut suffire si le schéma est stable et les documents prévisibles. Passer à 27B peut améliorer les instructions complexes et les exceptions, au prix de la vitesse et de la concurrence. Dimensionner l’infrastructure avant de connaître la tolérance à l’erreur inverse le bon ordre : définir d’abord l’erreur acceptable, puis tester le plus petit modèle qui la respecte.

L’exemple montre aussi que la confidentialité ne dépend pas seulement du LLM. Il faut vérifier l’OCR, le stockage temporaire, les logs, l’interface, les sauvegardes et la destination du résultat.

L’exécution locale réduit une exposition, sans créer d’exception juridique

Si les données ne quittent pas l’infrastructure contrôlée, un risque majeur diminue : leur remise à un tiers. La CNIL recommande d’envisager des solutions locales, sécurisées et spécialisées lorsque des données personnelles ou des documents sensibles sont introduits. Elle ne dit pas que l’installation d’un modèle règle la conformité.

Traiter des données personnelles reste un traitement, même sans Internet. L’organisation a toujours besoin d’une finalité, d’une base juridique, de minimisation, de durées de conservation, de contrôles d’accès, de sécurité et de mécanismes d’exercice des droits. Les données de santé relèvent aussi des catégories particulières de l’article 9 du RGPD. Selon l’échelle, le risque et l’usage, une analyse d’impact peut être nécessaire.

Il faut séparer trois couches juridiques :

1. La licence du modèle. Des poids téléchargeables ne sont pas sans conditions. Qwen 3.8 et Gemma 4 utilisent Apache 2.0 ; gpt-oss combine Apache 2.0 et sa politique d’utilisation. D’autres modèles imposent des licences communautaires, limites de redistribution ou usages interdits. Une quantification tierce doit conserver et documenter la bonne licence.
2. La protection des données d’entrée. Le RGPD s’applique à la finalité et au traitement, pas au pays de fabrication du GPU. Les historiques, les embeddings —représentations numériques des documents utilisées pour les rechercher— et les journaux d’instructions peuvent eux aussi contenir des données personnelles.
3. La réglementation du système et de son usage. Le règlement sur l’IA classe selon la finalité prévue. Résumer des documents pour assister une personne n’est pas recommander un traitement ni devenir un logiciel médical. Un dispositif médical, un composant de sécurité ou un système participant à certaines décisions peut relever d’obligations de haut risque et de règles sectorielles.

L’exception prévue pour certains logiciels libres n’est pas non plus une autorisation générale. Elle ne couvre pas de la même façon les systèmes interdits, à haut risque ou soumis à transparence.

Dans un cas médical, professionnel, financier ou juridique, la revue doit porter sur tout le système et sa finalité. La question n’est pas seulement « quelle licence utilise Qwen ? », mais « quelle décision prend notre processus, avec quelles données et qui en répond ? ».

Des poids téléchargés ne sont pas un système de production

La facilité d’ouverture d’un chat peut masquer le travail qui suit.

Une entreprise peut avoir besoin d’authentification, de droits par utilisateur, de chiffrement, d’isolation réseau, de gestion des secrets, de files, de limites d’usage, de traces auditables, de mises à jour, de tests de régression et d’un retour arrière. Si plusieurs personnes partagent une machine, il faut aussi dimensionner la concurrence : une station performante pour une conversation peut se dégrader avec dix.

Les modèles à poids ouverts arrivent généralement avec moins de produit autour d’eux. ChatGPT n’est pas seulement un fichier de poids : il inclut recherche, outils, filtres, environnement d’exécution, gestion du contexte, infrastructure et mises à jour. En local, quelqu’un doit choisir, construire et maintenir ces pièces.

Ce contrôle fait partie de la valeur. On peut figer une version, interdire les sorties réseau, observer chaque appel et retirer les capacités inutiles. Mais le coût passe du prix par token au matériel, à l’électricité, à l’intégration, à la sécurité et à l’exploitation.

Quand cela s’intègre dans l’architecture

L’inférence locale a généralement du sens lorsque plusieurs conditions sont réunies :

• les données sont sensibles ou soumises à des exigences strictes de résidence et de contrôle ;
• la tâche est bien définie et évaluable avec des exemples réels ;
• un modèle local atteint la qualité nécessaire, même s’il n’est pas le meilleur modèle disponible ;
• le volume est stable et suffisant pour utiliser le matériel ;
• le mode hors ligne, la latence réseau réduite ou le fait de figer une version apporte de la valeur ;
• l’organisation peut exploiter le système et gérer ses mises à jour.

Cela a moins de sens pour un usage sporadique, lorsqu’il faut toujours la capacité maximale, que les connaissances les plus récentes sont essentielles ou qu’aucune équipe ne peut maintenir l’infrastructure. Une API professionnelle correctement contractualisée peut être plus sûre qu’un serveur local improvisé. L’emplacement physique ne remplace pas une bonne architecture.

De nombreux cas adopteront un modèle hybride. Un petit modèle peut classer, rédiger ou supprimer les informations identifiantes en local. Les cas difficiles passent à un modèle plus grand dans un cloud privé ou, lorsque c’est juridiquement possible, à un service externe. La recherche documentaire reste locale et seul le nécessaire est escaladé.

Ce n’est pas un choix idéologique entre cloud et souveraineté, mais une décision d’architecture fondée sur le risque, la qualité, la latence et le coût total.

Ce qui change réellement

La tendance principale n’est pas qu’un portable exécutera le meilleur modèle au monde. Les modèles de pointe continueront eux aussi à grandir, à consommer davantage de calcul pendant la réponse et à s’intégrer à des systèmes impossibles à reproduire sur un portable.

L’essentiel est que le niveau de capacité jugé suffisant par une entreprise tient chaque année dans un modèle plus petit.

Nous verrons davantage de modèles conçus dès l’origine pour les appareils : peu de paramètres actifs, quantification intégrée à l’entraînement, mémoires de contexte réduites et prédiction de plusieurs tokens à la fois. Les fabricants augmenteront mémoire partagée et bande passante. Les programmes d’inférence exploiteront mieux GPU et NPU sans que chaque projet doive développer des optimisations propres à son matériel.

Nous verrons aussi moins de chats locaux génériques et davantage de fonctions invisibles dans les produits : classer un incident, extraire une facture, chercher dans la documentation, préparer une réponse ou transcrire une réunion. Un petit modèle qui résout une tâche de façon prévisible peut valoir davantage qu’un assistant général impressionnant en démonstration.

Pour les entreprises, l’effet le plus intéressant sera architectural. Une partie de l’inférence se rapprochera des données et deviendra une couche de l’application. Les grands modèles serviront d’escalade pour les exceptions, tout comme nous n’envoyons pas aujourd’hui tous les traitements vers la même base ou le même service.

L’inférence locale ne supprime pas les problèmes difficiles de l’IA. Elle change celui qui apparaît en premier. Il n’est plus nécessaire de commencer par demander si une machine peut exécuter le modèle. Nous pouvons partir de la question qui aurait toujours dû précéder les autres :

quelle partie précise du processus mérite d’être confiée à ce modèle, et comment saurons-nous quand il se trompe ?

Sources

• Stanford HAI : Technical Performance, AI Index Report 2025
• Epoch AI : Algorithmic progress in language models
• Qwen : fiche et poids officiels de Qwen 3.8 27B
• Simon Willison : essais pratiques avec Qwen 3.8 27B
• LocalLLaMA : Qwen 3.8 27B en programmation réelle
• LocalLLM : modèles utilisés comme assistants quotidiens
• Google : besoins en mémoire de Gemma 4
• Google Developers : Gemma 4 12B sur portable
• OpenAI : présentation de gpt-oss
• OpenAI : model card de gpt-oss
• llama.cpp : inférence et quantification sur matériel grand public
• NVIDIA : spécifications de DGX Spark
• AMD : grands modèles en local avec Ryzen AI Max+ 395
• Apple : Mac mini avec M6 et M5 Pro
• Apple : Mac Studio avec M5 Max et M5 Ultra
• DeepSeek : fiche et poids officiels de DeepSeek V4 Flash
• MLX Community : quantification à 2,44 bits et essais sur M5 Max
• CNIL : questions-réponses sur le déploiement de l’IA générative
• Comité européen de la protection des données : avis 28/2024
• Commission européenne : comprendre le règlement sur l’IA
• EUR-Lex : règlement général sur la protection des données