不少人以为 AlphaFold 3 的门槛就是“一张显卡”。真正部署后才发现：模型容器已经启动，任务仍可能卡在数据库下载、MSA 搜索、内存不足或 JAX 编译；如果要批量预测蛋白—蛋白、蛋白—核酸或蛋白—小分子复合物，等待时间和失败重跑还会继续放大。
问题不在于 AlphaFold 3 不能运行，而在于它其实包含两类资源特征完全不同的工作：前半段是依赖数据库、CPU、内存和磁盘 I/O 的数据检索，后半段才是依赖 GPU 和显存的模型推理。把两段混在一台机器上硬跑，往往既浪费资源，也难排查瓶颈。
先看官方量级：显卡只是其中一项
Google DeepMind 当前安装文档给出的完整部署量级很直观：遗传数据库下载约 252 GB，解压后约 630 GB，完整安装需预留最高约 1 TB 磁盘，并推荐使用 SSD；长序列的数据检索阶段建议至少准备 64 GB 内存。官方验证的高性能配置包括单张 A100 80 GB 或 H100 80 GB，可处理最多 5,120 tokens 的输入。
| 环节 | 主要资源 | 官方信息或实用判断 | 常见失败表现 |
|---|---|---|---|
| 数据库准备 | 容量、带宽、解压空间 | 下载约 252 GB，解压约 630 GB，完整部署最高约 1 TB | 下载中断、磁盘写满、权限报错 |
| MSA/模板搜索 | CPU、内存、SSD I/O | 建议至少 64 GB 内存；深 MSA 可能需要更多 | 搜索极慢、内存被杀、进程长时间无输出 |
| 模型推理 | GPU、显存、JAX 编译 | 官方重点验证 A100/H100 80 GB；输入越大耗时越高 | OOM、重复编译、显卡利用率间歇性下降 |
| 批量任务 | 调度、缓存、结果管理 | 应复用 MSA、模板和编译缓存 | 相同链重复检索，成本和总时间成倍增加 |
这些不是所有任务的最低配置。较短输入可以使用更小显存的设备，例如官方文档给出 A100 40 GB 配合 unified memory 可处理到 4,352 tokens，但吞吐会低于 80 GB 配置。关键不是照抄一张“万能配置表”，而是先看输入 token 数、复合物类型、模型种子数量和任务批量。
新版支持 CPU，不代表 CPU 适合批量生产
AlphaFold 3 v3.0.4 已加入 CPU-only 和 Apple Silicon 路径，这让测试环境更容易搭建。但官方安装文档同时说明，CPU-only 折叠大约比 GPU 慢 100 倍，且并非其重点数值验证路径。
因此，CPU 模式更适合检查 JSON 输入、验证依赖、跑通小任务；当目标是几十到几百个候选、多个 seed 或较大复合物时，GPU 仍是更现实的生产选择。能启动与能按截止时间完成，是两套标准。
技术干货一：把数据检索和 GPU 推理拆开
官方程序允许通过 --run_inference=false 只运行 MSA 与模板搜索，也允许通过 --run_data_pipeline=false 跳过数据检索、只做特征化和模型推理。
这意味着可以把 CPU 密集的数据检索放到大内存、快速 SSD 的节点，把推理放到高显存 GPU 节点。GPU 不必在数据库搜索时空等，检索产生的 JSON 也可以保存并复用，失败时无需全部从头再来。
对于固定链 A 与多个候选链组合的任务，复用价值更明显。官方性能文档举例：若有 n 条第一类链和 m 条第二类链，先分别预计算 MSA 与模板，可把原本 n×m 次完整检索降为 n+m 次数据管线运行，再组合做推理。候选筛选越多，这一差距越大。
技术干货二：别让编译时间反复吞掉小任务
JAX 首次遇到新的输入 bucket 会编译计算图。若批量任务的长度分布杂乱，重复编译可能让人误以为 GPU 性能不稳定。AlphaFold 3 支持持久化编译缓存；官方以 152 个残基的蛋白为例，首次运行总计 148 秒，缓存预热后第二次总时间降到 32 秒，其中推理部分为 15 秒。
批量任务可先按 token 长度分组，合理设置 buckets，并使用 --jax_compilation_cache_dir 保留缓存。需要注意，这组数字是官方特定示例，不应直接当作任何服务器都能复现的承诺。
80 GB 显存能带来什么？看输入规模，而不是只看卡名
在官方无编译时间测试中，单张 A100 80 GB 处理 1,024 tokens 约需 62 秒，5,120 tokens 约需 2,547 秒；H100 80 GB 对应约为 34 秒和 1,416 秒。输入规模增长后，耗时并非线性增加，因此长复合物、多个 seed 和批量候选应在启动前做容量与排期估算。
服务器真正节省的也不只是单次推理时间。更重要的是数据库常驻、环境固定、任务排队、日志保留、失败续跑，以及把 CPU 搜索和 GPU 推理放在合适资源上。对偶尔跑一个短序列的人，在线服务或小规模测试可能更省事；对需要本地部署、批量运行或复现流程的团队，稳定环境与调度能力往往比临时找一张显卡更重要。
三种使用方式，先按任务频率选择
如果只是偶尔验证一个较短的目标，先使用合规的在线入口或临时算力，通常比维护整套数据库更简单。若课题组需要反复运行同一批候选、调整复合物组合或保留可复现环境，适合租用已经配置好 CPU、内存、SSD 和 GPU 的计算环境，自行控制参数与结果。若团队缺少部署和结构分析人员，则应把环境搭建、批量运行、结果整理和解释边界拆开确认，再决定是否委托分析。
选择时还要计算“非推理时间”：数据库首次下载与更新、容器构建、模型编译、输入检查、队列等待和失败重跑都会占用项目周期。对于批量任务，先用 3—5 个代表性输入做小规模基准，记录数据管线耗时、峰值内存、显存和单任务输出大小，再估算全部任务，通常比直接把数百个 JSON 一次性入队更稳妥。
先提供 6 项信息，再决定怎么跑
如果准备部署或批量运行 AlphaFold 3，可以先整理：序列或复合物类型、总 token/残基量级、任务数量、seed 数量、可接受完成时间、现有 CPU/内存/GPU/磁盘。云生信可以先判断瓶颈在数据库、数据管线、显存还是批量调度，再分别沟通云生信服务器上的环境部署、租用算力自行操作，或单独委托分析；服务范围与费用分别确认。
首次沟通只需任务概况和可分享的报错摘要，不必直接发送未确认可传输的完整研究数据。AlphaFold 3 输出属于计算预测，需结合置信度、实验数据和具体研究问题解释，不能替代实验验证，也不用于临床判断。
