在 2x DGX Spark 上部署 DeepSeek v4 Flash 0731 — 5-7 GB 操作系统余量，你会如何降低 VRAM 占用并增加操作系统可用 RAM？

大家好，我正在一个由 2 台 DGX Spark 组成的集群上部署 DSv4Flash 0731，但一直遇到一个棘手问题：留给操作系统/缓存的 RAM（统一内存）几乎为零。我非常希望听到社区的反馈，看看我能做些什么来获得更多内存余量。DGX 存在一个问题：当 RAM 填满时系统会锁死，因此更大的余量可以让系统更加稳定。问题：在 2 台 NVIDIA DGX Spark 上以完整 1M 上下文运行 DeepSeek-V4-Flash-0731（304B MoE）时，我们如何释放更多内存给操作系统？ 硬件 2 台 DGX Spark（GB10 Grace Blackwell，SM121）：每台 128 GB 统一内存（可见约 121.7 GiB），约 273 GB/s 带宽，20 核 ARM，4 TB NVMe，DGX OS（无头模式，已禁用 GUI/桌面服务） 直连 ConnectX-7 网络，双链路，RoCE，MTU 9000；NCCL 确认使用 IB 传输（约 200 Gbps） 模型 DeepSeek-V4-Flash-0731，原生 FP8 检查点（167 GB safetensors） 总参数 304B，MoE：每层 256 个路由专家，每个 token 6 个激活专家 + 1 个共享专家，43 层 稀疏注意力（indexer top-k 512）+ 内置 KV 压缩（按层分组 4x / 128x），YaRN 校准的 1M 上下文 服务栈 vLLM 0.26.1rc1 从源码构建（DeepSeek V4 SM12x 支持 PR），CUDA 13.0 工具链，运行在容器中 张量并行 TP=2 跨两台机器（--nnodes 2，多进程后端，无 Ray） DSpark 推测解码（方法 "dspark"，num_speculative_tokens=5）——约 80% 草稿接受率 llama-swap 作为统一的 OpenAI 兼容端点/模型路由器；Open WebUI 前端 关键引擎参数 --kv-cache-dtype fp8_ds_mla（8 位打包，584 字节/token/层；根据模型压缩，实测跨所有层有效约 3.9 KB/token） --max-model-len 1048576（完整 1M） --gpu-memory-utilization 0.82 ← 这个旋钮正是问题所在 --max-num-batched-tokens 4096（更大的值会通过微块大小的压缩器状态缓存组导致每请求块记账爆炸——每个 4-token 块固定占用约 1 MB 的 slab） --max-num-seqs 6，启用前缀缓存 + 分块预填充，CUDA graphs 开启 分词器/工具/推理解析器：deepseek_v4 每节点内存剖析（实测） 权重 + 激活 + CUDA graphs：约 87–89 GiB（不可移动；TP=2 下每节点权重约 83.5 GiB） KV 缓存池：约 11.2 GiB → 约 1.6M token 容量（1M 上下文下 1.53 倍并发） 留给操作系统 + 服务：空闲时约 5–7 GB，在马拉松式 1M 上下文会话期间降到约 2–3 GB（主机侧缓慢泄漏，持续长上下文负载下约 100–200 MB/h） 看门狗：earlyoom 绝对下限 1.5/1.0 GiB，自定义优雅卸载器在 2 GB 触发，vm.min_free_kbytes=2 GiB，swap 关闭（在统一内存上，swap 会把干净的 OOM 杀死变成 30 分钟的活锁） 性能（让你知道我们不想失去什么） 单流解码 82 tok/s，预填充约 1,400 tok/s，146K token 大海捞针测试 3/3 通过 我们已经排除了以下方案（请不要再建议这些） 将 gpu-memory-utilization 降低到 0.82 以下：在 1M 上下文下 KV 池会触及 vLLM 的单请求服务下限，拒绝启动 单独降低 max-model-len：什么也释放不了——池的大小由预算百分比决定，而不是上下文 对模型容器设置 cgroup/docker 内存上限：会在文件支持页面上产生回收循环，并饿死 sshd（试过，比不试更糟） 启用 swap：在统一内存上会导致整机活锁 CPU 卸载 / --cpu-offload-gb：在统一内存（单一内存池）上没有意义 LMCache 磁盘层：不兼容——对打包的 fp8_ds_mla 布局断言失败（"kv_cache last dim must be 584, got 512"） 从 NVMe 流式加载权重：带宽差距 40 倍，实测约 14 tok/s，而当前是 82 真正的问题 在相同的统一内存机器上，哪些主机侧或 vLLM 侧的杠杆能真正减少常驻开销？具体好奇以下几点： 缩小 vLLM 主机进程的占用空间（API 服务器 + 引擎 + worker 进程的 RSS） 针对 2 节点 TP 的 NCCL 缓冲区/注册调优（NCCL_BUFFSIZE 等）——能释放 GB 级还是只有 MB 级？ torch.compile / inductor / CUDA graph 内存：在 Blackwell 上，--enforce-eager 的内存节省是否值得延迟损失？有没有人对大型 MoE 做过实测？ 有没有人找到长时间上下文 vLLM 服务中主机 RSS 缓慢增长（约 100–200 MB/h）的来源？ 有没有可以安全裁剪的 DGX OS / GB10 特定保留（驱动、carveout）？ 非常感谢你们的所有回复！！