IT资源栈近日，在开发者社区 Linux.do 中，有用户报告指出，经由 OpenRouter 和 Kilo 等第三方聚合平台调用的 DeepSeek V4 Flash 模型出现了严重的输出异常。根据用户反馈，这些平台提供的该模型版本在生成回答时，不仅无法正常推理，反而输出了大量类似乱码的无意义文本，且这些内容中还夹杂着疑似被污染的非正常广告信息，最终导致输出流强行中断。这种现象呈现出明显的“中毒”特征，即模型的推理链似乎被注入了无效或恶意的上下文数据。为了排查故障源头，用户进行了对比测试：使用 OpenCode 以及 DeepSeek 官网的 V4 Flash 模型时，服务表现完全正常，并未出现乱码或中断情况。这一对比结果有力地证实了问题并非出在 DeepSeek 的官方模型端，而是特定于 OpenRouter 和 Kilo 这两家服务商的接口层或转发机制。受影响的目前仅限于这两家平台上的 V4 Flash 免费版本，其他模型及官方渠道运行稳定。该事件暴露了第三方 AI API 聚合服务在传输稳定性或上下文处理上可能存在的潜在风险，对于依赖此类聚合平台进行开发的项目而言，可能面临不可预期的输出质量波动。
事件分析
此次故障事件凸显了当前大模型应用生态中，第三方 API 聚合层存在的潜在技术隐患。当上游模型在官方渠道表现正常时，特定聚合商出现的问题往往指向请求路由、上下文传输或网关配置层面的缺陷。特别是输出内容表现为“乱码广告”而非单纯的无意义字符，这可能暗示着在数据转发过程中，模型的系统提示词或上下文窗口被错误修改，或者是聚合商为了降低成本而复用了被污染的会话缓存。此外，推理过程的中断表明生成内容的 Logits 分布异常，触发了安全停止机制。对于开发者而言，这意味着在生产环境中过度依赖单一聚合商存在风险，必须设计多源切换机制和输出清洗逻辑，以应对中间层服务不稳定带来的“幻觉”或数据中毒风险。
💡 核心观点：聚合平台的中间层故障再次警醒开发者：实现生产级AI应用必须具备对上游模型供应商的冗余容灾与实时监控能力。
原文链接：Linux.do
评论前必须登录！
立即登录 注册