DeepSeek 10-15 宕机补偿落地：10.8-10.14 消费全额返还赠金，「云 API 保险」的边界在哪

补偿落地：全额返还赠金，自动到账

官方方案有三个要素：补偿区间为 10 月 8 日至 14 日的消费、返还形式为全额赠金、到账方式为自动、抵扣规则为赠金优先抵扣。与「现金退款」相比，赠金方案对用户侧的约束是：补偿沉淀在平台账户内，继续消费才能兑现；对平台侧，这是把故障成本转化为留存锁定的标准操作。对以 API 计费接入业务系统的政企用户，赠金能抵扣后续调用，但无法覆盖故障期间已产生的业务损失——宕机约 5 小时里被阻塞的业务流程，不在补偿范围内。补偿窗口早于宕机发生日、与账单口径对齐，也体现了云服务「按账期回溯结算」的运营习惯：这不是对宕机当日的「现金流冲抵」，而是「账期级的成本修正」。

• 08:11 起中断：对话服务与 V4.1 Flash API 部分中断，至 13:04 前后恢复，持续约 5 小时；
• 补偿区间：10 月 8 日至 14 日消费，全额以赠金返还（早于宕机日，与账单口径对齐）；
• 到账方式：自动到账，赠金优先抵扣；
• 背景：新浪科技统计年内至少第 18 次重大服务中断；机悟官网此前已发《DeepSeek 年内第 18 次宕机》。

「赠金优先抵扣」的边界：云 API 保险在哪里断掉

「赠金优先抵扣」这条规则值得展开：它意味着账户中的赠金会先于现金被消耗，如果赠金已耗尽后再次发生故障，补偿逻辑可能变化——此为基于公开规则的机制推论，据报道，官方未证实（10-16 发稿时点该赠金仍有效）。叠加年内至少第 18 次重大中断的背景，「故障是小概率事件」的判断在 DeepSeek 这里不成立；而补偿方案中没有任何 SLA 条款——恢复时限承诺、赔偿上限、现金兜底均缺失。拿行业惯例做参照，「赠金」路线是「不补偿」与「现金补偿」之间的中间选项：一份真正的保险有保单（SLA 条款）、保额（赔偿上限）、承保方（平台承诺）三要素，而这次补偿方案只有「事后赠金返还」一个要素。「补偿」与「保险」之间的差距，正体现在这些缺失项上。

政企视角：赠金≠现金、SLA 缺失、本地部署的确定性

把这套补偿机制放进政企采购语境，对照项有三：其一，赠金≠现金，补偿无法进入财务对账闭环，也无法覆盖业务损失；其二，抵扣顺位与补偿逻辑可能随账户状态变化，依赖该机制做连续性规划本身就有不确定性；其三，SLA 条款整体缺失，故障恢复时长没有合同承诺。本地化部署的价值恰恰落在这些缺失项上：故障归己、数据归己，恢复时长由自有运维体系决定，不存在「赠金顺位」问题，等保三级/密评合规与国产化适配在本地环境原生满足。对已在用 DeepSeek API 的客户，务实做法是保留云 API 的同时评估本地推理兜底路径，把补偿机制当作成本参考而非连续性保障。这套补偿的窗口、形式、到账方式、抵扣顺位四个要素，今后都可以被逐项列进采购评估问卷——缺项必须书面写明。

• 三项对照：赠金≠现金（无法对账、无法覆盖业务损失），抵扣顺位可能随账户状态变化，SLA 条款整体缺失；
• 硬件基线/实测：llama.cpp + 7900 XTX 24G 单机 55+ token/s；UOS 25/麒麟 V10/欧拉适配；等保三级/密评/备案材料包交付；三年 TCO 约为云 API 1/6~1/8；
• 务实做法：保留云 API 的同时评估本地推理兜底路径，把补偿机制当成本参考而非连续性保障。