做推理优化这几年我最常被问的一句话就是“你们那个显存到底是怎么省下来的”早先我还会耐心解释半天后来干脆把内部这套方案的演进过程整理成文。从最早只解决“KV Cache 别爆显存”的 DFlash到后来补上数据管线的 DSpark再到今天能把两层能力揉进同一个运行时里的 DFlash2这一路踩坑不少收益也确实大。这篇就把这三者的关系、DFlash2 的核心设计以及怎么在 sglang 这类推理框架里真正把它用起来一次讲清楚。如果你正在做大模型推理部署或者被长序列、高并发下的显存瓶颈折磨过这篇值得看完。1. 一套运行时的两次迭代DFlash、DSpark 与 DFlash2 的定位拆解先说结论DFlash、DSpark、DFlash2 不是三个并列的独立项目更像是一条演进链。DFlash 是第一代显存调度内核DSpark 是围绕它补起来的数据流加速模块而 DFlash2 是把两者整合、并加入显存分页调度与冷热数据管理能力的第二代整体解决方案。很多人第一次听到这套名字容易把 DSpark 联想成某个 Spark 的分布式计算分支其实是两码事。1.1 DFlash 的本质一个针对长序列推理的显存分页调度器早期我们做 LLM serving 时最头疼的就是 KV Cache。序列一长缓存的 key 和 value 矩阵会以惊人的速度吃掉显存。举个例子跑一个 7B 参数的模型fp16 权重大概占 14GB听起来还能接受但一旦并发拉到 32 路、每路上下文长度跑到 32KKV Cache 轻松冲破 100GB单张 A100 的 80GB 直接爆掉。DFlash 第一代的核心思路就是给 KV Cache 做分页调度——像操作系统把物理内存切成页一样把 KV Cache 切成固定大小的块按需分配、不够了就往 CPU 内存甚至 NVMe 上换出。这思路倒不算原创但胜在工程实现足够细致把换入换出的开销压到了很低。不过 DFlash 第一代有个明显的短板它只管显存里的 KV Cache不管数据从磁盘到 GPU 之前那段路。训练好的模型上线之后除了缓存还有 prompt 的 tokenize、batch 组装、请求排队这些环节。序列一长数据预处理反而成了新瓶颈。这就是 DSpark 出现的背景。1.2 DSpark 的定位数据管线的“前端加速器”DSpark 解决的问题很具体让数据在进入模型计算之前不再成为空闲等待的源头。它把 tokenize、padding、batch 拼装、甚至是 LoRA 权重加载这些动作做成一条可流式执行的异步管线。请求进来之后DSpark 会提前把该做的预处理做完数据进入 DFlash 的调度区域时已经是“即拿即用”的状态。我习惯把这两者的关系类比成餐厅后厨DFlash 是负责控制上菜节奏的传菜员保证所有菜都稳稳当当端到桌上DSpark 则是备菜组提前把原料切好、配好传菜员一喊就能出锅。没有备菜组的时候传菜员再勤快也得等厨师现切。对于高并发场景备菜这段时间的累积延迟非常可观尤其是在请求长度差异很大的情况下短的请求可以被立即调度长的请求则要在内存池里等更久如果前端没有做负载均衡很容易出现长尾效应。1.3 DFlash2 背负的使命把调度从“能用”变成“好用”其实第一代 DFlash 上线后我们已经能扛住“长序列高并发”的显存压力了但工程上不美观DFlash 的配置是独立于推理框架的每次接入一个新的 serving 框架都要手动做适配DSpark 又是一个单独的进程数据传递要走共享内存调试起来很麻烦。DFlash2 要解决的问题就是把显存调度和数据管线统一进同一个运行时对外只暴露一个配置入口内部则由统一的内存管理器来协调。DFlash2 相比第一代最核心的变化是引入了显存页的统一映射表和冷热访问统计。简单说它不再只是“显存不够就换出”而是会记录每个缓存块的访问频率、最近使用时间并预测接下来哪些块最可能被访问然后把最可能用到的留在 HBM把冷数据换到 DRAM把冰数据换到 NVMe。这种分层调度策略直接决定了同一块物理显存能支撑多少并发生。2. DFlash2 的核心机制分层内存池、冷热预取与计算图协作第一代 DFlash 也有换进换出但策略很朴素基本就是最久未使用LRU算法。实际跑起来会有个问题某个 batch 里有一条很长的序列它占用的缓存块特别多一旦这条序列暂时不参与解码这些块就会被判定为“闲置”然后换出等它下一轮又需要解码时必须全部换回来这个颠簸开销非常致命。DFlash2 在机制层面做了三件关键事情。2.1 分层内存池把 HBM、DRAM、NVMe 当成统一寻址空间DFlash2 在初始化时会按照配置把 GPU HBM、CPU DRAM、NVMe 三块空间统一纳入一个“虚拟显存地址空间”。每个 KV Cache 块都拥有一个全局编号并不关心物理上放在哪里访问的时候通过一层页表来映射到真实的物理位置。这套做法借鉴了操作系统虚拟内存但它的核心难点在于GPU 的 kernel 不能像 CPU 那样直接缺页中断一旦要访问的数据不在 HBM 里就必须在 kernel 启动之前保证数据已经就位。所以 DFlash2 里有一个核心组件叫 staging buffer专门负责提速换入换出。每次要交换数据时不是一块一块单独搬而是批量地把一批要换出的块从 HBM 拷贝到 DRAM同时把下一批要用的块从 DRAM 拷回 HBM。因为 PCIe 带宽跑的是一次长 burst比多次小传输高效得多实测下来吞吐差距可以到 3 倍以上。2.2 冷热分离与预取策略用数据驱动替代拍脑袋DFlash2 的调度器里内置了一个访问特征分析器会统计每个请求的 beam width、上下文长度、解码阶段等特征并结合最近的访问历史给每个缓存块打一个“热度分”。热度分越高的块越倾向于留在 HBM热度分低到一定程度才允许被换出。这个冷热判断不是静态阈值而是每隔一段时间就重新计算一次参数也可以在线调整。为了减少预取错误率DFlash2 有比较保守的默认配置预取窗口默认是 4 个块只有在显存充裕的时候才扩大到 8。我个人建议如果是刚上手不要把预取窗口调大宁可让某些块“晚一步到位”也尽量不要因为错误预取把真正要用的块挤出去。频繁的预取和驱逐之间如果形成抖动性能会下降得非常难看。我的建议是Threshold 的值可以先从 0.8 起步观察一个高峰周期后再逐步逼近 0.9。DFlash2 在 sdg 阶段会输出每个 block 的命中率当 HBM 命中率低于 95% 时说明换出策略已经紧张了需要调低并发或者增加 HBM 预留空间。2.3 与计算图引擎的深度协作让显存分配“预约式”进行DFlash2 和 sglang 这类框架集成时并不是简单在外部包一层而是会 hook 计算图的节点级调度。在一条 prompt 被真正送入模型计算之前DFlash2 会根据预估的 seq_len 范围向计算图“预约”所需的 KV Cache 块。这样一来模型执行时几乎不会遇到“临时发现显存不够”的情况因为占用在计算之前已经分配好了。这种预约式分配的额外好处是能够更平滑地处理并发请求的波峰。传统的按需分配在请求瞬间大量涌入时会频繁触发换出造成整体吞吐抖动DFlash2 会把这些请求的显存需求排入一个等待队列用巴特沃斯滤波的方式平滑掉短期脉冲。真要来形容这种感觉的话就是从“一张手忙脚乱的食堂打饭窗口”变成了“提前订位的餐厅后厨”每桌菜都在自己的时间片里按节奏出餐。3. 实操落地在 sglang 中开启 DFlash2新手可以直接抄作业DFlash2 目前最推荐的接入方式就是配合 sglang 使用。sglang 本身已经支持了多种后端的调度能力但默认情况下它并不启用 DFlash2 的分层 offload。下面这套步骤是我在一台 8卡 A800 机器上反复验证过的单卡 80GB模型用 Qwen2.5-72B-Instruct量化精度为 FP8序列长度上限 32K供参考。3.1 前置准备与环境检查开始之前先确认三件事情GPU 驱动版本建议不低于 535CUDA 版本建议 12.4 以上太旧的驱动在 NVMe offload 时容易触发不可恢复的 ECC 错误确认磁盘类型是 NVMe SSD且剩余空间至少是模型缓存预期的 2 倍。DFlash2 的 NVMe 换出文件是预分配的空间不够会在运行中段直接报错PyTorch 版本建议 2.3 以上因为 DFlash2 依赖了 torch.cuda._sleep 这个新的内核级等待原语版本太低会退化成 busy waitCPU 占用率会异常升高。检查命令可以参考下面这段python -c import torch; print(torch.__version__, torch.version.cuda) nvidia-smi | grep Driver Version df -h /dev/nvme0n1如果这三项都没有问题就可以继续安装。3.2 安装 DFlash2 并初始化配置DFlash2 的安装包已经发布到了内部镜像源不过使用方式一直都保持为一个 Python 包 一个独立的配置文件。安装很简单pip install dflash22.0.0但装完不算完需要在项目根目录新增一个dflash2_config.json这个文件是 DFlash2 运行时的总配置入口。我第一次用的时候漏了这个文件结果 DFlash2 直接以 fallback 模式运行等于没开。下面是一个适合 72B 模型在 8 卡 A800 上使用的配置{ enable: true, memory: { hbm_reserve_mb: 20480, dram_capacity_mb: 128000, nvme_capacity_mb: 512000, staging_buffer_size_mb: 512 }, kv_block: { block_size: 128, prefetch_window: 4 }, policy: { cold_threshold: 0.8, swap_batch_size: 32 } }几个关键参数我说一下依据。hbm_reserve_mb是保留给模型权重和 activation 的显存72B FP8 的权重大约 72GB但 8 卡并行后每卡承担约 9GB再算上 activation所以我给每卡预留 20GB 是相对宽松的如果你用的是量化更低的模型可以适当放宽到 24GB 甚至 32GB。dram_capacity_mb决定了把 KV Cache 换出后能借到多少系统内存128GB 一般是单机常见配置如果你的机器内存更大建议尽量调高因为 DRAM 的换入换出速度远快于 NVMe。swap_batch_size是一次性批量换出的 block 数建议和张量并行数一致32 是我们反复测试后的甜点值。3.3 在 sglang 启动命令中开启 DFlash2配置文件就位后启动命令里只需要加--dflash2-config dflash2_config.json。下面是完整示例python -m sglang.launch_server \ --model-path Qwen/Qwen2.5-72B-Instruct \ --tensor-parallel-size 8 \ --host 0.0.0.0 \ --port 30000 \ --max-running-requests 128 \ --context-length 32768 \ --dflash2-config dflash2_config.json启动之后观察日志出现类似DFlash2: enabled, total virtual cache size 112.3GB, committed 48.5GB这样的输出就说明 DFlash2 已经成功接管了 KV Cache 的分配。注意如果enable字段你没有显式设置成 truesglang 是不认的日志里会提示 fallback这一点踩坑率极高。启动之后我建议用一个简单的并发压测脚本验证一下实际效果而不是只看显存数字。可以用 sglang 自带的 benchmark 工具也可以写一个小脚本。为方便观察 DFlash2 是否真的触发换出可以在服务运行期间执行grep dflash2_swap查看日志里的换页统计。我遇到过有人配置了半天显存倒是变得很低但吞吐也掉了一半最后发现是冷热阈值设得太激进所有缓存块都被判定为冷数据等于全程在做备份式迁移。经验值是如果 HBM 命中率低于 98%先别急着加并发回看阈值配置。3.4 从 DFlash 第一代升级到 DFlash2 的三个关键变化如果你之前用的是 DFlash 第一代升级到 DFlash2 后有三处调整必须跟上第一环境变量名变了。老版本里常用的DFLASH_OFFLOAD_ENABLE、DFLASH_DRAM_LIMIT这类变量在 DFlash2 里都已经失效统一收进dflash2_config.json改环境变量不会生效。第二第一代的共享内存通信方案被废除了DSpark 的数据输出现在直接通过 zero-copy pointer 传给 DFlash2如果你的脚本里还依赖/dev/shm/dflash这个路径需要一并改掉。第三是 GPU 显存分配方式从按 block 动态分配变成了启动时就一次性预留 HBM reserve所以如果你同时跑别的任务得留意会不会因为 DFlash2 优雅地把空间“霸占”了导致另一个任务启动失败。DFlash2 也提供了hbm_reserve_mb这种手动控制手段不需要的模型推理任务在启动前先规划好。4. 我从 DFlash 切到 DFlash2 后踩过的坑问题排查速查表任何方案在实际落地时都不是一帆风顺的。下面这几个问题是我自己在迁移 DFlash2 过程中真实遇到、并且最终解决掉的记录成速查表供参考。4.1 显存峰值不降反升第一次在 8 卡 A800 上跑起来时我发现显存占用比不开 DFlash2 还要高一度怀疑是自己配置错了。排查之后发现原因是staging_buffer_size_mb设了 1024也就是每张卡多占了 1GB 的固定 staging 区域而在吞吐压力不大时这套备用缓冲根本用不上反倒垫高了基数。解决办法是把 staging_buffer 调回 512MB并把prefetch_window从 8 调回 4显存峰值立刻回落。这里也提醒大家显存占用不是越低越好它要给动态波动留出缓冲带。4.2 输出首字延迟TTFT变长并发压测时发现别的指标都正常但首字延迟偶尔会从 200ms 直接跳到 800ms。定位后发现根本原因在 NVMe 换出路径上当某个大 batch 完成解码后DFlash2 需要把这一大批冷块批量换出到 NVMe而 NVMe 写满一小段高速缓存后写入速度会突然掉到一个很低的值。解决办法是在配置里把swap_batch_size调小从 64 降到 32这样每次换出的数据量更小避免对 NVMe 带宽形成瞬时饱和。首字延迟重新回落到稳定区间。4.3 与 PyTorch 2.x 的分页缓存冲突DFlash2 内部管理了一块大 pagesize 的显存池和 PyTorch 2.x 的 caching allocator 如果遇到一起会出现一种奇怪的现象——模型可以通过 profiling 显示显存占用并不高但只要一分配 activation就会因碎片化导致 OOM。这个问题比较隐蔽后来通过在启动脚本里加PYTORCH_NO_CUDA_CACHE1关闭 PyTorch 自带的分页缓存同时把 DFlash2 的enable开关前的启动顺序调整成先初始化 DFlash2 再加载模型权重终于稳定下来。如果你用的框架不是 sglang而是自己写的 engine也建议遵守这个顺序。4.4 NVMe 异常打满导致整体性能回退DFlash2 会动态把访问频率过低的 block 换到 NVMe 上但如果你跑的是同一批 prompt 反复压测这些 prompt 的 KV Cache 其实一直都很“热”本不该换出。某次我直接把cold_threshold调到了 0.99结果几乎所有块都被判定为冷数据换出数量激增。日志里全是swap_outNVMe 的 iowait 瞬间打满。这个问题的教训是阈值必须依据真实访问分布来设压测场景和真实线上场景的特征差异极大不要为了“更激进”而牺牲稳定。DFlash2 新版本已经加入了自适应的热度分析但如果你用的是 2.0 初始版本还是手动谨慎一点。4.5 几个容易忽视的配置细节第一dram_capacity_mb不是越大越好。虽然 DRAM 比 NVMe 快很多但如果你把系统内存的 80% 以上都划给 DFlash2操作系统本身的 page cache 会受影响数据读取的全局性能反而下降。第二如果你使用容器运行必须给容器显式分配足够大的/dev/shm默认 64MB 是绝对不够的建议至少--shm-size32g这个在输出大量样本时尤其重要。第三所有 DFlash2 相关的文件路径建议用绝对路径避免在 docker exec 或 systemd 环境下出现相对路径定位错误。5. 写在后面这几条经验让我少走了很多弯路DFlash2 这套方案我前后调了快两个月最后留下来的除了各项性能数据还有几条比较朴素的经验。第一调度框架这东西永远不要在压测数据没看完之前就调参。DFlash2 给了很多控制旋钮但每个旋钮之间是耦合的——cold_threshold影响换出频率换出频率反过来影响 staging buffer 的利用率而 staging buffer 又决定了你还能开多少并发。一定要先把默认配置跑通再去看 DFlash2 输出的统计指标基于数据做一处改一处不要凭感觉同时动好几个参数。第二如果你只是想让长序列推理不至于 OOM并不追求极致吞吐那 DFlash2 默认配置加一个开启开关就是你最需要的全部不需要额外折腾。我之前见过有同学对着参数表来回调了好几天结果收益不到 3%纯属浪费精力。它是一个让你在显存和吞吐之间做权衡的工具不是越多配置就越高级。第三也是最想强调的一点上线前一定要在真实流量上跑一轮稳定性测试。DFlash2 的动态预取和分页功能在构造出来的压测数据上表现得很好一旦遇到线上真实的长度分布不均冷热变化幅度会大得多。提前把 NVMe 健康状态、DRAM 余量都纳入监控比任何参数调优都重要。最后再分享一个小技巧DFlash2 有配套的实时监控接口可以看到每一层内存池的使用率和换入换出次数但有点隐蔽需要在dflash2_config.json里显式开启history_enabled: true才有历史曲线。我第一次没开出问题的时候想复盘都缺数据。如果你也准备在生产环境用建议第一次启动就把它打开日志数据不会骗人很多疑难杂症的定位都靠它。