宏基因组做完组装、分箱和质量评估后，很多项目会在最后的物种分类阶段突然卡住：gtdbtk classify_wf 开始运行不久，pplacer 被系统杀掉，或者监控里出现几百 GB 的“内存占用”。前面几十 GB 内存都能完成，为什么分类反而需要更大的机器？
答案不在 MAG 文件本身有多大，而在参考树和分类流程。GTDB-Tk 2.8.0 当前配套 R232 参考数据。官方硬件说明给出的量级是：古菌约 100 GB 内存，细菌约 140 GB；若启用完整细菌树 --full_tree，内存需求可到约 950 GB。R232 参考包解压后也需要约 100 GB 存储。也就是说，128 GB 节点并不是“差一点就够”，而是对细菌默认流程已经低于官方建议。
先分清：真正吃内存的是哪一步
GTDB-Tk 的 classify_wf 会依次完成基因识别、标记基因搜索、比对、ANI 筛查和系统发育放置。前几步可以随输入 MAG 数量增加而增加计算量，但让内存突然抬升的常见节点是 pplacer：它要把查询基因组放到固定参考树上，参考树本身决定了基础内存门槛。
GTDB-Tk v2 曾通过分治策略把完整参考树拆成较小的树，显著降低过往版本的内存压力；但数据库继续扩展后，R232 的默认细菌分类仍需要至少约 140 GB。把旧教程中的“64 GB 或 128 GB 足够”直接套到新版本，最容易造成节点选型错误。
| 场景 | 官方资源量级 | 上机前判断 |
|---|---|---|
| 古菌分类 | 约 100 GB 内存 | 128 GB 节点可作为起点，但仍要给系统留余量 |
| 细菌默认分类 | 约 140 GB 内存 | 128 GB 不够，建议从 192 GB 或 256 GB 节点规划 |
细菌 --full_tree |
约 950 GB 内存 | 属于大内存任务，先确认是否真的需要完整树 |
| R232 参考数据 | 约 100 GB 存储 | 下载包、解压目录、缓存和结果不能只按 100 GB 刚好预留 |
| 1000 个基因组 | 官方示例约 90 分钟/64 CPU | 这是官方硬件测试量级，不是对所有数据的耗时承诺 |
为什么监控显示 280 GB，却未必真的用了 280 GB
官方 FAQ 专门解释了 pplacer 的内存显示。它会先申请一大块虚拟地址空间，再逐步把参考树信息写入物理内存。随后主进程按 --pplacer_cpus 派生工作进程，Linux 使用 copy-on-write，共享只读内存页。监控工具可能把父进程与子进程的映射重复相加，于是单个约 140 GB 的细菌树，在 1 个工作进程时可能被报告为约 280 GB。
判断是否真的内存不足，不能只看 VIRT 或把每个进程的 RES 简单相加。更有用的是同时观察系统可用内存、swap、cgroup/调度器限制和 OOM 日志。如果物理可用内存持续下降并在缓存参考树时被杀，才是实质性不足；如果只是每个派生进程都显示相同映射，可能是共享页被重复展示。
128 GB 节点上，哪些“省内存操作”值得做
第一，先确认版本与数据库匹配。R232 要求 GTDB-Tk 2.7.0 及以上；2.8.0 沿用同一套 R232 数据。不要混用旧环境和新数据库，也不要把别人服务器上的 GTDBTK_DATA_PATH 直接照抄。
第二，除非研究问题明确要求，不要随手加 --full_tree。默认分治树约 140 GB，完整细菌树约 950 GB，两者不是小幅差异。--place_species 也会让已被 ANI 筛中的基因组继续进入系统发育放置，增加运行时间和 pplacer 内存负担，应按输出需求决定。
第三，控制 pplacer 并发。官方建议在内存紧张时尝试 --pplacer_cpus 1；这不能把 140 GB 的参考树压进 128 GB 物理内存，但能减少进程映射带来的调度压力与误判。--scratch_dir 可把内存映射文件放到磁盘，适合内存不足时尝试，但会转化为明显的磁盘 I/O，临时盘必须有空间且速度足够。
第四，利用 ANI 筛查减少后续放置。2.7.0 以后，R232 带有预构建的 skani 数据库，存储占用从早期 R232 的约 198 GB 降到约 98 GB。官方测试显示，ANI 筛查在合适数据集上可减少 25%—60% 的计算时间；但新物种比例高时收益会变小，不能把它当作固定加速承诺。
拆成小批次，为什么仍可能爆内存
把 1000 个 MAG 拆成 10 批，每批 100 个，确实能降低部分基因识别、ANI 比对和结果管理压力，也便于失败后重跑；但每一批进入细菌参考树放置时，仍要加载同一套树。因此，拆批可以缩短单次队列、控制临时文件，却不能把约 140 GB 的基础门槛变成 14 GB。若所有小批次同时启动，反而可能让多份参考树竞争内存和磁盘。
更稳妥的做法是先按细菌、古菌和未定域结果查看流程输出，再让大内存步骤串行执行。团队服务器上应把 GTDB-Tk 作为“大内存队列”管理：限制同节点并发，单独设置临时目录，保留版本与参考库记录。这样做的价值不是让一个任务看起来更快，而是避免两个 140 GB 作业同时落在 256 GB 节点上，最终双双被杀。
还要区分“程序结束”和“分类可信”。分类完成后应检查 gtdbtk.bac120.summary.tsv、gtdbtk.ar53.summary.tsv、失败与过滤记录，以及 summary 中的分类方法、ANI、AF 和 warning。当前默认物种判定通常使用物种 ANI 半径（常见约 95%）和最低 AF 0.5；处于边界、标记基因不足或质量较差的 MAG，不能因为流程跑完就强行解释到物种水平。
一个可复用的资源记录至少包括：任务 ID、输入 MAG 数、版本、数据库 release、CPU、申请内存、--pplacer_cpus、临时盘位置、峰值 RSS、用时和退出状态。下一批数据直接按实测记录排队，比只保存一条成功命令更有价值。
一套更稳妥的上机顺序
- 记录 GTDB-Tk 版本、GTDB release、MAG 数量、细菌/古菌比例和运行参数。
- 先执行
gtdbtk check_install，确认依赖和参考包完整，再检查参考包 MD5 与环境变量。 - 用少量代表性 MAG 试跑，但要知道小批量只能测试环境，不能消除参考树的基础内存门槛。
- 运行时分别记录系统可用内存、最大常驻内存、临时目录增长和 OOM/cgroup 日志。
- 根据任务选择节点：默认细菌分类优先考虑 192—256 GB 内存；完整树则应按接近 1 TB 的大内存节点单独排队。
GPU 通常不是这里的关键。GTDB-Tk 的主要瓶颈在 CPU、内存、参考数据读取和临时盘。给 128 GB 机器加一张高端显卡，并不能替代 140 GB 以上的可用内存。多人共用服务器时，还要把“机器总内存”和“作业实际申请内存”分开：节点有 256 GB，但调度器只给任务 128 GB，依然会失败。
把配置问题提前算清楚
如果你的 MAG 已经完成分箱，却在 GTDB-Tk 分类阶段中断，可以准备软件版本、GTDB release、MAG 数量、命令、报错片段、节点内存和临时盘信息。云生信会先判断是版本/数据库不匹配、真实内存不足、进程映射误读、调度器限额还是磁盘 I/O，再沟通服务器环境、部署支持或委托分析的适用范围。
