How many minutes does AutoDock Vina take per ligand?

There is no defensible universal number. Runtime changes with ligand flexibility and size, receptor flexibility, box size, exhaustiveness, scoring and output settings, engine version, CPU allocation, concurrent jobs, hardware, and workflow overhead. Benchmark representative local cases [1,2,4,6].

Does doubling Vina exhaustiveness double runtime?

Exhaustiveness increases search effort and is often described as roughly proportional to time, but exact wall-time scaling is not guaranteed across ligands, versions, CPU allocation, and systems. Measure the intended values and check pose behavior rather than assuming an exact multiplier [1,3,4].

Should I give every Vina job all CPU cores?

Not automatically. More cores may reduce one job's latency, while several smaller concurrent jobs may improve total batch throughput. Compare both at the same total-resource budget and watch for limited parallel work, oversubscription, memory or storage contention, and thermal throttling [1].

How do I estimate the time for a Vina ligand library?

Measure usable ligands per elapsed hour on a representative sample using the planned environment and concurrency. Divide the remaining comparable ligand count by that throughput, then add allowances based on observed failures, retries, review, exports, variability, and the slow tail.

Is GPU Vina always faster than CPU Vina?

No universal claim transfers across implementations and workloads. Compare the exact GPU method, hardware, algorithmic settings, scientific outputs, batch scale, and end-to-end timing with the CPU baseline. Published Vina-GPU speedups belong to the tested systems [5].

Can two MolNexus trial runs benchmark a full library?

No. They can reveal local workflow fit and bracket two representative single-ligand observations. They cannot estimate the workload distribution, concurrency, sustained performance, failure rate, or full-library throughput without a larger controlled benchmark.

Structural Bioinformatics

How Long Does AutoDock Vina Take? A Benchmark-First Guide to CPU Cores, Exhaustiveness, and Batch Size

Estimate Vina runtime from a representative local benchmark, then plan CPU allocation, exhaustiveness, concurrency, and batch throughput without relying on a universal minutes-per-ligand claim.

By BioChemIntelli

Published September 11, 2026

Answers such as “Vina takes five minutes” omit the variables that determine whether the estimate is useful. The same named tool can run a small rigid ligand in a focused box, a flexible molecule in a large site, multiple ligands sequentially, or many jobs concurrently. Startup, preparation, failures, result parsing, and storage may also matter more to operational throughput than the engine time printed for one successful run.

A benchmark-first estimate does not need a large study. It needs a representative sample, a frozen configuration, repeated measurement, and a projection formula whose assumptions are visible. The result belongs to that workload and machine, not to AutoDock Vina in general.

Define which time you are estimating

Runtime metrics answer different questions

Metric	Definition	Use	Common error
Engine wall time	Elapsed time from Vina process start to exit.	Compare engine configurations on controlled inputs.	Calling it total workflow time.
End-to-end ligand time	Preparation, queuing, docking, parsing, validation, and export for one ligand.	Plan a traceable operational workflow.	Excluding failed or manually repaired ligands.
Latency	Elapsed time until one requested result is available.	Interactive or single-case use.	Using it as batch throughput.
Throughput	Successfully completed, quality-controlled ligands per elapsed hour.	Estimate library completion.	Counting launched jobs or poses instead of usable ligands.
Compute consumption	CPU-core-hours, GPU-hours, memory, and storage used.	Compare resource cost and scheduling.	Ignoring that faster wall time can consume more total resources.

Use a monotonic timer around the process or workflow and log both start and finish. Record exit status and output validity. Throughput should count only ligands that reached the predeclared usable-output state. If 100 jobs launch and 15 fail preparation or execution, the denominator for planning cannot pretend all 100 succeeded.

Report the median and a spread such as the interquartile range or a high percentile, not only the fastest example. Batch completion is often governed by the slow tail, resource contention, and retry policy.

Record the variables that can change Vina runtime

Runtime-driver inventory

Driver	Record	Why it matters
Ligand complexity	Heavy atoms, rotatable bonds, macrocycle treatment, and prepared states.	Vina's search effort depends partly on ligand size and flexibility [1].
Receptor model	Rigid receptor or explicitly flexible side chains, atom count, and special components.	Additional degrees of freedom can enlarge the search problem.
Search space	Center and each box dimension.	A larger box is harder to search and may require more exhaustiveness [1,6].
Search settings	Exhaustiveness, seed, number of modes, energy range, scoring function, and version.	They change work, stochastic variation, and output.
CPU allocation	Processor model, logical/physical cores, Vina CPU setting, affinity policy, and concurrent jobs.	One job using more threads can compete with throughput from multiple jobs.
System conditions	Operating system, power mode, thermal behavior, memory pressure, virtualization, storage, and other workloads.	Nominally identical core counts can produce different elapsed times.
Workflow overhead	Import, preparation, conversion, startup, parsing, validation, export, and retry time.	Engine-only speed can misrepresent total completion time.

Vina's official FAQ explains that the number of search runs is controlled by exhaustiveness and that independent runs can be parallelized when resources permit [1]. It also notes that the internal number of sequential steps is influenced by ligand size and flexibility and by flexible side chains. This means two ligands with the same file format can have materially different runtimes.

Do not describe exhaustiveness as a fixed accuracy percentage. It controls search effort. More effort may make sampling more reproducible or recover a pose missed at lower effort, but the gain and cost must be measured for the target and ligand range.

Run a small benchmark matrix before the full batch

Minimum benchmark design

Dimension	Suggested design	Purpose
Representative ligands	Select at least a low-, median-, and high-complexity case from the actual prepared collection; add known problematic chemistry.	Capture the workload distribution instead of one convenient molecule.
Search effort	Compare the intended exhaustiveness with one lower and one higher justified value, such as 8, 16, and 32.	Observe the local quality-cost curve; these values are test points, not universal recommendations.
CPU strategy	Compare several cores on one job with multiple concurrent smaller jobs, without oversubscribing the machine.	Distinguish single-ligand latency from batch throughput.
Replicates	Repeat each key condition with recorded seeds.	Separate typical runtime and pose behavior from stochastic variation.
Outputs	Capture wall time, CPU allocation, success/failure, scores, pose-family consistency, and usable export.	Prevent speed from being optimized at the cost of result usability.
Environment	Freeze engine version, receptor, preparation policy, box, scoring, hardware, OS, power state, and background-load rule.	Make comparisons interpretable and repeatable.

Randomize or alternate benchmark order so that warming, thermal throttling, and background activity do not always favor the same condition. Run a warm-up that is excluded by rule if the first invocation has one-time overhead. Do not remove slow or failed runs after seeing them; classify them and report results both with and without justified infrastructure failures.

Check output quality while benchmarking. The fastest condition is not useful if repeated seeds disagree on the relevant pose family or if the higher-effort condition materially changes a predeclared validation endpoint.

Estimate completion from measured throughput

Projection worksheet

Quantity	Calculation	Boundary
Observed usable throughput	Successfully completed and accepted ligands ÷ elapsed benchmark hours.	Valid only for the benchmarked environment and workload mix.
Base batch time	Remaining ligands ÷ observed usable throughput.	Assumes comparable complexity and scheduling.
Retry allowance	Add time from the measured failure/retry rate and policy.	Do not assume every failure is recoverable.
Review/export allowance	Add measured downstream time per accepted ligand or batch.	Relevant when humans or conversions gate completion.
Planning interval	Report a central estimate plus a conservative bound from observed variability.	Not a contractual completion promise.

Tune CPU allocation for throughput, not folklore

CPU scheduling experiments

Strategy	Measure	Watch for
More cores for one ligand	Latency and pose behavior at 1, 2, 4, or another justified core count.	Diminishing wall-time returns, limited exhaustiveness parallelism, and thermal throttling.
Several jobs concurrently	Total usable ligands/hour at fixed machine capacity.	CPU oversubscription, memory pressure, storage contention, and harder failure recovery.
Hybrid schedule	Throughput across the real ligand-complexity distribution.	Slow flexible ligands creating a long tail after short jobs finish.
Reserved interactive capacity	Throughput while preserving responsiveness for review or other work.	A benchmark that monopolizes resources unavailable in normal operation.

The fastest single ligand and the fastest complete library may use different allocations. If one Vina process cannot efficiently consume every core at the chosen exhaustiveness, several independent jobs may improve throughput. If too many processes compete, each can slow down and make failures less predictable. Measure the machine at a fixed total-resource budget.

Agarwal and Smith varied box size and exhaustiveness for a pose-accuracy dataset and found a dataset-specific speed–accuracy tradeoff, with limited median RMSD improvement beyond some search effort in that study [4]. Use that evidence to justify testing a curve—not to declare exhaustiveness 8, 25, or any other value optimal for every target.

Compare GPU claims only within the tested implementation

CPU-versus-GPU evidence checklist

Question	Required record
Same algorithm and settings?	Implementation name, commit or release, scoring, search semantics, precision, modes, and stopping behavior.
Same scientific endpoint?	Pose, score, repeatability, and acceptance metrics—not runtime alone.
Comparable hardware accounting?	Exact CPU and GPU models, host resources, power or cost basis, and concurrent workload.
End-to-end or kernel timing?	Data transfer, preparation, startup, execution, output, and failures included or excluded explicitly.
Representative scale?	Ligand count and complexity, receptor, box, and batch size matching the planned job.

Vina-GPU research demonstrates that specific GPU implementations can accelerate Vina-derived workloads on tested systems [5]. A published speedup is a property of that method, hardware, settings, and benchmark—not a multiplier that can be applied to stock Vina or to an unrelated GUI. Revalidate result behavior as well as speed before changing implementations.

For a traceable library workflow, use the batch-docking and traceability guide. For search-space and exhaustiveness decisions, use the grid-box and search-effort protocol before timing the frozen setup.

What MolNexus can reveal in two trial runs

MolNexus 0.1.1 exposes CPU and Vina run settings inside a local Windows 10/11 64-bit workflow using AutoDock Vina 1.2.7, and retains completed work in local history with result and export views. A two-run trial can test a low- and high-complexity representative ligand, confirm that settings and outputs remain traceable, and produce two local observations.

Two runs cannot estimate a full library distribution, concurrency scaling, sustained thermal behavior, failure rate, or product-wide throughput. BioChemIntelli does not currently publish a MolNexus minutes-per-ligand or screening-throughput benchmark. The paid offer is US$499 once for one Windows PC at a time; no GPU, cloud, cluster, Linux, or institutional deployment is advertised.

References

Center for Computational Structural Biology. Frequently Asked Questions AutoDock Vina documentation Official guidance on search runs, parallelism, ligand complexity, box size, and exhaustiveness.
Trott O, Olson AJ. AutoDock Vina: improving the speed and accuracy of docking with a new scoring function, efficient optimization, and multithreading Journal of Computational Chemistry (2010) DOI: 10.1002/jcc.21334 Original AutoDock Vina method and benchmark paper.
Eberhardt J, Santos-Martins D, Tillack AF, Forli S. AutoDock Vina 1.2.0: New Docking Methods, Expanded Force Field, and Python Bindings Journal of Chemical Information and Modeling (2021) DOI: 10.1021/acs.jcim.1c00203 Original Vina 1.2 method and feature paper.
Agarwal R, Smith JC. Speed vs Accuracy: Effect on Ligand Pose Accuracy of Varying Box Size and Exhaustiveness in AutoDock Vina Molecular Informatics (2023) DOI: 10.1002/minf.202200188 Original dataset-specific study of box size, exhaustiveness, pose accuracy, and compute cost.
Tang S, Chen R, Lin M, et al.. Accelerating AutoDock Vina with GPUs Molecules (2022) DOI: 10.3390/molecules27093041 Original Vina-GPU implementation and hardware benchmark; not a stock-Vina speed promise.
Center for Computational Structural Biology. Basic docking AutoDock Vina documentation Official current setup, configuration, execution, and output example.