Note: This post is pure google bait designed to help others who run into the same problem. We hope it helps!
A new GPU generation showed up on a client’s mixed-GPU queue with a cuda_cores value that isn’t in any published Schrödinger table. Since this cluster had only seen V100 GPUs prior there are configuration and user-behavior changes that had to occur.
Adding new GPUs to an old production HPC Cluster
Recently, for a client, we added NVIDIA RTX PRO 5000 Blackwell nodes to a Schrödinger GPU queue that had only ever seen Tesla V100s. This cluster had been running very stably with a rarely changing config for quite some time. But then a fantastic new multi-GPU compute node phenotype showed up.
The cuda_cores value Schrödinger needs for license accounting on this card is 14080 — and it is not yet in the published Schrödinger 2026-3 tables.
Those tables list the RTX PRO 4000 SFF Blackwell (8960) and the RTX PRO 6000 Blackwell (24064), but the 5000 sits between them and does not appear anywhere. The authoritative source is the on-node utility $SCHRODINGER/utilities/query_gpgpu -a, which reports 14080 “Discounted Cores” for the Blackwell Pro 5000.
At the current token formula that is 32 tokens / 2.0 licenses per GPU — exactly 2× a V100.
If you drop a new GPU generation into an existing Schrödinger queue and reuse the old cuda_cores value, you will silently mis-count licenses. Always measure. And if the queue now spans two GPU generations, split it into one typed host entry per generation.
The new Blackwell GPU
More Detail:
Standard compchem HPC cluster setup: a client GPU queue (gpu-q) that had run Tesla V100 work for years got a new tranche of nodes carrying NVIDIA RTX PRO 5000 Blackwell cards.
Schrödinger’s licensing for GPU jobs keys off a per-host-entry keyword called cuda_cores. When queue-based license checking is enabled, the Job Server converts cuda_cores into a number of license tokens and reserves them at submission time. If the value is wrong and then license accounting is wrong, quietly, until the pool is exhausted or Schrodinger subjobs start failing with license errors.
So the first question on any new card is simply: what is this card’s cuda_cores value? The published tables (in license_usage_gpu.htm and config-queuing-system.htm) list a lot of hardware — V100, A100, L4, H100, B200, and two Blackwell workstation cards — but not the RTX PRO 5000 Blackwell. “Blackwell” is a family of very different dies; you cannot interpolate a value from the model number.
Always ask the GPU card, not the documentation table
The authoritative source for a card’s cuda_cores value is the on-node utility, not a lookup table. From the 2024-2 release onward the value labelled “Discounted Cores” is the cuda_cores value (before 2024-2 it was “Total Cores”):
14080, identical across all eight GPUs on the node. That is the value that goes into schrodinger.hosts. Every other number in this post is derived from it.
What 14080 cuda_cores costs in license tokens
Schrödinger’s License Usage per GPU Calculator converts cuda_cores to tokens:
Baseline = (cuda_cores / 5120) × 16. IfBaseline < 16: round to the nearest 4. IfBaseline ≥ 16: floor to the nearest 16. One standard GPU license = 16 tokens (historically anchored to the V100’s 5120 cores).
For the RTX PRO 5000 Blackwell:
(14080 / 5120) × 16 = 44, floored to the nearest 16 = 32 tokens = 2.0 licenses per GPU. A Blackwell RTX PRO 5000 costs exactly twice the license tokens of a V100.
Reference:
Published Schrödinger cuda_cores / token values (from license_usage_gpu.htm and config-queuing-system.htm, 2026-x; core counts are for PCIe models unless noted). One standard GPU license = 16 tokens.
Always verify the exact card with query_gpgpu -a.
| GPU | cuda_cores | Tokens | Licenses |
|---|---|---|---|
| Tesla T4 | 2560 | 8 | 0.5 |
| Tesla V100 | 5120 | 16 | 1.0 |
| A100 | 6912 | 16 | 1.0 |
| L4 (2024-2+) | 7680 | 16 | 1.0 |
| RTX PRO 4000 SFF Blackwell | 8960 | 16 | 1.0 |
| H100 | 14592 | 32 | 2.0 |
| B200 (SXM) | 18944 | 64 | 4.0 |
| RTX PRO 6000 Blackwell | 24064 | 64 | 4.0 |
| RTX PRO 5000 Blackwell (measured, not in 2026-3 docs) |
14080 | 32 | 2.0 |
Note where the 5000 lands: between the 4000 SFF (8960) and the 6000 (24064), and right next to the H100 (14592). Nothing in the model name tells you that. Only the utility does.
Two related gotchas worth knowing while you’re in here:
- Nvidia L4 was
7424before the 2024-2 release and was reduced to5120in 2024-2. A site that upgraded across 2024-2 without re-runningquery_gpgpumay still be using the outdated value. - The single-license exception is ending. 2026-2 was the last release in which one Desmond / WaterMap / FEP+ license covered a single GPU regardless of core count. From 2026-3, high-end single cards (H100, B200, large Blackwell) require multiple licenses per GPU — which makes a correct
cuda_coresvalue significant, not cosmetic.
If this is your first time mixing GPU generations…
Everything above is about getting one number right. The moment a HPC cluster holds two GPU generations, a second problem appears: a single host entry can carry only one cuda_cores value, and no single value is correct for both a V100 (5120) and a Blackwell (14080).
If you leave the old untyped gpu-q entry in place with the V100 value, a job that lands on a Blackwell card reserves 16 tokens when it actually needs 32 — a silent 2× under-reservation. Slurm believes fewer licenses are checked out than really are, over-schedules GPU work, and your users start seeing intermittent “did not manage to acquire a GPU” / “unavailable license” failures at runtime instead of clean queue waits. Those are miserable to diagnose because they look like license-server or GPU faults, not a config typo.
The Schrödinger-supported model is one GPU host entry per GPU type, each with a typed --gres and its own cuda_cores. Split the single gpu-q into two:
That gets the license math right, but it is not free — there are two user-facing consequences to plan for:
- Maestro’s Host dropdown changes. It is populated from the GPU host entries, so users will now see
gpu-v100-qandgpu-blackwell-qinstead ofgpu-q. Any saved Maestro job settings, shell scripts, or workflow/FEP drivers that name-HOST gpu-qwill break (“unknown host”) until repointed. This needs an end-user heads-up, not a silent flip. - Typed jobs stop spilling across pools. A
gpu-v100-qjob will wait for a V100 even if Blackwell GPUs are idle, and vice versa. You trade the old untyped queue’s automatic cross-generation load-spreading for correct per-card accounting. There is no single setting that gives you both.
If you need a zero-user-impact stopgap before you can coordinate the dropdown change, the safe interim patch is to bump the existing untyped gpu-q entry to the larger card’s value (cuda_cores: 14080). Nothing under-reserves after that; V100 jobs simply over-reserve (2 licenses for a 1-license card). Wasteful but safe — and it buys you time to roll out the typed split properly.
One operational note: remember to make the edit in every installed suite’s schrodinger.hosts (e.g. 2025-4, 2026-1, 2026-3) — the entries are usually identical except for the install path. No daemon restart is needed; the Job Server re-reads schrodinger.hosts on every submission.
Bottom line
The NVIDIA RTX PRO 5000 Blackwell’s Schrödinger cuda_cores value is 14080 → 32 tokens / 2.0 licenses per GPU, and as of Suite 2026-3 it is not yet listed in any published table.
The RTX PRO 5000 sits between the two Blackwell cards Schrödinger does document, so guessing from the model name gets you the wrong license math. Run $SCHRODINGER/utilities/query_gpgpu -a on the actual node, read the “Discounted Cores” line, and use that. And whenever a new GPU generation joins an existing queue, don’t reuse the old cuda_cores — split the queue into one typed host entry per generation so every job reserves the licenses it actually consumes.
