Most of my infrastructure work is in the cloud. This one couldn't be.
A manufacturing plant — about 200 employees, somewhere between 15 and 30 cameras — needed a single on-premises server to run:
- Face ID attendance at the entrances,
- Scale events from the weighing stations feeding inventory,
- and, later, vision AI on the production floor.
Video from 30 cameras going out to the cloud is expensive and fragile, and attendance can't stop working because the internet did. So: a box in the server room.
The tempting move is to buy the biggest GPU you can afford and figure it out later. Here's why I didn't, and what I did instead.
Decision 1: Phase 1 has no GPU — but is built for two
At planning time, two critical numbers were unknown: the final camera count and the real characteristics of the RTSP streams (resolution, codec, bitrate, frame rate). GPU choice depends entirely on both. Buying one before measuring is guessing with a large invoice.
But some parts can't be changed later without rebuilding the whole machine. So the rule was:
Size the parts you can't swap for the maximum config. Defer the parts you can.
| Part | Choice | Why |
|---|---|---|
| CPU | Ryzen 9 9900X / 9950X | Plenty of cores for Phase 1 inference and decode on CPU |
| Motherboard | AM5, X870E with x8/x8 dual-GPU slots, 2× 2.5GbE | Can't be swapped later; must support two GPUs at full useful bandwidth |
| PSU | 1200–1500 W | Sized for two GPUs now so it isn't the reason we rebuild |
| Case | Full tower | Room and airflow for two large cards |
| RAM | 64 GB DDR5, expandable to 128 GB | Start reasonable, leave headroom |
| Storage | 1–2 TB NVMe | Plus a real storage plan (below) |
| GPU | None yet | Bought after measuring real streams |
Motherboard, PSU and case are the "buy once" parts. The GPU is a "buy when you know" part.
Decision 2: The bottleneck is decoding, not inference
This was the most useful insight of the planning phase. People budget for the neural network. But before a frame reaches the network, it has to be decoded from H.264/H.265 — and 30 continuous streams is a lot of decoding.
On NVIDIA cards, decoding is handled by dedicated NVDEC hardware, separate from the CUDA cores that run inference. Different cards have different numbers of decode engines, and a card with excellent inference throughput can still choke on decode if you feed it dozens of streams.
So the GPU question isn't just "how many TOPS?" It's:
- How many streams at what resolution/codec does each NVDEC engine handle?
- Do we actually need every frame? (Attendance at a door does not need 25 fps of analysis.)
- Can cameras provide a low-resolution sub-stream for AI and keep the main stream for recording?
Answering those with measured streams can cut the required GPU class dramatically.
Decision 3: Attendance-of-record lives somewhere else
Attendance data affects payroll. Vision experiments affect nothing — yet. Putting both on one machine means a heavy experiment or a driver update can take down the system people get paid by.
The recommendation: keep the authoritative attendance record on a separate, small, boring machine (Django/DRF + PostgreSQL, synced to the cloud), and treat the big server as a processing node that sends events to it. If the GPU box is down for maintenance, payroll data is safe.
Decision 4: Plan storage before it's a problem
Thirty cameras generate footage continuously. "1–2 TB NVMe" is for the OS, models and databases — not for video. Before go-live you need answers to:
- How many days of footage must be kept, and is that a legal or a business requirement?
- Is footage recorded continuously or only on events?
- Where do backups of the attendance database go?
Rough math is easy and sobering: bitrate × cameras × seconds per day × retention days. Do it with measured bitrates, not spec-sheet ones.
The checklist I'd reuse
- Separate unknowns from decisions. Don't buy anything that depends on an unknown.
- Buy the non-swappable parts (board, PSU, case) for the maximum future config.
- Measure the real streams before choosing a GPU — and check decode capacity, not just inference.
- Reduce the workload first: sub-streams, frame skipping, region-of-interest.
- Keep the system of record off the experimental box.
- Do the storage math before the disks fill up, not after.
Hardware is unforgiving in a way cloud isn't — you can't resize a motherboard. But most of the risk disappears if you're honest about what you don't know yet.