Google Gemini 发布后，讨论集中在三点：Ultra、Pro、Nano 到底谁开放了；Bard 换成 Gemini Pro 后为什么还是不好用；自评基准分数能不能信。本文梳理版本差异、实测问题的成因，给出 API 接入路径、合规注意事项和一份上手前的检查清单。
Google 发布 Gemini 之后，开发者的第一波反应并不是惊叹，而是三个很实际的问题：哪一版现在能用？Bard 里跑的到底是不是它？那些漂亮的基准分数比的是什么？
试用者很快发现体验存在落差：一边是演示视频里近乎电影级的推理与多模态能力，另一边是实际对话中动不动“我只是一个语言模型”、上下文中途串味、甚至把自家架构和参数量说错。本文把这些反馈归拢一下，讲清版本关系，解释实测“翻车”的技术原因，并给出开发者的接入路径与取舍。
版本先分清：Ultra、Pro、Nano 不是同一个东西
发布时公布的是三档尺寸，它们的定位和可用时间完全不同，很多争论其实源于把三者混为一谈。
| 版本 | 定位 | 典型场景 | 当时的可用状态 |
|---|---|---|---|
| Ultra | 旗舰，能力最强 | 复杂推理、高难度多模态任务 | 发布时未对外开放，官方称后续通过更高级的消费端订阅与云服务提供 |
| Pro | 主力通用模型 | 通用文本、代码、API 调用 | 已接入 Bard（英文为主），并通过 Gemini API 与 Vertex AI 向开发者开放 |
| Nano | 端侧小模型 | 手机等本地设备 | 面向设备厂商，走端侧集成路线 |
所以“Gemini 不如 GPT-4”这类判断必须先加限定词：多数人当时能摸到的只有 Pro 和 Bard 里的那一版。官方口径是 Ultra 在部分基准上超过 GPT-4，从未说过 Pro 也超过；把 Pro 的体验当成 Ultra 的水平来评价，结论自然会失真。Ultra 的具体开放时间与形态，务必以官方最新公告为准，讨论中出现的“推迟到明年”“要走订阅收费”都只是当时的推测。
Bard 实测为什么感觉明显不如预期
试用反馈里最集中的几类问题，其实都有比较清楚的技术解释，不完全是“谷歌不行了”。
模型对自己版本的描述不可信
有人问 Bard 用的是什么模型，它回答“我是 Ultra 版本，参数量 1.6 万亿，采用 GAN 架构”。这几乎全是编的：Gemini 并非 GAN 架构，参数量也不是模型自报的数字。
原因在于，模型不知道自己被部署成哪一版、叫什么名字。身份信息来自系统侧注入的提示词，属于上下文，不在模型权重里；一旦被追问细节，模型只能按训练语料中“模型自我介绍”的模板去补全。同理，问它“你和另一个模型什么关系”，它会一本正经地编出一套分工协作的说法。这条经验对所有大模型都适用：永远不要把模型的自述当作事实来源。
会话状态与对齐策略带来的干扰
- 上下文串味：连续多轮对话里，前面话题的实体被带进后面的回答，说明会话管理或上下文拼接策略偏激进。
- 过度保守：频繁触发“我只是一个语言模型”式的兜底话术，是多层安全对齐叠加的结果，代价是可用性下降。
- 联网不等于核实：挂了搜索能力，只代表能检索，不代表会把检索结果严格约束在回答里。检索结果与参数记忆冲突时，仍可能出现“瞎说”。
期望值来自演示，而不是产品
精心挑选的 show case 与面向全量用户的通用对话产品，中间隔着一整层工程调优。前者展示的是能力上限，后者体现的是平均水平。对比时把对手的“生产可用状态”拿来比自己的“演示状态”，落差感会被放大。
基准分数的对比对象，比分数本身更重要
关于“Gemini 超过 GPT-4”的争论，有价值的质疑集中在两点：
- 对比的是哪一版 GPT-4。如果参照的是早期版本，而对手模型在这期间持续迭代、同一批基准上的分数已经上涨，那么“领先”的结论会随时间迅速失效。
- 评测集的透明度。厂商自选题目、自定评测流程时，存在对特定 benchmark 过拟合的空间，分数高不一定迁移到你的业务场景。
稳妥的做法是自建小评测集：从真实业务里抽 50～200 条样本，覆盖你最在意的任务（抽取、改写、代码修复、多轮追问），固定提示词与评分标准，再把候选模型跑一遍。花半天时间，比看十张榜单有用。
想真正用上：几条路径与取舍
| 路径 | 适合谁 | 说明 |
|---|---|---|
| Gemini API / AI Studio | 个人开发者、原型验证 | 上手最快，适合先跑通流程、验证提示词 |
| Vertex AI | 企业、需要 SLA 与合规审计的场景 | 走云平台账号体系，配额、计费、日志更规范 |
| 消费端对话产品 | 普通用户、轻度体验 | 以英文体验为主，能力随版本滚动更新 |
调用示例（模型 ID 与端点以官方文档为准，不要照抄占位符）：
curl -s "https://<官方端点>/v1/models/${MODEL_ID}:generateContent" \
-H "Content-Type: application/json" \
-H "x-goog-api-key: ${API_KEY}" \
-d '{"contents":[{"parts":[{"text":"把这段日志归类为 error/warn/info"}]}]}'
关于网络与地域限制：部分地区的用户直接访问会失败。这里需要提醒的是，使用共享账号、来路不明的代理服务或所谓“解锁”工具，存在账号被封、密钥泄露、请求内容被中间人记录的风险，企业场景还可能触碰数据处理合规问题。更稳妥的替代做法是通过云平台的正式企业渠道开通服务，或在自己可控的、符合服务条款的机房环境里运行调用脚本。如果只是需要一个长期在线、网络稳定的开发环境来跑 API 客户端和自动化任务，租用一台海外机房的独立机器（例如整台 Mac mini 放在新加坡机房、按月远程使用）是常见选择之一，前提是先确认目标服务的条款允许这种用法。
上手前的检查清单
- 确认你要用的是哪一档模型，端点与模型 ID 从官方文档抄，不靠记忆
- 提示词用英文先测一遍，再考虑中文
- 结构化输出（JSON 模式或 schema 约束）优先于自由文本解析
- 不向模型询问“你是哪个版本”“你有多少参数”
- 敏感数据脱敏后再发；确认数据是否会被用于训练
- 记录 token 用量与延迟，按最坏情况估算成本
- 用自建评测集对比，而不是厂商榜单
小结
Gemini 的三档模型解决的是不同问题：Pro 是当下能用的那一档，Nano 走端侧，Ultra 是能力上限的展示。Bard 的实际体验之所以让人失望，主要是身份幻觉、上下文管理与过度保守的对齐策略叠加，而不是“模型完全不行”。基准分数可以作为参考，但必须看清楚对比对象和评测集来源。
对开发者来说，合理的做法是：先用 API 跑通一条真实业务链路，用自建评测集拿到属于你自己的分数，再决定要不要把它放进生产。至于 Ultra 什么时候全面开放、以什么形式提供，等官方文档更新，别拿讨论区的猜测当排期。