上周四 DeepSeek 宕机近五小时，但有人发现自己手上的 API 还能调通。技术群随即炸出结论：官方都崩了，你还能通，你用的是假模型。
直觉上挺有道理。但从 API 调用路径看，这个推论经不起推敲。
官方说的是"部分中断"，不是"全挂"
DeepSeek 官方通知明确：故障时间为 10 月 15 日 8:11 至 13:04，持续 4 小时 52 分，"服务系统出现故障，导致该时段内 API 服务无法正常使用"。
同期状态页显示，受影响组件包括对话服务、DeepSeek V4 Pro API 和 V4.1 Flash API，并非全站不可用。官方 9:06 已定位原因并实施修复，13:04 宣布服务恢复。
"部分中断"的意思是：不是所有请求、所有节点、所有路径同时失效。你的请求没被路由到故障环节，或触发重试后落到可用节点，就能成功返回。这跟"模型被调包"之间，隔着一整套基础设施的复杂性。
能调通，说明不了模型真假
一个 API 请求从发出到响应，要穿过至少五层：网络入口、认证鉴权、计费配额、调度负载均衡、推理集群。推理只是最后一环。
推理集群没坏、但入口或调度层出故障的情况很常见------一部分人拿不到响应，另一部分人走另一条路径正常通过。故障期间能调通，只说明你绕开了问题环节，不说明结果被替换。
反过来，如果模型真被调包，你日常也测不出来，因为输出风格、响应格式、定价都没变。用"宕机期间能不能通"判断模型真伪，是个无效检验。
"假模型"怀疑是怎么烧起来的
10 月 15 日宕机，情绪已点燃。10 月 17 日 DeepSeek 上线 V4.1-Flash-1017，三端同步，模型名价格不变。OpenAI 的 GPT-6 Astra 则在 10 月上旬就已发布，Pro 版本陆续向 Pro/Business/Enterprise 开放。两种"上新"在同一时间段集中出现，成了情绪温床------严格说并非同日。
接着有人把新模型送进指纹工具 ModelTrace，跑出与 GPT-6 Astra 相似度 84.66%、与 GPT 家族 90.71%。"换皮实锤"截图一夜传遍技术群。
但翻它的说明文档会发现：候选库只有 18 个模型，全部来自 GPT 和 Claude 家族，没有 DeepSeek。无论喂什么模型，它都必须在 18 个里挑"最像的"，再归一化输出百分比。
这是闭集分类概率，不是"84.66% 可能是 GPT"的证据。拿一张陌生人照片，让一个只认识 18 个明星的人认，他不会说不认识，只会指着最像的说"就是他"。ModelTrace 的输出，性质类似。
API 使用者真正该关心什么
走官方 API，宕机期间能不能通，取决于你的请求路径和重试策略，不取决于模型真假。走第三方中转，情况更复杂------可能涉及路由到不同后端、缓存复用、降级到小模型，但那是另一件事，跟 DeepSeek 官方那次故障无关。
真正值得关注的，是 DeepSeek 算力余量不宽裕、运维还在补课。上海证券报报道，9 月 V4.1 Flash 内测阶段每账号限流 20 并发；峰谷定价的官方理由是"更合理地配置资源、提升服务稳定性"。这次近 5 小时故障，暴露的是稳定性问题，不是模型真实性问题。
V4.1-Flash-1017 本身是一次正常迭代：基准提升、耗时与输出缩短、API 模型名不变，权重在 HuggingFace 开源（MIT 许可证），发布两天后（10 月 19 日）登顶 Code Arena WebDev 开源榜。说它不够惊艳可以，说它是假模型，目前只有那张被误读的指纹截图。
结论
宕机那天 API 还能通，最合理的解释是：你不在故障路径上，或者请求在恢复过程中被成功处理了。这不是假模型的证据，而是分布式系统"部分失效"的正常表现。
真要担心模型被调包，正确方法是拿官方权重在本地跑一份基线，对比同一组固定 prompt 下的输出分布。需要点工程投入，但能回答的问题，比一张 84.66% 的截图多得多。