很多单细胞 RNA-seq 项目会遇到一个反直觉问题：STARsolo 的稀疏索引可以在 16 GB 内存下生成，真正把 FASTQ 送进去后却出现 OOM、共享内存报错或 BAM 排序变慢。原因通常不是“STAR 不能跑”，而是把索引构建、基因组装载、比对、细胞条形码纠错和输出排序当成了同一个资源阶段。
STAR 官方仓库当前公开的最新命名版本是 2.7.11b（2024-01-24）。STARsolo 文档说明，它直接完成条形码纠错、剪接比对、UMI 去重和每细胞定量，输出格式可对接 10x 结果；文档还给出“约为 CellRanger 10 倍速度”的总体描述，但这不是对每个样本、参数和硬件的承诺。真正要做稳定交付，先把索引大小、共享内存和输出策略拆开计算。
先看官方数字：16 GB 是一种取舍，不是全流程配置
STAR 手册给出的典型哺乳动物基因组索引目录需要至少 100 GB 磁盘空间；人类基因组在共享内存模式下的 GenomeIndexSize 约为 31,000,000,000 bytes（约 31 GB）。STARsolo 文档建议加入 --genomeSAsparseD 3 生成稀疏后缀数组，它有机会把索引构建内存压到 16 GB，代价是速度下降 30%—50%。因此，“16 GB 能建索引”只说明采用了更省内存的建库策略，并不代表 16 GB 节点适合后续多样本映射。
| 环节 | 官方或文档数字 | 服务器规划含义 |
|---|---|---|
| 最新命名版本 | STAR 2.7.11b | 版本、索引和参数要成套记录 |
| 人类索引共享内存量级 | 约 31 GB | 共享内存上限不能只按 16 GB 配 |
| 典型哺乳动物索引磁盘 | 至少 100 GB | 还要留 FASTA、GTF、临时目录和结果空间 |
| 稀疏索引 | 可适配 16 GB；速度下降 30%—50% | 省内存换时间，适合建库资源紧张场景 |
| STARsolo 输入顺序 | cDNA Read2 在前，Barcode/UMI Read1 在后 | 顺序写反会得到“流程跑完但结果不对” |
映射阶段，内存到底花在哪里？
第一部分是 genome index。默认 --genomeLoad NoSharedMemory 会让每个 STAR 进程自行载入索引；如果同一台服务器要连续跑多个样本，可以用 LoadAndKeep 把索引放入 Linux 共享内存，让后续任务复用。手册要求共享内存参数 kernel.shmmax 和 kernel.shmall 大于索引量级；人类参考若只给了几 GB /dev/shm，就算物理内存很多，也可能在启动时失败。
第二部分是映射与单细胞计数。STARsolo 需要同时处理 cDNA、细胞条形码和 UMI，进行纠错、去重和按基因聚合；细胞数、reads/cell、是否启用 GeneFull 或 Velocyto 类特征，都会改变运行中间数据。第三部分是输出：如果要求坐标排序 BAM、基因组浏览或下游重比对，临时目录和排序阶段会继续吃磁盘与内存。只监控“索引文件大小”，会漏掉峰值。
一条可复用的命令，先把关键边界写清楚
STAR --genomeDir /data/star/grch38 \
--readFilesIn sample_R2.fastq.gz sample_R1.fastq.gz \
--readFilesCommand zcat \
--runThreadN 32 \
--soloType CB_UMI_Simple \
--soloCBwhitelist /data/10x/3M-february-2018.txt \
--soloUMIlen 12 \
--genomeLoad NoSharedMemory \
--outTmpDir /scratch/sample01 \
--outFileNamePrefix /data/result/sample01_
这条命令中的 Read2 是 cDNA，Read1 是 barcode/UMI；10x V3 等化学版本还要核对 whitelist 和 UMI 长度。若目标是尽量贴近 CellRanger 4/5 的计数逻辑，STARsolo 文档列出了 --soloCBmatchWLtype 1MM_multi_Nbase_pseudocounts、--soloUMIfiltering MultiGeneUMI_CR 和 --soloUMIdedup 1MM_CR 等参数，但“接近”不等于所有 QC 指标和过滤结果完全相同。
服务器怎么配，关键看是否共享和是否保留 BAM
个人单样本测试，可以从 64 GB 内存、16—32 核、100 GB 以上索引盘作为工程起点；这是便于加载人类索引并留出系统余量的实用建议，不是 STAR 官方硬门槛。多人并行或要输出坐标排序 BAM，更建议从 128 GB 内存、NVMe 临时盘评估。若只是做矩阵、不保留 BAM，可把空间和排序压力降下来；若要复现、浏览或二次比对，则应把 BAM、临时文件和备份分开预留。
还要把“样本大小”和“并发数”放进同一个预算。单个样本 100 GB FASTQ，并不等于只需要 100 GB 空间：解压、临时排序、日志和失败重跑都可能产生额外副本。若两三个样本同时启动，即使每个任务都能在 64 GB 上单独运行，也可能在峰值阶段互相争抢内存和 NVMe 吞吐。更稳妥的做法是先用一个代表样本记录 MaxRSS、临时目录峰值和每分钟 I/O，再按计划并发数加安全余量，而不是直接用“核数×任务数”估算服务器。
如果团队需要周期性复用同一参考，建议把参考索引做成只读版本目录，给每个项目单独保存参数、软件版本和日志。这样既能避免用户误改索引，也方便在升级 STAR 或替换 GTF 时进行 A/B 对照。服务器租赁时，应提前确认是否允许调整 /dev/shm、是否有作业队列、临时盘是本地 NVMe 还是网络盘；这些条件会直接决定 LoadAndKeep 能否落地。
资源评估最好输出一页“运行卡片”：记录参考版本、STAR 版本、核心参数、预计并发、磁盘配额、失败重试方式和结果保留周期。交接时把这张卡片与 Log.out、命令行和软件容器标签一起归档，后续换机器或换分析人员时，排查成本会明显下降。
共享服务器上，连续运行多个样本时可以评估 LoadAndKeep：索引只加载一次，后续任务复用同一份只读内存；但必须和管理员确认 /dev/shm、kernel.shmmax、ulimit 和作业调度策略。没有共享内存条件时，明确使用 NoSharedMemory，并把每个任务的 --outTmpDir 放在本地 NVMe，避免多个任务同时写 NFS 小文件。
5 个最容易被忽略的排查点
- 索引和 STAR 版本是否配套。 参考 FASTA、GTF、
sjdbOverhang、STAR 版本变化后，应重新核对索引，不要把旧目录直接复制给新二进制。 - 共享内存失败不等于物理内存不足。 查看
Log.out、/dev/shm、ipcs和系统限制；有时是shmmax太小，改成NoSharedMemory或调整管理员配置才是正确方向。 - FASTQ 顺序和化学版本。 Read1/Read2 写反、whitelist 用错版本，可能让流程完成但有效细胞和匹配率异常。
- 索引构建不要和正式映射抢节点。
--genomeSAsparseD 3可以降低建库内存，但 30%—50% 的速度损失应纳入排期；最好一次构建、多次复用。 - 把“跑完”与“结果可比”分开。 若需要和 CellRanger 对照，必须固定 GTF、whitelist、过滤参数和输出类型；不同版本和参数的矩阵不能只看文件名就直接合并。
如果你的 STARsolo 任务反复卡在索引、共享内存、UMI 纠错或 BAM 排序，可以准备 STAR 版本、参考包、细胞数、reads/cell、FASTQ 大小、目标输出和报错阶段。云生信会先判断是资源不足、共享内存限制、参数/化学版本不匹配，还是输出策略造成的 I/O 瓶颈，再沟通服务器租赁、环境部署或委托分析的适用范围。具体耗时和峰值以代表样本实测为准，不承诺复现文档中的速度描述。
