Post-quantum TLS acceleration — instrumented cost model
Experiment plan · methodology · measurement set

Post-quantum TLS acceleration

Isolating the contribution of Intel QAT, AVX-512 and GPU batching to TLS 1.3 handshake rate. Pick an arm, watch which engine performs each operation, and edit the per-operation costs to match your own measurements.

Draft
2026-08-18
Phase
P0 bring-up
Lattice build
{{ buildLabel }}

Every cost on this page is a placeholder. Order-of-magnitude figures for a modern server core, not measurements from your platform. The page exists to hold measured values once phase P1 produces them, and MUST NOT be quoted as a source of results.

Configuration matrix · five arms, adjacent arms differ by one variable

Modelled result

{{ m.k }}
{{ m.v }} {{ m.u }}

Where the work actually lands

The accelerator has no lattice datapath, so the split is fixed by architecture before any tuning begins.

Drag to orbit · {{ armId }} · {{ activeEngineLabel }}
{{ e.name }} {{ e.note }} {{ e.share }}

ML-KEM and ML-DSA need small-modulus number theoretic transforms and Keccak sampling; the accelerator public-key unit cannot express them. Lattice work therefore stays on the core, or moves to the GPU, in every arm.

One handshake, in wall-clock time

Core time occupies the CPU. Device time runs on the accelerator and does not. Offload gain is reclaimed core time, not magic.

Operation
0 µs{{ halfLatency }} µs{{ latency }} µs — first byte
core + dev
{{ s.label }}
{{ s.timeText }}
Core occupancy
core busy {{ occCorePct }}% of the {{ latency }} µs handshake · {{ devTotal }} µs runs on devices, off the core

{{ narration }}

Per-step table for {{ armId }}
Every figure in the graphics above, as text.
Step Engine Core µs Device µs
{{ s.label }} {{ s.engName }} {{ s.coreText }} {{ s.devText }}

Four questions, four arm pairs

Each question maps to exactly one pair of arms differing by one variable. An arm that answers none of them is cut from the matrix.

{{ q.n }}
{{ q.title }}
{{ q.body }}
{{ q.value }}
{{ q.metric }}

All configurations compared

Handshakes per second, per core
{{ r.id }} {{ r.cps }} {{ r.delta }}
Hairline marks the A1 classical baseline. Click a row to load that arm into the timeline and the floorplan. D1 is reported separately in the plan because it changes the latency contract.
Transition cost, then what the accelerator gives back
{{ w.value }}
{{ w.id }}
{{ w.note }}

The GPU arm is a latency experiment

Throughput on the accelerator is not the question. The queue in front of it is. Batched lattice operations only reach their published rates at large batch sizes, and a TLS terminator must hold connections until a batch fills.

Modelled p99 handshake latency and handshake rate against GPU batch size The pass band is the range of batch sizes where modelled throughput exceeds arm B2 and p99 latency does not. Values are listed beside the chart. pass band p99 budget · B2 + 10% = {{ curve.baseP99 }} µs batch size {{ t.label }} — p99 latency, log scale -- handshake rate
{{ b.k }} {{ b.v }} {{ b.u }}
{{ verdict }}
{{ verdictNote }}

Moving this slider rewrites the batch fill wait in the cost model, so arm D1 changes everywhere on the page. The arm passes only if a batch size exists where throughput rises and p99 does not.

One handshake, five instrumented layers

A regression is only attributable if the same request is observable at every layer it touches. Run the timeline above and watch which layers the current operation reaches.

{{ l.name }}
{{ l.counters }}
{{ l.tool }}

Run protocol, validity controls, phases

{{ p.n }} {{ p.title }}
{{ p.body }}
Validity controls · checked per run
✓ {{ v.title }} {{ v.body }}
Phases
P{{ p.n }}
{{ p.title }}
{{ p.body }}
A result without its run manifest is not a result and is not reported.

Cost model · placeholders, shipped to be overwritten

Edit any value. Every graphic and figure on this page recomputes immediately. Handshake rate is derived, never entered.

{{ c.unit }}
{{ c.source }}

Intel QAT accelerates the classical leg of a hybrid handshake. It has no lattice datapath, so ML-KEM and ML-DSA always run on the core or on the GPU. Compare B1 with B2 to see the offload contribution in isolation, and B2 with D1 to see the GPU contribution. Anchors from vendor material — a 15% and 21% hybrid transition cost, 2,926 pure post-quantum handshakes per second per core, 9.0 million batched ML-KEM-768 encapsulations per second on a datacentre GPU — are order-of-magnitude checks only, never quoted as our own findings.