直接回答：ColabFold 本地部署需要多大显存，官方没有给数字，只能拿你最长的那条序列实测。 但有一条更容易被忽略的事实：很多”爆显存”不是序列长到跑不了，而是打开了会成倍抬高显存的实验性参数。
三句话记住：
- 显存需求按”最长序列”算，不按平均长度算：500+ 残基和 100–200 残基不是一个量级；
training=True这类实验性参数会成倍抬高显存：官方 issue 里一条 500 多残基的序列，报错时请求过一次约 53GB 的分配；- 本地部署要过两道门：显存够不够（实测）+ 容器镜像的 CUDA 标签与本机驱动对不对得上。
一、先说清”53GB 是怎么来的”
官方仓库有一条至今未关闭的 issue（sokrypton/ColabFold#352，2023-01-11 创建），标题本身就是结论方向：training = True causes a GPU memory error, asks for 53 GB on normal sized proteins。
| 项 | 官方 issue 里的事实 |
|---|---|
| 场景 | 官方 AlphaFold2_batch notebook，批量预测 |
| 输入 | 3 条序列：517 / 536 / 553 残基，三条全部失败 |
| 报错原文 | Out of memory while trying to allocate 53061779456 bytes |
| 换算 | 约 53 GB 的一次性分配请求 |
| 触发条件 | 同时打开了 training = True |
| 时间点 | 报错出现在 Running model_3 之后约 23 秒 |
三点判读（属工程判断，官方未在该 issue 里给定论）：
- 一次就要 53GB，说明是设置把显存需求放大了，而不是”序列长到必然跑不了”；
- 官方 notebook 里的
training=True属于实验性设置（用于采样多样性），会同时抬高显存与耗时； - 500–550 残基在高校里很常见（不少靶点、复合物都在这个区间），所以这个问题会反复撞上。
二、遇到爆显存的排查顺序（照这个顺序做，别乱试）
① 先看最长序列有多少残基（知道显存需求的上限在哪）
② 再确认有没有开 training=True 这类实验性参数 —— 先关掉再测
③ 再看是不是把长序列和短序列混在同一个 batch 里
④ 降低单批条数 / recycle 次数
⑤ 用 nvidia-smi 记录"单条预测的显存峰值"，标定长度↔显存曲线
⑥ 按曲线决定一次并行跑几条，或者再谈加卡/换卡关键点：前 4 步都不花钱。不做标定就下单加卡，等于赌。
三、本地部署的第二道门：容器镜像和驱动
ColabFold 官方的本地路线是 Docker / Singularity 容器，镜像标签按 CUDA 版本分发。官方 wiki 写明：
| 项 | 官方口径 |
|---|---|
| 镜像命名 | Each Docker image tag follows the format colabfold:<colabfold_version>-cuda<cuda_version> |
| 当时的可用标签 | 用户转述官方 wiki：CUDA 11.8 / 12.2 两个版本 |
| 驱动下限 | CUDA 12 需驱动 ≥ 525.60.13；CUDA 11 需驱动 ≥ 450.80.02 |
| 官方建议 | 始终使用最新驱动 |
| 运行参数 | Docker：--runtime=nvidia --gpus 1；Singularity：--nv |
| 需要挂载 | /cache（模型缓存/权重目录） |
| 权重下载 | python -m colabfold.download |
所以”本地装不上”的常见原因不是代码，而是驱动太旧：镜像只按若干 CUDA 版本构建，当机器驱动只能支持更低的 CUDA 时，就会出现”找不到可用标签”。升级驱动通常比到处找旧镜像更省事。
四、交付/自建时按这 6 步走
| 步骤 | 做什么 | 为什么 |
|---|---|---|
| 1 | 问清最长序列多少残基、一次跑几条 | 显存需求由最长那条决定 |
| 2 | 用最长序列做单条实测，记录显存峰值 | 官方无显存表，只能实测 |
| 3 | 标定”长度 ↔ 显存”曲线，再定并发 | 避免批量跑到一半集体失败 |
| 4 | 按 nvidia-smi 的驱动版本选容器标签 |
驱动 ↔ CUDA 大版本必须对得上 |
| 5 | 容器内验证 GPU 可见（docker run --gpus all … nvidia-smi） |
直通没配好时，容器里看不到卡 |
| 6 | 权重先下载到 /cache 并固定路径 |
首次运行要拉较大权重，容易误判成”卡住” |
五、询价/自建前，先确认这 6 个问题
| # | 要问的 | 为什么 |
|---|---|---|
| 1 | 最长的序列多少残基？ | 显存需求的上限 |
| 2 | 一次跑几条？批量还是单条？ | 批量与并发直接决定显存压力 |
| 3 | 会不会用 training=True 这类实验性参数？ |
会成倍抬高显存 |
| 4 | 机器驱动版本是多少？ | 决定能用哪个 CUDA 标签 |
| 5 | 本地部署还是先用线上/公共算力？ | 使用频率低时，先租可能更省 |
| 6 | 有没有 MSA（多序列比对）数据库与存储需求？ | 这部分吃的是内存与磁盘，不是显卡 |
常见问题
ColabFold 本地部署至少要多少显存？
官方没有给出显存表，必须用你最长的那条序列实测。可参考的事实是：官方 issue 里 500–550 残基的序列、在打开 training=True 的情况下，出现过约 53GB 的一次性分配请求——这说明参数设置可以把需求放大到远超常规显存。正确顺序是：先关掉实验性参数、用最长序列实测单条峰值，再乘并发数并留余量。
ColabFold 报 Out of memory 一定是显卡不够吗？
不一定。前面那条官方 issue 里，三条 500 多残基的序列全部失败，而触发条件里包含 training=True——关掉它、降低并发、把长序列单独排批，往往就能跑通。判断方法很直接：用 nvidia-smi 看单条预测的显存峰值，如果峰值离显存容量还有很大距离却仍报 OOM，就要怀疑是批型或参数的问题，而不是卡的问题。
本地部署 ColabFold 用 Docker 还是裸装？
官方 wiki 给的是容器路线（Docker / Singularity），镜像标签按 CUDA 版本分发，并写明了驱动下限（CUDA 12 需 ≥525.60.13、CUDA 11 需 ≥450.80.02）。容器路线的最大好处是环境与宿主隔离，不会被系统里已有的 CUDA、Python 版本干扰；代价是要先把 nvidia-container-toolkit 配好、确认容器内 GPU 可见，并把 /cache 挂出来。
权重下载很慢、首次运行像卡住了，正常吗？
正常。官方要求先执行 python -m colabfold.download 把权重下载到缓存目录（容器里对应 /cache）。首次运行会拉取较大的模型文件，表现为长时间没有输出。交付时的做法是：先把权重下载到位并固定在 /cache，再让用户跑第一条序列，避免把”在下权重”误判成”机器有问题”。
如果你们正在给课题组或实验室看机器，把 要跑的软件 / 模型、大概几个人用、预算范围 发我一句，我按这个给你一份带参数清单的配置思路——不推销最高配，只帮你把钱花在真正影响出结果的地方。
