Not every optimization problem belongs on a GPU. Small, simple factor models can be solved well on CPU. The boundary appears when the workflow expands: larger universes, transition scenarios, lot-aware accounts, risk mappings, and repeated re-optimization under changing inputs.
That boundary is where PRISM is designed to operate. It is not a single solver claim. It is a routed stack: CPU where CPU is enough, GPU where scale and repeated work justify it, and discrete refinement where the problem has hard combinatorial edges.
Figure 1: GPU usefulness grows with workflow pressure
The GPU boundary is operational, not ideological
The question is not whether a GPU is faster in isolation. The question is whether GPU-native optimization lets the business run a workflow that CPU-only systems would force into overnight windows, smaller universes, or reduced scenario sets.
PRISM's public evidence is framed around this distinction: corrected cold-start evidence, repeated-run 5,000-asset transition results, 82,103 real-asset GPU proof, and a 100,004-asset structured suite. Different results answer different operational questions.
Figure 2: Routed execution model
GPU-native means the workflow can be redesigned
Once solves are fast enough, a platform can run more what-if analysis, harvest tax losses more frequently, rebalance batches inside tighter windows, and compare transition paths before trading. Speed is not the final product. Speed is the thing that makes the better product possible.
Practical next step: list the analyses your current solver prevents because they are too slow. That list is usually more important than a generic benchmark table.