直接回答：从测序读段到变异结果，主力工具是 BWA（比对）、samtools（比对文件处理）、bcftools（变异文件处理）和 Salmon（转录组定量）——这四个工具都不使用显卡。钱应该花在 CPU 核数、内存容量，以及存储的容量与读写速度上。
这个方向的误配非常集中：只要课题组标题里带”测序””生信””组学”，就容易被按”深度学习任务”配成多卡 GPU 服务器，而实际上整条流程里一张卡也用不上；反过来，把预算全压在 GPU 上之后，存储容量和读写速度反而成了真正的瓶颈，流程天天卡在写 BAM、写中间文件上。
三句话先记住：
- 全流程不吃显卡：BWA、samtools、bcftools、Salmon 的定位都是 CPU / IO 型工具，GPU 预算留给真正需要的方向（深度学习、结构预测）；
- 存储是主角：比对产生的 BAM 通常显著大于原始测序数据，且需要长期保留——只按原始数据体积买硬盘是常见错误；
- 决定配置档位的不是”用哪个软件”，而是”走哪条流程路线”：要不要保留比对结果（STAR 还是 Salmon）、要不要做大队列 VCF 合并——这两个决策直接改变内存与存储的配置档位。
一、四个工具一张表：硬件画像
| 工具 | 在流程里的位置 | GPU | CPU | 内存 | 存储 | 最该注意的 |
|---|---|---|---|---|---|---|
| BWA（含 BWA-MEM） | DNA 读段比对到参考基因组（建索引 + 比对） | 不需要 | 极重要（多线程，核数决定通量） | 中—高 | 容量 + IO（BAM 输出很大） | 比对是要读参考、写 BAM 的 IO 密集任务 |
| samtools | 比对文件排序 / 去重 / 索引 / 切片 / 格式转换 | 不需要 | 重要（排序与压缩可按线程加速） | 中 | IO 极敏感 + 容量高 | 瓶颈几乎总在磁盘 IO 与压缩解压 |
| bcftools | VCF/BCF 变异文件合并 / 过滤 / 注释 / 统计 | 不需要 | 重要（部分操作多线程） | 中—高（大样本合并明显上升） | 容量 + IO | 注释库要离线预置 |
| Salmon | RNA-seq 转录本定量（不需生成完整比对结果） | 不需要 | 极重要（多线程定量） | 中—高（低于全比对流程） | 容量中等、IO 敏感 | 与 STAR 二选一，直接决定内存与存储档位 |
一句话概括这张表：四个格子里的 GPU 全是”不需要”。
二、为什么这类任务”吃存储”吃得这么厉害
这是本方向最容易被低估、也最容易在交付后被投诉的一项。原因有三个：
- BAM 是”再生成一遍原始数据”：BWA 的产物是比对结果文件，体积通常显著大于原始测序数据（具体倍数随物种、测序深度、比对参数变化，官方未给统一系数 → 须按课题组实际数据实测）；
- 中间文件会层层叠加：排序、去重、索引、格式转换每一步都会产生新文件，处理完往往不能立刻删；
- 数据往往要”长期保留”：测序数据是经费买来的原始资产，多数课题组不允许删。
因此规划存储时的正确口径是“原始数据 × 倍数”，并且给 work / 中间目录单独留盘，而不是按原始数据的体积直接买。这一点和我们之前写的实验室服务器的存储配置是同一套逻辑。
三、samtools：这类工具”换硬盘”常比”换 CPU”更有效
samtools 是排序、索引、格式转换用的基础小工具，几乎每个测序流程都会调用它。它的特征非常明确：
- 瓶颈几乎总是磁盘 IO + 压缩/解压的 CPU 开销，而不是内存容量；
- 排序与压缩/解压支持多线程，但多用户同时跑时一定要限制线程数，否则互相拖慢（这是最常见的”服务器变慢”投诉来源）；
- CRAM 这类压缩格式是”用 CPU 换存储”的取舍，选之前要清楚代价。
采购含义：如果课题组反馈”流程卡在这一步很慢”，优先改善存储介质（NVMe / 更快的 SSD 与更高带宽）通常比加 CPU 更明显。这也是我们在服务器卡顿该不该加显卡里讲的同一个诊断顺序：先分清瓶颈在 CPU、IO 还是显卡，再花钱。
四、bcftools：平时很轻，做”大队列合并”时内存会明显上升
bcftools 处理的是 VCF/BCF 变异文件，日常的过滤、统计、格式转换需求不大；真正要预留资源的是”多队列/多批次样本合并”——这类操作的内存占用会随样本数明显上升。
另外有一项经常在交付阶段才被发现的前置条件：
| 前置条件 | 不处理的后果 |
|---|---|
| 变异注释数据库（如 dbSNP 等）需要在服务器本地可用 | 实验室服务器通常不出外网 → 注释步骤中途失败，或注释结果版本不一致 |
| 数据库版本需与流程/文献口径一致 | 同一批数据在不同时间跑出不同注释结果 |
所以我们的做法是：在方案里就把”离线预置注释库”写成交付项，先把数据库下好、版本对齐、路径固定，再交付。
五、Salmon 还是 STAR？这一问直接改变内存与存储档位
这是本方向最值钱的一个售前问题，因为它把同样的数据量指向了完全不同档位的机器：
| 路线 | 产物 | 内存压力 | 存储压力 | 适用 |
|---|---|---|---|---|
| Salmon（选择性比对定量） | 转录本丰度结果 | 较低 | 较小（不产生完整比对文件） | 只要”基因/转录本表达量” |
| STAR 等全比对流程 | BAM 等比对结果 | 高（人类基因组建索引一项就要按几十 GB 级别准备缓存，并留余量） | 高（比对文件体积大且需保留） | 下游还需要比对结果（如可变剪接、IGV 查看、部分变异流程） |
关于 STAR 建索引的内存口径，我们在《STAR 建索引跑到一半被系统杀掉？》里引用过官方作者给出的量级——人类基因组约 32GB 量级并要留余量，被系统 OOM 杀掉往往不是”机器慢”，而是内存不够。
结论：报价前一定要问一句”你们下游需要 BAM 吗“。答案不同，内存和存储的配置档位要差一档——按 STAR 配给只用 Salmon 的课题组，就是白花钱。
六、交付前必须落实的三件事（都在”买机器”之外）
| # | 前置条件 | 不落实的后果 |
|---|---|---|
| 1 | 参考基因组 / 转录组索引与注释库的离线预置 | 实验室服务器常无法访问外网，流程跑到一半去下载参考文件 → 直接中断，或几个人下了不同版本 |
| 2 | 线程数配额 | 多人共用一台机器而不限制线程，等于互相抢核，谁都跑不快 |
| 3 | 中间文件目录与清理策略 | 临时文件写满系统盘，是最常见的”昨天还好好的，今天跑不了” |
这三项都是软件层的配置工作，不需要额外买硬件，但直接决定机器好不好用。多人共用的账号与配额做法，可参考课题组共用一台服务器怎么设。
七、按规模分档（可直接对照预算看）
| 场景 | CPU | 内存 | 存储 | GPU | 备注 |
|---|---|---|---|---|---|
| 单人 / 少量样本（几十个样本级） | 16–32 核 | 64–128GB | 4–8TB（其中 1–2TB NVMe 做热区） | 不配 | 单机即可，先把流程跑通 |
| 常规课题组（几百个样本 / 多样本并行） | 32–64 核 | 128–256GB | 8–16TB + 独立 work 盘 | 不配 | 线程配额 + 中间目录规范 |
| 大队列 / 多项目并行 | 64 核以上或多节点 | 256GB 以上 | 共享存储 + 统一调度 | 不配（除非另有深度学习任务） | 任务排队、目录规范、数据分层 |
三条判断口径（比”经验值”靠谱）：
- 并发任务数决定核数与内存，不是”人数”——同时跑 3 个比对就要按 3 个任务算；
- 存储按”原始数据 × 倍数”估，并给 work 目录单独留盘；
- 要不要 GPU，只看课题组有没有深度学习/结构预测这类任务，跟”测序”本身无关。
八、五句可以直接写进方案的结论
- 本方向的比对、定量、变异处理流程不使用 GPU——显卡预算应优先留给深度学习类需求；
- 配置重点是 CPU 核数、内存容量与存储的容量 + 读写速度，三者的排列顺序取决于流程路线；
- 存储按倍数估算：比对结果与中间文件通常显著大于原始测序数据，且需长期保留；
- “要不要 BAM”决定内存与存储档位：Salmon 路线明显轻于全比对路线，采购前必须确认；
- 离线资源要预置：参考基因组索引、注释数据库、线程配额与中间目录策略，属于交付项而非”用户自己搞定”。
常见问题
做基因组测序分析一定要配显卡吗？
不需要。BWA（比对）、samtools（比对文件处理）、bcftools（变异文件处理）、Salmon（转录组定量）这四个主力工具的资源需求都集中在 CPU、内存与存储上，官方资料里没有把 GPU 作为运行条件。真正需要显卡的是流程之外的任务，例如课题组同时在做的深度学习模型训练、蛋白结构预测等。正确做法是把”测序流程”和”深度学习任务”分开评估：如果只有前者，显卡预算应该省下来；如果两者都有，才按 GPU 需求配卡，并把 CPU、内存留给流程。
为什么说”只按原始测序数据买硬盘”是错的？
因为流程会产生比原始数据更大的文件。比对产生的 BAM 文件通常显著大于原始测序数据，并且还要保留索引、去重后文件、中间结果；这些文件在处理完成前不能删、完成后课题组往往也不允许删（属经费产出的原始资产）。所以容量应该按”原始数据 × 倍数”来估，倍数随物种、测序深度与流程参数变化，没有官方统一系数，必须按课题组实际数据实测。同时建议把中间文件目录单独放在一块盘上，避免写满系统盘。
已经配了 64 核，为什么流程还是慢？
大概率不是 CPU 不够，而是这两件事之一：一是存储——samtools 这类工具的瓶颈几乎总在磁盘 IO 与压缩解压，升级存储介质往往比继续堆核数有效；二是并发没管——多人共用时不限制线程数，会互相抢核。建议按”先看瓶颈在哪”的顺序排查：任务管理器中 CPU 是否真的跑满、磁盘占用率是否接近饱和、以及同一时间有几任务在跑。相关口径我们写在服务器 CPU 和显卡都跑满了还是很慢，再加一张卡有用吗里。
Salmon 和 STAR 该怎么选，影响机器配置吗？
影响很大。Salmon 直接从读段估计转录本丰度、不需要生成完整比对结果，因此内存与存储压力都更小；而以 STAR 为代表的全比对流程会产出 BAM 等比对文件，内存与存储需求明显更高（例如 STAR 建索引一项，人类基因组就要按几十 GB 量级的内存做准备，见我们此前的STAR 内存报错解析）。所以采购前必须先确认下游是否需要比对结果：只需要表达量的课题组，按轻路线配；需要 BAM 的（可变剪接、IGV 查看、部分变异流程），按重路线配。
实验室服务器不能上外网，会影响测序流程吗？
会，而且这是交付阶段最常被忽略的问题。测序流程需要两类外部资源：参考基因组 / 转录组索引和变异注释数据库（如 dbSNP 等）。内网无外网的实验室，必须在交付前把这两类资源离线预置好，并保证版本与整个课题组的口径一致——否则流程会中途失败，或者同一批数据在不同时间跑出不同注释结果。我们在方案里会把”离线预置参考与注释库”写成交付项，用户不需要自己找。
如果你们正在给课题组或实验室看机器，把 要跑的软件 / 模型、大概几个人用、预算范围 发我一句，我按这个给你一份带参数清单的配置思路——不推销最高配，只帮你把钱花在真正影响出结果的地方。
