Free Sizing Tools
Size it before you buy it
Six calculators built from the sizing work we do before quoting a machine — GPU and AI servers, video analytics, face recognition, VM density, surveillance storage retention and RAID capacity. No sign-up, nothing emailed to you, the arithmetic is shown.
Which one do you need?
Most people arrive knowing the workload but not which calculator answers it. In short: storage questions start with retention, GPU questions start with what the GPU is doing, and consolidation questions start with the machines you already run.
NVR Storage & Retention Calculator
How much storage a camera estate needs, or how many days a given array will hold. Then the chassis, drive count, drive size, bandwidth and NIC that actually carry it.
Use it when a policy or a tender fixes the retention period — 30, 60, 90 days — and you need the array that genuinely holds it. Or the other way round: you have the array and need to know what retention it really gives you once RAID parity and the codec are accounted for.
- Six resolutions, four codecs, motion-recording duty cycle
- RAID 5 and RAID 6 sized side by side, 8 to 60 bays
- Flags an array that fits on capacity but not on throughput
RAID Capacity Planner
Usable capacity for RAID 1, 5, 6, 10 and ZFS RAIDZ1/Z2/Z3 — what the drives are labelled, what the operating system will report, and what the filesystem takes off the top.
Use it before you order drives, and whenever a quoted usable capacity does not match what the operating system will report. The gap between a 20 TB label, 18.2 TiB of addressable space and what the filesystem leaves you is where storage budgets go wrong.
- Seven RAID levels including the ZFS parity variants
- Decimal TB against binary TiB, shown side by side
- Per-filesystem overhead for ext3/4, XFS, NTFS, ReFS and ZFS
GPU & AI Server Sizing Calculator
What an AI workload actually needs: VRAM, GPU count, system RAM and NVMe, from the model size, precision, concurrent users and the context they need.
Use it when you know the model and roughly how many people will use it at once, and need to know whether that is one L40S or four H100s — and how much system RAM and NVMe have to sit behind them.
- Chat, coding, reasoning, RAG, agents, vision and fine-tuning
- KV cache sized properly — usually the term that decides the answer
- Every step of the arithmetic shown, with adjustable headroom
Video Analytics GPU Sizing
How many GPUs a camera estate's analytics needs — stream density by detector, resolution and frame rate, capped to what a chassis holds.
Use it when the camera count is settled and the question is how many GPUs the analytics layer needs. Detector type moves this figure more than resolution does, which is why it is the first input rather than an afterthought.
- Object, people, LPR/ANPR, behaviour, crowd and transformer detectors
- Density anchored on NVIDIA's published VSS benchmarks
- Scales by adding servers, never by overfilling a box
Face Recognition GPU Sizing
Both stages sized separately: extraction against new faces per second, matching against a 10K to 10M enrolled database — the larger one is the answer.
Use it when faces are being matched against a large enrolled database. Extraction and matching scale on different things, so a system sized for one can be badly wrong for the other — this says which of the two is binding.
- Recognition sized per face, not per frame — the usual over-sizing error
- Matching cost scaled by enrolled database size
- Names which stage is binding, because the remedy differs
VM Density & Host Sizing
Enter your virtual machines row by row. Get the host count, their shape, the failover capacity N+1 really needs, and what HA requires from network and storage.
Use it when consolidating or refreshing a virtualisation estate and you need a host count you can defend: how many, what shape, and what N+1 failover actually costs before anyone signs for it.
- Unlimited rows — a real heterogeneous estate, not an average VM
- CPU overcommit 1:1 to 1:3; memory always 1:1, never overcommitted
- Names whether CPU or memory is the binding ceiling
Sizing tools for people specifying infrastructure
These six calculators do the arithmetic we do internally before quoting a machine. They are for the person who has to put a number in a budget, a bill of quantities or a tender response and be able to defend it: how much storage a camera estate needs for ninety days, how many GPUs an inference workload takes at fifty concurrent users, how many hosts a hundred virtual machines really need once failover is included.
Each one is a working tool rather than a lead form. There is no sign-up, no email gate, and nothing you type leaves your browser — the whole calculation runs on your machine. Every step of the arithmetic is shown beside the answer, so you can check it, argue with it, or paste it into a document and attribute it.
What a calculator cannot tell you
Sizing is arithmetic; specifying is engineering. These tools do not know that your corridor cameras see almost no motion at night, that the analytics model you have licensed is heavier than the reference one, that the site has 6 kW to a rack and not 12, or that the tender's evaluation matrix rewards a spare bay. That is the part our engineers do, and it is the part worth a conversation.
Why these and not a vendor sizing sheet
A vendor sizing sheet gives you one number, and it is almost always the number that sells the most hardware or the number from the most flattering benchmark. Neither survives a procurement question. These tools compute from first principles instead — bitrate, duty cycle and parity for storage; model weights, precision and KV cache for inference; per-stream detector cost for analytics — and show the working, so the answer can be reproduced by somebody who does not trust us.
That also means the assumptions are visible and adjustable rather than buried. H.265 at a given resolution has a bitrate range, not a bitrate; a motion-recording duty cycle of 30% is a guess about your scene; a 20% headroom on VRAM is a choice somebody made. Where a figure is an assumption the tool says so and lets you move it, because a sizing that cannot be stress-tested is not a sizing.
The ceilings are real ones. A calculator that returns "you need 11 GPUs" without saying that no chassis in the catalogue holds 11 has answered a maths question and not an engineering one. These cap at what a real chassis takes and then add a second server, which is what actually happens on site.
- Computed from physical quantities, not interpolated from a vendor's single data point.
- Every intermediate figure shown — you can check the arithmetic line by line.
- Assumptions are labelled as assumptions and can be changed.
- Capped at what real hardware holds, then scaled by adding machines.
- Runs in your browser. No sign-up, no data sent to us, no follow-up email.
Need the sizing checked, or turned into a configuration?
Send us the output and the constraints you are working under — the site, the power envelope, the retention policy, the tender reference if there is one. We will come back with a validated configuration and a price, or tell you plainly where the numbers do not add up.
All six run entirely in your browser. Nothing you type is sent to us, and there is no sign-up — if the numbers are useful, they are useful whether or not you ever talk to us.