单细胞 RNA-seq 做完 Cell Ranger 后，常会看到某些“本不该表达”的基因散落在多种细胞里。环境 RNA、空液滴和条形码交换可能把技术噪声带进差异分析，CellBender 的 remove-background 因此经常被加入预处理流程。
但它并不是把一个过滤阈值套在矩阵上，而是用深度生成模型估计细胞概率、背景表达和污染比例。很多任务训练阶段看似正常，却在生成 posterior 或输出矩阵时突然爆显存、爆内存。资源规划若只报“约 1 万个细胞”，往往少算了真正决定计算量的液滴范围。
先看三个可核对的数字
CellBender 论文报告：对典型的 10x 数据，约 5,000—30,000 个细胞，使用 NVIDIA T4 或 K80 GPU 时，总运行时间通常约 20 分钟到 1 小时，具体取决于数据规模和参数。官方 v0.3.2 教程中，完整未裁剪的 heart10k 数据在 T4 上约需 30 分钟；训练通常为 150 epochs。
这些数字适合做量级参考，不是交付承诺。同样 1 万个细胞，如果一个样本纳入 20,000 个液滴，另一个纳入 70,000 个液滴，后者需要评估的空液滴和 posterior 范围明显更大。官方 v0.3.2 的更新重点之一，正是降低 --total-droplets-included 很大时的 CPU 峰值内存。
| 环节 | 资源主要花在哪里 | 可观察信号 | 先检查什么 |
|---|---|---|---|
| 读取原始矩阵与先验估计 | CPU 内存、磁盘读取 | 日志停在加载或先验阶段 | 输入是否为 raw 矩阵、文件是否完整 |
| 150 轮左右模型训练 | GPU 计算与显存 | loss 曲线、GPU 利用率、epoch 速度 | CUDA/PyTorch、batch size、是否断点续跑 |
| posterior 生成 | GPU/CPU 峰值内存 | 训练结束后才 OOM | 纳入液滴数、posterior batch 参数、版本 |
| 输出与报告 | CPU 内存、临时盘 | h5、PDF、HTML 报告写入失败 | 临时空间、写权限、是否保留 checkpoint |
为什么液滴数比“最后保留多少细胞”更关键
CellBender 需要同时观察含细胞液滴和空液滴，才能学习环境背景。--total-droplets-included 控制纳入模型的液滴总数，而不是最终细胞数。把这个参数设得过小，可能截断空液滴背景；设得过大，则会增加训练和 posterior 生成的内存压力。
v0.3.0 起，官方说明 --expected-cells 与 --total-droplets-included 通常不必手动设置，自动行为已有改进。工程上更稳妥的做法，是先检查 UMI rank 图和自动先验，再决定是否覆盖默认值，而不是照抄另一批数据的 5,000/20,000 配置。
当前代码中的默认纳入液滴数为 25,000，默认训练 batch size 为 128。这些默认值并不意味着所有样本都应相同；超载实验、细胞数特别多、空液滴平台不清晰时，仍要结合报告和生物学背景判断。
一套可以执行的排错顺序
第一步，确认输入使用未预过滤的 raw UMI count matrix。官方教程明确提醒，真实数据运行前不要先做特征选择或条形码筛选；否则模型看不到完整的空液滴背景。
第二步，固定版本和环境。CellBender 官方目前建议新分析使用 v0.4.0 或更高版本；v0.4.0 将 Python 兼容范围更新到 3.10—3.12，算法输出与 v0.3.2、v0.3.0 保持一致。不要使用曾短暂发布的 v0.3.1，官方说明该版本存在会破坏去噪矩阵的重大错误。
第三步，用一个代表样本跑基线，同时记录 GPU 利用率、峰值显存、系统内存、液滴数、每轮耗时和临时盘占用。下面的命令保留 checkpoint，任务被抢占或中断后更容易恢复：
cellbender remove-background \
--cuda \
--input raw_feature_bc_matrix.h5 \
--output sample_cellbender.h5 \
--checkpoint sample_ckpt.tar.gz
如果训练已经结束，却在 posterior sampling 阶段出现 GPU OOM，官方 troubleshooting 建议可把 --posterior-batch-size 从默认 128 降到 64。代价是后处理速度可能下降，但通常比重复完整训练更可控。只要 checkpoint 与原命令参数保留完整，重新运行时可以从断点继续。需要注意，CellBender 当前单个任务只使用 1 张 GPU，给同一样本增加第二张卡并不能解决显存不足；多卡更适合让不同样本并行，同时为每个任务单独限制 CPU、内存和临时盘。
若 loss 曲线在后期仍有明显尖峰或没有收敛，官方建议优先检查报告，并可能把 learning rate 降低一半后重跑。这个问题属于优化稳定性，不应通过盲目增加 epochs 掩盖。每次调参只改变一个关键变量，保存命令、日志和报告，才知道结果变化来自参数还是数据。
第四步，不要只看命令是否结束。至少打开 output_report.html、UMI count 图、loss 曲线和 metrics 文件，核对自动先验、细胞概率突降位置、去除计数的基因分布以及警告信息。输出矩阵能被 Seurat 或 Scanpy 读取，只能证明格式可用，不能证明去噪合理。
批量项目可以把 metrics 中“找到细胞数与 expected cells 的比值”“非空液滴占比”和“收敛指标”纳入自动质控，但阈值仍应结合样本类型设定。发现异常时回看单样本报告，不要让一条统一规则覆盖所有组织、建库批次和细胞活性差异。
GPU 服务器怎样配才不会“只快一半”
单样本运行时，GPU 负责模型训练和推断，但原始矩阵加载、posterior 整理、HDF5 写入和报告生成仍会消耗 CPU 内存与磁盘。大量样本并发时，显卡数量增加还会同步放大 CPU、内存和 NVMe 压力。若所有任务把 checkpoint、posterior 和报告写进同一个拥堵的网络目录，GPU 也会等待 I/O。
因此，服务器规划应按“单样本峰值 × 并发数”核算：每个任务绑定 GPU，限制并发，给系统内存留余量，并把临时文件放到节点本地高速盘；完成后再把 h5、报告、日志和 checkpoint 归档。对于几十个样本，可先分层试跑低背景、中等背景和高背景样本，再确定队列资源，而不是一次性全部提交。
去掉更多 counts，不代表结果一定更好
CellBender 适用于液滴型 scRNA-seq、snRNA-seq 和 CITE-seq 的系统背景建模，但它不能修复严重失败的实验。官方文档指出：若空液滴几乎没有 UMI，工具可能几乎不去除；若背景高到无法辨认空液滴平台，算法也可能困难，这时应认真考虑实验质量本身。
去噪后的差异基因、细胞比例和稀有群体需要与原始矩阵、标记基因和样本背景对照。FPR 变大往往伴随更多信号被移除，不能用“去得越多越干净”判断质量。
如果你的 CellBender 任务卡在 CUDA 环境、posterior 阶段 OOM、多样本排队缓慢，或不知道液滴数、GPU、系统内存和临时盘如何搭配，可以准备 CellBender 版本、输入格式、预计细胞数、UMI rank 图、液滴数、报错和样本数量。云生信会先判断是参数、环境还是资源瓶颈，再确认租用环境自行运行、环境部署交接或委托分析的范围。
联系云生信，咨询 CellBender GPU 环境与分析方案
