周三早上六点二十六分（美东时间），Gemini 突然不答话了。
你打开 App，敲完一行字，回来的不是答案，是两个干巴巴的错误码——1076 和 1099。换个浏览器、退出重登、清缓存，全没用。这一卡，卡了六个多小时。
这可能是 Gemini 上线以来最大的一次宕机。
先说发生了什么
按 Tom’s Guide 和 TechRadar 的实时追踪，故障从美东时间 6 月 10 日早 6:26 开始（太平洋时间 3:26）。Downdetector 上的报障曲线几乎同时往上窜，美国地区峰值一度到 765 单，全球累计到下午已经是几千单。
波及的国家至少九个：美国、英国、意大利、葡萄牙、泰国、希腊、波黑、法国、比利时。受影响的月活用户，超过 4 亿。
有意思的是，不是整个 Gemini 全趴下。
| 模型 | 状态 |
|---|---|
| Gemini Pro | 基本打不开 |
| Gemini Flash | 基本打不开 |
| Gemini Flash Lite | 时断时续，偶尔能答 |
承接日常流量最大的 Pro 和 Flash 全废了，反倒是最轻量的 Flash Lite 还能喘口气。这个分布本身就说明，坏的不是某个模型，是它们共用的那层后端。
那两个错误码到底是什么
Google 没把话说全，但报道里把两个码拆开了：
- 错误 1076：连接握手超时。请求没能在规定时间内跟后端建立起安全链路——说白了就是排队排到超时，重发一次往往就过了。
- 错误 1099：服务端的会话冲突，或者上下文塞爆了。这个跟你的手机、网络都没关系，纯粹是 Google 那头的问题。
两个码指向的是同一个地方：Gemini 处理回复的那套基础设施。请求还没走到「生成答案」这一步，就先在门口挂了。
Google 说了什么，又没说什么
整个过程里，Google 的官方口径基本就一句车轱辘话：工程团队「还在排查根因」，并且「向所有受影响的用户致歉」。
到了 6 月 11 日凌晨，服务陆续恢复。Google 补了一句，说后端数据库的一个性能问题影响了 Gemini 工具目录的读取，现在已经修好了。
但真正的根因——是发版翻车、底层硬件故障，还是算力被打满——到现在没有一个像样的复盘。
这才是问题。
为什么一次宕机值得单独说
放在两年前，一个聊天机器人挂半天，顶多算个小新闻。现在不一样了。
Gemini 早就不只是个对话框。它绑进了 Android、塞进了 Workspace、接进了搜索，是几亿人每天干活、查资料、写邮件的入口。这种东西一旦停摆六小时，影响的不是「今天没法跟 AI 聊天」，是一整条工作流断在半路。
ChatGPT 今年也宕过三个小时，OpenAI 同样没把原因讲清楚。两家头部公司，半年内先后栽在「可靠性」和「透明度」这两件事上——这不是巧合。
模型越做越聪明，跑分一个比一个高。但用户最先感知到的，从来不是多答对了一道题，而是「我要用的时候它在不在」。
一个被反复忽略的常识
AI 公司很爱讲参数、讲上下文长度、讲 benchmark。可对接进生产系统的企业来说，SLA（服务可用性承诺）才是签合同时真正盯的那一栏。
一个跑分领先但每个月崩一次的模型，和一个跑分差几分但全年几乎不掉线的模型，企业 IT 会选哪个，答案其实不用猜。
这次 Gemini 的六小时，给所有把鸡蛋放进一个篮子的用户提了个醒：你依赖的那个 AI，背后是一套和别的云服务一样会出故障的系统。它不会因为叫「人工智能」就更不容易坏。
下一次轮到谁，只是时间问题。
参考来源：Google Gemini Outage Tops Six Hours, Errors 1076 and 1099 Worldwide（Tech Times）；Google Gemini was down — live outage updates（Tom's Guide）；CocoLoop、Is Google Gemini down for you?（TechRadar）；Gemini not working for you? You're not alone（Android Authority）