將 OpenAI 程式庫與 Gemini Enterprise Agent Platform 搭配使用

Chat Completions API 是與 OpenAI 相容的端點，可讓您在 Gemini Enterprise Agent Platform 上，使用 OpenAI 的 Python 和 REST 程式庫，輕鬆與 Gemini 互動。如果您已使用 OpenAI 程式庫，可以透過這個 API，以低成本的方式切換呼叫 OpenAI 模型和 Agent Platform 託管模型，比較輸出內容、成本和擴充性，而不必變更現有程式碼。如果您尚未開始使用 OpenAI 程式庫，建議您使用 Google Gen AI SDK。如要將現有的 OpenAI SDK 程式碼遷移至 Google Gen AI SDK，請參閱「從 OpenAI SDK 遷移至 Google Gen AI SDK」。

支援的模型

Chat Completions API 支援 Gemini 模型，以及 Model Garden 中選取的自行部署模型。

Gemini 模型

下列模型支援 Chat Completions API：

按一下即可展開支援的模型

從 Model Garden 自行部署的模型

Hugging Face Text Generation Interface (HF TGI) 和 Agent Platform Model Garden 預先建構的 vLLM 容器支援 Chat Completions API。不過，並非所有部署至這些容器的模型都支援 Chat Completions API。下表列出各容器最常用的支援模型：

HF TGI

vLLM

支援的參數

Chat Completions API 支援下列 Google 模型的 OpenAI 參數。如需各項參數的說明，請參閱 OpenAI 的「建立對話完成內容」說明文件。第三方模型支援的參數因模型而異。如要查看支援的參數，請參閱模型說明文件。

messages
  • System message
  • User message：支援 text 和 image_url 類型。image_url 類型支援儲存在 Cloud Storage URI 中的圖片，或採用 "data:<MIME-TYPE>;base64,<BASE64-ENCODED-BYTES>" 格式的 base64 編碼。如要瞭解如何建立 Cloud Storage bucket 並上傳檔案，請參閱「探索物件儲存庫」。
  • Assistant message
  • Tool message
  • Function message：這個欄位已淘汰，但為了回溯相容性仍提供支援。
model
detail 如果是 Gemini 3 之前的模型，所有訊息和內容的 detail 欄位必須一致 (這是要求層級)。在 Gemini 3 以上版本，這會對應至部分層級的 `media_resolution`。詳情請參閱「媒體解析度」。
max_completion_tokens max_tokens 的別名。
modalities 支援 audio、image 和 text。
max_tokens
n
frequency_penalty
presence_penalty
reasoning_effort 設定回覆所用的時間和詞元數量。
  • low：1024
  • medium：8192
  • high：24576
由於回覆不含思考過程，因此只能指定 reasoning_effort 或 extra_body.google.thinking_config 其中之一。
response_format
  • json_object：解讀為將「application/json」傳遞至 Gemini API。
  • json_schema。 系統不支援完全遞迴的結構定義。支援 additional_properties。
  • text：解讀為將「text/plain」傳遞至 Gemini API。
  • 任何其他 MIME 類型都會原封不動地傳遞至模型，例如直接傳遞「application/json」。
seed 對應至 GenerationConfig.seed。
stop
stream
temperature
top_p
tools
  • type
  • function
    • name
    • description
    • parameters：使用 OpenAPI 規格指定參數。這與 OpenAI 參數欄位不同，後者會描述為 JSON 結構定義物件。如要瞭解 OpenAPI 和 JSON 結構定義之間的關鍵字差異，請參閱 OpenAPI 指南。
tool_choice
  • none
  • auto
  • required：對應 FunctionCallingConfig 中的模式 ANY。
  • validated：對應 FunctionCallingConfig 中的模式 VALIDATED。這是 Google 專屬功能。
web_search_options 對應至 GoogleSearch 工具。不支援子選項。
function_call 這個欄位已淘汰，但為了回溯相容性，系統仍支援此欄位。
functions 這個欄位已淘汰，但仍支援回溯相容性。

如果傳遞任何不支援的參數，系統會忽略該參數。

多模態輸入參數

Chat Completions API 支援特定多模態輸入。

input_audio
  • data: 任何 URI 或有效 Blob 格式。我們支援所有 Blob 類型，包括圖片、音訊和影片。只要是 GenerateContent 支援的項目，都在支援範圍內 (HTTP、Cloud Storage 等)。
  • format:OpenAI 同時支援 wav (audio/wav) 和 mp3 (audio/mp3)。使用 Gemini 時，系統支援所有有效的 MIME 類型。
image_url
  • data: 與 input_audio 類似，支援任何 URI 或有效 Blob 格式。
    請注意，如果 image_url 是網址，預設會是 image/* MIME 類型， 如果 image_url 是 Blob 資料，則可做為任何多模態輸入內容。
  • detail:與媒體解析度類似，這項設定會決定要求中每張圖片的權杖數量上限。請注意，OpenAI 的欄位是依圖片設定，Gemini 則會對整個要求強制執行相同的詳細程度，在單一要求中傳遞多個詳細程度類型會擲回錯誤。

一般來說，data 參數可以是 URI，也可以是 MIME 類型和 Base64 編碼位元組的組合，格式為 "data:<MIME-TYPE>;base64,<BASE64-ENCODED-BYTES>"。如需 MIME 類型的完整清單，請參閱 GenerateContent。如要進一步瞭解 OpenAI 的 base64 編碼，請參閱相關說明文件。

如需使用方式，請參閱多模態輸入範例。

Gemini 專屬參數

Gemini 支援多項 OpenAI 模型不具備的功能。這些功能仍可做為參數傳遞，但必須包含在 extra_content 或 extra_body 中，否則系統會忽略這些功能。

extra_body 項功能

加入 google 欄位，內含任何 Gemini 專屬功能。extra_body

{
  ...,
  "extra_body": {
     "google": {
       ...,
       // Add extra_body features here.
     }
   }
}
safety_settings 這對應於 Gemini SafetySetting。
cached_content 這對應於 Gemini generateContent.cached_content 欄位。
thinking_config 這對應於 Gemini GenerationConfig.ThinkingConfig。
thought_tag_marker 如果模型支援「思考」功能，這項設定可將模型的想法與回覆分開。
如未指定，系統不會傳回模型想法周圍的標記。如果存在，後續查詢會移除思考標記，並根據情境適當標記思考。這有助於保留後續查詢的適當情境。
stream_function_call_arguments 以 JSON 區隔的形式，串流傳回函式呼叫引數。詳情請參閱「 串流函式呼叫引數」。
tools 指定類似 `GenerateContent` 的工具。詳情請參閱 Tool。
media_resolution 指定類似於 `GenerateContent` 的要求層級媒體解析度。詳情請參閱 MediaResolution。

extra_content 項功能

extra_content 可讓您指定不應忽略的 Gemini 專屬內容。

加入 google 欄位，內含任何 Gemini 專屬功能。extra_content

{
  ...,
  "extra_content": {
     "google": {
       ...,
       // Add extra_content features here.
     }
   }
}
thought 這個欄位會明確標示欄位是否為想法，且優先順序高於 thought_tag_marker。這有助於區分思考過程中的不同步驟，尤其是在工具使用情境中，中間步驟可能會被誤認為最終答案。只要將輸入內容的特定部分標記為思考，就能引導模型將這些內容視為內部推論，而非面向使用者的回覆。
thought_signature 這個位元組欄位會提供思維簽章，用來驗證模型傳回的思維。這個欄位與布林欄位 thought 不同。詳情請參閱「想法簽章」。
parts 專用於工具訊息，將多模態函式回覆部分傳回模型。 詳情請參閱「 FunctionResponsePart」和「多模態函式回覆」。

後續步驟