本周在 r/LocalLLaMA 上，一个用户晒出了一个具体场景：他用 DeepSeek 最新发布的 V4-Flash-0731 模型做长时间编程任务，当上下文（即模型一次能"看到"的文本量）超过 10 万 token 后，模型会中途停止生成——不报错、不崩溃，就是停下来。在命令行敲一个 resume，它又正常继续跑。

这是什么

这是一次本地部署（在自己的电脑或服务器上跑 AI 模型，而非调用云端 API）的故障报告。DeepSeek 是中国头部大模型公司，V4-Flash 是其最新轻量版本，主打"小、快、能本地跑"。用户用的是社区（Unsloth）做的量化版本（把模型压缩到更小体积，方便在普通显卡上运行）Q8_K_XL，跑在 OpenCode（一个开源编程助手）里。

问题不是模型答错题，而是"停下来不动"。在 10 万 token 以上，每隔一段时间就要人工敲 resume 才能继续。这不是个别现象——这种"长上下文失稳"是开源大模型的常见老毛病，但出现在头部厂商的新模型上，仍然说明本地部署的成熟度还不够。

行业怎么看

支持开源社区的声音认为，这恰恰是开源模型的价值——bug 一旦被贴出来，作者和社区能在几天内修，闭源模型出问题你连日志都看不到。Unsloth 等量化团队通常会跟进优化。

但反对意见同样值得注意：一位资深用户在评论中指出，长上下文稳定性的根本问题不在模型本身，而在推理框架（llama.cpp 等负责实际运行模型的底层软件）和 prompt 缓存机制（让模型不用每次都重新"读"一遍历史对话，省时间和算力）。换句话说，同样的 bug 可能出在不同模型身上，根因是基础设施而不是 DeepSeek 的锅。

更现实的判断是：这件事告诉我们，"DeepSeek 又开源了一个新模型"和"你真的能在本地稳定用它"之间，距离还很长。

对普通人的影响

对企业 IT：想把 AI 跑在公司内网、需要保护数据的企业，会重新评估"开源模型 + 自建团队"的总成本——人力运维成本往往被低估。

对个人职场：普通白领暂时不必担心，这只是开发者社区的事；但如果你所在的公司正在评估"自建 AI"，可以问一句：长任务稳定性谁负责。

对消费市场：消费者层面的 AI 产品（ChatGPT、文心一言等云端服务）不受这个问题影响——它们的服务器端做了大量工程优化。但"本地 AI 替代云端"的叙事，比想象中更远。