Comment lire une fiche de modèle

Une fiche de modèle est le README.md d’un dépôt de modèle sur Hugging Face, et c’est l’endroit où vous devriez regarder avant de télécharger quoi que ce soit. La plupart des fiches sont longues — cette page vous indique quels champs sont importants pour exécuter le modèle localement et lesquels vous pouvez survoler. Les propres directives de Hugging Face sur ce qu’une fiche doit contenir se trouvent dans la documentation des fiches de modèles du Hub. En pratique, une poignée de champs font la majeure partie du travail lorsque vous décidez si un modèle convient à votre matériel.

​

Nombre de paramètres

Généralement dans le nom du modèle lui-même (7B, 30B) ou indiqué près du haut de la fiche. C’est le principal facteur déterminant les exigences de mémoire — voir Mémoire et délestage pour comprendre comment le nombre de paramètres se traduit par un nombre de VRAM.

​

Architecture : dense vs. mélange d’experts

Vérifiez si la fiche décrit le modèle comme dense ou mélange d’experts (MoE). Un modèle dense exécute chaque paramètre sur chaque jeton. Un modèle MoE — nommé comme 30B-A3B, signifiant 30B de paramètres totaux avec 3B actifs — n’exécute qu’un sous-ensemble de paramètres “experts” par jeton, donc il décode plus rapidement qu’un modèle dense de la même taille totale. Le piège : vous avez toujours besoin de suffisamment de mémoire pour contenir tous les paramètres, pas seulement les actifs, car n’importe quel jeton peut être acheminé vers un expert différent. Recherchez les deux nombres sur la fiche : paramètres totaux (ce dont vous avez besoin pour le stockage) et paramètres actifs (ce qui détermine la vitesse par jeton).

​

Longueur de contexte

Le nombre maximum de jetons que le modèle peut contenir dans une seule conversation, généralement listé comme quelque chose comme “128K de contexte” ou max_position_embeddings dans la configuration. Cela compte double : cela limite ce que vous pouvez envoyer au modèle en une seule fois, et cela définit directement votre plafond de mémoire de cache KV. Voir Cache KV et contexte pour comprendre pourquoi un contexte plus long coûte plus de VRAM.

​

Licence

Vérifiez le champ de licence avant de construire quoi que ce soit sur un modèle — il détermine si vous pouvez utiliser les sorties commercialement, redistribuer des affinages, ou l’exécuter dans un produit du tout. Les licences varient considérablement entre les familles : certaines sont entièrement permissives (Apache 2.0, MIT), d’autres comportent des restrictions d’utilisation ou nécessitent une attribution. C’est une métadonnée que Hugging Face met directement en avant sur la fiche selon sa documentation des fiches de modèles.

​

Fichiers et dépôts : safetensors vs. GGUF

Un seul modèle est souvent publié à travers plusieurs dépôts ou formats de fichier :

• safetensors sont les poids originaux (ou convertis), typiquement à pleine précision (FP16/BF16) ou accompagnés d’autres formats quantifiés. Ce sont ceux que les backends comme vLLM chargent typiquement.
• GGUF est le format que les backends basés sur llama.cpp (y compris Ollama et LM Studio) chargent. Un dépôt GGUF offre généralement plusieurs variantes quantifiées du même modèle en tant que fichiers séparés.

Un nom de fichier comme …Q4_K_M.gguf vous indique trois choses en un coup d’œil : c’est une quantification Q4 (4 bits), de la famille de quantification K, au point de taille/qualité M (moyen) au sein de cette famille. Voir Quantification pour savoir comment lire le reste du schéma de nommage et choisir une variante.

​

Modèle de chat

La plupart des modèles affinés pour les instructions s’attendent à ce que les invites soient enveloppées dans un modèle de chat spécifique (jetons spéciaux marquant les tours système/utilisateur/assistant). Les backends qui servent le modèle — Ollama, llama.cpp, vLLM — appliquent typiquement le bon modèle automatiquement à partir des métadonnées bundled avec le modèle, mais si vous construisez vous-même des invites brutes, vérifiez la fiche pour le format attendu. Utiliser le mauvais modèle dégrade silencieusement la qualité de la sortie sans lancer d’erreur.

​

Utilisation prévue

Les fiches indiquent typiquement pour quoi le modèle a été affiné — chat général, codage, raisonnement, suivi d’instructions — et parfois ce à quoi il est connu pour être faible. Cela vaut le coup d’être survolé avant de consacrer du matériel à un modèle qui s’avère être un mauvais ajustement pour votre tâche ; voir Quel modèle local pour quelle tâche ? pour faire correspondre les modèles aux tâches de manière plus systématique.

​

Ce qui compte une fois que vous le servez via Tokios

Lorsque vous enregistrez un modèle local comme déploiement Tokios, deux champs de la fiche de modèle se traduisent directement en décisions de configuration :

• Identifiant du modèle upstream vs. nom du déploiement. L’identifiant que votre backend sert (par exemple, une balise Ollama ou un chemin avec lequel un serveur llama.cpp a été lancé) est différent du nom de déploiement public que vous lui donnerez dans Tokios — la fiche vous indique le premier, vous choisissez le second.
• Longueur de contexte et licence sont portées comme contraintes sur la façon dont vous pouvez utiliser le déploiement, quel que soit le client qui l’appelle.

​

Aller plus loin

​

Une fois que vous en avez choisi un et qu’il fonctionne

Lire la fiche vous dit ce que le modèle peut faire. Une fois que vous l’avez téléchargé et qu’il répond aux requêtes sur localhost, l’étape suivante est de le rendre accessible.