普通云服务器能否跑生信，关键在于目标软件的要求是否被满足。一个能启动Linux和R的实例，可能仍缺所需指令集、可用内存、足够临时盘或特定GPU软件栈。本文把兼容性核对拆成软件、CPU、内存、磁盘和访问环境五项，适合在购买或租用前填写一张技术需求表。最终容量仍须用目标任务验证，不能仅根据产品类别判断。
先写下软件名称、版本、子命令、建库类型或模型，以及输入规模。不同版本和不同子流程可能要求不同资源。比如Cell Ranger官方列出系统、CPU、内存与存储要求，并提醒大数据集需要额外资源；这些要求不能直接当作Seurat、组装或蛋白预测的通用标准。阅读官方页面时记录版本和核对日期，正式部署再确认当前版本是否仍适用。
| 检查层 | 应准备的依据 | 通过条件 |
|---|---|---|
| 软件 | 目标版本的官方要求和支持输入 | 版本与任务相匹配 |
| CPU | 架构、指令集与实际额度 | 二进制能在该架构运行 |
| 内存 | 实际可用量、容器或账号限制 | 覆盖任务峰值及并发安排 |
| 磁盘 | 工作路径、容量、临时盘与读写 | 流程所需路径可写且空间足够 |
| 系统与依赖 | 发行版、系统库、R/Python或容器 | 样例运行及必要依赖通过 |
| 访问 | 数据、参考、许可和网络条件 | 所需内容可按获准方式获得 |
登录候选Linux环境后读取CPU信息，再与软件要求核对。以下检查不改变系统。x86与ARM不能仅凭核心数互换；即使架构相同，某些预编译程序也可能要求特定指令集。出现Illegal instruction时，应核对程序构建和CPU支持，而不是继续增加内存。
uname -m
lscpu
grep -m1 -E 'flags|Features' /proc/cpuinfo
nproc
# 记录输出，并与具体工具版本的官方要求逐项对应虚拟CPU的定义、CPU型号是否固定和可用额度应向提供方确认。nproc是当前环境的可见信息，不替代合同资源说明。对于GPU任务，还需核对实际GPU型号与显存、驱动、框架和CUDA兼容；能运行nvidia-smi只证明某一层设备可见，不能单独证明目标模型已经能调用GPU。
先定位项目实际工作目录，再看空间与文件系统。系统盘空余不等于工作盘空间，挂载点配置不对还可能把大文件写进系统盘。除了总字节，还应注意小文件较多时的inode和账号配额。配额如果由管理员或平台设置，普通df输出未必反映全部限制，应使用该环境提供的配额查询方式。
pwd
df -h .
df -i .
findmnt -T .
free -h
cat /proc/self/cgroup
ulimit -a内存也要分清主机总量、当前可用量和任务硬限制。Docker等容器可设置独立资源约束，cgroup限制还可能来自上级组。不要因为free显示大量内存，就假定某个账号任务拥有全部额度。与提供方写清最大可用量，以及超过额度时是限制、终止还是需要调整方案。
先用官方或项目已有的小样例确认程序能运行、依赖完整、输入类型受支持，再逐步测试正式步骤的内存、时间和临时盘。程序一启动就缺动态库，应修复环境；样例正常但正式数据内存超限，才进入容量评估；CPU不满而I/O等待高，应检查存储与并发。三类问题不能统一解释成配置不够。
验收记录应保存软件版本、输入说明、实际命令、输出检查、资源日志和环境清单。候选资源通过这些条件后，再按长期使用、账号、目录和并发需要做补充验证，结论只覆盖已经测试的范围。