400 Gbp 土壤宏基因组：nanoMDBG 6 天、125 GB 内存，选错算法可能要 753 GB

长读长宏基因组最容易出现的误判，是把“数据量大”直接等同于“买更大的服务器”。2026 年 Nature Communications 发表的 nanoMDBG 证明，算法选择同样会把资源差距拉开：在 400 Gbp 的 Nanopore 土壤数据上，nanoMDBG 用 125 GB 内存、6 天完成组装；metaFlye 在同一任务中需要 753 GB 内存、28 天。

这并不是说 125 GB 可以随便找一台电脑跑。400 Gbp 原始 reads、纠错中间文件、组装图、reads 回贴 BAM 和后续分箱仍会占用大量 CPU、内存与磁盘。真正稳妥的做法，是先按测序类型和数据复杂度选 assembler，再做小规模基线和质量验证，而不是只比较谁的 N50 更高。

同一批 ONT reads，资源差距可以超过 6 倍

nanoMDBG 已集成到 metaMDBG，主要面向 Nanopore R10 simplex 长读长。论文还比较了 50 Gbp 人肠道数据和更复杂的土壤数据。下表是论文给出的实际基准，不是对任意样本的耗时保证。

在 400 Gbp 土壤数据中，nanoMDBG 的 correction 阶段用 32 核运行约 16 小时、峰值 74 GB，只占总组装时间约 10%。这说明后续图构建和解析仍是长任务，不能看到纠错结束就判断“快跑完了”。调度时应为整个 assembly 预留连续时间，并保留可恢复输出。

资源预估不能只按 FASTQ 文件大小乘倍数。gzip 压缩率会受碱基质量和序列复杂度影响，同样 100 GB 压缩文件可能对应不同总碱基量；土壤、肠道和 mock community 的物种多样性、丰度跨度和重复结构也不同。咨询或排队时应提供总 reads、总 bases、read N50、质量分布和样本类型，而不是只报“一个 Nanopore 样本”。

正式全量组装前，可以对代表性 reads 子集做环境验收，确认命令、输出目录、版本和监控都正常。但子集运行时间与内存不能简单线性放大到全量：低丰度物种、复杂分支和长重复可能只在数据增大后出现。基线的作用是发现环境与 I/O 问题，不是替代全量资源余量。

先确认数据模式，再写命令

当前 metaMDBG 仓库同时支持 HiFi 和 ONT，但输入模式不同。Nanopore R10 simplex 使用 --in-ont，PacBio HiFi 使用 --in-hifi。一个可复现的 ONT 起点如下：

metaMDBG asm \
  --in-ont reads.fastq.gz \
  --out-dir sample_nanomdbg \
  --threads 32

正式运行前至少记录 metaMDBG 版本、reads 总碱基数、长度分布、平均质量、过滤阈值、线程数和工作目录。论文基准使用的是 v1.2；官方仓库在 2026 年 5 月发布 v1.4，并说明有运行时间、内存和 polishing 更新。新版本可能更快，但不能直接把 v1.2 的数字当作 v1.4 或自己样本的保证。

输入质控要避免两个极端。完全不看 adapters、短 reads 和低质量尾部，会把无效序列带入纠错；过度过滤又可能损失低丰度基因组覆盖。至少保存过滤前后 reads 数、总 bases、长度与质量分布，并把过滤命令写入日志。涉及人源或宿主样本时，还要根据伦理和分析目的决定宿主过滤发生在组装前还是结果阶段，不能默认把敏感 reads 带入共享环境。

环境也应固定：保存 metaMDBG、minimap2、samtools 版本及 Conda/容器清单；同一项目不要中途升级 assembler。

ONT R9、早期高错误率 reads、超长 reads 与 R10 simplex 的误差结构不同。若数据类型不匹配，算法优势可能消失。对于 HiFi，应该走 metaMDBG 的 HiFi 模式，并与 hifiasm-meta、metaFlye 的结果和研究目标一起评估，而不是因为 nanoMDBG 在 ONT 基准中更省资源就跨平台套用。

服务器规划要覆盖“组装之后”

原始 FASTQ 只是第一份数据。组装目录、纠错 reads、临时图、contigs、GFA、reads-to-contigs BAM、coverage 表和 MAG 分箱结果可能同时存在。尤其是 reads 回贴，如果先写巨大 SAM 再排序，会产生不必要的 I/O 峰值。更合理的是流式传给 samtools：

minimap2 -ax map-ont -t 32 contigs.fasta.gz reads.fastq.gz \
  | samtools sort -@ 16 -o reads_vs_contigs.bam
samtools index reads_vs_contigs.bam

组装工作目录应放在吞吐稳定、可持久化的 SSD/NVMe；临时文件可用本地 scratch，但 checkpoint 和关键中间文件不能只放会自动清理的临时盘。共享文件系统拥堵时，CPU 使用率会下降，任务看似“还在跑”却长期等待 I/O。先监控读写带宽和队列，再决定增加线程。

建议在基线任务外层使用 /usr/bin/time -v 记录峰值内存与墙钟时间，同时定期采集 iostat、剩余空间和输出目录增长。只看 CPU 百分比无法区分计算、I/O 等待和内存换页；如果 swap 开始持续增长，应先停止放大全量任务。输出完成后为原始 reads、contigs、配置和关键报告生成校验值，迁移到归档盘后再清理工作目录。

多样本并发也要按峰值算。两份各需 125 GB 的土壤任务同时运行，不能只申请一台 256 GB 节点后让系统自由竞争；还要给操作系统、文件缓存、回贴和下游流程留余量。长达数天的任务应设置日志、磁盘告警和失败恢复检查，避免在第 5 天因空间写满重跑。

更省内存，不等于可以跳过组装质控

2025 年 Nature Biotechnology 对 21 个 HiFi 宏基因组和多种 assembler 的复查指出，长读长组装可出现每 1 亿 bp 超过 40 个错误，包括嵌合、过早环化、单倍型错误、重复和 phantom sequence。论文特别提醒：报告为 circular 的 contig 也可能缺失核心基因组片段。

质量验收最好分三层。第一层看 reads 回贴率、split alignment、零覆盖区和覆盖突变，判断 contig 是否有直接 read 支持；第二层看 CheckM2、GUNC 等完整性与污染指标，判断 MAG 是否像一个一致的基因组；第三层看 GTDB 分类、核心代谢与蛋白完整性，判断结果是否符合生物学背景。任何单一指标都不能替代另外两层。

nanoMDBG 的 2026 论文同样显示方法之间有取舍。ONT 长 contig 的污染比例中位数都较低，但 metaFlye 的污染长 contig 为 2/326，nanoMDBG 为 13/1006；另一方面，nanoMDBG 的 clipping events、零覆盖区域和全长蛋白指标在多个数据集上优于 metaFlye。结论不是“一个工具永远最好”，而是组装后必须把 reads 回贴，检查 clipping、零覆盖、污染、完整性和基因预测。

圆形 contig 也不能直接等同于完整染色体或质粒。至少要核对覆盖是否连续、末端是否有异常 reads split、单拷贝核心基因是否完整，以及近缘参考中应存在的核心功能是否缺失。对关键 MAG，建议保留多 assembler 结果或至少做针对性复核。

如果项目目标是找病毒、质粒或特定低丰度物种，评价标准还要调整。追求最长 contig 可能牺牲保守性；追求最低污染又可能减少可恢复序列。应在组装前写清主要交付是高质量 MAG、移动遗传元件、基因目录还是群落比较，再决定是否并行跑第二个 assembler，以及哪些 contig 值得人工复核。

如果你的长读长宏基因组卡在 nanoMDBG/metaFlye 选择、125/256/768 GB 内存配置、400 Gbp 工作盘、长任务调度、reads 回贴或 MAG 质控，可以准备测序平台与 chemistry、reads 总量和质量、样本类型、现有服务器和目标交付。云生信可先做工具适配与小规模基线，再确认租用环境自行运行、服务器部署交接或委托分析的范围。

联系云生信，咨询长读长宏基因组组装服务器与分析方案

参考资料

• nanoMDBG 原始论文：High-quality metagenome assembly from nanopore reads
• metaMDBG 官方仓库与当前运行方式
• 长读长宏基因组组装错误基准
• metaMDBG HiFi 原始论文与资源基准