AF_Cache：面向高通量蛋白质相互作用预测的 AlphaFold 高效化流程

一句话定位：AF_Cache 不改动 AlphaFold 的预测内核，而是用「GPU 加速比对 + 输入特征缓存 + 序列长度分桶」三项工程优化，系统性地消除 AlphaFold2/3 在大规模相互作用筛查中本不该重复做的计算——重复生成 MSA、重复编译模型——从而在保持预测一致性的前提下，把端到端耗时压缩一个数量级以上。

文献信息

一、问题背景

蛋白质之间如何彼此结合，是几乎一切细胞过程的基础。AlphaFold2（AF2）让研究者能够以接近实验的精度、从结构层面预测蛋白质相互作用（protein–protein interaction, PPI），AlphaFold3（AF3）在此基础上进一步提升。然而，当研究目标从"预测少数几个复合物"扩展到"对成百上千个蛋白做全互配（all-against-all）筛查"时，官方默认流程的计算开销会迅速变得不可承受。

作者把 AlphaFold 的耗时拆解为两个主要来源，其中第一项对 AF2 与 AF3 都成立：

（1）多序列比对（MSA）生成。 官方流程依赖基于 CPU 的 JackHMMer 与 HHblits 进行同源序列搜索与比对，这一步本身就慢；更关键的是，AlphaFold 在每次预测前都会临时为当前复合物的每条链重新生成 MSA，完全不复用先前算过的结果。在全互配场景下，这意味着同一个单体的比对会被反复计算无数次。

（2）JAX 模型编译（仅 AF2）。 AF2 的神经网络基于 JAX，当输入序列长度发生变化时必须重新编译计算图。对大蛋白而言这点开销可以忽略；但对一批较短的蛋白来说，编译反而成为单次预测中最耗时的环节。AF2 虽提供了把序列补齐（padding）到等长以复用编译的选项，但该选项仅对单体（monomer）可用，且不支持按多个尺寸分桶，对短序列的效率很差。

在相关工作上，更快的 MSA 方法早已存在：ColabFold 用 MMseqs2 替代了 CPU 比对；Perry 等人的 AlphaFast 进一步用 GPU 版 MMseqs2、以批处理方式为 AF3 加速 MSA 生成。AF_Cache 与这些工作同源但定位不同——它把"去冗余 + GPU 加速 + 减少编译"三件事一并解决，并且同时覆盖 AF2 与 AF3。

二、方法学详解

AF_Cache 的核心是三项相互独立、可叠加的优化。理解它们各自解决什么问题，是判断这套流程价值的关键。

2.1 GPU 加速的 MSA 生成（MMseqs2-GPU + CPU/GPU 并行）

整个数据集的 MSA 在工作流开始时一次性生成，使用 GPU 加速版的 MMseqs2，其序列搜索与 profile 搜索均在 GPU 上完成。单 GPU 的 MMseqs2 已快于纯 CPU 方案，且使用多 GPU 时加速比进一步提升（本文基准在单块 GPU 上进行）。

在比对协议上，AF_Cache 沿用 ColabFold 的搜索与比对流程，并加入一处工程改进：在对 UniRef 数据库与环境数据库（environmental databases）分别比对时，让 CPU 步骤与 GPU 步骤跨两个数据库并行执行，从而减少 GPU 在等待 UniRef 比对完成时的空转时间。这一点是相对 ColabFold 的增量优化。

2.2 输入特征缓存：把组合爆炸压回线性

这是全文最有价值的一刀，其依据是一个简单的组合数学事实。

设有 N 个蛋白做全互配（含同源二聚体），需要预测的二聚体数量为 N(N+1)/2 对。每对包含 2 条链，因此按"每条链各算一次 MSA"的默认逻辑，链级比对总数为：

默认链级 MSA 次数 = N × (N + 1)

但这些链当中，互不相同的单体其实只有 N 个。也就是说，默认流程把每个单体的比对重复计算了约 (N+1) 次。AF_Cache 的做法是：对一组去重后的单体，所有比对与模板特征只生成一次并缓存，需要时直接复用。缓存以 pickle 文件形式存于 AF2 版本，以 JSON 输入文件形式存于 AF3 版本。

在本文 100 蛋白的基准里：默认需 100 × 101 = 10,100 次链级比对（对应 10,100 个"链出现次数"），而实际只需 100 次。去冗余因子约为 101×——这个数字纯由组合关系决定，与硬件、数据库都无关。

为了量化这一收益，作者定义了三条对照基线（贯穿全文与所有图表）：

• • vanilla（原版）：官方默认行为，对每对、每条链都重新生成 MSA。
• • opti（手工优化）：把 100 个单体的 MSA 只生成一次，再用符号链接（AF2）或写入输入 JSON（AF3）的方式复用。这是一个有经验的用户会手动采用的合理基线。
• • AF_Cache：在 opti 的去冗余之上，叠加 GPU 比对与（AF2 的）分桶编译。

2.3 模型编译优化：尺寸分桶 + 张量补齐（仅 AF2）

针对 AF2 的 JAX 重编译问题，AF_Cache 把总长度（两条链长度之和）相近的复合物归入同一个"桶"，桶内将所有特征张量补齐到相同长度。这样 JAX 模型在每个桶内只对第一个复合物编译一次，后续复合物直接复用已编译图。每省去一次编译，约节省 1–2 分钟 GPU 时间。

该机制 AF3 本身已内置（AF3 对单体与多聚体都自动按桶补齐；AF2 仅对单体支持），因此作者只为 AF2 实现，AF3 部分直接复用官方推理代码。

2.4 工程实现与可用性

AF_Cache 以单条 Nextflow 流程交付，工程完成度是其重要卖点：

• • 输入只需一个装有 FASTA 文件的目录；默认执行全互配，也可通过输入文件指定特定配对。对称对默认去重（只保留 A–B、不含 B–A），可用 --both_directions 开关包含双向。
• • 流程自动下载并安装依赖，包括序列数据库与 AF2 的网络权重参数，因此本身也是在本地或 HPC 上部署 AF2/AF3 的一种省心方式。
• • AF3 官方需用户手写 JSON 输入，AF_Cache 将其全自动生成。
• • 支持跨多节点的 HPC 并行，也支持在本地单机运行单个任务。模板生成可用 --skip_templates 关闭。

三、基准测试设计

清晰交代基准设计，是评估这类"加速类"工作可信度的前提。本文的设计如下。

数据集。 于 2026 年 1 月 29 日从人类蛋白质图谱（Human Protein Atlas, HPA）按筛选条件 subcell_location:Mitochondria AND hpa_evidence:Evidence at protein level 获得 821 个线粒体蛋白，随机抽取其中长度在 40–1000 残基之间的 100 个蛋白，序列取自 UniProt。对这 100 个蛋白做全互配（含同源二聚体）预测，共 5,050 对：即 100×99/2 = 4,950 个异源二聚体 + 100 个同源二聚体。三套流程（AF_Cache2/3、AlphaFold2.3、AlphaFold3.0）在同一数据集上对比。

结构证据标注。 为识别"有结构支持"的蛋白对，作者用 MMseqs2 以序列一致性阈值 fident = 0.7 将每个蛋白比对到 PDB（之所以不取更高阈值，是因为许多 PDB 序列短于对应的 UniProt 序列）。当两个或更多蛋白映射到同一 PDB 条目时，其所有可能配对都被标记为"共享 PDB 条目"——作者也明确指出，共享 PDB 条目并不等于这些蛋白一定直接相互作用。

预测设置。

• • AF2（无论缓存或默认）：仅用 model_1_multimer_v3 做单次预测，最大循环数（recycles）= 3；模板生成关闭（缓存版用 --skip_templates，默认版用 dummy 模板库）。
• • AF3：单一随机种子，单个扩散样本（diffusion sample）。
• • 默认流程的 MSA 在独立的 CPU 集群上生成，使用与官方一致的工具（JackHMMer、HHblits）与数据库（full BFD、small BFD、UniRef30、MGnify、UniProt、UniRef90；AF2 默认用 full BFD，AF3 默认用 small BFD）。

硬件。 默认流程的 MSA 部分使用 8/16/32 个 Intel Xeon Gold 6130 CPU 核（视内存需求而定）；GPU 任务在单块 NVIDIA A100（40 GB）上运行。

作者自陈的可比性限制（值得留意）。 受 HPC 集群限制，默认流程的 CPU 与 GPU 部分只能分开运行，这可能与"真正一体化运行的官方流程"存在时间差异；此外，官方流程会对数据库做分区（partition），其内存利用与并行度优于本文的 MSA 生成。为部分弥补这一不对等，作者把对比统一折算到 128 个 CPU 核（假设完美并行），但承认无法保证完全补偿。这一节是判断"加速比是否被高估/低估"的关键背景。

四、核心结果

4.1 预处理（MSA + 缓存）加速：把"13×"和"1343×"讲清楚

原文给出几个不同口径的加速比，初看容易混淆。笔者从补充表 S1 的 MSA 列做了因子分解，发现这些数字其实由两个正交的因子相乘而成，分解结果与原文完全吻合：

这个分解一举澄清了几件事：

• • 原文摘要的 "MSA 最高提速 13×"，指的是单位比对吞吐上 GPU 相对 CPU 的提升（公平折算到 128 核后）；AF2 默认用 full BFD 故为 13×，AF3 默认用 small BFD 故为 5×。
• • 原文另一处的 "相对 vanilla 提速 1343× / 542×"，则是把 GPU 加速与去冗余叠加后的总效果。两个数字并不矛盾，而是同一件事的两个层次。
• • 至于更醒目的 "1702× / 688×"（full / small BFD），是按"原始 GPU 核时 vs CPU 核时"硬比得到的；作者本人即指出这不现实——因为单块 GPU 与单个 CPU 核在成本/可得性上不可同日而语，故才有折算到 128 核后的 13×/5×。

预处理的最后一步是 parse_features：为 AF2 生成缓存与模板（可用 --skip_templates 跳过），平均约 20 秒/蛋白；AF3 版本约 10 秒/蛋白——更短是因为 AF3 自带缓存机制，无需额外生成。

4.2 推理加速：AF2 约 2×，AF3 不变

推理阶段的对比只在 AF2 上有意义，因为 AF_Cache3.0 直接复用 AF3 官方推理代码，与默认 AF3 在该阶段没有差别。（一个工程细节：AF3 的版本会影响推理速度，作者在内部测试中发现 3.0.1 明显快于 3.0.0，流程已自动采用 3.0.1。）

对 AF2，缓存 + 等长补齐把预测与编译的总时间从 253 GPU·小时降到 125 GPU·小时，降幅超过 50%。按每对计（补充表 S2），预测耗时从 180.5 秒降到 89.2 秒，恰为 2.02×，每对节省约 91 秒——与正文"平均每对快约 90 秒"一致。这 90 秒正对应被分桶机制省去的、原本每对都要付出的 JAX 编译开销（落在"每次编译 1–2 分钟"的区间内）。换言之，**AF2 的"2× 推理加速"本质上就是把逐对重复编译变成逐桶编译一次**。

此外，作者注意到在配对总长约 1200 残基以上，AF2 的预测耗时呈现两条曲线。这很可能源于 AlphaFold 的早停容差（early-stop-tolerance）：仅当本轮预测结构与上一轮的 RMSD 超过 0.5 Å 时才追加一次循环；RMSD 较低者在第 2 轮即停止，从而缩短了这些对的预测时间。对比中也可见 AF2（无论默认还是缓存版）整体都明显慢于 AF3。

4.3 完整运行时分解（补充表 S1 / S2）

表 S1：总运行时分解（单位：小时；MSA 已折算到 128 核）

表 S2：每对蛋白平均耗时（单位：秒/对）

派生：整体加速比一览（笔者由上表计算）

这张派生表点出一个常被宣传数字掩盖的真相：面对一个会手动去冗余的用户（opti 基线），AF_Cache 对 AF3 的端到端净增益只有约 6%——因为 AF3 的推理与"其他处理"不受影响，而 MSA 在 opti 下已经很便宜。AF_Cache 对 AF3 的真正价值，更多在于自动化（自动写 JSON、自动缓存）与相对 vanilla 的巨大改进，而非相对一个精心手调流程的推理提速。对 AF2 则不同：分桶带来的 2× 推理提速是 opti 给不了的，故 AF_Cache2.3 相对 opti 仍有 3× 的实打实增益。

4.4 预测一致性（ipTM）：整体中等，结构支持对高度一致

速度之外，作者用 ipTM 评分对比新旧流程预测结果的一致性（Pearson 相关）：

• • 全体配对：相关性中等。 AF2 r = 0.70、AF3 r = 0.64（P < 10⁻³⁰⁰）。作者指出这与 Todor 等人的既往发现一致。
• • 有共享 PDB 条目支持的配对：高度一致。r 升至 0.98（AF2）/ 0.94（AF3）（P < 10⁻³⁰）。
• • AF2 与 AF3 之间： 全体 r = 0.42（AF_Cache）/ 0.41（默认）；在共享 PDB 条目子集上升到 0.92–0.94（补充图 S2、S3）。

作者据此论证：对结构上真实可信的蛋白对，AF_Cache 与官方流程给出几乎相同的判断；整体的中等相关反映的是 AlphaFold 自身对输入的敏感性，而非缓存引入的退化。

五、批判性评价

优点

• • 定位精准、即插即用。 不触碰预测内核，只消除冗余计算，因此风险低、可信度高；Nextflow 封装 + 自动装依赖 + AF3 自动写 JSON，工程完成度在同类工具中突出。
• • 数字诚实。 作者主动区分"1702× 的理想口径"与"13× 的现实口径"，并坦陈 HPC 限制带来的可比性瑕疵，这种透明度在加速类论文里并不常见。
• • 可分解、可复现。 加速比能被干净地分解为"去冗余 × GPU 比对"两个正交因子，且代码、MSA 与预测模型全部公开于 Zenodo。

需审慎看待之处

• • 衡量的是"一致性"而非"正确性"。 ipTM 对比反映 AF_Cache 与默认 AlphaFold 输出彼此是否一致，而非二者对实验真值是否准确。全体配对仅中等相关（0.64–0.70）意味着两套流程在大量蛋白对上给出不同的 ipTM——使用者无论用哪套流程，都应谨慎解读单个配对的 ipTM 绝对值。
• • 中等相关存在一个未被拆开的混杂因素。 该相关性同时包含两个来源：(a) AlphaFold 本身的随机性/输入敏感性（即 Todor 等所述），以及 (b) AF_Cache 与"默认"在 MSA 数据库与比对工具上的系统性差异（ColabFold/MMseqs2 vs 原版/JackHMMer-HHblits）。论文将中等相关主要归因于 (a)，但严格而言 (b) 也会贡献差异：对信号强的蛋白对，两者收敛（高相关）；对边界对，MSA 组成的差异足以让 ipTM 倒向不同结果。这一点对"能否用 AF_Cache 无缝替换默认流程"很重要。
• • 基准范围有限。 仅一个数据集（人类线粒体蛋白、40–1000 残基、100 个蛋白、配对长度上限约 2000 残基），对其他蛋白质组、超大复合物、超长或高度无序的序列，泛化性未直接验证。
• • 加速比依赖硬件与基线。 13×/5× 取决于 A100 vs Xeon 的算力比以及"折算到 128 核且完美并行"的假设；换一套硬件配比，性价比结论会改变。基准为单 GPU，多 GPU 下 MSA 数字会进一步变化。
• • 对 AF3 相对 opti 的净增益很小（~6%）。 如上所述，若你已经在手动复用 AF3 的 MSA，AF_Cache3.0 的额外加速有限，其主要价值在自动化而非推理提速。

小结

AF_Cache 把一个朴素却被长期忽视的事实——全互配筛查中绝大多数 MSA 与模型编译都是重复劳动——转化为一套工程上扎实、对 AF2/AF3 双覆盖、本地与 HPC 通吃的加速流程。其加速可被清晰分解为"去冗余（101×）× GPU 比对（AF2 13× / AF3 5×）"，并对 AF2 额外贡献分桶带来的 2× 推理提速；与此同时，对结构上可信的蛋白对，预测结果与官方流程高度一致。它不是一个新模型，但对"想把 AlphaFold 真正用到蛋白质组规模"的研究者而言，是一个降低门槛、提升吞吐的实用基础设施。