一行 " 服务器暂时不可用 "，卡住了 10 月 15 日周四早高峰里无数工位上的人。

四个多小时后服务才恢复，又过了几个小时，DeepSeek 的傍晚回应来了——过去一周你在 API 上花掉的钱，全额退。

10 月 15 日傍晚，DeepSeek 开放平台在用量信息页挂出《服务恢复及补偿通知》。方案给得相当直接：按账号 7 日内（10 月 8 日至 10 月 14 日）的消耗金额，以赠金形式全额返还，赠金自动到账、无需申请，后续 API 计费扣款优先从赠金账户扣除。对开发者来说，这等于过去一周的调用白用了一遍。通知里两次致歉，称已第一时间启动针对服务稳定性的全面排查和彻底整改，全面梳理并剥离单点依赖，" 坚决杜绝同类问题再次发生 "。

通知发出后，社交平台上陆续有人晒出到账截图，金额差距相当大：上周只零星调用几次的，到账几毛、几元；用量大的拿到几百元，个别用户的补偿超过 1000 元。

这笔钱对应的是当天上午那场几乎贯穿整个办公高峰的停摆。官方服务状态页记录得很清楚：故障从 8 时 11 分开始，受影响组件包括对话服务、DeepSeek V4 Pro API、DeepSeek V4.1 Flash API 及另外 1 个组件；9 时 06 分更新为 " 已定位原因，正在实施修复 "，两分钟后对话服务转为完全中断；12 时 49 分 " 已实施修复，正在监控结果 "；13 时 04 分 " 本次问题已解决，服务已恢复 "。从 8 点 11 分到 13 点 04 分，中断时长 4 小时 52 分钟。"DeepSeek 崩了 " 的话题，也随之冲上微博热搜。

定位只用了不到一小时，修复却耗掉四个多小时。快思慢想研究院院长田丰在接受澎湃科技采访时解释，大模型服务重启一次本身就相当于一次小型发布，要重新加载权重、预热、再逐步放流量，缓存重建还会带来二次冲击；更麻烦的是修复过程正撞上早高峰，用户发现卡顿后反复点击 " 重试 "，访问量被成倍放大，维护难度随之上升。一位 AI 云计算服务商高管则直言，除了算力紧张，运维工程建设也不完善，测试、预发布、灰度升级、回退机制这一整套 SOP，还没跟上研究型团队的迭代速度。

这也不是 DeepSeek 今年第一次 " 掉链子 "。官方事件日历显示，9 月 2 日和 9 月 15 日均出现过网页和 API 部分中断，10 月 12 日出现部分网页中断，9 月以来另有 9 次 " 网页和 API 性能下降 " 的记录。有媒体统计，今年以来 DeepSeek 至少已发生 18 次大面积服务异常，平均每月一到两次。7 月，DeepSeek 还专门推出峰谷定价，高峰时段 API 价格是闲时的一倍，官方理由是更合理地配置资源、提升稳定性，但这根价格杠杆没能拦住这次宕机。

真正让这次故障显得 " 贵 " 的，是它发生的时间段，完整覆盖了 9 时至 12 时的高峰计价时段，损失的是全天最忙的三个小时。OpenRouter 数据显示，10 月 15 日当周，DeepSeek V4.1 Flash 仍是全球调用量最高的模型，即便宕机当天调用量下滑 11%，依然排第一。当 AI 越来越像一位干活的员工，宕机也就越来越像停工：智能体跑到一半被中断，上下文状态、改了一半的文件、执行到一半的工具链，都可能要从头再来。开源社区 OpenCSG 当天就提醒，外部推理服务正在变成企业业务的一项依赖，这次故障让这种依赖变得具体。

耐人寻味的是，宕机当天上午，排在 OpenRouter 榜单第二的阶跃星辰，正好宣布正式开源旗舰基座模型 Step 5 Preview 完整权重。一边是对手放量开源，一边是自己的服务器 " 繁忙 "。

截至发稿，DeepSeek 并未披露此次故障的具体原因。赠金已经到账，服务也早已恢复，只是那个上午被卡住的几个小时，退不回来了。

来源：星河商业观察