LLM parameters : comprendre les poids et régler les réponses

Un grand modèle de langage (LLM) de 70B possède environ 70 milliards de paramètres appris. Régler la température sur 0.2 modifie la façon dont une API compatible échantillonne sa réponse, pas le nombre de poids du modèle. L’expression « LLM parameters » recouvre donc deux décisions distinctes : quel modèle utiliser et comment lui demander de produire une réponse. Choisissez d’abord le modèle adapté à la tâche, puis configurez uniquement les réglages que son API et sa version prennent effectivement en charge.

Vérifié à partir de la documentation en ligne des fournisseurs le 25 octobre 2026. Cette distinction est devenue essentielle : certaines API rejettent désormais les réglages d’échantillonnage, tandis que d’autres les acceptent sans en tenir compte. Copier une configuration toute faite peut donc faire échouer une requête ou ne rien changer au résultat.

LLM parameters : deux notions à distinguer

Les paramètres du modèle appartiennent au modèle entraîné. Les paramètres de génération appartiennent à la requête que vous lui envoyez. Modifier les seconds ne réentraîne pas les premiers.

Prenons l’image d’un bâtiment. Sa structure porteuse détermine ce qu’il peut supporter ; des brise-soleil orientables permettent d’adapter l’usage des espaces. Orienter une lame n’ajoute pas un étage. De la même façon, changer la température ne transforme pas un petit modèle en grand modèle.

Que désigne le mot « paramètres » pour un LLM ?

Lorsqu’on parle de la taille d’un modèle, les paramètres sont des valeurs numériques apprises, principalement des poids, qui déterminent ses calculs. L’entraînement ajuste ces valeurs à partir des données. Dans les échanges autour des API, le même mot désigne aussi les réglages qui influencent la génération des réponses. L’explication d’IBM distingue bien les valeurs apprises de la configuration externe.

Un fournisseur qui annonce « notre modèle a plus de paramètres » parle du modèle. Un développeur qui propose de « modifier les paramètres pour extraire les données des factures » pense probablement aux réglages de la requête. Faites préciser le sens avant d’y voir une promesse de performance.

À quoi correspond un paramètre dans le modèle ?

Un paramètre appris est un nombre utilisé dans le réseau. Il peut s’agir, par exemple, d’un poids qui module la contribution d’un signal interne à un autre. Ce n’est ni un fait soigneusement étiqueté, ni un document, ni un mot rangé dans un tiroir individuel.

Il existe aussi une catégorie distincte : les hyperparamètres d’entraînement, comme le taux d’apprentissage, qui déterminent le déroulement de l’entraînement. Une application métier qui appelle un modèle existant ne contrôle généralement ni ces réglages ni les poids appris.

Les tokens sont encore autre chose. Ce sont les unités dans lesquelles sont découpées les entrées et les sorties, souvent des fragments de mots. Un prompt plus long ne donne pas davantage de paramètres au modèle. Le guide des tokens en IA explique cette unité ; le guide du prompt système montre comment les instructions orientent le comportement sans modifier les poids appris.

Première partie : le nombre de paramètres renseigne sur la taille du modèle

Le nombre de paramètres aide à estimer les besoins en stockage et en calcul, mais ne suffit pas à choisir le meilleur modèle pour une tâche métier. C’est un point de départ pour dimensionner l’infrastructure. La décision doit ensuite reposer sur une évaluation de la tâche réelle.

Que signifient les milliards de paramètres d’un LLM ?

Le « B » désigne un milliard de valeurs apprises. Un modèle présenté comme un 70B compte environ 70 milliards de paramètres ; le « T » désigne mille milliards. Les appellations publiées peuvent être arrondies : pour estimer précisément les besoins d’un déploiement, il faut partir du checkpoint réel et de son format de stockage.

Deux modèles ayant le même nombre de paramètres peuvent différer par leur architecture, leurs données et méthodes d’entraînement, ou leur spécialisation. Un même modèle peut aussi occuper des volumes de mémoire très différents selon la précision utilisée pour stocker chaque poids.

Pour un acheteur en entreprise, la question utile est celle des critères d’acceptation : le modèle extrait-il le bon total sur une facture, conserve-t-il l’identifiant du client, produit-il un correctif qui passe les vérifications requises ? Un nombre de paramètres plus élevé ne répond à aucune de ces questions.

Calculer la mémoire nécessaire aux poids d’un modèle 70B

Le stockage brut des poids se calcule en multipliant le nombre de paramètres par le nombre d’octets par paramètre. Pour un modèle hypothétique d’exactement 70 milliards de poids, on obtient les calculs suivants. Il ne s’agit pas de mesures prises sur un déploiement.

Ces valeurs sont exprimées en gigaoctets décimaux. Les 140 GB correspondent à environ 130.4 GiB, l’unité binaire affichée par certains outils de mesure de la mémoire. La conversion change l’unité, pas le modèle.

La documentation de Hugging Face explique comment la quantification, qui stocke les poids avec une précision réduite, diminue leur encombrement en mémoire tout en cherchant à préserver la précision des résultats. Notre guide de la quantification des LLM détaille les formats et les compromis.

Des prompts plus longs et des requêtes simultanées modifient également la charge du système qui exécute le modèle. La documentation de l’estimateur de mémoire de Hugging Face distingue explicitement le chargement du modèle de l’inférence, c’est-à-dire la génération des réponses.

Ce que le nombre de paramètres dit du coût et de la qualité

À conditions égales, davantage de poids demandent généralement plus de ressources pour le stockage et l’exécution. Mais « à conditions égales » est une réserve de taille. La précision, l’architecture, le matériel, le traitement par lots et le volume de texte traité influencent le résultat.

En auto-hébergement, le nombre de paramètres aide à présélectionner le matériel. Avec une API hébergée, il ne permet pas de calculer la facture : celle-ci dépend des règles de facturation du fournisseur et de votre charge de travail. Un modèle qui exige de nombreuses nouvelles tentatives ou d’importantes corrections humaines peut aussi s’avérer peu adapté à l’exploitation, malgré son efficacité apparente.

Pour la qualité, considérez la taille comme un indice de capacité, pas comme une note. Un cahier des charges doit demander des résultats sur des entrées représentatives, les cas d’échec et les conditions d’évaluation. Une estimation non publiée du nombre de paramètres d’un modèle fermé ne constitue pas une preuve.

Modèles MoE : distinguer paramètres totaux et paramètres actifs

Les paramètres totaux décrivent l’ensemble du modèle ; les paramètres actifs décrivent le chemin de calcul annoncé pour un token. Ces deux nombres comptent dans un modèle à mélange d’experts, généralement abrégé en MoE.

Un MoE contient des sous-réseaux experts et un routeur qui choisit lesquels traitent chaque token. Ces « experts » sont des composants mathématiques, pas des spécialistes identifiés que l’on pourrait affecter à la comptabilité ou au juridique. Activer seulement une partie du modèle peut réduire les calculs par rapport à une activation complète. Les autres poids doivent néanmoins être stockés quelque part. L’explication de PyTorch sur les MoE décrit le routage et les communications qu’il implique.

L’expression « 104B actifs » correspond à un exemple concret publié par un concepteur : dans son annonce de Kimi K3.1 Pro, Moonshot AI indique 2.8T paramètres au total et 104B actifs. En convertissant le total en 2 800B, on obtient 104 ÷ 2 800, soit environ 3.7% de paramètres actifs. Ce pourcentage résulte de notre calcul à partir des nombres annoncés ; ce n’est ni une mesure d’accélération ni un classement de qualité.

Autre exemple : la fiche du modèle Qwen3-235B-A22B de Qwen annonce 235B paramètres au total et 22B activés. L’illustration laisse les pièces inactives visibles : le besoin de stockage ne disparaît pas parce qu’un token emprunte un autre chemin.

Avant un déploiement, demandez comment l’ensemble du modèle est stocké et réparti, comment les experts sont distribués entre les équipements et quelles sont les performances avec votre nombre réel de requêtes simultanées. Le nombre de paramètres actifs ne spécifie pas les besoins en mémoire du processeur graphique (GPU). Le guide du mélange d’experts approfondit cette question d’infrastructure.

Deuxième partie : les paramètres de génération orientent la réponse

Les réglages de génération modifient la sélection des tokens et l’arrêt de la réponse, dans les limites des capacités du modèle. Une API est l’interface que votre application appelle pour demander une réponse. Ses réglages ne peuvent ni fournir une source manquante, ni lever une ambiguïté dans une consigne, ni garantir une réponse correcte.

Température : concentrer ou élargir les choix

La température modifie la distribution de probabilités utilisée pour sélectionner le token suivant. Une valeur basse favorise davantage les choix les plus probables ; une valeur haute autorise plus de variation. Ce réglage permet d’arbitrer entre des formulations régulières et une plus grande diversité de propositions.

Dans un workflow de traitement des factures, la variation est rarement l’objectif. Pour proposer plusieurs accroches de campagne, elle peut être utile. Mais une température basse ne rend pas vrai un numéro de facture inventé, et une température élevée n’ajoute aucune connaissance.

Même une requête à température nulle ne garantit pas une reproductibilité universelle. Le glossaire d’Anthropic avertit explicitement que des entrées identiques peuvent produire des résultats différents à température zéro. La reproductibilité doit s’évaluer sur l’ensemble du système d’exécution.

Top-p : limiter l’ensemble des candidats

Le top-p, ou échantillonnage par noyau, limite les tokens candidats en fonction de leur probabilité cumulée. Il s’agit d’un seuil de probabilité, pas d’un nombre de candidats ni d’un pourcentage du vocabulaire.

Prenons une distribution illustrative des probabilités du token suivant : 0.60, 0.25, 0.10 et 0.05. Avec un seuil top-p de 0.9, il faut retenir les trois premiers candidats : les deux premiers totalisent 0.85, tandis que les trois premiers atteignent 0.95. Ces nombres servent d’exemple pédagogique ; ils ne proviennent pas d’une sortie de modèle observée.

La température remodèle les probabilités ; le top-p restreint les candidats admissibles. Pour une première configuration métier, ne modifiez qu’un réglage d’échantillonnage à la fois. C’est aussi ce que recommande OpenAI dans sa référence Chat Completions.

Limite de tokens : un plafond, pas une longueur demandée

La limite de tokens de génération plafonne la réponse. Elle ne demande pas au modèle d’utiliser exactement ce nombre de tokens et n’agrandit pas sa fenêtre de contexte, c’est-à-dire sa capacité à prendre en compte la conversation.

Un plafond trop bas peut interrompre un objet JSON, une phrase ou un correctif de code. Un plafond élevé ne rend pas automatiquement la réponse utile. Indiquez la longueur souhaitée dans le prompt, puis laissez assez de marge sous la limite pour obtenir un résultat complet.

Le raisonnement impose une distinction supplémentaire. La référence Responses d’OpenAI précise que le plafond de sortie inclut à la fois les tokens visibles et ceux du raisonnement. De même, la référence Messages d’Anthropic comptabilise les tokens de réflexion dans max_tokens. Ne dimensionnez pas une requête avec raisonnement comme si chaque token autorisé devait apparaître dans la réponse finale.

Séquences d’arrêt : s’arrêter à une frontière précise

Une séquence d’arrêt met fin à la génération lorsqu’une chaîne de caractères désignée apparaît. N’en utilisez une que si l’application dispose d’une frontière fiable, par exemple un marqueur de fin explicite qui ne peut pas légitimement figurer dans le contenu.

Un saut de ligne est un mauvais choix d’arrêt générique pour un rapport de plusieurs lignes. Une accolade fermante est un mauvais choix pour du JSON imbriqué : la première accolade correspondante peut interrompre la réponse trop tôt. Pour une extraction structurée, privilégiez le mécanisme de schéma pris en charge par le fournisseur et validez les champs renvoyés.

Commencer sans séquence d’arrêt personnalisée est généralement raisonnable. Un plafond de tokens de sortie et une validation restent nécessaires.

Pénalités : limiter les répétitions avec discernement

Une pénalité de présence tient compte du fait qu’un token est déjà apparu. Une pénalité de fréquence tient compte de son nombre d’apparitions. Les pénalités positives découragent la réutilisation ; les valeurs négatives peuvent l’encourager, lorsque le point de terminaison les prend en charge.

Une répétition n’est pas toujours un défaut. Un code produit, un nom de client, une clé JSON ou un identifiant de programmation peuvent devoir réapparaître à l’identique. Les pénaliser peut nuire à la tâche.

Pour l’extraction et le code, commencez sans pénalité de répétition. Pour la rédaction, corrigez d’abord toute consigne qui favorise une structure répétitive. Envisagez ensuite seulement une faible pénalité prise en charge, et vérifiez qu’elle améliore le texte sans modifier la terminologie imposée. La référence de génération de Google avertit aussi que des pénalités de fréquence négatives peuvent entraîner des boucles de répétition de tokens.

Plages de valeurs et réglages par défaut : OpenAI, Anthropic et Google

Le point de terminaison, le modèle et la version de l’API déterminent les réglages que vous pouvez envoyer. Un nom de champ commun dans un SDK ne prouve pas que tous les fournisseurs mettent en œuvre le même contrôle.

Le tableau concerne Chat Completions pour OpenAI, Messages API dans sa version 2026-10-21 pour Anthropic et generateContent de Gemini Developer API pour Google. Les réglages de Vertex AI ou de l’API Interactions de Google ne sont pas transposés ici.

NS signifie que la documentation actuelle du champ cité ne précise pas de plage numérique ou de valeur par défaut. Cela ne signifie ni zéro, ni illimité, ni non pris en charge. Lorsqu’il est conseillé ci-dessous d’omettre un réglage, il s’agit d’un conseil de configuration, pas d’une valeur par défaut inventée.

Sources : schéma des requêtes OpenAI, schéma des requêtes Anthropic, migration de version Anthropic, schéma de génération Google, métadonnées des modèles Google et plage du top-p chez Google.

Le tableau général de dépannage de Google indique une plage de température plus étroite que la référence du champ de génération. Utilisez cette référence avec le maxTemperature du modèle choisi ; consultez Model.temperature, Model.topP et Model.outputTokenLimit pour ses valeurs spécifiques. Un exemple de requête ne constitue pas une valeur par défaut documentée.

OpenAI : vérifier d’abord la compatibilité avec le raisonnement

Le guide GPT-6 actuel d’OpenAI demande de retirer temperature et top_p lorsque l’effort de raisonnement n’est pas réglé sur none. GPT-6 Astra et GPT-6.1 Sol ne prennent pas en charge none ; GPT-6 Sol et GPT-6 Luna le prennent en charge. Il s’agit d’une restriction de compatibilité, pas de la documentation d’une température numérique fixe.

Le point de terminaison compte également. Responses utilise max_output_tokens, dont le schéma actuel fixe le minimum à 16 ; aucune valeur numérique par défaut ni aucun maximum universel n’y sont précisés. Son schéma de création n’expose pas les champs stop, presence_penalty ou frequency_penalty de Chat Completions. Dans Chat Completions, la référence indique expressément que stop n’est pas pris en charge par o3 et o4-mini, et déprécie max_tokens au profit de max_completion_tokens.

En pratique, construisez la requête pour le point de terminaison choisi, puis appliquez les règles de compatibilité du modèle. Ne recopiez pas tout le tableau dans une seule requête.

Anthropic : une version d’API peut supprimer un réglage

Le guide de migration du 21 octobre d’Anthropic indique qu’envoyer temperature, top_p ou top_k avec la version d’API 2026-10-21 provoque une erreur 400, même avec une valeur par défaut. Lorsque ces champs sont omis, le comportement inclut une température de 1.0.

Utiliser une ancienne version d’API ne rétablit pas automatiquement cette souplesse sur tous les modèles. La documentation d’Anthropic sur la réflexion précise que certains modèles, dont Claude Sonnet 5.5, rejettent les valeurs d’échantillonnage autres que celles par défaut, que la réflexion soit activée ou non. Elle indique pour ces modèles un top-p par défaut de 0.99 et précise explicitement que 1 est rejeté. Une ancienne plage générique ne peut pas primer sur cette règle propre au modèle.

Pour générer une réponse, fournissez un budget max_tokens positif, dans la limite du modèle. Le minimum documenté de zéro sert à préchauffer le cache sans produire de réponse ; ce n’est pas un réglage utile pour l’extraction.

Google : un réglage accepté peut rester sans effet

Le guide de migration de Google pour Gemini 3.6 Flash et 3.5 Flash-Lite indique que ces modèles ignorent les réglages dépréciés de température, de top-p et de top-k. Il demande aux développeurs de les retirer et précise que les générations de modèles suivantes les rejetteront avec une erreur 400.

Le problème diffère ici d’une requête rejetée : l’application peut sembler accepter un changement de température alors que le modèle se comporte exactement comme avant. Consultez la documentation du modèle choisi avant de considérer une réponse réussie comme la preuve qu’un réglage a été appliqué.

Quels réglages choisir pour les tâches métier ?

Partez du comportement pris en charge par le fournisseur et d’une définition mesurable de la réussite. Les valeurs ci-dessous sont nos suggestions de départ pour les points de terminaison qui autorisent ces réglages. Ce ne sont ni les valeurs par défaut des fournisseurs, ni des optimums mesurés, ni des configurations transposables partout. Les règles de compatibilité présentées plus haut priment.

Extraction : préserver les valeurs exactes

Pour extraire les champs d’une facture, classer des tickets d’assistance ou relever les métadonnées d’un contrat, essayez une température de 0 ou 0.2 uniquement si elle est prise en charge. Ne modifiez pas le top-p. Omettez les arrêts personnalisés et les pénalités de répétition ; sur un modèle OpenAI Chat Completions compatible, fixer explicitement les deux pénalités à 0 permet aussi de définir une configuration de référence sans pénalité.

Pour les requêtes Anthropic actuelles et les modèles Gemini Flash cités, omettez les réglages d’échantillonnage. Définissez explicitement les champs, les catégories autorisées et des exemples de données manquantes, puis utilisez la fonction de sortie structurée prise en charge par le fournisseur. Validez le résultat indépendamment de sa mise en forme.

Pour une courte fiche extraite, un plafond initial de 1 000 tokens de sortie peut servir de premier essai sur une requête compatible sans raisonnement. Ce n’est pas une limite universelle : examinez les troncatures et l’usage réel, puis prévoyez séparément le budget de raisonnement lorsqu’il s’applique. Demandez un marqueur de valeur manquante plutôt qu’un numéro de facture inventé.

Critère d’acceptation : tous les champs requis sont présents, les valeurs correspondent à la source et les informations absentes le restent. Réussir la validation JSON ne suffit pas.

Rédaction : varier les formulations sans altérer les faits

Pour un e-mail de prospection ou une description de produit, commencez par le comportement par défaut pris en charge par le modèle. Sur un point de terminaison réglable, comparez-le avec une température de 0.7, sans changer le top-p. Précisez dans le prompt le public, la longueur, le ton, les faits à inclure et les affirmations interdites.

N’appliquez pas de pénalités au départ. Si un modèle OpenAI Chat Completions compatible réutilise régulièrement des expressions indésirables, une pénalité de fréquence de 0.2 constitue un essai modéré dans sa plage documentée. Ne la conservez que si la relecture montre une amélioration ; les noms de produits imposés doivent rester intacts.

Pour les modèles qui suppriment les réglages d’échantillonnage, demandez explicitement des approches différentes, par exemple une version factuelle et concise et une version narrative. Évaluez les différences dans les textes obtenus.

Critère d’acceptation : une variation utile, sans nouvelles affirmations factuelles. Un texte plus surprenant n’est pas nécessairement un meilleur texte commercial.

Code : prévoir une réponse complète et vérifier le comportement

Pour un correctif ciblé sur un point de terminaison réglable, une température de 0 ou 0.2 offre un point de comparaison raisonnable. Avec un modèle de raisonnement, respectez sa configuration prise en charge et omettez les champs d’échantillonnage incompatibles. Écartez les pénalités de répétition et les arrêts personnalisés, sauf si un protocole testé les exige.

Fournissez le code pertinent, les contraintes et le comportement attendu. Prévoyez assez de tokens de sortie pour obtenir un correctif complet. Si la réponse atteint son plafond, considérez le résultat comme incomplet au lieu de supposer que la partie visible peut être appliquée sans risque.

Critère d’acceptation : le correctif respecte la spécification et passe les vérifications adaptées. Les identifiants répétés sont normaux dans du code, et une réponse plausible ne prouve pas qu’elle s’exécute correctement.

Ce que ni le nombre de paramètres ni les réglages ne garantissent

La promesse excessive consiste à faire passer un seul nombre pour une évaluation. Ni un nombre de poids ni une température ne peuvent la remplacer.

Un modèle plus grand n’est pas automatiquement meilleur pour votre workflow spécialisé. Un nombre réduit de paramètres actifs dans un MoE ne signifie pas que l’ensemble du modèle tient dans la mémoire correspondante. Une température basse ne garantit pas la vérité. Un plafond de sortie élevé ne garantit pas un raisonnement complet, et un appel d’API réussi ne prouve pas que tous les réglages envoyés ont été appliqués.

Les éléments utiles sont une entrée représentative, une condition de réussite définie et un résultat examiné. Avant un achat, demandez au fournisseur de démontrer le workflow avec la configuration que vous utiliserez réellement. Pour un développement, consignez le modèle, le point de terminaison, la version de l’API, le prompt et les réglages afin de comprendre ce qui a changé lorsque le comportement évolue.

Acheteurs, responsables opérationnels et développeurs : les prochaines étapes

Les acheteurs doivent comparer les résultats, les responsables opérationnels définir l’échec et les développeurs retirer les réglages non pris en charge. Ces responsabilités se rejoignent autour d’un même petit jeu d’évaluation.

Un acheteur peut choisir un service hébergé sans connaître son nombre de paramètres si le service démontre qu’il obtient les résultats attendus. Pour un auto-hébergement, attendez d’avoir dimensionné le checkpoint complet, la précision et la charge de travail avant d’acheter le matériel. Un responsable opérationnel dont le workflow fonctionne n’a pas besoin de le remplacer parce qu’un autre modèle annonce un nombre plus élevé.

Les développeurs qui changent de modèle ou de version d’API doivent vérifier la compatibilité dès maintenant. Les responsables opérationnels qui utilisent une interface gérée sans réglages de génération accessibles sont peu concernés par la syntaxe des champs de requête, mais doivent toujours valider les réponses.

1. 1

   Réunir les cas qui doivent réussir

   Lundi prochain, rassemblez 20 exemples représentatifs d’un même workflow, avec des entrées incomplètes, ambiguës et particulièrement longues. Écrivez le résultat attendu ou les critères de relecture avant de comparer les modèles.

2. 2

   Expliciter la configuration de la requête

   Consignez le point de terminaison, le modèle et la version de l’API. Vérifiez les réglages pris en charge, retirez les autres et choisissez un budget de sortie permettant un résultat complet. Conservez dans le prompt la terminologie obligatoire et le comportement attendu en cas de données manquantes.

3. 3

   Modifier un seul réglage et évaluer le résultat

   Comparez la configuration de référence à une variante qui ne modifie qu’un réglage pris en charge. Pour l’extraction, vérifiez la fidélité à la source ; pour la rédaction, l’exactitude factuelle et l’utilité ; pour le code, le comportement et les contrôles. Gardez la configuration la plus simple, sauf si le changement apporte une amélioration suffisante pour le justifier.

Questions fréquentes

Comment fonctionne la température d’un LLM ?

Elle modifie la concentration de la distribution de probabilités du token suivant. Les valeurs basses favorisent les choix probables ; les valeurs hautes autorisent plus de diversité. Ce réglage agit sur l’échantillonnage, pas sur les poids appris, et certaines API actuelles le rejettent ou l’ignorent.

Quelle est la taille approximative d’un modèle 70B ?

Pour exactement 70 milliards de poids, le stockage brut représente environ 140 GB en 16 bits, 70 GB en 8 bits ou, dans le cas idéal, 35 GB en 4 bits. Ces valeurs décimales n’incluent ni la mémoire nécessaire à l’exécution ni le surcoût de la quantification. Les besoins de déploiement dépendent du checkpoint réel et de la charge de travail.

Quels sont les quatre types de paramètres ?

Il n’existe pas de classification universelle en quatre types pour les LLM. Il est utile de distinguer les paramètres appris du modèle, les réglages d’architecture, les réglages d’entraînement et les réglages de génération. Ces catégories aident à comprendre le système ; elles ne signifient pas que chaque API dispose de quatre réglages.

Quelle différence entre GPT et LLM ?

LLM signifie grand modèle de langage : c’est la catégorie générale. GPT signifie transformeur génératif préentraîné et désigne une famille de modèles ainsi qu’une approche au sein de cette catégorie. D’autres familles de modèles de langage sont également des LLM.

Quels sont les quatre types de LLM ?

Il n’existe pas de liste standard unique de quatre types. La distinction entre modèle dense et mélange d’experts décrit l’architecture ; celle entre poids ouverts et poids fermés décrit leur disponibilité. Elles répondent à des questions différentes et ne doivent pas être combinées en un prétendu classement de qualité.

ChatGPT est-il un LLM ou une IA ?

ChatGPT est une application d’IA qui utilise des modèles. Il faut distinguer l’application, le modèle sélectionné à l’intérieur et les réglages d’API accessibles aux développeurs : ce sont des couches différentes.

Quelles IA ne sont pas des LLM ?

L’IA ne se limite pas aux modèles de langage. Un classificateur de fraude ou un système de vision par ordinateur peut utiliser des méthodes d’apprentissage automatique sans recourir à un LLM. Le nombre de paramètres n’est pas non plus une notion exclusive aux modèles de langage.

Quel LLM est le plus intelligent ?

Le nombre de paramètres ne permet pas d’apporter une réponse valable pour toutes les tâches. Comparez les modèles sur des exemples représentatifs du travail à accomplir, avec les mêmes critères d’acceptation et une configuration documentée. Un résultat sur un benchmark ne tranche pas toutes les tâches métier.

À quelle branche de l’IA appartiennent les LLM ?

Les LLM sont des modèles d’apprentissage profond utilisés pour le traitement et la génération du langage. Leurs paramètres appris appartiennent au modèle ; la température et les réglages de requête comparables relèvent de la façon dont l’application l’utilise.

Pour des explications concrètes sur les systèmes d’IA et les choix qui les façonnent, abonnez-vous à la newsletter.