IA locale contre ChatGPT : où en sommes-nous vraiment ?

L’IA locale offre une option pratique pour les tâches délimitées avec des contrôles clairs. Pour remplacer le travail confié à ChatGPT ou Claude, trois éléments doivent s’accorder : les capacités du modèle, la mémoire utilisable et un agent capable d’inspecter et de vérifier sa sortie.

Un modèle adapté à votre station de travail a encore besoin d’outils appropriés et d’une vitesse suffisante pour répéter les essais. Cet article sépare les résultats de benchmarks, les estimations de mémoire et les preuves de tâches terminées afin que vous évaluiez chaque élément séparément.

Points essentiels #

• Capacité : les scores de référence décrivent des réglages d’évaluation précis, pas votre build local quantifié.
• Mémoire : prévoyez ensemble les poids, le cache de contexte et la surcharge d’exécution.
• Vitesse : rejouer une conversation d’agent mesure le service, pas la justesse.
• Vérification : un agent a besoin de contrôles adaptés au résultat demandé.
• Choix : comparez les tâches répétées, le temps de réparation et le coût total avant d’acheter du matériel.

Lire les scores dans leur contexte #

L’Artificial Analysis Intelligence Index agrège plusieurs évaluations en un score de référence. Le classement des modèles et les résultats du matériel local présentent les entrées suivantes, vérifiées le 6 octobre 2026.

Les points d’index ne sont ni des pourcentages d’intelligence ni des taux de réussite. Un écart de 13 points entre GLM et Claude n’établit pas une différence de 13 % dans vos résultats de codage. Les réglages de raisonnement comptent aussi pour comparer un même modèle.

La méthodologie d’évaluation publiée décrit le protocole. Certaines évaluations incluent des outils et une infrastructure d’agent. Considérez le score comme un résultat obtenu dans ces conditions. Ne le transférez pas directement à une copie locale compressée exécutée par une autre application.

ChatGPT et Claude sont des produits, alors que ce tableau compare des modèles sous-jacents sélectionnés. Votre abonnement, le modèle choisi, les outils disponibles et le contexte de la tâche ajoutent d’autres différences. Commencez par une tâche répétée, puis testez l’ensemble du système.

Prévoir toute la requête #

La compatibilité mémoire commence par trois allocations. Les poids stockent les paramètres appris. Le cache clé-valeur, ou cache KV, conserve les données d’attention utilisées pendant l’inférence. Les tampons d’exécution et les autres logiciels consomment l’espace restant.

Required memory = resident weights + context cache + runtime allowance
Available memory = physical capacity - operating system and application reserve

La quantification réduit la précision de stockage des poids. Une précision plus faible réduit les besoins mémoire, avec une qualité qui dépend du modèle et du build quantifié. La précision du cache est un réglage séparé. Un fichier de poids Q4 ne prouve pas que le cache utilise quatre bits.

Pour un exemple approximatif limité aux poids, 27 milliards de paramètres à 16 bits exigent environ 50,3 GiB. Huit bits donnent environ 25,1 GiB, et quatre bits environ 12,6 GiB. Les tailles de fichiers publiées incluent aussi les métadonnées, le conditionnement et la précision mixte. Utilisez donc les fichiers exacts pour planifier le déploiement.

La fiche du modèle Qwen3.8-27B et la fiche du modèle GLM-5.3 décrivent des architectures différentes. Un modèle mixture-of-experts n’active qu’une partie de ses paramètres pour chaque jeton, mais les autres poids exigent toujours un stockage. Le déport change l’emplacement et la latence, sans supprimer ces poids.

Commencer par les fichiers publiés #

La taille du téléchargement offre un point de départ plus concret que le nombre de paramètres. Les builds Qwen et GLM publiés par Unsloth montrent combien le besoin de stockage change avec la quantification choisie.

Sources des fichiers : Qwen Q4_0 , Qwen Q8_0 , fragments GLM UD-Q4_K_XL et fragments GLM UD-IQ2_M . Les valeurs sont des listes arrondies vérifiées le 6 octobre 2026. Les conversions en GiB divisent les octets décimaux par 2³⁰.

Ces tailles concernent les fichiers de poids, pas la mémoire résidente totale. Le chargement, les caches, les tampons temporaires et les composants supplémentaires du modèle affectent le processus en cours. Ne comparez pas directement un téléchargement de 29 Go à une allocation de 30 GiB sans convertir les unités.

Le contexte change l’adéquation #

Le cache d’attention de Qwen fournit un exemple calculé. Sa configuration publiée indique 64 couches, une attention complète toutes les quatre couches, quatre têtes clé-valeur et une dimension de tête de 256.

Full-attention KV bytes per token:
16 layers × 4 KV heads × 256 dimensions × 2 (K and V) × 2 bytes
= 65,536 bytes

8,192 tokens  = 0.5 GiB
32,768 tokens = 2.0 GiB

Ce composant de cache calculé suppose des clés et valeurs 16 bits pour une séquence. Il exclut l’état d’attention linéaire, les tampons d’exécution, la surcharge de l’allocateur et les composants optionnels de vision ou de décodage spéculatif. Ces allocations exigent encore une réserve.

Pour un budget indicatif, ajoutez 3 à 5 GiB pour ces allocations restantes aux tailles de poids arrondies. Cette marge est une hypothèse à remplacer par des mesures de votre runtime.

Une allocation utilisable de 30 GiB laisse une marge importante pour l’exemple Q4, alors que les scénarios Q8 la dépassent selon ces hypothèses. Une réserve mesurée plus faible change la limite. Un prompt court réussi ne prouve donc pas une capacité suffisante pour une longue session de codage.

Les requêtes simultanées ajoutent une autre dimension. Ollama documente la croissance de la mémoire de contexte avec les requêtes parallèles, ainsi que des contrôles séparés de précision du cache. Son cache Q8 utilise environ la moitié de la mémoire du cache F16, tandis que Q4 en utilise environ un quart, avec des compromis de qualité propres au modèle. Consultez la FAQ du runtime Ollama .

Adapter le matériel à l’allocation #

Une RTX 5090 offre 32 Go de mémoire graphique dédiée. Un DGX Spark doté de 128 Go utilise une mémoire partagée. Artificial Analysis documente ces deux configurations dans ses résultats matériels. Une capacité supérieure permet de plus grandes allocations, mais elle ne prouve pas la vitesse de service.

GLM UD-Q4_K_XL dépasse les trois capacités avant l’ajout d’un cache. L’ensemble de poids IQ2 d’environ 222,6 GiB dépasse aussi un système de 128 Go. Sur un Mac de 256 Go, sa faisabilité dépend de l’allocation réellement accessible au GPU et de la surcharge restante. Les spécifications Apple établissent des options matérielles, pas une allocation d’inférence garantie.

Un budget utilisable hypothétique de 240 GiB laisse environ 17,4 GiB après ces poids IQ2. Un budget de 192 GiB échoue avec les poids seuls. Aucun des deux budgets ne prouve une valeur par défaut du système, un cache compressé pris en charge, un débit utile ou une qualité IQ2 acceptable. Exigez une configuration runtime démontrée avant d’acheter pour cette charge.

La vitesse est un résultat séparé #

Le benchmark d’inférence locale d’Artificial Analysis rejoue une charge enregistrée de 168 tours de modèle. Ses résultats pour portables et stations de travail indiquent les temps suivants pour les configurations Qwen3.8 27B testées.

Le résultat RTX prend environ un cinquième du temps du Spark. Les configurations de service comptent, ce qui n’établit pas un ratio matériel universel. Les builds testés diffèrent aussi des exemples de planification GGUF ci-dessus.

Le temps de rejeu exclut l’exécution des outils et impose des longueurs de réponse enregistrées. Il ne note pas la capacité des réponses à résoudre la tâche initiale. Une mesure sur MacBook ne détermine pas non plus les performances d’un Mac Studio.

Donner un retour à l’agent #

Un système d’exécution d’agent fournit des outils, du contexte, une boucle d’action et une vérification. Le modèle écrit ou choisit les actions dans ce système. Pour un export CSV, les capacités utiles incluent la lecture des fichiers du projet, la modification du code, l’exécution des tests et la réception des erreurs produites.

Considérez une tâche d’export indicative, pas une expérience mesurée. L’agent écrit une fonction de téléchargement, mais sa sortie utilise un mauvais format de date. Une vérification visuelle ne voit pas le problème. Un test ouvre le fichier exporté et compare ses dates au format requis. L’agent reçoit l’échec, change le formateur et relance le contrôle.

LangChain rapporte un passage de 52,8 % à 66,5 % sur Terminal Bench 2.0 avec GPT-5.2-Codex constant. Son rapport d’ingénierie des agents décrit les consignes de vérification, le contexte de l’environnement, la détection des modifications répétées et les changements de budget de raisonnement.

Adapter les contrôles au travail #

Un contrôle réussi établit seulement ce qu’il couvre. Un test CSV qui valide les noms de colonnes laisse non testés le format des dates, les guillemets, Unicode et le contrôle d’accès. Définissez le résultat demandé avant de choisir la vérification.

L’étude τ-bench évalue des agents qui interagissent avec des outils, des utilisateurs et des règles métier. Son article de recherche vérifie l’état final de la base de données par rapport aux résultats attendus. Cela montre pourquoi un texte de confirmation fluide ne suffit pas à vérifier une transaction.

Local ne signifie pas hors ligne #

L’inférence locale contrôle l’endroit où le modèle s’exécute. L’application environnante détermine encore où circulent les documents, les requêtes de recherche, les traces et les résultats des outils. Un modèle de codage local relié à une recherche distante ou à des outils cloud reste un système en réseau.

Ollama indique ne pas recevoir les prompts ni les réponses lors d’une exécution locale et documente la désactivation de ses fonctions cloud. Il s’agit d’une déclaration propre au runtime, pas d’une garantie de confidentialité pour chaque agent connecté. Vérifiez le point de terminaison du modèle et chaque intégration dans la documentation du runtime .

Un flux hybride a besoin d’une règle de transfert explicite. Par exemple, gardez l’extraction de documents privés en local, puis envoyez seulement des résultats agrégés approuvés pour l’analyse hébergée. Examinez précisément les données sortantes. Un résumé contient encore des informations sensibles s’il conserve des noms, des détails clients ou des constats confidentiels.

Tester avant d’acheter #

Choisissez une tâche répétée avec une condition de fin claire. Comparez la configuration locale au produit hébergé que vous utilisez, avec ses outils. Donnez les mêmes entrées et critères d’acceptation aux deux systèmes, puis répétez la tâche sur plusieurs exemples représentatifs.

1. Enregistrer la configuration : fichier de modèle exact, quantification, version du backend, limite de contexte et réglage de raisonnement.
2. Définir la réussite : artefact attendu, comportement requis et effets secondaires interdits.
3. Mesurer la fin : durée, contrôles réussis, essais échoués et réparations manuelles.
4. Inclure le coût de possession : matériel, électricité, frais d’API, maintenance et votre temps.
5. Classer les échecs : erreurs de raisonnement, limites mémoire, latence, contexte absent ou vérification absente.

L’inférence locale convient aux tâches dont la qualité et la latence évaluées répondent à vos exigences. Un modèle hébergé reste utile lorsque sa capacité supplémentaire réduit les erreurs ou le travail de revue. Un flux hybride attribue des tâches différentes à chaque système après avoir défini les données autorisées à sortir de la machine.

Compter le coût par résultat accepté #

Le temps de réparation humaine change souvent l’économie. Une réponse locale rapide qui exige dix minutes de correction consomme plus de temps de travail qu’une réponse plus lente qui passe la revue. Comptez les résultats acceptés avec la dépense d’inférence.

Cost per accepted task =
(hardware allocation + electricity + service fees + maintenance + review time)
÷ accepted tasks

Coût de revue indicatif : avec un taux supposé de 30 $ par heure, huit minutes de correction coûtent 4 $ par tâche. Cent tâches de ce type consomment 400 $ de temps de revue. Ces chiffres sont des exemples arithmétiques, pas des taux d’échec mesurés pour un modèle local.

Comparez des résultats équivalents. Incluez les essais rejetés dans le temps et le coût. Pour un matériel possédé, répartissez le prix d’achat sur une période d’utilisation et un volume de tâches réalistes. Pour un service hébergé, incluez l’abonnement ou les frais d’API applicables et le travail de revue restant.

Pour les détails matériels, consultez le guide des modèles locaux, GPU et contextes . Pour les capacités et les prix, lisez la comparaison mémoire DGX Spark . Utilisez vos résultats de tâches pour choisir la configuration minimale répondant à vos exigences de qualité, de vitesse et de données.

Vidéo de référence #

Références #

• AI Mechanics : Local AI vs ChatGPT: How Close Are We Really? .
• Artificial Analysis : résultats des modèles , méthodologie d’évaluation et résultats d’inférence locale .
• Éditeurs de modèles : Qwen3.8-27B et GLM-5.3 .
• Unsloth : builds Qwen GGUF et builds GLM GGUF .
• Ollama : documentation du runtime, de la mémoire et de la confidentialité .
• LangChain : résultats d’ingénierie des agents .
• τ-bench : recherche sur l’évaluation des agents, outils et utilisateurs .