Guide du développeur sur les modèles à poids ouverts

Un modèle à poids ouverts (open-weight) est un modèle dont les poids entraînés — les paramètres appris, enregistrés sous forme de fichier — sont publiés en téléchargement, généralement accompagnés du code d’inférence nécessaire pour les exécuter, mais sans les données d’entraînement ni le pipeline d’entraînement qui les ont produits.

Si vous appelez jusqu’ici une API hébergée et que vous vous demandez si vous pourriez récupérer le modèle et l’exécuter comme vous installez un package, la réponse se décompose en deux parties : oui, vous pouvez le télécharger ; non, cela ne signifie pas que vous pouvez l’exécuter. Ce guide couvre ce que contient une publication à poids ouverts, pourquoi la licence importe davantage que l’étiquette, ce qu’il faut vérifier avant de construire dessus, ce qu’implique réellement le service d’un modèle de pointe, et les trois voies qu’un développeur d’applications sans GPU peut raisonnablement emprunter.

Que vous apporte concrètement un modèle à poids ouverts ?

Une publication à poids ouverts contient les poids, généralement le code d’inférence et un fichier de configuration décrivant l’architecture, et rarement quoi que ce soit sur la manière dont le modèle a été entraîné. Les poids sont le modèle : des milliards de nombres, stockés dans un format numérique tel que des flottants 16 bits ou un type quantifié 4 bits, organisés dans les tenseurs attendus par l’architecture. Le code d’inférence charge ces tenseurs et exécute une passe avant. Tout ce qui se situe en amont — le corpus d’entraînement, le filtrage des données et les scripts d’entraînement — reste chez l’éditeur.

C’est précisément cette omission qui distingue le poids ouvert de l’open source. La Open Source AI Definition publiée par l’Open Source Initiative exige plus qu’un fichier de poids : les paramètres, le code qui entraîne et exécute le système, et une description des données d’entraînement suffisamment complète pour qu’un ingénieur compétent puisse reconstruire un équivalent. Le jeu de données brut lui-même ne figure pas dans cette liste. Une publication qui ne livre que les poids et le code d’inférence ne satisfait pas ce critère, quelle que soit la permissivité de sa licence.

Pourquoi l’étiquette ne vous dit rien et la licence vous dit tout

L’étiquette « poids ouverts » décrit ce qui a été publié, non ce que vous êtes autorisé à en faire. La licence attachée aux poids fixe les conditions, et celles-ci vont de l’usage commercial sans restriction à un usage réservé à la recherche, les licences personnalisées rédigées par l’éditeur étant fréquentes. Deux modèles peuvent être téléchargeables depuis le même hub et comporter des obligations totalement différentes.

Kimi K3 en est un cas concret. Moonshot livre ses poids et le code associé sous une licence qu’il a rédigée lui-même plutôt qu’une licence standard. Le fichier de licence de Kimi K3 autorise l’usage commercial, la modification et la redistribution, mais y attache un seuil de chiffre d’affaires pour les opérateurs de model-as-a-service ainsi qu’une obligation d’attribution pour les déploiements dépassant un seuil de revenu mensuel ou d’utilisateurs actifs mensuels. Rien de tout cela n’est visible dans le mot « ouvert ». On le découvre en lisant le fichier.

Que faut-il vérifier dans une licence à poids ouverts ?

Avant de construire sur un modèle à poids ouverts, lisez sa licence pour y chercher quatre éléments : l’usage commercial est-il autorisé, pouvez-vous redistribuer les poids, pouvez-vous effectuer un fine-tuning et publier des dérivés, et qu’interdit la politique d’usage acceptable.

1. Usage commercial. Certaines licences l’autorisent sans réserve, d’autres le restreignent au-delà d’un seuil de chiffre d’affaires ou d’utilisateurs, d’autres l’interdisent. Vérifiez toute obligation qui se déclenche à l’échelle.
2. Redistribution. Pouvez-vous livrer les poids à l’intérieur de votre propre produit ou image de conteneur, ou devez-vous seulement renvoyer les utilisateurs vers le téléchargement de l’éditeur ?
3. Fine-tuning et dérivés. Confirmez que vous pouvez modifier les poids, et vérifiez sous quelle licence le dérivé doit être publié ainsi que l’existence éventuelle de règles de nommage.
4. Restrictions d’usage acceptable. De nombreuses licences comportent une annexe de politique d’usage qui interdit certaines applications. Lisez-la à l’aune de votre produit réel, pas de la démo.

Considérez le fichier de licence présent dans le dépôt comme la source de vérité. Les tags de métadonnées du hub et les résumés tiers finissent par être obsolètes.

Libre à télécharger n’est pas libre à exécuter

Pouvoir télécharger les poids d’un modèle et pouvoir les servir sont deux questions distinctes, et pour un modèle comptant des milliers de milliards de paramètres, la seconde réponse est un centre de données, pas un ordinateur portable.

Le résumé du modèle Kimi K3 indique 2 800 milliards de paramètres au total dans une architecture mixture-of-experts, dont 104 milliards activés par token, 896 experts parmi lesquels 16 sont sélectionnés par token, et une longueur de contexte de 1 048 576 tokens. Le même tableau donne le format numérique : poids MXFP4 et activations MXFP8, fixés pendant l’entraînement plutôt qu’appliqués à un modèle terminé. Même sur quatre bits, 2 800 milliards de paramètres représentent un stockage de l’ordre du téraoctet : l’onglet Files du dépôt montre des poids répartis sur 96 shards safetensors totalisant environ 1,56 To, avec des types de tenseurs référencés en F32, BF16 et U8. Chacun de ces octets doit être résident en mémoire d’accélérateur pour servir une requête à pleine vitesse, et le fait que « seuls 104 milliards soient actifs » ne réduit pas cette empreinte, car les experts déclenchés changent à chaque token.

La fiche elle-même vous indique comment tout cela est censé être exécuté. Sa section de déploiement désigne vLLM, SGLang et TokenSpeed comme moteurs à utiliser et vous renvoie vers une API hébergée ; une recette TokenSpeed existe spécifiquement pour ce modèle. Rien dans la fiche ne décrit une installation locale. Moonshot a annoncé Kimi K3 le 16 juillet 2026 et a publié les poids sur Hugging Face le 27 juillet 2026, la date fixée par cette annonce.

Comment exécuter concrètement un modèle à poids ouverts ?

Pour un développeur d’applications, un modèle à poids ouverts est accessible par trois voies : l’API hébergée de l’éditeur, un fournisseur d’inférence tiers qui exécute les poids publiés, ou une build communautaire quantifiée plus petite exécutée localement via un outil tel qu’Ollama ou LM Studio. Télécharger les poids bruts d’un modèle de pointe ne figure pas dans la liste, pour les raisons exposées ci-dessus.

Deux réserves concernant la troisième ligne. Des quantifications communautaires de Kimi K3 existent bel et bien, et Hugging Face répertorie des dizaines de dérivés quantifiés, mais la plupart restent des builds de 2 800 milliards de paramètres ou des versions élaguées de plusieurs centaines de milliards de paramètres, et non des téléchargements à l’échelle d’un ordinateur portable. La voie locale fonctionne pour les modèles dimensionnés pour cela, et c’est précisément ce que couvrent les guides Ollama et Jan.ai.

La bonne nouvelle est que changer de voie se réduit le plus souvent à modifier une base_url. Le quickstart Kimi K3 de Moonshot expose un endpoint compatible OpenAI, tout comme le serveur local d’Ollama :

from openai import OpenAI

# Publisher API
client = OpenAI(base_url="https://api.moonshot.ai/v1", api_key="YOUR_KEY")
# Serving provider (check your provider's docs for its endpoint)
# client = OpenAI(base_url="https://<provider>/v1", api_key="YOUR_KEY")
# Local runtime via Ollama
# client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

response = client.chat.completions.create(
    model="kimi-k3",  # model id differs per route
    messages=[{"role": "user", "content": "Summarise this licence."}],
)
print(response.choices[0].message.content)

Compatible ne signifie pas identique. Kimi K3, par exemple, ne désactive jamais le raisonnement, accepte un champ reasoning_effort réglé sur "low", "high" ou "max", et renvoie un champ reasoning_content que chaque tour ultérieur de la même conversation doit reporter tel quel. Vérifiez la documentation de l’éditeur pour ce genre de champs avant de présumer d’un remplacement transparent.

Comment choisir entre les trois voies ?

Le choix entre une API hébergée, un fournisseur d’inférence tiers et une build locale quantifiée se ramène à l’endroit où vont vos données, à la latence que le produit peut absorber, et à votre préférence entre payer au token ou à l’heure de matériel maintenu en fonctionnement. Si les prompts contiennent des données qui ne peuvent pas quitter votre infrastructure, la voie locale — ou un fournisseur proposant un accord de traitement des données que vous pouvez accepter — devient la contrainte qui détermine tout le reste. Si la fonctionnalité est interactive, l’API de l’éditeur et les fournisseurs d’inférence vous donnent le modèle complet à la vitesse d’un centre de données, tandis qu’une build quantifiée sur un ordinateur portable échange capacité et débit contre une absence totale de sortie de données. Si l’usage est en dents de scie, la facturation au token est peu coûteuse au démarrage et onéreuse à volume élevé ; s’il est régulier et intensif, les heures de matériel ou le matériel en propre aplanissent la courbe. Répondez à ces trois questions dans cet ordre et la voie se choisit généralement d’elle-même.

Conclusion

Poids ouverts signifie que vous obtenez les paramètres, pas la recette, et sans garantie que votre matériel puisse en faire quoi que ce soit. Lisez le fichier de licence dans le dépôt, lisez la section de déploiement de la fiche du modèle, et choisissez une voie en fonction des données, de la latence et de la structure de coûts plutôt qu’en fonction de ce qui est téléchargeable. Si la voie locale vous convient, commencez par le guide sur l’exécution privée de modèles avec Jan.ai, qui s’appuie directement sur tout ce qui précède.

FAQ

Quelle est la différence entre les fichiers safetensors et GGUF sur Hugging Face ?

Safetensors est le format de stockage de tenseurs de Hugging Face utilisé par les éditeurs pour les poids originaux ; il ne stocke que les tenseurs, de sorte que la configuration et le tokenizer sont livrés dans des fichiers distincts, et il se charge sans exécution de code basée sur pickle. GGUF est le format binaire créé pour llama.cpp et utilisé par Ollama et LM Studio ; un seul fichier regroupe les tenseurs quantifiés ainsi que des métadonnées normalisées. Les éditeurs publient généralement des safetensors, et la communauté les convertit en GGUF pour les runtimes locaux.

Puis-je appeler l'API hébergée d'un modèle à poids ouverts avec le SDK Anthropic au lieu du SDK OpenAI ?

Oui, si l'éditeur expose un endpoint compatible Anthropic, ce qui relève d'une fonctionnalité propre à chaque fournisseur et non d'une propriété des poids ouverts. C'est le cas de Moonshot : réglez l'URL de base du SDK sur https://api.moonshot.ai/anthropic et kimi-k3 répond sur un endpoint Messages à /anthropic/v1/messages. Les conventions Anthropic s'appliquent alors : max_tokens est obligatoire, l'effort de raisonnement se règle via output_config.effort (low, high ou max), et chaque bloc thinking, signature incluse, doit être renvoyé exactement tel qu'il a été reçu.

Une build communautaire quantifiée d'un modèle à poids ouverts est-elle soumise à la même licence que les poids originaux ?

Considérez que oui. Une quantification communautaire GGUF ou MLX est dérivée des poids de l'éditeur ; en pratique, les conditions de licence de l'éditeur — y compris les conditions d'usage commercial, les règles d'attribution et toute politique d'usage acceptable — continuent donc de s'appliquer, en plus de ce que le ré-uploadeur peut ajouter. Le tag de licence d'un dépôt Hugging Face est défini par la personne qui l'a mis en ligne et peut être absent ou erroné : lisez donc le fichier LICENSE en amont plutôt que les métadonnées du dérivé.