做 10x Multiome ATAC + Gene Expression 时，最容易踩的坑不是命令不会写，而是把“最低配置”当成“稳定配置”：任务能启动，跑到中段却因内存、磁盘或并发被杀；换更大机器后，又发现核数翻倍并没有等比例提速。
2026 年 4 月发布的 Cell Ranger ARC 2.2 已支持 GEM-X Epi Multiome，并能在本地运行 Pan-Human Azimuth 细胞注释。功能更完整，也意味着分析前更应把版本、参考数据、资源上限和交付范围一起规划，而不是等报错后再临时加机器。
先看结论：64 GB 是门槛，不是所有项目的舒适区
10x Genomics 当前给出的 ARC 2.2 单机最低要求是 8 核、64 GB 内存、1 TB 可用磁盘，推荐值为 48 核、320 GB 内存。官方还用 PBMC 10k 数据做过测试：8 线程、64 GB 的墙钟时间约 14 小时 08 分；32 线程、256 GB 约 4 小时 50 分；48 线程、384 GB 约 2 小时 59 分。这些数字能帮助估算量级，但不能直接当成自己样本的承诺——细胞数、每细胞 reads、磁盘性能和并发都会改变结果。
| 资源或设置 | 官方信息 | 项目上该怎么理解 |
|---|---|---|
| 最低硬件 | 8 核 / 64 GB / 1 TB | 能进入分析流程，不代表适合多个样本并行 |
| 推荐硬件 | 48 核 / 320 GB | 更接近稳定交付配置，仍需按数据量实测 |
| PBMC 10k 实测 | 64 GB：14h08m；256 GB：4h50m | 加内存和线程可明显提速，但不是线性收益 |
| 本地模式默认值 | 全部可用核心 + 90% 内存 | 共享服务器上若不设上限，容易挤压其他任务 |
| 64 GB 调度示例 | --localmem=57 |
给系统和调度器留余量，不要把物理内存全部报给流程 |
为什么 Multiome 比普通表达矩阵更吃资源？
Multiome 不是把两个结果文件简单拼在一起。同一批细胞需要同时处理 ATAC 与 GEX 两类 FASTQ，完成比对、条形码兼容性检查、片段与峰相关计算、表达矩阵生成以及联合降维和聚类。高峰内存可能集中在某个阶段，磁盘还要同时容纳输入、参考包、临时文件和最终输出。只看 FASTQ 总大小，往往会低估峰值资源。
此外，ARC 本地模式默认会使用检测到的全部核心和 90% 内存。一台 128 GB 共享节点上，如果两个用户各启动一个任务，两个流程都认为自己能拿到约 115 GB，实际可用量却不会凭空翻倍。这类“偶发 OOM”常被误判为软件不稳定，根因其实是资源边界没有写进命令和调度策略。
一条命令，至少把四件事说清楚
cellranger-arc count \
--id=sample01 \
--reference=/data/refdata-cellranger-arc-GRCh38-2024-A \
--libraries=libraries.csv \
--localcores=32 \
--localmem=240 \
--create-bam=true
这里的 32 核和 240 GB 只是示例，不是通用答案。真正要确认的是：软件版本与参考包是否匹配、节点是否支持 AVX、ATAC/GEX 路径和 library type 是否正确、后续是否需要 BAM。ARC 2.2 的 --create-bam 必须明确给出 true 或 false；若后续不做浏览器核查或重比对，关闭 BAM 能减少存储压力，但这是分析方案选择，不能为了省盘盲目关闭。
如果只想先验证主流程，--nosecondary 可跳过聚类等二级分析并缩短运行时间，但它不等于完整交付。安装后还可以先跑 cellranger-arc testrun --id=tiny：官方称通常需 10—20 分钟，在 16 核工作站上最长可到约 60 分钟。它适合检查安装与基础环境，不能替代真实样本压测。
从“能跑”到“按时交付”，建议做这 5 步
- 先锁版本。 记录 ARC、参考包、操作系统和 CPU 指令集；ARC 2.2 要求 64 位 CentOS/RedHat 8.0+ 或 Ubuntu 18.04+，并要求 AVX。
- 选一个代表样本试跑。 记录峰值内存、墙钟时间、最大磁盘占用和 I/O wait，不只看平均 CPU。
- 显式限制资源。 在共享机上始终设置
--localcores与--localmem；64 GB 作业可参考官方示例，把内存上限设为 57 GB，为系统留余量。 - 按峰值排并发。 先满足单任务高峰，再决定能否并跑。不要用“总内存 ÷ 64”机械计算并发数，还要为文件缓存、调度器和其他进程留空间。
- 提前算磁盘回收。 官方最低可用磁盘是 1 TB；PBMC 10k 测试的存储高水位约 348—400 GB。项目应分别规划输入、运行中间文件、BAM、归档和备份，完成后再按约定清理。
跑慢、被杀、结果异常，排查方向并不相同
如果任务启动后很快提示预检失败，优先查 FASTQ 路径、libraries.csv、参考包、系统版本与 AVX；反复在同一 stage 被系统杀掉，先对照调度器记录和 dmesg，确认是否触发 OOM，而不是立刻重跑。CPU 利用率不高但墙钟时间持续增长，则应检查磁盘吞吐、共享存储拥堵与小文件读写。若流程完成但有效细胞、TSS enrichment、FRIP 或基因表达质量异常，问题更可能来自文库和数据质量，继续加内存不会改善生物学结果。
因此，一次可复现的交付至少要保存命令、软件版本、参考包名称、关键日志、web summary 和资源使用记录。下次增加样本时，才能依据真实高水位扩容，而不是从头猜配置。对多人共用的机器，还应给任务目录、参考数据和结果归档设清晰权限，避免“算完了却找不到输入版本”或误删中间结果。
需要注意的是，Cell Ranger ARC 的主要瓶颈通常是 CPU、内存和存储 I/O，不是有 GPU 就一定更快。若后续还要做深度学习细胞注释、跨模态模型或大规模二次分析，再单独评估 GPU 型号和显存更合理。把 CPU 流程与 GPU 工作负载混在同一张配置单里，往往既增加成本，也难以解释实际收益。
单机、集群还是外包分析？先看管理成本
单个或少量样本，用独占的大内存 Linux 服务器通常最直接，日志和目录也容易排查。已有 HPC 时，可用单节点 job submission mode；10x 对 ARC 的多节点 cluster mode要求共享文件系统及 SGE 或 LSF。Slurm/Torque-PBS 虽有用户用于单节点提交，但官方明确说明并不正式支持，模板、路径和资源申请都要由本地管理员验证。
服务器租用解决的是硬件与使用周期；环境部署解决版本、参考包、依赖和测试；委托分析则还应包含输入检查、参数记录、质控解释与结果交付。三者不是同一项服务。云生信可以先根据样本数、FASTQ 规模、交付物和时间窗口判断瓶颈，再决定是补算力、搭环境，还是把流程整体托管，避免“机器买大了仍不会跑”或“跑到一半才发现磁盘不够”。
如果你正准备 Multiome 项目，可把 样本数、每个样本两类 FASTQ 大小、预计细胞数、是否保留 BAM、期望完成时间 发来，我们可协助做资源估算和执行方案。具体运行时间以数据质量与实测为准，不承诺所有样本都复现官方基准。
联系云生信，咨询 Cell Ranger ARC 资源与环境
