dmidecode 是唯一能直接读取 BIOS/UEFI 硬件内存上限的命令，需 root 权限执行 sudo dmidecode -t 16 查 Maximum Capacity，结合 Number Of Devices 和 sudo dmidecode -t 17 查单槽最大容量，最终上限取两者最小值；free 和 /proc/meminfo 仅反映当前识别内存，受 BIOS 设置、内核参数或硬件故障影响，不能代表物理上限。
dmidecode 是唯一能直接读取 BIOS/UEFI 硬件限制的命令，free 和 /proc/meminfo 只反映当前识别到的内存，不是上限。
查主板 BIOS 层面的最大内存容量
执行 sudo dmidecode -t 16 | grep -i "maximum capacity"，输出类似：Maximum Capacity: 64 GB 或 Maximum Capacity: 491520 MB。
这个值是主板固件硬编码的上限，与 CPU 是否支持无关。
-
dmidecode必须用 root 权限，普通用户运行会报Permission denied - 老旧主板、VMware Workstation 或某些 OEM 笔记本可能不提供该字段，输出为空或
Not Specified - 若出现多条
Maximum Capacity，只认Physical Memory Array类型下的那条，忽略Memory Device下的
查实际可用插槽数和单槽最大支持容量
仅看 Maximum Capacity 不够——它可能是理论值，但受插槽数和单槽上限共同约束。需结合 Number Of Devices（插槽数）和每个插槽支持的最大单条容量。
- 先运行
sudo dmidecode -t 16，找Number Of Devices: 4 - 再运行
sudo dmidecode -t 17 | grep -A5 "Size:"，观察已识别插槽的Size:行；如果某槽显示Size: 32768 MB，说明该槽物理上可插 32GB 条 - 真正上限 = 插槽数 × 单槽最大支持容量（不是当前插着的容量），例如：4 槽 × 32GB = 128GB，但 BIOS 显示
Maximum Capacity: 64 GB，则最终以 64GB 为准
为什么 free -h 和 cat /proc/meminfo 不能用来判断上限
MemTotal 值（来自 /proc/meminfo）或 free 输出的 total 列，只表示内核当前“看到”的物理内存总量，它已被三重过滤：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- BIOS 设置关闭了 Memory Remapping（常见于老主板或启用 IOMMU 的场景）
- 内核启动参数加了
mem=（如mem=16G），强制截断识别 - 硬件故障（如金手指氧化、插槽虚接）导致部分内存未被 BIOS 初始化
也就是说，即使主板支持 128GB，但 free 显示只有 32GB，问题大概率不在 free，而在 BIOS 或物理连接。
混插、降频和 SPD 信息的误导性
dmidecode -t 17 中的 Speed: 和 Type: 字段来自内存条 SPD 芯片，不是当前运行状态：
- 混插 DDR4-2400 和 DDR4-3200 时，整机运行在 2400MHz，但
dmidecode仍分别显示各自标称频率 -
Speed: Unknown很常见（尤其笔记本/OEM 机型），不代表内存损坏，只是 SPD 未被正确读取 -
Type: DDR4是硬性门槛——插 DDR5 条进去，BIOS 根本不会识别，dmidecode里连Memory Device条目都不会出现
真正决定能否插满上限的，永远是 BIOS 报告的 Maximum Capacity 和物理插槽兼容性，不是 Linux 软件层的任何缓存或统计值。
