Un modèle open-weight est-il gratuit ?

Les poids sont gratuits à télécharger, pas gratuits à faire tourner. Vous payez les GPU (loués ou possédés), l'électricité, l'ops et les gens qui maintiennent le service. À faible volume, une API hébergée revient en général moins cher que l'auto-hébergement une fois le coût total de possession compté.

Quelle différence entre open weights et open source ?

Open weights signifie que les paramètres sont publiés, donc vous pouvez faire tourner et fine-tuner le modèle. Open source est une barre de licence plus stricte : usage, modification et redistribution libres, sans restriction de domaine d'usage (la définition OSI). Apache-2.0 et MIT qualifient ; beaucoup de licences communautaires de labos, dont Llama, non, car elles portent des plafonds ou des conditions d'usage.

Quand l'auto-hébergement devient-il vraiment rentable ?

À volume soutenu et prévisible. En ordre de grandeur, l'auto-hébergement tend à devenir rentable autour de 500K tokens par jour pour un petit modèle sur un seul GPU, et de quelques millions de tokens par jour pour un modèle de classe 70B. Face à des API bon marché, il peut falloir des dizaines de millions de tokens par mois. En dessous, le coût d'ops l'emporte sur l'économie de tokens.

Puis-je utiliser un modèle US et rester conforme RGPD en EU ?

Souvent oui, mais pas par défaut. Une API hébergée aux US peut créer une exposition au CLOUD Act, donc vous fixez une région EU (Bedrock Frankfurt, Vertex Frankfurt, Azure West Europe), signez un accord de traitement des données, et gérez base légale, rétention et sous-traitants. L'alternative : un fournisseur EU-natif comme Mistral, ou l'auto-hébergement d'un modèle open-weight dans une infrastructure EU sous votre contrôle.

Qu'est-ce qui change avec l'EU AI Act en 2026 ?

Les obligations de fond de l'EU AI Act s'appliquent à partir du 2 août 2026. En pratique vous classez votre usage de l'IA, assurez la littératie IA dans vos équipes, et pour les usages à risque plus élevé ajoutez documentation, gestion du risque et supervision humaine. Le choix de déploiement s'inscrit dans ce cadre : l'endroit où tourne le modèle et le fournisseur que vous utilisez influent sur la façon dont vous démontrez le contrôle et le traitement des données.

← Stack

Déployer un modèle

API du labo, open-weight managé ou auto-hébergé : où tourne votre modèle, et qui paie quoi.

Vue d'ensemble

Un binaire circule partout : payer un fournisseur propriétaire, ou faire tourner soi-même un modèle libre et gratuit. Les deux branches sont fausses. Faire tourner un modèle en production, c'est un spectre à trois positions, et le choix porte rarement sur le modèle lui-même : il porte sur l'endroit où se fait l'inférence et sur qui assume le coût, le contrôle et la conformité.

Position 1 : un modèle fermé derrière une API de labo (Anthropic, OpenAI, Google). Vous payez au token, vous obtenez la capacité maximale sans aucune infrastructure, et vos données sortent de votre périmètre. Position 2, celle que la plupart des analyses escamotent : un modèle open-weight chez un inference provider managé (Together, Fireworks, Groq, Bedrock, Vertex, Mistral hébergé). Vous payez toujours au token, mais les poids sont ouverts, le catalogue est large, et vous pouvez fixer une région EU. Position 3 : le même modèle open-weight auto-hébergé sur vos propres GPU, on-prem ou en edge. Là vous payez l'infrastructure au lieu des tokens, vous gardez le contrôle total et la souveraineté des données, et vous n'êtes gagnant qu'à volume soutenu.

Deux mythes à déconstruire avant d'aller plus loin. Open-weight n'est pas gratuit : télécharger les poids ne coûte rien, mais les faire tourner coûte du compute, de l'ops et des gens. Et open-weight n'est pas open-source : des paramètres publiés n'impliquent pas une licence de niveau OSI. La licence Llama porte un plafond d'utilisateurs actifs mensuels et des conditions d'usage en EU ; Qwen, DeepSeek et plusieurs modèles Mistral sortent sous des licences réellement permissives, Apache-2.0 ou MIT. La licence fait partie de la décision de déploiement, ce n'est pas une note de bas de page.

Architecture

Lisez le spectre de gauche à droite. À mesure que vous passez d'une API de labo vers l'auto-hébergement, trois choses bougent ensemble : vous cessez de payer au token pour payer l'infrastructure, le contrôle et la souveraineté des données montent de faible à élevé, et le temps de démarrage passe d'instantané à un vrai projet d'ingénierie. Aucune position n'est universellement bonne : seulement celle qui correspond à votre volume, à votre tolérance à la latence et à vos contraintes de conformité.

Le spectre de déploiement : API du labo → open-weight managé → auto-hébergé, et le gradient coût, contrôle et souveraineté qui le traverse.

Concepts clés

Open weights: Les paramètres du modèle entraîné sont publiés et téléchargeables, donc n'importe qui peut faire tourner le modèle. Cela ne dit rien des termes de licence : un modèle open-weight peut tout de même porter des plafonds commerciaux ou des restrictions d'usage.
Open source (OSI): Une barre plus haute qu'open weights : la licence doit satisfaire la définition de l'Open Source Initiative (usage, modification et redistribution libres, sans restriction de domaine d'usage). Apache-2.0 et MIT qualifient ; la plupart des licences « communautaires » des labos non.
Inference provider: Un service managé qui héberge des modèles open-weight et les sert via une API, donc vous payez au token sans posséder de GPU. Together, Fireworks, Groq, AWS Bedrock et Google Vertex en sont des exemples ; certains ajoutent du fine-tuning et des régions EU.
Auto-hébergement: Vous faites tourner le modèle sur une infrastructure que vous contrôlez : GPU loués, votre propre datacenter, ou matériel en edge. Vous échangez la facturation au token contre du coût capital et opérationnel, et gagnez le contrôle total sur les données et la disponibilité.
Coût total de possession (TCO): Le coût réel de l'auto-hébergement, pas seulement la facture GPU : ajoutez électricité, refroidissement, réseau, outillage et le temps des équipes pour l'exploiter. Une règle courante situe le coût réel au coût GPU brut multiplié par 1,3 à 3.
Prompt caching: Réutiliser à prix réduit un préfixe déjà traité (prompt système, définitions d'outils, tours précédents) sur les appels suivants. Cela change l'économie des boucles d'agents, où le même grand contexte se répète sur de nombreuses étapes.
Souveraineté des données: Le contrôle sur le lieu de traitement des données et la juridiction qui les gouverne. Pour un acheteur EU, une API hébergée aux US peut créer une exposition au CLOUD Act ; une région EU ou un fournisseur EU-natif garde le traitement dans la juridiction européenne.

Quand l'utiliser

Cas adaptés

API du labo quand vous voulez la capacité maximale sans aucune infrastructure, que votre volume est faible à modéré, et que vos données ne sont pas soumises à une contrainte de résidence que vous ne pouvez pas satisfaire avec une région ou un accord de traitement.
L'inference managé quand vous voulez un modèle open-weight (pour la portabilité, le fine-tuning, ou éviter le lock-in d'un labo) sans exploiter de GPU, et qu'un large catalogue ou une région EU compte plus que de le faire tourner vous-même.
Auto-hébergement quand le volume est élevé et prévisible, quand les données ne doivent jamais quitter votre périmètre, ou quand les exigences de latence et de disponibilité justifient de posséder la stack. C'est rentable à l'échelle, pas avant.
Un mélange, routé par tâche : une API de grand labo pour les étapes de raisonnement complexes, un petit modèle managé ou auto-hébergé à bas coût pour la classification et le routage à fort volume. Le choix de déploiement se fait par charge de travail, pas par entreprise.

Anti-patterns

Auto-héberger à faible volume pour économiser. En dessous d'environ 500K tokens par jour pour un petit modèle, ou de quelques millions pour un grand, une API revient moins cher une fois le TCO complet calculé. Vous dépenserez plus en ops que vous n'économiserez sur les tokens.
Croire qu'open-weight veut dire gratuit. Les poids ne coûtent rien à télécharger et tout à faire tourner. Budgétez les GPU, l'ops et les gens avant de vous engager.
Envoyer des données personnelles EU réglementées à une API hébergée aux US sans région fixée ni accord de traitement des données. La qualité du modèle est sans objet si le chemin des données n'est pas conforme.
Choisir un modèle open-weight sur la seule capacité sans lire la licence. Un plafond d'utilisateurs actifs mensuels ou une restriction de domaine d'usage peut l'exclure de votre produit après que vous avez déjà construit dessus.

Exemples de code

Position 1 : un modèle fermé via API du labo

from anthropic import Anthropic

client = Anthropic()  # ANTHROPIC_API_KEY in the environment
msg = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=512,
    messages=[{"role": "user", "content": "Summarise this ticket."}],
)
print(msg.content[0].text)
# You pay per token. No GPU, no ops. Data transits the provider.

Le chemin le plus rapide vers la capacité maximale. Le compromis : la sortie des données et un coût au token qui croît linéairement avec le volume.

Position 2 : un modèle open-weight via inference managé

from openai import OpenAI

# Same OpenAI-compatible client, pointed at a managed provider's
# base_url (Together, Fireworks, Groq, Bedrock-compatible gateways...).
client = OpenAI(
    base_url="https://api.example.com/v1",
    api_key="...",  # provider key
)
resp = client.chat.completions.create(
    model="Qwen/Qwen3-235B",  # open weights, Apache-2.0
    messages=[{"role": "user", "content": "Summarise this ticket."}],
)
print(resp.choices[0].message.content)
# Still per-token, but open weights and a provider-chosen region.

La position intermédiaire : un modèle open-weight et une interface portable compatible OpenAI, sans faire tourner de GPU vous-même. La plupart des providers permettent de fixer une région EU.

Position 3 : auto-héberger le même modèle open-weight

# Serve an open-weight model on your own GPU with vLLM.
pip install vllm
vllm serve Qwen/Qwen3-235B --port 8000

# It exposes the same OpenAI-compatible API on localhost:8000.
# Now you pay for the GPU and the ops, not per token.
# Below sustained volume this costs MORE than the managed call above.

Surface d'API identique, structure de coût opposée : l'infrastructure au lieu des tokens, le contrôle total au lieu d'un endpoint partagé. Rentable seulement à volume soutenu et prévisible.

Comparatif

vs Lab API

Modèle de coût, contrôle, temps de démarrage

Facturation au token, capacité maximale, démarrage instantané, zéro ops. Vous renoncez au contrôle de la résidence des données et votre coût croît linéairement avec le volume. Idéal pour un volume faible à modéré et le raisonnement le plus difficile, quand la conformité le permet.

vs Managed inference

Modèle de coût, ouverture, région

Facturation au token sur des modèles open-weight, large catalogue, API portable compatible OpenAI, souvent une région EU. Le milieu pragmatique : des poids ouverts et aucun GPU à exploiter. Vous dépendez du provider pour la disponibilité et le prix, mais vous pouvez déplacer les mêmes poids ailleurs.

vs Self-hosting

Modèle de coût, souveraineté, charge opérationnelle

Payer l'infrastructure au lieu des tokens, contrôle total et souveraineté des données, et la charge opérationnelle la plus lourde. Rentable seulement à volume soutenu et prévisible. Le bon choix quand les données doivent rester dans votre périmètre ou que le volume suffit à amortir les GPU.

Ressources

FAQ

Un modèle open-weight est-il gratuit ?: Les poids sont gratuits à télécharger, pas gratuits à faire tourner. Vous payez les GPU (loués ou possédés), l'électricité, l'ops et les gens qui maintiennent le service. À faible volume, une API hébergée revient en général moins cher que l'auto-hébergement une fois le coût total de possession compté.
Quelle différence entre open weights et open source ?: Open weights signifie que les paramètres sont publiés, donc vous pouvez faire tourner et fine-tuner le modèle. Open source est une barre de licence plus stricte : usage, modification et redistribution libres, sans restriction de domaine d'usage (la définition OSI). Apache-2.0 et MIT qualifient ; beaucoup de licences communautaires de labos, dont Llama, non, car elles portent des plafonds ou des conditions d'usage.
Quand l'auto-hébergement devient-il vraiment rentable ?: À volume soutenu et prévisible. En ordre de grandeur, l'auto-hébergement tend à devenir rentable autour de 500K tokens par jour pour un petit modèle sur un seul GPU, et de quelques millions de tokens par jour pour un modèle de classe 70B. Face à des API bon marché, il peut falloir des dizaines de millions de tokens par mois. En dessous, le coût d'ops l'emporte sur l'économie de tokens.
Puis-je utiliser un modèle US et rester conforme RGPD en EU ?: Souvent oui, mais pas par défaut. Une API hébergée aux US peut créer une exposition au CLOUD Act, donc vous fixez une région EU (Bedrock Frankfurt, Vertex Frankfurt, Azure West Europe), signez un accord de traitement des données, et gérez base légale, rétention et sous-traitants. L'alternative : un fournisseur EU-natif comme Mistral, ou l'auto-hébergement d'un modèle open-weight dans une infrastructure EU sous votre contrôle.
Qu'est-ce qui change avec l'EU AI Act en 2026 ?: Les obligations de fond de l'EU AI Act s'appliquent à partir du 2 août 2026. En pratique vous classez votre usage de l'IA, assurez la littératie IA dans vos équipes, et pour les usages à risque plus élevé ajoutez documentation, gestion du risque et supervision humaine. Le choix de déploiement s'inscrit dans ce cadre : l'endroit où tourne le modèle et le fournisseur que vous utilisez influent sur la façon dont vous démontrez le contrôle et le traitement des données.