Monte Carlo simulation is LLM decode at the batch level, and the quant world solved the hardware a decade before AI needed it.

The quant finance world solved the hardware acceleration problem for sequential-but-parallel stochastic simulation years before the AI world needed to. The architectures are now converging.

I want to trace this precisely because the connection runs deeper than "both use GPUs." The compute patterns are structurally identical. The hardware solutions are structurally identical. And the kernel optimizations that the AI infrastructure world spent 2023-2026 developing map one-to-one onto techniques the HFT world developed in 2010-2020 under harder latency constraints.

---

The shared compute pattern.

Monte Carlo simulation in quantitative finance: you have N independent paths through a stochastic differential equation. Each path is a Markov chain -- step T+1 depends on step T and a random draw, but nothing before T. Paths are independent of each other. You run all N paths simultaneously, collect the terminal values, compute the expectation. This is embarrassingly parallel across paths, strictly sequential within each path.

LLM decoding: you have a batch of B requests. Each request is a sequence of tokens. Token T+1 is generated from the model's state at token T (via the KV cache). Requests are independent of each other. You run all B requests simultaneously in a batch, generate the next token for each. This is embarrassingly parallel across requests, strictly sequential within each request.

These are the same computational structure. Large-scale parallel Markov chains, independent paths, sequential within path, parallel across paths. The 2019 paper "Tensor Processing Units for Financial Monte Carlo" (arXiv:1906.02818) was the first to state this explicitly: "We highlight the computational similarity between training neural networks with SGD and simulating stochastic processes." It was right. The similarity runs deeper than they realized -- not just training, but inference.

The TPU/GPU hardware that was designed for the matrix operations in neural network inference is the right hardware for financial Monte Carlo for the same mathematical reason. Correlated stochastic paths need large matrix-matrix operations at each step (updating the full covariance structure of a high-dimensional portfolio). LLM decode needs large matrix-vector operations at each step (multiplying the weight matrices against one token's hidden state). The difference -- matrix-matrix versus matrix-vector -- is the small-batch vs large-batch distinction, the same tradeoff that shows up in the memory-bandwidth-bound vs compute-bound analysis of decode.

---

The HFT latency split and the PD disaggregation pattern.

HFT firms have been running a specific hardware architecture for over a decade: FPGA for the fast, deterministic, nanosecond path; GPU for the slower, ML-intensive, millisecond path. This split is not arbitrary -- it reflects a physical constraint that the AI world is now encountering from a different direction.

The FPGA path: market data arrives from the exchange co-location feed. The FPGA parses the FIX protocol (14 nanoseconds in the current state of the art), updates the order book (deterministic, nanoseconds), runs pre-trade risk checks (deterministic, nanoseconds), and fires the order. The end-to-end tick-to-trade is sub-500 nanoseconds. This is possible because FPGAs are reconfigurable logic -- they implement the algorithm directly in hardware, with no operating system, no kernel networking stack, no context switches, no jitter. Identical latency on every cycle.

The GPU path: a more complex ML signal -- "predict alpha from order book microstructure features" -- runs on a GPU with TensorRT inference. Latency is under 1 millisecond, acceptable for the ML signal because the FPGA fast path already handles the latency-critical execution. The GPU is the high-capacity slow path.

The AI inference disaggregation pattern (PD disaggregation): prefill is compute-bound, latency-tolerant, high-parallelism -- runs on compute-optimized hardware. Decode is memory-bandwidth-bound, latency-sensitive, sequential -- runs on memory-optimized hardware. The fast path (decode, first-token latency) and the slow path (prefill throughput) run on different hardware with different optimization targets.

The structural isomorphism: HFT FPGA (deterministic fast path) plus GPU (ML slow path) equals PD disaggregation prefill (throughput slow path) plus decode (latency fast path). Both architectures split the workload at the point where the latency/throughput tradeoff becomes a hardware design decision rather than a software tuning decision.

The AFD architecture (NVIDIA's Attention-FFN Disaggregation with Groq LPX) is the AI world's version of the same split applied one level lower: within the model, attention (memory-capacity-bound, needs HBM) and FFN (memory-bandwidth-bound, needs SRAM) run on different hardware. The HFT world did this same split at the workload level (order execution vs signal computation) fifteen years earlier.

---

The kernel-level techniques that transferred.

DPDK (Data Plane Development Kit) is a kernel-bypass networking library that HFT and cloud providers developed to eliminate the Linux networking stack overhead. Instead of: NIC receives packet, kernel copies to user space (50-1000 CPU cycles overhead per context switch), application processes it, DPDK does: NIC DMA-copies directly to user-space memory mapped ring buffer, application polls the ring buffer directly. Zero kernel involvement. Zero context switches. Deterministic.

GPUDirect RDMA is the AI infrastructure equivalent: instead of GPU to PCIe to host CPU memory to host DRAM to NIC to network, GPUDirect does GPU HBM straight to NIC to network. Zero CPU involvement. The NIC DMA-copies directly from GPU memory. The connection: both techniques bypass the OS for data movement because the OS overhead was the latency bottleneck. The insight and the technique are identical; the workload differs.

Lock-free data structures in HFT: order books are updated millions of times per second. Mutex-protected updates add microseconds of latency. The solution: lock-free queues (SPSC: single-producer single-consumer ring buffers with atomic compare-and-swap), lock-free hash maps, seqlock-based order books where readers don't acquire a lock but detect concurrent writes and retry. HFT engineers spent a decade developing and deploying these at production scale.

vLLM's continuous batching scheduler: adding requests to an active batch without pausing decode. The scheduler maintains a token queue and request state without locks on the hot path. The same lock-free design principles -- minimize atomic operations, use seqlock-style patterns for state that's read much more than written -- apply to both. The AI serving community is rediscovering techniques the HFT community published in the 2010s.

---

JaxMARL-HFT: the convergence made explicit.

A 2026 paper trained multi-agent RL agents on a year's worth of Limit Order Book data -- 400 million orders -- using JAX with XLA compilation. The result: 240x reduction in training time compared to PyTorch implementations on equivalent hardware.

The reason JAX achieves 240x: XLA (Accelerated Linear Algebra) compiles the LOB simulation into a static computational graph that the TPU-style accelerator can execute without Python interpreter overhead, without dynamic dispatch, without host-device synchronization on every step. The entire LOB simulation runs inside the compiled XLA graph. The full year of order data is batched across the simulation trajectories and executed in one fused kernel.

This is exactly what torch.compile and CUDA graph capture do for LLM inference: eliminate Python interpreter overhead, fuse kernel launches, minimize host-device synchronization. The 240x improvement in JaxMARL-HFT is the same class of improvement as the 2-3x improvement from CUDA graph capture in LLM serving -- compiler optimization eliminating per-step framework overhead.

The deeper point: JAX's functional programming model (pure functions, no side effects, explicit state threading) is better suited for sequential-but-parallel simulation than PyTorch's imperative model. Financial Monte Carlo is a pure functional operation -- given the initial state and the random draws, the terminal state is deterministic. LLM decode is almost a pure functional operation -- given the KV cache and the input tokens, the output distribution is deterministic. JAX's model fits both workloads naturally.

The AI world is slowly converging on the same realization. torch.compile is an approximation of XLA for PyTorch. The reason it requires whole-graph capture and static shapes to achieve peak performance is that it needs the same purity assumptions JAX enforces by design. The HFT/quant community has been writing JAX (functionally) for financial simulation for years. The AI community is arriving at the same programming model through performance pressure.

---

The specific kernel optimization connection: register-level computation.

At the lowest level, the kernel optimizations that matter in finance and AI are the same operations on the same hardware.

In HFT FPGA design, the "register-level" computation means implementing the trading algorithm directly in the FPGA's reconfigurable logic, bypassing the memory hierarchy entirely. The order book delta, the pre-trade risk computation, the order placement logic -- all of it executes in the FPGA's fabric with nanosecond-scale pipelining. The memory hierarchy (DRAM, cache, registers) is largely irrelevant because the algorithm fits in the logic fabric.

In GPU kernel design, register tiling means keeping hot intermediate values in registers rather than shared memory or HBM. The analogous goal: minimize trips through the memory hierarchy for the values that are accessed most frequently. FlashAttention's core contribution is keeping the softmax numerator and denominator in registers across KV block iterations, avoiding HBM round-trips for the accumulator state. The FA4 advance on Blackwell was moving the accumulator to TMEM (on-chip tensor memory), further reducing register pressure.

The FPGA implements its fast path entirely in logic fabric (analogous to registers). The GPU implements its hot path in TMEM/registers/shared memory. Both are trying to eliminate the memory hierarchy for the most latency-sensitive computation. The optimization philosophy is identical; the hardware primitives differ.

WaveTune (arXiv:2604.10187, April 2026) makes this connection explicit from the other direction: it models GPU kernel performance using "wave-aware bilinear modeling" -- the same class of analytical performance model that HFT engineers use for FPGA pipeline throughput analysis. In FPGA design, you analyze the throughput of each pipeline stage and identify the critical path (the slowest stage that limits overall throughput). WaveTune applies this pipeline analysis to GPU thread block waves, modeling which wave configuration maximizes utilization on specific GPU microarchitectures. The analytical technique is FPGA pipeline analysis adapted for GPU wave scheduling.

---

The regulatory and compliance angle that the AI world is about to need.

One thing the quant world developed that the AI world hasn't built yet: hardware-level auditability. Every order fired from an FPGA must be attributable, timestamped with nanosecond precision, and logged in a format that regulators can audit. The FPGA includes dedicated logic for this -- a timestamping engine that tags every order with the hardware clock reading at the moment of execution. Not a software timestamp. A hardware timestamp from the FPGA's deterministic clock.

AI agentic systems are accumulating regulatory requirements that will eventually demand the same. What action did the agent take? At what precise time? In what system state? Logs produced by software running on CPU have non-deterministic timing. An eBPF-based observability layer (which I wrote about separately) provides kernel-level timestamps. The FPGA-timestamped audit trail is the more precise version of the same idea -- hardware-enforced auditability.

The firms that built this for HFT in 2012 are the firms that will be most prepared to offer it as a service for AI compliance in 2027.

---

Monte Carlo simulation is LLM decode at the batch level.

HFT's FPGA+GPU split is PD disaggregation at the workload level.

DPDK kernel bypass is GPUDirect RDMA at the networking level.

JAX XLA compilation is torch.compile at the optimizer level.

The quant world developed all of these under harder constraints, a decade earlier.

The convergence is happening at the hardware level -- the same silicon, optimized for the same matrix operations, running the same class of computation for different applications.

the kernel engineer who came from quant finance has a decade of solved problems in their head that the ai infrastructure engineer is re-solving right now. wave quantization analysis, pipeline stage throughput modeling, lock-free data structures at production scale, kernel-bypass data movement -- the technique library transfers completely. the workload changes. the math doesn't.

---

P.S. AMD's Versal AI Core series integrates both FPGA logic fabric and AI engine arrays (vector processor arrays similar to small tensor cores) on the same die. HFT firms are evaluating it for the next generation of their fast-path plus ML-path split, because the inter-die communication overhead between the current FPGA and GPU setup (even with NVLink) adds latency. Versal eliminates the inter-chip hop for ML inference that follows the FPGA decision. The same motivating principle as AFD (eliminating the inter-chip hop between attention and FFN computation) applied to HFT's FPGA+ML hybrid architecture. When a chip family designed for HFT and AI systems engineering makes the same design decision, it's worth asking why -- and the answer in both cases is that the inter-chip communication bottleneck has the same mathematical structure regardless of the workload.