10月12日中午前后，DeepSeek网页端与App的对话功能出现异常，用户反复收到“服务器繁忙”“消息正在生成”的提示，无法正常发起新对话，引发多平台热议。微博知乎
官方服务状态页把本次事件标注为对话服务的“部分中断”，排查后显示“服务已恢复”。 但截至当天14时前后，仍有用户反馈自己的对话没有恢复，甚至出现“小号能用、大号不行”的账号分化。 恢复记录与用户体感的落差，正是这轮“DeepSeek对话出现异常”登上热榜的原因：官方宣布的恢复，不等于每个用户都已经恢复。微博小红书微博
状态页的“11分钟”，和用户的“两个多小时”
有微博用户转述官方状态页，本轮对话服务的中断记录为12:05至12:16、共约11分钟，现已修复，API类目未见异常。 但用户的实际体感明显更长：小红书从12:17起就有连续异常笔记，到13时41分还有用户表示问题已持续两个多小时。 这个差距恰恰是“部分中断”的含义——不是所有节点同时失效，也不会同时放出来，“别人都说好了、我这还是不行”成为本轮反馈最集中的形态。 截至发稿，DeepSeek未披露本次中断的具体原因。微博小红书小红书
这是3月以来第四轮公开可查的服务异常
3月29日至31日，DeepSeek网页对话、App及API连续三天出现异常，官方状态页记录的三轮故障分别持续约1小时48分、10小时13分和1小时3分，其间过去30天网页对话服务的整体可用性为98.61%。 那次故障中，还有用户报告对话内容丢失。新浪科技微博
7月2日下午，“服务器繁忙”在文档上传等场景集中复发，官方状态页面确认网页及API服务性能下降，并表示已定位原因。 7月22日下午，联网搜索功能单独故障约4小时，状态页记录故障从13时前后持续到17时。 加上10月12日这轮，全年公开可查的服务异常已有至少四轮，社交平台流传的“今年已崩18次”之类数字则是未经证实的自媒体统计。微博新浪科技
别把“崩了”和“变笨”混为一谈
最近围绕DeepSeek还有另一类“异常”讨论：回答时好时坏。10月8日，字节Seed团队9月底挂上arXiv的一篇65页论文登上知乎热榜第一，研究对象正是DeepSeek-V4系列。 研究称分块KV缓存压缩后，模型表现随信息输入的Token位置周期性波动，每隔4个Token一个循环。 在其128K Token长上下文检索测试中，同一条信息仅换个位置，DeepSeek-V4-Flash-Base的检索准确率最高相差40.2个百分点，这不能读成整个系列“性能下降四成”。 需要注意，这是尚未获DeepSeek官方确认的第三方研究，且它说的是答得准不准，和今天“聊不了”的服务中断是两类问题：前者靠压缩策略与推理链路本身解释，后者是平台可用率问题。知乎知乎知乎
两类异常的用户应对因此完全不同。服务中断时，先查官方服务状态页确认是否为平台故障，反复切换网络并不能解决——本轮就有用户无线网络和5G来回切换仍然刷不出，只能暂时改用其他助手。 本轮API与第三方接入基本未受影响，有开发能力的用户可临时以API为备用入口，但7月2日那轮API同样降级过，业务连续性不能押注“API不会崩”。回答质量的波动则更像使用习惯问题：长对话里把关键材料挪近问题本身、重要结论多问一次再采信。微博
而无论哪一类“异常”，都指向同一个事实：对把论文、方案、代码草稿沉淀在对话窗口里的用户，DeepSeek的中断记录已经是2026年反复出现的事件。最重要的输出及时导出到对话之外，是这一轮又一次被用户亲身印证的教训。
