Product 2 · Ball tracking
One measured job · the rest estimated
BallTrack AI — GPU performance
BallTrack AI runs a YOLO neural network on every frame, so the GPU
sets the pace. This table is a buying guide: what to expect from a
given card on a typical half of football.
How to read this table: one row is measured, the rest are estimates
The measured row is the RTX 3090, and only the RTX 3090.
It comes from one real job — a ~30 minute match segment
(53,466 frames at 4354×1748) processed on an RTX 3090
with a Ryzen 9 5900X, using the yolo11l model with TensorRT
FP16 and 3 detection workers:
Pass 1 detection 76.7 min at 11.6 fps,
Pass 2 smoothing 15 seconds,
Pass 3 render ~28 min —
~1 h 45 min total.
Every other row is extrapolated, not measured. Those
numbers are calculated from published GPU specifications (FP16 tensor
throughput, memory bandwidth, VRAM and TensorRT support level) and
from published YOLO benchmarks on other hardware.
Nobody has run this workload on those cards. No public YOLO11-large
TensorRT FP16 benchmark exists across this set of GPUs, so the
estimates lean on adjacent measurements and are given as ranges on
purpose — read the range, not the midpoint.
Only the detection pass scales with the GPU.
Pass 2 is a fixed ~15 second CPU cost on every card, and
Pass 3 (render) is decode- and CPU-bound rather than
encoder-bound — on the measured 3090 run NVENC had roughly
6× headroom over the rate the render pass
actually sustained. Every row below therefore holds the render pass
at about 28 minutes, the measured figure, and
lets only the detection pass move. A table whose total times scaled
with raw GPU compute would be wrong.
Real times vary with match length, footage resolution and quality,
model and detection settings, and the rest of your PC — the CPU
matters more than people expect. Treat estimates as
“which class of card is this”, not as a stopwatch.
Why VRAM matters more than raw speed
BallTrack AI does not decide how hard to push your
graphics card — you do. A setting in the app called
detection workers lets you pick a number from
1 to 5 — it starts at 1, so on
every card it is a number you raise deliberately, and it is the main
speed control you have.
The same number also sets how many decode workers the render pass
uses, so it moves both of the long phases. VRAM is what caps
the number you are allowed to pick — which is why memory
size, not clock speed, is the spec to shop for.
VRAM
Workers you can run
What that buys you
8 GB
1–2 workers. Below the floor:
roughly 25% slower than a machine that
can run four.
10–11 GB
3 workers. Most of the win is already
here — within about 8% of the best this pipeline does.
12 GB
4 workers.
Full speed. This is where the curve
goes flat — the useful target.
16 GB
5 workers — the app’s maximum.
Full speed, no memory ceiling to work
around, and enough spare to try a heavier model at fewer
workers.
24 GB+
Still 5 workers. No further gain from the
memory — but this is the one tier that has actually been
run.
Green edge marks the flat part of the curve: past
12 GB, extra memory does not make the job finish sooner. Worker
counts assume the default yolo11l model,
about 2 GB per process, after leaving room for the parent process
and a Windows desktop.
A worker is a whole copy of the model
Each detection worker is a separate process with its own copy of
the network resident on the GPU — roughly 2 GB
each, of which 1.2 GB is the TensorRT execution
context alone. Add ~2 GB for the parent process and ~1.5 GB
for your Windows desktop and browser, and the ceiling is simple
arithmetic: (VRAM − 3.5 GB) ÷ 2.
The gains stop at about four
The GPU serves one worker at a time. A worker spends ~133 ms
on the GPU against ~75 ms on the CPU per frame, so
two workers already keep it busy. Going
1 → 3 is a real, large win; past
about four, more workers change nothing. Shop for enough
VRAM for 3–4 workers, not for the biggest number
on the box.
A heavier model costs you workers
The app labels each model with its memory cost — the largest,
yolo11x, is about
5 GB per worker instead of 2. On the same
arithmetic that turns 16 GB into roughly two workers and
24 GB into about four. Model quality and worker count
trade against each other on one memory budget.
The
honest caveat: all of the above is arithmetic extrapolated from a
single measured configuration — five workers plus the parent process
occupying about 11 GB on a 24 GB card. The numbers say
12–16 GB is comfortable, and that is what
we recommend, but only 24 GB has actually been validated
in real runs. Anything below 24 GB is unvalidated
territory.
Recommended minimum
RTX 3060 12 GB
~2 h 45 min – 3 h 10 min for the job above (estimated)
The cheapest card that clears both hard gates: a modern enough GPU
for TensorRT to load at all, and 12 GB of VRAM
— which is exactly where the worker ladder above goes flat, at
four detection workers beside the parent process
and a Windows desktop. What makes it slow is the chip, not the
memory; it is fine to leave running overnight.
8 GB cards are below the floor, because the
parent process and each worker carry a ~1.2 GB TensorRT
execution context on top of the yolo11l weights and activations —
about 2 GB per process before the desktop takes its share, so
8 GB leaves room for one or two workers and gives up roughly
25% of the pace.
Honesty note: every VRAM figure on this page extrapolates from a
single measured data point — five workers plus the parent occupying
~11 GB on a 24 GB card. No card below 24 GB
has been validated. An RTX 2080 Ti is estimated to be
faster for similar used money, but it sits exactly on
TensorRT’s oldest supported generation and its 11 GB
stops one worker short.
Recommended sweet spot
16 GB, any recent generation
RTX 4080 SUPER or RTX 5070 Ti · ~1 h 35 min – 1 h 45 min (estimated)
16 GB is what takes VRAM out of the equation: all five
workers plus the parent process should fit with room spare, no
memory ceiling to work around, no out-of-memory surprises, and
enough left over to try a heavier model at fewer workers. Buy enough memory, not the fastest
chip — and note that 24 GB does not go faster than
this, because the worker count is already at the app’s
maximum. Detection gains over a 3090 are genuinely marginal
— memory bandwidth, not tensor throughput, is what this workload
rewards — and the second NVENC encoder does not help, because the
render pass is limited by CPU decode rather than by encoding.
Against a 3090 these cards are roughly a wash on time.
Not worth buying for this workload: RTX 4060 Ti 16 GB (the
VRAM is attached to a very narrow memory bus) and GTX 1080 Ti at
any price (TensorRT will not load on it).
Estimated time for a ~30-minute match segment
yolo11l · TensorRT FP16 · 53,466 frames at 4354×1748
·Ryzen 9 5900X class CPU
·sorted fastest to slowest
Measured actually run and timed
Estimate calculated from specs — never run
Worker-capped VRAM stops short of the 4-worker plateau
The uncomfortable part of these numbers
The spread from the recommended minimum to the fastest consumer
GPU on the market is only about 2.5×, against a
roughly 8× gap in raw half-precision tensor
throughput. That is because a large share of the work is not on the
GPU at all: video decoding, masking, tracking and smoothing all run
on the CPU. The render pass alone is a measured 28
minutes that barely moves with the graphics card, so on this
hardware the pipeline cannot go below roughly 35 minutes
total no matter how fast the card is.
Practical consequence: past the 16 GB class, spending
more on a GPU buys progressively less. The remaining big wins are
software-side, and they are on our list.
Method, in brief: non-measured rows scale only the detection pass of
the measured RTX 3090 result, by a blend of each card’s half-precision
tensor throughput and memory bandwidth, after splitting that pass into
GPU-bound and CPU-bound shares — only the GPU share scales. Pass 2 is held at
the measured 15 seconds and the render pass at the measured ~28 minutes on
every card, because it is limited by CPU-side decode and frame handling rather
than by the encoder; extra NVENC engines therefore do not shorten it. The
worker column is what the app’s 1–5 detection-worker setting will
let you select on that card: usable VRAM at roughly 2 GB per process after
leaving room for the parent process and a Windows desktop, extrapolated from
one measured configuration (five workers plus parent, ~11 GB on a 24 GB card)
— nothing below 24 GB has been validated. Detection fps figures inherit the
measured run’s three-worker pace and are not scaled up for cards that
could run four or five, because the modelled gain from three to four is only
about 8% and stops there; a card limited to one or two workers falls
roughly 25% behind the four-worker best case, against the three-worker
pace’s 8%.
Estimated totals are rounded to the nearest five minutes;
ranges are roughly ±10–20%, and wider at the extremes. GPU
specifications, encoder counts and TensorRT support levels come from vendor
documentation. Every non-3090 figure remains an estimate: no such benchmark
has been run.