Performance in OpenFold3 NIM
NIM Accuracy
OpenFold3 is an all-atom biomolecular complex structure prediction model from the OpenFold Consortium and the AlQuraishi Laboratory. OpenFold3 is a PyTorch implementation of the JAX-based AlphaFold3 reported in Accurate structure prediction of biomolecular interactions with AlphaFold 3. Like AlphaFold3, OpenFold3 extends protein structure prediction capabilities to model complete biomolecular complexes including proteins, DNA, RNA, and small molecule ligands.
The OpenFold3 NIM’s accuracy should match that of the AlQuraishi Laboratory implementation of OpenFold3, when using equivalent parameters and inputs.
Running on hardware that is not listed in the Support Matrix might produce results that deviate from the expected accuracy.
The accuracy of the NIM is measured by structural quality metrics such as lddt (local distance difference test). These scores help assess the reliability of the predicted structures.
Factors Affecting NIM Performance
The performance of the OpenFold3 NIM is determined by several key factors:
Hardware Factors
- GPU type and memory: Different GPU architectures provide different performance levels
- System RAM: Larger proteins and complexes require more system memory
- Storage speed: Fast NVMe SSD storage improves model loading and caching performance
Input Complexity
- Sequence length: Runtime increases with total sequence length
- Number of chains: Multi-chain complexes require more computation than single chains
- MSA size: Larger MSAs can improve accuracy but increase memory usage and computation time
- Ligands, DNA, RNA: Additional molecular components increase computational cost
Model Configuration
- Diffusion samples: Multiple samples provide diversity but multiply computational cost
Performance Characteristics
Typical Runtimes
For reference, approximate runtimes on high-end hardware (NVIDIA H100 80GB):
Structure Prediction (OpenFold3 NIM v1.6.0 on NVIDIA H100 80GB):
- ~200 residues: 2.9-3.6 seconds
- ~300-400 residues: 4.5-12.6 seconds
- ~500-600 residues: 11.6-26.8 seconds
- ~800-900 residues: 20.6 seconds
- ~1300-1500 residues: 30.5-53.1 seconds
- ~1700-1900 residues: 56.5-72.5 seconds
- Memory usage: Varies with sequence length, typically 40–80 GB GPU memory
Short sequences improved substantially in 1.6.0. In earlier releases, runtime below roughly 400 residues was dominated by fixed per-request overhead rather than by the model itself, so a 186-residue input cost almost as much as a 600-residue one. CUDA graph capture removes most of that overhead, so runtime now tracks sequence length across the whole range.
The total runtime for structure prediction depends on:
- Total number of residues in the complex
- Total number of atoms in the complex
- Number of molecules and chains
- Number of sequences in the MSAs
- Number of diffusion samples requested
Performance Results on H100
The following table shows OpenFold3 NIM runtime on NVIDIA H100 80GB, with and without structural template processing.
Structural template support is available in version 1.1.0 and later.
All runtimes are in seconds for end-to-end structure prediction with a single diffusion sample. The template measurements include an average of 4 CIF template files per protein chain. The additional time is primarily attributed to CIF parsing.
Performance Analysis
Key Observations:
- Scaling Behavior: Runtime increases with total sequence length and with the number of chains and atoms in the complex.
- Change from 1.5.0: CUDA graph capture removed a fixed per-request cost of roughly 7-8 seconds on H100, so comparing these numbers with the 1.5.0 table shows a ratio that shrinks as inputs grow, from about 3.5x at 186 residues to about 1.15x at 1869, even though the same amount of time was saved in both cases. Read the difference between the two releases, not the ratio.
- Hardware range: The fastest SKUs (GB200, GB300) complete typical predictions in roughly 75% of the H100 time, with B200, H200 and GH200 at 88–91%. A100-class parts take 1.4–1.7x the H100 time. Refer to Table 1 for per-SKU numbers.
- Small proteins (fewer than 400 residues): Complete in ~3-13 seconds on H100.
- Large proteins (more than 1,500 residues): Complete in ~43–73 seconds on H100.
Template Processing Impact:
- Template overhead: Structural templates add modest overhead (typically 1-9 seconds) depending on sequence length and chain count.
- Primary cost: The additional time is mostly attributed to CIF parsing (average 4 templates per chain).
- Overall impact: Templates provide structural guidance with minimal performance cost.
Recommended Configuration:
- For large proteins (more than 1,800 residues): Prefer high-memory GPUs; actual requirements depend on workload (MSA depth, templates, and molecule composition). Refer to Table 1 for measured per-SKU results.
- For template-guided predictions: Structural templates add minimal performance overhead.
Configuration
The benchmarks use the following configuration:
Performance Metrics
The following table contains end-to-end runtime (seconds) for the OpenFold3 NIM across supported NVIDIA hardware units. Inputs are the same 21 benchmark cases, arranged by sequence length and annotated with PDB ID and sequence length.
Table 1: Performance Across the Supported NVIDIA Hardware Units
The table shows the prediction times for tests with varying sequence lengths for hardware units. It features the following:
- Hardware: Nineteen supported GPU SKUs (NVIDIA H100 80GB HBM3, H100 NVL, H100 PCIe, H200, H200 NVL, B200, B300, GB200, GB300, GH200, A100 SXM4 80GB, A100 80GB PCIe, A100 SXM4 40GB, A100 40GB PCIe, L40S, RTX PRO 6000 Blackwell Server Edition, RTX PRO 6000 Blackwell Workstation Edition, RTX 6000 Ada Generation, and DGX Spark GB10). One tab per SKU.
- Metric: End-to-end predict time (seconds).
- Configuration: Default model; no structural templates. Inputs sorted by sequence length and annotated with PDB ID and sequence length.
A dash (—) means the case was not measured on that SKU. The benchmark suite caps input length on memory-constrained parts: 1500 residues on the 40-48 GB GPUs (L40S, RTX 6000 Ada, A100 SXM4 40GB, A100 40GB PCIe) and 1800 residues on GB10. These are benchmark limits, not limits the NIM enforces. The NIM itself imposes no maximum sequence length. Longer inputs on those GPUs may still run, but are not covered by these measurements.
NVIDIA H100 80GB HBM3
NVIDIA H100 NVL
NVIDIA H100 PCIe
NVIDIA H200
NVIDIA H200 NVL
NVIDIA B200
NVIDIA B300 SXM6
NVIDIA GB200
NVIDIA GB300
NVIDIA GH200 144GB HBM3e
NVIDIA A100 SXM4 80GB
NVIDIA A100 80GB PCIe
NVIDIA A100 SXM4 40GB
NVIDIA A100 40GB PCIe
NVIDIA L40S
NVIDIA RTX PRO 6000 Blackwell Server Edition
NVIDIA RTX PRO 6000 Blackwell Workstation Edition
NVIDIA RTX 6000 Ada Generation
NVIDIA DGX Spark (GB10)
Performance Optimization Tips
- GPU Selection: Use any of the supported GPUs listed in Table 1. For best throughput, prefer higher-performance SKUs such as B200, H100, and H200.
- Sequence Length: Performance scales with sequence length.
- Multiple Samples: Setting
diffusion_samples > 1increases runtime in affine fashion (input featurization time is independent ofdiffusion_samples). - MSA Size: While larger MSAs can improve accuracy, they also increase memory usage and computation time. Consider filtering MSAs for very large proteins.
- Structural Templates: Templates add modest overhead (1-10 seconds) but can significantly improve prediction accuracy. Refer to Template Processing for guidance.
- Batch Processing: Requests are not batched. For multiple independent predictions, process them sequentially, serve them from a container with several GPUs (refer to Serve Requests on Multiple GPUs), or use multiple NIM instances.
- Memory Management: Ensure adequate GPU memory for your target sequence lengths. Very long sequences (more than 1,800 residues) are memory-intensive, and actual requirements depend on workload characteristics (MSA depth, templates, and molecule composition). Refer to Table 1 for measured per-SKU results.
Reproduce Performance Benchmarks
Overview
This section provides scripts and instructions for reproducing the performance metrics reported above. The benchmarking process is as follows:
- Run inference with OpenFold3 NIM to generate predicted structures
- Use OpenStructure (OST) to compare predictions against reference structures
- Extract accuracy metrics like lDDT (local Distance Difference Test)
Prerequisites
Run the OpenFold3 NIM
Before running benchmarks, ensure that OpenFold3 NIM is deployed and running. The benchmarking scripts send inference requests to the NIM service.
Verify NIM is Running:
The default NIM URL is http://localhost:8000. If your NIM is running on a different host or port, specify it using the --nim-url parameter when running benchmarks. For detailed deployment instructions and configuration options, refer to the Getting Started guide.
Install the OpenStructure Docker Image
OpenStructure is a computational structural biology framework that provides tools for structure comparison and validation. You need the OpenStructure Docker image for running benchmarks:
Download Reference Structures
You need reference structures (ground truth) in CIF format for comparison. These are experimentally determined structures from the Protein Data Bank (PDB):
- CIF (Crystallographic Information File): A standard format for representing molecular structures, including atomic coordinates, experimental metadata, and structural annotations
- Obtaining reference structures: Download from RCSB PDB using the PDB IDs from the performance table (for example, 8eil, 7r6r, 1a3n)
Example:
Prepare Input JSON Files
What are Input JSON Files?
Input JSON files contain the sequence information needed for OpenFold3 NIM to make predictions. They are an intermediate format: benchmark_openfold3.py converts each file into a NIM API request. Each file specifies:
- Protein sequences (amino acid chains)
- Chain IDs
- Optional: DNA, RNA, ligands, MSAs, templates
Example Input JSON Structure
Create Input JSON Files
You can create input JSON files by extracting sequences from PDB structures. Save this script as generate_inputs.py:
Benchmarking Script
The following is a complete script to benchmark OpenFold3 NIM predictions. Save this as benchmark_openfold3.py:
Run a Single Benchmark
To run a benchmark for a single structure, follow these steps in order:
Each step must complete successfully before proceeding to the next. Verify that input and reference files exist (Step 4) before running the benchmark (Step 5).
Understand the lDDT Metric
lDDT (local Distance Difference Test) is a metric for assessing the quality of predicted protein structures:
- Score Range: 0.0 to 1.0 (or 0 to 100 when expressed as percentage)
- Interpretation:
- lDDT above 0.90: Very high accuracy, very high confidence
- lDDT 0.70-0.90: Good accuracy, reliable predictions
- lDDT 0.50-0.70: Moderate accuracy, some structural features correct
- lDDT below 0.50: Low accuracy, limited reliability
How lDDT Works:
- Measures local geometric agreement between predicted and reference structures
- Evaluates distances between atoms within local neighborhoods (typically 15 Å radius)
- Less sensitive to domain movements and mobile regions than global metrics like RMSD
- Focuses on local structural correctness rather than global superposition
Why lDDT for OpenFold3:
- AlphaFold3 and OpenFold3 models are trained to optimize lDDT during the training process
- Well-suited for evaluating multi-chain complexes and structures with mobile regions
- Provides per-residue metrics in addition to global metrics
- Standard metric used in CASP (Critical Assessment of protein Structure Prediction) competitions
Run Benchmarks for the Performance Table
To reproduce the performance metrics from the table above, follow these steps in order:
Complete Steps 1 and 2 before running Step 3. The benchmark workflow requires:
- Both Python scripts (
generate_inputs.pyandbenchmark_openfold3.py) saved as files - The bash script (
run_benchmarks.sh) saved as a file - All scripts must be in the same directory before execution
Running steps out of order results in “File Not Found” errors.
Step 1: Prepare the Python Scripts
Save the two Python scripts provided earlier in this document:
generate_inputs.py- Creates input JSON files from PDB (refer to Prepare Input JSON Files)benchmark_openfold3.py- Runs inference and compares structures (refer to Benchmarking Script)
Step 2: Create the Benchmark Workflow Script
Save the following as run_benchmarks.sh:
Step 3: Run the Complete Workflow
The run_benchmarks.sh script handles all steps automatically: generating input files, downloading reference structures, and running benchmarks for all test cases. Make sure the OpenFold3 NIM is running before executing the script.
Expected Output Format
The comparison results JSON file contains detailed metrics:
The primary metric of interest is lddt, which is a float value (0.0 to 1.0) representing the overall structural quality of the prediction. Higher values indicate better agreement with the reference structure.
Troubleshooting
General Performance Issues
- Out of memory errors: Reduce MSA depth, decrease sequence length, or upgrade to GPUs with more memory
- Slow performance: Ensure fast storage (NVMe SSD), sufficient CPU cores, and adequate system RAM
- Poor quality predictions: Check input sequence quality, increase MSA depth if available, or request more diffusion samples (
diffusion_samples)
Benchmarking Issues
The following are “File not found” errors.
- “Input file not found”: Generate input JSON files first using
generate_inputs.py - “Reference file not found”: Download CIF files from RCSB PDB
The following are structure comparison issues.
- OpenStructure comparison failures: Ensure both predicted and reference structures have compatible chain IDs and residue numbering
- Missing atoms in predictions: Use
--fault-tolerantflag to handle incomplete structures (already included in script) - lDDT score of 0.0: Check that sequences match between prediction and reference; may indicate alignment failure
The following are NIM connection issues.
- “Connection refused”: Ensure OpenFold3 NIM is running
For runtime settings that affect performance, such as multi-GPU serving and request size limits, refer to Configuration Alternatives.