GitHub: https://github.com/geekchow/deepseek-v41-flash-inference-guide背景本文选自开源学习指南《DeepSeek V4.1 Flash 大规模推理部署实践》。全书用一个贯穿示例串联编程 Agent 通过 Messages 协议发起第三轮请求上下文 10 万 token、带一张截图、以edit_file工具调用结束文中的“第 N 步”即指该示例中的步骤完整场景见 04 贯穿示例。你在哪里第 5 章第 2 篇贯穿示例的第 ②前缀命中、第 ⑤ 的 KV 换入部分、第 ⑨落盘以及“SWA 机器宕机”变体。读完本文你将知道V4.1 Flash 的 KV 缓存为什么分三层、Block KV 为什么放在独立的 3FS 集群而不是本机内存、SWA KV 如何以 1.35 MiB/序列的代价被保存、命中策略的精确公式以及缓存开销如何被重叠掉。开源状态这部分kvcache-store、Entrypoint未开源以下内容全部来自官方 QA 的设计描述。1. 角色回顾Entrypoint请求入口在路由前算出前缀命中长度维护 SWA KV 的位置目录。KVCache Storagekvcache-store 服务 专用 3FSFire-Flyer File System集群持久化 Block KV靠 3FS 自带 GCGarbage Collection垃圾回收回收。出现在示例② 命中 96,896⑤ 换入 KV、拉回 SWA⑨ decode 结束后落盘变体中回退到 96,768。2. 先懂一点模型为什么会有两种 KVV4.1 Flash 采用CEDCausal Encoder-Decoder因果编码器-解码器结构并结合 CSA2Compressed Sparse Attention 2压缩稀疏注意力第二版的跨层 KV 复用arXiv 2609.19969。对推理系统而言只需记住三点Block KV主 KV indexer K长距离稀疏注意力用的压缩 KV按 128 token 一块分页存储。解码器层的 Block KV 由最后一个编码器层的隐状态投影得到所以 prefill 只需在编码器层计算这也是 prefill 每 token 只激活 8B 参数、decode 激活 16B 的原因。常驻显存的全局 KV 只有890 字节 / token约为 V4-Flash 的 1/4。SWA KV滑动窗口注意力的局部 KV窗口 128 token。它不能从 Block KV 推出必须单独保存或重算。YOCOYou Only Cache Onceconsumer 层部分 SWA 层是“消费者”层它们的 SWA 不保存靠 prefill 重算恢复。FP4 格式主 KV 为每 16 个元素一组、e4m3 缩放类似 NVFP4 但没有全局 scaleindexer KV 为 MXFP4每 32 个一组、ue8m0 缩放SWA KV 落盘格式为 MXFP8528 字节 / token。3. 内部设计3.1 三层存放内容介质副本管理者在途的 Block KV 状态 KV推理卡显存HBM—prefill / decode 实例SWA KV本机内存单副本不进 3FSprefill / decode 实例跨机命中经 400G VLANVirtual Local Area Network虚拟局域网拉回分页 Block KV专用 3FS 存储集群应用层不做副本依赖 3FS 自身冗余kvcache-store下图回答三类 KV 分别住在哪里、谁能访问。专用 3FS 集群Prefill 机器 P-42Decode 机器 D-17只查元数据记录位置异步取回GDR 逐层换入400G VLAN 拉回HBM在途 KV本机内存SWA KV 快照HBM在途 KV共享内存换入缓冲Block KV 分页102 纠删码Entrypoint哈希链元数据SWA 位置目录3.2 Block KV为什么用独立存储集群官方给出三个理由任意 prefill 机器可以命中任意前缀——缓存不在本机路由就不必考虑“前缀亲和”避免它与负载均衡打架存储与计算独立扩缩容缓存不受计算节点故障影响——计算节点故障率比存储节点高一个数量级以上。其他要点prefill 侧也用分页 KVdecode 不做 KV offloaddecode 不受缓存容量约束因此也不用 Hi-Sparse但decode 产生的 KV 仍会写盘以提高命中率。3FS 的可靠性设计数据以102 纠删码ECErasure Coding存储每个 EC 组可容忍两个节点同时故障读请求同时发往组内 11 个存储节点任意 10 个返回即可解码用冗余读消除长尾抖动每个存储节点部署一个GC Worker按 LRULeast Recently Used最近最少使用定期淘汰使磁盘占用低于水位线kvcache-store 本身没有过期逻辑。容量与保留期参数数值KV 缓存总容量约 100 PiB SSDTTLAgent 流量 3 天对话chatbot流量 7 天为什么对话流量更长对话流量命中长尾更重少量 KV 被读非常多次。经验上 TTL 约 3 天会让对话流量损失 0.5%–1% 命中率存储与在线 GPU 配比约 14.4 TB / GPU逻辑容量物理容量更大推荐存储服务器20 × 30.73 TB SSD每台至少 40 GB/s 读、5 GB/s 写总容量至少能保留 24 小时数据3.3 缓存开销如何被重叠下图回答匹配、取回、换入三步分别由谁执行、哪一步藏不住。引擎进程3FSFetch 进程kvcache-store(CHECK)Entrypoint引擎进程3FSFetch 进程kvcache-store(CHECK)Entrypoint路由前必须知道命中长度藏不住loop[每一层]哈希链前缀匹配只看元数据命中长度路由到 prefill异步读 Block KV任意 10/11 返回写入主机共享内存换入线程 GDRH2D 第 i1 层前向计算第 i 层匹配Entrypoint 对本地 CHECK 角色的 kvcache-store 做哈希链前缀匹配只查元数据。因为路由前要用到命中长度这一步无法隐藏。取回独立进程异步把 KV 从 3FS 搬到主机共享内存。换入swap-in引擎进程内的线程把共享内存搬到 HBM目标是让逐层 H2DHost to Device与前向计算重叠。由于 CUDA copy engine 处理细粒度 KV 块拷贝性能差换入改用GDRGPUDirect RDMA用 RDMA 网卡打满 PCIe 带宽且不占用 GPU 的 SM。3.4 SWA KV每条序列只存 1.35 MiB存放结构SWA KV 不进分页块而是放在状态缓存state cache里每条序列占一个固定大小的槽位StateBlock分两个区StateBlock [ 存储区SWA前 20 层 | 丢弃区YOCO consumer 层 SWA C2 压缩边界累加器 ca_state / ica_state ]丢弃区靠 prefill 重算恢复C2 压缩窗口边界天然对齐 128 的倍数没有跨边界依赖。存多少state_size_to_disk 20 层 × 134 token × 528 B/token 1,415,040 B ≈ 1.35 MiB / 序列 └ 128 窗口 6 个投机回退余量只在 128 的倍数位置存prefill 结束后序列末尾预留 1 个 token向下取整到 128 的倍数作为存储位置不足一个 128 单元则本轮不存。分块 prefill 中途不存只有最后一块存。decode 期间在显存里另分一个副本区请求每跨过一个 128 边界就把当前窗口在显存内拷贝到副本区请求结束时从最近一次完成的拷贝落存挂载点向下取整到 128 边界。拷贝位置最多越过边界 5 个 token由槽位环形缓冲比窗口多出的 6 个位置吸收。存在哪不进持久化缓存留在产生它的机器内存里。Entrypoint 维护一个逻辑统一、物理上按 key 分片到各 Entrypoint 机器的内存目录记录它在哪台机器命中时若不在本机从远端经 400G VLAN 拉回。SWA KV 与 Block KV 共用同一条 P→D 传输路径。3.5 命中策略精确版原则命中长度由 Block KV 决定最后一块要不要重算由 SWA KV 决定。下图回答给定输入长度 L最终命中长度如何算出。有无输入长度 L命中上限L − 134查 Block KV得 L1128 的倍数区间 L1−128 到 L1有 SWA 快照?命中 L1命中 L1 − 128回退一块重放上限L − 134来自 YOCO 截断要求128 窗口 6 个投机回退 token。回退的 128 个 token 由SWA Bounded Replay在 prefill 中重放机制见 DeepInfer · Prefill 篇。4. 交互契约对端输入输出deepseek-recipe → Entrypointtoken 列表 采样参数—Entrypoint → Prefill LB请求 命中长度决定未命中 token 数也就是计算配额—kvcache-store ↔ Prefill 引擎命中块的位置KV 块3FS → 共享内存 → HBMPrefill / Decode → 3FS新的完整 128-token 块—Prefill / Decode → 本机内存 目录SWA 快照20 层 × 134 token目录项5. ⚓ 回到示例第 ②步算出命中 96,896第 2 轮结束时序列长 97,000。它的 decode 实例在请求结束时把 Block KV 写到 3FS⌊97,000 / 128⌋ 757个完整块 → 覆盖前96,896个 tokenSWA 快照的位置 ⌊(97,000 − 1) / 128⌋ × 128 96,896存在这台 decode 机器我们称为 D-17的内存里目录记录 “key → D-17”。第 3 轮L 100,000。上限L − 134 99,866。Entrypoint 查哈希链前 757 块全部命中L1 96,896 ≤ 99,866。查 SWA 目录区间[96,768, 96,896]内有快照恰在 96,896→命中 96,896。未命中后缀 100,000 − 96,896 3,104 token连同命中长度一起交给 Prefill LB。第 ⑤步缓存部分把 96,896 token 的 KV 搬进显存分配到的 prefill 机器P-42的 Fetch 进程从 3FS 读 757 个块每块同时发往 11 个节点、收齐 10 个即解码写入主机共享内存。引擎的换入线程用 GDR 逐层把 KV 搬进 HBM与前向计算重叠。按 890 B/token 估算96,896 token 的全局 KV 约86 MB——这就是“1/4 体积”在 I/O 上的意义长上下文命中的搬运量很小。SWA 快照不在 P-42 本机 → 按目录从 D-17 经 400G VLAN 拉回 1,415,040 字节。第 ⑨步为第 4 轮做准备decode 期间每跨过一个 128 边界就在显存里拷贝一次 SWA 窗口本轮输出约 700 token 后结束序列总长约 100,700最近一次拷贝位于⌊100,699 / 128⌋ × 128 100,608落存到 decode 机器内存新增的完整块写入 3FS。第 4 轮来时命中长度最多可达 100,608。变体D-17 宕机第 ② 步查 SWA 目录D-17 不可达区间[96,768, 96,896]内没有可用快照→ 命中 L1 − 128 96,768。未命中后缀变为 3,232 token其中最后 128 个“命中但需重放”的 token 只用来重建 SWA KV它们的 Block KV 仍直接复用、不重算也不覆写。代价多算 128 个 token结果正确。6. 故障行为故障影响设计如何应对计算节点宕机其上的在途请求、本机 SWA 快照丢失Block KV 在独立 3FS不受影响SWA 缺失只导致回退一块重放3FS 存储节点宕机—102 EC每组可同时坏 2 个读任意 10/11 即可网络抖动、慢节点读尾延迟冗余读先到先得存储写满—每节点 GC Worker 按 LRU 淘汰到水位线以下跨数据中心部署光纤被施工挖断等可靠性风险技术上可行KV 已大幅压缩按每 8 卡约 400 Gbps 预留互联DeepSeek 实际部署在不同但相邻的数据中心上一篇05.1 deepseek-recipe 下一篇05.3 负载均衡器 返回概念地图 返回专栏目录
