The Card Trick

C.J. Marsden

There is a slide in every actuarial modelling pitch now. It has a picture of a graphics card on it, and somewhere near the card there is a number. The number is usually a hundred. A hundred times faster. Sometimes the deck is honest enough to footnote where the hundred came from — a gaming benchmark, a graphics-rendering throughput figure, a machine-learning training run — and sometimes it isn't, but it rarely matters, because nobody in the room is reading the footnote. The number has already done its work. The chief actuary nods. The chief risk officer, who once heard that the bank down the road moved its risk engine onto GPUs, nods harder. And the procurement form acquires a tick in a box marked GPU-accelerated, which it will keep forever, regardless of whether a single one of the firm's regulatory runs ever touches a graphics card again.

This is a card trick in both senses. There is a card, and there is a trick, and the trick is that the thing being sold and the thing being delivered are two different objects that happen to share a name.

Let me be precise about the accusation, because the vendors have a habit of retreating into precision when challenged and I would rather meet them there. I am not saying the software cannot use a GPU. It can. FIS will tell you, correctly, that Prophet's vectorised framework runs on GPU as well as on AVX-enabled CPUs, with tooling to manage the card's memory and let you tune batch sizes. Moody's will tell you something similar about AXIS. These statements are true. The capability is real. What is not true — what is never quite said, but is everywhere implied — is that this capability bears on the calculation that is actually keeping your reporting team in the office until midnight. It does not. The marketing describes one scope. The engineering describes another. They overlap almost nowhere that counts, and the entire commercial proposition depends on you not noticing the gap.

The borrowed number

Start with the hundred, because it is the most easily dismantled part of the trick.

The headline speedups quoted in this market are not measured on insurance liabilities. They are imported wholesale from graphics and from machine learning, two workloads that share a defining property: they are dense, regular arithmetic performed in low precision. A GPU built to render a modern game is moving through tens of trillions of operations a second, but those operations are single-precision, or half-precision, or lower — the kind of arithmetic where an error in the eighth decimal place is a slightly wrong shade of green and nobody dies. Machine learning is the same. Half-precision is not a compromise there; it is a feature.

Regulated reserving does not live in that world. A best-estimate liability, a technical provision, a CSM roll-forward that has to reconcile to the penny across reporting periods and survive an auditor and a regulator — that work runs in double precision, because it has to, because the whole point is that the number is correct and reproducible. And here is the inconvenient fact the slide omits: the consumer graphics cards from which the hundred-times figure is borrowed deliberately cripple double-precision arithmetic, frequently to a thirty-second or a sixty-fourth of their single-precision rate. The headline number is a measurement of exactly the precision your valuation is not allowed to use. The data-centre cards that restore double precision exist, but they are priced accordingly, and the moment you put their real fp64 throughput next to a grid of CPU cores doing the same honest arithmetic, the hundred shrinks to something you would be embarrassed to print.

I have watched an actuary stand at a podium and justify GPU adoption with a slide quoting the calculations-per-second a graphics card needs to render a video game. The figure was genuinely staggering and entirely beside the point. It was a number about pixels, deployed to sell a claim about reserves, and not one person asked why those two quantities should have anything to do with one another.

The wrong bottleneck

The deeper problem is not the precision. It is that the GPU is the wrong tool for the shape of the work, and no amount of cores will fix a shape mismatch.

A seriatim liability projection is not dense regular arithmetic. It is a long, branching, sequential march. You take a policy, and you walk it forward month by month for decades, and at every step you ask questions: is it still in force, has the guarantee bitten, is the policyholder lapsing, and if so are they lapsing more because the guarantee is now in the money. This is control flow — conditionals stacked on conditionals — and a GPU despises control flow. Its arithmetic units are yoked together in lockstep; when the policies in a batch want to take different branches, the hardware cannot let them, and it serialises, processing each path in turn while the others idle. The very thing that makes a liability model a liability model is the thing that empties a GPU of its advantage.

Then there is time. A reserve next month depends on the reserve this month. A CSM depends on its own previous value. You cannot project year twenty before you have projected year nineteen; the calculation is inescapably sequential along its longest axis. The only parallelism genuinely available is across policies and across scenarios — run a thousand model points at once, run a thousand economic paths at once — and that is real, and it is worth having. But it is also precisely the parallelism that a CPU grid already harvests, cheaply, and very nearly linearly. The honest comparison was never the GPU against a single labouring processor. It was the GPU against a grid that has been splitting work across cores for twenty years and can rent ten thousand more by lunchtime. Against that baseline, on this workload, the card has very little left to offer.

And the work is memory-bound besides. Marching policy records and looking up mortality, lapse and economic tables is mostly moving data, not crunching it. The GPU's enormous arithmetic capacity sits waiting on memory it cannot feed fast enough. You are buying a racing engine and using it to tow.

The tell: the vendors know

If all of this were merely my opinion against the brochure, you could reasonably discount it. It is not. The most damning evidence comes from the vendors themselves, who, the moment they step out of the marketing department and into a technical interview, say exactly what I have just said.

FIS's own product lead for insurance risk has gone on the record to the trade press making the point that comparing GPUs and CPUs on raw speed misses the picture entirely — what matters is which tool delivers the needed speed at the lowest cost — and to observe, almost as an aside, that you can usually just make a run go faster by adding more CPU cores. Read that again. The man selling you the GPU is telling you that the CPU grid you already own will probably get you there. Elsewhere in the same coverage, a practitioner notes that GPU code is brutally hard to debug, a specialism unto itself — which, for a model you must explain line by line to a regulator, is not a minor inconvenience but a governance liability.

The clinching tell is what the vendors actually sell when a client says my run is too slow. They do not say put it on a GPU. They reach, every time, for a different basket: proxy functions that replace the heavy stochastic calculation with a fitted approximation, clustering and compression to throw away redundant policies and scenarios, and elastic CPU grids spun up across thousands of cloud cores on demand. Moody's flagship answer to runtime is a suite of compression and proxy tools and a grid-in-the-cloud service running on Azure. If the GPU were the hundred-times miracle the front of the deck implies, none of this would exist. You do not build an elaborate apparatus for avoiding a calculation you can run a hundred times faster. The runtime tooling the vendors are genuinely proud of is a standing, unspoken admission that the GPU does not solve the problem the brochure says it solves.

So why is the card on the slide?

Because the slide was never aimed at the actuary.

The GPU line is aimed at the board, and at procurement, and at the part of a chief risk officer that wants to be told the firm is modern. It is a signal, not a specification. Its function is to place a tick in a column and a reassuring image in a deck, and it performs that function whether or not the technology is ever load-bearing. The capability is real — and there are corners of actuarial work where a GPU genuinely earns its keep: scenario generation, the dense inner loops of certain nested-stochastic problems, the fitting of proxy models, the machine-learning emulators that are quietly doing more of the heavy lifting every year. A precise, modest claim about those workloads would be entirely defensible. But a precise modest claim does not sell, so the brochure offers an imprecise enormous one and trusts the buyer to generalise it to the overnight valuation it will never touch.

What allows the trick to keep working is that nobody checks. There is no independent benchmark, published by anyone without a licence to sell, of double-precision GPU throughput on a real liability model against an equivalently-priced CPU grid. The profession that prides itself on not taking numbers on faith takes this number on faith, because the number flatters the same modernity everyone in the room already wants to believe in. We audit the firm's reserves to the penny and accept the vendor's FLOPS without a receipt.

So the next time the card appears on the slide, ask three questions, and watch the room. Which specific calculations run on the GPU — name them. What is the double-precision throughput, not the single-precision headline. And is the run that is actually hurting you one of those calculations, or is it the branching, recursive, memory-bound projection that will sit exactly as slow as it does today no matter how many graphics cards you bolt to it. The answers, if you can extract them, will tell you everything the hundred was put on the slide to stop you asking.

It is a good trick. It has worked on cleverer audiences than you would think. But it is still a trick, and the tell is that the people performing it stop performing the moment you get them off the stage.