DeepSeek V4.1 Flash：显存杀手，本地能跑吗？

V4.1 Flash 和 V4 Flash 差在哪？

V4.1 Flash 是全新架构，不是 V4 Flash 的小修：层数从 43 减到 40，总参数从 284B 涨到 769B，解码激活从 13B 涨到 16B，原生带视觉。 三个版本的关键差异：

能力上的差距是实打实的：官方评测里 V4.1 Flash 在 Terminal Bench 2.1 拿到 90.6 分（V4 Flash 82.7、V4 Pro 87.9），DeepSWE v1.1 解决率 74.2%（V4 Flash 54.4%），Codeforces 评分 3471。DeepSeek 自己的结论是「V4.1 Flash 在性能、成本、速度上全面超过 V4 Pro」，所以 API 上 deepseek-flash 已经指向它，deepseek-v4-pro 也将从 9 月 14 日中午起路由到 V4.1 Flash，直到 V4.1 Pro 发布。

来源：模型卡、技术报告、DeepSeek API 文档。

511 GB 权重由什么组成？

Engram 查表占了 189 GiB，专家占 260 GiB，两者加起来 94%，都不能砍。 vLLM 团队给出的原生 checkpoint 构成如下（来源）：

两点对本地部署很关键：

• 专家原生就是 4-bit。 社区常见的「Q4 量化」对 V4.1 Flash 的专家部分几乎不再压缩，只能靠 Engram 和注意力层再降精度。所以 V4.1 Flash 的 GGUF 出来以后，Q4 档体积不会像其他模型那样砍到原生的 1/4，估计仍在 400 GB 上下。
• Engram 原则上可以放硬盘，但要等运行时适配。 它是按 2/3/4-gram 哈希查表的稀疏访问：两个模块各 8 个哈希头，每个 token 一共查 48 行、读约 12 KB，行为像词嵌入而不是矩阵乘；查哪些行只由输入 token 决定，整段提示词的地址在前向开始前就能全部算出、整批预取。技术报告 2.4.2 节写明官方推理就是把表放在主机内存、通过 RDMA 后台预取，不占显存；换成 NVMe 只是延迟从微秒变成百微秒，解码 10 tokens/s 只需 120 KB/s 的读带宽。所以规划本地内存时可以把这 189 GiB 从预算里拿掉，只留 NVMe 空间。前提是运行时实现「按需从磁盘查表」这个算子，截至 9 月 10 日 llama.cpp、vLLM、MLX 都没有，官方参考代码也是整表加载进内存。

下表是本站模型库按通用公式算出的显存需求。模型库沿用官方口径，参数量记 552B 骨干、不含 Engram，激活参数记「8 / 16」；Q4 一列假设的是尚不存在的 Q4_K_M GGUF，真实体积会比它大：

注意 8K 和 128K 两列的数字几乎一样：V4.1 Flash 的全局 KV cache 每 token 只有 890 字节，128K 上下文才 0.11 GiB，1M 上下文 0.87 GiB。这是本站模型库里第一个 KV cache 可以忽略不计的模型，原因见下一节。

为什么叫它显存杀手：KV cache 去哪了？

「显存杀手」杀掉的是 KV cache 这一项：V4.1 Flash 把每 token 的全局 KV 压到 890 字节，1M 上下文不到 1 GiB，上下文长度从此不再决定显存。 先看它和其他模型的差距，KV 每 token 字节数按各模型的注意力结构计算，V4 Flash 取官方「V4.1 是它的 1/4」的口径：

按 DeepSeek 自己的图，这个数字比 V1 时代小了 437 倍。技术报告 2.3 到 2.4 节给出的四步压缩，每一步都是架构层面的，不靠量化损失换来：

1. KV 是 512 维潜向量，存成 FP4。 延续 MLA 的思路，每个 token 每层只存一条 512 维的压缩向量，不存 64 个头各自的 K 和 V；V4.1 进一步把它用 E2M1 格式存储，每 16 个通道配一个 E4M3 缩放因子，比 V4 的 FP8 再减半。为此在后训练里做了量化感知训练。
2. 40 层只有 4 层真正产出 KV。 CSA2 把每层设成 Full、Reindex、Reuse 三种模式之一，配置文件里 kv_source_layer_ids 只有第 2、8、14、20 层是 Full 模式，其余层复用它们的 KV 和稀疏索引，这就是「跨层复用」。
3. 编码器每两个 token 合成一条。 编码器 18 层 CSA2 的压缩比是 2，全局 KV 的条数是 token 数的一半；解码器 20 层的 KV 由编码器最后一层的输出投影得到（CED），不再单独存。
4. 本地注意力窗口固定 128。 滑动窗口那一份 KV 用 FP8 存，但只保留最近 128 个 token，40 层加起来几 MB，和上下文长度无关。

计算侧同样不随上下文线性增长：全局注意力只对索引器选出的 512 个位置做，解码器还把候选范围限制在前一个 Full 层给出的候选池里，所以 1M 上下文不只是「装得下」，也「算得动」。

落到本地部署上，这意味着三件事：

• 上下文长度从显存预算里消失。 一张 24GB 卡跑 Qwen3.8 27B，上下文开到 32K 就要给 KV 留 8 GiB；V4.1 Flash 在卸载模式下的 7 GB 显存是常数，8K 和 1M 一个样。模型页「什么显卡能跑」一表里的建议上下文直接给到 128K，原因就在这里。
• 多会话和状态存盘几乎免费。 一个 20 万 token 的 agent 会话只有 178 MB 全局 KV，llama.cpp 那种把 slot 存盘再恢复的做法可以按会话随手做；服务端并发多路长会话也不再被 KV 卡住，这正是 DeepSeek 把 API 价格压下来的底气。
• 但它杀不掉权重。 511 GB 的权重一个字节都没少，显存需求只是从「权重 + 越来越大的 KV」变成「权重 + 几乎为零的 KV」。所以本地能不能跑，问题从显存挪到了内存和硬盘，下面三条路线讨论的全是权重往哪放。

CED 架构对本地推理意味着什么？

Causal Encoder-Decoder（CED）把预填充的工作量砍了一半，但解码一点没省；对本地用户，它改善的是长提示词的等待时间，不是每秒吐字数。 技术报告 2.2 节的机制是：

1. 40 层被分成 20 层「因果编码器」和 20 层「解码器」。解码器各层的全局 KV 不再由自己那一层的隐状态算出，而是从第 20 层的输出直接投影得到。
2. 于是预填充（处理提示词）只需要跑前 20 层，每 token 只激活 8B 参数；解码（生成回复）仍要跑满 40 层，激活 16B。
3. 解码器的滑动窗口注意力（SWA，窗口 128 token）仍按层计算，所以预填充结束时要把提示词的最后 128 个 token 再过一遍解码器，重建解码器的 SWA 状态。这一步叫 SWA Bounded Replay，代价固定为 128 token，与提示词长度无关。

落到本地部署上：

• 长提示词的预填充成本约减半。 走专家卸载时，预填充要把每层激活的专家权重从内存搬进显卡，V4.1 Flash 只搬 20 层、8B 参数，而 V4 Flash 要搬 43 层、13B。给 agent 喂几十 KB 的代码或文档，这一段等待会明显短于 V4 Flash。
• 解码速度不受益，反而更慢。 解码激活 16B 比 V4 Flash 的 13B 多 23%，在内存带宽被卡死的卸载模式下，预估约 9 tokens/s，V4 Flash 约 12 tokens/s。
• 会话状态几乎不占空间。 全局 KV 每 token 890 字节，一个 20 万 token 的 agent 会话只有 178 MB，llama.cpp 那种把 slot 存盘再恢复的用法会变得非常便宜。SWA 状态则不需要持久化，恢复时按官方做法回放最后 128 个 token 即可。
• 单机用户可以比官方更精确。 官方服务端的 SWA 回放是近似重建，技术报告第 6 节承认在缓存恢复边界上可能有未知退化。单用户的本地运行时不需要这个近似：把 SWA KV 一直留在内存里就是精确状态，40 层 × 128 token 的 SWA 缓存只有几 MB。
• 运行时实现难度高于 V4。 预填充和解码走不同的层数，再加上分层稀疏索引器、Engram 哈希查表、FP4 KV 反量化和 mHC 残差流，llama.cpp 要新写的图结构比支持 V4 Flash 时多得多。V4 Flash 0731 发布当天 unsloth 就建了 GGUF 仓库，V4.1 Flash 不能照这个节奏预期。

三条部署路线各要什么条件？

数据中心一条路今天能走，Mac Studio 和消费卡两条路都在等软件。 各设备在本站公式下的预估速度：

带星号的是专家卸载速度，前提是 llama.cpp 已支持；本站模型库按官方 552B 骨干参数计算、不含 Engram，卸载所需的 304 GB 内存和下文布局 B 的原生 280 GB 是同一口径。DGX Spark 只有 128GB 统一内存，表里的卸载数字对它不成立。

路线一：vLLM 多卡数据中心，今天就能跑

vLLM 0.30.0 起提供专门的 Docker 镜像，官方在四种硬件上验证过：8 卡 H200 节点（1128 GB 显存）、GB200 NVL4 单托盘（768 GB）、GB300，以及 AMD MI350X。vLLM 给出的最低显存是 614 GB（511 GB × 1.2 余量），所以 4 卡 H200（564 GB）不够；A100 一代没有 FP8 和 FP4 支持，不在验证列表里。DeepSeek 自家推理代码的示例也是 8 路张量并行。首次加载要读完 511 GB 权重，官方把引擎就绪超时设成了一小时。

路线二：Mac Studio M3 Ultra 512GB，等 MLX 支持 Engram 放硬盘

统一内存 512GB 是家用设备里唯一接近的容量。把 476 GiB 原生权重整个装进去不行：macOS 默认只允许 GPU 占用约 75% 的统一内存，即便用 iogpu.wired_limit_mb 调到极限也只剩几 GB 余量。但如果 Engram 留在 SSD 上，内存里只剩专家、注意力和词嵌入，原生 FP4 精度约 290 GiB，512GB 装得下还有余量，不需要再压专家精度。所以 Mac 这条路等的不是低比特版本，而是 MLX 实现 V4.1 架构加磁盘查表；mlx-community 截至 9 月 10 日还没有任何 V4.1 转换。等版本出来后，按 819 GB/s 带宽和 16B 激活推算，解码约 40 tokens/s，会是家用设备里最快的方案。

路线三：消费卡或工作站卡 + 大内存，等 llama.cpp

把 Engram 放硬盘之后，剩下的专家、注意力和词嵌入有两种放法，都是 llama.cpp 现有的机制，只等它支持 V4.1 架构：

布局 A 的解码按显卡带宽走，本站公式下 RTX PRO 6000 约 80 tokens/s 量级，多卡拆分会打折；布局 B 被内存带宽卡住，双通道 DDR5 约 9 tokens/s，8 通道 DDR5 的带宽约为双通道的四倍，能到 20 到 30 tokens/s。两者之间还有折中：哪 6 个专家被激活是每个 token 由路由决定的，没法只把「激活的专家」放显存，但可以把前 N 层的全部专家留在显卡上，其余层卸载，llama.cpp 的 --n-cpu-moe 就是这个语义；原生 FP4 下每层专家约 6.8 GB，24GB 卡能多留两层，96GB 的 PRO 6000 能留 12 层。

坏消息是 llama.cpp 仓库里截至 9 月 10 日没有 V4.1 架构的 PR，磁盘查表算子也不存在，这两条布局目前都走不通。已经有大内存工作站的读者，先用 V4 Flash 0731 的 GGUF 把卸载流程跑通，见显存不够，加内存有用吗。

现在能用什么命令启动？

只有 vLLM 一条命令可用，其余运行时还没有对应的模型文件。 8 卡 H200 节点上按 vLLM 官方 recipe 启动（来源）：

docker run --gpus all --privileged --ipc=host -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e VLLM_ENGINE_READY_TIMEOUT_S=3600 \
  -e VLLM_USE_RUST_FRONTEND=1 \
  vllm/vllm-openai:deepseekv41-flash-0909 deepseek-ai/DeepSeek-V4.1-Flash \
  --tokenizer-mode deepseek_v41 \
  --tensor-parallel-size 8 \
  --tool-call-parser deepseek_v41 \
  --enable-auto-tool-choice \
  --reasoning-parser deepseek_v41 \
  --mm-encoder-tp-mode data

GB200 NVL4 单托盘把 --tensor-parallel-size 改成 4；AMD 卡换用 vllm/vllm-openai-rocm:deepseekv41-flash-0909 镜像。只跑文本任务时加 --language-model-only，跳过视觉编码器并把这部分显存让给 KV cache（它和 --mm-encoder-tp-mode data 二选一）。

两个容易踩的坑：

• 默认开启思考模式，推理强度 50。请求里 max_tokens 给得小，预算会全花在思考轨迹上，返回空内容和 finish_reason=length，看起来像模型坏了。要么在 chat_template_kwargs 里设 thinking: false，要么把 max_tokens 放大。
• 推理强度只接受 low / high / xhigh / max 或 1 到 100 的整数，medium 和 minimal 会被拒绝。

Ollama、LM Studio、llama.cpp、MLX：截至 9 月 10 日都没有可用文件，出现后本站模型页会更新启动命令。

该等还是该买？

不要为 V4.1 Flash 买硬件。 三个理由：

• 它的能力优势集中在长上下文 agent 任务，这类任务一次会话几十万 token，本地卸载模式 9 tokens/s 的解码速度撑不起来，走 API 用 deepseek-flash 更便宜也更快，算账方法见本地部署要花多少钱。
• 家用能跑满血的 DeepSeek 仍然是 V4 Flash 0731：Q4 GGUF 155 GB，一张 24GB 卡加 192GB 内存就能卸载运行，配置方案见本地部署 DeepSeek 该选什么显卡。
• 「Flash」不再意味着小。V4 Flash 是 284B，V4.1 Flash 是 769B，命名指的是 API 档位而不是体积。等 V4.1 Pro 发布时，再判断是否值得为整个 V4.1 系列升级硬件。

已经有 256GB 以上内存工作站或 Mac Studio M3 Ultra 512GB 的读者，值得盯住 llama.cpp 的 V4.1 支持和 mlx-community 的转换进度：一旦 GGUF 或 MLX 版本出现并支持 Engram 放硬盘，这两类机器是最先能跑起来的家用设备。