Utiliser les bibliothèques OpenAI avec Gemini Enterprise Agent Platform

L'API Chat Completions fonctionne comme un point de terminaison compatible avec Open AI et conçu pour faciliter l'interaction avec Gemini sur Gemini Enterprise Agent Platform à l'aide des bibliothèques Open AI pour Python et REST. Si vous utilisez déjà les bibliothèques OpenAI, vous pouvez utiliser cette API pour passer de l'appel de modèles OpenAI à l'appel de modèles hébergés par Agent Platform afin d'en comparer la sortie, les coûts et l'évolutivité, sans modifier votre code existant. Si vous n'utilisez pas encore les bibliothèques OpenAI, nous vous recommandons de utiliser le SDK Google Gen AI. Pour migrer votre code SDK OpenAI existant afin d'utiliser le SDK Google Gen AI, consultez Migrer du SDK OpenAI vers le SDK Google Gen AI.

Modèles compatibles

L'API Chat Completions est compatible avec les modèles Gemini et certains modèles auto-déployés de Model Garden.

Modèles Gemini

Les modèles suivants sont compatibles avec l'API Chat Completions :

Cliquer pour développer la liste des modèles compatibles

Modèles déployés automatiquement à partir de Model Garden

Les conteneurs pour HuggingFace Text Generation Interface (HF TGI) et les conteneurs vLLM prédéfinis Agent Platform Model Garden sont compatibles avec l'API Chat Completions. Toutefois, tous les modèles déployés dans ces conteneurs ne sont pas compatibles avec l'API Chat Completions. Le tableau suivant inclut les modèles compatibles les plus populaires par conteneur :

HF TGI

vLLM

Paramètres disponibles

Pour les modèles Google, l'API Chat Completions est compatible avec les paramètres OpenAI suivants. Pour obtenir une description de chaque paramètre, consultez la documentation d'OpenAI sur la création de complétion de conversation. La disponibilité des paramètres pour les modèles tiers varie selon les modèles. Pour connaître les paramètres acceptés, consultez la documentation du modèle concerné.

messages
  • System message
  • User message : les types text et image_url sont acceptés. Le image_url type accepte les images stockées dans un URI Cloud Storage ou un encodage en base64 au format "data:<MIME-TYPE>;base64,<BASE64-ENCODED-BYTES>". Pour apprendre à créer un bucket Cloud Storage et à y importer un fichier, consultez Découvrir le stockage d'objets.
  • Assistant message
  • Tool message
  • Function message : ce champ est obsolète, mais reste disponible pour des raisons de rétrocompatibilité.
model
detail Pour les modèles antérieurs à Gemini 3, le champ detail doit être cohérent dans tous les messages et contenus (il s'agit d'un niveau de requête). Pour Gemini 3 et versions ultérieures, cela correspond à un `media_resolution` au niveau de la partie. Pour en savoir plus, consultez Résolution des médias.
max_completion_tokens Alias de max_tokens.
modalities Compatible avec audio, image et text.
max_tokens
n
frequency_penalty
presence_penalty
reasoning_effort Configure la durée et le nombre de jetons utilisés pour une réponse.
  • low: 1024
  • medium: 8192
  • high: 24576
Comme aucune réflexion n'est incluse dans la réponse, vous ne pouvez spécifier qu'un seul des éléments reasoning_effort ou extra_body.google.thinking_config peuvent être spécifiés.
response_format
  • json_object : interprété comme une transmission de "application/json" à l'API Gemini.
  • json_schema. Les schémas entièrement récursifs ne sont pas acceptés. additional_properties est accepté.
  • text: interprété comme une transmission de "text/plain" à l'API Gemini.
  • Tout autre type MIME est transmis tel quel au modèle, ce qui revient à transmettre "application/json" directement.
seed Correspond à GenerationConfig.seed.
stop
stream
temperature
top_p
tools
  • type
  • function
    • name
    • description
    • parameters : spécifiez les paramètres à l'aide de la spécification OpenAPI. Cela diffère du champ de paramètres OpenAI, qui est décrit comme un objet de schéma JSON. Pour en savoir plus sur les différences de mots clés entre OpenAPI et les schémas JSON, consultez le guide OpenAPI.
tool_choice
  • none
  • auto
  • required : correspond au mode ANY dans le FunctionCallingConfig.
  • validated : correspond au mode VALIDATED dans FunctionCallingConfig. Il s'agit d'une fonctionnalité spécifique à Google.
web_search_options Correspond à l'outil GoogleSearch. Aucune sous-option n'est acceptée.
function_call Ce champ est obsolète, mais reste disponible pour des raisons de rétrocompatibilité.
functions Ce champ est obsolète, mais reste disponible pour des raisons de rétrocompatibilité.

Si vous transmettez un paramètre non accepté, il est ignoré.

Paramètres d'entrée multimodaux

L'API Chat Completions est compatible avec certaines entrées multimodales.

input_audio
  • data: tout URI ou format blob valide. Nous acceptons tous les types de blobs, y compris les images, les contenus audio et les vidéos. Tout ce qui est compatible avec GenerateContent est accepté (HTTP, Cloud Storage, etc.).
  • format: OpenAI est compatible avec wav (audio/wav) et mp3 (audio/mp3). Avec Gemini, tous les types MIME valides sont acceptés.
image_url
  • data: : comme input_audio, tout URI ou format blob valide est accepté.
    Notez que image_url en tant qu'URL sera défini par défaut sur le type MIME image/* et que image_url en tant que données blob peut être utilisé comme n'importe quelle entrée multimodale.
  • detail: similaire à la résolution des médias, cela détermine le nombre maximal de jetons par image pour la requête. Notez que, bien que le champ d'OpenAI soit par image, Gemini applique le même niveau de détail à l'ensemble de la requête. Si vous transmettez plusieurs types de détails dans une même requête, une erreur se produit.

En général, le paramètre data peut être un URI ou une combinaison de type MIME et d'octets encodés en base64 au format "data:<MIME-TYPE>;base64,<BASE64-ENCODED-BYTES>". Pour obtenir la liste complète des types MIME, consultez GenerateContent. Pour en savoir plus sur l'encodage en base64 d'OpenAI, consultez sa documentation.

Pour connaître les cas d'utilisation, consultez nos exemples d'entrées multimodales.

Paramètres spécifiques à Gemini

Plusieurs caractéristiques compatibles avec Gemini ne sont pas disponibles dans les modèles OpenAI. Celles-ci peuvent toujours être transmises en tant que paramètres, mais doivent être contenues dans un extra_content ou un extra_body. Dans le cas contraire, elles seront ignorées.

Fonctionnalités extra_body

Incluez un champ google pour contenir toutes les fonctionnalités extra_body spécifiques à Gemini.

{
  ...,
  "extra_body": {
     "google": {
       ...,
       // Add extra_body features here.
     }
   }
}
safety_settings Cela correspond à l'élément Gemini SafetySetting.
cached_content Cela correspond au champ generateContent.cached_content de Gemini.
thinking_config Cela correspond à l'élément Gemini GenerationConfig.ThinkingConfig.
thought_tag_marker Permet de séparer les réflexions d'un modèle de ses réponses pour les modèles à raisonnement.
Si cet élément n'est pas spécifié, aucun tag n'est renvoyé pour les réflexions du modèle. S'il l'est, les requêtes suivantes supprimeront les tags de réflexion et marqueront les réflexions de manière appropriée pour le contexte. Cela permet de conserver le contexte adéquat pour les requêtes suivantes.
stream_function_call_arguments Diffuse les arguments d'appel de fonction sous forme de segments JSON. Pour en savoir plus, consultez Diffuser des arguments d'appel de fonction.
tools Spécifiez des outils semblables à `GenerateContent`. Pour en savoir plus, consultez Tool.
media_resolution Spécifiez une résolution de média au niveau de la requête semblable à `GenerateContent`. Pour en savoir plus, consultez MediaResolution.

Fonctionnalités extra_content

extra_content vous permet de spécifier du contenu spécifique à Gemini qui ne doit pas être ignoré.

Incluez un champ google pour contenir toutes les fonctionnalités extra_content spécifiques à Gemini.

{
  ...,
  "extra_content": {
     "google": {
       ...,
       // Add extra_content features here.
     }
   }
}
thought Ce champ indique explicitement si un champ est une réflexion et est prioritaire sur thought_tag_marker. Il permet de distinguer les différentes étapes d'un processus de réflexion, en particulier dans les scénarios d'utilisation d'outils où les étapes intermédiaires étapes peuvent être confondues avec des réponses finales. En taguant des parties spécifiques de l' entrée comme des réflexions, vous pouvez guider le modèle pour qu'il les traite comme un raisonnement interne plutôt que comme des réponses destinées à l'utilisateur.
thought_signature Champ d'octets qui fournit une signature de réflexion à valider par rapport aux réflexions renvoyées par le modèle. Ce champ est différent de thought, qui est un champ booléen. Pour en savoir plus, consultez Signatures de réflexion.
parts Spécifique à un message d'outil pour renvoyer des parties de réponse de fonction multimodale au modèle. Pour en savoir plus, consultez FunctionResponsePart et Réponse de fonction multimodale.

Étape suivante