2026 年 3 月发布的 DeepVariant 1.10，把 RNA-seq 模型正式列入支持范围，还为 PacBio 与 ONT 长读长加入连续定相输出。很多人看到“GPU 版”后，第一反应是：找一张显卡，变异检测就能很快跑完。
但 DeepVariant 不是一个从头到尾都由 GPU 接管的黑盒。它至少包含 make_examples、call_variants 和 postprocess_variants 三个阶段，CPU、显存、内存和存储分别卡在不同位置。只盯显卡型号，常见结果是 GPU 在等数据，CPU 在拆分区间，最后一步又因内存不足中断。
先看结论：16 GB 是显存占用，不是整机配置
DeepVariant 官方 FAQ 表示，Keras 模型在测试中占用约 16 GB GPU 显存；同时，当前 call_variants 的 GPU 推理最多只使用 1 张 GPU。因此，把预算堆到多卡机器上，并不会自动缩短单个样本的推理时间。
更关键的是，make_examples 主要依赖 CPU，可按基因组区间分片；postprocess_variants 则要汇总、排序全部中间结果。官方文档给出的经验是，并行后处理可能需要每个 CPU 核约 2—3 GB 内存；若关闭并行，整体仍可能需要 20—50 GB 内存。这意味着一张 16 GB 显存的 GPU，并不能替代 64 GB、128 GB 甚至更高的系统内存规划。
| 阶段 | 主要瓶颈 | 官方信息与工程判断 | 配置重点 |
|---|---|---|---|
make_examples |
CPU、随机读写 | 单进程可按区间分片；分片数通常与可用 CPU 核匹配 | 足够 CPU 核、本地高速盘、合理分片 |
call_variants |
GPU 显存与推理 | Keras 模型测试占用约 16 GB；单样本最多使用 1 张 GPU | 单卡显存留余量，别为单样本盲目堆多卡 |
postprocess_variants |
系统内存、排序 | 并行时约 2—3 GB/核；串行模式总内存仍可能达 20—50 GB | 控制 CPU 数与 num_partitions，保留内存余量 |
| 输入与中间文件 | 容量、吞吐 | 官方示例中 30× WGS：BAM 66.99 GB，CRAM 37.85 GB；CRAM 运行更慢 | NVMe 暂存，容量按输入、中间文件和结果共同计算 |
为什么“GPU 使用率不高”不一定是故障
官方的 fast pipeline 可以让 CPU 生成样本图像时，GPU 同时执行 call_variants。这类流水线只有在两端速度接近时才有效：CPU 分片太少、BAM 位于网络盘、容器挂载目录吞吐不稳，都可能让 GPU 间歇空转。
官方文档还给出一个直观对比：同一份 30× 全基因组数据，BAM 约 66.99 GB，单个 make_examples 作业约 79 分 47 秒；CRAM 约 37.85 GB，却运行约 96 分 53 秒。CRAM 节省了约 43.5% 容量，但该测试中耗时增加约 21%。这不是说 CRAM 一定慢，而是提醒我们：压缩率、解码开销、存储吞吐必须一起评估。
一套更稳的资源规划方法
如果是单个 WES 或小区域验证，可先在较少 CPU 核上跑通容器、参考基因组和模型版本；如果是 30× WGS、长读长或批量样本，再把资源拆成四个问题。
- 输入规模：记录 BAM/CRAM 大小、覆盖深度、参考版本和样本数，而不是只写“一个全基因组”。
- 并行策略：
--num_shards决定make_examples并行度。核数增加会放大内存和 I/O 压力，不能只按 CPU 总数拉满。 - 显卡边界：官方记录约 16 GB 显存占用，实际部署应为驱动、容器和峰值保留余量；当前单样本多卡没有收益。
- 磁盘预算：至少同时容纳输入、参考文件、容器镜像、中间 TFRecord、VCF/gVCF 与日志。批量任务要设置按样本清理和归档规则。
真正开始扩容前，建议先用一个有代表性的样本做基线测试，并同时记录四类指标：CPU 利用率、GPU 利用率与显存、峰值系统内存、磁盘吞吐与等待时间。如果 CPU 长时间满载而 GPU 断断续续，优先检查分片生成速度和输入盘；如果 GPU 显存接近上限但系统内存很空，才需要考虑更大显存；如果最后合并阶段突然被系统杀死，问题多半不在模型推理，而在后处理并行度与内存峰值。只看总运行时间，无法定位该把预算花在哪里。
多样本任务还要区分“单样本加速”和“样本级并发”。由于当前 call_variants 单个样本最多使用一张 GPU，多卡服务器更适合让不同样本分别占用不同 GPU，而不是让一个样本跨卡运行。此时 CPU 核、内存、NVMe 带宽也要按并发样本数同步增加；否则两张 GPU 同时读写一个拥堵的网络盘，利用率反而可能下降。队列系统应为每个任务明确申请 CPU、内存、GPU 和临时盘，并限制同一节点同时运行的样本数。
还有一个容易被忽略的变量是中间目录。若 intermediate_results_dir 指向容量较小的系统盘，任务可能在运行数小时后才因空间耗尽失败；若指向共享存储，成千上万个分片文件又会放大元数据访问延迟。更稳妥的做法是把中间结果放在节点本地 NVMe，完成后只回传 VCF、gVCF、统计报告和必要日志，并在确认结果完整后再清理临时文件。这样既能减少网络盘压力，也方便按样本复查失败阶段。
版本复现同样重要。DeepVariant 1.10 的模型会通过 model.example_info.json 携带与训练相匹配的输入参数；自定义模型或拆开运行三个阶段时，模型文件与该元数据应一同保存。容器标签、参考 FASTA、索引文件、BAM/CRAM 和命令行参数也应进入任务清单。仅记录“用了 DeepVariant”，不足以支持后续复跑或审稿核对。
下面这类命令适合先做单样本基线，再根据监控结果调整分片。版本、模型类型、参考基因组必须与数据一致：
docker run --gpus 1 \
-v /data/input:/input \
-v /data/output:/output \
google/deepvariant:1.10.0-gpu \
/opt/deepvariant/bin/run_deepvariant \
--model_type=WGS \
--ref=/input/GRCh38.fa \
--reads=/input/sample.bam \
--output_vcf=/output/sample.vcf.gz \
--output_gvcf=/output/sample.g.vcf.gz \
--num_shards=16
RNA-seq 模型上线，不等于 RNA 变异可以直接下结论
DeepVariant 1.10 的 RNA-seq 支持扩大了工具适用范围，但 RNA 数据受表达量、可变剪接、等位基因特异表达、比对策略和 RNA 编辑影响。低表达位点没有足够覆盖，并不等同于基因组中不存在变异；RNA 中观察到的差异，也不能直接替代 DNA 层面的生殖系或体细胞验证。
因此，RNA-seq 变异检测更适合在明确研究目标和过滤规则下作为补充证据。若研究结论涉及临床判断或关键候选验证，应结合 DNA 数据、正交实验和相应规范，而不是把模型输出当作最终证据。
什么时候服务器比本地工作站更合适
当任务包含 30× WGS、多样本并发、长读长、gVCF 输出或需要保留完整中间文件时，服务器的价值不只是“有 GPU”，而是能把 CPU 分片、单卡推理、内存峰值、本地 NVMe 和容器版本统一管理。这样更容易复现失败步骤，也避免个人电脑被长期占用。
如果你的 DeepVariant 任务出现 GPU 空转、后处理爆内存、容器与 CUDA 不兼容，或不确定 64 GB / 128 GB 内存、单卡 GPU 与 NVMe 容量该怎样搭配，可以准备软件版本、数据类型、样本数、单样本大小、当前报错和期望时间。云生信会先判断瓶颈位于 CPU、GPU、内存还是存储，再确认是租用环境自行运行、部署并交接环境，还是委托分析更合适。
