Build1 publisher2 min readPublished
NVIDIA's BioIR starts its inference clock after the alignment you had to build yourself
NVIDIA backs its structure-prediction runtime with a production run across 4,777 proteomes rather than a benchmark chart, and the distance between that number and your cluster is mostly work BioIR never touches.
The Engineer · Build desk
What happened
- NVIDIA's BioNeMo Inference Runtime speeds supported structure-prediction models on its GPUs using optimized kernels and, where applicable, CUDA Graphs, while keeping the caller inside a familiar PyTorch workflow.
- It is offered two ways: an end-to-end processor that parses, tokenizes, generates features, runs GPU inference and writes PDB or mmCIF, or direct construction and reuse of the supported model as a torch module.
- Its production evidence is the recent AlphaFold Database expansion, which covered 4,777 proteomes and about 31 million candidate complexes, of which 1.81 million were released as high-confidence predictions.
- Every protein chain must arrive with its own A3M alignment, with paired or unpaired alignments accepted when an input carries multiple non-identical protein chains.
- The metric the runtime reports, model_inference_time, is a CUDA-synchronized measurement of the folding model's forward pass that excludes parsing, tokenization, feature generation, postprocessing and writing.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint With no HHsearch or HMMsearch in the runtime, the ceiling on a proteome-scale run is set by alignment infrastructure BioIR neither schedules nor measures, so buying GPUs does not move it.
- cost Adoption cost lands on data staging rather than a build chain, since the wheel's precompiled CUBINs remove the CUDA toolchain from runtime while a staged checkpoint and chemical metadata stay mandatory.
- decision Anyone whose worklist includes ligand-affinity prediction keeps a second code path, because the end-to-end processor stops at ligand structure.
- precedent NVIDIA's own instruction to build Ray test rows from a real worklist, and never to repeat a single row as scaling evidence, is the bar any throughput number from this runtime should now be held to.
Upstream of the five stages the end-to-end processor runs, every protein chain needs an A3M alignment that you produced somewhere else [8]. BioIR runs no HHsearch and no HMMsearch, and templates arrive only if you hand them over [9]. That is the product boundary. Finding the homologs is your cluster's job.
The forward-pass timer is unusually candid about its own scope, which is more than most throughput metrics manage, but it does mean a serial run reports a model number rather than a pipeline number [7]. The serial backend exists for that: one input through every stage in order, setup confirmed, then you switch the executor to Ray [15].
Sampling settings matter more than the framing suggests. The tutorial's example asks for 3 recycling steps, 50 sampling steps and a single diffusion sample [16]. Those knobs set the forward-pass cost, so a structures-per-hour figure is a statement about the budget somebody chose, and a rate quoted without them does not compare to yours.
The Ray path is replication rather than sharding: a complete model replica on each GPU in one node, fed from a set of independent records [3]. Because nothing is split across devices, per-GPU memory bounds the replica, not aggregate node memory [4]. The record count also has to exceed the replica count, or you are timing startup [13].
The AFDB figures are worth dividing. About 31 million candidate complexes across 4,777 proteomes is roughly 6,500 candidates per proteome [1]. The 1.81 million released as high-confidence is 5.8 percent of the candidates [2], or about 17 candidates generated for every structure that shipped [3]. Size a worklist on released output and the GPU hours you have to buy are the 17, not the one.
What the post does not publish is a rate for that run, or how the alignments for 31 million inputs were produced [19]. It shows you how to track structures per hour on your own hardware instead [18]. That is the honest version, and it is also why the 31 million does not transfer on its own. It transfers if alignments already exist for every chain, if the records are genuinely independent, and if the GPUs sit in a single node.
One detail tells you who the pipeline was built for: the scores come back as a JSON string you have to decode yourself [17].
Read as engineering, BioIR is a kernel library and a replica scheduler with a candid timer wrapped around the model [2]. The part of the AFDB result you can reuse today is the measurement recipe that came with it [18].
What to watch
- A published structures-per-hour figure for the AFDB run with the alignment stage inside the measured window would make the throughput claim checkable.
- A documented Ray layout spanning more than one node's GPUs, since the current replica scheme is described only within a single node.
- Documented driver and CUDA compatibility bounds for the precompiled CUBINs shipped in the wheel.