RFD4-Proteina

IPD NVIDIA

Proto is not affiliated with Institute for Protein Design and NVIDIA. This toolkit is open source and builds on the implementations produced by these organizations. Product names, logos, and trademarks are the property of their respective owners.

GitHub GitHub HuggingFace HuggingFace Website Website Preprint Preprint Cite Cite Tool Source Tool Source Open as Notebook Open as Notebook Run Locally Run Locally

RosettaCommons/RFD4-Proteina

View repo

RFD4-Proteina nvidia

@article{corley2026rfd4proteina,
  title={Biomolecular design through latent reasoning with {RFD4-Proteina}},
  author={Corley, Nathaniel and Didi, Kieran and Kazman, Maxwell W. and Brent, Rafael I. and Bauer, Magnus S. and Biswas, Riti and Bonzanini, Julia E. and Chazin-Gray, Adam M. and Chen, Jie and Favor, Andrew and Gantz, Maximilian and Jones, Henry A. and Kim, Paul and Lunn-Halbert, Margaret C. and McNamara-Bordewick, Nora K. and Salike, Saman and See, D{\'e}Jena{\'e} L. and Sharma, Shajesh and Sun, Eric and Venkatesh, Preetham and Woodbury, Seth M. and Wu, Kejia and Zhang, Yuyang and Allen, Joel D. and Butcher, Jasper and Chang, Lemuel and Cho, Yehlin and Courbet, Alexis and Coventry, Brian and Dallago, Christian and Delfosse, Elliot S. and Eisenach, Helen E. and Garcia Sanchez, Mariana and Geffner, Tomas and Goreshnik, Inna and Greisen, Per and Kim, David E. and Kim, Donghyo and King, Brianne R. and Krishna, Rohith and Li, Yanjing and Li, Zi Ming and Muraishi, Aiko and Muratspahi{\'c}, Edin and Nagl, Oliver and Rangel, Griffin H. and Ruder, Antonia and Shin, Hojeong and Xu, Zefei and Yang, Yuwei and Crispin, Max and King, Neil P. and DiMaio, Frank and Bhardwaj, Gaurav and Bronstein, Michael and Kreis, Karsten and Hilvert, Donald and Green, Anthony P. and Vahdat, Arash and Baker, David},
  year={2026},
  note={Preprint},
  url={https://rfd4-proteina.org/assets/paper/RFD4-Proteina.pdf}
}

evo-design/proto-tools

View source

Run locally with proto-tools

pip install git+https://github.com/evo-design/proto-tools.git

Toolkit contributorsbviggiano

​

Background

​

Learning Resources

• RFD4-Proteina documentation — Official documentation covering model inputs, conditioning, generation settings, and example workflows.
• RFD4-Proteina model card — Model weights, checkpoint information, training details, and licensing.
• RFD4-Proteina on NVIDIA build — Hosted inference endpoint for running the model without managing a local GPU environment.

​

Tools

​

Toolkit Notes

• Symmetry support. RFD4-Proteina does not currently support symmetry-conditioned generation. For the design of symmetric protein assemblies, use rfdiffusion3-design.
• Hardware requirements. This toolkit requires a CUDA-enabled GPU. The upstream rfd4-generate implementation initializes its Lightning trainer with GPU acceleration, so selecting device="cpu" does not provide a CPU inference path. The environment setup also requires Linux x86_64, a CUDA-capable system, and an NVIDIA driver with a major version of at least 525.
• Model weights and checkpoints. The default checkpoint is available from nvidia/RFD4-Proteina without an access request. Model files are downloaded automatically when needed. The denoising model and its corresponding autoencoder must be loaded as a compatible pair. model_revision can be used to select a specific Hugging Face revision for reproducibility. If adapter_path is provided, the adapter must be compatible with the selected base checkpoint and autoencoder.
• Model persistence. Generation runs in-process rather than through the rfd4-generate command-line entry point, so a persistent worker loads the checkpoint once and reuses it. The first call in a worker pays the load; later calls do not. In local testing on an H200, three sequential designs took 37s, 13s, and 13s. Batch work therefore benefits from running inside ToolInstance.persist_tool("rfd4-design"). Changing model_checkpoint, model_revision, adapter_path, or use_torch_compile restarts the worker, since each of those is fixed at load time. Each worker is also pinned to its assigned GPU and is restarted rather than moved if the device changes.
• GPU memory. Memory requirements depend on input size, sequence length, and batch_size. Test the longest intended design at batch_size=1 before increasing parallelism. If a run exceeds available GPU memory, reducing the batch size is generally the first adjustment to make.
• Model compilation. use_torch_compile is disabled by default. When enabled, the implementation compiles the model for multiple sequence-length buckets, introducing substantial initial compilation overhead. Compilation may be worthwhile for repeated or large-scale inference, but offers less benefit for short runs.
• Evaluating designs. RFD4 outputs do not include a calibrated confidence score indicating whether a design will fold or function as intended. Independent structure prediction, for example with boltz2-prediction or esmfold-prediction, can help assess consistency between the designed sequence and generated structure. Each RFD4Design includes a complex object suitable for downstream analysis. Use chain_sequence_map() or chain_sequences to access sequences across molecular entities. extract_protein_chains() returns only protein chains and therefore omits DNA and RNA chains.
• Output organization. Results are grouped by input specification. designed_structures contains one RFD4Designs collection per specification, in the original input order. Each collection contains up to num_replicates designs. If a specification produces no designs, its collection remains empty rather than changing the position of subsequent results.
• Reproducibility. Generation is stochastic, and seed can be used to control random sampling. Repeated inverse-folding runs with the same seed produced identical sequences and structures in local tests. Exact reproducibility is not guaranteed across different hardware or software environments. deterministic_sampling=True changes both modalities to ODE integration, avoiding additional noise injection during the trajectory, but does not guarantee bitwise reproducibility in every environment. For most design applications, evaluating several independent candidates is preferable to relying on a single output.
• Features not exposed by this toolkit. The current implementation does not expose upstream reward-guided beam search, rfd4-evaluate, antibody or VHH-specific workflows, or the Diffusers interface. Reward-guided search requires additional configuration and, for some scoring functions, external structure-prediction runtimes. The toolkit also does not expose a separate folding mode. In the upstream implementation, sequence-conditioned structure generation can be expressed through sequence conditioning, which is available through known_sequence.
• Metrics and output filtering. The implementation disables tagged upstream metrics through metrics_tags=[], preventing the configured AlphaFold2, AlphaFold3, and OpenFold3 refolding oracles from running. Untagged metrics, including the upstream unknown_residue_filter, may still be evaluated and recorded in output metadata. The implementation also sets delete_failing_pre_oracle=False so designs are not silently removed by that preliminary filter. These metadata should not be interpreted as independent structural validation.
• Third-party licensing. The upstream RFD4-Proteina distribution includes optional integrations and container environments for external structure-prediction systems. These components may be subject to licenses and usage conditions that differ from those of RFD4-Proteina itself, including restrictions on particular model weights. The Proto toolkit described here does not invoke these external refolding oracles. Users who enable them independently should review the applicable licenses and distribution terms.

​

Infrastructure Guides