RunPod publie un guide pour quitter l'API OpenAI au profit d'un LLM à poids ouverts auto-hébergé

RunPod a publié un guide pour migrer de l'API OpenAI vers un modèle de langage auto-hébergé à poids ouverts. Il vise les équipes lassées des limites de requêtes et de factures qui augmentent avec le trafic. L'annonce ne donne aucun chiffre d'économie. Il s'agit d'un contenu de fournisseur : RunPod vend du cloud GPU, et la logique du guide va dans ce sens. Mais la procédure de migration est devenue presque standard en quelques années, et mérite un examen lucide.

Pourquoi les équipes quittent l'API

Une API managée pose trois problèmes chroniques. Le premier, ce sont les limites : les plafonds de requêtes et de tokens par minute bloquent la croissance du produit plus vite qu'on ne le voudrait. Le deuxième, c'est l'imprévisibilité de la facture : chaque token est facturé, et une fonctionnalité qui réussit peut soudain devenir le premier poste de dépenses. Le troisième, c'est la dépendance aux décisions d'autrui : le fournisseur peut modifier le comportement du modèle, augmenter ses prix ou retirer une version du support. Pour certaines entreprises s'ajoute la question de la destination des données.

L'auto-hébergement remplace la facturation au token par la location de GPU au temps. Le calcul est favorable lorsque la carte est chargée de façon stable et dense. Si les requêtes sont rares et irrégulières, le matériel inactif annule facilement tout le gain, et l'API reste moins chère.

À quoi ressemble la migration

Le schéma décrit par RunPod, que suivent la plupart des équipes, est court. On choisit d'abord un modèle ouvert adapté à la tâche : Llama, Qwen, Mistral ou, par exemple, gpt-oss, d'OpenAI elle-même. On lance ensuite un serveur d'inférence comme vLLM, capable d'exposer un endpoint compatible OpenAI. Le code client n'est ainsi presque pas touché : on change l'adresse, la clé et le nom du modèle.

Sur RunPod, le déploiement peut se faire de deux façons : sur un pod GPU dédié, ou en mode serverless, où les workers s'adaptent à la charge et ne sont pas facturés à l'arrêt.

Repères sur le matériel et la compatibilité :

• Trois paramètres changent dans le code : base_url, clé API et nom du modèle.
• D'après OpenAI, gpt-oss-120b tient sur un seul GPU de 80 Go de mémoire ; licence Apache 2.0.
• gpt-oss-20b est conçu pour environ 16 Go de mémoire.
• Pod convient à une charge stable, Serverless à une charge variable.
• La facturation porte sur le temps de fonctionnement du GPU, et non sur les tokens.

Où se cachent les pièges

Un modèle ouvert n'est pas tenu de se comporter comme GPT sur vos prompts. Sur les raisonnements complexes et le contexte long, l'écart peut être sensible, et le function calling comme la sortie structurée sont implémentés différemment selon les modèles. Un endpoint compatible OpenAI garantit le format de la requête, pas la qualité de la réponse.

Le second groupe de risques tient à l'exploitation. En serverless, il y a un démarrage à froid : la première requête après une période d'inactivité peut prendre nettement plus de temps que d'habitude. Supervision, files d'attente, mise à jour des poids et des versions du serveur deviennent votre affaire, et non plus celle du fournisseur. Pour une petite équipe, cela peut coûter plus cher que les tokens économisés.

Comment tester sur son propre trafic

Avant de basculer la production, il est raisonnable de suivre plusieurs étapes :

1. Activer la journalisation des requêtes et réponses réelles pour constituer un jeu de test fidèle. 2. Faire passer ce jeu de test dans le modèle candidat et le comparer au modèle actuel selon vos propres critères, et non selon les benchmarks publics. 3. Lancer le nouveau modèle en mode shadow sur une petite part du trafic, par exemple 5–10%. 4. Calculer le coût de mille requêtes avec une charge GPU réelle, temps d'inactivité compris. 5. Conserver l'API OpenAI comme route de secours en cas de panne ou de qualité insuffisante.

Si, au bout du compte, les chiffres concordent, la migration se justifie. Sinon, le guide de RunPod reste utile : il montre ce que coûte réellement l'indépendance vis-à-vis de l'API d'un tiers.