Gemini OpenAI 格式(对话)
对话与文本
Gemini OpenAI 格式(对话)
用 OpenAI 兼容 /v1/chat/completions 调用 Gemini 对话与多模态模型
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[].texttype:"image_url"/type:"input_audio"/type:"file"→ 由系统下载/解码后塞进parts[].inlineData,并按 MIME 校验白名单:- 图片:
image/png、image/jpeg、image/jpg、image/webp、image/heic、image/heif - 音频:
audio/mpeg、audio/mp3、audio/wav - 视频:
video/mp4、video/mov、video/mpeg、video/mpg、video/avi、video/wmv、video/mpegps、video/flv - 文档:
application/pdf、text/plain
- 图片:
content字符串里夹的Markdown 图片会被识别并拆成独立inlineDatapart(与type:"image_url"等价)。
4. tools 透传
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→stop、MAX_TOKENS→length、SAFETY/RECITATION/PROHIBITED_CONTENT/...→content_filter、有functionCall→tool_calls。
6.2 流式 chat.completion.chunk
- 流式响应中
delta.content是字符串(不是数组)。 - 图片以
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 用量信息,可在日志中查看:responseId与response.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(最灵活,完全控制)
thinking_level 代替 thinking_budget:
优先级:extra_body.google.thinking_config>reasoning_effort。传了extra_body.google后系统自动的思维链适配会关闭,所有 thinking 行为完全由调用方控制。
Q2:思维链的输出怎么拿?
设了include_thoughts: true 后,思考过程会放在响应的 reasoning_content 字段:
delta.reasoning_content 增量返回。
