Skip to main content
POST
Gemini OpenAI 格式(对话)
若使用 Google Gemini 原生协议,请参见 原生 Gemini 格式。通用多模型 Chat Completions 说明见 原生 OpenAI 格式(ChatCompletions)
路径:POST https://api.gravitex.ai/v1/chat/completions

1. 模型分类


2. 请求路径与认证


3. 标准 OpenAI 字段 → Gemini 映射

messages.content 支持多模态数组(OpenAI v2):
  • type:"text"parts[].text
  • type:"image_url" / type:"input_audio" / type:"file" → 由系统下载/解码后塞进 parts[].inlineData,并按 MIME 校验白名单:
    • 图片:image/pngimage/jpegimage/jpgimage/webpimage/heicimage/heif
    • 音频:audio/mpegaudio/mp3audio/wav
    • 视频:video/mp4video/movvideo/mpegvideo/mpgvideo/avivideo/wmvvideo/mpegpsvideo/flv
    • 文档:application/pdftext/plain
  • content 字符串里夹的 ![alt](data:image/...;base64,...) Markdown 图片会被识别并拆成独立 inlineData part(与 type:"image_url" 等价)。

4. tools 透传

三个特殊名称会被识别成 Gemini 原生工具开关,其它 function 走标准 functionDeclarations。

5. extra_body — 完全透传 Gemini 原生参数

extra_body.google.* 命名空间下的所有字段都会透传给 Gemini 原生 API。

5.1 两条透传路径

5.2 thinking_config(snake_case 白名单)

只要传了 extra_body.google,系统自动的思维链适配会关闭,全部 thinking 行为由调用方掌控。

5.3 完全透传合并规则

  • extra_body.google(剔除上面 1 个 snake_case key)作为 patch。
  • 把已经根据 OpenAI 字段构造好的 Gemini 请求作为 base。
  • deep merge
    • 相同 key 两边都是 map → 递归合并;
    • 其它类型(标量、数组、null)→ patch 直接覆盖 base;
    • patch 中不存在的 key 保留 base 原值。
  • 合并后直接作为上游请求体发送,效果等同于”原生 Gemini 调用”。
含义:你可以用 extra_body.google.generationConfig.maxOutputTokens 覆盖通过 OpenAI 字段 max_tokens 设置的值,也可以用 extra_body.google.safetySettings 完全替换平台默认安全设置,新增 Gemini 字段(如未来上线的字段)无需改代码即可直接使用。

5.4 透传示例


6. 响应格式

6.1 非流式 chat.completion

  • id = 上游 responseId(与日志 request_id 一致,便于排查问题),上游缺 responseId 时回退到 chatcmpl-* 格式。
  • reasoning_content:思考过程的文本内容(仅 include_thoughts:true 时才会返回)。
  • executable_code / code_execution_result:自动转成 markdown 代码块嵌入在 text 里。
  • 非图片媒体(音频等):以 markdown [media](data:...) 形式嵌入在 text 里。
  • finish_reason 映射:STOP→stopMAX_TOKENS→lengthSAFETY/RECITATION/PROHIBITED_CONTENT/...→content_filter、有 functionCalltool_calls

6.2 流式 chat.completion.chunk

  • 流式响应中 delta.content 是字符串(不是数组)。
  • 图片以 ![image](data:image/png;base64,...) markdown 形式嵌入 delta.content
  • id 在流式响应中保持一致。

7. usage 用量

response.usage 完整字段:

7.1 思考 token 怎么算

  • reasoning_tokens 单独显示,方便查看思考消耗。
  • completion_tokens 包含 reasoning_tokens(OpenAI 标准语义,扣费按 completion_tokens)。

7.2 输出 token 归类

系统会根据实际输出内容自动归类 token 类型:
归类基于实际输出内容,而非模型名——即使模型名含 “image”,纯文本回答仍按文本计费。

7.3 modality 大小写处理

系统自动兼容 "image" / "IMAGE" 等不同大小写写法。

8. 日志与对账

平台会为每个请求记录上游的 token 用量信息,可在日志中查看:
  • responseIdresponse.id 完全一致,也与日志的 request_id 一致,方便排查问题。

9. 完整调用示例

9.1 纯文本对话(开 thinking)

9.2 多模态输入(文本 + 图片 URL)

9.3 启用 Google 搜索 + URL 上下文

9.4 流式对话


10. OpenAI 独有参数(Gemini 无对应,传了会被忽略)

以下 OpenAI 标准参数在 Gemini API 中没有对应字段,传入后会被静默丢弃,不会报错:

11. Q&A — 思维链(Thinking / Reasoning)控制

Q1:用 OpenAI 格式调用时,能控制 Gemini 的思维链长度吗?

可以。 有两种方式:

方式一:reasoning_effort(OpenAI 标准字段,最简单)

直接传 OpenAI 的 reasoning_effort 参数,系统自动转成 Gemini 的 thinking 配置:
映射规则(自动处理):

方式二:extra_body.google.thinking_config(最灵活,完全控制)

Gemini 3 系列用 thinking_level 代替 thinking_budget
优先级extra_body.google.thinking_config > reasoning_effort。传了 extra_body.google 后系统自动的思维链适配会关闭,所有 thinking 行为完全由调用方控制。

Q2:思维链的输出怎么拿?

设了 include_thoughts: true 后,思考过程会放在响应的 reasoning_content 字段:
流式响应中,思考内容通过 delta.reasoning_content 增量返回。

Q3:Gemini 2.5 和 Gemini 3 的 thinking 有什么区别?


12. 已知限制


13. 调试 / 排错快速索引