Call an API, rent a GPU, or use your own hardware?

Choose a way to complete your task, then compare its full cost. Owning a GPU does not make inference free, and a cheaper token price does not prove that a service meets your needs.

Start with the work: the model or acceptable alternatives, the output quality you need, your context length, when requests arrive, and how long users can wait. Then consider four choices: call an API, rent a suitable GPU configuration, keep using an existing system, or buy a new one.

This guide connects those choices without assuming that different models or machines have equivalent performance. The calculator uses hypothetical, editable USD inputs, not live prices, measured throughput or an RTX 5070 benchmark. Method and linked documentation reviewed 6 November 2026.

Start with the decision you need to make

These are starting points, not automatic recommendations. For example, continuous traffic alone does not prove that buying hardware is cheaper. A lightly loaded always-on machine can consume cash while completing little useful work.

Check task fit before comparing money

Write down a small acceptance test. Use representative prompts, expected output length, required tool use or structured output, and your success criteria. Keep the model version and quantization explicit. A smaller open model and a closed flagship are different candidates until the task results establish that both are acceptable.

Check memory and usable speed separately. Weights are only part of the memory requirement; context and concurrent requests also need capacity. CPU offload can change how a model runs, and a model that loads is not necessarily fast enough for your workload. Ollama documents how to inspect the CPU/GPU split with ollama ps; that status is not itself a latency benchmark. See the Ollama FAQ.

For each candidate, record:

• Whether it passes the same quality and capability checks.
• Context length, quantization, software version and hardware configuration.
• Time to first useful output and completion time under representative concurrency.
• Accepted completions, retries and failed requests during a defined time window.
• Whether the service window, privacy, licensing and deployment-control requirements are met.

Do not turn a short peak tokens-per-second result into a month's sustainable capacity. Traffic distribution matters: an hourly average can hide a queue that misses the deadline during a burst. An API can also have rate limits that must be checked for your account and route.

Estimate four budgets for your workload

Use monthly token totals for the API and independently established runtime for each hardware option. The calculator does not convert tokens into GPU hours, validate model fit, or infer performance equivalence from the name of a GPU.

All numerical examples use a 30-day planning month. New hardware is modeled as an outright purchase, and the existing system is assumed to have no outstanding loan. Enter paid external operations, applicable taxes, cooling, repairs, backup services and other relevant expenses in the cash-cost fields. If a cost is already included in a quote, do not add it again.

Read cash spending and ownership cost separately

API: token usage plus other cash costs over the planning period. Input, output and actual cached reads have separate rates. Include retries in usage and put relevant funding fees, minimum charges or other services into the monthly cash field. Enter your own integration setup and operations hours separately; these contribute to economic cost, not cash paid. Enter paid external labor in cash fields instead.

Rented GPU: billed compute, storage, transfers, other cash expenses and the value of your setup and operations time. Billed hours can include startup and idle time. Runpod distinguishes running and retained storage charges, so stopping GPU compute is not the same as eliminating every charge. See Runpod Pod pricing and our Runpod vs Vast.ai session calculator.

For request-pattern decisions, use Serverless or a dedicated Pod? to compare worker lifecycles with an independently entered Pod service window.

Existing hardware: the old purchase is not a new cash payment. Additional cash can include upgrades, electricity and maintenance. Economic cost also includes the system's value used during the period: its current realizable sale value minus the expected value at the end. This makes the opportunity cost of keeping a valuable machine visible without charging its original purchase price again.

New hardware: whole-system purchase and setup, operating costs and your time, minus expected resale. The interface shows initial cash, total cash paid before resale and terminal asset value separately. It does not treat future resale as money available to pay today's purchase bill.

For both owned options:

Monthly electricity =
  (active hours × active whole-system watts
   + powered-on idle hours × idle whole-system watts)
  / 1,000 × price per kWh

Period economic cost =
  initial system value − terminal value
  + upgrades and setup
  + operating cash costs
  + explicitly valued owner time

Use measured whole-system power when you have it. A GPU's rated power alone does not establish your wall-socket consumption. Hours outside the entered active and idle time are treated as powered off. The model does not automatically add cooling or calculate failure probabilities.

Owner time is included in economic cost and excluded from cash paid. If someone is actually paid, enter that expense in cash costs; avoid counting the same hours again as owner time. Existing-machine incremental cost includes new expenses and your valued time, while its economic total additionally includes the asset value consumed.

Three hypothetical scenarios you can change

The buttons load complete sets of assumptions, including different API volumes and independently assumed GPU hours. They are not a benchmark linking those volumes to those hours. Each preset clears the task-equivalence confirmation.

The table shows period economic budgets, including explicitly valued owner time. It does not name a winner, because the examples do not establish that all options complete equivalent work.

In the existing-system example, the equipment has a hypothetical current value of $1,200 and a terminal value of $600. Over 24 months, that contributes $600 to economic cost but is not a new cash purchase. The same example uses 60 active hours per month at 300 whole-system watts and $0.20/kWh: $3.60 in monthly electricity. Setup and maintenance time have their own cost. Changing idle hours, your time valuation or expected resale changes the result.

The continuous-service example includes both active and idle power. That is still only a planning assumption. A customer-facing service may also require redundancy, recovery, monitoring or a backup API; enter the cash costs and verify that the remaining operational requirements are feasible.

Why there is no universal break-even token count

A break-even point is conditional on a workload, a service requirement and a time horizon. It changes when the input/output ratio, cache use, task quality, hardware throughput, idle time or operating effort changes.

For a simplified monthly cash model, a threshold could be calculated from fixed costs divided by the difference in variable cost per accepted result. That expression is useful only when the variable-cost difference is positive and the self-hosted system has enough capacity. If either condition is missing, the formula does not establish a usable threshold.

This first version compares budgets at your entered workload. It does not extrapolate GPU capacity or produce a universal payback date. To investigate a possible threshold, vary one assumption at a time, export each scenario and recheck whether the task still fits. Use a shorter or longer holding period and a conservative resale value as separate scenarios, rather than assuming one forecast is certain.

For token-specific provider choices, continue with NanoGPT vs OpenRouter or Chutes vs OpenRouter. Use those published-rate comparisons to establish billing assumptions; performance and suitability remain separate checks.

Turn an estimate into a decision

Before committing to a new purchase or a long-running rental, replace the assumptions that could change your choice:

1. Run the acceptance test on the candidate model and configuration.
2. Record representative runtime, failures, retries and service-window constraints.
3. Save the exact quote, region, currency, included resources and date.
4. Measure whole-system power where relevant; record setup and maintenance hours.
5. Recalculate the same accepted workload, including paid idle time and retained resources.
6. Check upfront cash independently of lifetime economic cost.

The useful outcome is a defensible choice for your workload. A lower displayed budget is one input to that choice; it becomes actionable when the requirements and the assumptions behind it have been checked.