Can you run RFantibody or BindCraft without a GPU cluster, and what do you get?

You can run these tools on one GPU, and plenty of people do. What changes between a demonstration and a campaign is not the software but the number of designs you can afford to throw away. What a single card gets you, and where the real cost sits.

Design around an antibody patent: a redesigned VHH binding the same epitope as the patented antibody
Aisle between computer server racks in a small data room

Yes. RFantibody, BindCraft and the models underneath them run on a single modern GPU, and a hosted service will run them for you without any local hardware at all. The code is open and the weights are public, though the licences differ and BindCraft installs PyRosetta, which requires a separate licence for commercial use. The installation problems people hit are ordinary dependency problems rather than a gate. What a single card does not give you is a campaign, and the distinction matters more than the hardware question: generating ten designs and generating ten thousand are the same command, but only one of them produces binders. The cost is in the designs you discard.

What RFantibody and BindCraft need to run

All of them are GPU workloads built on standard deep learning stacks, which means the requirements are familiar even if the biology is not.

A current generation card with a reasonable amount of memory will run them. Memory is usually the binding constraint rather than raw speed, because the limit shows up as the size of the complex you can handle in one pass rather than as a longer wait. Large targets and large complexes are what push against it.

The installation is the part that generates forum threads. These are research repositories, with pinned dependency versions, CUDA requirements and model weights downloaded separately. The published containers remove most of this, and running them inside the container rather than against a local environment avoids the majority of reported problems.

If you have no GPU, hosted services run these pipelines through a web interface, charged per job. For trying a tool on a target, this is the shortest route and there is no reason to build anything locally.

So the entry barrier is low, which is the premise most comparisons start and stop at.

How far a single GPU takes an RFantibody campaign

One card is enough for three kinds of work.

  • Understanding what the tool does to your target: run a small number of designs against your structure, look at where the model places the binder, and judge whether the predicted interface is plausible. The exercise is diagnostic rather than productive, and it is often the most informative thing a team can do in a week.
  • Method development: testing how the output changes with the epitope definition, the framework choice or the generation parameters. Small batches answer these questions perfectly well.
  • Teaching and evaluation: reproducing a published example, which the repositories are set up to support.

What a single card will not support is the attrition that a campaign is built on.

Why one design and one campaign are different problems

Design success behaves as a per-attempt probability rather than as a property of any individual run, and that single fact reorganises everything downstream of it.

The published numbers make the shape of it visible. An independent evaluation of BindCraft, run on peptide binders, generated 70 unique designs against the oncoprotein MDM2, synthesised 15, and found 7 that bound with nanomolar affinity. Against WDR5, 6 of 9 tested candidates bound. Against PD-1 and PD-L1, none of the tested peptides bound at all (Filius et al., ACS Chemical Biology 2025, 20:2991-2998, DOI, reference located through PubMed).

Read that as a funnel rather than as a score. Dozens of designs produce a handful worth making, which produce a few that work, and on some targets the final number is zero. The discarded designs were the mechanism rather than waste.

This is why campaign scale is the real variable. If your pipeline keeps a small percentage of what it generates, then the number of designs you can afford to generate sets the number of candidates you can afford to be strict about. Generate a hundred and you have to accept marginal candidates. Generate thousands and you can apply the structural filter, the developability filter and the specificity filter in series and still have a shortlist.

Working at small scale rarely leaves you with nothing. What it leaves you with is candidates that passed because the filter had to be relaxed to keep them.

Where the compute goes: filtering rather than generation

Generation is rarely the expensive part, and the accounting usually runs as follows:

  • Backbone generation is the step people picture, and it is cheap per design.
  • Sequence design on each backbone is cheaper still, often around a second per sequence.
  • Filtering is where the budget goes: each designed sequence has to be independently folded and docked to confirm that it adopts the intended structure and engages the intended site. That prediction runs on every candidate, several times over where you are sampling, and it is the step that scales badly.

The practical ratio is therefore counter-intuitive, since the generative model that attracts all the attention consumes far fewer hours than the verification that follows it. Verification is also where the quality of the campaign is decided, which is the subject of what each tool does.

The part no amount of GPU time solves

Three constraints sit outside the compute question, and they decide the outcome more than the hardware.

  • The target: a poorly chosen or undesignable site runs exactly as smoothly as a good one and returns ranked candidates either way. The PD-1 and PD-L1 results above are better explained by the target than by a shortage of compute, although a single study cannot settle that. Site assessment is covered in our note on choosing which site to target.
  • The filtering criteria: deciding which thousand of ten thousand designs deserve attention, and on which combination of structural confidence, predicted interface quality and developability descriptors, is a matter of judgement. It is also where two groups running identical software arrive at different results.
  • The experiment: at the end of the funnel somebody has to make the proteins and test them. Cell-free expression and an ELISA turn a shortlist into measured binders, and without that step what you hold is a ranked list. This is the argument set out in what a binding experiment proves.

A bigger cluster improves none of the three.

Three options, depending on what you are trying to settle

If you want to understand the method, install it or use a hosted service and run a small batch against a target you know well. Twenty designs on a familiar protein will teach you more than any amount of reading about the model.

If you want a binder for a programme, the question is less whether you can run the software than whether you can run a funnel, which means enough designs to allow strictness, a filtering stage you trust, and a laboratory able to express and test the shortlist. Teams that have all three should build it, and teams that have one or two generally find the gap sits in the laboratory rather than in the GPU.

That funnel is what Immunochem runs: six weeks from the antigen to candidate sequences, twelve weeks to binders validated in the laboratory, with the attrition reported rather than hidden. The models are the same ones you would install yourself.

Receive a feasibility study on your antigen - for free

Frequently asked questions

Can RFantibody run on a laptop?

Not usefully. A laptop GPU will struggle with memory on realistic complexes, and designs are not fast enough to reach meaningful numbers. For trying the tool, a hosted service is the better route.

How many RFantibody designs do you need for one binder?

There is no universal figure, and it depends on the target. The published evaluations give a sense of scale: dozens of designs reduced to a handful synthesised, of which some fraction binds, and on difficult targets none. Plan for a funnel rather than a hit.

Which is the hardest part to install?

Dependency and CUDA version mismatches, which is why the published container images exist. Running inside the container avoids most reported problems.

Is it cheaper to use a hosted service or to buy a GPU?

For occasional jobs, hosted. For sustained campaigns, owned hardware pays back, though usually not before the laboratory capacity becomes the real constraint. Most teams discover that the limiting factor is the ability to express and test candidates rather than to generate them.

If the tools are free, what is a service provider for?

Target assessment, filtering criteria, campaign scale and the validation experiment. The model weights are public and we do not treat them as proprietary. The decisions around them and the laboratory work are the service.

Have a target and want to know whether a campaign against it is worth running?

Receive a feasibility study on your antigen - for free