知识卡片：DeepSeek宕机近5小时，按API用量发放补偿

一句话结论

DeepSeek 网页与 API 在早间发生近 5 小时的大面积不可用，官方定位原因并修复后，按用户过去 7 天 API 用量发放赠送余额作为补偿。

事件概述或研究问题

• 时间线：早上 8 点左右，DeepSeek 网页和 API 大面积不可用；9 点左右官方称已定位原因；12 点 50 分左右完成修复，整体持续近 5 小时。
• 受影响范围：对话服务、V4 Pro API、V4.1 Flash API 均受影响。
• 后续处置：当日下午官方向 API 用户发放赠送余额，计算依据为过去 7 天 API 使用量；有网友晒出获得 300 多元。

方法/产品要点

• 涉及产品面：DeepSeek 对话服务（网页端）与两类 API（V4 Pro、V4.1 Flash）。
• 补偿机制：不与单次故障时长直接挂钩，而是以“过去 7 天 API 使用量”为基数发放赠送余额，属于按历史用量比例回馈的思路。
• 故障处置节奏：先定位原因（约 1 小时内），再进行修复，最终在中午前后恢复。

主要结果或产业意义

• 结果：服务在约 5 小时后恢复；API 用户获得与历史用量挂钩的赠送余额补偿。
• 产业意义：对以 API 为主要收入与依赖形态的模型厂商而言，宕机不只是可用性问题，还直接牵动开发者信任与迁移成本；用“按用量补偿”而非统一额度，体现对重度用户的差异化安抚。待核实：本次故障的具体技术根因、受影响用户规模与补偿总金额。

为什么重要

• 与既有脉络的关系：本卡片与“DeepSeek 后台通知上调 API 定价，预计涨幅较大”构成同一厂商的连续事件线索——一边是价格与算力资源分配的调整信号，一边是服务稳定性出现缺口，两者共同指向算力供给压力这一背景。本条增量信息在于：把“算力紧张”的推测，落到一次具体的服务中断与用户补偿动作上。
• 对开发者而言，模型选型不只比较价格与能力，还要评估可用性历史与故障补偿政策。

局限与不确定性

• 故障根因、是否与算力紧张或扩容/调价相关：待核实。
• 受影响用户数量、地域分布、是否全部恢复：待核实。
• 补偿覆盖范围（是否覆盖非 API 的对话服务用户）、发放总额：待核实。
• “有网友晒出获得 300 多元”属个案展示，不能代表整体补偿水平：待核实。

可用于图书/PPT/简报的角度

• “模型厂商的服务等级”：从价格战转向稳定性与补偿机制的竞争维度。
• 案例对照：一次宕机 + 一次按用量补偿，作为“AI 基础设施可靠性”章节的实例。
• 开发者视角：多模型冗余与降级策略的必要性。
• 时间线图示：8:00 故障 → 9:00 定位 → 12:50 修复 → 下午补偿。

原始材料

• 来源：腾讯研究院AI速递 20261016
• 标题：腾讯研究院AI速递 20261016
• URL：https://m.sohu.com/a/1088289922_455313?scm=10001.325_13-325_13.0.0-0-0-0-0.5_1334&digest_item=6
• 条目：七、DeepSeek宕机近5小时，按API用量发放补偿
• 英文关键词：DeepSeek, API outage, compensation, V4 Pro, V4.1 Flash