候选服务器的配置表只能说明计划提供什么，真正的验收需要回答：在这个账号、这个工作盘和这个环境里，目标任务能否按约定运行并产出正确结果。本文给出一套从轻量检查到代表性任务的验收流程，适合在正式上传全部研究数据之前执行。它不是跑分竞赛，也不通过压满共享节点来证明性能。

准备一个可复核的验收包

选择获准使用的小规模输入、固定的软件版本和一条能够在原环境正确运行的命令。明确预期输出、参数、线程和随机设置，再列出目标正式规模。没有旧基准时，可先用软件官方测试数据和预期结果建立兼容性基准，但应说明它只覆盖该样例；一个小数据集成功，不能证明大队列一定能完成。

验收部分应保留的证据不合格时先排查
身份与路径账号、工作目录、挂载和配额登录身份、权限或写错磁盘
环境软件版本、依赖、镜像摘要缺库、构建与架构兼容
输入文件列表和内容校验传输缺失、文件名或参考差异
执行实际命令、退出码、stdout和stderr参数、限额、临时目录
输出必要文件、维度或关键指标流程未完成或结果不适用
容量峰值、耗时、工作盘增长计算、内存或I/O瓶颈

先检查文件系统的基本写读能力

在约定的工作盘里新建独立验收目录，做小文件写入、复制和校验。下面使用教学文本，不接触原始数据；文件很小，不能用于推断磁盘的持续吞吐性能。若工作盘路径由提供方指定，应先进入该路径，避免误测系统盘。

mkdir -p acceptance-pilot/{input,output,logs}
cd acceptance-pilot
printf 'acceptance-demo\n' > input/demo.txt
sha256sum input/demo.txt > demo.sha256
sha256sum -c demo.sha256
cp input/demo.txt output/demo-copy.txt
cmp input/demo.txt output/demo-copy.txt
df -h . > logs/filesystem.txt
df -i . > logs/inodes.txt

校验失败时先确认路径、文件内容和账号权限，不能把小文件复制失败归为服务器性能不足。临时目录如果在另一挂载点，应单独检查其容量与访问限制。日后正式任务也应记录实际临时路径，否则验收时测的工作盘与程序真正使用的盘可能不同。

用同一命令测代表性任务

把目标分析整理成已验证的run_target.sh，要求从当前项目目录读取指定输入并输出到约定位置。脚本必须与要验收的软件相对应；不要为了让测试通过而换成一个完全不同的轻量程序。使用独立日志前缀，保存原始统计和退出状态，失败日志也要保留。

/usr/bin/time -v -o logs/target.resources.txt \
  bash run_target.sh \
  > logs/target.stdout.txt \
  2> logs/target.stderr.txt
status=$?
printf 'exit_status=%s\n' "$status" > logs/target.exit.txt
grep -E 'Elapsed|Maximum resident|Exit status' logs/target.resources.txt

GNU time的统计用于解释本次执行。多进程、容器和调度任务还需要按环境补充任务层统计，不能只取一个进程数值相加或当作节点总消耗。若记录显示实际任务早早退出，较短耗时不是性能提升；只有输出验收通过后，耗时比较才有意义。正式数据规模不同，也应单独记录，不能把不同规模的运行时间混在同一张比较表里。

核对结果，再确认并发和规模边界

逐项检查预期文件存在、非空、可读取、样本标识一致，以及与基准的关键指标相符。确定性输出可以比较hash；含时间戳、随机过程或浮点差异的结果，应定义适当字段和容差，必要时由熟悉方法的人复核。日志没有ERROR也不代表生物学结果已正确，更不能以服务器验收替代研究质量审查。

兼容性通过后，再用正式任务的代表性规模确认内存与工作盘，并在约定条件下测试需要的并发。不要擅自对共享节点执行破坏性或满负载压力测试。把通过范围写清：哪一版本、哪种输入、多少并发、哪个目录、需要哪些额外支持。发现容量缺口时，拿资源日志调整配置；发现软件问题时，先处理兼容性。