The Cost of a GPU CI Runner Per Build Minute

A GPU CI runner is priced per minute, which makes the headline number look small and the monthly number look like a mistake. The gap is entirely arithmetic, and it is worth doing once with the assumptions written down.

The published per-minute rate

GitHub’s Actions runner pricing reference lists a GPU-powered larger runner, billing SKU linux_4_core_gpu, at $0.052 per minute, and a Windows equivalent, windows_4_core_gpu, at $0.102 per minute. The standard Linux 2-core hosted runner on the same page is $0.006 per minute. All figures are USD and were on that page at the time of writing, August 2026. GitHub publishes the full table here.

Two structural facts on the same page shape everything below. Larger runners bill only for the minutes a workflow actually executes on them — an idle configured runner costs nothing — and they are available only to organisations and enterprises on the Team or Enterprise Cloud plans. A personal account cannot buy this SKU at any price, which by itself pushes many teams toward the self-hosted comparison below.

What one eval job costs

Take a concrete job: a model evaluation suite that takes twelve minutes of wall clock on the GPU runner from checkout to artifact upload. Every number below is derived from the $0.052 figure above and the stated assumptions; nothing here was measured.

Per run
  12 min x $0.052/min                     = $0.624

Per day, at 40 merged-and-pushed runs
  40 x $0.624                             = $24.96

Per 30-day month
  30 x $24.96                             = $748.80

Same job on a standard Linux 2-core runner (if it could run there)
  12 min x $0.006/min                     = $0.072  (8.7x cheaper per run)

The multiplier is the number worth carrying: on the published rates, the GPU SKU is roughly 8.7 times the standard Linux runner per minute. That ratio, not the absolute cent figure, is what should drive the path filters and concurrency groups discussed in the GPU eval job page. Cutting the trigger from every push to every push that touches model code is frequently a larger saving than any optimisation inside the job.

Note also what the twelve minutes contains. If four of those minutes are a cold weight download, the eval is a $0.416 job wearing a $0.624 price tag, and caching the weights removes a third of the bill without touching the suite.

The self-hosted comparison

The alternative is a GPU instance you run yourself with a self-hosted runner on it. AWS lists g5.xlarge — one NVIDIA A10G, four vCPUs — at $1.006 per hour on-demand in us-east-1 on its EC2 on-demand pricing page at the time of writing. AWS publishes the on-demand table here. Converted and extended:

Per minute
  $1.006 / 60                             = $0.016767/min

Always-on, 730 hours in an average month
  730 x $1.006                            = $734.38/month

Break-even against hosted at $0.052/min
  $734.38 / $0.052                        = 14,122 hosted minutes/month
                                          = about 1,177 twelve-minute jobs
                                          = about 39 jobs per day

So an always-on self-hosted g5.xlarge is cheaper than the hosted GPU SKU only once you are past roughly 39 twelve-minute eval jobs a day. Below that, you are paying for idle silicon. The assumptions doing the work here are: 730 hours per month, on-demand pricing with no savings plan or reserved instance, one instance, and no charge for the EBS volume, the data transfer, or the engineer who patches it. Every one of those pushes the break-even higher, which means the real crossover is worse for self-hosting than the arithmetic above suggests.

The variant that changes the answer is not running the instance all the time. A spot instance launched per job and terminated after it pays only for the job’s own minutes, at a spot price that is typically a fraction of on-demand — the ephemeral spot runner page builds that, and it is where the self-hosted route actually wins on low volume.

Minutes that are not the eval

Per-minute billing meters wall clock, not useful work, and several things inside a job are wall clock nobody counted.

• Image pull. A CUDA base image is measured in gigabytes. On a hosted runner with a cold Docker cache that is minutes, billed at the GPU rate, before any of your code runs.
• Queue time is not billed, but timeout is. A hung job runs to the workflow timeout, and the GitHub Actions default job timeout is 360 minutes. At $0.052 that is $18.72 for one job that produced nothing. Setting timeout-minutes is the highest-value line in the file.
• Retries multiply. A flaky gate that fails one run in four and gets re-run does not add 25% to the bill; it adds 25% of full-job cost each time, which is why the tolerance band on the eval threshold is a cost control as much as a correctness one.
• Matrix jobs multiply too. A three-way matrix over model sizes is three billed runners, not one runner doing three things.

What to check on your own account

The published rate is an input to your bill, not your bill. Three things to read before trusting any of the above.

1. The current runner pricing reference, for the SKU name and rate. Both the label and the price have changed within the last year.
2. Your organisation’s Actions usage report, which breaks spend down by runner SKU and by repository. This is the only place that tells you what fraction of GPU minutes came from which workflow.
3. The included-minutes allowance on your plan, which applies to standard runners and does not apply to larger runners — a detail that surprises teams whose first GPU bill arrives despite an unexhausted minute allowance.

If you take one number away, take the ratio rather than the rate: a GPU CI minute is roughly an order of magnitude more expensive than a standard one, so the cheapest optimisation available is nearly always running the job less often rather than running it faster.