DeepSeek V4.1 Flash上下文长度是 1M（1,048,576 tokens），最大输出 384K。按 DeepSeek 官方 API 文档，当前在售的 deepseek-flash 与 deepseek-v4-pro 同为 1M 上下文。但"标称 1M"和"能用满 1M"是两件事：本文把能放多少、靠什么撑起来、怎么计费，以及 3 条容易踩空的边界一次讲清。 DeepSeek V4.1 Flash的上下文长度是多少
打开 DeepSeek 官方 API 文档的"模型 & 价格"页，与上下文直接相关的只有两行：上下文长度 1M、输出长度最大 384K。这个 1M 不是约数，而是 2 的 20 次方，即 1,048,576 个 token——社区开发者实测的超限报错里就直接印着这个数字。
表里可以逐个字段核到的内容如下：
| | |
|---|
| | 即 1,048,576 tokens，两个在售模型相同 |
| | |
| | deepseek-flash 为 2500，deepseek-v4-pro 为 500，按账号计 |
| | 图像理解仅 deepseek-flash 支持，v4-pro 不支持 |
| | 思考强度可选 low / high / max，默认 high |
| | 模型名用 deepseek-flash；旧名仍可调用但已路由到新模型 |
把这条线拉长看会更清楚：DeepSeek V3 时代的上下文是 64K，2025 年 8 月发布的 V3.1 扩展到 128K（官方发布公告原文为"上下文均已扩展为 128K"），到 2026 年 4 月 V4 系列上线时 1M 成为官方服务的标配。所以现在讨论的 1M，是 DeepSeek 从 V4 起就定下、V4.1 Flash 延续并大幅压低了成本的同一档位。
1M上下文到底能放多少内容
官方"Token 用量计算"页给了一组可直接用的换算比例：1 个英文字符约等于 0.3 个 token，1 个中文字符约等于 0.6 个 token。按这个比例反推，1M 上下文大约能装下 175 万个汉字（约 350 万个英文字符）。官方同时提醒：不同模型分词不同，实际数值以接口返回的 usage 为准。
图片要单独算。"图像理解"文档写明：图片进入模型前会被自动缩放，每张图片消耗的 token 存在 1024 个的上限——所以 2000×2000 和 5000×5000 的图消耗的 token 是一样的。按这个上限算，1M 上下文理论上能放约 1000 张图，但单请求最多 600 张，因此实际天花板是 600 × 1024 ≈ 61.4 万 token，约占 1M 的 59%。
| | |
|---|
| | |
| | |
| | 无官方字符比例，建议用官方 tokenizer 离线估算 |
| | 单张上限 1024 token，单请求上限 600 张 |
| | 图片 token 与文本 token 合并计费、合并占位 |
要注意最后一行：图片不是额外送的，它和文本抢同一块 1M 额度。一次请求里塞 600 张图，留给文字的额度就只剩约 41 万 token。
1M上下文靠什么撑起来：KV缓存降到890字节
1M 上下文能不能落地，卡点从来不是"模型看不看得见"，而是"显存放不放得下、算力扛不扛得住"。DeepSeek 在 V4.1 Flash 上的做法，是把每条 token 要常驻显存的那份缓存压到极小：官方口径为 全局 KV 缓存 890 字节/token。
这个数字换算成实际占用更有意思：890 字节 × 1,048,576 tokens ≈ 0.93 GB（约 0.87 GiB）。也就是说，把 1M 上下文整个拉满，KV 缓存占用不到 1 GB。作为对比，上一代 V4 Flash 的口径是 3,514 字节/token，同样拉满 1M 约需 3.68 GB——差出约 4 倍，这正是官方说"对 HBM 的需求减少到 1/4"的来源。
支撑它的是一套新结构（均取自官方模型卡与发布公告）：
- CED 因果编解码结构：在一个 552B 参数的 MoE 主干上，把 40 层 Transformer 拆成 20 层因果编码器 + 20 层解码器，让"读"和"写"用不同的算力预算——输入侧每 token 只激活 8B 参数，输出侧激活 16B。读长上下文走轻路径，这正是 1M 上下文在首字阶段不炸掉的原因。
- CSA2 压缩稀疏注意力：取消前代的稠密分支，把主 KV 存储与 Top-K 索引检索解耦，按 Full / Reindex / Reuse 三档在层间复用。
- FP4 主 KV 缓存：主缓存用 4 位浮点存储，量化安排在位置编码旋转之后，解码时在寄存器内反量化回 FP8 参与计算；对量化噪声更敏感的滑动窗口局部 KV 仍保留 FP8。
- SWA 有界重放：滑动窗口的局部状态不再落盘，命中时靠尾部少量 token 做近似重放，把持久化前缀缓存压到前代的约 1/8。
顺带提示一个容易混淆的口径：官方模型卡正文写的是 552B 骨干参数，另列的 Engram 条件记忆模块为 196B（相加约 748B），而同一页面侧栏的 Model size 却标为 763B。三个数字口径不同，无法互相换算，引用时应说明用的是哪一个，不要混用。
官方在发布公告里给的总结是两句可直接引用的话：对 HBM 的需求减少到 1/4，对 SSD 的需求减少到 1/8；相对于初代模型，KV Cache 已经缩小了 437 倍。而"能装"之外还要"能用"——第三方评测机构 Artificial Analysis 的长上下文推理测试 AA-LCR v1.1 上，V4.1 Flash 拿到 84%。
四代模型的KV缓存演进对照
把官方那张"持续进展"的图拆成一张表，能看出一条很清楚的路线：每一代都在同一个方向上加压，而上下文长度同期从 64K 一路走到 1M。
| | | | |
|---|
| | | | |
| | | | |
| | | | |
| | | | 跨层投影 + 层维解耦 + FP4 主KV + 有界重放 |
这张表的每行来源要分开看：890 字节与"相对初代 437 倍"是 DeepSeek 官方公告与模型卡的原话；3,514 字节由德国科技媒体 heise 转述 DeepSeek 官方说明；48,068 与 389,120 两个中间值来自第三方技术拆解，但它们与官方"437 倍"以及逐代压缩倍率互相自洽——890 × 437 ≈ 389,120。正因为口径混杂，本文不做"某一代就是这个数"的绝对断言，只把官方终值与第三方中间值并列。
上下文长度怎么计费：长度不是价格档位
很多服务会按上下文长度分档定价（128K 一个价、1M 另一个价），DeepSeek 不是这样。官方价格表里只有一个维度：token 数。上下文长短本身不改变单价，真正决定账单的是"这些 token 命中了缓存没有"以及"在什么时段跑"。
表里的价格单位是"每百万 tokens"，高峰时段为北京时间周一至周五 9:00–12:00 与 14:00–18:00，其余时间均为空闲时段，空闲价为高峰价的一半。三条换算关系值得记下来：
- 缓存命中与未命中差 50 倍（0.02 元对 1 元）。同样读 100 万 token，命中花 0.02 元，未命中花 1 元。
- 输出是输入未命中的 4 倍（4 元对 1 元）。长上下文场景里，答案写得越长越贵。
- 换时段等于打五折。同一个长文档批处理任务挪到晚间或周末跑，费用直接减半。
缓存也不是"有重复就一定便宜"。官方"上下文硬盘缓存"文档写明：缓存按缓存前缀单元判别，后续请求只有在完整匹配某个前缀单元时才算命中；系统在三种时机落盘——每次请求的用户输入结束位置与模型输出结束位置、检测到的公共前缀、以及长输入长输出中按固定 token 间隔截取的片段。缓存默认对所有用户开启，无需改代码；命中情况可从返回的 prompt_cache_hit_tokens 与 prompt_cache_miss_tokens 两个字段直接读到。官方也明说缓存是"尽力而为"，不保证 100% 命中，且不再使用后会自动清空，时间一般为几个小时到几天。
3条实际边界：别把1M当成能用满1M
这是本篇最值得记住的部分。标称 1M 之上，还有三件事会先撞上来。
| | |
|---|
| 官方文档只给了上下文 1M 与最大输出 384K，并未单列"最大输入"；社区实测的超限报错把 messages 与 completion 的 token 合并计数 | 想拿到 384K 的完整输出，输入就必须留出对应空间 |
| 只改动中间一句，后续内容就无法完整匹配原有前缀单元 | 反复改同一个长上下文的中间部分，会导致大段内容按未命中价计费 |
| 思考模式下，若请求携带 tools，历史轮次的 reasoning_content 必须回传且会被拼接进上下文；不带 tools 时则被忽略 | 工具类长会话的上下文消耗会明显高于直觉，且漏回传会直接报 400 |
关于第一条，社区开发者实测的超限报错原文是：
报错把 messages 与 completion 的 token 放在一起计数，且 1,274,958 已经超过 1,048,576——这说明输入与输出共用同一个 1M 额度。官方文档没有单列"最大输入"这个字段，所以严格来说这是一个由报错口径推出的结论，而不是官方给出的独立参数。
长上下文怎么用更省：5条可执行做法
- 把稳定不变的内容放最前面：系统提示、长文档、代码库快照放在消息开头，并在多次请求中保持完全相同的顺序与前缀，让缓存前缀单元能整段命中。
- 别硬续超长旧会话：把要交接的内容写成"文件路径 + 任务目标 + 已完成部分"，在新会话里重新开始。把上下文从百万级降回十万级，比在超长对话里反复触发未命中更省。
- 图片先缩再传：image_url 支持 detail 字段，设成 low 会在推理前把图缩到 512×512，更快也更省 token；需要在多个请求里复用同一张图时改用 Files API 的 file_id，可绕开 48 MiB 的请求体内联限制。
- 控制输出长度：输出单价是输入未命中的 4 倍。独立评测显示 V4.1 Flash 单任务平均输出约 8.9 万 token，比 V4 Pro 多 62%——在长文档与代码场景里，这一项很容易吃掉价格优势。
- 把批量任务挪到空闲时段：工作日晚间与周末全天都是空闲价，直接减半，不需要改任何代码。
还有一条容易被忽略的机制：超长上下文的首字等待可能较久，但官方有请求保活机制——连接会保持，并持续返回空行或 keep-alive 注释；如果 10 分钟后请求仍未开始推理，服务器才会关闭连接。这也意味着长上下文的超时设置不应照抄短请求的配置。
长上下文常见报错与排查
| | |
|---|
提示 maximum context length 超限 | 输入+输出 token 合计超过 1,048,576 | 新开会话交接，或减少历史消息与图片，给输出留出额度 |
| 并发数超过账号上限（flash 2500 / v4-pro 500） | |
| 历史轮次的 reasoning_content 未完整回传 | 把上一轮的完整 assistant 消息原样 append 回 messages |
| 图片出现在 system 或 assistant 消息中 | |
两条时效提示。其一，DeepSeek 于 2026 年 9 月 10 日的发布公告原计划"北京时间 9 月 14 日 12:00 之后至 V4.1 Pro 上线前，v4-pro 请求全部路由到 V4.1 Flash 并按 Flash 价计费"，但截至目前（2026 年 9 月 14 日），官方中英文定价页均已改为"继续提供 V4 Pro 的 API 调用服务，计费方式保持不变"——计划已调整，仍在使用 v4-pro 的长上下文任务不必仓促迁移，但请以定价页当日口径为准。其二，网上流传的部分第三方模型页把 V4.1 Flash 的最大输出写成 128K、许可证写成 Apache 2.0，这两项均与官方文档和 Hugging Face 模型卡不符（官方为 384K、MIT），请勿据此做容量或商用规划。
常见问题
Q：DeepSeek V4.1 Flash 的上下文长度到底是多少？
A：1M，即 1,048,576 个 token，最大输出 384K；API 模型名为 deepseek-flash。
Q：1M 上下文需要额外付费吗？
A：不需要。官方价格表不按上下文长度分档，只按 token 数与缓存命中情况计费，用满 1M 与只发一句的单价完全一样。
Q：上下文长度和输出长度是分开算的还是合并的？
A：按社区实测的报错口径，输入与输出 token 合并计入 1M。官方文档只给了上下文 1M 与最大输出 384K，未单列最大输入，规划长文任务时建议给输出预留空间。
Q：1M 上下文大约相当于多少字？
A：按官方换算比例（1 中文字符 ≈ 0.6 token），约 175 万个汉字；英文约 350 万个字符。实际以接口返回的 usage 为准。
Q：v4-pro 的上下文长度也是 1M 吗？
A：是。官方价格表中上下文长度与输出长度两行对两个模型是同一个值，差异在并发上限（flash 2500、v4-pro 500）与是否支持图像理解。
Q：为什么长上下文调用经常全额计费、缓存命不中？
A：缓存按"缓存前缀单元"完整匹配才算命中。反复修改长上下文的中间部分，或每轮都调整系统提示，都会让后续内容无法完整匹配，从而按未命中价计费。
Q：图片会占多少上下文？
A：每张图最多 1024 个 token，单请求最多 600 张，因此图片合计最多约占 61.4 万 token；把 detail 设为 low 会让图片先缩到 512×512，更省额度。
Q：开源部署时上下文也能开到 1M 吗？
A：官方模型卡把 context_window 标为 1M，权重按 MIT 许可发布；但模型卡的推荐采样参数里 max_tokens 建议不低于 256K，与 API 侧"最大 384K"是两个口径，自建服务时按自己的显存与服务框架实测为准。
Q：长上下文请求超时了怎么办？
A：官方保活机制会在等待期间持续返回空行或 keep-alive 注释，10 分钟后请求仍未开始推理才会断开。长上下文的超时与重试配置不要照抄短请求。
AI 速览
