DeepSeek V4：1M 上下文进入成本结构阶段
DeepSeek V4 的核心变化不是把 1M context 写进功能清单，而是让长上下文从能力展示进入成本、路由和产品默认值的重新设计。
概述
DeepSeek V4 Preview 最值得关注的信号，是官方把「cost-effective 1M context length」放在发布首屏，并声明 1M context 已经成为所有官方 DeepSeek 服务的默认能力。这个表述的分量很重：长上下文不再只是 Pro 用户偶尔开启的实验窗口，而是模型、API、价格和产品入口必须共同承受的基础假设。对 builder 来说，真正的问题随之变化：过去问的是模型能不能吃下 1M，现在要问的是每次把 1M 当默认上下文时，账单、延迟、缓存和召回策略会怎样重排。
官方同时给出两条产品线：DeepSeek-V4-Pro 是 1.6T total / 49B active params，DeepSeek-V4-Flash 是 284B total / 13B active params。这个组合说明 DeepSeek 没有把长上下文只交给最大模型，而是在能力上限和日常吞吐之间做了明确分层。判断也因此更清楚：1M context 的价值不在「所有请求都塞满窗口」，而在系统可以按任务难度和交互模式，把长上下文能力变成可调度的资源。
所以这篇的立论很简单：DeepSeek V4 的意义，是把长上下文从「能做到」推向「成本结构问题」。如果你还把 1M 看成宣传数字，就会错过真正的工程变化；如果你已经在做 repo agent、研究助手、企业知识库或复杂客服，V4 提醒你重新设计的是上下文经济学，而不是 prompt 模板。
发生了什么
DeepSeek 在 2026 年 4 月 24 日发布 V4 Preview，并宣布 API 当天更新可用。官方文档写得很直接：chat.deepseek.com 可通过 Expert Mode / Instant Mode 试用，API 侧只需保留 base_url，把 model 更新为 deepseek-v4-pro 或 deepseek-v4-flash。这个迁移路径的判断意义大于宣传意义，因为它降低了接入摩擦，让 builder 可以把 V4 当成现有 DeepSeek 调用栈的升级，而不是一套新供应商集成。
发布还明确了旧模型的生命周期：deepseek-chat 与 deepseek-reasoner 会在 2026 年 7 月 24 日 15:59（UTC）之后完全退役且不可访问，目前分别路由到 deepseek-v4-flash 的 non-thinking / thinking 模式。这个时间点不是小字注释，而是产品战略信号：DeepSeek 希望把 V4 变成默认入口，同时用 Flash 承接大量普通流量。对建设者而言，继续围绕旧模型做长期优化已经不划算，迁移计划应该按这个退役日期倒排。
技术侧，官方把长上下文效率归因于 token-wise compression 加 DSA（DeepSeek Sparse Attention），并强调在 compute 与 memory costs 上做了大幅降低。这里要克制地读：官方没有在页面文本里展开可复现实验细节，不能把它直接翻译成你自己部署中的成本数字；但方向足够明确，DeepSeek 选择在注意力和上下文存储层面处理成本，而不是只靠硬件堆窗口。
为何重要
1M context 真正昂贵的地方，从来不是模型声明支持多少 token，而是每次请求都会把更多历史、文档、代码和工具结果带进推理路径。上下文一旦变成默认能力，浪费也会默认发生：检索召回过宽、agent 历史不剪枝、代码仓库全量塞入、客服记录不分层，都会把「长上下文」变成「长账单」。DeepSeek V4 的价值在于它迫使团队把上下文当资源管理，而不是当无限扩容的输入框。
Pro/Flash 的分层进一步说明，长上下文产品需要路由而不是单模型信仰。V4-Pro 承担强推理、复杂 agent 和高价值任务，V4-Flash 承担快速、经济和简单 agent 任务，这比「一个最强模型包打天下」更接近生产现实。我的判断是，未来长上下文系统的竞争会落在路由策略上：什么时候用 Flash 读全局，什么时候把压缩摘要交给 Pro，什么时候用缓存复用已经付过费的上下文。
这也改变了 RAG 和 agent 的边界。过去 RAG 的价值是绕开有限窗口；当 1M 变成默认，RAG 的价值会转向过滤、排序和成本控制。能够塞进去不等于应该塞进去，能保存全部历史也不等于应该让模型每轮读取全部历史。V4 这类模型越普及，越能看出检索系统的核心能力其实是节制。
对建设者的影响
第一，重新定义你的上下文预算。不要只写「最大上下文 1M」这类配置项，而要把上下文拆成稳定背景、短期工作记忆、检索片段、工具输出和用户显式输入，每一层都要有进入窗口的条件。这个设计看上去琐碎，却会直接决定长上下文是生产优势还是成本黑洞。
第二，把模型选择和上下文长度分开评估。V4-Pro 的 1.6T total / 49B active params 适合高价值复杂任务，V4-Flash 的 284B total / 13B active params 更适合快路径；但长上下文本身未必总要上 Pro。务实的做法是先让 Flash 做粗读、压缩、分类和低风险回答，再把确实需要深推理的片段交给 Pro。这个路由如果做对，1M context 才会变成产品能力，而不是每次请求的固定税。
第三，尽快处理旧模型退役。官方已经给出 2026 年 7 月 24 日 15:59（UTC）这个不可访问节点，继续依赖 deepseek-chat 或 deepseek-reasoner 的硬编码会变成稳定性风险。更好的迁移方式是把 thinking / non-thinking 作为产品级模式暴露给路由层，而不是把旧模型名留在业务逻辑里。
第四，别把长上下文当成检索质量的替代品。1M window 会让糟糕检索的后果更隐蔽：答案可能看似引用充分，但模型在无关材料里消耗了注意力和预算。对企业知识库、代码库和研究助手来说，V4 的上线应该推动更严格的召回评估，而不是取消评估。
该忽略什么
第一，忽略「1M context 以后 RAG 过时」这种结论。它误把窗口长度当成信息组织能力。长窗口解决的是上限，RAG 解决的是选择；当窗口变长，选择反而更重要，因为无关信息的成本和干扰都被放大了。
第二，忽略「官方默认 1M，所以所有请求都该默认 1M」的偷懒实现。默认能力不等于默认使用，尤其在 API 产品里，默认支持只是降低上限焦虑；真正成熟的系统会尽量少用上下文，只在价值超过成本时才展开长窗口。
第三，忽略单纯拿 Pro/Flash 参数规模做高低判断。V4-Pro 和 V4-Flash 的关键关系是任务分层，不是简单替代。把所有请求打到 Pro 会浪费，把所有请求压到 Flash 会丢复杂任务质量；V4 的建设者红利，恰恰在于你能设计出中间那层路由。
常见问题
DeepSeek V4 的 1M 上下文是真能用，还是只是参数表上的数字？
能用，但关键不在窗口长度，而在它被设成官方服务的默认能力——约束随之从'能不能开'变成长上下文的成本、路由和缓存策略。把它当默认值之前，先算清你的高频请求是否值得每次喂满上下文。
DeepSeek V4 和 GPT 在长上下文上该怎么选？
不该按'谁的窗口更大'选。V4 的差异是把长上下文压进成本结构，所以选型要看你的负载是偶发长文档还是高频长上下文——后者才是 V4 成本设计的受益场景，否则窗口大小对你没区别。
上了 DeepSeek V4 的 1M 上下文，成本会失控吗？
会，如果你把'窗口能塞 1M'当成'每次都塞满'。成本控制点在路由（短请求别走长上下文）和缓存复用（重复前缀别重复计费），这两个才是长上下文被产品化后真正要管的开关。