Gemini 系列接入中转：Pro / Flash / Flash-Lite 三档怎么选

三档的定位差异

关键判断：三档之间的差异，在简单任务上几乎看不出来。所以选择依据不该是「哪个更强」，而是「我的任务在哪一档上开始出现质量不足」。

实用的测试方法：拿你真实的 20 条任务，先在 Flash-Lite 上跑，记录不合格的比例 → 换 Flash 再跑 → 换 Pro。第一个让你合格率超过可接受线的档位，就是你的答案。 这比看任何 benchmark 都准。

四条选择线

一、任务复杂度

• 分类、抽取、格式转换、改写：Flash-Lite 通常够用。这类任务的正确答案是确定的，不需要强推理。
• 摘要、问答、代码生成：Flash 起步。
• 多步推理、复杂代码重构、长文档交叉引用：Pro。

二、延迟敏感度

这是一条经常被忽略但影响很大的线：

• Flash-Lite 的首 token 延迟明显低于 Pro；
• 在交互式场景（代码补全、实时对话、Agent 循环）中，延迟的影响往往大于能力差异 —— 因为 Agent 每一步都在等，累积起来很可观。

经验法则：如果一次用户操作背后有 5 次以上模型调用，把延迟权重调高，优先选低延迟档。

三、上下文长度需求

Gemini 系列的长上下文是它的传统优势。但要注意三点：

1. 不同档位的上下文上限不同，不是全系一致；
2. 长上下文意味着大请求体，容易撞上反代体积限制（见本站《上下文长度与截断》）；
3. 长上下文的处理时间显著更长，容易撞上超时。

所以：真正需要长上下文时，先确认这条链路上每一环的上限（客户端 → 中转站 → 上游），再决定用哪一档。

四、成本

三档之间的价格差异可以达到一个数量级。所以在批量任务上，档位选择对总成本的影响远大于「谈折扣」。

一个务实的做法：批量任务默认走最低档，只对失败的样本升级重跑。 抽样 5%–10% 人工复核质量即可。

通过中转接入 Gemini 的四个注意点

1. 协议形态

Gemini 原生协议与 OpenAI 格式差异较大。中转站通常提供两种形态：

• OpenAI 兼容端点：/v1/chat/completions，模型名写 gemini 系列；
• Gemini 原生端点：/v1beta/models/...:generateContent（少数站提供）。

建议用哪一种：如果你的代码已经基于 OpenAI SDK，用兼容端点，减少改动。但要注意——OpenAI 格式下的多模态、工具调用转换质量差异很大（见下两条）。

2. 多模态传法

Gemini 原生支持图片、音频、视频输入。但通过 OpenAI 兼容端点时：

• 图片输入通常可以透传（OpenAI 也有 image_url 格式）；
• 音频与视频输入基本走不通，因为 OpenAI 格式没有对应的字段。

所以：如果需要音频/视频输入，必须确认站方是否提供 Gemini 原生端点。

3. 工具调用的转换质量

Gemini 的函数调用结构（functionDeclarations）与 OpenAI（tools）差异较大。经中转转换后，可能出现：

• 多轮调用时上下文丢失；
• 参数类型漂移（数字变字符串）。

必测：用本站《函数调用兼容性》一篇里的四个用例跑一遍。

4. 模型命名

Gemini 的版本命名比较混乱（带 -preview、-exp 后缀的变体很多），而不同中转站收录的变体不同。

做法：以 /v1/models 返回的清单为准，不要用官方文档里的名字。

一个选型结论

默认起步档：Flash。

理由：它是「能力足够 + 成本可控 + 延迟可接受」的交点。先用它跑通全流程，再针对具体环节做上下调整 —— 而不是一开始就选最高档，那样你既不知道钱花在哪，也不知道降档会损失什么。

Flash-Lite 的正确用法不是「替代 Flash」，而是「承接那些不需要强能力的批量任务」。 把这两者的边界划清楚，成本能降得很明显，而体验基本无感。