Cheapest of Six Azure GPU VMs for gpt-oss-120b: $2,681 to $5,363 a Month

Step 1. Work out how much GPU memory the model needs

The model card lists gpt-oss-120b under the Apache 2.0 license, with “117B parameters with 5.1B active parameters”, and says it can “run on a single 80GB GPU” because its mixture-of-experts weights are quantized to MXFP4 (Hugging Face model card (read 2026-10-18)). We did not take that sentence on trust. The script asks the Hugging Face API for the file list of one pinned commit, b5c939de…, and adds up the root-level model-*.safetensors files: 15 files, 65,248,893,184 bytes (65.2 GB). The repository also holds a second copy of the weights under original/ and a file under metal/. They are alternative formats of the same model, so the script does not count them.

A model needs room beyond its weights: the key-value cache that grows with every token in flight, and the serving software. How much depends on context length and traffic, which this page does not measure. The script sets one constant, HEADROOM_GB = 10, and calls a size a fit when its total GPU memory is at least the weights plus that headroom: 75.2 GB. The 10 is our assumption. Change it and the “fits” column changes with it. The weights are counted in decimal gigabytes (10⁹ bytes) and compared with the GB figure Microsoft states; the page does not settle whether Microsoft’s GB are decimal or binary, and the 10 GB of headroom absorbs that difference.

We chose the six sizes by hand from Microsoft’s GPU size pages: the one- and two-GPU sizes of the NC A100 v4 and NCads H100 v5 series, the eight-GPU ND H100 v5, and a four-T4 size as a size that must not fit. We did not price every Azure GPU size. Not priced: the four-GPU NC96ads A100 v4, the ND A100 v4 sizes, and any H200, MI300X or other family. A size outside this list could cost less than the cheapest one here.

The GPU memory of each size comes from Microsoft’s own size pages (each linked in the table, all read 2026-10-18). The mapping is written out in the script as SKUS, so the reader can disagree with it:

The four-T4 size is in the list on purpose. Its 64 GB in total is below the 65.2 GB of weights, so it is the one size the script must mark as not fitting. A check that cannot fail would prove nothing, and this one fails if the weights are miscounted (run 2).

Step 2. Pull the prices and keep the raw answer

Microsoft publishes list prices through the Azure Retail Prices API, which needs no sign-in. The script uses the 2023-01-01-preview version because the documentation says savings-plan rates are only returned by that version, asks for USD, and filters to serviceName eq 'Virtual Machines', priceType eq 'Consumption' and the six sizes above (Microsoft Learn: Azure Retail Prices REST API overview (read 2026-10-18)). The API returns at most 1,000 records a page and a link to the next one, so the script follows NextPageLink until there is none (Microsoft Learn, same page (read 2026-10-18)), pauses between pages, and waits as long as a retry-after header says if the API asks it to slow down. On 2026-10-18 the answer was 950 rows on one page.

The script writes every row as it came, with the fetch time and each row’s effectiveStartDate, to the snapshot CSV. Everything after that is computed from the file, not from the live API.

Each size has more than one price row per region. The script sorts the 950 rows into four classes from the fields the API returns: spot (skuName contains “Spot”), low priority (contains “Low Priority”), Windows (productName ends in “Windows”), and everything else, which we treat as Linux pay-as-you-go. The “Windows” test is our reading of the API: its documented example row has the productName “Virtual Machines FS Series Windows”, and the rows for these sizes follow the same pattern (Microsoft Learn, same page (read 2026-10-18)). Only the last class is priced here: 169 rows. A row of any other type than Consumption would show up as its own “other type” class in the row count and would not be priced.

Step 3. Turn the hourly price into a month

The API prices a VM per hour. A month is 730 hours (8,760 divided by 12), the same for every region, so the monthly figure is the hourly price times 730. That assumes the VM runs all month. A VM you stop part of the day costs less, and the CSV has the hourly price so you can apply your own hours. The 1-year and 3-year figures are the savings-plan hourly rates the API lists on the same row, times 730, where it lists them.

SELECT l.sku, t.gpus, t.gb, (t.gpus * t.gb >= {need_gb}) AS fits, l.region, l.location, l.price,
       round(l.price * 730, 2) AS monthly, round(l.sp1 * 730, 2) AS m1, round(l.sp3 * 730, 2) AS m3
FROM lin l JOIN sku_t t USING (sku)
ORDER BY fits DESC, t.gpus, l.sku, monthly, l.region

The full script has the fetch, the self-checks listed under Method, and the CSV writer. It needs Python 3 and the duckdb module (DuckDB documentation (read 2026-10-18)).

Run 2: plant seven faults and see whether the script notices

We ran the script from the saved snapshot with seven faults planted after loading and before the checks: one Linux price row loaded twice, one price set to 0, one A100 row renamed to a size that is not in the mapping, every row of one size deleted, one price quoted per month instead of per hour, one 3-year savings-plan rate set 50% above the price, and the weights size halved, as if only half the files had been summed. Each fault trips named checks:

• The duplicated row trips the row count against the file’s data lines and the check for one Linux row per size and region.
• The zero price trips the check that every price is above zero.
• The renamed size trips the check that every size the API returned is in the mapping.
• The deleted size trips the check that every key of the mapping matches at least one Linux row (Standard_NC80adis_H100_v5 matches none), and the row count.
• The monthly price trips the check that every price is in USD per hour.
• The inflated savings-plan rate trips the check that no rate is above the pay-as-you-go price.
• The halved weights trip the check against the pinned byte count and the check that the four-T4 size does not fit. With 32.6 GB of weights it would fit, and the table of results would quietly list it as a candidate.

The script reports nine failures, prints no table, exits with code 1 and writes no CSV. One fault is counted twice in places: the duplicated row is also the first row the zero-price, per-month and savings-plan faults hit, so those checks report two rows, not one. The planted run counts 141 Linux rows where run 1 counts 169. The script holds its result tables back when a check fails, so a reader never sees numbers from a run that did not pass.

Command: run 2

python3 guides/azure-gpu-cost-by-region/azure_gpu_cost_by_region.py --out loop-out/planted.csv --snapshot guides/azure-gpu-cost-by-region/azure_vm_prices_2026-10-18.csv --plant duplicate-row,zero-price,rename-sku,drop-sku,bad-unit,sp-above-price,weights-shrunk

Output from our run 2

duckdb 1.5.6, python 3.14.8
model   openai/gpt-oss-120b @ b5c939de8f754692c1647ca79fbf85e8c1e70f8a license apache-2.0: 15 weight files, 65248893184 bytes (65.2 GB)
PLANTED: the weights size halved, as if only half the files were summed
need    32.6 GB of weights + 10 GB headroom = 42.6 GB of GPU memory
PLANTED: one Linux price row loaded twice
PLANTED: one Linux price set to 0
PLANTED: one NC24ads A100 v4 row renamed to a size that is not in SKUS
PLANTED: every NC80adis H100 v5 row deleted
PLANTED: one Linux price quoted per '1 Month' instead of '1 Hour'
PLANTED: one 3-year savings-plan rate set 50% above the pay-as-you-go price
prices  guides/azure-gpu-cost-by-region/azure_vm_prices_2026-10-18.csv: 950 data lines, fetched 2026-10-18T14:42:48Z
rows by meter class: linux pay-as-you-go 141, low priority 248, spot 268, windows 140
Linux pay-as-you-go rows from a non-primary meter region: 0 (kept: they are the only Linux row for their region and size if the checks below pass)
Linux rows whose 1-year and 3-year savings-plan rates both equal the pay-as-you-go price (no discount): 2

SELF-CHECK FAILED: no CSV written
  - loaded 797 price rows but the file has 950 data lines (-153)
  - weights are 32624446592 bytes, the pinned commit has 65248893184
  - rows with a size that is not in SKUS: 'Standard_NC24ads_A100_v4_x' x 1
  - SKUS key 'Standard_NC80adis_H100_v5' matches no Linux pay-as-you-go row
  - 1 size-and-region pairs have more than one Linux pay-as-you-go row
  - 2 Linux rows have a price that is missing or not above zero
  - 2 Linux rows are not priced in USD per '1 Hour'
  - 3 Linux rows have a savings-plan rate above the pay-as-you-go price (or a 3-year rate above the 1-year rate)
  - Standard_NC64as_T4_v3 (4 x 16 GB) was expected not to fit the weights, but it does
exit code 1

Run 3: the same numbers from the saved snapshot

A reader who wants to check the page does not need today’s prices. We ran the script again with --snapshot on the file run 1 saved. It reads the same 950 rows, passes the same checks and writes a CSV that is identical to run 1’s, which run 4 confirms by comparing the two files. Only the weights are fetched again, from the pinned commit. The two tables between the blocks below are left out here; they are the ones run 1 printed, from the same rows.

Command: run 3

python3 guides/azure-gpu-cost-by-region/azure_gpu_cost_by_region.py --out loop-out/rerun.csv --snapshot guides/azure-gpu-cost-by-region/azure_vm_prices_2026-10-18.csv

Output from our run 3, the facts

duckdb 1.5.6, python 3.14.8
model   openai/gpt-oss-120b @ b5c939de8f754692c1647ca79fbf85e8c1e70f8a license apache-2.0: 15 weight files, 65248893184 bytes (65.2 GB)
need    65.2 GB of weights + 10 GB headroom = 75.2 GB of GPU memory
prices  guides/azure-gpu-cost-by-region/azure_vm_prices_2026-10-18.csv: 950 data lines, fetched 2026-10-18T14:42:48Z
rows by meter class: linux pay-as-you-go 169, low priority 290, spot 322, windows 169
Linux pay-as-you-go rows from a non-primary meter region: 0 (kept: they are the only Linux row for their region and size if the checks below pass)
Linux rows whose 1-year and 3-year savings-plan rates both equal the pay-as-you-go price (no discount): 2

Output from our run 3, the self-check

SELF-CHECK PASSED: 950 price rows equal the 950 data lines of the file, the weights equal the pinned 65248893184 bytes, every size is mapped, every SKUS key matches a Linux row, one Linux row per size and region, every price is above zero in USD per hour, no savings-plan rate is above its price, 1 size(s) do not fit
wrote loop-out/rerun.csv
exit code 0

Command: run 4, compare the two CSV files

python3 -c "print(open('loop-out/rerun.csv').read() == open('guides/azure-gpu-cost-by-region/azure_gpu_cost_by_region.csv').read())"

Output from our run 4

True
exit code 0

Method

• Prices: Azure Retail Prices API, https://prices.azure.com/api/retail/prices, api-version=2023-01-01-preview, currencyCode=USD, fetched 2026-10-18 (run 1 saved the exact fetch time in the snapshot). The API has no release to pin, so the raw rows are the pin: azure_vm_prices_2026-10-18.csv, 950 rows, each with its effectiveStartDate. Prices are as of that date.
• Model: openai/gpt-oss-120b, Apache 2.0, commit b5c939de8f754692c1647ca79fbf85e8c1e70f8a, read from the Hugging Face API. Weights are the 15 root-level model-*.safetensors files, 65,248,893,184 bytes.
• Rows kept: type Consumption, not Spot, not Low Priority, productName not ending in Windows: Linux pay-as-you-go, 169 rows, one per size and region.
• Monthly price: hourly price × 730. Savings-plan figures are the hourly rates in the same row × 730.
• Fits: GPUs × memory per GPU ≥ weights + 10 GB (HEADROOM_GB, our assumption).
• Median: the median of the regions where the API lists a price for a size, each region counted once. It is not weighted by anything.
• No sampling, no random seed. Output is sorted by fit, GPU count, size, price and region.
• Self-checks, each with the fault that trips it: rows loaded equal the file’s data lines (a duplicated row, a deleted size); weights equal the pinned byte count (halved weights); every size is mapped (a renamed size); every mapping key matches a Linux row (a deleted size); one Linux row per size and region (a duplicated row); every price is above zero (a zero price); every price is in USD per hour (a monthly price); no savings-plan rate is above its price (an inflated rate); the four-T4 size does not fit (halved weights); the output has as many rows as the Linux price rows (a join that drops rows; no run plants this fault). The CSV is written only if all pass.

Limits

• This is not a client result. It is a list-price calculation from public data. It describes no company’s bill and does not say what anyone paid.
• List price is not what you pay. Enterprise agreements, reservations, spot prices and negotiated discounts are not in it. We did not price reservations or spot, and the savings-plan rates are only those the API lists.
• Compute only. No disks, network, egress, support, serving software or staff.
• It does not measure speed. We did not run the model. Which size serves how many requests a second, at what context length, is not on this page, so the page cannot say which size is the better buy.
• The 10 GB of headroom is an assumption. A long context or many simultaneous requests needs more. At 75.2 GB the one-A100 option is a tight fit on an 80 GB card, and a deployment that needs more headroom would need a larger size, such as the 94 GB H100 NVL size.
• One model. The weights of gpt-oss-120b set the memory test. Another 120B model in another format would need another number.
• A price is not availability. A size listed in a region may need quota you do not have. The API lists Azure Government and edge regions as it returns them; we did not filter them.
• Prices move. The numbers are as of the fetch date. The snapshot lets anyone reproduce them; it does not keep them current.
• Use of the data. The prices are Microsoft’s published retail prices, as the API returns them. The model card lists the Apache 2.0 license (gpt-oss-120b model card (read 2026-10-18)).

Tested on

When this is not enough

• You need your own price. List price is a starting point. Your Azure agreement, reservations or committed spend change it, and so does what you already run.
• You need to know the speed. Which size holds the model is one question and how many users it serves is another. That needs a load test of your model, your context length and your traffic.
• You need capacity. A price in a region is not a quota. Ask Azure.
• You need the whole bill. Add storage, network, serving software, security review and the people to run it before you compare with a deployed alternative.