The Infrastructure Engines

Calculators for people who sign the invoice

Vendor pricing pages round in their own favour. These engines do the arithmetic the other way: what actually fits, what it actually costs, and where the number flips. Every formula is printed on the tool’s own page — nothing is a black box.

Deterministic engines

Same inputs, same output, every time. No account, no rate limit, no server round-trip.

VRAM Oracle

Local LLM Hardware Sizer

Whether an open-weight model fits a given GPU, and what breaks first — weights, KV cache, or context. Resolves to real machines from the index that can actually run it.

Inputs: Parameter count · quantization (GGUF / EXL2) · context length · batch size
Core relation: VRAM ≈ params × bpw/8 + 2 × n_layers × d_model × ctx × batch × kv_bytes + overhead

Open engine →

TCO Calculator

Cloud API vs Local Server Break-Even

The month where owning inference hardware becomes cheaper than paying per token. Includes electricity, depreciation and the utilisation rate you will realistically hit.

Inputs: Monthly token volume · model price · hardware capex · power draw · kWh price
Core relation: break_even_months = capex / (monthly_api_spend − monthly_power_cost)

Open engine →

Cost Predictor

Multi-Model Prompt Cost Calculator

Paste a real prompt, estimate the output, and see the per-call and per-million-call cost across the frontier models side by side. Input and output are priced separately.

Inputs: Prompt text · expected output length · call volume
Core relation: cost = (in_tokens × in_price + out_tokens × out_price) / 1e6 × calls

Open engine →

Dimensionality Matrix

Vector Database Sizer

The RAM an HNSW index needs before it OOMs in production — raw vectors plus graph overhead — and how much headroom to keep for query-time allocation.

Inputs: Vector count · embedding dimensions · precision (fp32 / fp16 / int8) · M (graph degree)
Core relation: RAM ≈ N × (dims × bytes_per_dim + M × 8 × 2) × 1.1

Open engine →

Conversational advisors

These read the product index and reason over it. Describe the workload in plain language; they answer with a specific configuration and name the bottleneck.

Cluster Topology

Hardware Cluster Architect

Describe the workload — model, quantization, concurrency, context — and it proposes a hardware topology drawn from indexed products, with the bottleneck named.

Inputs: Natural-language workload description
Core relation: Retrieval over indexed products, ranked by fit and cost per token/s

Open engine →

Provider Matrix

FinOps Router

Given a token profile and caching behaviour, it computes the cheapest provider mix and shows where prompt caching or a dedicated instance changes the answer.

Inputs: Input / output tokens · cache hit rate · latency tolerance
Core relation: argmin over providers of effective blended price after caching

Open engine →

How these are built

Constants come from primary sources. Bits-per-weight figures track llama.cpp / GGUF quant types; token prices track each provider’s published rate card, dated on the page.

The model is stated, not hidden. Each engine shows its formula and the assumptions it bakes in — KV-cache dtype, HNSW graph degree, utilisation rate — so you can challenge the result.

Results link back to hardware. A VRAM number is only useful next to machines that hit it, so every engine resolves to real entries in the compute index.