先摆三个数字：故障窗口近5小时；官方按近7天消耗全额返还赠金；对应时段，我自己的本地模型启动了，一开始完成了28次请求、22478个token，没有中断。数字都来自引擎日志，文末会说怎么核。
10月15日早上的事，关注到的朋友应该都清楚了。8点11分起，DeepSeek网页版和API陆续不可用，13点04分官方确认恢复，前后将近5小时。随后官方开放平台发布补偿方案：按用户近7天（10月8日至14日）的消耗金额，以赠金形式全额返还，自动到账。传播最广的一条评论是'给我补了77块钱，我永远支持DeepSeek'。
我自己是云API和自建模型两边都在用的用户。不是幸灾乐祸——恰恰相反，我认为这次事件里真正值得学的，是我的两类方案能配合，而不是谁取代谁。
·　·　·
故障当天上午9点50到10点43，正好落在故障窗口里，我的AI助手在给我干活——一串bash调用，改配置、查数据。它调用的不是DeepSeek，是我自己那台双3080跑的94G开源模型。
看到故障消息后，我做了件挺职业病的事：把引擎日志拉出来，看同一时段这台机器是什么状态。日志长这样：


▲ 引擎日志（2026-10-15 09:50–10:43，故障窗口内）
故障窗口内共完成28次请求、22478个token，解码速度中位数66.7 token每秒，报错0次。把两条时间线画在一起：


▲ 云端故障窗口与本地请求分布（本地数据来自引擎日志）
云端故障的时间窗，和我这边正常出活的日志，同一天并排躺在我的屏幕上。但请注意这个'正常'的含金量：它不是因为我技术多好，只是因为我的业务恰好没有依赖出事的那一家。如果那天挂的是我依赖的服务，我的表现不会比任何人好。
·　·　·
那个'77块'值得算一算。按7天折算，这位用户每月API开销在330元上下，属于重度使用。
再算我那台机器：整机满载功耗不到1千瓦，按我家0.48元一度的电价，24小时连轴转的上限约320元一个月；日常这种用法，110元足够。


▲ 月度成本粗算（电费为估算，硬件为旧机改造不计入）
结论可能让一部分期待'自建白嫖'的朋友失望：纯算钱，本地方案并不占便宜，电费大致打平API账单，机器钱还提前付了。本地方案真正买到的东西是另外两样——服务连续性（这5小时就是例子），和数据不出家门以及可以随时开启自己的实验。

不过故障当天的日志里还是有一条难看的记录：1.5 token每秒，64个token跑了48秒。那是模型刚加载完、专家权重还没进内存缓存的冷启动阶段，那几分钟它基本是瘫的。94G的权重从磁盘往起攒，得给它时间。
更大的坑在维护。上个月容器重建，启动脚本里一个参数把我手动加的配置整个抹掉，排查了大半天。云API再不稳，人家公司修起来比你快一百倍；本地服务出了问题，凌晨三点爬起来修的人是你自己。
所以我的结论是分层级的：轻度使用，云API是正确答案，便宜、量大、质量高，故障了赔赠金，态度也到位；重度依赖、数据敏感、或者网络环境受限的，值得配一套本地方案当后备——注意措辞，是后备，不是替代。
我自己的用法慢慢演化成了一个不太成熟的分工：日常主力还是云API，质量摆在那里；本地模型跑两类活，一类是高频的小任务（改配置、查数据这种，量大、不值得走公网），一类是任何不想出门的内容。15日那天恰好是第二类在值班，替第一类顶了5个小时。两套系统互为备份，谁出事另一套在——这大概是这次事件里最值得抄的作业。
留个问题，挺认真的：重度使用云API，是否曾经有过顾虑？评论区聊聊。
文中日志可复核：docker logs 按故障时段过滤，统计'完成'行数与token数即为28次/22478。电价、功耗均为估算口径，欢迎较真。