脱敏说明文中节点主机名已替换为节点1~节点4。设备型号与内存容量属公开技术信息予以保留。日期2026-07-02集群规模4 台 DGX Spark / ThinkStation PGX 节点用途评估当前集群可用于模型推理、微调、训练的统一内存资源目录一、摘要二、实测内存数据三、系统本身需要预留的内存四、推理场景估算五、训练与微调场景估算六、网络对统一内存使用的影响七、推荐资源规划八、监控建议九、最终结论一、摘要当前 4 台 Spark 节点每台标称128GB统一内存集群标称总量约512GB。从系统实际读取结果看每台 Linux 可见内存约121.69 GiB4 台合计约486.76 GiB。考虑系统本身运行开销后当前实际可用内存约472.06 GiB。如果为系统、驱动、通信库、运行时、缓存和突发开销预留安全余量建议模型工作负载长期稳定使用的统一内存控制在推荐稳定水位约 360-410 GiB 激进可用水位约 430-450 GiB 不建议长期压满460 GiB二、实测内存数据数据来源4 台节点的/proc/meminfo。节点主机名MemTotalMemAvailableSwapTotal节点 1节点1127,600,812 kB123,252,984 kB16,777,212 kB节点 2节点2127,600,812 kB124,031,140 kB16,777,212 kB节点 3节点3127,600,812 kB124,031,404 kB16,777,212 kB节点 4节点4127,600,812 kB123,677,244 kB16,777,212 kB换算为 GiB节点Linux 可见总内存当前可用内存当前系统占用/缓存差值节点 1121.69 GiB117.54 GiB4.15 GiB节点 2121.69 GiB118.29 GiB3.40 GiB节点 3121.69 GiB118.29 GiB3.40 GiB节点 4121.69 GiB117.95 GiB3.74 GiB集群合计项目数值标称统一内存512 GBLinux 可见总内存486.76 GiB当前 MemAvailable472.06 GiB当前系统占用/缓存差值14.70 GiBSwap 合计64.00 GiB说明MemAvailable不是纯空闲内存而是 Linux 估算的“在不明显触发 swap 的情况下可供新应用使用的内存”。DGX Spark / GB10 使用统一内存模型nvidia-smi对传统 GPU 显存字段显示为N/A因此应以系统统一内存和框架实际占用为主要参考。Swap 不应被视为可用于模型的有效内存。模型推理/训练一旦大量进入 swap性能会明显下降甚至出现超时或进程被杀。三、系统本身需要预留的内存即使当前系统很空也不建议把472 GiB全部规划给模型。需要预留以下部分类别建议预留OS、systemd、日志、SSH、后台服务4-8 GiB/节点NVIDIA 驱动、CUDA/NCCL/UCX/MPI 运行时2-6 GiB/节点文件缓存、页表、内核 buffer4-8 GiB/节点推理服务框架开销2-8 GiB/节点多机通信和临时 buffer4-12 GiB/节点安全余量8-16 GiB/节点建议按每台节点至少预留保守预留25-30 GiB/节点 激进预留15-20 GiB/节点对应集群可规划模型内存规划方式每节点模型可用4 节点合计保守90-96 GiB360-384 GiB平衡100-105 GiB400-420 GiB激进108-112 GiB432-448 GiB极限115 GiB460 GiB建议日常按“平衡”水位规划即集群模型占用控制在400 GiB左右。短时间压测可以冲到430-450 GiB但不建议作为长期服务或训练配置。四、推理场景估算4.1 权重占用粗算不同精度下模型权重大致占用精度每参数占用100B 参数权重200B 参数权重400B 参数权重FP16/BF162 bytes186 GiB373 GiB745 GiBFP8/INT81 byte93 GiB186 GiB373 GiBINT4/FP40.5 byte47 GiB93 GiB186 GiB注意真实推理还需要 KV cache、激活、通信 buffer、框架管理开销因此不能只按权重大小判断。4.2 可承载模型规模按当前集群400-420 GiB推荐模型水位估算推理精度建议模型规模说明BF16/FP16160B-200B需要为 KV cache 和运行时留空间INT8/FP8300B-380B取决于量化格式和框架支持INT4/FP4500B权重可放下但速度和通信效率取决于推理框架如果需要较长上下文或较高并发KV cache 会显著增加内存占用模型规模需要下调。经验建议场景建议单用户长上下文推理优先留足 KV cache模型规模保守多用户并发推理控制 batch 和 max context避免 KV cache 撑满离线批处理推理可更接近430-450 GiB激进水位长期在线服务建议控制在360-410 GiB五、训练与微调场景估算训练比推理更吃内存因为除了权重还需要梯度、优化器状态、激活、通信 buffer 等。5.1 全参训练以 BF16 全参训练 Adam 类优化器估算单参数可能需要权重 BF162 bytes 梯度 BF16/FP322-4 bytes 优化器状态8 bytes 或更多 master weights / 其他状态视框架而定实际常见估算可达到12-20 bytes/参数再叠加激活和通信开销。在当前 4 节点上建议训练方式建议规模BF16 全参训练较稳妥10B-20BBF16 全参训练优化充分20B-30B更大模型全参训练不建议除非使用强 ZeRO/FSDP/offload 策略5.2 LoRA / QLoRA 微调LoRA/QLoRA 的内存压力主要来自基座模型权重LoRA adapter 参数激活KV/attention 中间状态optimizer 只作用于少量可训练参数因此它比全参训练更适合当前集群。建议规模微调方式建议规模LoRA BF16 基座70B级别较合理QLoRA 4bit 基座70B-120B可尝试更大模型 QLoRA取决于框架、序列长度和 batch需逐步压测建议先从70B 模型 4bit/8bit 权重 较短 context 小 batch 梯度累积开始验证再逐步增加 batch size 和 context length。六、网络对统一内存使用的影响当前网络复测结果测试结果NCCL 单 rail13.9698 GB/sNCCL 双 rail22.8542 GB/sRoCE 单 railib_write_bw约13.0 GB/s这说明多机通信已经从异常低速恢复双 rail 也能带来明显收益。但需要注意多机推理时tensor parallel / pipeline parallel 都会消耗网络带宽。全参训练时梯度同步和 optimizer sharding 通信会更重。如果模型非常大、层间通信频繁网络可能成为瓶颈。当前双 rail22.85 GB/s对推理和 LoRA 比较友好对大规模全参训练仍需保守。七、推荐资源规划7.1 推理服务推荐配置模型权重 KV cache runtime 总占用 400 GiB 集群预留 70 GiB 单节点模型相关占用 100 GiB适合场景70B BF16/FP16 推理100B-200B BF16/FP16 推理需要控制上下文和并发300B INT8/FP8 推理500B 4bit 推理需确认框架支持与性能7.2 LoRA / QLoRA 微调推荐配置模型 激活 optimizer runtime 总占用 380-420 GiB 单节点峰值占用 100-105 GiB适合场景70B LoRA70B-120B QLoRA小 batch 梯度累积控制 sequence length逐步拉高7.3 全参训练推荐配置优先目标10B-20B 优化后尝试20B-30B 不建议直接尝试70B 全参训练如果要做更大规模全参训练需要FSDP 或 ZeRO-3activation checkpointingoptimizer state shardingmixed precision严格监控每节点内存峰值充分压测 NCCL 通信八、监控建议运行模型前后建议持续观察free-hcat/proc/meminfo|grep-EMemTotal|MemAvailable|SwapTotal|SwapFreenvidia-smi多机任务中建议每台节点都看watch-n1free-h关键告警点现象含义MemAvailable低于10 GiB/节点风险很高Swap 开始明显使用性能会快速下降进程被 OOM kill模型/批量/context 超出可承载范围NCCL timeout可能是网络、内存压力或某节点异常九、最终结论当前集群可用于模型的统一内存资源可以按以下方式理解标称总统一内存512 GB Linux 实际可见486.76 GiB 当前可用472.06 GiB 推荐模型长期稳定占用360-410 GiB 短期激进可尝试430-450 GiB 不建议压满460 GiB 以上推荐优先使用场景70B级别模型推理和 LoRA/QLoRA 微调。100B-200B级别 BF16/FP16 分布式推理。300BINT8/FP8 推理或更大量化推理。10B-30B级别全参训练。当前不建议直接把整个集群当作完整512GB可用模型内存来规划。更稳妥的做法是按400GB左右作为模型工作负载预算再根据实际框架、batch size、context length 和并行策略逐步压测上调。