A price elasticity model estimates how demand responds to a price change. That definition is uncontroversial, and it is also the reason so many pricing pipelines end up over-provisioned: it describes one regression, while the thing a pricing team actually runs is a few thousand of them, plus a scenario sweep over candidate price grids on top.
The gap between those two mental models is where compute budgets go to die. If you think of elasticity as one model fit, then a refresh that takes eleven hours instead of six looks like a hardware problem — the data grew, so buy more machine. If you think of it as a repeated dense-and-sparse linear-algebra workload, the same slowdown looks like something you should measure before you spend anything.
This article stays on the engineering side of that line. We will define the model class precisely enough to reason about its compute shape, then treat the estimation and simulation pipeline as the object to be profiled. Econometric specification — which controls, which functional form, which segmentation — belongs to the people who own the pricing decision. What we take responsibility for is whether their pipeline finishes before the decision window closes.
What is a price elasticity model, and what does it actually compute?
Own-price elasticity is the percentage change in quantity demanded for a one-percent change in price. In practice it is estimated, not observed: a log-log demand specification regresses log quantity on log price plus controls for promotion, seasonality, competitor price, channel, and inventory state. The coefficient on log price is the elasticity. Cross-price elasticities come from the same design matrix with the competitor or substitute price terms retained.
Pricing teams use those coefficients in two ways, and the second one dominates the compute bill.
The first use is descriptive: which products are price-sensitive, which are not, where margin can be taken without volume loss. That is a read of the fitted coefficients.
The second use is prescriptive: given the elasticity surface, simulate demand and margin under a grid of candidate prices, subject to constraints — price ladders, competitor gaps, minimum-margin floors, cannibalisation between own SKUs. This is a scenario sweep. Every point on the grid is an evaluation of the fitted model, and the grid is combinatorial across the SKUs whose prices move together.
So the workload has two stages with different arithmetic character. Estimation is many small-to-medium solves. Simulation is a large number of cheap evaluations that become expensive purely through count.
Why the “one pooled regression” framing breaks
The naive pipeline fits one model on pooled historical transactions and calls the result the elasticity. It fails for reasons that are statistical first and computational second.
Elasticity is not a property of a business; it is a property of a product in a segment at a point in time. Pooling across a catalogue produces an average that is wrong nearly everywhere — a staple and a discretionary item in the same fit drag each other toward a meaningless middle. So teams segment: by category, by store cluster, by customer tier, by season. Each segment gets its own fit.
Segmentation immediately creates a data-sparsity problem. Narrow segments have few price changes, and elasticity is identified by price variation. Unregularised least squares on a thin segment produces coefficients with signs that are economically impossible. The standard responses — ridge or elastic-net shrinkage, hierarchical models that shrink segment coefficients toward a category prior, Bayesian estimation with informative priors — all replace one closed-form solve with either a regularisation path across candidate penalties or an iterative sampler.
Add the design-matrix structure. Fixed effects for SKU, store, and week are one-hot encodings; a catalogue-scale design matrix is overwhelmingly zeros. Treated as dense, it consumes memory and FLOPs proportional to a matrix that is mostly nothing.
The result is a workload profile that looks nothing like “a regression”:
- Hundreds to tens of thousands of independent segment-level estimations, each modest in size
- A hyperparameter or penalty path per segment, multiplying that count by a small integer
- Design matrices that are structurally sparse in the fixed-effect blocks and dense in the continuous-control blocks
- A scenario sweep whose cost scales with the price grid, not with the data
- A hard wall-clock deadline set by a pricing committee, not by a scheduler
That last item is what makes this an engineering problem rather than an academic one. The workload is embarrassingly parallel in one dimension and serially dependent in another, running against a fixed clock.
Where the compute actually sits
Mapping the stages to hardware behaviour is what makes the bottleneck legible. The pattern below is what we typically see when we instrument an elasticity pipeline; the exact proportions vary with catalogue size and specification (observed pattern across GPU-throughput engagements, not a benchmarked distribution).
| Pipeline stage | Arithmetic character | Usual limiter | What to look at first |
|---|---|---|---|
| Feature and design-matrix construction | Data movement, joins, one-hot expansion | Host memory bandwidth, PCIe transfer | Whether dense one-hot blocks are being materialised at all |
| Normal-equations / Gram matrix formation | Sparse-dense matrix product | Sparse routing and format choice (CSR vs blocked) | Whether a sparse block is being handled by a dense kernel |
| Solve / factorisation per segment | Dense linear algebra, small matrices | Kernel launch overhead, tensor-core occupancy | Batched solves vs one launch per segment |
| Regularisation path | Repeated solves over penalty grid | Same as above, multiplied | Warm starts and path reuse |
| Iterative / MCMC estimation, where used | Long serial chains | Latency, not throughput | Chain-level parallelism across segments |
| Scenario sweep over price grid | Very many cheap evaluations, GEMM-shaped | Memory-bound if batched badly, otherwise compute | Batch geometry and precision |
| Constraint evaluation and ranking | Branchy, low arithmetic intensity | Serialisation on CPU | Whether it belongs on the device at all |
Two observations from that table are worth stating plainly.
The most common single defect is thousands of tiny GPU launches where one batched call belongs. Segment-level solves are individually too small to saturate a modern accelerator. Launched one at a time from a Python loop, the device spends most of its time idle between kernels, and utilisation graphs look busy while throughput is dismal. Batched dense routines — cuBLAS batched GEMM and batched factorisation, or a torch.compile-fused equivalent — collapse that overhead. This is the same class of finding described in our note on profiling before procurement in GPU-accelerated workloads, and it recurs across finance pipelines that share the many-small-models shape, including the segmented estimation stacks behind probability of default credit-risk models.
The second is format mismatch. A design matrix that is 95% zeros, handed to a dense GEMM, wastes almost all of its arithmetic. cuSPARSE and equivalent sparse paths exist for exactly this, but the routing decision is often implicit — a library densifies silently, and nothing in the logs says so. Checking whether the sparse blocks stay sparse through the Gram-matrix formation is a five-minute inspection that regularly recovers a large multiple, not a percentage.
How do you tell whether a slow elasticity refresh is capacity-bound or inefficiency-bound?
This is the decision that determines whether money gets spent. Run it as a checklist before a procurement conversation, not after.
Diagnostic checklist — capacity vs inefficiency
- Achieved occupancy during the estimation stage. If the device is idle a large fraction of wall-clock time while the job is “running”, the constraint is launch pattern, not capacity. Low occupancy plus high apparent utilisation is the signature.
- Tensor-core utilisation in the dense solve steps. If the solves run in FP32 on general-purpose units while the hardware has tensor cores sitting unused, there is headroom that no purchase is needed to unlock. Mixed precision in the solve path is a specification question worth asking — but it is asked, not assumed.
- Sparse-path confirmation. Instrument the Gram-matrix formation and confirm the sparse blocks are handled by sparse kernels. A densification is a correctness-preserving, throughput-destroying default.
- Batch geometry in the scenario sweep. Evaluate whether the price grid is being swept as one large batched operation or as a nested loop. Nested loops here are the most common cause of a sweep that scales worse than the grid.
- Host-device transfer share. Measure the fraction of wall-clock time spent moving design matrices across PCIe. If feature construction is on the host and estimation on the device, transfer can dominate everything else.
- Multi-GPU scheduling across independent segments. Segment fits are independent. If a second and third device are installed and idle during the refresh, the pipeline has a scheduling gap, not a capacity gap.
- Only if 1–6 are clean: the workload is genuinely capacity-bound. Now the question is how much hardware, and that answer is defensible.
The point of the ordering is that steps 1 through 6 cost engineering time and no capital, while step 7 costs capital. Reversing the order is how organisations end up with a larger cluster running the same inefficient pipeline, and a refresh that is faster by less than the invoice implied.
Worked example: scenarios per decision window
Assumptions stated explicitly, because the numbers are illustrative arithmetic rather than a measurement of any particular client system.
Suppose a retail pricing team has a six-hour Monday-morning window between data cutoff and the pricing committee. Their pipeline must complete a segment-level elasticity refresh and then sweep candidate prices.
- 4,000 segments, each with a 5-point regularisation path → 20,000 solves
- Solves launched individually, averaging 40 ms of wall-clock each including launch and transfer overhead → roughly 13 hours of estimation alone
The refresh misses the window before the sweep starts. The naive read is that 4,000 segments needs more hardware.
Now change only the launch pattern. If batching the solves into groups of 256 brings effective per-solve wall-clock into the low single-digit milliseconds — the kind of shift batched dense routines produce when the individual problems are small — estimation lands inside roughly an hour, and five hours of the window remain for the sweep. At, say, 30 ms per fully batched scenario evaluation, that residual window admits a scenario count in the hundreds of thousands rather than the low thousands.
The commercial framing that matters is not “the job got faster.” It is more scenarios evaluated per decision cycle, on hardware already paid for. A pricing team that can test cannibalisation across a whole category, rather than sampling a handful of price points, makes a different quality of decision. That is the ROI, and it is measurable in scenarios-per-window, which is a number the pricing lead already cares about.
Which parts are ours, and which are yours
This boundary is worth being explicit about, because blurring it produces bad work in both directions.
| Question | Owner | Why |
|---|---|---|
| Which functional form (log-log, semi-log, discrete choice) | Client | Identification and interpretation depend on domain and data-generating process |
| Segmentation scheme | Client | Reflects commercial structure and merchandising judgement |
| Which controls and instruments address endogeneity | Client | Econometric validity, not throughput |
| Regularisation strength and priors | Client, informed by us | Statistical choice; we surface the compute cost of each option |
| Whether the sparse blocks stay sparse | Us | Kernel-level routing |
| Batch geometry and launch pattern | Us | Throughput engineering |
| Precision in the solve path | Joint | We identify the headroom; the client rules on numerical acceptability |
| Multi-GPU scheduling across segments | Us | Systems work |
| Whether to buy hardware | Client, after our measurement | The measurement makes the decision defensible either way |
We do not tell pricing teams what their elasticities are. We make it possible for them to estimate more of them, more often, and to test more scenarios against them, without a procurement cycle in between. The same division applies across the finance workloads we touch — the modelling judgement stays with the domain owner, whether the pipeline is elasticity estimation, cash-flow forecasting, or a latency-bound execution path.
FAQ
What is a price elasticity model, and how is it used in financial pricing decisions?
A price elasticity model estimates the percentage change in demand associated with a one-percent change in price, typically from a log-log demand specification with controls for promotion, seasonality, competitor price and channel. Pricing teams read the fitted coefficients descriptively to see which products tolerate price increases, and then use them prescriptively to simulate demand and margin across a grid of candidate prices under constraints. The second use is where the compute cost concentrates.
What distinguishes a single pooled elasticity regression from the segmented, regularised estimation families pricing teams actually run?
Elasticity is a property of a product in a segment at a point in time, so pooling across a catalogue averages away the signal. Real pipelines fit hundreds to tens of thousands of segment-level models, and because narrow segments have little price variation, those fits need ridge, elastic-net, hierarchical shrinkage or Bayesian priors. Each of those replaces one closed-form solve with a regularisation path or an iterative sampler, multiplying the model count by a further factor.
What does the compute profile of an elasticity modelling pipeline look like?
Design-matrix construction is data-movement bound; Gram-matrix formation is a sparse-dense product whose cost depends entirely on whether the fixed-effect blocks stay sparse; the per-segment solves are small dense linear algebra dominated by launch overhead unless batched; and the scenario sweep is GEMM-shaped work that scales with the price grid rather than the data. Constraint evaluation and ranking is branchy, low-intensity work that often does not belong on the accelerator at all.
How do you tell whether a slow elasticity refresh or price-grid sweep is bound by hardware capacity or by kernel-level inefficiency?
Work through six no-capital checks first: achieved occupancy during estimation, tensor-core utilisation in the dense solves, confirmation that sparse blocks are not being silently densified, batch geometry in the sweep, host-device transfer share, and whether installed GPUs sit idle while independent segment fits queue. Only when all six are clean is the workload genuinely capacity-bound — and at that point the sizing question has a defensible answer.
Where do sparse-matrix routing, tensor-core utilisation and multi-GPU scheduling recover the most throughput?
Sparse routing pays off most in Gram-matrix formation, where one-hot fixed-effect blocks are overwhelmingly zeros and a dense kernel wastes nearly all its arithmetic. Tensor-core utilisation matters in the batched dense solve and in the scenario sweep, both of which are GEMM-shaped. Multi-GPU scheduling pays off in the estimation stage specifically, because segment fits are independent and therefore trivially distributable — which is also why idle secondary devices during a refresh are such a reliable tell.
How many candidate price scenarios can realistically be evaluated inside a fixed pricing decision window on existing hardware?
That depends on grid geometry, model complexity and how much of the window the refresh consumes, so the honest answer is that it must be measured rather than quoted. What we can say is that the count is usually governed by launch pattern and batch geometry rather than by device count, which means the achievable number on installed hardware is often one or two orders of magnitude above what the current pipeline delivers.
Which parts of elasticity work are econometric decisions the client owns, and which are compute-engineering problems?
Functional form, segmentation scheme, endogeneity controls, and the acceptability of reduced precision in the solve path are the client’s calls — they determine whether the estimates mean anything. Sparse-path routing, batch geometry, launch patterns, and multi-GPU scheduling are throughput engineering and can be measured and fixed without touching the specification. The procurement decision sits at the boundary: the client makes it, but only after the measurement exists.
The number to put in front of the pricing committee
If there is one metric to standardise on, make it scenarios completed per decision window, on the hardware currently installed. It is a single number, the pricing lead already understands it, and it moves for both of the reasons that matter — better engineering and more capacity — which means it can be used to distinguish between them.
Before the next capacity request, run the six checks above and see which of them come back clean. When a refresh or sweep misses its window, that is exactly what a GPU performance audit is for: establishing, with measurement rather than inference, whether the constraint is the machine or the code that runs on it.
