DGX Spark 统一内存UMA显存核算用四项模型估算大模型训练能否装入 128GB 内存池【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本篇指南以 agents 仓库dgx-spark-ops插件中的 UMA Memory Accounting 工作表为核心讲解如何在启动训练前估算模型 微调方法 batch/packing 组合能否装入 NVIDIA DGX Spark 单机的 128GB 统一内存池掌握权重、优化器状态、梯度、激活四项的核算公式与 dtype 字节表学会用四个实测锚点校验估算结果并理解它与 OOM 处置梯、热监控在插件内的协作关系从而把启动前按字节规划内存从口号变成可复制的计算流程。为什么 UMA 场景需要专门的显存核算DGX Spark 的 GB10 芯片没有独立 GPU 显存——CPU 与 GPU 共享同一个 128GB 统一内存UMA池。这带来两个与离散 GPU 完全不同的行为也正是核算工作表存在的前提见 SKILL.mdnvidia-smi/cudaMemGetInfo会低估内存压力甚至什么都不报。它们只报告 CUDA 分配器可见的内存页缓存与 mmap 页面同样消耗同一个池机器完全可能显示还有余量却照样 OOM在某些驱动/配置组合下内存查询直接返回[N/A], [N/A]而非数值。因此在 Spark 上应以free -g作为预算基准而不是 128GB 规格数free -g | awk NR2 {print free:, $4, GB}经验法则是取 free 值扣除数 GB 的操作系统/驱动开销对剩余量做预算。模型加载是一个瞬时峰值而非稳态。加载 safetensors 时会先 mmap 文件再拷贝进 CUDA 张量——加载期间 mmap 页与 CUDA 拷贝同时在池上计费。一个训练时放得下的模型如果余量是按加载后稳态而非这个翻倍瞬态规划的仍然可能在加载阶段 OOM。工作表 uma-accounting.md 的定位是规划数学而非保证planning math, not a guarantee它的输入是参数量、dtype、微调方法输出是一个与已知锚点对比的内存估算当估算被证明过于乐观时按 SKILL.md 中的 OOM Ladder 处置而不是按字节贴边规划——文档明确建议总是保留余量。文件头部还标注了维护纪律Last verified: 2026-07-13当新的模型规模锚点在 Spark 上被验证、或官方 playbook 改变量化默认值时需要刷新这提醒读者该工作表的结论带有硬件与工具链版本前提。核算工作表四项 一个可忽略项总占用 ≈权重 优化器状态 梯度 激活再加上 LoRA/QLoRA 适配器这一近似为零的项。逐项从参数量和 dtype 出发计算再求和。第 1 项权重params × bytes/param按 dtype 取值dtype每参数字节数fp324bf16 / fp162int81int4QLoRA NF40.5一个 70B 模型在 bf16 下约 140GB——在其他任何组件加载之前就已经超出整个池同一模型 4-bitQLoRA下约 35GB。这正是70B 级模型之所以在 Spark 上可行靠的是 QLoRA 而不是 bf16的量化依据。第 2 项优化器状态全量微调要为每个可训练参数携带优化器状态LoRA/QLoRA 只为适配器参数携带因此无论基座多大这一项对它们都可忽略优化器每参数字节数仅可训练参数AdamWfp32 状态84B 动量 4B 方差AdamW 8-bitbitsandbytes≈2量化的动量 方差在 128GB 的机器上adamw_8bit是 Unsloth 的默认值是有原因的——对任何不是仅 LoRA/QLoRA 适配器的 runfp32 变体大约会让这一项膨胀 4 倍。仓库中 lora-qlora-recipes 的超参数参考 给出了optimadamw_8bit的完整训练脚本示例unsloth-trl-mapping.md 也确认该字符串在 Unsloth 与 TRLSFTConfig间一一对应、无需翻译——与本文工作表直接兼容。第 3 项梯度与计算精度同 dtype——通常是 bf16即 2 字节/参数——并且和像优化器状态一样只针对可训练参数。全量微调要为每个权重支付这份开销LoRA/QLoRA 只为适配器支付因为冻结的基座权重从不累积梯度。第 4 项激活最难钉死在单一数字上的一项——它随 batch 大小、序列/packing 长度和架构注意力变体、hidden 尺寸、层数变化而不只取决于参数量。工作表指出比精确估算更重要的是两个抓手梯度检查点gradient checkpointing用重算换内存相比不启用期望在这一项上节省约30%代价是每个被检查点的段多一遍重算。这也是 Unsloth 将use_gradient_checkpointingunsloth设为默认的原因。Packing/序列长度是比 batch 大小更直接的杠杆。这也是 SKILL.md 的 OOM Ladder 把缩短 packing 长度放在缩小 batch之前的原因。第 5 项LoRA/QLoRA 适配器开销秩r的适配器在一个线性层上增加r × (in out)个参数——A是r×inB是out×r两个矩阵合计r·in r·out。在实际使用的秩范围RL 场景 1–32规模化 SFT 最高约 256下这是基座模型规模的千分之几——除非使用异常高的秩否则在工作表里直接取零。四个实测锚点估算之外的一致性校验工作表第二部分是已知在单台 Spark 上跑通的组合用途不是替代公式而是拿新计划去对照它做 sanity check模型规模方法实测总占用备注70BQLoRA≈40GB3 个 epoch 需 30–48 小时70B 靠 QLoRA 而非 bf16 能跑的参考点~120B 级 MoE 模型NVFP4 原生 LoRA≈68GB据 Unsloth 官方 DGX Spark 教程2025-12社区配方nvfp4-lora-spark实验性质不能作为其他 100B MoE 模型的默认假设27BLoRApack ≤1024 时放得下单台 Spark 上的 LoRA 上限——更大的 dense 模型需要多机 Spark 或更小的方法9B全量微调宽裕地放得下全量 FT 的上限——再往上全量 FT 必须换 LoRA/QLoRA 或多机 Spark对上限条目的正确读法是它们是实践中装得下的最大规模而非硬性架构边界——更小的 batch、更短的 packing 或更省的优化器有时能把某条上限再推一点点反过来同一模型类的更重配置也可能远低于上限就失败。超出这四个参考点的组合应回到上面四项公式重新推导并在估算被证明乐观时用 OOM Ladder 验证。实操70B QLoRA 的完整规划序列结合工作表与 SKILL.md 的 Planning Sequence一次启动前的核算按顺序进行读free -g扣除 OS/驱动开销得到预算按 uma-accounting.md 估算权重 优化器 梯度 激活与最接近的锚点70B QLoRA、27B LoRA、9B 全量 FT对比而不是只信估算本身若估算贴近预算先用更短的 packing 或更小的 batch 起步——比 run 中途撞 OOM Ladder 便宜。SKILL.md 给出的 70B QLoRA sanity check 脚本验证公式与 ≈40GB 锚点的一致性params 70e9 weights_gb params * 0.5 / 1e9 # NF4第 1 项 adapter_gb 0.5 # 第 5 项可忽略 total_gb weights_gb adapter_gb # 再加激活 print(f{total_gb:.0f}GB before activations)仅权重一项就落在 ≈40GB 锚点附近——如果同一模型规模的计划估算远超这个数字就是该回查 dtype 与方法的信号。估算乐观了怎么办不要跳级按 SKILL.md 的 OOM Ladder 逐级执行缩小 batch 永远不是第 1 步刷缓冲缓存上一轮 run 或大数据集读取留下的页缓存常常占掉失踪的数 GB 余量零配置代价sync; echo 3 /proc/sys/vm/drop_caches需要 root这是 run 之间的复位动作不是训练中的常规步骤。背后完整诊断见 gotcha-checks.md 的 G3。降 batch 或 packing 长度flush 无效后才动 run 本身的行为优先缩短 packing 长度因为长上下文下它更直接地驱动激活占用。降级方法bf16 LoRA 优先于 QLoRA。前两步仍 OOM 就降一档方向是 bf16 LoRA 而不是反过来——QLoRA 的 bitsandbytes 反量化缓冲是瞬态的 CUDA 侧分配可能先于等量的 bf16 LoRA run 触发 OOM尽管 QLoRA 稳态占用更小。QLoRA OOM 不等于模型放不下。三步走完仍放不下才考虑更小的模型或多机 Spark。插件内的落地preflight 命令与 ops agent这套核算在仓库里不是孤立的参考文档而是dgx-spark-ops插件诊断链的一环spark-preflight.md 命令接收计划中的工作负载如QLoRA 8B, 3 epochs, 8k context驱动 subagent 执行硬件身份确认、G1–G10 检查然后**用 spark-memory-thermal-ops 工作表计算该工作负载的内存余量**最后输出env-report.json含headroom_gb字段与ready/ready-with-warnings/blocked判定。dgx-spark-ops-engineer.md agent 在其第 3 步方法中要求按工作表估算权重 优化器 梯度 激活外加模型加载瞬态峰值与free -g余量而非nvidia-smi对比把任何贴着预算落地的计划标出来并引用 Anchors 表中最接近的锚点而不是裸信估算——与本文的工作表用法完全一致其行为准则中同样写明nvidia-smi的余量数字在统一内存下不可信规划 run 前必须与free -g交叉核对。多小时的 run 还会撞上持续功耗上限配套的 thermal-sample.sh 以 30–60 秒间隔把nvidia-smi的温度/功耗采样写成 CSV与训练日志按时间戳对齐bash assets/thermal-sample.sh 30 thermal.log脚本自带提示持续 ~100W 是平台功耗上限而非配置 bug与 gotcha-checks.md G4 的诊断阈值一致不应为了修复正常平台行为去重调 batch 或精度。启动即失败的场景ABI 不匹配、flash-attn、playbook 过期则由 spark-training-gotchas 覆盖本文的记忆核算假设 job 已经启动。适用边界工作表针对GB10aarch64、SM121、CUDA 13单机 128GB UMA的规划场景多机 Spark 的跨机策略DDP/FSDP、禁用 TP属于 G10 范畴不在本表适用面内。锚点是实践上装得下的经验值而非架构边界且绑定验证时的工具链状态文件标注 Last verified: 2026-07-13换用新量化默认值或新模型规模时应重新验证。估算接近预算时正确动作是启动前收缩 packing/batch而不是启动后再爬 OOM Ladder~120B 级 MoE 的 NVFP4 LoRA 锚点是实验性社区配方不要外推到其他 100B MoE 模型。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
DGX Spark 统一内存（UMA）显存核算：用四项模型估算大模型训练能否装入 128GB 内存池
DGX Spark 统一内存UMA显存核算用四项模型估算大模型训练能否装入 128GB 内存池【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本篇指南以 agents 仓库dgx-spark-ops插件中的 UMA Memory Accounting 工作表为核心讲解如何在启动训练前估算模型 微调方法 batch/packing 组合能否装入 NVIDIA DGX Spark 单机的 128GB 统一内存池掌握权重、优化器状态、梯度、激活四项的核算公式与 dtype 字节表学会用四个实测锚点校验估算结果并理解它与 OOM 处置梯、热监控在插件内的协作关系从而把启动前按字节规划内存从口号变成可复制的计算流程。为什么 UMA 场景需要专门的显存核算DGX Spark 的 GB10 芯片没有独立 GPU 显存——CPU 与 GPU 共享同一个 128GB 统一内存UMA池。这带来两个与离散 GPU 完全不同的行为也正是核算工作表存在的前提见 SKILL.mdnvidia-smi/cudaMemGetInfo会低估内存压力甚至什么都不报。它们只报告 CUDA 分配器可见的内存页缓存与 mmap 页面同样消耗同一个池机器完全可能显示还有余量却照样 OOM在某些驱动/配置组合下内存查询直接返回[N/A], [N/A]而非数值。因此在 Spark 上应以free -g作为预算基准而不是 128GB 规格数free -g | awk NR2 {print free:, $4, GB}经验法则是取 free 值扣除数 GB 的操作系统/驱动开销对剩余量做预算。模型加载是一个瞬时峰值而非稳态。加载 safetensors 时会先 mmap 文件再拷贝进 CUDA 张量——加载期间 mmap 页与 CUDA 拷贝同时在池上计费。一个训练时放得下的模型如果余量是按加载后稳态而非这个翻倍瞬态规划的仍然可能在加载阶段 OOM。工作表 uma-accounting.md 的定位是规划数学而非保证planning math, not a guarantee它的输入是参数量、dtype、微调方法输出是一个与已知锚点对比的内存估算当估算被证明过于乐观时按 SKILL.md 中的 OOM Ladder 处置而不是按字节贴边规划——文档明确建议总是保留余量。文件头部还标注了维护纪律Last verified: 2026-07-13当新的模型规模锚点在 Spark 上被验证、或官方 playbook 改变量化默认值时需要刷新这提醒读者该工作表的结论带有硬件与工具链版本前提。核算工作表四项 一个可忽略项总占用 ≈权重 优化器状态 梯度 激活再加上 LoRA/QLoRA 适配器这一近似为零的项。逐项从参数量和 dtype 出发计算再求和。第 1 项权重params × bytes/param按 dtype 取值dtype每参数字节数fp324bf16 / fp162int81int4QLoRA NF40.5一个 70B 模型在 bf16 下约 140GB——在其他任何组件加载之前就已经超出整个池同一模型 4-bitQLoRA下约 35GB。这正是70B 级模型之所以在 Spark 上可行靠的是 QLoRA 而不是 bf16的量化依据。第 2 项优化器状态全量微调要为每个可训练参数携带优化器状态LoRA/QLoRA 只为适配器参数携带因此无论基座多大这一项对它们都可忽略优化器每参数字节数仅可训练参数AdamWfp32 状态84B 动量 4B 方差AdamW 8-bitbitsandbytes≈2量化的动量 方差在 128GB 的机器上adamw_8bit是 Unsloth 的默认值是有原因的——对任何不是仅 LoRA/QLoRA 适配器的 runfp32 变体大约会让这一项膨胀 4 倍。仓库中 lora-qlora-recipes 的超参数参考 给出了optimadamw_8bit的完整训练脚本示例unsloth-trl-mapping.md 也确认该字符串在 Unsloth 与 TRLSFTConfig间一一对应、无需翻译——与本文工作表直接兼容。第 3 项梯度与计算精度同 dtype——通常是 bf16即 2 字节/参数——并且和像优化器状态一样只针对可训练参数。全量微调要为每个权重支付这份开销LoRA/QLoRA 只为适配器支付因为冻结的基座权重从不累积梯度。第 4 项激活最难钉死在单一数字上的一项——它随 batch 大小、序列/packing 长度和架构注意力变体、hidden 尺寸、层数变化而不只取决于参数量。工作表指出比精确估算更重要的是两个抓手梯度检查点gradient checkpointing用重算换内存相比不启用期望在这一项上节省约30%代价是每个被检查点的段多一遍重算。这也是 Unsloth 将use_gradient_checkpointingunsloth设为默认的原因。Packing/序列长度是比 batch 大小更直接的杠杆。这也是 SKILL.md 的 OOM Ladder 把缩短 packing 长度放在缩小 batch之前的原因。第 5 项LoRA/QLoRA 适配器开销秩r的适配器在一个线性层上增加r × (in out)个参数——A是r×inB是out×r两个矩阵合计r·in r·out。在实际使用的秩范围RL 场景 1–32规模化 SFT 最高约 256下这是基座模型规模的千分之几——除非使用异常高的秩否则在工作表里直接取零。四个实测锚点估算之外的一致性校验工作表第二部分是已知在单台 Spark 上跑通的组合用途不是替代公式而是拿新计划去对照它做 sanity check模型规模方法实测总占用备注70BQLoRA≈40GB3 个 epoch 需 30–48 小时70B 靠 QLoRA 而非 bf16 能跑的参考点~120B 级 MoE 模型NVFP4 原生 LoRA≈68GB据 Unsloth 官方 DGX Spark 教程2025-12社区配方nvfp4-lora-spark实验性质不能作为其他 100B MoE 模型的默认假设27BLoRApack ≤1024 时放得下单台 Spark 上的 LoRA 上限——更大的 dense 模型需要多机 Spark 或更小的方法9B全量微调宽裕地放得下全量 FT 的上限——再往上全量 FT 必须换 LoRA/QLoRA 或多机 Spark对上限条目的正确读法是它们是实践中装得下的最大规模而非硬性架构边界——更小的 batch、更短的 packing 或更省的优化器有时能把某条上限再推一点点反过来同一模型类的更重配置也可能远低于上限就失败。超出这四个参考点的组合应回到上面四项公式重新推导并在估算被证明乐观时用 OOM Ladder 验证。实操70B QLoRA 的完整规划序列结合工作表与 SKILL.md 的 Planning Sequence一次启动前的核算按顺序进行读free -g扣除 OS/驱动开销得到预算按 uma-accounting.md 估算权重 优化器 梯度 激活与最接近的锚点70B QLoRA、27B LoRA、9B 全量 FT对比而不是只信估算本身若估算贴近预算先用更短的 packing 或更小的 batch 起步——比 run 中途撞 OOM Ladder 便宜。SKILL.md 给出的 70B QLoRA sanity check 脚本验证公式与 ≈40GB 锚点的一致性params 70e9 weights_gb params * 0.5 / 1e9 # NF4第 1 项 adapter_gb 0.5 # 第 5 项可忽略 total_gb weights_gb adapter_gb # 再加激活 print(f{total_gb:.0f}GB before activations)仅权重一项就落在 ≈40GB 锚点附近——如果同一模型规模的计划估算远超这个数字就是该回查 dtype 与方法的信号。估算乐观了怎么办不要跳级按 SKILL.md 的 OOM Ladder 逐级执行缩小 batch 永远不是第 1 步刷缓冲缓存上一轮 run 或大数据集读取留下的页缓存常常占掉失踪的数 GB 余量零配置代价sync; echo 3 /proc/sys/vm/drop_caches需要 root这是 run 之间的复位动作不是训练中的常规步骤。背后完整诊断见 gotcha-checks.md 的 G3。降 batch 或 packing 长度flush 无效后才动 run 本身的行为优先缩短 packing 长度因为长上下文下它更直接地驱动激活占用。降级方法bf16 LoRA 优先于 QLoRA。前两步仍 OOM 就降一档方向是 bf16 LoRA 而不是反过来——QLoRA 的 bitsandbytes 反量化缓冲是瞬态的 CUDA 侧分配可能先于等量的 bf16 LoRA run 触发 OOM尽管 QLoRA 稳态占用更小。QLoRA OOM 不等于模型放不下。三步走完仍放不下才考虑更小的模型或多机 Spark。插件内的落地preflight 命令与 ops agent这套核算在仓库里不是孤立的参考文档而是dgx-spark-ops插件诊断链的一环spark-preflight.md 命令接收计划中的工作负载如QLoRA 8B, 3 epochs, 8k context驱动 subagent 执行硬件身份确认、G1–G10 检查然后**用 spark-memory-thermal-ops 工作表计算该工作负载的内存余量**最后输出env-report.json含headroom_gb字段与ready/ready-with-warnings/blocked判定。dgx-spark-ops-engineer.md agent 在其第 3 步方法中要求按工作表估算权重 优化器 梯度 激活外加模型加载瞬态峰值与free -g余量而非nvidia-smi对比把任何贴着预算落地的计划标出来并引用 Anchors 表中最接近的锚点而不是裸信估算——与本文的工作表用法完全一致其行为准则中同样写明nvidia-smi的余量数字在统一内存下不可信规划 run 前必须与free -g交叉核对。多小时的 run 还会撞上持续功耗上限配套的 thermal-sample.sh 以 30–60 秒间隔把nvidia-smi的温度/功耗采样写成 CSV与训练日志按时间戳对齐bash assets/thermal-sample.sh 30 thermal.log脚本自带提示持续 ~100W 是平台功耗上限而非配置 bug与 gotcha-checks.md G4 的诊断阈值一致不应为了修复正常平台行为去重调 batch 或精度。启动即失败的场景ABI 不匹配、flash-attn、playbook 过期则由 spark-training-gotchas 覆盖本文的记忆核算假设 job 已经启动。适用边界工作表针对GB10aarch64、SM121、CUDA 13单机 128GB UMA的规划场景多机 Spark 的跨机策略DDP/FSDP、禁用 TP属于 G10 范畴不在本表适用面内。锚点是实践上装得下的经验值而非架构边界且绑定验证时的工具链状态文件标注 Last verified: 2026-07-13换用新量化默认值或新模型规模时应重新验证。估算接近预算时正确动作是启动前收缩 packing/batch而不是启动后再爬 OOM Ladder~120B 级 MoE 的 NVFP4 LoRA 锚点是实验性社区配方不要外推到其他 100B MoE 模型。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
