算笔账：DeepSeek补偿方案到底值不值？附权益对比

10月15日上午8点11分起，DeepSeek网页端与App同步陷入不可用，直到13点04分才宣告恢复；当晚，开放平台发布《服务恢复及补偿通知》：API用户账号过去7天（10月8日至10月14日）的消耗金额，以平台赠金形式全额返还、自动到账。结论先说：这笔补偿在费用口径上是净赚，在损失口径上不是——值不值，取决于你是不是付费API用户、以及还会不会继续用这个平台。每日经济新闻

宕机本身：近5小时，而且今年不是第一次

官方状态页的时间线是8时11分记录异常并开始排查、9时06分更新"已定位原因"、12时49分实施修复、13时04分三个组件全部恢复正常，累计中断约4小时52分钟。故障根因官方未披露，仅在通知中承诺"全面梳理并剥离单点依赖"；日活从约1.2亿涨到约2亿、同期算力储备仅增长约8.3%的媒体测算，则指向算力供需失衡的结构性压力。也不是第一次——据媒体与网友统计，2026年内DeepSeek已至少出现18次大面积服务异常，3月底一次曾超过12小时。以上均为外部统计与测算口径，没有官方数字印证。知乎知乎

第一笔账：返还率100%，停机占比2.9%

近5小时的中断，占一周168小时的比例约2.9%。若严格按"服务不可用时间"折算，退还当周费用的3%上下就已对价充分；实际方案直接返还整周消耗的100%，而且返还窗口把故障前六天正常服务的费用也一并算进。到账金额与个人用量成正比，晒出来的从几块钱到两百多元不等，公开晒图中最高的一批在三百多元。对照不少服务中断只以一纸道歉收场的先例，纯看费用，这次给得超过行业惯例。封面新闻机器之心

第二笔账：到账的是赠金，不是现金

补偿的真实价值要再打三层折扣。第一层是覆盖范围：多家媒体报道，免费网页端与App用户不在补偿之列，同样经历了宕机却"一分钱没有"，这是争议最大的一点。第二层是形态：返还的不是退款而是平台赠金，据媒体与用户反馈不能提现，只能按通知原文"API计费扣款先从赠金账户扣除"的方式抵扣后续消费。第三层是兑现条件：这笔钱只有持续使用DeepSeek才能完整变现——对本来就稳定跑量的开发者几乎等同于退款，对准备减少使用或转投其他模型的人，价值取决于未来还会在平台上花掉多少。换句话说，这是一笔对双方都体面的安排：钱没有流出平台，还顺带留住了用户下一周期的用量。上点科技

第三笔账：退的是服务费，不是业务损失

API用户这5小时的真实成本并不是那笔API费用：接入接口的第三方应用、智能客服、自动化任务同步停摆，开发者承担的是业务中断的损失，而补偿通知对营业损失只字未提。这并非DeepSeek独有——阿里云、腾讯云、华为云的SLA文档核心结构几乎都是"可用性指标+计算方法+赔偿方案+免责条款"，赔付通常以代金券按停机比例返还而非现金，间接损失一概排除。区别在于，云厂商有事先写好的赔付合同，而大模型服务在此之前没有公开的可用性承诺和赔偿条款——这次全额返还，是一次性的善意动作，不是履约。知乎

权益对比：放到行业惯例里看这份方案

表中的云服务一列来自对公开条款的二手归纳，与DeepSeek并非同一类合同，只能看方向：额度口径与触发便利度明显超过行业惯例，但补偿的性质（仍是费用返还）和边界（不含免费用户、不赔损失）没有改变。

值不值，分人头

持续付费的API用户：100%返还对2.9%的停机占比，明显值。把DeepSeek接进关键业务的开发者：几百上千的赠金对冲不了5小时的中断损失，值不值已经不是重点，该做的是给业务准备多模型冗余。免费网页用户：这次什么都没有，宕机的代价只体现为那5小时的"服务器暂时不可用"。真正值得盯着的后续有两件事——官方"剥离单点依赖"的整改会不会降低宕机频率，以及这次之后大模型行业会不会出现公开的可用性承诺。前者决定下一次还要不要补偿，后者决定补偿会不会变成行业底线。