Deepseek V4的百万上下文窗口：临界点

刚刚验证了Deepseek V4声称的百万上下文，并在三个生产代码库上运行：45k（微服务）、180k（单体后端）和520k（全栈应用）。观察任务包括依赖追踪、跨文件重构和bug隔离，以查看召回效果。**在150k以下**表现稳定，例如在45k token时，跨8个文件的函数调用追踪保持了准确的路径重建。在180k时，跨14个文件的多文件重构显示了架构理解的一致性，没有矛盾或上下文丢失模式。**超过300k**后，精度质量下降。要求给出400k token之前定义的函数的确切行号，响应给出“大约第230行”而非实际的第247行。在520k时，输出转向跳过实现细节的架构摘要，如果关注边缘情况则是个问题。**延迟差距**：在deepinfra fp4端点上首次token时间约为1.19秒。在最大推理模式下首次回答时间延长至约120秒，因为模型在产生可见输出前完成内部思维链，这对交互式工作流至关重要。提供商基准显示未知答案任务上幻觉率为94%（aa-omniscience），但V4在没有实际信息的情况下生成自信的回应。表现为引用不存在的工具函数或幻影依赖。需要为任何生产关键任务添加验证层。**实际范围**：150-250k token似乎最适合编码工作，全上下文保留、低于2秒响应延迟、最小精度损失。超过300k需要防御性提示和源验证。百万窗口在技术上可行，但需要谨慎处理。上下文大小变化使得提示工程技术仍然重要，而非完全消除需求。