直接回答：宏基因组（微生物组）分析这条路线，显卡基本用不上——真正的天花板是内存和磁盘。 决定内存的不是”微生物基因组很小”，而是你要用多大的物种数据库（Kraken2 标准库索引约 103GB，最大档 GTDB 索引约 644GB），以及要处理多少测序数据量。钱应该花在 内存容量、存储容量与本地盘的读写速度上。
这个方向我们见过两种典型误配，方向正好相反：
- 按”深度学习任务”配成多卡 GPU 服务器：宏基因组的分类、组装、分箱、质量评估全是 CPU + 内存 + IO 型工作，一张卡也用不上；
- 按”微生物基因组才几 Mb”配成小内存机器：分类要常驻一本几 GB 到几百 GB 的物种库，组装（metaFlye 官方实测：输入 255G 数据 → 峰值内存 662G）看的是输入数据量，不是物种基因组大小。按基因组大小估内存，一定会低估。
三句话先记住：
- 内存是天花板，且由”数据库档位 + 数据量”两个变量决定——不是由物种基因组大小决定；
- 存储要按”多份数据库 + 原始数据 + 中间文件”一起算：Kraken2 建标准库一项就要约 100GB 磁盘，而课题往往同时留 2–3 个库；
- 数据库不要放网络盘（官方明确不建议 NFS），且内外网隔离的实验室必须提前离线预置——这是交付阶段最常见的”跑不起来”。
一、五类工具一张表：硬件画像
| 工具 | 在流程里的位置 | GPU | CPU | 内存 | 存储 | 最该注意的 |
|---|---|---|---|---|---|---|
| Kraken2（+Bracken） | 读段 → 物种分类与丰度 | 不需要 | 中—高（多线程吞吐） | 高—极高 ★ 第一变量（索引 7.5GB–644GB） | 高（建库约 100GB + 索引 + 归档） | 内存必须装得下数据库；数据库别放 NFS |
| MetaPhlAn | 物种组成与相对丰度（marker 基因法） | 不需要 | 中—高（BowTie2 比对） | 中 | 中（数据库压缩包 3–6GB，解压后更大） | 轻量路线，适合样本多、只要物种谱 |
| MEGAHIT | 宏基因组组装（拼 contig） | 不需要 | 高 ★（长任务，核数决定时长） | 中—高（随数据量与多样性上升） | 高（输入 FASTQ + 中间文件多） | 复杂样本（土壤等）要用官方 meta-large 档 |
| MetaBAT2 | 分箱（contig → MAG） | 不需要 | 中—高 | 中 ★（随 contig 数与样本数） | 中—高（BAM 文件通常很大） | BAM 必须先排序；别用 conda 版 |
| CheckM2 | MAG 质量评估（完整度/污染度） | 不需要 | 中—高（--threads 提速） |
中（官方给了 --lowmem 减半） |
中—高（DIAMOND 数据库 + 报告） | 内存可减半，不必为它顶格配内存 |
一句话概括：这张表里”GPU”一列全是”不需要”；真正要花钱的是内存、存储和本地盘速度。
二、Kraken2：内存由”选哪档数据库”决定，档与档之间差 40 倍以上
Kraken2 是宏基因组”每个样本里有什么菌、各占多少”这一步的主力工具。它的配置逻辑和别的软件不一样——软件本身很轻，重的是数据库。
官方 MANUAL 的 “System Requirements” 写得很直白：
*”Construction of a Kraken 2 standard database requires approximately 100 GB of disk space.”*
*”To run efficiently, Kraken 2 requires enough free memory to hold the database (primarily the hash table) in RAM.”*
- 建标准库：约 100GB 磁盘（官方 2018-01-01 的测试明细是：基因组库文件 42GB + NCBI 分类信息 26GB + compact hash table 29GB）；
- 运行时内存：要装得下数据库（主要是那张哈希表），官方同时提供了
--memory-mapping选项——可以不把整库读进内存，代价是变慢。
而数据库本身有多个档位，官方指定索引站给出的”索引大小”是这样的（索引大小 ≈ 内存/磁盘的量级）：
| 索引档位 | 内容 | 归档大小 | 索引大小 |
|---|---|---|---|
| Viral | RefSeq 病毒 | 0.5 GB | 0.6 GB |
| Standard-8 | 标准库，库上限 8GB | 5.5 GB | 7.5 GB |
| Standard-16 | 标准库，库上限 16GB | 11.2 GB | 14.9 GB |
| Standard | 古菌/细菌/病毒/质粒/人类等 | 79.6 GB | 103.1 GB |
| PlusPF | Standard + 原生动物 + 真菌 | 84.8 GB | 109.9 GB |
| PlusPFP | PlusPF + 植物 | 171.8 GB | 231.5 GB |
| core_nt | GenBank+RefSeq+TPA+PDB（官方称 “Very large collection”） | 245.8 GB | 316.2 GB |
| GTDB v226 | 细菌 + 古菌（分箱流程常用） | 500.9 GB | 644.0 GB |
这张表是售前最该拿出来的一页：从 7.5GB 到 644GB，同一款软件的内存差出 80 倍以上。所以配机前必须问清三件事：
- 要定到哪个层级——门/属够用（
Standard-16这类压缩档往往就够）还是要到种（Standard）甚至株（GTDB）？ - 样本类型是什么——肠道/口腔用
Standard通常够，土壤/水体/发酵样本含植物或原生动物成分时要用PlusPF/PlusPFP，否则目标类群不在库里，结果是”查不到”而不是”算错”； - 一次几个人同时跑——Kraken2 默认把库加载进每个进程自己的内存，3 个人同时跑 103GB 的库，内存就得按 300GB 往上准备（这一条是本项目工程口径，不是官方数值，但它是最容易翻车的地方）。
另外三条官方写明的注意事项，建议直接写进方案：
| 官方原文 | 采购含义 |
|---|---|
| *”we strongly suggest against using NFS storage to store the Kraken 2 database if at all possible.”* | 数据库放本地盘 / NVMe，不要放网络盘 |
| *”Users should be aware that database false positive errors occur in less than 1% of queries, and can be compensated for by use of confidence scoring thresholds.”* | 不是”100% 准”；用 --confidence 阈值压制假阳性 |
*”If these programs are not installed on the local system and in the user’s PATH when trying to use kraken2-build, the database build will fail.”*（指 NCBI BLAST+ 的 dustmasker/segmasker） |
自建库前必须装 NCBI BLAST+，否则建库直接失败 |
还要提醒一句：Kraken2 的输出是分类结果，相对丰度要靠配套的 Bracken 算（官方定位：*”estimate relative abundances within a specific sample from Kraken 2 classification results”*）。要出丰度表就必须一起装 Bracken，这不是可选项。做 16S 项目的客户则用官方特殊库（--special greengenes / rdp / silva），不必上全库。
三、MetaPhlAn：走”轻量路线”的物种谱工具，数据库是它的全部重量
如果课题组只要物种组成和相对丰度、样本量又大，MetaPhlAn（marker 基因法）往往比全库比对更合适——它不需要把每一条读段比到完整基因组库上。官方数据库体积如下（官方下载命令 metaphlan --install）：
| 数据库包 | 官方文件体积 | 说明 |
|---|---|---|
mpa_vJan26_CHOCOPhlAnSGB_202605.tar |
5.6 GB | 当前最新（2026-08） |
mpa_vJan25_CHOCOPhlAnSGB_202503.tar |
4.8 GB | 2025 版 |
mpa_vJun23_CHOCOPhlAnSGB_202403.tar |
3.1 GB | — |
| 玩具库（TOY） | 1.3 MB | 只用于测试环境 |
注意上表是压缩包体积，解压后的 BowTie2 索引通常更大，官方未在同一页给出解压体积。磁盘按”压缩包体积 × 2–3 倍”预留（这是我们的工程口径，不是官方数值），并且老版本库不要随手删——很多课题组需要复现一年前的分析口径。
售前含义：同样是”微生物组分析”，走 Kraken2 全库路线和走 MetaPhlAn 路线，内存档位差一个数量级。所以第一句话该问的不是”要不要显卡”，而是“你们要的是物种谱，还是要能定到株/要做组装分箱”。
四、MEGAHIT 与 MetaBAT2：组装与分箱，官方没给数值，但给了”降资源”的开关
这两个工具是”把菌拼出来”这一段的主力：MEGAHIT 拼 contig，MetaBAT2 把 contig 分箱成 MAG。它们的官方文档都没有给”内存 = X GB”的数值，所以我们从不编造公式，只把官方给出的开关列给客户——这些开关直接决定”同样的机器能不能跑完”。
MEGAHIT（官方 README）：
| 开关 | 官方原文 | 用途 |
|---|---|---|
--kmin-1pass |
*”if sequencing depth is low and too much memory used when build the graph of k_min”* | 低深度数据内存过高时降内存 |
--presets meta-large |
*”if the metagenome is complex (i.e., bio-diversity is high, for example soil metagenomes)”* | 土壤等复杂样本质量优先 |
--continue -o out |
*”resume an interrupted job from out“* |
断点续跑（宏基因组组装动辄跑很久，这项几乎是刚需） |
MetaBAT2（官方 README）的两条硬注意事项，属于”不按它做就一定出问题”：
- *”Be careful to have bams sorted first!”* —— 送入的 BAM 必须先排序；
- *”The conda version of MetaBAT has never been supported and is very out of date.”* —— 不要用 conda 版交付（要按官方源码/发布包安装）。
另外 MetaBAT2 的设计目标是免调参（*”requires virtually no parameter optimization”*），所以不存在”为了调参而加内存”的正当理由——这是客户常被误导的一点。
五、CheckM2：官方给了 --lowmem，内存可以减半
MAG 做完要评估质量（完整度/污染度），这一步用 CheckM2。它的官方 README 罕见地直接写了一个降内存开关：
*”Low memory mode — If you are running CheckM2 on a device with limited RAM, you can use the
--lowmemoption to reduce DIAMOND RAM use by half at the expense of longer runtime.”*
→ 官方口径：--lowmem 把 DIAMOND 的内存占用减半，代价是跑得久一些。 官方没有给”需要多少 GB”的绝对数值，所以正确做法是先按 --threads（官方示例 --threads 30）把速度拉起来，内存不足时用 --lowmem 兜底，而不是为了这一个步骤把整机内存顶格配满。
顺带两条官方耗时口径，可以直接答复”这软件重不重”：源码安装 *”no longer than 5-10 mins on an average computer”*；自检 checkm2 testrun *”should complete in < 5 mins on an average desktop computer”* ——它是一个轻量步骤，不是配置瓶颈。
六、内存到底按什么估？按”数据量”，不是按”微生物基因组大小”
这是本篇最值钱的一段，也是客户最容易算错的地方。
宏基因组客户常说：”微生物基因组才几 Mb，我这机器不用多大吧？”——错的。看两个官方实测口径：
| 工具 | 官方口径 | 含义 |
|---|---|---|
| Flye / metaFlye（官方 benchmark 表） | HMP mock（PB meta，输入 7GB）→ 峰值 72GB；Zymo Even（ONT meta，输入 14GB）→ 129GB；Sheep gut HiFi（输入 255GB）→ 662GB，而组装产物只有 4.2 Gb | 宏基因组组装的内存随输入数据量走，与物种基因组大小无关 |
| NextDenovo（官方 FAQ 公式） | 每个并行子任务 32–64GB；校正子任务 ≈ TOTAL_INPUT_BASES / 4 字节；官方基准配置里人 CHM13（120X）排序一步就要 150GB |
内存按输入总碱基数算 |
所以给宏基因组客户的内存口径应该是：
- 先问一路数据量（每个样本多少 GB、多少样本）；
- 内存 ≈ 单次最大任务的数据量 × 倍数，并留出”并发任务叠加”的余量；
- 拿客户自己的真实数据实测一次峰值内存再定档（这一步我们会在装机后回填台账，而不是拍脑袋给数）。
反过来，Kraken2 这一档的内存是确定可查的——直接按上面那张索引表选，是唯一能”报方案时就写死”的数字。
七、交付前必须落实的四件事（都不在”买硬件”里）
宏基因组是”数据库依赖”最重的一类分析，这四项不落实，机器再好也跑不起来：
| # | 前置条件 | 不落实的后果 |
|---|---|---|
| 1 | 离线预置数据库：Kraken2 索引（含 --max-db-size 压缩档）、Bracken 配套库、MetaPhlAn 库、CheckM2 的 DIAMOND 数据库 |
实验室常无外网 → 流程跑到一半去下载，几 GB 到几百 GB 的库下不下来，直接中断 |
| 2 | 安装 NCBI BLAST+（dustmasker/segmasker） |
官方明确：这两个程序不在 PATH 里，kraken2-build 建库会直接失败 |
| 3 | 数据库与热数据落本地盘（官方不建议 NFS 存库） | 大库在网络盘上随机读，速度与稳定性都不可控 |
| 4 | 线程配额与中间目录规范 | 多人同跑时互相抢核；中间文件写满系统盘，是”昨天还好好的，今天跑不了”的头号原因 |
第 4 条的具体做法，可参考课题组共用一台服务器怎么设：账号、配额、监控；存储分层口径见实验室服务器的存储怎么配。
八、按规模分档（可直接对照预算看）
| 场景 | CPU | 内存 | 存储 | GPU | 备注 |
|---|---|---|---|---|---|
| 单人 / 小样本集，只用压缩档索引（Standard-16 级） | 16–32 核 | 64–128GB | 4–8TB（含 1–2TB NVMe 热区） | 不配 | 先把流程跑通；库选 15GB 档即可 |
| 常规课题组：Standard 全库（索引约 103GB）+ 组装分箱 | 32–64 核 | ≥256GB（库 103GB + 并发与系统余量） | 8–16TB + 独立 work 盘 | 不配 | 别两个人同时开全库，或把内存按并发累加 |
| 大队列 / 多项目并行 / 要定到株（GTDB 索引约 644GB） | 64 核以上或多节点 | 按索引档位单独定（644GB 档要 512GB–1TB 级） | 共享存储 + 统一调度 | 不配（除非另有深度学习任务） | 索引档位先定，再定内存 |
三条判断口径：
- 先定数据库档位，再定内存——这是本方向唯一”能算准”的部分；
- 组装/分箱的内存按输入数据量估，并按”几个人同时跑”叠加；
- 要不要 GPU，只看课题组有没有深度学习/结构预测任务，跟”宏基因组”本身无关。
九、五句可以直接写进方案的结论
- 宏基因组分析流程不上显卡——分类、组装、分箱、质量评估都是 CPU + 内存 + 存储型任务；
- 内存的第一变量是”数据库档位”：Kraken2 索引从 7.5GB 到 644GB 分档，采购前先问”要定到门属还是种株”；
- 组装/分箱的内存按输入数据量估（官方实测：输入 255GB → 峰值 662GB），按物种基因组大小估一定不够；
- 存储要按”多份数据库 + 原始数据 + 中间文件”一起算，Kraken2 建标准库一项就约 100GB，且数据库不放 NFS；
- 离线数据库与 NCBI BLAST+ 属于交付项，不是”用户自己搞定”。
常见问题
做宏基因组分析要配显卡吗？
不需要。 这条流程的四个环节——物种分类（Kraken2/MetaPhlAn）、组装（MEGAHIT/metaFlye）、分箱（MetaBAT2）、质量评估（CheckM2）——官方资料里都没有把 GPU 作为运行条件，它们吃的是 CPU、内存和存储。只有课题组同时在做的深度学习类任务（例如蛋白结构预测、序列大模型）才需要显卡，那属于另一类需求，建议分开评估：只有宏基因组需求时，显卡预算应该省下来给内存和存储。
Kraken2 到底要多大内存？
取决于你选哪档数据库。官方索引站的”索引大小”从 Standard-16 的约 15GB、Standard 的约 103GB，一直到 GTDB 的约 644GB。官方 MANUAL 的口径是”运行时要有足够空闲内存装下数据库（主要是哈希表）”，所以内存应不低于索引大小并留系统余量（这是我们加上了余量的工程口径，官方表列的是索引大小本身，不是运行时 RAM 的保证值）。另外两点要注意：同一时间几个人跑就要按几份库累加内存；内存实在不够可以用官方的 --memory-mapping，代价是变慢。
我们的数据库能放在 NAS 上吗？
不建议。 Kraken2 官方 MANUAL 明确写了 *”we strongly suggest against using NFS storage to store the Kraken 2 database if at all possible”*。大库在本地 NVMe/SSD 上，随机访问延迟低、稳定性好；放网络盘不仅慢，还会因为网络抖动或断连导致任务失败。做法是给数据库单独放一块本地盘（容量按最大档索引 + 建库峰值预留）。
客户说”微生物基因组才几 Mb，机器不用配大”，怎么解释？
这是把参考库/数据量和单个物种基因组大小搞混了。宏基因组组装的内存取决于输入测序数据量：Flye/metaFlye 的官方 benchmark 里，输入 7GB 数据峰值内存 72GB、输入 255GB 数据峰值 662GB——而组装产物（微生物基因组）只有几 Mb 到几 Gb；NextDenovo 的官方公式也是按输入总碱基数分配内存（校正子任务约需”总碱基数 / 4 字节”）。所以正确的口径是：内存按数据量估，不是按物种基因组大小估。
CheckM2 是不是特别吃内存，要按它配机器？
不必。 CheckM2 官方 README 直接提供了降内存开关：--lowmem 可把 DIAMOND 的内存占用减半，代价是运行时间变长；官方也没给出”需要多少 GB”的绝对值。它更接近一个”分钟—小时级”的轻量步骤（官方：源码安装 5–10 分钟、checkm2 testrun 自检 < 5 分钟）。配置瓶颈在 Kraken2 的库和组装/分箱，不在 CheckM2，合理的做法是内存不足时先加 --lowmem，而不是为它顶格配内存。
16S 扩增子项目也要配这么大的机器吗？
通常不用。 16S 项目做的是靶向分析，不需要全物种基因组库——Kraken2 官方提供了 16S 专用库（--special greengenes / rdp / silva），QIIME 2 与 DADA2 也走的是另一套流程（详见16S 扩增子分析的服务器怎么配）。这是售前必须分清的第一件事：扩增子、宏基因组（鸟枪法）、宏转录组，三者的机器档位完全不同。
如果你们正在给课题组或实验室看机器，把 要跑的软件 / 模型、大概几个人用、预算范围 发我一句，我按这个给你一份带参数清单的配置思路——不推销最高配，只帮你把钱花在真正影响出结果的地方。
