How Revolut Cut AI Coding Costs 90%: 56 B200 GPUs, Buy vs Rent

Updated November 4, 2026 · VCT original financial model. Revolut says its self-hosted GLM-5.3 coding infrastructure serves roughly 2,000 engineers on 56 NVIDIA B200 GPUs at a reported blended price of $0.30 per million tokens with cache reads free, and cut its coding-model invoice to about one tenth of what it paid for Anthropic and OpenAI. Those are company-reported results, presented by AI operations leader David Abitbol at AI Engineer NYC on October 13, 2026—not an independent audit of Revolut's costs or engineering productivity.

The question the headlines miss: when would it make sense to buy the GPUs, rent them, or use cheaper APIs and coding subscriptions? It depends on the cache-read share, output tokens, tasks completed, serving hours, model quality and the cost of idle capacity. This original calculation covers all four choices, including GPUs' potential—but highly uncertain—future resale value.

Quick answer:

Don't confuse three different denominators: billed API tokens, total model-server processed tokens and successful coding tasks. An agentic task can cache gigabytes of context, make dozens of requests and still produce a small accepted patch. The economic objective is fully loaded dollars per accepted, verified task at the required latency, not the lowest promotional cents per million.

What Revolut actually disclosed—and what remains unknown

The original talk, transcript and operating slides support the following fact check.

Revolut's technical experience is that FP4 quantization, efficient tensor parallelism, smaller actively served contexts, KV-cache engineering and routing can deliver greater throughput on the same GPUs. Its operations team reported that employees could use models beyond coding—documentation, Jira, coordination and inbox tasks—once budgets stopped making people ration tokens. The causality and the size of productivity uplift remain unverified outside the organization.

GLM-5.3 is an open-weight model from Z.ai, not a proprietary foundation model created by Revolut. Open weights permit local deployment subject to license and security review; they do not imply that model development was free.

A real 2.4-billion-token coding example: caching dominates the bill

One developer supplied the following self-reported usage: two legacy Cursor Pro+ subscriptions at $60 each, $120 total each month, and 2.4 billion counted tokens/month, of which 90% are cache reads. This is an individual case study, not a randomly sampled average from Cursor, Anthropic or OpenAI.

At $0.30/M applied to all 2.4B counted tokens, the hypothetical cost would be $720. At $0.30/M applied only to the 240M non-cached tokens, the hypothetical charge would be $72. Revolut says "cache is free," but its billing reconciliation is undisclosed; do not claim one of those figures is its actual tariff or that the $120 plan entitles every developer to 2.4B tokens. Cached prefixes are cheaper to serve but still occupy memory and infrastructure.

To calculate provider API charges, we need the remaining split. For the article's reproducible example, assume 90% cache reads, 8% uncached input and 2% generated output—2.16B, 192M and 48M tokens respectively. Only the 90% cache share was reported; the additional 8%/2% assumption is a VCT sensitivity scenario.

Current alternatives: GLM, DeepSeek, OpenAI, Claude and Cursor

These are list-price API-equivalent calculations, not actual subscription bills. All prices are US dollars per million tokens from the provider sources linked in the table, and all use the same 90%/8%/2% workload. Vendor models and agent harnesses are not interchangeable in quality or token usage.

DeepSeek's off-peak and peak rates apply at different hours, so they are a range, not a fixed blended month. Its official pricing page lists UTC scheduling and separately billable search/fetch APIs. OpenAI's standard rate differs from Flex, Fast and regional processing. Enterprise contracted rates, cache writes, context premiums, app tooling and tax can change the outcome. Do not interpret cheaper tokens as equivalent coding quality. For this workload, a managed API may be cheaper than the $120 subscription, if the plan allows the required work—and much cheaper than running a rarely used 8×B200 server.

Exact formula, all volumes in millions: API charge = cached-read count × cached price + fresh-input count × input price + output count × output price + tool/cache-write fees. The real comparison should multiply by attempts per accepted task and include engineer review and failure costs.

ChatGPT, Claude Code and Cursor are subscriptions—not raw-token guarantees

Individual developer plan comparisons do not automatically transfer to an enterprise's per-seat procurement contract or pooling rights. Before pricing Claude or ChatGPT from a token count, obtain actual usage telemetry including cache hits and writes, model mix, counted reasoning/output, tool calls and subscription-limit events.

Three usage patterns—not measured platform averages

Those are hypothetical workloads run through API pricing, not a promise that a $20 or $100 plan will serve that volume. The user's $120 realized price is especially informative because it challenges the assumption that self-hosting must be cheaper than a developer's actual subscription.

What can 56 B200s actually serve at a useful speed?

"2,000 engineers / 56 GPUs = 35.7 engineers per GPU" describes access, not full-speed concurrency. Agents spend time calling tools, executing builds, waiting for approvals or running tests; requests arrive in bursts. Separate (a) total processed+cached tokens, (b) fresh prefill throughput, (c) generated tokens per second, (d) simultaneous in-flight requests and (e) latency percentiles.

An independent SemiAnalysis InferenceX GLM-5.3/B200 benchmark measures 9,876 total tokens/sec per GPU at an approximate 200-output-token/sec interactivity target on the AgentX coding workload with optimized FP4/Dynamo SGLang serving. At a 50-output-token/sec target, its measured throughput differs: 13,575 total tokens/sec/GPU with another serving configuration. These are benchmark operating points, not Revolut production trace data. You must never describe 9,876 as output tokens/sec per GPU.

The NVIDIA Dynamo GLM-5.3 recipe tests an agentic workload with 64K median input, 400 median output, 90% KV-cache hits, and KV-aware routing. Its published B200 deployment examples require 16 GPUs (four four-GPU workers) for an aggregated configuration and 20 GPUs for a disaggregated one. A model shard can fit in four GPUs, and an eight-GPU server is a reasonable capital-cost building block for modeling, but that does not establish that a lone eight-GPU node replicates NVIDIA's production benchmark behavior, KV-cache headroom or failover. Test your topology.

For a capacity upper-bound illustration, assume 70% of the 9,876 total-token/sec/GPU benchmark is safely usable at the required latency, leaving 30% for scheduling, variation and spikes. This is our assumption, not a vendor guarantee.

At a fixed 200-token/sec interactive target, spreading a fixed quantity of work over 730 hours instead of 176 hours increases monthly volume capacity about 4.15×. It does not make a server capable of four times the concurrent peak traffic. More off-hour autonomous jobs can raise utilization, while daytime latency targets and queueing remain the binding constraint.

The heavy-coding-user stress test

One 2.4B-token/month user (90% cached reads) consumes 6.85% of a single 8-B200 node's modeled 176-hour capacity, or 1.65% of its modeled 730-hour capacity. Therefore, without spare nodes or peak/latency effects, the benchmark-equivalent upper bounds are ~14 such users per node in 176h or ~60 if perfectly smoothed over 730h; across 56 GPUs ~102 versus ~424. This does not refute Revolut's 2,000 engineers—it reveals why daily token volume and arrival patterns are missing variables in the headline.

With 2% output in the illustrative mix, that heavy user generates 48M output tokens/month, averaging ~76 output tokens/sec during 22 eight-hour workdays. An entire organization with 2,000 such users would request ~152,000 aggregate output tokens/sec while on shift. That is very different from 2,000 engineers holding occasional conversations.

How much reserve capacity?

For seven eight-GPU nodes, one-node failure removes ~14.3% of the fleet. Either (i) keep logical headroom across active nodes and show latency still meets SLOs after one fails, or (ii) pay for an additional physical hot/warm standby node. For example, with 70% normal usage on 56 GPUs, losing eight leaves the original demand at approximately 81.7% of the surviving 48-GPU capacity—before other failure modes or traffic spikes. A hot standby costs capital and power even if it creates no incremental billable tokens.

A single 8-GPU node is not an enterprise N+1 service. A rigorous purchase case should compare the same number of resilient replicas across on-prem, reserved cloud and API, and demand p95/p99 first-token latency plus sustained throughput load-test evidence.

Rent GPUs: public alternatives and the hidden hourly contract

As of November 4, 2026, the major specialist cloud price pages show these illustrative on-demand rates. Availability, server topology, geographic region, networking and committed discounts may differ.

Product selection matters. Lambda also lists different 16+-GPU cluster contracts with longer minimum terms; Together's dedicated inference B200 list price is separate from GPU Clusters, and its preemptible $4.09 rate is unsuitable as the only source of always-on low-latency service. RunPod community rates and secure-cloud rates are not identical. Reserving capacity for 90+ days often changes the break-even. Some providers have a minimum node size or availability-zone shortage; an eight-GPU equivalent is not a binding offer until confirmed.

If a workload can run during 22 eight-hour workdays and shut down without SLA penalty, paying for 176 hours is much cheaper than paying for 730 hours. The owned server's power bill and reserved floor-space may persist after the engineers go home. Conversely, off-hour autonomous agent fleets may use enough night/weekend capacity to make owning infrastructure more attractive.

Buy B200 GPUs: the servers are an asset, but not a risk-free investment

You buy a whole HGX system—GPUs, CPUs, memory, interconnects, storage, cooling, rack space, networking, warranty—not eight consumer graphics cards. Lenovo's June 2026 TCO study quotes $550,475 as the usual customer price for its specific eight-B200 configuration. The October 2026 Rack Report indicates $360K–$470K for other standard eight-GPU nodes. Specifications, support and procurement terms differ; $450K is our illustrative purchase price, not a confirmed offer.

Asset value is real; future resale is uncertain. American Compute reports too few used B200-server sales for a reliable observed resale price. Its forecast for 36-month B200 residual value is approximately 16%–46% of purchase price, depending on conservative versus moderate assumptions. This is a third-party forecast, not a guaranteed buyback or independent liquidation appraisal. GPUs can be sold, moved to another workload, leased to outside users, or retained as redundancy, but the operational and commercial terms determine whether they produce cash. NVIDIA's hardware roadmap and falling inference pricing can impair them long before the book-depreciation period ends.

Three-year discounted cash-flow example: one eight-B200 server

For rigor, use present value, not just linear depreciation. Define monthly discount rate r = 10% / 12, term n = 36, and present-value annuity factor A = (1 − (1 + r)^−n) / r.

Monthly ownership TCO = ((purchase + setup − terminal resale / (1 + r)^n) / A) + recurring operations.

For this base case, it is $17,934.51/month. This is an economic equivalent monthly cost, not the cash you pay every month, an EBITDA figure, or an official tax depreciation rate. It assumes the hardware retains value only as an uncertain terminal cash flow, and financing cost is represented by the discount rate.

Resale sensitivity, same hardware and other assumptions:

A forced liquidation, storage and removal fees or hardware failure could push realization below the forecast bands. Conversely, a second internal workload may create reuse value greater than resale proceeds. Do not double count reuse value and resale: you can reuse the same server or sell it, not both.

Power sanity check: At an illustrative 14 kW IT power draw for an eight-B200 node, power-usage effectiveness of 1.3, 730 hours/month and $0.15/kWh, electricity alone is ~$1,993/month. The other ~$4K of the assumed $6K operating budget must cover colocation, network, warranty and support. A dedicated on-call inference/SRE team may require another $15K–$30K/month in fixed fully loaded personnel costs; at one node, this can materially change the answer. The 14kW, PUE and electricity assumptions are not universally observed deployment costs.

Buy-versus-rent crossover: 274–335 hours per month, before staffing

At Together's $8.19 per GPU-hour, eight GPUs cost $65.52/hour. Divide the $17,935 economic monthly ownership cost by that hourly rental rate: ~274 billable hours/month. Against Lambda at $6.69 per GPU-hour, the break-even is ~335 hours/month. This comparison assumes equivalent fully usable GPU configurations, identical inference quality and no incremental dedicated serving payroll.

• 176 hours/month: Rent Together $11,532 versus own $17,935. Renting wins.
• 730 hours/month: Rent Together $47,830 versus own $17,935. Ownership wins against on-demand GPU rental, provided the fleet is actually needed throughout the period.
• One dedicated $15K/month platform operator, one node: Own ~$32,935/month, moving the Together buy/rent crossover to ~503 hours/month. The same operator cost spread over many nodes is much less significant.

Cash payback is a separate calculation: avoiding a $47,830 cloud rental while spending $6,000/month to operate an owned node would recover $470,000 upfront in roughly 11.2 months if you genuinely need 730 billed GPU hours every month, the cloud has no cheaper long-term contract, and the owned system is service-equivalent. This is a simple cash-payback comparison, not investment profit, an IRR, or a promise that 24/7 on-demand rental is the appropriate alternative for three years.

What if you rent out your idle owned GPUs?

An owned server can potentially generate outside revenue, but that requires customers, a secure multi-tenant stack, billing, incident response, SLAs and distribution. It can also reduce availability for internal users.

Illustration only: a team uses its eight-GPU server 176 hours/month, leaving 554 potential hours. Suppose it can sell idle time at $4 of net incremental contribution per GPU-hour after extra hosting fees and variable costs:

To beat Together's $11,532 work-hours rental bill in this scenario, you would need around 200 extra sold hours/node/month, roughly 36% of the 554 idle hours, at that assumed net contribution. This is not a forecast: customer demand and actual net selling rates may be lower or zero, and the accounting must avoid counting the same GPU capacity twice.

Investor interpretation: A B200 is a depreciating productive asset, not an appreciating securities investment. Its financial return arises from avoided compute spend, cash-paying tenants, or productive reuse minus capital costs and risks; a resale forecast alone is not operating yield.

Interactive calculator: when does self-hosting break even?

Adjust engineers, cache ratios, GPU pricing and hardware depreciation below. The calculator compares subscription, managed API, GPU rental and owned-GPU economic cost under the same demand assumptions. Its outputs are scenarios, not quotes or guarantees of equivalent model quality.

Team-size economics: demand is more important than headcount

An eight-B200 node has a modeled limit of 35.04B counted tokens in 176 serving hours, based on SemiAnalysis's 9,876 total tokens/sec per GPU at the 200-output-tokens/sec interactivity target, 70% usable capacity, and no extra node reserved for failover. It is 145.34B in 730 continuous hours if requests are sufficiently spread out.

At those assumptions, scaling by the number of engineers alone is wrong: an engineer consuming 100M tokens/month and the unusually heavy 2.4B-token/month example consume 24× different capacity.

How team size changes the decision

For the table, a subscribed engineer costs a hypothetical $120/month (the real power-user example's two legacy Cursor subscriptions), every workload is served within 176 hours/month, and infrastructure requires enough full eight-GPU nodes to process the total volume. No standby node or $15K+ monthly dedicated inference engineer is included—both should be added for production HA.

Read the table correctly: At 200 engineers consuming 100M tokens monthly, a $17,935 owned node is below $24,000 in seat subscriptions, but renting those eight GPUs for 176 hours is only $11,532, and a pay-as-you-go GLM API might cost less still. At 100 super-heavy users consuming 2.4B tokens each, fixed subscriptions may be dramatically less expensive if the product actually permits the workload; a seven-node GLM fleet is not competitive at their reported $120/subscriber spend.

Contrast a fully utilized service: At 500 engineers × 200M counted tokens = 100B/month, the same benchmark model fits within the 145.34B one-node capacity when serving over 730 hours. An $17,935 owner/TCO could then beat 730-hour on-demand renting (~$47,830), 500 hypothetical subscriptions ($60,000), and the GLM-5.3 API equivalent of ~$43,400. Quality, 24/7 utilization, failover and staff payroll remain critical. No 8-GPU single-node design should be labeled highly available.

Buy versus the same-model API: a stricter break-even

For GLM-5.3, the same 90% cache / 8% fresh / 2% output mix costs:

Blended GLM API rate = 0.90 × $0.26 + 0.08 × $1.40 + 0.02 × $4.40 = $0.434 per 1M counted tokens.

Equating this with the $17,934.51/month owned-node economic cost gives 41.3B counted tokens/month, at equal quality and developer experience. Compare it with the node's benchmark-derived capacity:

Critical finding: at 176 hours/month, buying cannot beat paying for the same-model API under these exact capacity, cache and price assumptions, even if the server runs flat out. At 730 hours, it can. This is not a categorical verdict for every company: vendor discounts, burstiness, model latency, migration costs and different cache accounting can reverse the result.

At the full modeled capacity, the owned-node economic infrastructure cost is about $0.512 per million counted tokens at 176 hours or $0.123 per million at 730 hours. Do not compare either rate to a token invoice that excludes cache reads without normalizing the denominator.

For an alternative cheap hosted model, the comparison can be even less favorable to buying B200s: at the hypothetical 90/8/2 mix, DeepSeek Flash's off-peak API would be approximately $0.0267 per million counted tokens, much lower than the maximum-capacity owned-node economics. This is not evidence DeepSeek Flash has GLM-5.3's or Claude's task quality or security guarantees.

Mini-calculator: the decisions readers should test

Our separate, ready-to-integrate calculator uses these inputs:

1. Team demand: engineers, counted tokens per engineer/month, cache/fresh/output split (must sum to 100%), subscription price, and serving hours/month.
2. Performance and reliability: validated total tok/s per GPU at a specified user latency, usable fraction, GPUs/node, and separately reserved spare nodes.
3. Cloud/own economics: hourly rental price, complete server purchase and installation, monthly operations, years held, projected resale, cost of capital and incremental platform engineering cost.
4. API comparison: provider's current cached/fresh/output rates and applicable tool charges.

Capacity needed = CEILING(total tokens per month / [GPUs per node × tested total tok/s/GPU × serving seconds/month × usable fraction]).

Total buy/month = active plus reserved nodes × discounted monthly ownership cost/node + incremental platform staff.

Total rent/month = active plus reserved nodes × GPUs/node × billed hours × hourly price + incremental platform staff.

Total API/month = cached tokens × cache price + fresh tokens × input price + output tokens × output price + other tool and platform charges.

The calculator should always label the result "estimated nominal economics; model-quality and peak-latency equivalence not established", rather than auto-declaring the cheapest row a purchasing recommendation.

The best alternatives: use the right tier before spending capital

The most competitive option is usually a portfolio of inference and developer products, not a single cheap model. These categories have different integration, security and quality characteristics.

Model candidates to benchmark before buying: GLM-5.3 (closest to the Revolut example), GLM-5.3 Flash, current DeepSeek Flash/Pro, Qwen open-weight coding models, Kimi, and smaller gpt-oss/Qwen families. Do not declare one model "equally good" using different benchmark suites. Run an evaluation suite of real repository tasks: time-to-accepted patch, tool success/failures, security regression checks and human review minutes.

Serving software: NVIDIA Dynamo/SGLang and vLLM are mature open-source directions worth evaluating; the NVIDIA GLM-5.3/5.2 example uses FP4 B200 workers, KV-aware routing and realistic cached coding traces. SemiAnalysis InferenceX demonstrates how throughput and per-user speed can trade off. A benchmark taken at 50 output tokens/s cannot be substituted for the throughput at Revolut's 200 tok/s target.

Compliance and supply chain: Self-hosting a Chinese-developed open-weight model can keep inference traffic in the organization's own perimeter—but only after auditing the model artifacts, licensing, dependencies, sandbox permissions, logs, retention, PII handling and applicable data-transfer rules. Security comes from the deployment architecture and governance, not the model's country of origin alone.

Avoid an especially common procurement mistake: a $450K node purchased versus $8.19/GPU-hour cloud list price is not a full choice set. Compare the provider's reserved term, spot/preemptible limitations, model API with real cache-hit ratio, alternative open models on fewer GPUs, electricity and networking, N+1, hardware warranty, on-call staffing and opportunity cost of capital.

What engineers actually ask: six 2026 Reddit case studies

Published articles often choose a GPU price, divide it by a per-token API rate, and announce a break-even. Users ask harder questions: What happens when the hardware is idle? Are subscriptions subsidized? How much of my context is cached? What about the person on call? Will my GPUs still be valuable after three years? The following are dated self-reported community examples, not independently audited company disclosures or representative survey results. Their value is in the questions and methods, not in treating every claim as a benchmark.

A worked check of the $6.4K used-GPU story: the poster's $308/month API-equivalent minus ~$64/month electricity is $244/month of gross operating avoidance. Dividing $6,406 by $244 gives a ~26-month simple cash payback before labor, motherboard failures, insurance, network, opportunity cost or resale. If used hardware can be resold, economic TCO can be lower; if the process stops needing that model or output quality drops, payback may never occur. The poster also warned that the coding-plan comparison needed another telemetry check—another reason to label it anecdotal.

These cases explain why three calculators are necessary within one article: API token pricing, GPU buy-versus-rent, and the fully allocated cost of a productive AI engineering workflow.

A faster model can be economically cheaper even with more expensive tokens

Cost per million tokens alone can reward low-quality systems that generate cheap but unusable patches. Build an evaluation from real GitHub issues with the same agent instructions, test suites and review policy. Track accepted changes, retries, tool execution and human review time. Model drift and false positives belong in the denominator.

Hypothetical quality-adjusted example at a $75/hour fully loaded engineering rate (illustrative—not vendor benchmark data):

The cheaper model's inference is six times less expensive per attempt, yet the entire accepted task is about twice as costly once review time is included. This is why enterprise buyers should test a fallback to premium frontier models before deciding that 100% of requests belong on a cheaper self-hosted endpoint.

Operational denominator: dollars per accepted, tested change = (inference + tools + GPU overhead + SRE + failed retries + review labor) / accepted changes. Report it by task class and maintain a holdout evaluation set. If the cheaper model fails critical security tasks at a higher rate, that risk cannot be reduced to one blended token price.

An independent plausibility check on Revolut's 56-GPU throughput

Revolut's own talk and slides show a stable serving phase at around 5.95 requests/second, compared with 3.38 during its earlier TP8 migration. The slides describe 76% more requests/second and 88% lower first-token latency, measured on the same 56 GPUs. Those numbers prove the internal serving configuration improved; they do not disclose mean prompt length, cache hits by request, or total per-engineer tokens.

As a sanity check, not a production measurement, 56 GPUs × the independent 9,876 total tokens/sec per GPU benchmark equals ~553K benchmark total tokens/sec. Dividing that by 5.95 RPS would imply ~93K counted tokens/request if running at 100% of that benchmark or ~65K at the article's illustrative 70% usable capacity. This does not establish that Revolut runs 65K prompts: the benchmark uses a different workload, cache mix and optimized model-serving stack. It shows that engineers need to collect request-weighted real token traces, not reverse-engineer production traffic from one slide.

This cross-check also limits claims about concurrency. A request per second is an arrival-rate measure, while a 200 output-token/sec stream is a per-request decoding speed. A large input prefill may produce very few output tokens; cached context does not cost the same GPU work as fresh context. Sizing from total tokens alone should be explicitly described as a screening estimate, not a production capacity guarantee.

What other cost calculators and guides leave out

The following are worth comparing before commissioning an enterprise inference platform; none supplies audited Revolut traffic. They illustrate why a new synthesis is useful:

The key difference: our calculator is intended to ask not merely "which rate is cheaper" but "can the configuration actually serve the demand within the chosen latency and failure budget, and is it cheaper on a fully comparable task?" A calculated break-even that exceeds one node's available throughput is an impossible break-even for that configuration.

Why this matters to venture investors and infrastructure startups

The VCT AI infrastructure funding map tracks neoclouds, inference platforms, networking, chips and data centers; this case explains how a buyer might underwrite their services. The gross margin of a GPU-cloud startup and the ROI of its customers depend on actual demand: running costs are not automatically justified by a large model, a large user count or an impressive benchmark.

A venture diligence memo should request six reproducible outputs:

1. Real token traces: cached reads, cache writes, fresh input and output by model, hour and tenant.
2. Workload shape: p50/p95/p99 first-token time, decoding throughput, concurrency bursts and context-length distribution.
3. Accepted-task economics: dollars per completed, tested change, including retries, tool use and developer review.
4. Asset quality: delivered GPUs, purchase price, warranty, installation and time to first revenue-generating inference.
5. Capital and exit exposure: cost of funds, encumbrances, depreciation and a resale sensitivity with a downside case of zero.
6. Safety and retention: customer data restrictions, fallback percentage, uptime, model drift, workload retention and gross margins after full overhead.

The highest-return intervention may not be a GPU purchase. It may be a cheaper default model, improved prefix caching, a shorter context, better agent instructions, lower output verbosity, scheduled workloads, or a smarter frontier fallback. Conversely, at sufficiently steady utilization, renting perpetual 24/7 capacity may transfer a very large margin to the provider.

See Qodo's code-verification economics and Factory's coding-agent funding case for two examples of why accepted engineering work matters more than tokens. The winner is the system that delivers the lowest quality-adjusted cost per accepted unit of work, with enough reliability that engineers actually use it. That is a stronger investment metric than dollars per million tokens alone.

Research notes and reproducibility

As-of date: November 4, 2026. US-dollar prices are public US list prices, excluding tax and discounts unless stated. The 2.4B-token Cursor example is self-reported. The 100M and 200M per-employee scenarios, $450K node, 30% resale after 36 months, $6K/month operations, 10% capital cost and 70% benchmark utilization are VCT assumptions. The 9,876 total-token/sec/GPU value is a published benchmark at a specific user-speed target, not a Revolut fleet average. No throughput, resale value or GPU availability should be inferred as guaranteed. This is an operating-economics analysis rather than financial or procurement advice.

For updated workloads, recompute before purchasing: subscription rules and AI API prices change quickly, while hardware acquisition and facility commitments can last years.