Quitter l'API tient en une ligne de code.
La réécriture pour laquelle tout le monde prévoit un budget n'existe pas. Les stacks de serving auto-hébergées parlent la même API compatible OpenAI que votre code appelle déjà, donc la migration de l'infrastructure se résume au base URL. Le reste, honnêtement, ce sont des evals, pas de l'ingénierie, et cela joue dans les deux sens : la même ligne qui vous laisse les quitter vous laisse nous quitter aussi.
Dans cet article 3 sections
- Des équipes restent sur des API d'IA hébergées longtemps après avoir voulu en partir, parce qu'elles ont budgété une réécriture. Pour l'infrastructure en dessous, cette réécriture n'existe pas : les stacks de serving auto-hébergées exposent la même API compatible OpenAI que votre code parle déjà.
- La migration côté application, c'est le base URL et la clé. Vos prompts, vos handlers de streaming, votre outillage : inchangés.
- Le reste, honnêtement, c'est le comportement du modèle : un modèle différent répond différemment, donc le vrai travail de migration consiste à faire tourner vos evals sur vos propres tâches. Plus petit qu'une réécriture, et testable avant de vous engager.
- La même propriété vous protège à la sortie : des open weights plus une API standard signifient que nous quitter tient aussi en une ligne. Nous vendons à des clients qui peuvent partir.
La réunion a lieu partout. Tout le monde dans la salle veut quitter l'API hébergée, choisissez la raison : les données qui ne devraient pas sortir, le palier de rate limit qui ne survivra pas à la feuille de route, la facture qui grimpe avec le succès. Et puis quelqu'un prononce la phrase qui y met fin : nous sommes trop intégrés, ce serait une réécriture. Six mois plus tard, même réunion, même phrase, un sprint de logique de retry en plus entre les deux.
La phrase mérite un audit, parce que l'intégration qu'elle décrit a la profondeur d'une valeur de configuration.
h2 (#the-standard): Le monde s'est standardisé pendant que vous ne regardiez pas
Quelque chose d'utile s'est produit dans le monde du serving ces dernières années : le format de l'API OpenAI est devenu le standard de fait pour dialoguer avec les modèles de langage, et les stacks de serving open source l'ont adopté délibérément. Mêmes routes, même format de requête, même protocole de streaming, pour le cœur largement utilisé de la surface : chat completions, streaming, embeddings. Quand nous livrons un endpoint privé, il parle ce dialecte nativement. Votre SDK ne sait pas qu'il a déménagé. Si votre application s'est appuyée sur les extras propriétaires d'un fournisseur, c'est un court audit, pas une réécriture, et nous le parcourons avec vous : la plupart des extras ont des équivalents directs ou de fins shims.
- OPENAI_BASE_URL=https://api.vendor.example/v1
+ OPENAI_BASE_URL=https://inference.yourcompany.internal/v1
OPENAI_API_KEY=**** # your key, issued by you, revoked by youPrompts, handlers de streaming, logique de retry, outillage : intacts. Ce diff est toute la migration de l'infrastructure. C'est exactement pourquoi le budget de réécriture mérite la méfiance : il a été chiffré pour un monde où chaque fournisseur avait son propre format de communication, et ce monde a disparu.
h2 (#the-honest-remainder): Ce qui change vraiment : le modèle
Maintenant la moitié honnête, parce que l'affirmation de la ligne unique n'est vraie que pour l'infrastructure. Un modèle différent est un collègue différent. Posez-lui la même question et la réponse revient formulée et structurée différemment. Des prompts ajustés pour un modèle peuvent avoir besoin d'adaptation. Les cas limites se déplacent. C'est un vrai travail. Il est aussi borné, testable et bon marché par rapport à ce que vous aviez budgété : faites tourner votre jeu d'evals existant (ou construisez le petit jeu que vous devriez avoir de toute façon) contre le modèle candidat sur vos tâches réelles, comparez, décidez. Cela se passe avant de vous engager, sur un endpoint que vous pouvez essayer, pas après une réécriture que vous ne pouvez pas annuler.
| UNE LIGNE (L'INFRASTRUCTURE) | DU VRAI TRAVAIL (LE MODÈLE) |
|---|---|
| LA PARTIE QUE TOUT LE MONDE SURESTIMELe base URL et la clé d'API | Faire tourner vos evals sur le nouveau modèle |
| Formats de requête et de réponse, streaming | Ajustements de prompts là où le comportement a changé |
| Votre code de retry et d'outillage | Décider la quantization et le dimensionnement (nous nous en chargeons) |
| Les extras d'API propres au fournisseur, si vous les avez utilisés | Un court audit : remplacer ou shimmer chacun |
Remarquez ce qui n'est pas apparu dans ce tableau : aucune affirmation selon laquelle le modèle ouvert est aussi bon. Nous ne faisons pas cette affirmation, parce qu'elle vieillit mal et parce que vous ne devriez de toute façon pas l'accepter d'un fournisseur. L'exécution des evals remplace l'affirmation. Vos tâches, les deux modèles, côte à côte, et la décision vous appartient avec les éléments sous les yeux. Cette passe d'evals fait partie de notre déploiement, avec le dimensionnement et le compromis de quantization (montré, pas caché), là où un hébergeur infogéré mérite ses honoraires.
h2 (#both-ways): La ligne coupe dans les deux sens, à dessein
Tout ce qui précède décrit aussi le fait de nous quitter. Les open weights sont des fichiers portables. Le endpoint parle le dialecte standard. Vos données vivent sur votre machine et partent avec vous. Si nous cessons de mériter la charge de travail, la migration loin de nous est la même ligne unique, et nous l'avons construite ainsi délibérément, pour la même raison que le reste de l'entreprise a supprimé les compteurs et refuse les taxes de sortie (l'argument sur les frais d'egress est la même posture une couche plus bas). Un anti-lock-in que vous ne pouvez pas exercer est un mot de brochure. Des clients qui peuvent partir, et qui restent quand même, sont la seule référence qui vaille.
Une liberté de plus voyage avec : une fois le modèle à vous, personne ne le retire sous vos prompts, et la version qui a passé vos evals reste la version qui répond jusqu'à ce que vous en décidiez autrement. Sur une API hébergée, ce calendrier appartient à quelqu'un d'autre.
“La même ligne qui vous laisse les quitter vous laisse nous quitter. C'est tout l'intérêt.”
Réponses directes
L'API compatible OpenAI est-elle vraiment compatible ?+
Le cœur largement utilisé (chat completions, streaming, embeddings) est le standard de fait que le monde du serving implémente. Si vous vous êtes appuyé sur les extras propriétaires d'un fournisseur, ils reçoivent un court audit : la plupart ont des équivalents directs ou de fins shims, et nous parcourons cette liste avec vous.
Qu'advient-il de mon prompt engineering ?+
L'essentiel se transfère. Une partie a besoin d'ajustements là où le comportement du nouveau modèle diffère, et vos evals vous montrent exactement où. Budgétez des heures d'ajustement de prompts, pas une réécriture.
À une ligne de votre propre endpoint.
Apportez-nous le modèle que vous voulez faire tourner. Nous le dimensionnerons, le déploierons derrière l'API que votre code parle déjà, et ferons tourner les evals avec vous avant que vous ne changiez quoi que ce soit.
Parler à un ingénieurVous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur
