空间转录组最容易被低估的，不是画图，而是重新分割细胞、导入第三方 segmentation、重新分配转录本这些“看起来只是换边界”的步骤。Xenium Ranger v4.0 可以 resegment、relabel、import-segmentation，还支持基因与蛋白表达数据；但组织面积和转录本数量一放大，内存需求并不是线性的小幅增加。
官方基础要求写着 64 GB RAM，很多人据此安排一台普通工作站。可在 2 cm²、约 10 亿转录本的特定任务中，官方最低内存会提高到 256 GB，导入 GeoJSON 细胞与细胞核边界时甚至达到 488 GB。这正是空间数据更适合先做资源测算、再上服务器的原因。
64 GB 是基础门槛，不是所有数据的统一答案
Xenium Ranger v4.0 对 relabel、resegment 和 import-segmentation 的基础要求是 8 核 CPU、64 GB RAM、1 TB 可用磁盘，并推荐 32 核、128 GB RAM。CPU 还需支持 AVX2。官方内部测试常用 --localcores=32 --localmem=128。
真正改变配置的是组织面积、转录本总数与导入数据类型。下表均来自 10x Genomics v4.0 系统要求，不是云生信自行设定的“建议价位”。
| 数据规模与任务 | 官方最低内存 | 为什么更重 | 配置判断 |
|---|---|---|---|
| 常规 resegment / relabel / import | 64 GB | 基础图像、边界与转录本处理 | 128 GB 更接近官方测试配置 |
| 1 cm²、5 亿转录本，导入转录本分配与可视化多边形 | 256 GB | 大量转录本与 polygon 映射 | 单节点高内存优先 |
| 2 cm²、10 亿转录本，relabel | 256 GB | 全量转录本重标注 | 预留内存与 1 TB 以上工作空间 |
| 2 cm²、10 亿转录本，导入核/细胞 GeoJSON 边界 | 488 GB | 海量多边形解析、索引与关联 | 512 GB 节点更合理 |
| 2 cm²、10 亿转录本，导入 Cellpose label mask | 256 GB | 标签矩阵与转录本分配 | 先核对 mask 尺寸和格式 |
为什么 GeoJSON 可能比 label mask 更吃内存
同样是“导入 segmentation”，输入表达方式不同，计算路径也不同。GeoJSON 需要解析大量多边形顶点、几何关系和细胞/细胞核边界，再与空间转录本建立对应；label mask 更像规则网格上的整数标签。官方因此给出了 488 GB 与 256 GB 的不同最低值。
这并不说明 label mask 一定更好。GeoJSON 便于保存精细边界和外部工具结果，mask 便于像素级对齐。选择时要同时看分割算法输出、坐标转换、下游可视化和复现需求，不能只为了省内存临时改变数据表达。
v4.0 的 import-segmentation 支持 transcript-based 方法的 FeatureCollection 与 GeometryCollection GeoJSON，但后者已经标记为弃用并计划在未来移除。新流程应优先采用仍被支持的格式，避免资源准备完毕后才因兼容性返工。
一套更稳的运行方法
第一步，先从 experiment.xenium、转录本数量、组织面积和 segmentation 输入类型确定任务档位。只说“一个 Xenium 样本”信息不足；同一平台的 1 cm² 与 2 cm² 数据，资源要求可能跨越一个数量级。
第二步，显式限制本地资源，不要直接让程序占满共享服务器。Xenium Ranger 默认会使用可用内存的 90% 和全部核心，可用下面的方式固定 32 核与 128 GB：
xeniumranger resegment \
--id=sample_resegment \
--xenium-bundle=/data/xenium/output-XETG00000__001__sample__date.zip \
--localcores=32 \
--localmem=128
命令只是资源控制示例，实际 pipeline、bundle 与分割参数必须按研究目标设置。若样本属于 5 亿或 10 亿转录本的大任务，应按官方高内存表重新配置，而不是硬把 --localmem 压到 128。
第三步，提前检查 Linux 资源限制。官方建议用户打开文件数至少 16k，系统最大文件数按可用内存每 GB 配 10k，用户进程数按每个可用核心 64。很多任务不是 RAM 真不够，而是默认 ulimit 只有 1024 或 4096，程序大量并发进程和文件时被系统截断。
第四步，把输入 bundle、第三方边界文件、工作目录和输出放在吞吐稳定的存储上。基础要求已经是 1 TB 可用空间；大样本还应为中间文件、失败重跑与归档保留余量。共享 NFS 能支持集群模式，但网络盘拥堵会让更多 CPU 核等待 I/O。
官方 v3.1 曾用 200 FOV、约 5.14 亿转录本的数据做过 SSD/HDD 对比：resegment 分别约 3 小时 21 分和 3 小时 27 分，relabel 约 1 小时 14 分和 1 小时 20 分；导入转录本分配时，SSD 约 1 小时 35 分，HDD 约 1 小时 58 分。这里不能把旧版本结果当成 v4 的固定耗时，但它说明不同 pipeline 对存储敏感程度不同，导入转录本分配尤其值得关注 I/O。
容量规划也要区分“可用空间”和“最终交付大小”。运行期间输入 bundle、解压或缓存内容、pipestance、中间矩阵、cells.zarr、报告和最终 bundle 可能同时存在。若服务器还要并行处理多个样本，应按并发峰值预留，而不是等一个任务写满后再临时迁移。
基线测试最好选组织面积、转录本密度和边界复杂度都具有代表性的样本，同时记录峰值内存、打开文件数、进程数、读写吞吐和阶段耗时。只有这样，扩容决定才有证据，而不是简单地把 CPU 核数拉满。
服务器、单节点提交还是集群？
10x Genomics 给出三种运行方式：独立服务器、单节点 job submission、以及基于 SLURM 的集群模式。独立服务器最直接、最容易排错；单节点提交适合已有调度系统的团队；多节点集群可以缩短部分任务，但配置复杂度最高。
不要因为有集群就自动选择多节点。对于 488 GB 内存级别的 GeoJSON 导入，如果已有单台 512 GB 或更高内存节点，单节点往往更容易保证路径、版本和失败恢复。只有任务可有效拆分、共享文件系统稳定、SLURM 配置成熟时，多节点才真正有价值。
Xenium Ranger v3.1 已支持失败后用相同命令从原 pipestance 阶段恢复，v4.0 延续了新一代流程。运行时应保留完整输出目录、命令、版本与日志，不要失败后直接删除 pipestance，否则会把可恢复任务变成从头重跑。
分割结果能跑完，不代表生物学上合理
resegment 或 import 成功，只说明软件完成了边界与转录本分配。核扩张距离、细胞边界 stain、Cellpose/Baysor 参数都会改变每个细胞收到的转录本和细胞面积，进而影响细胞类型、空间邻域与差异表达。
至少要核对分割细胞数、无核或异常多边形、每细胞转录本数、细胞面积、组织边缘和典型 marker 的空间位置。v4.0 还加入大细胞分割选项和蛋白图像作为边界或内部 stain 的能力；这些选项应由组织结构和染色质量驱动，而不是为了得到更多细胞。
如果你的 Xenium Ranger 任务卡在 64/128/256/512 GB 内存选择、GeoJSON 与 mask 取舍、进程/文件数限制、NFS 性能或多样本排队，可以准备 Xenium Ranger 与 XOA 版本、组织面积、转录本数量、pipeline、segmentation 格式、当前报错和期望完成时间。云生信会先判断瓶颈在内存、文件系统、格式还是流程参数，再确认租用环境自行运行、环境部署交接或委托分析的范围。
联系云生信，咨询 Xenium Ranger 服务器与空间分析方案
