Gemini 专项 共 1 家

Gemini 系列的优势在长上下文与多模态。百万级 token 的上下文窗口让「整份代码库丢进去」或「长视频直接分析」成为可能，这是另外两家暂时不好替代的能力。

这一类站点的关键差异是「长上下文是不是真的」。窗口大小写在文档里容易，但要真按百万 token 处理，对上游通道和计费都有要求。测试方法很直接：喂一份接近上限的长文档，看它是否完整处理、以及是否在某个长度之后悄悄截断。

多模态能力同理。宣传页说支持图片/视频/音频理解，实际能不能用要用真实素材验证，尤其视频输入对通道要求更高，部分站点会用「暂不支持」的方式静默失败。

还有一个实际问题是计费口径。长上下文请求的 token 量很大，如果站点在中间做了一次转发导致缓存失效，同样的对话反复发送会显著推高费用。长文档场景建议优先选支持上下文缓存的站点。

• 要最稳的：按当前可用率排序取最高。样本数越少越可能失真，本站标注了数据来源（公开数据集 / 本站实测），可点进详情页核对。
• 要响应最快的：按最近一次探测的首页响应时间排序。单次测量波动较大，更适合当作参考区间而不是绝对值。

百万 token 上下文，中转站能完整支持吗？

不一定。有些站点虽然列出 Gemini Pro，但对输入长度设了较低的实际上限，超出后返回错误或静默截断。验证方法是拿一份接近标称上限的长文档测试，并在文档中埋入只有读完才能回答的问题，看答案是否正确。

Gemini Flash 和 Pro 该怎么选？

按任务复杂度分。Flash 便宜且快，适合分类、抽取、格式转换这类结构化任务；Pro 适合需要推理与长上下文理解的场景。实际做法是先用 Flash 跑一遍，只在效果不达标的那部分流量上换 Pro，这样成本最优。

视频、音频输入在中转站上可靠吗？

比图片输入的不确定性高。图片支持较普遍，视频音频只有部分站点实现。如果你依赖这类能力，建议先用真实素材做一轮完整测试，不要仅依据功能列表就投入开发。

长上下文场景下，怎么控制成本？

关键是让上下文缓存生效，把固定不变的长文档放在请求前部、变动内容放后部 —— 这与官方建议一致，也依赖中转站是否透传缓存字段。本站详情页会标注该站的接口探测结果，可作为筛选起点。