SitePoint’s self-hosted LLM pricing guide, published August 6, contains a 100-fold error in its central cost-per-token example and uses that bad result to claim a six-to-seven-month break-even against API usage. The guide’s own formula produces a monthly total cost of ownership of about $5,931 for its two-H100 colocation scenario. At the stated workload of 5 million tokens per day, that is roughly $39.54 per million tokens, not $0.40.
That changes the practical conclusion for anyone budgeting an on-premises inference server. The $36,000 dual-H100 deployment in SitePoint’s example does not beat GPT-4.1 API pricing at 5 million tokens per day when its stated staffing, colocation, power, and tooling assumptions are included. Its ongoing monthly operating expense alone exceeds the correctly calculated GPT-4.1 bill by several thousand dollars.
The page does identify several real costs that teams routinely omit—engineering time, facility overhead, and capacity utilization—but its worked example turns the article’s headline recommendation upside down. Engineers should not use its break-even table or its supplied calculator outputs for procurement approval without correcting the units and re-running their own traffic data.
SitePoint’s example assumes $36,000 in used H100 SXM hardware amortized over 36 months, two GPUs drawing an average of 500 watts, a 1.4 power-usage-effectiveness multiplier, $0.13 per kWh electricity, $700 monthly colocation, $100 in software, and 25% of a senior engineer costing $192,000 annually. The article’s formula correctly returns approximately $5,931 per month.
The next calculation does not. The guide defines monthly volume as daily token volume, measured in millions, multiplied by 30. At 5 million tokens per day, that is 150 million tokens per month. Dividing $5,931 by 150 produces $39.54 per million tokens.
SitePoint instead states that the same arrangement yields “~$0.40 per 1M tokens.” That figure would require around 14.8 billion tokens per month, or about 494 million tokens every day—not 5 million. The error is not a minor rounding issue: it cuts the reported unit cost by a factor of roughly 99.
The article then carries the mistake into its break-even story. It says the deployment reaches parity with GPT-4.1 at roughly 5 million tokens daily and recovers the $36,000 hardware investment in about six to seven months. Neither claim survives the article’s stated assumptions.
OpenAI lists GPT-4.1 at $2 per million input tokens and $8 per million output tokens. With SitePoint’s assumed 70% input and 30% output mix, the blended rate is $3.80 per million tokens. At 150 million tokens per month, GPT-4.1 usage would cost about $570 monthly before discounts and cached-input effects—not the $7,500 to $15,000 monthly range asserted in the guide.
The result is straightforward: $570 in API spending cannot cover $4,931 in monthly operating expenses, let alone repay a $36,000 hardware purchase. Under that scenario, there is no financial break-even.
The article’s own
Using SitePoint’s full $5,931 monthly TCO and GPT-4.1’s $3.80 blended rate, the deployment would need to process about 52 million tokens per day merely to match the API bill. That assumes every generated token can be served by an open-weight model whose quality is acceptable for the workload—an assumption that should never be hidden inside a pricing comparison.
If a company already has operations staff, rack space, network capacity, and a server team whose work is not materially increased by the model service, its incremental costs may be lower. But SitePoint did not make that leaner scenario its worked example. It specifically assigned $4,000 per month to engineering labor and $700 to colocation, then treated the project as though those costs did not govern its claimed API crossover.
The same problem is visible in the guide’s comparison with low-cost open-model API providers. SitePoint says a provider charging $0.40 per million tokens would cost about $600 monthly at 5 million tokens per day. The correct arithmetic is $60: 150 million monthly tokens multiplied by $0.40 per million.
Even a continuously utilized $2,016-per-month H200 cloud commitment would need to serve roughly 168 million tokens daily to match a $0.40-per-million API rate. A full $5,931 monthly owned-and-colocated deployment would need almost 494 million tokens daily. Those figures may be reachable for a high-volume product, but they are a completely different capacity-planning conversation from “50M+ tokens per day.”
That naming error matters beyond taxonomy. Dense parameter count, total mixture-of-experts parameters, active parameters, weight format, maximum context, KV-cache precision, batching, and concurrency all determine memory use and throughput. Treating “70B” as a universal deployment class is a shortcut that conceals the actual engineering constraints.
The H200 comparison shows why. NVIDIA confirms the H200 provides 141 GB of HBM3e memory. A dense 70-billion-parameter model stored in FP16 consumes roughly 140 GB of weight storage before runtime allocations, attention buffers, and the key-value cache used to retain context during generation. A single H200 therefore cannot realistically provide a useful concurrent FP16 serving configuration for a 70B dense model merely because the nominal parameter count almost equals the card’s memory capacity.
SitePoint says an H200 “suffices” for a 70B FP16 model serving concurrent users at moderate throughput. That conclusion needs model-specific profiling, a defined context limit, batch size, framework configuration, and an explicit memory budget. None are supplied. vLLM documentation and its engineering work on cache management make clear that KV-cache allocation is a first-order serving constraint, not spare change left after model weights load.
A quantized 70B model is a different case. Four-bit weights reduce the memory requirement dramatically, making a 48 GB or 64 GB multi-GPU setup viable for some workloads. But quantization changes quality, throughput, memory pressure, and sometimes feature compatibility. A planning document should state the quantization method and performance target rather than label a GPU “70B FP16” capable as if that establishes production capacity.
But those figures cannot substitute for instance-level and region-level quotes. AWS sells H200 capacity in eight-GPU P5e and P5en configurations, for example; a per-GPU hourly number does not necessarily describe what a customer can rent as a standalone production endpoint. Capacity commitments, networking, storage, support tiers, reserved-use terms, and regional availability can produce a materially different bill.
The U.S. Energy Information Administration also publishes electricity data by sector, month, and geography. A flat $0.13 commercial rate can be a reasonable model input, but it is not a safe estimate for a colocated server, a home lab, or a business with demand charges. The guide appropriately warns readers to use local rates, yet its headline figures project more certainty than the underlying variables support.
Hardware depreciation deserves similar caution. A used H100 SXM board is not a consumer GPU purchase. Compatibility with the server chassis, cooling arrangement, NVLink or NVSwitch topology, firmware state, support contract, replacement lead time, and burn-in testing can all turn an attractive secondary-market price into a costly integration project. Those risks do not invalidate used hardware; they are why it should be modeled as an availability and maintenance decision rather than just an amortization line.
A useful model should specify:
SitePoint is right that staffing is often the hidden line item. Its own example shows why: the $4,000 monthly fractional engineer allocation dwarfs the $131 modeled power bill. Correcting the arithmetic makes the lesson sharper. For a modest 5-million-token-per-day service, the people operating the stack—not the electricity or the GPU purchase—determine whether self-hosting is economically rational.
The page does identify several real costs that teams routinely omit—engineering time, facility overhead, and capacity utilization—but its worked example turns the article’s headline recommendation upside down. Engineers should not use its break-even table or its supplied calculator outputs for procurement approval without correcting the units and re-running their own traffic data.
The $5,931 example costs $39.54 per million tokens
SitePoint’s example assumes $36,000 in used H100 SXM hardware amortized over 36 months, two GPUs drawing an average of 500 watts, a 1.4 power-usage-effectiveness multiplier, $0.13 per kWh electricity, $700 monthly colocation, $100 in software, and 25% of a senior engineer costing $192,000 annually. The article’s formula correctly returns approximately $5,931 per month.The next calculation does not. The guide defines monthly volume as daily token volume, measured in millions, multiplied by 30. At 5 million tokens per day, that is 150 million tokens per month. Dividing $5,931 by 150 produces $39.54 per million tokens.
SitePoint instead states that the same arrangement yields “~$0.40 per 1M tokens.” That figure would require around 14.8 billion tokens per month, or about 494 million tokens every day—not 5 million. The error is not a minor rounding issue: it cuts the reported unit cost by a factor of roughly 99.
The article then carries the mistake into its break-even story. It says the deployment reaches parity with GPT-4.1 at roughly 5 million tokens daily and recovers the $36,000 hardware investment in about six to seven months. Neither claim survives the article’s stated assumptions.
OpenAI lists GPT-4.1 at $2 per million input tokens and $8 per million output tokens. With SitePoint’s assumed 70% input and 30% output mix, the blended rate is $3.80 per million tokens. At 150 million tokens per month, GPT-4.1 usage would cost about $570 monthly before discounts and cached-input effects—not the $7,500 to $15,000 monthly range asserted in the guide.
The result is straightforward: $570 in API spending cannot cover $4,931 in monthly operating expenses, let alone repay a $36,000 hardware purchase. Under that scenario, there is no financial break-even.
| Scenario using SitePoint’s stated assumptions | Correct result |
|---|---|
| Monthly TCO for the two-H100 colocation deployment | $5,931 |
| Monthly volume at 5M tokens per day | 150M tokens |
| Self-hosted cost per 1M tokens | $39.54 |
| GPT-4.1 monthly cost at a 70/30 input/output mix | $570 |
| Self-hosting operating expense before hardware amortization | About $4,931 per month |
| Break-even against GPT-4.1 at that traffic level | It does not occur on cost alone |
break_even_month function actually contains the correct guardrail: when monthly self-hosting operating expense is equal to or higher than the API bill, it returns infinity. The error appears to be in the manually supplied API-cost input and the cost-per-million interpretation, rather than in that portion of the Python logic.
The claimed 2M–5M daily crossover is far below the math
A corrected crossover point depends on what costs the organization treats as incremental. That distinction is more important than a single generic “self-hosting break-even” number.Using SitePoint’s full $5,931 monthly TCO and GPT-4.1’s $3.80 blended rate, the deployment would need to process about 52 million tokens per day merely to match the API bill. That assumes every generated token can be served by an open-weight model whose quality is acceptable for the workload—an assumption that should never be hidden inside a pricing comparison.
If a company already has operations staff, rack space, network capacity, and a server team whose work is not materially increased by the model service, its incremental costs may be lower. But SitePoint did not make that leaner scenario its worked example. It specifically assigned $4,000 per month to engineering labor and $700 to colocation, then treated the project as though those costs did not govern its claimed API crossover.
The same problem is visible in the guide’s comparison with low-cost open-model API providers. SitePoint says a provider charging $0.40 per million tokens would cost about $600 monthly at 5 million tokens per day. The correct arithmetic is $60: 150 million monthly tokens multiplied by $0.40 per million.
Even a continuously utilized $2,016-per-month H200 cloud commitment would need to serve roughly 168 million tokens daily to match a $0.40-per-million API rate. A full $5,931 monthly owned-and-colocated deployment would need almost 494 million tokens daily. Those figures may be reachable for a high-volume product, but they are a completely different capacity-planning conversation from “50M+ tokens per day.”
“Llama 4 70B” is not a current Meta model
The guide repeatedly frames its API and hardware examples around “Llama 4 70B.” Meta’s released Llama 4 family does not include a 70-billion-parameter model. Meta identifies Llama 4 Scout as a mixture-of-experts model with 109 billion total parameters and 17 billion active parameters, while Llama 4 Maverick has roughly 400 billion total parameters and 17 billion active parameters. The 70B model in Meta’s catalogue is Llama 3.3 70B Instruct.That naming error matters beyond taxonomy. Dense parameter count, total mixture-of-experts parameters, active parameters, weight format, maximum context, KV-cache precision, batching, and concurrency all determine memory use and throughput. Treating “70B” as a universal deployment class is a shortcut that conceals the actual engineering constraints.
The H200 comparison shows why. NVIDIA confirms the H200 provides 141 GB of HBM3e memory. A dense 70-billion-parameter model stored in FP16 consumes roughly 140 GB of weight storage before runtime allocations, attention buffers, and the key-value cache used to retain context during generation. A single H200 therefore cannot realistically provide a useful concurrent FP16 serving configuration for a 70B dense model merely because the nominal parameter count almost equals the card’s memory capacity.
SitePoint says an H200 “suffices” for a 70B FP16 model serving concurrent users at moderate throughput. That conclusion needs model-specific profiling, a defined context limit, batch size, framework configuration, and an explicit memory budget. None are supplied. vLLM documentation and its engineering work on cache management make clear that KV-cache allocation is a first-order serving constraint, not spare change left after model weights load.
A quantized 70B model is a different case. Four-bit weights reduce the memory requirement dramatically, making a 48 GB or 64 GB multi-GPU setup viable for some workloads. But quantization changes quality, throughput, memory pressure, and sometimes feature compatibility. A planning document should state the quantization method and performance target rather than label a GPU “70B FP16” capable as if that establishes production capacity.
Hardware price ranges are inputs, not a deployment plan
Several of SitePoint’s broad hardware observations are directionally sensible. NVIDIA’s H200 does have 141 GB of HBM3e memory, and AWS publishes H200 capacity-block pricing in a range that overlaps part of the guide’s cited hourly figures. The guide’s electricity calculation—two 500 W GPUs running for 720 hours equals 720 kWh before facility overhead—is also arithmetically correct.But those figures cannot substitute for instance-level and region-level quotes. AWS sells H200 capacity in eight-GPU P5e and P5en configurations, for example; a per-GPU hourly number does not necessarily describe what a customer can rent as a standalone production endpoint. Capacity commitments, networking, storage, support tiers, reserved-use terms, and regional availability can produce a materially different bill.
The U.S. Energy Information Administration also publishes electricity data by sector, month, and geography. A flat $0.13 commercial rate can be a reasonable model input, but it is not a safe estimate for a colocated server, a home lab, or a business with demand charges. The guide appropriately warns readers to use local rates, yet its headline figures project more certainty than the underlying variables support.
Hardware depreciation deserves similar caution. A used H100 SXM board is not a consumer GPU purchase. Compatibility with the server chassis, cooling arrangement, NVLink or NVSwitch topology, firmware state, support contract, replacement lead time, and burn-in testing can all turn an attractive secondary-market price into a costly integration project. Those risks do not invalidate used hardware; they are why it should be modeled as an availability and maintenance decision rather than just an amortization line.
A defensible self-hosting calculation starts with service capacity
The better way to evaluate self-hosting is to start with the service the organization needs, then price the infrastructure capable of delivering it. “Tokens per day” alone is inadequate because a bursty workload with strict latency objectives needs capacity that a daily average conceals.A useful model should specify:
- The exact model, revision, weight precision, context limit, and inference engine being deployed.
- Prompt and completion token distributions, including cache-hit rates and tool-generated tokens.
- Peak concurrent requests, target time to first token, required output rate, and availability objective.
- GPU memory reserved for model weights, KV cache, framework overhead, and operational headroom.
- The actual all-in API price for the alternative model, including prompt caching, batch discounts, regional-routing premiums, and volume commitments.
- Whether engineering, facilities, networking, security, and on-call coverage are new costs or costs already funded elsewhere.
SitePoint is right that staffing is often the hidden line item. Its own example shows why: the $4,000 monthly fractional engineer allocation dwarfs the $131 modeled power bill. Correcting the arithmetic makes the lesson sharper. For a modest 5-million-token-per-day service, the people operating the stack—not the electricity or the GPU purchase—determine whether self-hosting is economically rational.
References
- Primary source: SitePoint
Published: 2026-08-06T23:20:08.347000+00:00
Loading…
www.sitepoint.com - Related coverage: pokitx.com
Loading…
www.pokitx.com - Related coverage: apicostcalc.com
Loading…
apicostcalc.com - Related coverage: muirouter.com
Loading…
muirouter.com - Related coverage: ai.google.dev
Loading…
ai.google.dev - Related coverage: ai.google.dev
Loading…
ai.google.dev - Related coverage: discuss.ai.google.dev
Loading…
discuss.ai.google.dev - Related coverage: aws.amazon.com
Amazon EC2 Capacity Blocks for ML Pricing – AWS
Find pricing information and pricing examples for Amazon EC2 Capacity Blocks for MLaws.amazon.com
- Related coverage: platform.claude.com
Loading…
platform.claude.com - Related coverage: platform.claude.com
Loading…
platform.claude.com