GPU optimisation
Buying hardware is procurement. Getting three times the throughput out of hardware you already own is engineering.
Who it's for
You are probably here because
-
01
The cluster is busy and the throughput still disappoints.
-
02
Your GPUs sit idle waiting for the dataloader.
-
03
Inference latency is fine at one user and unusable at fifty.
-
04
Your cloud GPU bill is rising faster than your usage.
What's included
What you actually get.
This page is written for the buyer who already has the cluster and is unhappy with what it produces. Optimisation is the cheapest capacity there is: doubling throughput on an existing cluster defers the next hardware purchase entirely.
Profiling and bottleneck analysis
Where the time actually goes: compute-bound, memory-bandwidth-bound, I/O-bound, or waiting on the scheduler.
Inference throughput work
Batching and continuous batching, KV-cache management, paged attention, speculative decoding, tensor and pipeline parallel layout across nodes.
Quantisation and compression
INT8, FP8 and 4-bit weight quantisation, pruning and distillation, with accuracy measured before and after and never traded silently.
Training efficiency
Mixed precision, gradient checkpointing, ZeRO and FSDP sharding, dataloader and storage tuning so GPUs are not idle waiting for data.
Memory and interconnect tuning
NVLink and PCIe topology, NUMA pinning, collective-communication tuning, overlap of compute and transfer.
Cluster-level utilisation
MPS and MIG partitioning, scheduler queue design, fair-share quotas, right-sizing jobs to devices.
Custom CUDA and HIP kernels
Where a library primitive does not exist or does not fit the shape of your data. Kernel fusion, tiling, shared-memory and register blocking, tensor-core paths with the right precision and layout.
Custom operators and benchmarks
Operators exported into PyTorch, ONNX Runtime or TensorRT with numerical-equivalence checks, each shipping with a reproducible benchmark harness and a maintenance note.
Published shapes
Three shapes, not three prices.
We publish what each tier physically is and who it suits. The number comes after we understand the workload.
| Tier | Shape | Suits | |
|---|---|---|---|
|
Performance audit Ranked report with measured headroom |
Fixed scope: profile the workload end to end | Anyone unsure where the time is going | Brief this tier |
|
Implementation Quoted per item, with a target number |
We execute the ranked list | Teams who have the report and want the throughput | Brief this tier |
How it runs
Each stage, and what it produces.
-
01
Profile
Nsight Systems and Compute across a representative workload.
Output
A written report naming the bottleneck class for each stage.
-
02
Rank
Every fix estimated for effort and expected return.
Output
A ranked list with an estimate of what each fix returns.
-
03
Implement
Quoted per item, each with a target number.
Output
A before-and-after benchmark per item, reproducible by you.
-
04
Verify and hand over
Benchmark harness, maintenance notes, training.
Output
A harness a future engineer can run to check the claim.
What you are handed
- A profiling report with the bottleneck class named per stage
- A reproducible benchmark harness you keep
- Accuracy measured before and after every quantisation change
- A maintenance note per kernel, so it survives the next engineer
Argument panel (dark)
Optimisation is the cheapest capacity there is
Doubling throughput on an existing cluster defers the next hardware purchase entirely. It is the same argument for a cloud bill, where the saving arrives every month rather than once.
Frame this as capacity, not as tuning. The question is not 'can it be faster', it is 'how much of next year's hardware budget can this release'.
Note panel
What we publish
Every engagement ends with an honest before-and-after table: workload, hardware, baseline throughput, optimised throughput, method, and the accuracy delta.
Technical buyers check the method column, which is exactly why it is there. Accuracy is never traded for speed without it appearing in that table.
Technology
Proof
One project, in full.
Stock and dispatch system for a regional distributor
Four branches on separate spreadsheets, month-end taking a week.
One day
Month-end close
Four branches tracked stock in separate spreadsheets. Dispatch errors were routine, nobody could see group stock in one place, and month-end close took a week of reconciliation that one person held in their head.
One day
Month-end close
Four
Branches on one system
Single view
Group stock
Commercials
How buying this works.
Engagement
Fixed-scope performance audit, then implementation quoted per item.
Price
On request, after scope
What sets the price
The audit is fixed scope and fixed price. Implementation is quoted per item on the ranked list, so you buy the fixes worth buying and skip the rest.
Each implementation item carries a target number and a before-and-after benchmark. If we miss the target we say so.
Every project is quoted after we understand the scope. You will have a written, fixed quote before any build work begins. No open-ended billing.
Questions
Answered plainly.
It depends entirely on what is wrong. The audit exists to answer that with a measured number before you commit to implementation, rather than with an adjective beforehand.
Sometimes, and we measure it before and after on your own evaluation set. Accuracy is never traded silently, and if the trade is bad we recommend against it.
Yes. Geospatial processing, video transcode, Monte Carlo and financial workloads all take the same treatment.
Then building one is the first item on the list, because without it no performance claim can be checked, including ours.
Yes. The argument is stronger there: the saving recurs monthly.
Infrastructure
Book a performance audit
Fixed scope, fixed price, and a ranked list with measured headroom at the end of it.
We reply to every enquiry within one working day.