单细胞项目做到几十万、上百万细胞后，最危险的误判是：软件最低要求只有 64 GB 内存，所以找一台“大一点的电脑”就能跑。Cell Ranger v10.1 的官方资源表给出了更清楚的分界——针对 100 万细胞的 Flex v2 GEX+AB+CRISPR 代表性数据，为把运行时间控制在两天以内，要求 32 核、512 GB RAM、2 TB 可用磁盘。
而官方 EC2 实测中，这个任务墙钟时间为 35.61 小时、消耗 561.57 core-hours，工作盘高水位达到 1611 GB。所以百万细胞任务不是“内存够就行”，而是 CPU、内存、NVMe、临时文件、并发和失败恢复必须一起规划。
64 GB 是软件门槛，不是百万细胞配置
Cell Ranger v10.1 的基础硬件要求是 8 核、64 GB 内存、1.5 TB 可用磁盘，推荐 64 核、128 GB 内存；但官方同时强调，大数据集需要额外资源。下面数字来自 v10.1 系统要求与 AWS 时间试验，数据类型、读深和 feature 数不同，不能把任意项目机械套入同一档。
| 代表性数据 | 为低于2天给出的资源 | 官方墙钟时间 | 工作盘高水位 |
|---|---|---|---|
| 2万细胞，3’/5’/Flex GEX，1万～2万 reads/cell | 8核、64 GB、0.5 TB | 7.56小时 | 126 GB |
| 32万细胞，Flex v1 GEX+AB，200 features | 8核、64 GB、1 TB | 32.7小时 | 621 GB |
| 100万细胞，Flex v2 GEX+AB+CRISPR，500 features | 32核、512 GB、2 TB | 35.61小时 | 1611 GB |
这里的 1611 GB 是磁盘高水位，不是内存峰值。它解释了为什么一台有 512 GB RAM、但工作目录只剩 1 TB 的节点仍可能失败。输入 FASTQ、参考基因组、pipestance、中间文件、BAM、矩阵与报告会在运行阶段同时存在，最终交付体积远小于过程峰值也很正常。
容量测算应从“一个项目”拆成“一个任务峰值”。例如 384 个样本并不等于要把 384 份结果同时常驻内存，但所有 FASTQ、解复用信息和多文库中间文件会进入同一个运行链路。最少要列出四项：输入数据总量、预计细胞与 reads、是否包含抗体或 CRISPR 库、是否保留 BAM。再按“输入 + 运行峰值 + 最终结果 + 重跑缓冲”分区，而不是看到官方写 2 TB 就只准备一个恰好 2 TB 的分区。
如果节点还承担其他任务，应以可独占资源计算，不能把机器标称 512 GB 全部交给 Cell Ranger。操作系统、监控、SSH 会话、文件缓存和其他用户都会占内存。磁盘也要看运行时真正可用空间，而不是阵列总容量；快照、回收站、配额和稀疏文件都可能让“看起来还有空间”与实际可写空间不一致。
先限制资源，再提交全量任务
Cell Ranger 本地模式默认使用可用内存的 90% 和全部核心。在共享服务器上直接运行，可能挤占其他用户；更稳妥的做法是显式限制资源，并给操作系统和文件缓存留下余量：
cellranger multi \
--id=flexv2_million \
--csv=multi_config.csv \
--localcores=32 \
--localmem=480
上例适用于总内存 512 GB 节点的资源控制示意，并不是所有百万细胞任务的固定答案。真正提交前，应检查样本数、预计细胞数、GEX reads/cell、Antibody/CRISPR feature 数、是否生成 BAM、参考版本和剩余磁盘。输入规模不同，峰值会明显变化。
Linux 限制也不能忽略。官方建议用户可打开文件数至少 16k，系统最大文件数按 Cell Ranger 可用内存每 GB 配 10k，用户进程数按每个可用核心 64。任务在高并发阶段报 “too many open files” 时，继续加内存通常无效，应先检查 ulimit -n、ulimit -u 和系统级限制。
本地 Azimuth 省去上传，但不能替代人工复核
v10.1 的一个重要更新，是人类样本默认可运行本地 Pan-Human Azimuth 注释，不需要 10x Cloud 账户。官方说明该模型基于 23 种组织、380 种细胞类型训练；算法在嵌入空间中为每个细胞查找 500 个近邻，参考使用前 128 个主成分。
这对数据不能离开本地环境的团队很有价值，但有三条边界。第一，只支持人类样本；第二，模型仍是 beta；第三，训练时排除了癌症数据。肿瘤、强扰动、发育阶段或疾病特异细胞不能把自动标签当作最终结论。输出中低于 100 UMI 的 barcode 会被标为 Unassigned 或 Low UMI Barcode，也应结合 QC 处理。
本地注释结果会进入 cell_types/Azimuth/，并在 web_summary.html 中显示。交付时不应只保留一列 fine cell type，还应同时保存 broad、coarse、fine 三层标签、参考模型信息和每类细胞数量。对于免疫细胞亚群、肿瘤细胞和稀有细胞，建议把自动标签与经典 marker、双细胞指标、样本来源和批次分布交叉核对；如果不同层级标签冲突，应先回到表达证据，而不是人为挑选更“好看”的名称。
同一批数据在升级 Cell Ranger 或参考模型后重新注释，标签比例可能改变。因此，流程记录中要同时写明 Cell Ranger 版本、转录组参考、Azimuth 模型版本和是否启用云端模型。只有固定这些信息，后续补样、返修或不同服务器重跑时，差异才有机会被解释。
如果选择 10x 的云端注释模型，数据会传输到 10x Cloud，并受相应条款和区域限制约束。项目有隐私、医院数据或伦理限制时，应在分析前确定使用本地 Azimuth、关闭注释，还是采用团队认可的其他本地参考映射流程，而不是跑到一半才处理合规问题。
百万细胞任务怎样做得更稳
第一，先用一部分 FASTQ 或较小批次完成预演，记录磁盘增长曲线、峰值内存、CPU 利用率和各阶段耗时。若 CPU 利用率长期低而磁盘队列很高，瓶颈更可能在共享存储；此时增加核心反而会放大 I/O 竞争。
预演样本不能只选数据量最小的一份。更合理的是选择 reads 较深、feature 较多、细胞回收量较高的代表样本，并检查多文库配对和 sample barcode 配置。这样测得的峰值更接近正式任务；若预演只覆盖最简单样本，放大到全量时仍可能在聚合、降维或注释阶段出现新的资源峰值。
第二，把工作目录放在本地 NVMe/SSD，完成后再把结果、日志和必要中间文件迁移到共享存储。官方也明确推荐 NVMe 或 SSD，而不是机械硬盘。至少保留 pipestance、完整命令、multi_config.csv、软件与参考版本，便于从失败阶段恢复和复现。
第三，百万细胞实验往往包含数十到数百个样本。不要同时启动多个 512 GB 级任务；应按节点真实内存与磁盘峰值限制并发。Cell Ranger 支持 Slurm 集群模式，官方也建议大型数据采用集群，但共享文件系统不稳定时，单个高内存节点可能更容易排错。
第四，流程跑完后仍要检查每样本 reads、有效 barcode、UMI、mapping、抗体或CRISPR feature、批次和细胞类型分布。Cell Ranger 10.1 的汇总 QC 能减少逐个打开报告的工作量，却不能替代对异常样本和自动注释的逐项核查。
如果你的任务卡在 128/512 GB 内存选择、2 TB 工作盘、Flex v2 多样本排队、本地 Azimuth、Slurm 或失败恢复，可以准备 Cell Ranger 版本、文库类型、样本与预计细胞数、reads/cell、feature 数、现有服务器和期望时间。云生信可先做资源测算与小规模基线，再确认租用环境自行运行、服务器环境部署交接或委托分析的范围。
联系云生信，咨询 Cell Ranger 百万细胞服务器与分析方案
