GPU pricing model validation starts before any model reaches a validator. It starts with a profile of what the pricing code actually does on the hardware. Carefully tuned code still fell short of peak in one roofline study, which took a V100 kernel through eight optimisation steps to 55% of theoretical double-precision peak. A profiling pass on a realistic workload shows where the time goes and whether stalled kernels are memory-latency-bound rather than bandwidth-bound.
The same rule applies to every other decision in a quant compute pipeline: local-vol PDE or Heston Monte Carlo, build or buy, how much hardware a treasury needs, and what evidence a model risk team will accept. Each one is settled by measuring your own book, workload and team, not by a general rule or a vendor’s headline number.
Why is our pricing code reaching only half the H100’s quoted FLOPS?
A quoted FLOPS figure is a theoretical peak, so the first step is profiling to find where the pricing kernel spends its time. The diagnosis starts with profiling for hotspots and bottlenecks. Nsight Compute reports achieved compute and memory throughput as a percentage of the theoretical maximum, and its roofline chart places each kernel in the memory-bound or compute-bound region.
TechnoLynx profiles your pricing kernels on the A100 or H100 you target, attributes the gap to its cause and implements the fix the profile supports, as part of GPU Performance Engineering. The first step is agreeing which kernel shapes and batch sizes represent your real workload.
Where the cycles go: reading a root-caused profile
The roofline model caps attainable performance at the lower of two numbers: peak compute, or memory bandwidth multiplied by operational intensity. The ridge point where those two lines meet is the minimum intensity a kernel needs to reach peak. The V100 study shows how that reading drives the work. Its kernel sat in the bandwidth-bound region, just below the 7.4 FLOPs/byte machine balance. Loop restructuring raised its intensity and moved it towards compute-bound. Register pressure then held occupancy at 8 warps per SM until register limits doubled it to 16. The authors also adjusted the ceiling itself: because 58% of the FP64 instructions were fused multiply-adds, the realistic peak was 5.3 TFLOP/s, and the final kernel reached 70% of that. Pricing code needs the same adjustment. With 58% FMAs the V100 study’s realistic ceiling was 79% of theoretical peak.
“Memory-bound” needs a closer look. Nsight Compute’s guidance separates two cases. A kernel stalled waiting on L1TEX loads is memory-latency-bound, which is not the same as saturating bandwidth, and it needs more instruction-level parallelism, unrolling or pipelining rather than more bandwidth. On the H100 specifically, one measurement study found that plain global-load bandwidth peaked at a small per-thread load and then fell by about 35% as offered load rose. The authors describe this as a regime that depends on configuration, not a property of every kernel. NVIDIA’s CUDA guide makes effective bandwidth (bytes read plus bytes written, divided by elapsed time) a high-priority metric for measuring performance.
Launch overhead on fast silicon
On the H100, one study found a launch-overhead effect that the slower L4 did not show. A 2026 study of batch-1 decode found an H100 reaching only 27% of its peak HBM bandwidth, while an L4 reached roughly 81%. The study traced the difference to per-kernel CPU launch overhead: about 30 µs to launch each kernel, against roughly 10 µs of GPU work per kernel on the H100. A CUDA Graphs A/B test, which changes only the launch path, made the H100 1.259× faster and the L4 only 1.028× faster. The scope is narrow: 7 to 8B-parameter grouped-query-attention transformers at batch size 1, bf16 weights, and NVIDIA GPUs hosted on Modal’s cloud only. The mechanism (a fixed CPU cost per launch, and less GPU time per kernel on faster silicon) does not depend on the workload being a language model, so it is worth checking in any pricing loop that launches many short kernels per quote.
cuBLAS shape fit, or something else?
When the hot kernels are matrix operations, library calls are the next suspect. The roofline chart shows which region each kernel falls in. If the library kernel itself sits low on the roofline, the first move is to pad, reshape or batch the calls. If it sits near its roof and the step is still slow, the time is going somewhere else. A study of GPU ports of QuantLib code paths also relied on profiling. Profiling explained one application’s weaker speedup as divergent branches plus local-memory traffic. Auto-tuning a Monte Carlo kernel raised its L2 hit rate from 6.17% to 65.7% for a 1.72× gain, and the best configuration was specific to each GPU architecture.
Profiling findings and the first fix each one points to
| What the profile shows | What it means | First fix to try |
|---|---|---|
| Kernel under the sloped part of the roofline | Bandwidth-bound | Data layout, coalesced access, lower precision where results allow |
| Long-scoreboard stalls on L1TEX, bandwidth not saturated | Memory-latency-bound | Instruction-level parallelism, unrolling, pipelining |
| Low achieved occupancy from high register use | Too few warps to hide latency | Retune block size or cap registers, then check for spills |
| Short kernels where launch time outweighs GPU work per kernel | Launch-bound | CUDA Graphs, larger batches per launch |
| One math pipeline oversubscribed | Compute-pipeline-bound | Change the instruction mix to balance the pipelines |
Custom kernels come last. Vendor-specific APIs are not magically faster than standard ones. They expose lower-level features that only pay off with real engineering commitment, and whether that commitment is worth making is a question for the profile, not for a blog post. Custom kernel work earns its place only when the standard fixes in the table fail to close the gap. For a deployed pricing service under latency or inference cost pressure the order is the same: batching, caching, quantisation, runtime choice and serving configuration can each be tuned on their own, and replacing the model is the most expensive lever. NVIDIA’s own guidance is to judge progress by absolute duration and to re-identify the dominant limiter on each new architecture. Our piece on why kernel-level profiling beats vendor specs covers that diagnosis in more depth.
If the question is which GPU to buy rather than why the current one underperforms, LynxBenchAI publishes how each device runs the public PyTorch stack. Those results are broadly indicative for custom PyTorch models, but they do not run or measure your pricing kernels, so the profile of your own code still decides.
Where a pipeline also runs a quantised transformer component, quantising one layer at a time against an FP32 reference isolates the layers most sensitive to reduced precision. One published tool found fewer than ten sensitive layers in the vision models it tested, and handling those separately improved quantised accuracy. The same tool found activation errors well above weight errors, which makes the calibration data the first thing to check.
Local-vol PDE or Heston Monte Carlo for our exotic FX book?
Neither one wins by rule. A one-factor local-vol model is cheaper to code and compute than a two-factor model, and in one published case it met a trading desk’s needs for American and Asian options. A two-factor stochastic-local-vol model adds stochastic-volatility dynamics, at a multiple of the coding complexity and computation time. Which trade-off your book can live with is something you measure on your own barrier and Asian payoffs and your own vol-surface history.
TechnoLynx can run that comparison as a GPU Performance Engineering engagement. TechnoLynx agrees the payoff set, accuracy tolerance and intraday calibration cadence with your quants, implements an ADI PDE scheme and a Heston Monte Carlo engine with their calibration routines on your target GPUs, and reports accuracy, calibration stability and cost per quote. The first step is a short paid consultation to validate the specification.
Pricing accuracy on barrier and Asian payoffs
The published evidence below points both ways. A 2022 paper found that a fully parameterised one-factor local-vol model calibrated accurately to FX skew for American and Asian options and met its trading desk’s requirements, so the authors saw no need for a two-factor extension. A study of a four-factor FX local-stochastic-vol model found that adding stochastic rates moved a 5-year TARN price by −16.07% and a foreign no-touch by 1.35%. A 2009 comparison against indicative market prices for first-generation FX exotics measured the errors of both Dupire local vol and Heston, and found that a calibrated Vanna-Volga method could potentially beat both. The same paper warns that FX quoting conventions (there are at least four definitions of at-the-money) can corrupt the smile surface before any model sees it. Read together, these results suggest the dominant payoffs decide the answer. A book of mostly Asians and near-vanilla structures may sit comfortably inside a well-calibrated local-vol model, while long-dated barriers and no-touches are where smile dynamics show up in the price.
Calibration stability when FX vol surfaces move fast intraday
Local-vol calibration is an ill-posed inverse problem built on sparse quotes, which is why regularisation methods such as Tikhonov are used. The 2022 local-vol paper found that calibration accuracy depended mainly on how smooth the market surface was. It set two conditions for a good fit: ATM variance rising with tenor, and every 25-delta butterfly sitting between zero and the 10-delta butterfly. Heston-type models bring their own difficulty in FX. The Feller condition is often violated there, which makes the variance density singular at zero. Where the Feller condition is violated, Monte Carlo calibration promises fewer numerical problems than a finite-difference Fokker-Planck solve, and in a 2016 implementation it reached overall calibration errors of the same size as the finite-difference route. The simulation scheme matters too. A 2025 comparison timed a truncated Euler scheme at 0.0733 s against 137.9 s for backward Euler at 40 steps, though backward Euler was the more accurate and stable of the two under stress. An intraday recalibration cadence turns all of this into hard constraints. A calibration that is accurate overnight but fragile on a noisy morning surface can force a fallback or hybrid model, whichever model wins on accuracy.
Compute cost at your quote volume
Finite differences gain less from a GPU than Monte Carlo does. Klaus Spanderen’s 2013 QuantLib workshop slides put the GPU speedup for finite-difference methods at roughly 10× rather than 100×, and note that performance depends on the sparse linear algebra underneath. That is not a verdict against the PDE. The roofline paper cites Jike Chong’s port of a financial implicit-PDE solver whose working set fit in L1, where the roofline indicated no optimisation was necessary. On the Monte Carlo side, a study of a basket option on 10 FX rates under local volatility measured a 10.83× double-precision GPU speedup over an 8-core Xeon CPU, and single precision stayed stable to a relative error of 4e-7. In September 2023, STAC published STAC-A2 results for an 8-GPU H100 server on its Heston-based Monte Carlo Greeks benchmark, including a warm baseline time of 8.9 ms, figures that HPE chose to highlight.
Comparison matrix: what to measure for each approach
| Criterion | Local-vol PDE (ADI) | Heston or SLV Monte Carlo | What settles it on your book |
|---|---|---|---|
| Accuracy on exotics | Has met desk requirements for American and Asian payoffs in one published case | Captures smile dynamics that move barrier and no-touch prices | Price error against a trusted reference for your dominant payoffs |
| Calibration stability | Ill-posed inverse problem, sensitive to surface smoothness | Feller violations common in FX; Monte Carlo calibration sidesteps some PDE issues | Recalibrating across recent intraday surface snapshots |
| GPU gain | Around 10× for finite differences | Larger speedups typical for Monte Carlo | Cost per quote at your expected volume on GPUs you can afford |
The decision logic follows from the matrix. If local-vol PDE meets the accuracy tolerance on your dominant payoffs at lower cost and calibrates stably, it wins. If barriers or Asians show material mispricing from smile effects and the GPU budget can absorb the Monte Carlo cost, Heston wins. Either result holds for this book’s payoff mix and today’s volume assumptions, and both can change.
Can a three-person team build and trust this without hiring quant developers?
Yes, if the team adapts existing code before it builds anything new, and agrees a minimum validation suite before any real risk goes through the library. Adding stochastic volatility is the heavier lift. The 2022 local-vol paper notes that moving to a two-factor LSV model raises coding complexity and computation time several-fold. In the four-factor study, calibrating to the same accuracy without control variates cost more than 60 times the 2D PDE solve. That is variance-reduction engineering a small team has to own.
Adapting is a real option. QuantLib is under a modified BSD licence that allows use in proprietary applications, and its project describes firms using it as base code or as a benchmark. A Heston stochastic-local-vol Monte Carlo calibration has been published on the HPC-QuantLib blog, and a public reproducibility repository for Heston SLV barrier pricing includes PDE solvers, Monte Carlo validation routines and calibration code. The caveat is GPU support. One study accelerated QuantLib code paths with hand-written CUDA and OpenCL or directive-based ports, and an actuarial presentation notes that the C/C++ and CUDA skills involved are uncommon among actuaries.
The minimum viable validation is short, but none of it is optional:
- Reference-price comparison against closed forms or a trusted CPU implementation, with an agreed tolerance, because bitwise-identical floating-point results are not always possible.
- CPU-to-GPU parity checks that allow for fused multiply-add, reordered parallel sums and math-library differences between platforms.
- Convergence tests across paths, grid size and time steps, plus Greeks stability under small input shifts.
- Unit-level tests on device functions before they are combined into one kernel.
That suite is a floor. It does not replace ongoing model risk review, which is covered in the validation section below.
Build the pricing engine or license a vendor quant library?
Set the fully loaded cost of building against licence plus integration over the same multi-year horizon. On the build side, count the engineer-months, then maintenance and model-validation effort for the life of the platform. Build only if your requirements are narrow or bespoke enough to justify it and the team can sustain the pricing code long-term. The comparison has to be built from your own payroll and the quotes vendors give you.
Two pieces of evidence change how the sum should be read. A 2026 Milliman white paper found that, once Azure costs were included, the GPU benefit over CPUs shrank to roughly one order of magnitude, and warned that using the raw speedup may overestimate savings by an order of magnitude or more. The same paper separates “GPU code” from “efficient GPU code” and notes that the latter needs deep knowledge of the architecture. So the build side of your sum should price the optimisation work, not just the port. Buying does not remove the validation burden either. SR 11-7 expects banks to validate their own use of vendor products, often relying more on sensitivity analysis and benchmarking when the code is closed, and to keep enough knowledge in-house for a contingency if the vendor relationship ends.
What goes into each side of the cost comparison
| Cost line | Build in-house | License a vendor library |
|---|---|---|
| Up-front | Engineer-months for the pricer, calibration and GPU optimisation | Licence, integration, data feeds |
| Ongoing | Maintenance, key-person risk, extensions | Renewals, support fees, version upgrades |
| Validation | Full model documentation and independent review | Validation of your own use, plus documented customisation |
| Exit | You own the code | Contingency plan if the vendor model is no longer supported |
The decision logic: buy when the products are standard and the team lacks ongoing quant-dev capacity; build when the requirements are bespoke, integrate tightly with proprietary risk infrastructure, or give you an edge you want to keep. A hybrid is another option for a small team: license or adopt a core library and build thin custom wrappers around it. Our guide to total cost of ownership modelling for GPU infrastructure covers how to structure the hardware side of that comparison.
A treasury’s daily valuation workload differs in scale from a trading desk’s and should be sized as its own workload. TechnoLynx can benchmark a GPU-ported library or kernel, such as implied-volatility surface calibration, at treasury-representative scale to give throughput and cost per valuation run before that decision. Sizing starts from the treasury’s actual instrument count, revaluation frequency and deadline: intermittent use points to cloud rental or a vendor platform, and sustained heavy use points to owned hardware. The method for turning the numbers into a purchase is in stating defensible GPU capacity requirements before you buy.
Who can profile, port and benchmark our pricing pipeline?
TechnoLynx profiles your pricing and risk kernels on the GPUs you run or plan to buy, finds what actually limits them, and implements the fixes, from batching and data layout through to custom CUDA kernels where the profile justifies them. On a model choice, the same team builds both candidates on your hardware and measures them on your book, rather than recommending one from general experience. TechnoLynx delivers this through GPU Performance Engineering, starting with a short paid consultation that fixes the workload, payoffs and tolerances to measure. For the hardware shortlist, LynxBenchAI’s published results inform the purchase, but they do not run your pricing code.
The engagement has limits. It does not replace your model validation function: SR 11-7 expects validation by people with no stake in whether the model is approved, so TechnoLynx produces the evidence validators review, not their sign-off. A desk whose products a licensed library already covers well is better served by the licence and an internal integrator. Where the work is continuous rather than a bounded project, hiring a quant developer is a sound route. Teams looking for the cheapest hours rather than a measured outcome will not get what they want from us.
What GPU pricing model validation will our model risk team expect?
Expect the three elements named in the Federal Reserve’s 2011 SR 11-7 guidance: conceptual soundness, ongoing monitoring including benchmarking, and outcomes analysis including back-testing. Vendor models follow the same general principles as in-house ones. A 2024 review of banking validation practice and ModelOp’s summary of the guidance describe the same three-part frame. The agencies’ Revised Guidance on Model Risk Management supersedes SR 11-7. Its text keeps conceptual soundness, outcomes analysis and vendor-model validation as named expectations.
TechnoLynx can agree the backtesting method and acceptance criteria with your validators before the build, implement the model and numerical scheme on your compute platform, build the backtesting pipeline, and package the evidence and methodology documentation for independent review.
Evidence checklist for a GPU pricing library
- Conceptual soundness: the mathematical specification, numerical techniques and approximations, explained with their merits and limitations and compared with alternatives.
- Benchmarking: SR 11-7 names, as a benchmark for pricing models, alternatives that are more accurate but too slow to run daily, and says discrepancies should trigger investigation.
- Sensitivity and stress testing: small input changes that cause large output changes signal an unstable model, and extreme inputs should be tested to find where the model stops working.
- Numerical parity: GPU results checked against the CPU reference within a stated epsilon, since parallel reordering changes floating-point results.
- Out-of-sample and out-of-time testing, named in SR 26-2 as part of model testing.
- Back-testing over a period not used in development, at a frequency that matches the forecast horizon.
- Code under change control, with every change logged and auditable.
- Replication: validators reproduce the model’s logic and tests from the documentation.
Pass or fail has consequences. SR 11-7 says a model with significant deficiencies should not be used, or should be used only under tight constraints, until the issues are resolved. Our article on profiling-based validation for GPU workloads covers how to make performance claims hold up under that kind of review.
Backtesting a jump-diffusion power price model against PPA settlements
Back-testing a jump-diffusion power price model means comparing its forecasts with settlements from a period not used in development. Agree statistical adequacy and economic relevance criteria with validators before the build rather than checking them afterwards. On the statistical side, a 2016 study calibrated electricity spot models with MCMC, accepted a model only if every posterior predictive p-value exceeded 10%, and re-estimated on a second dataset to confirm the choice held. That study also found a single mean-reverting jump process inadequate for spikes, while signed sums of such processes were adequate. On the economic side, a PPA study calibrated on 2023 to 2024 and evaluated all pricing and hedging on 2025 data not used in estimation. It deliberately started estimation after the 2022 price shock. Its authors also say these are within-model results, not market validation.
PPAs have long horizons, so the SR 11-7 provision on long forecast horizons applies: back-testing should be supplemented with early-warning metrics from shortly after the model goes live. Three caveats remain. The fitting window can leave out the extremes that matter, as the 2026 study’s did by design when it excluded the 2022 shock. Validation also reviews conceptual soundness, not just statistical fit. And supervisory guidance can change mid-build, as SR 11-7’s replacement shows.
Does the kernel still hit 500 µs inside the live quoting loop?
A kernel microbenchmark alone does not answer that. The 500 µs budget belongs to the integrated pipeline under load, and it has to be shown there, at the tail of the distribution, before the co-lo upgrade goes in. Dean and Barroso (2013) showed that latency variability in individual components is magnified at the service level, and that brief high-latency episodes can dominate overall performance. An open-source tick-to-trade reference implementation shows the same effect inside one host: its queue-wait stage measured 640 ns at the median but 20 µs at p99.
TechnoLynx splits the 500 µs budget across kernel, messaging and pipeline stages, instruments the live loop, replays volatile-open bursts on the co-lo hardware and produces the tail evidence for sign-off, through GPU Performance Engineering, starting with a short paid consultation.
The replay should reach the volume EU RTS 6 sets for algorithmic trading stress tests: twice the highest message volume of the previous six months. The decision belongs to a named owner, such as the quant platform lead or the head of trading technology risk, who reviews the integration evidence and can block go-live regardless of delivery pressure. The wider method is in our piece on validating GPU kernel optimisations under production conditions.
From the profiler to the validator, one evidence trail
The artefacts that make a pricing pipeline fast are largely the ones that make it approvable. A roofline profile explains why the kernel was rewritten. A parity report shows the GPU matches the CPU reference. A comparison on your own payoffs justifies PDE over Monte Carlo, or the reverse. A back-test on data the model never saw closes the loop. Keeping these as one versioned record matches SR 11-7’s call for documentation detailed enough for unfamiliar parties. Build-versus-buy remains the one decision here that only your own payroll and vendor quotes can settle. For the wider picture of how this fits trading, risk and treasury systems, see our work on AI and GPU engineering for finance.
