Le modèle ne suffit pas : il faut choisir comment l’exécuter
Après avoir sélectionné une famille comme Qwen, DeepSeek, GLM, Kimi ou MiniMax, une seconde décision apparaît : par quel canal utiliser le modèle ?
Trois options dominent : l’API officielle de l’éditeur, un fournisseur d’inférence tiers ou l’auto-hébergement des poids. Elles peuvent exposer un modèle de même famille, mais elles ne donnent pas le même niveau de contrôle, le même coût ni exactement les mêmes réponses.
Option 1 : l’API officielle
L’éditeur héberge le modèle et fournit une clé, un endpoint et une facturation à l’usage.
Avantages
- mise en route rapide ;
- accès direct au catalogue et aux nouveautés ;
- aucune infrastructure GPU à maintenir ;
- documentation et support proches du modèle ;
- montée en charge gérée par le fournisseur.
Limites
- choix de régions parfois restreint ;
- dépendance aux quotas et conditions du fournisseur ;
- versions pouvant changer ou disparaître ;
- traitement des données à examiner attentivement ;
- accès international ou facturation parfois complexes.
Quand la choisir ?
Pour un prototype, une évaluation rapide ou un produit dont les données et contraintes sont compatibles avec les conditions officielles.
Option 2 : un fournisseur d’inférence tiers
Un cloud ou une plateforme spécialisée sert les poids du modèle depuis sa propre infrastructure. Le même fournisseur peut réunir plusieurs familles derrière une API commune.
Avantages
- région ou infrastructure plus proche de vos besoins ;
- comparaison de plusieurs modèles avec une intégration unique ;
- endpoints serverless ou dédiés ;
- facturation et support parfois plus accessibles ;
- possibilité d’épingler une version ou une quantification.
Limites
- ajout d’un intermédiaire et d’un contrat ;
- modèle potentiellement modifié, quantifié ou configuré différemment ;
- délai entre sortie officielle et disponibilité ;
- qualité de service variable ;
- compatibilité API parfois partielle.
Quand la choisir ?
Lorsque la région, la consolidation des fournisseurs ou l’absence d’exploitation GPU est prioritaire, mais que l’API officielle ne convient pas.
Option 3 : l’auto-hébergement
Vous téléchargez les poids et exécutez le modèle avec un runtime comme vLLM, SGLang ou un autre moteur compatible.
Avantages
- contrôle du réseau, des journaux et des mises à jour ;
- version stable et épinglée ;
- personnalisation et fine-tuning possibles selon licence ;
- absence de facturation par token ;
- possibilité de traiter sans envoyer les données à un tiers.
Limites
- achat ou location de GPU ;
- capacité, disponibilité et supervision à gérer ;
- sécurité et correctifs sous votre responsabilité ;
- coût élevé à faible utilisation ;
- besoin de compétences en inférence et en exploitation.
Quand la choisir ?
Lorsque les poids et la licence le permettent, que le volume est suffisant ou que les données doivent rester dans une infrastructure contrôlée.
Tableau de décision
| Critère | API officielle | Fournisseur tiers | Auto-hébergement |
|---|---|---|---|
| Démarrage | Très rapide | Rapide | Plus lent |
| Exploitation GPU | Aucune | Aucune ou limitée | À votre charge |
| Choix de région | Selon éditeur | Souvent plus large | Contrôlé |
| Contrôle de version | Selon API | Variable | Fort |
| Contrôle des données | Contractuel | Contractuel | Technique et organisationnel |
| Coût à faible volume | Souvent favorable | Souvent favorable | Souvent défavorable |
| Coût à volume stable | Variable | Variable | Potentiellement favorable |
| Personnalisation | Limitée | Variable | Forte selon licence |
| Réversibilité | Dépend de l’API | Souvent facilitée | Forte si runtime standard |
Pourquoi le même modèle peut-il répondre différemment ?
Le nom de famille ne garantit pas une exécution identique. Les différences peuvent venir de :
- version ou snapshot ;
- quantification des poids ;
- template de chat ;
- précision numérique ;
- paramètres de génération ;
- système de modération ;
- longueur de contexte réellement autorisée ;
- outils ajoutés par le fournisseur ;
- version du runtime.
Lorsque vous changez de canal, rejouez le jeu d’évaluation complet.
Calculer le coût complet
API
Additionnez entrée, sortie, cache, appels ratés, outils, stockage et éventuels frais de plateforme.
Auto-hébergement
Calculez : coût GPU horaire ÷ requêtes utiles par heure, puis ajoutez stockage des poids, trafic, redondance, supervision et temps humain.
Un GPU inutilisé reste facturé. À l’inverse, une API coûte plus cher lorsque chaque requête envoie un contexte inutilement long. Comparez le coût par résultat validé sur un mois représentatif.
Vérifier les données
Pour une API officielle ou tierce, documentez région, rétention, usage pour entraînement, sous-traitants, accès support, chiffrement et suppression.
Pour l’auto-hébergement, ne supposez pas que tout est privé par défaut. Les logs, traces, sauvegardes et services d’observabilité peuvent exporter le contenu. Faites une cartographie réelle des flux.
Vérifier la licence
Avant de télécharger un modèle :
- confirmez l’usage commercial ;
- vérifiez les restrictions et seuils ;
- identifiez les obligations de redistribution ;
- séparez licence des poids et du code ;
- vérifiez les dérivés et fine-tunings ;
- conservez la version du texte de licence examinée.
Un fournisseur tiers peut avoir le droit de servir un modèle sans que vous ayez le droit de redistribuer ses poids.
Une stratégie progressive
Étape 1 : évaluer par API
Testez deux ou trois modèles sur des données non sensibles. Mesurez qualité, français, outils, latence et coût.
Étape 2 : choisir le canal cible
Éliminez les options incompatibles avec région, licence ou sécurité. Comparez ensuite API officielle et fournisseurs tiers.
Étape 3 : benchmarker le local
Si le volume ou le contrôle le justifie, déployez un prototype du modèle ouvert. Mesurez débit et mémoire au lieu d’utiliser une estimation théorique.
Étape 4 : préparer la réversibilité
Utilisez un contrat interne, épinglez les identifiants et conservez des tests. Préparez un fallback qui a réellement été exécuté.
Exemple : assistant de support
Une jeune équipe peut commencer avec l’API officielle pour valider la qualité. Si les données deviennent sensibles, elle peut migrer vers un fournisseur européen servant les mêmes poids. Si le volume devient stable et important, elle peut comparer un endpoint dédié à l’auto-hébergement.
Le modèle ne change pas nécessairement à chaque étape, mais sa version, son runtime et son comportement doivent être réévalués.
Les erreurs courantes
- choisir uniquement selon le prix par token ;
- envoyer des données sensibles pendant l’essai ;
- supposer qu’une API compatible OpenAI est identique ;
- oublier la licence des poids ;
- auto-héberger sans supervision ni redondance ;
- ne pas épingler la version ;
- considérer un fournisseur tiers comme transparent ;
- ne jamais tester la procédure de fallback.
FAQ
Quelle option choisir pour commencer ?
Une API est généralement la plus rapide pour évaluer. Utilisez des données minimisées et vérifiez ses conditions.
Quand l’auto-hébergement devient-il rentable ?
Quand le débit et l’utilisation du GPU sont suffisamment stables pour compenser infrastructure et exploitation. Il faut le mesurer.
Un fournisseur européen peut-il servir un modèle chinois ?
Oui si la licence le permet. Cela peut changer le lieu d’inférence, mais pas l’origine ni nécessairement toutes les dépendances.
L’API officielle donne-t-elle toujours la meilleure qualité ?
Pas nécessairement. Elle peut proposer la version la plus récente, mais un fournisseur tiers peut optimiser son runtime. Seul un test tranche.
Peut-on migrer sans changer le code ?
Parfois en grande partie grâce aux API compatibles, mais les outils, erreurs, paramètres et sorties doivent être testés.