一个 Cell Ranger 任务已经跑通，接下来还有十几个样本。最直觉的做法，是把所有任务一起启动。
结果可能恰好相反：内存被同时占满，FASTQ 和 BAM 抢同一块磁盘，临时目录越来越大，单个任务反而比原来更慢，甚至整批一起失败。
多样本批量运行的关键，不是“能开几个任务”，而是先算清一个任务的真实资源，再决定并发数。
Cell Ranger 的并发，不能只用 CPU 核数相除
Cell Ranger 在单机模式下默认使用检测到的全部核心和约 90% 可用内存。官方建议在共享环境中使用 --localcores 和 --localmem 设置上限，避免任务之间互相挤占。
如果一台 64 核服务器同时启动四个不设上限的任务，它们不会自动公平分配资源。真正要同时考虑的是：
- 单任务峰值内存；
- 每个阶段实际使用的线程数；
- 多个任务同时读 FASTQ、写 BAM 的 I/O 压力；
- 每个 pipestance 的临时和输出空间；
- 任务失败后是否能够清楚定位和重跑。
第一步：先用代表样本测出单任务基线
在整批启动前，先选择一个具有代表性的样本跑通。不要只记录总耗时，还要记录峰值内存、核心使用、工作目录最大占用、最终输出大小和关键日志。
样本间数据量差异较大时，可以把样本按小、中、大分组。用最小样本推断所有任务，往往会低估大样本的资源；直接用最大样本估算全部任务，又可能造成不必要的闲置。
这个基线决定了后面的并发安排，也决定服务器需要多少可分配资源。
第二步：把并发拆成三道上限
同一批任务能同时运行多少个，通常取决于三个上限中最小的那个：
- 内存上限：可用于任务的总内存 ÷ 单任务峰值内存；
- CPU 上限：可用核心数 ÷ 单任务设置的 localcores；
- I/O 上限：工作盘是否能承受多个任务同时读写和排序。
很多批量任务不是卡在 CPU，而是卡在第三项。CPU 看起来还有空闲，磁盘队列却已经拉长，此时继续增加并发只会让全部任务一起等待。
第三步：一个样本，一个清楚的输出边界
Cell Ranger 会把每个任务的运行状态、中间文件和最终结果放在对应的 pipestance 目录中。批量任务需要提前约定：
- 样本名与
--id的映射； - FASTQ 路径和文库类型；
- 参考包版本；
- 每个任务的工作目录和归档目录；
- 失败任务的日志、重跑规则和交付清单。
目录边界清楚，后续才能判断哪个样本完成、哪个样本需要重跑，也能避免矩阵、BAM 和质控报告对应错样本。
哪种批量策略更合适？
| 任务情况 | 主要风险 | 更合适的安排 |
|---|---|---|
| 2–3 个规模接近的样本 | 资源相互争抢 | 先测单任务，再做受控并发 |
| 样本大小差异明显 | 大任务挤掉小任务 | 按数据量分组，错峰运行 |
| 十几个以上样本 | 调度、日志和目录混乱 | 使用任务队列或集群调度 |
| 多人共享同一服务器 | 互相占满内存和工作盘 | 设置资源上限、目录和权限 |
大批量任务，为什么更适合服务器或集群？
10x Genomics 官方系统要求明确说明，大数据集需要更多资源，并支持在具备共享文件系统和调度系统的集群环境中运行。
这不意味着所有批量任务都必须上集群。少量样本可以在单台高内存服务器上按队列运行；任务数量增加后，再评估 Slurm 等调度方式。关键是让资源、目录、日志和失败重跑有统一规则。
准备批量方案前，先整理这张样本清单
- 样本名与文库类型；
- 每个样本 FASTQ 大小或 reads 数；
- Cell Ranger 与参考包版本；
- 每个样本需要保留的输出；
- 是否允许分批完成；
- 希望开始和完成的时间；
- 团队使用人数和数据访问要求。
把样本清单发来，先获得批量运行方案
如果你已经有多个 10x 样本，但不确定服务器要配多大、一次开几个任务，可以联系云生信企业微信客服，发送“Cell Ranger 批量”。
请准备样本数、文库类型、每个样本的数据量、参考版本、期望输出和时间要求。我们会先估算单任务资源，再给出内存、CPU、工作盘和并发安排建议。
