gpt-3.5-turbo-instruct : la variante 3.5 en mode completions⚠️ Modèle déprécié. OpenAI a retiré ce modèle. Pour les nouveaux projets, consultez GPT-4o mini pour un usage général économique ou GPT-4.1 pour un raisonnement plus robuste. Les intégrations existantes doivent planifier la migration avant la fermeture du point de terminaison API.
gpt-3.5-turbo-instruct est la variante GPT-3.5 Turbo qui exposait le modèle via l'API Completions historique plutôt que l'interface Chat Completions. Texte en entrée, texte en sortie, pas de tableau messages, pas de rôles, pas de formatage conversationnel autour du prompt — juste le prompt lui-même, et ce que le modèle continue.
Il est désormais déprécié. Le point de terminaison répond encore mais la surface API Completions elle-même a été progressivement abandonnée dans toute la gamme OpenAI, et ce modèle est l'un des derniers vestiges significatifs.
Pourquoi une variante séparée a existé
Quand OpenAI a livré GPT-3.5 Turbo en mars 2023, l'API Chat Completions était le nouveau paradigme. Le tableau messages, le rôle système, le prompting basé sur les rôles — tout cela constituait une nouvelle infrastructure. Beaucoup de code en production était écrit contre l'ancienne API Completions utilisée par GPT-3, où vous envoyiez une chaîne de caractères et le modèle la continuait.
Migrer ce code vers l'interface conversationnelle n'était pas trivial. Les prompts devaient être restructurés, les frontières de rôles devaient être définies, et les cas limites où le formatage conversationnel changeait le comportement du modèle devaient être débogués. Pour les équipes qui avaient des pipelines de production construits contre l'ancienne surface API, OpenAI a livré gpt-3.5-turbo-instruct comme passerelle — mêmes poids de modèle que le 3.5 Turbo standard, exposés via l'ancienne forme d'API.
La variante était particulièrement utile pour trois formes de charge de travail. Les pipelines de classification et d'étiquetage où vous vouliez un seul token ou une courte étiquette en sortie sans que le modèle n'enveloppe une réponse conversationnelle autour. Les flux de travail de style complétion de code où le prompt était déjà une sortie partielle et vous vouliez une continuation, pas un tour de conversation. Les pipelines dépendants des logprobs où l'API Completions exposait les probabilités de tokens de manière plus directe que la surface conversationnelle ne le faisait.
Pour ces trois cas, l'interface conversationnelle ajoutait de la surcharge — tokens supplémentaires pour le formatage, comportement du modèle façonné par l'entraînement sur des réponses de style conversationnel, style de sortie légèrement différent. La variante instruct permettait à ces charges de travail de continuer à fonctionner à l'ancienne.
Comment le modèle se comportait
Le même comportement de génération 3.5 que le reste de la famille. Profondeur de raisonnement au niveau 3.5. Factualité qui nécessitait une augmentation par récupération ou une révision humaine sur les chemins factuels. Calibration du refus qui était parfois trop empressée et parfois trop complaisante.
Ce à quoi il ne ressemblait pas, c'était un modèle conversationnel. La variante instruct n'enveloppait pas les réponses dans un cadrage conversationnel, ne produisait pas de formules toutes faites du type "en tant qu'assistant IA", ne s'entourait pas de précautions de la manière dont sont entraînés les modèles conversationnels. Pour les charges de travail qui voulaient une continuation propre, c'était un meilleur choix que le 3.5 Turbo standard, même si la capacité sous-jacente était la même.
La fenêtre de contexte de 16 385 tokens était héritée de la famille 3.5 au sens large.
Pourquoi les équipes sont restées sur instruct
Deux raisons au-delà de celle du code hérité mentionnée ci-dessus.
Premièrement, l'accès aux logprobs. L'API Completions exposait les logprobs au niveau des tokens de manière plus directe que l'interface conversationnelle ne le faisait. Les équipes faisant du décodage contraint, de l'échantillonnage de sortie structurée, de la classification avec scores de confiance, ou tout travail en aval conscient des logprobs se sont fixées sur la variante instruct pour cette surface. L'interface conversationnelle a fini par développer des capacités similaires mais l'API instruct était la forme la plus propre pour ce type de travail pendant longtemps.
Deuxièmement, moins de tokens de formatage. L'interface conversationnelle ajoute quelques tokens de formatage à chaque requête, ce qui s'accumule à haut volume. Pour les charges de travail avec des prompts très courts et des complétions très courtes, la surcharge de tokenisation de la variante instruct était moindre, ce qui se traduisait par des coûts par appel légèrement moins élevés et une latence légèrement plus faible.
Ces deux raisons se sont affaiblies au fil du temps à mesure que l'interface conversationnelle a mûri, mais les ancrage originaux sont toujours présents dans du code de production qui n'a pas été réarchitecturé.
Migration
La variante instruct dédiée n'a pas de successeur direct dans la gamme OpenAI. L'API Completions est suffisamment abandonnée pour qu'aucun modèle actuel ne soit offert à travers elle comme surface primaire.
Pour les charges de travail qui se sont fixées sur instruct pour des raisons de code hérité, la migration se fait vers l'interface conversationnelle sur un modèle actuel. GPT-4o mini est la correspondance comportementale la plus proche pour le trafic au format conversationnel. La réarchitecture du prompt constitue l'essentiel du travail — une fois qu'une charge de travail est sur l'interface conversationnelle, la mise à niveau du modèle elle-même est un simple changement de balise.
Pour les charges de travail dépendantes des logprobs, l'interface conversationnelle sur les modèles OpenAI actuels expose les données pertinentes, bien que les modèles d'intégration soient différents. Les équipes faisant du décodage contraint ou de l'échantillonnage structuré peuvent trouver que la fonctionnalité de sorties structurées strictes sur GPT-4o et GPT-4.1 est plus adaptée que l'échantillonnage conscient des logprobs contre un ancien modèle instruct.
Pour la classification à haut volume où la surcharge des tokens de formatage compte, gpt-4.1-nano ou un modèle à poids ouverts de la famille Gemma 3 est plus adapté qu'une autre variante instruct 3.5. Le coût par appel sur les modèles actuels à bas prix est bien en dessous du point de prix 3.5 Turbo.
Que faire aujourd'hui
Si gpt-3.5-turbo-instruct est encore dans votre pile technologique, la migration est l'une des plus lourdes de la famille 3.5. C'est la surface API elle-même qui change, pas seulement le modèle. Réarchitecturer autour de l'interface conversationnelle représente plus de travail que d'échanger un identifiant de modèle.
Planifiez-le délibérément. Auditez chaque site d'appel. Pour chacun, décidez si la charge de travail appartient encore du tout à un petit modèle, ou si le bon mouvement est de la consolider dans un pipeline plus large s'exécutant sur un modèle actuel de frontière ou de niveau intermédiaire. La plupart des équipes qui auditent honnêtement découvrent que le déploiement instruct original résolvait un problème qui n'existe plus.
Pour le contexte plus large du 3.5, consultez GPT-3.5 Turbo. Pour la direction actuelle de la gamme OpenAI, consultez GPT-4.1.
Le choisir
Ne choisissez pas cette variante pour de nouvelles constructions. L'API Completions est en voie d'abandon dans toute la gamme OpenAI et la génération 3.5 est dépréciée.
Pour les intégrations existantes, la migration se fait vers l'interface conversationnelle sur un modèle actuel. Planifiez-la avant l'arrivée de la date de dépréciation.
Dernière révision technique : 2026-05-22 — Tokonomix.ai
