Running ColabFold Locally & on HPC¶

Advanced

The historically slow part of an AlphaFold2-style pipeline isn't the neural network — it's the MSA search (jackhmmer against UniRef90/MGnify, HHblits against BFD/UniRef30), which is CPU-bound and can consume roughly 80%+ of total wall-clock time on the original pipeline. This motivates two related practices seen on real clusters:

1. Run the MSA/template search on CPU-only nodes, and inference on GPU nodes separately — don't tie up an expensive GPU allocation while waiting on CPU-bound sequence search. One common wrapper-script pattern (see the cluster examples below) exposes this directly via a -F true/false "feature-only" flag: run once with -F true -g false to produce features only, then again with -F false -g true on a GPU node to run inference from the cached features.
2. Or skip the search entirely — use ColabFold/MMseqs2. This is the same problem ColabFold was built to solve (see AF2 vs. ColabFold vs. AF3): MMseqs2-based search is dramatically faster, which is why LocalColabFold is commonly the pre-installed "fast path" module on HPC systems alongside native AlphaFold.

Advanced: monomer vs. multimer — two genuinely different conventions

Once you're predicting a complex, native AlphaFold-Multimer and ColabFold expect the input arranged differently — mixing the two up is an easy early mistake:

• Native AlphaFold-Multimer (run_alphafold.py --model_preset=multimer): one FASTA file, multiple separate > records — one per chain. Repeat a record for extra copies of the same chain (homomer), use different records for different chains (heteromer):

  >chain_A
  SEQUENCEA...
  >chain_A_copy2
  SEQUENCEA...
  >chain_B
  SEQUENCEB...
  

  (a homodimer of chain A plus one copy of chain B — source: Yale YCRC AlphaFold guide ↗).

• ColabFold (colabfold_batch or the Colab notebook): a single sequence entry, chains joined with a colon :, no trailing colon after the last chain:

  >complex
  SEQUENCEA:SEQUENCEA:SEQUENCEB
  

  A multi-record FASTA fed to colabfold_batch is instead treated as a batch of independent monomer jobs — one prediction per record, not one complex — the easiest way to accidentally get several unrelated monomers instead of the complex you meant to predict.

Advanced

If you're running ColabFold on your own apptainer/singularity-based setup rather than a documented HPC module, the same CPU/GPU-split logic applies, and it's worth specifically running the MSA step on GPU (via GPU-accelerated MMseqs2) rather than CPU where your hardware allows — this has been benchmarked as dramatically faster than CPU-bound MSA search. See NVIDIA's writeup on GPU-accelerated MMseqs2 for AlphaFold2 and the associated preprint for benchmarks and setup.

A few practical notes carried over from running ColabFold 1.5.3 via apptainer in production:

• Expect one apptainer/JAX-related warning about linking modules of different target triples (nvptx64-nvidia-gpulibs vs nvptx64-nvidia-cuda) — cosmetic, doesn't block a run.
• JAX may log Unable to initialize backend 'rocm'/'tpu' — expected and harmless on a CUDA-only node; JAX is just probing for backends that aren't present.
• Keep a GPU-utilization log (e.g. a background nvidia-smi polling loop writing to a .log file) alongside your job's stdout/stderr logs — useful after the fact for diagnosing whether a run was actually GPU-bound or stalled elsewhere.
• num_recycles and number of seeds are the main levers for the accuracy/runtime tradeoff: the ColabFold defaults (3 recycles) work for most well-aligned targets; bump both up for very large or difficult targets with shallow MSAs (<200 sequences), understanding this multiplies runtime accordingly. This mirrors the official AF2 v2.3.0 guidance that up to 20 seeds and 20 recycles were used as a CASP15 baseline setting for hard targets, but is not the default due to cost.