内存使用去向不明：MemTotal 8GB 但实际可用常不足 1GB，约 6.35GB 在虚拟机内部无法解释

反馈内容：开发环境疑似 Firecracker microVM（/proc/cmdline 含 init=/firecracker-init，无 PCI，virtio-mmio）。/proc/meminfo 显示 MemTotal 为 8.0GB，但内存去向存在约 6.35GB 的"黑洞"：

进程实际占用：所有进程 RSS 合计约 0.95GB（opencode ~438MB + 机器人进程 ~244MB + searxng ~88MB + 其他）。
可解释内存合计约 1.5GB：AnonPages ~0.93GB + Cached ~0.25GB + Slab/页表/内核栈/buffers 约 0.05GB + MemFree 0.22GB。
差额约 6.35GB 无法观测：MemTotal − 上述可解释项 = 6.35GB，既不在任何进程 RSS 中，也不在内核 slab/页表/缓存中。
实际可用极低：MemAvailable 常只有 300500MB，最低曾到 127MB；无 swap；zone 的 present/managed 与 DirectMap1G 显示存在 5GB+ 的直接映射，疑似被虚拟化层或宿主预留（virtio DMA 缓冲、大页映射或内存 balloon），guest 内用 /proc/meminfo、/proc/zoneinfo、free、/proc/slabinfo 均无法定位去向。
影响：由于实际可用内存严重不足，运行的 NapCat（QQ 机器人）在启动登录阶段发生 native 库段错误（NTSdk/wrapper.node，内核日志 segfault，退出码 11，10 秒内连续崩溃 3 次后主进程退出），需要手工释放 page cache 后才能勉强拉起，稳定性无法保证。

期望效果：说明该 6.35GB 内存的具体去向（若为虚拟化层/宿主预留，请给出 guest 内可观测或可配置的方式）。
提升 guest 实际可用内存，或将 MemTotal 调整为真实可用的数值，避免误导。
提供更高内存规格的实例，使 NapCat 等内存敏感服务能稳定运行，不再因内存不足段错误。

我的 UID：5ed6626d-4d2e-4e0e-abd3-1806d5cc69cf

Start by reproducing the report in the suspected Firecracker microVM and compare /proc/meminfo, /proc/zoneinfo, /proc/slabinfo, free, and the kernel log. Trace the difference between MemTotal, managed memory, and MemAvailable to the guest or host configuration. Done means the missing memory is explained with a guest-observable or configurable source, or MemTotal and instance sizing are corrected so NapCat can run reliably.