Skip to content

SuperMSA（CPU 集群版）赛题说明

Note

SuperMSA 赛题负责同学：水熙锐 shuixr25@mails.tsinghua.edu.cn

赛题介绍

多序列比对（Multiple Sequence Alignment，MSA）是蛋白质结构预测、功能注释和进化分析中的基础环节。本任务聚焦如下场景：给定一条查询蛋白质序列，程序需要在大规模序列数据库中检索同源序列，并将检索得到的序列按照残基位置完成比对。

具有同源关系的序列往往携带重要的共进化信号。在漫长演化过程中，同源蛋白的氨基酸位点并非独立突变：维持蛋白折叠、分子互作与功能活性的残基之间会发生协同变化，若某一位置发生突变，与之功能耦合的位点也会产生对应的补偿突变，以此维持蛋白质整体结构与功能稳定。这种残基位点间协同突变的关联信息即为共进化信号。在 MSA 中，大量同源序列汇聚对齐，能够将单条序列中无法观测的共进化耦合关系显现出来。但同源序列并不一定拥有较高的序列相似度，部分远缘同源序列的序列一致性低于 30%，很难被准确检索识别。

除此之外，序列数据库通常包含数千万乃至上亿条待比对序列。尽管现代算法引入了多级过滤机制，MSA 检索的计算开销依旧居高不下。以 AlphaFold3 为例，其默认数据流水线采用 HMMER 套件中的 JackHMMER 对蛋白质序列执行迭代搜索。随着生物数据库规模持续扩张、蛋白质结构预测需求不断提升，MSA 搜索耗时占端到端预测总时长 70% 以上，MSA模块成为整条预测流程最主要的性能短板。

因此，如何在保证搜索灵敏度的同时控制计算成本，是同源序列搜索领域长期存在的核心问题。

初赛提供 100 条蛋白质序列样本与一个包含数千万条序列的蛋白质数据库作为输入。参赛选手需要在保证结果正确性的基础上，尽可能优化程序在 CPU 平台上的运行性能。本赛事的运行平台为探索 1000 集群的单 CPU 节点，可用资源限制为 56 核。

相关论文

Accurate structure prediction of biomolecular interactions with AlphaFold 3

MMseqs2 enables sensitive protein sequence searching for the analysis of massive data sets

运行程序

代码获取

为方便选手使用，我们提供了 GitHub 仓库链接，这些仓库基于原作者版本进行了少量修改，以便更稳定地运行

https://github.com/thu-scc/SuperMSA.git

原作者仓库地址 - hmmer

数据获取

为方便选手使用，我们提供了清华云盘的获取链接。

https://cloud.tsinghua.edu.cn/f/5a06712e096a4226978f/

运行程序

github仓库中的Readme文件已经提供了从下载到运行的全流程脚本和命令行。

# 1. 克隆代码到 WORK
cd ~/WORK
git clone https://github.com/thu-scc/SuperMSA.git && cd SuperMSA #网络不佳可考虑下载压缩包后scp

# 2. 测试节点：编译 + 冒烟测试
ssh test01
module load compilers/gcc/v12.2.0    
cd ~/WORK/SuperMSA
autoconf            
./configure
make
./smoke_test.sh     # 预期输出: PASS: 8 hits

# 3. 登陆节点，数据解压到 WORK，与仓库并列
exit
cd ~/WORK
wget https://cloud.tsinghua.edu.cn/f/5a06712e096a4226978f/?dl=1 -O preliminary.tar.gz
tar xzf preliminary.tar.gz           # 得到 ~/WORK/preliminary/{query/, database.fasta}         

# 4. 提交完整基线作业（输出 stdout.%j 写在提交目录）
sbatch SuperMSA/job_baseline.slurm      # 路径可通过 REPO/DATA/OUT 参数修改
squeue -u $USER                      # 查看状态：PD 排队 / R 运行

评测指标

同源序列判断

本评测方案基于 SCOP 结构域注释判断同源关系，每个 SCOP 标签形如a.1.1.1 ，四个字段分别表示 class、fold、superfamily 和 family。每个蛋白质序列可能有多个 SCOP 结构域标签。查询序列和数据库目标序列均带有 SCOP 标签，数据库同时包含反转诱饵序列。命中判定规则如下：

命中序列判定
任一结构域与 query 同 superfamilyTP
否则，任一结构域与 query 同 fold忽略
否则，带有 class e 结构域忽略
否则，有标注（不同 fold）FP
无标注（反向诱饵）FP

指标定义

  • 召回率 = 找回的同 superfamily 序列 ÷ 真同源序列总数
  • 精确度 = 找回的同 superfamily 序列 ÷ 找回的序列总数
  • ROC1 = 第 1 个 FP 之前找回的真同源序列数量 ÷ 真同源序列总数
  • ROC10 = 前 10 个 FP 各自之前找回的真同源序列数量取平均 ÷ 真同源序列总数（Gribskov-Robinson 定义； FP 不足 10 个时按最终 TP 数补齐）。

在本赛题中 ROC10 是主要的质量指标。评测程序会同时打印出四个指标供选手进行调试改进。

评分方式

本赛题的得分分为正确性和性能两部分：

  • 正确性：该模块总分占全部评测分数的 30%。
    • 判断标准：对每个 query，若其 ROC10 ≥ 基线 ROC10 × 90%，则该 query 判定为正确；否则错误。
    • 扣分规则：每出现 1 个错误 query，扣除正确性部分分值的 1/5；正确性最低扣至 0 分，不出现负分。
  • 性能：该模块总分占全部评测分数的 70%。
    • 判断标准：统计预处理和完成全部 100 条序列搜索任务的总墙钟时间，即日志中的 prologue time + search time，不评估单条序列的搜索耗时。系统提供预热（warmup）阶段，预热耗时不计入。索引、embedding 生成等一次性预处理操作须计入 prologue time，并在报告中公开说明。
    • 得分规则：性能得分采用全场最快时间与实际运行时间的比值进行赋分计算。

可优化方向

  1. 批量处理：单条查询固定开销较大，但批量查询能够摊薄初始化成本
  2. 多任务并行：默认单个任务只占用8核，可以考虑同时运行多个任务
  3. 并行优化：研究 jackhmmer 扩展性，实现高效的并行方案。
  4. 向量化优化：结合平台 SIMD 特征、线程调度等进行优化
  5. 数据库与 I/O 优化：研究数据库布局、内存映射、分片等方案降低非核心计算开销。

提交要求

基本提交（计分）

初赛期间，使用提交脚本向计分服务器提交运行结果。

提交一份 SuperMSA 完整运行日志，即在运行目录执行 sbatch SuperMSA/job_baseline.slurm 后生成的 stdout.<JOBID>，原样提交，不得修改。日志中必须包含：

  • 预处理耗时 prologue time = ... s，必须为有限的非负数；即使没有额外预处理，也必须保留该行；
  • 全部 100 条正式 query 的运行记录及正确性评测汇总，official queries、with hit table 均须为 100，incorrect 的分母须为 100，search time 后须标明 (100 run)；
  • mean ROC10、incorrect = ... / 100 queries 等正确性结果，以及有效的 search time = ... s ... (100 run)；搜索耗时必须为有限的正数；
  • 同一次完整运行的结果，不得拼接多次运行、复用旧查询结果或只截取末尾汇总；缺失命中表、漏跑查询或运行失败的日志无效。

计分用时为 prologue time + search time，预热时间不计入；正确性部分按 incorrect 扣分，每个错误 query 扣除该部分分值的 1/5，最低为 0。

提交方式（提交脚本与题目名称以提交指南为准，请将作业编号替换为本队实际编号）：

wget https://lab.cs.tsinghua.edu.cn/scc/assets/submit.sh
chmod +x submit.sh
./submit.sh SUPERMSA stdout.12345          # 计分提交
./submit.sh --dry SUPERMSA stdout.12345    # 仅校验，不计入成绩

样例日志：supermsa-sample.log。该日志完成 100 条 query，incorrect = 0 / 100，计分用时为 2.0 + 45372.3 = 45374.3 s；样例仅供对照格式，正式提交须使用本队实际运行产生的完整日志。

最终提交

将以下材料与其他赛题的最终材料统一打包为 一个 .tar.gz 压缩包，通过 REPORT 提交；打包命令和截止时间见提交指南。本题需包含：

  • 优化报告：说明性能瓶颈、优化方法、运行配置、预处理内容与耗时，以及优化前后的总用时和加速比；
  • 修改过的源码或补丁、实际使用的 job_baseline.slurm 及相关运行脚本、编译与环境配置；
  • 与计分提交对应的完整运行日志及正确性评测明细 scores_vs_baseline.tsv。