Thread capacity is the maximum number of threads Gurobi Optimizer can use for one solve under your license. It applies to the three license types that restrict Gurobi on the number of solves: Single Use, WLS Single Use, and Floating Use.
How capacity is applied depends on the license type and the Gurobi version you run. From Gurobi 14.0, all three license types apply capacity the same way: as a flat cap on threads, whatever the size of the machine or container. Earlier versions applied it differently, as described below.
This article describes how Gurobi behaves.
Cores, logical processors, and threads
To keep the explanation precise, this article uses these terms as follows:
- Physical cores: the processing units in the CPU hardware.
- Logical processors: what the operating system schedules work on. Some articles call these virtual cores or vCPUs.
- Threads: the units of work Gurobi runs in parallel during a solve, set by the Threads parameter. In this article, "threads" never refers to hardware threads or virtual cores.
- Thread capacity: the number of threads your license allows Gurobi to use for one solve. It does not refer to the computing power of your hardware.
Thread capacity counts the threads Gurobi uses, not the hardware it runs on. The hardware still matters: by default, Gurobi decides how many threads to use based on the cores it detects. For background, see What are cores and threads? and How does Gurobi count cores?
How capacity is applied, by license type and version
The Gurobi version that runs your solve decides how capacity is applied. In the table, N is your license capacity (for example, 8, 16, or any numbers).
| License type | Gurobi version | How capacity is applied | Maximum threads per solve |
|---|---|---|---|
| Single Use | 14.0 and later | Flat thread cap, in any environment | N |
| 13.x and earlier | Compared with the machine's physical cores | N if the machine has more than N physical cores; otherwise, no cap | |
| WLS Single Use | 14.0 and later | Flat thread cap, in any environment | N |
| 11.0.1 to 13.x | Compared with the logical processors of the machine or container | N if it has more than N logical processors; otherwise, no cap | |
| 10.0.0 and earlier | Compared with the physical cores of the machine or container | N if it has more than N physical cores; otherwise, no cap | |
| Floating Use with a thread capacity | 13.0.1 and later | Flat thread cap, in any environment | N |
| Floating Use without a thread capacity | All versions | No thread cap | No cap |
Gurobi licenses are backward compatible. With a Gurobi license version X, you can run all Gurobi Optimizer versions <= X, except for Floating Use licenses with a thread capacity. This version requirement applies only to Floating Use.
- Floating Use licenses with a thread capacity require Gurobi Optimizer and the Token Server to both be version 13.0.1 or later. The Token Server refuses token requests from older clients.
- Floating Use licenses without a thread capacity keep working with older clients and servers.
- Single Use and WLS Single Use licenses work with any Gurobi version, so you can upgrade without getting a new license. Only the way capacity is applied changes, as shown in the table.
With these three license types, running on a machine with more cores than your license capacity never causes a license error in any Gurobi version. Gurobi limits the threads instead.
Example: an 8-thread Single Use license
The change in Gurobi 14.0 only makes a technical difference on machines with more than N/2 and up to N physical cores, whereas earlier versions did not cap threads. On larger machines, the result is the same. On smaller machines, the CPU already limits the number of threads in practice, so the result is effectively the same.
| Physical cores | Logical processors | Maximum threads (13.x and earlier) | Maximum threads (14.0 and later) |
|---|---|---|---|
| 12 | 24 | 8 | 8 |
| 8 | 16 | No cap | 8 |
| 4 | 8 | No cap | 8 |
| 2 | 4 | No cap | 8 |
How the Threads parameter works with capacity
The Threads parameter sets how many threads Gurobi may use. Where your license capacity applies (see the table above), it sets the most Gurobi can use, and Gurobi uses whichever is lower.
- Threads = 0 (default): Gurobi picks a thread count based on the hardware it detects, with a soft cap of 32. If your license capacity is lower, Gurobi uses that capacity.
- Threads set to a value at or below your capacity: Gurobi uses up to that value.
- Threads set above your capacity: Gurobi uses your license capacity instead, without an error or warning.
As a general guideline, keep the total threads of all solves running on one machine at or below the number of logical processors available. Some models do run faster with more threads than that, so test with your own models before changing this. See also Managing Threads and Memory Usage in Gurobi.
How to check your capacity and what Gurobi is using
Your license capacity. Sign in to the Gurobi User Portal and open your license. The limits section shows your capacity as Thread Limit or Cores. For WLS licenses, the Web License Manager shows the same information.
The thread count in the log. Each solve starts with a line like this in the log:
Thread count: 8 physical cores, 16 logical processors, using up to 8 threads
The last number is set after applying both the Threads parameter and your license capacity. With the default Threads setting, Gurobi chooses the value based on the hardware. It does not always show your license capacity. To see your capacity, check the User Portal as described above.
What Gurobi sees on your hardware. Run grbprobe to see the physical cores Gurobi detects on a machine, VM, or container.
If you are unsure which license size fits your models and use case, see How many cores does my model need? or contact your (Technical) Account Manager if known.
Further information
- How does Gurobi count cores?
- Managing Threads and Memory Usage in Gurobi
- What information is shared with Gurobi when using WLS licenses?
- What are cores and threads?