Local protein structure prediction with NVIDIA BioNeMo does not begin with the largest GPU you can afford. It begins with the workflow, the sequence databases you intend to keep, the number of researchers sharing the service and the amount of time you can tolerate between submission and result.
For NVIDIA’s current Claude Science example, a practical starting point is a qualified NVIDIA L40S or H100 system with fast local NVMe storage. NVIDIA’s tutorial estimates roughly 700 GB for the worked setup: about 490 GB for a UniRef30-only multiple-sequence-alignment database, plus 30 to 40 GB for the Boltz-2 and OpenFold3 containers, with the remainder available for Docker layers, results and working data. The full MSA dataset is much larger, at about 1.4 TB before local operating headroom.
That can fit a well-specified workstation. It does not mean every research group should buy one. A shared lab may get better control and utilisation from a rack server, while an occasional user may be better served by hosted GPU capacity.
This guide explains what the BioNeMo example actually runs, how to budget storage without false precision and when to choose a workstation, a server or a hosted system.
What NVIDIA’s example does
NVIDIA’s August 2026 technical guide connects Claude Science to the BioNeMo Agent Toolkit. The agent sends work to NVIDIA NIM microservices rather than asking a language model to calculate a protein structure itself.
The example has two main stages:
1. MSA Search NIM finds related protein sequences and builds a multiple sequence alignment. 2. OpenFold3 and Boltz-2 NIMs use the sequence and alignment information to produce structure predictions.
The distinction is important. The conversational interface coordinates tools, but the scientific computation still happens in specialised services with their own models, containers, data and GPU requirements.
NVIDIA presents both local and remote deployment paths. The NIM endpoints can run in Docker on a local GPU machine, or the researcher can connect to a remote GPU server through SSH, an HPC environment or cloud infrastructure. The interface does not settle where the compute should live.
MSA data is not an optional afterthought in the worked workflow. NVIDIA describes it as load-bearing for the prediction process. A machine with enough GPU memory but slow, cramped or poorly managed storage can therefore be the wrong purchase.
The short buying answer
| Working pattern | Sensible first platform | Reason | |---|---|---| | One researcher, occasional local runs | Qualified tower workstation with an L40S or H100-class GPU | Direct access, low administrative overhead and local data control | | Several researchers sharing models and databases | Rackmount PCIe GPU server | Central scheduling, shared storage, access control and easier service operation | | Continuous high-volume service or several GPU-bound models | Multi-GPU PCIe or HGX server, subject to measured scaling | More device memory, throughput and service isolation | | Short project, irregular demand or no suitable server room | Hosted owned system or time-limited cloud capacity | Avoids building facilities for uncertain duty cycle |
These are deployment categories, not performance claims. NVIDIA identifies L40S and H100 as suitable hardware for its example, but the published tutorial does not give a universal time-to-result for every protein, MSA depth or model setting. Ask vendors for a trial using your representative inputs.
Storage arithmetic before GPU selection
Start with the data you intend to retain. For the UniRef30-only example, a simple planning worksheet is:
| Allocation | Planning figure | Basis | |---|---:|---| | MSA database | about 490 GB | NVIDIA tutorial figure | | Boltz-2 and OpenFold3 containers | about 30 to 40 GB total | NVIDIA tutorial figure | | Container layers, indexes and updates | project-specific | measure after pulling exact image versions | | Input, output and temporary files | project-specific | measure representative runs | | Free operating margin | policy choice | needed for updates, recovery and predictable write behaviour |
The first two lines total about 520 to 530 GB. That does not make a 600 GB volume sensible. Filesystems, image updates, duplicate layers, logs, downloaded artefacts and active jobs all need room. A 1 TB usable local NVMe allocation is a defensible floor for evaluating the UniRef30-only path, provided the operator monitors growth. A 2 TB or larger usable allocation is easier to manage when several users retain results or multiple data versions.
Those figures are GPUMachines planning guidance derived from NVIDIA’s published inputs. They are not NVIDIA minimum requirements. Your measured working set takes priority.
If you plan to keep the full dataset that NVIDIA lists at about 1.4 TB, move beyond a single 2 TB consumer drive. Allow room for extraction, updates, snapshots and project output. Enterprise NVMe with power-loss protection, endurance appropriate to the write pattern and monitored health is a better basis for a shared service.
Database update policy also changes capacity. Keeping both the current and previous version for rollback can briefly double the database allocation. Downloading an archive before unpacking it may require the compressed and expanded copies at the same time. Put those temporary states in the worksheet.
Does the MSA database need to sit on local NVMe?
Not always, but local NVMe is the simplest predictable starting point for one machine. The database and indexes can be read without competing with other users on a general-purpose network share.
A shared lab may prefer central storage so every GPU worker sees the same approved database. In that case, test the complete path:
- cold start after caches have been cleared;
- repeated runs with a warm cache;
- several researchers starting jobs at once;
- database update while old jobs are still active;
- worker restart after a network interruption;
- restore from backup or snapshot.
Measure read throughput, metadata latency and queue time separately. A large sequential storage benchmark can look healthy while many small file operations delay job start.
For one server, local enterprise NVMe plus a backed-up source copy is often straightforward. For several servers, a scale-out or parallel storage design may make sense, but only after the access pattern is known. Our PCIe GPU server range can be configured with local NVMe and high-speed network interfaces for either approach.
Workstation: best for direct ownership of the workflow
A tower GPU workstation suits a researcher or small team that wants the model services and data close to the desk. It avoids a separate rack, remote scheduler and data-centre access process.
The GPU must be physically and electrically supported. L40S and H100 products are data-centre accelerators with cooling and platform requirements that differ from a typical desktop graphics card. A qualified workstation design needs enough slot space, power delivery, airflow and firmware support for the exact accelerator. “It has a PCIe slot” is not a qualification.
Check these items before ordering:
- exact GPU model, memory capacity and cooling format;
- chassis support for the card’s power and thermal load;
- local NVMe capacity after redundancy and filesystem overhead;
- CPU and system memory headroom for container operation, data handling and concurrent tasks;
- 10 GbE or faster networking if large databases or results move to shared storage;
- Linux distribution, NVIDIA driver and Docker support for the selected NIM releases;
- acoustic and heat output for the intended room;
- backup location for source data, configuration and results.
Do not choose system RAM by copying GPU memory. The CPU side may run data preparation, container services, indexing and the agent interface, but the amount depends on the exact workflow. Monitor a representative run and leave room for concurrent work and operating-system cache.
A workstation is less attractive when several people need fair scheduling, audited access or guaranteed availability. It can become a server under someone’s desk without the controls, cooling or support practices of one.
Server: best when the lab shares the service
A rackmount server makes the BioNeMo NIM endpoints a managed service. Researchers submit jobs or call an internal API; the database, container versions and access rules are maintained once.
This arrangement supports:
- central authentication and network policy;
- a scheduler or job queue;
- consistent container and model versions;
- shared database updates;
- monitoring, backup and recovery;
- more than one GPU or isolated services where the workload justifies them.
It also creates an operations job. Someone must own patching, failed jobs, storage growth, user quotas and scientific software changes. A server is not automatically cheaper than several workstations when administration and facilities are counted.
Single- or dual-GPU PCIe systems are often enough for an initial shared service. Move to denser PCIe systems or NVIDIA HGX servers only when model placement, concurrency or multi-GPU scaling data supports it. The BioNeMo tutorial’s use of one suitable GPU does not establish that an eight-GPU HGX system will make one workflow eight times faster.
For multiple users, decide whether a GPU is assigned per service, shared through a serving layer or scheduled per job. Then test memory isolation, cancellation and recovery. One failed container should not strand every accelerator on the host.
Hosted capacity: best when facilities or duty cycle do not fit
Cloud or hosted infrastructure is useful for evaluation, seasonal projects and teams that cannot operate a data-centre GPU locally. It can also shorten the path to a qualified H100 system.
The financial comparison needs more than an hourly GPU price. Include:
- provisioned hours, including idle but reserved time;
- storage for the MSA database, images and results;
- database download and update time;
- data transfer and egress;
- engineering time for environment rebuilds;
- required availability and reservation terms;
- security review for research data;
- the cost of local power, cooling, rack space and support in the ownership case.
If the database takes hours to stage for each short rental, cheap compute can still produce an expensive workflow. Persistent storage or a continuously available hosted machine may be better.
GPUMachines Buy & Host places customer-owned GPU hardware in managed facilities. It can suit a team that wants asset ownership and stable capacity without operating the room. Public cloud remains useful for short experiments and services that genuinely benefit from rapid scale-down. Compare both using expected annual jobs and measured runtime.
L40S or H100?
NVIDIA names both L40S and H100 in the tutorial’s workstation or cloud requirements. That gives buyers a qualified starting set, not a universal ranking.
L40S is a 48 GB data-centre GPU aimed at AI and graphics workloads. It can be a sensible evaluation or single-user option when the selected NIMs fit and the measured turnaround is acceptable.
H100 is built for data-centre AI and HPC work. It offers HBM memory and hardware intended for demanding training and inference workloads. It may suit a shared service, larger workload or shorter turnaround target, but price, power, platform and availability differ materially from L40S.
Ask for the following evidence on both candidates:
- model and NIM version;
- input sequence lengths and MSA settings;
- cold and warm job time;
- peak GPU memory;
- GPU utilisation over the run;
- CPU, RAM, local-disk and network measurements;
- concurrent-job behaviour;
- error and recovery behaviour.
An H100 that waits for storage or an MSA service is not solving the bottleneck. An L40S that meets the research turnaround may be the better purchase. If neither meets concurrency or memory requirements, a multi-GPU design becomes a testable next step rather than a guess.
Networking and access control
The NVIDIA example can connect a local agent to remote NIM endpoints. Treat those endpoints as internal scientific services.
Keep model and data services on a private network. Authenticate users at the API or access gateway. Limit SSH access, record image versions and separate administrative privileges from routine job submission. Research inputs may have contractual, privacy or export-control conditions; the deployment owner must establish the applicable policy.
For a workstation, 10 GbE can materially reduce the friction of moving hundreds of gigabytes compared with 1 GbE, but a faster port only helps when the storage source and network path can sustain it. Shared servers may justify 25, 100 or 200 GbE where measurements show parallel data staging or central storage needs it.
Use checksums or version manifests for downloaded databases and container images. A result should be traceable to the data snapshot, model version, container digest, parameters and input. Without that record, reproducing a prediction after an update becomes difficult.
Prediction is not biological proof
NVIDIA’s article is clear that the generated structures are hypotheses. Confidence metrics, agreement between OpenFold3 and Boltz-2, and a plausible visualisation do not establish biological truth, therapeutic effect or safety.
The article’s example discusses comparison across two prediction services and notes the importance of the MSA. That is useful workflow discipline. It is not a substitute for domain review, suitable controls, experimental validation or the regulatory process that may apply to downstream work.
GPUMachines can advise on compute, storage, networking and deployment. It cannot validate a biological conclusion. Research groups should assign scientific ownership to qualified specialists and retain the inputs and environment needed to reproduce each run.
A sensible evaluation before purchase
Use a short paid trial, loan system or hosted instance with your own representative jobs. Include easy and difficult cases, rather than a single demonstration input.
Record:
1. database and container versions; 2. input characteristics and MSA settings; 3. end-to-end time, including MSA search; 4. GPU time and peak memory; 5. storage and network behaviour; 6. failure, cancellation and restart behaviour; 7. result size and retention requirement; 8. concurrent performance for the expected number of researchers.
Then make the platform decision.
Choose a workstation when direct access matters, one or two researchers can manage the software and the measured workload fits one qualified GPU.
Choose a server when the database and service should be shared, users need scheduling or audit controls, or several jobs must run without depending on one person’s desktop.
Choose hosted capacity when demand is uncertain, the facility is not ready or a quick evaluation is worth more than immediate ownership. If usage becomes steady, compare a purchase using the same measured jobs.
GPUMachines can turn that evidence into a tower, PCIe server or hosted configuration. Bring the preferred NIMs, expected users, database plan, turnaround target and annual job volume. Those details decide the machine more reliably than “protein AI” as a category.