如果只用一句话概括 DeepSeek V4.1 Flash 的架构思路，可以理解为：把更多资源留给真正需要复杂计算的输出阶段，同时尽可能降低长输入和 KV Cache 带来的持续成本。
2026 年 9 月 10 日，DeepSeek 正式发布 V4.1 Flash。官方将其定义为新架构系列中的较小尺寸模型，但这里的“小”并不是传统意义上的小参数模型。V4.1 Flash 的 MoE 主干参数规模达到 552B，并额外引入了约 196B 参数的 Engram 条件记忆模块；真正决定推理开销的，是每个 Token 实际参与计算的参数量以及上下文状态需要占用多少缓存。
V4.1 Flash 在 Prefill，也就是读取输入时，每个 Token 只激活约 8B 参数；进入 Decode 输出阶段后提升到约 16B。与此同时，模型把全局 KV Cache 压缩到约 890 bytes/token，约为上一代 V4 Flash 的四分之一，相较 DeepSeek V1 则缩小约 437 倍；通过 SWA Bounded Replay，持久化 KV Cache 的规模进一步降到上一代约八分之一。
这几个数字放在一起，才是 V4.1 Flash 真正值得研究的地方。
它并不是简单把一个 552B 模型“量化得更小”，而是重新处理了三个问题：
输入应该经过多少计算、每一层是否都需要保存自己的全局 KV、超长上下文中的历史信息应该怎样被检索。
CED、CSA2、FP4 KV Cache，分别对应了这三个方向。
一、CED：为什么一个552B模型读取输入时只激活8B？
传统 Decoder-only Transformer 有一个很直接的特点：无论是在读取 Prompt，还是生成新的 Token，请求都需要按照模型层级向前传播。
这种设计用于普通聊天没有太大问题，但 Agent 的工作负载正在变得越来越不对称。
一个代码 Agent 可能需要读取整个项目目录、多个源文件、终端日志和历史工具结果；浏览器 Agent 可能连续把搜索结果、页面文本和工具响应加入上下文。真正需要输出的内容可能只有几十行代码或者一个简短结论，但输入已经达到数万甚至数十万 Token。
也就是说，在很多 Agent 任务里，“读”正在变成主要负载。
V4.1 Flash 的 CED，也就是 Causal Encoder-Decoder，就是针对这种输入密集型工作方式设计的。
它将 40 层 Transformer 主干划分成：
关键不只是把层切成两段，而是改变了 Decoder 获取全局 KV 的方式。
在普通结构中，不同层通常需要根据自己的隐藏状态形成对应的 KV。CED 则让 Decoder 的全局 KV 从 Encoder 最终隐藏状态中投影得到，各 Decoder 层保留自己的投影，因此可以看到同一份 Encoder 表示的不同视图，而无需让整个长输入都按照传统方式在上半部分重复生成独立的全局 KV。
结果就是 Prefill 与 Decode 出现明显的不对称：
报告对长序列 Prefill 的分析也体现了这个思路。传统结构的计算量可以粗略理解为随输入长度 N 和网络深度 L 一起增长；CED 中，长输入主要经过下半部分 Encoder，而 Decoder 仍需要处理滑动窗口范围内的局部状态，因此在 N 远大于局部窗口 n 时，Prefill 计算量可以近似从 O(NL) 收敛到 O(NL/2 + nL/2)。
这里不能把它理解成“后20层读取输入时完全不工作”。
Decoder 仍然需要维护自己的 Sliding Window Attention，也就是滑动窗口注意力状态。
CED 真正省掉的，是大量长上下文下重复生成全局状态的工作。
因此更准确的理解应该是：
全局信息尽量只做一次重计算，局部信息仍然保持逐层更新。
这也是为什么它特别适合输入长度远大于实际输出长度的 Agent 场景。
二、CSA2：890 bytes/token 是怎么压出来的？
CED 降低了 Prefill 计算量，但还有另外一个问题没有解决：
已经读取过的上下文放在哪里？
这就是 KV Cache。
模型生成新的 Token 时，并不会把此前全部上下文从头算一遍，而是把之前得到的 Key 和 Value 保存在缓存中。
上下文短的时候，这部分成本并不明显。
但如果把上下文扩展到 1M Token，再叠加大量并发请求，每一层都保存自己的 KV，显存占用会迅速增长。
V4.1 Flash 使用的核心结构是 CSA2，也就是 Compressed Sparse Attention 2。
它进一步把注意力层划分成三种静态模式：
| 模式 | Main KV | Indexer K | Top-K选择 | 核心作用 |
|---|---|---|---|---|
| Full | 本层生成 | 本层生成 | 重新选择 | 建立新的全局KV与索引 |
| Reindex | 复用Full层 | 复用Full层 | 重新选择 | KV共享，但保留本层检索偏好 |
| Reuse | 复用Full层 | 复用Full层 | 继续复用 | KV和检索结果同时共享 |
这三个模式最关键的设计，其实是把两个原本绑在一起的问题拆开：
谁负责保存历史？
以及：
当前层想从历史里看哪些位置？
Full 层负责生成一套新的全局 KV，同时完成稀疏索引。
Reindex 层不再保存一份新的 Main KV，而是复用此前 Full 层留下的 KV，但仍然使用自己的 Indexer Query 重新寻找 Top-K，因此不同层仍然可以关注不同的历史位置。
Reuse 则更进一步，连此前得到的 Top-K 位置一起复用。
所以原文里用“一层干活、几层抄作业”来理解 CSA2，方向并没有错，但还需要补一句：
Reuse 并不意味着这一层被跳过。
它仍然会计算自己的 Main Query，也仍然维护自己的局部 SWA 状态。复用的是全局 KV 和部分索引路径，不是把整个 Transformer Layer 删除。
三、CSA2具体怎么排：真正保存全局KV的层其实不多
按照 V4.1 Flash 公布的模型配置，如果从人类习惯的第1层开始编号，前两层主要使用局部 SWA。
Encoder 的第3至20层可以看成三组结构，每组六层：
也就是：
1个 Full + 5个 Reuse。
这一部分还使用了 m=2 的序列压缩方式，也就是进一步减少全局缓存位置。
进入 Decoder 后，第一组是：
之后四组则采用：
换句话说，40层网络并不是40层都保存一套独立的全局 KV。
公开配置中真正作为全局 KV Source 的只有少数层，而更多层通过 CSA2 复用这些状态。
这就是 V4.1 Flash 能在“层维度”继续压缩 KV Cache 的关键。
它并不是假设每层看到的内容完全相同，而是认为：
历史表示本身可以共享，但每一层如何使用这些表示，仍然可以有所不同。
这比简单让所有层共用完全相同的 Attention 结果要灵活得多。
四、Hierarchical Sparse Indexer：1M上下文不能每层都扫一遍
减少 KV 副本之后，还有一个计算成本：
怎么从一百万个历史位置里找出当前真正需要看的那些 Token？
如果每一个需要重新索引的层，都重新扫描完整的 1M Token，那么 KV 虽然省下来了，索引计算还是会迅速增长。
V4.1 Flash 因此在 Decoder 中进一步加入 Hierarchical Sparse Indexer。
它的基本思路是：
第一层 Full Indexer 可以扫描完整的可见上下文，然后把位置按块进行筛选，形成一个较小的共享候选池。
公开模型配置显示，候选池最多保留：
之后的 Reindex 层不再面对整个百万 Token 上下文，而是在这约 16384 个候选位置中重新选择自己的 Top-512。
Indexer 本身使用 32 个查询头，Head Dimension 为 128，最终每个查询保留 Top-512。
这样做之后，后续 Reindex 层的搜索规模就不需要继续随完整上下文长度线性增加。
不过这里有一个很重要的边界。
第一个 Full 层仍然要进行完整范围的搜索。
所以准确说法并不是“V4.1 Flash 的长上下文检索成本和长度完全无关”，而是：
> 把昂贵的全量搜索集中到少数位置，再让后面的索引层在有界候选池里工作。
这也是层级化索引真正降低计算成本的地方。
五、FP4 KV：共享之后，再把每条记录本身压小
CSA2 主要解决的是“多少层需要保存 KV”。
V4.1 Flash 还继续解决另一个问题：
每一条 KV 到底占多少字节？
模型的 Main KV 使用 FP4 缓存。
具体采用 E2M1 格式，并以每16个通道共享一个 E4M3 Scale 的方式保存。对精度更加敏感的局部 SWA KV，则继续保留 FP8。
这里还有一个很具体的工程细节：
Main KV 的量化是在 RoPE 之后进行的。
技术报告中的实验结论是，在 RoPE 之前量化虽然能够获得有限的精度收益，但会在 Decode 阶段引入额外处理成本，因此最终选择在位置旋转之后再量化。
这样一来，KV Cache 实际上同时在三个方向进行压缩：
最终得到的就是约：
890 bytes/token。
作为对比，DeepSeek 公布的历代数据中：
因此，V4.1 Flash 相比 V4 Flash 大约又压缩到四分之一，而相比初代 V1 则约缩小 437 倍。
六、为什么持久化KV还能从1/4继续降到1/8？
890 bytes/token 讨论的主要是推理过程中常驻 HBM 的全局 KV。
但 Agent 还有另一种场景。
一次长任务可能不会始终保持在 GPU 显存里。部分上下文状态需要放到 SSD 或主机内存，以便下一次请求继续使用。
如果把每一层的 Global KV 和 Sliding Window KV 全部持久化，SSD 容量与 I/O 同样会成为瓶颈。
V4.1 Flash 因此引入了 SWA Bounded Replay。
它没有要求把全部 SWA KV 永久写入 SSD，而是在恢复上下文时，只重新回放最近一个滑动窗口范围内的 Token，用有限的计算重新构造这些局部状态。
于是持久化缓存变成一种取舍：
技术报告给出的结果是，Persistent KV Cache 最终约为 V4 Flash 的八分之一。
这对持续几十轮甚至更多工具调用的 Agent 特别重要，因为长任务面对的不只是 GPU 显存成本，还有上下文跨请求保存、加载和恢复的问题。
七、除了CED和CSA2，还有三个容易被忽略的部分
1. Engram：把一部分知识从“计算”变成“查询”
V4.1 Flash 还加入了约 196B 参数的 Engram Conditional Memory。
它并不会像普通 Transformer 参数一样，每个 Token 全量参与神经网络计算，而是通过基于 Token 的稀疏查询方式访问。
因此它增加的是模型可以访问的条件记忆容量，而不是简单把这 196B 参数全部叠加到每 Token 激活计算中。公开配置显示 Engram 模块挂接在主干的两个位置。
这进一步说明为什么“大模型总参数”越来越不能直接等价成“单次推理成本”。
V4.1 Flash 的架构里至少要同时区分：
单看 552B 或更大的总数字已经很难准确判断真实成本。
2. Single-Pass mHC：继续处理残差连接效率
V4 系列已经引入 mHC，也就是 Manifold-Constrained Hyper-Connections。
V4.1 Flash 又使用了 Single-Pass mHC，并配套更加高效的 Mega-mHC Kernel，目的是减少残差混合过程中的额外计算和通信开销。
它不像 CED 或 CSA2 那样直接决定 KV Cache 大小，但属于整个推理效率优化链条的一部分。
3. DSpark：解决逐Token生成等待
DSpark 处理的是另一个问题：Decode 天生是自回归过程。
传统生成必须：
前面的 Token 没出来，后面的就无法最终确认。
DSpark 使用半自回归 Draft Generation 和基于置信度的 Verification，通过先预测一批可能的后续 Token，再由主模型验证，争取一次接受多个 Token。
它优化的是生成过程中的等待，而不是改变模型本身的知识能力。
实际 Tokens/s 和首 Token 延迟仍然会受到部署硬件、并发量、Reasoning Effort、上下文长度以及服务商实现影响，因此不宜把某一次第三方测试的速度当成所有环境下的固定指标。
八、原生多模态不是外挂一个视觉接口
V4.1 Flash 还原生支持图像输入。
公开模型配置显示，其视觉编码器 DeepSeek-ViT 包含 32 层，隐藏维度为 1024，并通过一个两层 MLP Projector 把图像特征转换为可以与文本共同处理的视觉 Embedding。
更关键的是，这部分多模态能力不是后期才外挂上去的。
DeepSeek 的模型说明显示，视觉 Embedding 从语言模型预训练早期就与文本一起进入训练流程。V4.1 Flash 的预训练数据规模约为 45T Token，并最终把上下文扩展到 1M。
因此 V4.1 Flash 的定位并不只是“一个更便宜的文本 Flash 模型”，而是面向长上下文、Agent 和多模态任务重新组织过的一套架构。
九、一张表看清V4 Flash、V4 Pro和V4.1 Flash
| 对比项 | V4 Flash | V4 Pro | V4.1 Flash |
|---|---|---|---|
| 主干参数 | 284B | 1.6T | 552B |
| 激活参数 | 13B | 49B | Prefill约8B / Decode约16B |
| 上下文 | 1M | 1M | 1M |
| 全局KV Cache | 3514 bytes/token | — | 890 bytes/token |
| 原生视觉输入 | 原版Flash不支持 | 不支持 | 支持 |
| 主体架构 | V4混合稀疏注意力 | V4混合稀疏注意力 | CED + CSA2 |
| API现状 | 原模型已下线，旧名称暂时兼容 | 目前仍继续提供API | deepseek-flash |
V4 Flash 和 V4 Pro 的参数规模与激活参数来自 DeepSeek V4 官方模型资料；V4.1 Flash 则已经换成 CED 架构，因此不能只按照参数数量直接横向比较。
这里尤其要注意 V4 Pro 的状态。
DeepSeek 在 V4.1 Flash 发布当天原本宣布计划逐步下线 V4 Pro，并计划自 9 月 14 日开始把相关请求切换到 V4.1 Flash。
但官方 API 文档随后进行了更新：因用户需求，DeepSeek V4 Pro 在 2026 年 9 月 14 日之后继续提供 API 服务，计费方式保持不变。
因此，目前不能再写成“V4 Pro 已经全部路由到 V4.1 Flash”。
十、FAQ：关于DeepSeek V4.1 Flash几个常见问题
Q1：V4.1 Flash真的比V4 Pro更强吗？
DeepSeek 官方表示，在其公布的多项测试中，V4.1 Flash 在性能、费用、速度和整体任务耗时等方面表现优于 V4 Pro，同时官方基准中 V4.1 Flash 在多项 Agentic Coding、自动化和工具使用任务上取得了较高成绩。
但不应该由此推导出“任何任务都强于 V4 Pro”。
模型能力仍然与任务类型、Reasoning Effort、Prompt、工具环境以及测试方法有关。正式替换生产模型之前，仍然应该使用自己的业务数据做回归。
Q2：为什么参数更多，推理成本反而可以更低？
因为总参数量与每 Token 的计算量已经进一步解耦。
V4.1 Flash 的主干规模是 552B，但 Prefill 只激活约 8B，Decode 激活约 16B；同时 CSA2 和 FP4 又大幅压缩了 KV Cache。
因此需要同时看：
不能只根据总参数数量判断运行成本。
Q3：API怎么调用？
DeepSeek 官方 API 当前使用：
官方同时提供 OpenAI 与 Anthropic 兼容格式，因此已有相应 SDK 的项目通常可以通过调整 base_url、API Key 和模型名称完成接入。
如果项目只使用 DeepSeek，并且需要第一时间获得官方原生功能和文档支持，直接使用 DeepSeek 官方 API 是较为清晰的方式。
如果同一个项目还需要同时测试 GPT、Claude、Gemini、DeepSeek 等多个模型，也可以在业务代码上方增加统一调用层。例如将 4SAPI 中转站作为备选接入方式，把多个模型的接口、密钥和模型切换尽量收敛在同一层管理，减少为不同供应商反复配置 SDK 和修改业务代码的工作。
这里的优势主要体现在工程接入和模型切换效率。至于实际请求延迟、稳定性与费用，则应按照具体模型、线路和当前计费规则实际测试；具体模型支持情况也应以平台实时页面为准。
Q4：可以自己部署吗？
V4.1 Flash 权重已经在 Hugging Face 发布，采用 MIT License，公开仓库同时提供了模型配置和相关推理说明。
不过“权重开放”不代表普通单卡服务器可以轻松完成完整部署。
552B 主干加上相关模型组件对显存、存储、网络互联和推理框架都有较高要求。DeepSeek 官方在发布说明中也将大规模部署描述为需要 GPU 集群和存储集群的场景，因此正式自部署前需要单独计算硬件和运维成本。
Q5：1M上下文是真的原生支持吗？
是。
官方模型说明将 V4.1 Flash 的上下文长度列为最多 1M Token。技术报告还指出，通过 CSA2 等长上下文优化，从较短上下文扩大到 1M 时，单 Token Decode 的额外计算增长受到较强控制。
不过支持 1M Context 与“任何 1M Token 请求效果都一样好”是两个概念。
实际业务仍然需要测试长上下文中的检索准确率、延迟、Token 消耗和任务成功率。
十一、真正值得关注的不是552B，而是成本函数变了
DeepSeek V4.1 Flash 最值得看的部分，并不是把总参数从 284B 提高到 552B。
它真正做的是重新拆分推理成本。
CED 在解决：
输入一定需要经过和输出一样多的计算吗？
CSA2 在解决：
每一层真的需要保存一份自己的全局 KV 吗？
Hierarchical Sparse Indexer 在解决：
一百万 Token 的历史，每一个索引层真的都需要重新扫描吗？
FP4 KV 在解决：
每条缓存记录一定需要使用更高精度保存吗？
SWA Bounded Replay 则进一步追问：
所有局部状态真的值得长期写进 SSD 吗？
这些优化叠加之后，才形成了 Prefill 约 8B 激活、Decode 约 16B 激活、890 bytes/token 全局 KV，以及 Persistent KV 约降到上一代八分之一这一组结果。
如果只记住三件事，可以是：
- CED：把长输入的全局计算更多集中在前20层，Prefill 激活约8B，Decode约16B；
- CSA2：通过 Full、Reindex、Reuse 让多个层共享全局 KV 与部分索引结果；
- FP4 + SWA Bounded Replay：继续压缩运行时和持久化 KV Cache，把长上下文存储成本进一步降下来。
至于实际项目如何接入，则属于另一层问题。
只使用 DeepSeek 时，官方 API 能够直接获得原厂文档和原生能力；当项目已经需要同时维护多家模型时，也可以把 4SAPI 中转站等统一接口作为备选方案，将模型切换尽量收敛在调用层。涉及敏感数据、长期生产部署或高并发业务时，还需要继续评估数据处理方式、日志策略、限流、计费和实际可用性。
V4.1 Flash 最有价值的启示或许正是这一点：
模型越来越大，并不意味着每一次推理都必须同比变贵。
当参数容量、实际激活计算和 KV Cache 被拆开设计之后，“模型规模”和“推理成本”之间的关系正在变得越来越不直接。
