Oxford Nanopore 原始信号从 POD5 变成可分析的序列，要经过 basecalling；如果还要同时做比对、条形码拆分、修饰碱基识别和 BAM/CRAM 输出，计算链会迅速变长。看到 Dorado 官方写着“多数 Pascal 及更新架构的 NVIDIA GPU、显存不低于 8 GB 预计可运行”，很多人会以为一张消费级显卡就足够。
能启动不等于能高效完成。Dorado 2.1.2 已支持 v6.0 模型，并持续优化 Blackwell GPU、SUP 短读长和 smallvar。真正决定周转速度的，是模型复杂度、GPU 数量、POD5 读取、输出格式、修饰模型以及下游并发共同形成的流水线。
先看四个数字，再谈显卡型号
官方平台说明中，未被广泛测试的 Linux/Windows NVIDIA 设备，通常要求 Pascal 及更新架构、至少 8 GB 显存，但 P100/GP100 例外；Apple Silicon 建议至少 16 GB 统一内存。这只是兼容性参考，不是所有模型与流程的性能保证。
Dorado 2.0 将 x86_64 平台最低 CUDA 提升到 12.8；2.1 系列进一步优化 v6.0 HAC 在 Blackwell 上的性能。另一方面，官方 v1.4 的内部测试显示：在同时输出全上下文修饰信息和 move table 时，CRAM 比 BAM 文件约小 35%。显存、驱动和存储格式因此必须一起规划。
| 决策点 | 会改变什么 | 官方依据 | 资源影响 |
|---|---|---|---|
fast / hac / sup |
准确性与速度取舍 | 官方提供三类模型，架构和规模差异明显 | SUP 通常更吃算力，不能只沿用 FAST 的配置 |
| 单卡或多卡 | 样本吞吐 | Dorado 支持 NVIDIA 多 GPU，并可近线性扩展 | GPU 增加后，CPU、POD5 读取和写盘也要跟上 |
| BAM 或 CRAM | 输出容量与兼容 | 特定修饰+move table 场景中 CRAM 约小 35% | CRAM 省空间，但要核对后续工具兼容性 |
| 修饰碱基模型 | 每条 read 的额外推断 | v6.0 提供 5mC/5hmC、4mC/5mC、6mA 等模型 | 增加 GPU 计算、输出字段和存储压力 |
8 GB 为什么只能看作“能否开始”的门槛
Dorado 会自动选择 batch size，也允许手动调整。更大的 batch 往往能提高现代 GPU 吞吐，但显存不足时会直接失败；更小的 batch 虽然更稳，却可能让 GPU 吃不满。不同模型、read 长度和修饰任务的显存占用并不相同，因此不能把“8 GB 能运行”理解成“8 GB 能稳定跑 SUP 加多种修饰”。
更稳的做法是先用一个代表性 POD5 子集进行基线测试，记录 reads/s、GPU 利用率、峰值显存、POD5 读取速度和 BAM 写入速度。GPU 利用率低时，不要立刻加卡，先检查输入是否仍是 FAST5 转换链、POD5 是否位于慢速网络盘、输出压缩和比对是否堵住流水线。
基线测试不能只截一段短读长文件。若样本中既有大量短片段，又有超长 reads，应分别观察吞吐和显存；Dorado 2.1.0 专门增加了 v5.0 以后 SUP 模型的可变 chunk size，以改善短 reads 性能，这也说明 read 长度分布会影响实际速度。测试时至少保留输入 read 数、成功输出 read 数、运行时间和失败日志，避免把“跑得快”建立在漏读或提前中止上。
还应把下游需求提前写清。只需要标准碱基序列，与同时调用 5mC/5hmC、6mA、输出 move table 并在线比对，资源负担完全不同。若后续工具只接受 BAM，就不能只因 CRAM 更省空间而切换；若团队长期归档，才值得验证 CRAM 解码、索引和共享软件链是否兼容。
官方 troubleshooting 明确指出，POD5 在 I/O 受限环境中能提供更好的读取性能。若多张 GPU 同时从共享目录读取大量小文件，线性扩展很快会被存储吞吐打断。服务器的意义正在于把 GPU、NVMe 暂存和输出归档放在同一套可监控的资源计划中。
一个可复现的运行起点
对 R10.4.1、E8.2、400 bps 数据，v6.0 HAC 是当前官方列出的 DNA 模型之一；具体模型仍必须与测序条件、采样频率和修饰类型匹配。下面示例让 Dorado 自动选择可用 GPU，并把 BAM 明确写入文件：
dorado basecaller \
hac@v6.0.0 \
/data/pod5/ \
--device cuda:all \
--modified-bases 5mCG_5hmCG \
> sample.hac.v6.bam
执行前先用 dorado download --list 查看当前安装可用模型。生产流程建议固定 Dorado 版本、完整模型名、POD5 批次、命令行和驱动信息；只写“用了 HAC”无法保证复现，因为 hac@latest 会随着软件与模型更新而变化。
需要边测边算时，还要分清实时 basecalling 与离线补算。实时任务更看重稳定吞吐，离线任务可以通过队列把多个 flow cell 分配到不同 GPU。若使用 cuda:all，要确认输出写入、比对和 demux 是否也能承受总吞吐；否则 GPU 增加只会把瓶颈推到磁盘。
多 GPU 并不等于所有步骤都线性加速
Dorado basecalling 支持多 GPU，但同一项目常常还包含 aligner、demux、summary、修饰碱基、poly(A) 估计甚至 smallvar。这些步骤对 GPU、CPU 和内存的使用模式不同。将所有功能塞进一个长命令，虽然方便，却不利于定位失败和复跑。
工程上可以把任务拆成“原始 POD5 校验—basecalling—比对/拆分—质控汇总—归档”，每一步保留校验值和日志。节点本地 NVMe 用于正在处理的数据，完成后再把 POD5、BAM/CRAM、summary 和日志转入容量盘。这样某一步失败时无需从头重复，也能避免个人工作站长期被占用。
批量项目应按峰值而不是平均值计算空间：原始 POD5、临时 BAM、最终 BAM/CRAM、索引、拆分文件和日志可能同时存在。若还保留 move table、修饰标签和比对信息，单纯按“测序原始数据大小”配盘通常会低估。
队列设计也要避免一张卡被多个任务无序争抢。对单卡节点，可以一次只运行一个 basecaller；对多卡节点，可显式指定 cuda:0、cuda:1，或在确认存储能跟上后使用 cuda:all。每个任务都设置独立输出目录、临时目录和日志，失败时记录 Dorado 版本、模型下载时间、驱动与 GPU 状态。这样既能复现，也便于判断下一次应扩 GPU、CPU 还是磁盘。
模型更新带来性能，也带来版本边界
Dorado 2.1.2 修复了 v6.0 HAC 的非确定性问题；2.1.0 更新了 minimap2，并优化 Blackwell 与短读长 SUP 性能。旧文章中的速度或 batch size 不应直接当成新版本结论。升级前应先用同一批 POD5 做小规模回归，比较 read 数、Q score 分布、长度分布、修饰输出和下游兼容。
此外，Dorado 已不再支持部分旧测序条件，例如 RNA002、R9.4.1、R10.3 和 R10.4。若历史数据与当前模型不匹配，需要按官方兼容说明选择旧工具或合适版本，不能为了“跑起来”强行套用新模型。
如果你的 Dorado 任务出现 GPU 利用率低、多卡扩展不明显、BAM 写盘跟不上、CUDA 版本不兼容，或不确定 HAC/SUP、修饰模型、NVMe 和归档空间怎样组合，可以准备 Dorado 版本、测序条件、模型、POD5 总量、GPU 型号、输出要求和期望完成时间。云生信会先判断瓶颈在模型、GPU、I/O 还是流程编排，再确认租用环境自行运行、环境部署交接或委托分析的范围。
