AlphaFold 把“没有结构可查”变成了“结构多到查不动”。AlphaFold DB 当前页面列出 261,552,403 个预测模型；面对这样的结构海洋，逐个下载、逐个比对已经不可行。Foldseek 把三维局部相互作用编码成 3Di 序列，论文报告它可把结构检索时间缩短 4～5 个数量级，在 AlphaFoldDB 基准中相对 Dali 和 TM-align 分别快约 184,600 倍与 23,000 倍。
但“算法快”不等于“随便一台电脑都能跑”。Foldseek 官方给出的 AFDB50 数据库约有 5400 万条目：默认保留 Cα 信息时需要 151 GB RAM；关闭结构位排序后可降到 35 GB，却会改变命中排序和最终分数。真正要规划的，是数据库规模、查询方式、内存、索引、临时盘与并发，而不只是 CPU 核数。
先算内存：不是“装上 Foldseek”就结束
官方给出的默认内存估算式是：(6 bytes Cα + 1 byte 3Di + 1 byte AA) × 数据库残基数。这意味着内存随数据库总残基数增长，而不是只看结构文件数量。长蛋白、全蛋白组、多个版本并存，都可能把同样的“几千万条结构”推到不同资源档位。
| 场景 | 官方或可计算数字 | 资源判断 | 适合做法 |
|---|---|---|---|
| AFDB50 默认搜索 | 5400 万条目、151 GB RAM | 普通 64/128 GB 工作站不足 | 选择 192/256 GB 以上单节点并留系统余量 |
| AFDB50 不保留 Cα 排序 | 约 35 GB RAM | 省内存，但排序和最终分数会变化 | 仅在确认输出影响可接受时使用 |
| 单条或少量查询 | --prefilter-mode 1 不受整库驻留内存限制 |
计算方式变化，适合单查询 | 先小规模验证灵敏度与输出字段 |
| GPU 搜索 | Ampere 或更新架构可获得完整速度 | 数据库还需 padding，显存不是唯一约束 | 先做 makepaddedseqdb，再测吞吐 |
| 自建结构库反复检索 | 先 createdb，可选 createindex |
首次预处理耗时，之后可复用 | 数据库、索引、版本和参数一起归档 |
151 GB 不是服务器应配置的总内存。系统、文件缓存、临时数据库、查询集合和并发任务都要占空间；若节点总内存正好等于理论值，常见结果是搜索刚进入峰值就被 OOM kill。实际配置应在代表性数据上记录峰值 RSS，再决定安全余量。
三种省资源方法，代价并不相同
第一种是关闭结构位排序：
foldseek easy-search query.pdb afdb50 result.m8 tmp \
--sort-by-structure-bits 0
它把 AFDB50 的内存需求从 151 GB 降到约 35 GB，但官方明确说明命中排名和最终分数会变化，E-value 不变。若任务是候选优先级排序、远缘同源发现或后续只取 Top hits，不能只看到“省了 116 GB”，还要验证排序变化是否影响结论。
第二种是对单条查询使用 --prefilter-mode 1。该模式计算全部最优无缺口比对，不受整库驻留内存限制，也能使用 GPU；但它更适合少量查询。把成千上万条结构逐条这样跑，可能从“内存瓶颈”变成“总计算量瓶颈”。
第三种是缩小数据库，例如只检索 PDB、Swiss-Prot 或指定物种蛋白组。这样最省资源，也最容易解释；代价是搜索空间变窄，可能漏掉来自非模式物种、宏基因组或未人工审校条目的远缘结构。数据库范围必须由研究问题决定，不能由机器配置倒推。
CPU、GPU与磁盘：别让快算法堵在数据准备上
Foldseek 的 CPU 版本已经支持多线程和 SIMD。GPU 搜索要求先把数据库转换为 padded 格式：
foldseek makepaddedseqdb targetDB targetDB_pad
foldseek search queryDB targetDB_pad resultDB tmp --gpu 1
官方说明 Ampere 及更新 NVIDIA GPU 可获得完整速度，Turing 可用但速度降低，Volta/Pascal 不受预编译包支持。这里的关键不是“有 GPU 就快”，而是 GPU 架构、数据库格式、显存传输、CPU 解压和本地盘吞吐要配套。若 padded 数据库放在拥堵的网络盘，多块 GPU 也可能等 I/O。
自建库反复使用时，createdb 和可选的 createindex 应只做一次，并固定 Foldseek 版本、源结构清单、数据库生成命令和校验值。临时目录优先放高速本地 SSD；结果、日志和可复现元数据再回传共享存储。这样既减少重复预处理，也避免多人各建一份数据库把容量迅速吃满。
数据库更新也要按“新版本重新建库”管理，而不是直接覆盖旧目录。AlphaFold DB 的数量会随 UniProt 同步发生新增、移除与序列变化：官方 v6 发布说明记录了 241,070,489 个模型，而当前 FAQ 页面已经列出 261,552,403 个预测模型。两个数字对应不同发布状态，不能混用。论文复现时应写明数据库名称、下载日期或版本，以及是否使用 UniProt50 聚类库；否则同一条查询在半年后重跑，候选数量和排名都可能不同。
容量估算还应把原始 PDB/mmCIF、Foldseek 数据库、索引、GPU padded 副本、临时文件与结果分开计算。如果同时保留 CPU 库和 GPU 库，磁盘并不是“下载包大小”那么简单。建议先在目标文件系统完整建一次库，用 du 记录各阶段峰值，再按数据库更新频率和保留版本数核算容量。多人共享时给数据库只读权限，每个任务使用独立临时目录，能减少误删、锁冲突与结果互相覆盖。
一套可执行的上线流程
先用 50～100 条有已知关系的查询做基线，分别记录搜索墙钟时间、峰值内存、临时盘峰值、结果条数和 Top hits 稳定性。再逐步提高查询数与并发，不要一开始就提交全库任务。
结果过滤至少同时看 E-value、比对覆盖度和 TM-score/LDDT 等结构质量指标。Foldseek 论文也指出，多结构域蛋白的相对取向、低置信度区域和高分假阳性需要进一步核查；“速度快”并不取消生物学解释与人工复核。
最后把查询、目标库版本、参数、输出格式与下游脚本写进工作流。对数百到数千个查询，任务数组通常比一味增加单任务线程更便于失败重跑；对共享数据库，限制并发和临时目录，才能避免多人同时把内存与 I/O 打满。
常见故障也应提前纳入验收：进程被系统杀死多半要先查峰值内存；速度随并发上升反而下降，通常要查共享盘吞吐和 page cache；同一查询在 CPU/GPU 路径结果不一致，则要核对数据库是否来自同一源、是否完成 padding、参数与软件版本是否一致。把这些检查写成自动化日志，比任务失败后只保存一张报错截图更有价值。
如果你的任务卡在 35/151/256 GB 内存选择、AFDB/PDB/自建库范围、CPU 与 GPU 取舍、索引复用或批量并发，可以准备查询数量与格式、目标数据库、期望输出、服务器配置和完成时间。云生信可先做资源测算与小样本基线，再确认租用环境自行运行、服务器部署交接或委托分析的边界。
联系云生信，咨询 Foldseek 结构检索服务器与分析方案
