Work follows load.

See how a search engine shares work between CPU and GPU.

Loading measurements…

View source code

Waiting for runtime

Recorded GPU demo

Playback only. No live searches.

Loading measured telemetry from the Razer GPU run…

0:00 / 0:00

All values are recorded measurements. Latency spikes and rejected searches are retained.

Capture details 300-trial benchmark report

Traffic

Results per query

GPU contention Off

Incoming requests

—/ sec

— completed / sec

Queue depth

—requests

p95 latency

—ms

p99 latency

—ms

Target 15 ms

Routing

Completions in the last second

CPU—

Utilization Unavailable

GPU—

Utilization Unavailable

Current policy

—

Waiting for a policy decision.

Waiting for controller

Latency

Last 60 seconds

p95p9915 ms target

Since start

0 rejected0 failed0 SLO misses

Runtime detailsHistory & measurements

Policy history 0 changes since start

Waiting for the first decision

Measurements

CPU completions / sec: —
GPU completions / sec: —
Pending GPU requests: —
Mean GPU batch: —
Free GPU memory: Unavailable

Waiting for runtime

Waiting for measurements

Utilization covers the whole machine. Latency includes queue wait; percentiles are rolling one-second histogram upper bounds, rounded by at most 10%. Traffic rates are targets. Results per query changes top-K selection work.

Recorded benchmarkFive strategies from a recorded test

Loading recorded measurements…

Strategy	Completed / sec	p99 latency	Rejected	SLO misses

Static GPU batching performed best on this trace. Default-gated Laya fell back on all 11 decisions: nine low-confidence responses and two timeouts. An ungated diagnostic chose GPU batching throughout and performed similarly to static batching.

Single runs, 8,040 offered queries each. Percentiles cover successful requests; SLO misses include rejected requests. Adaptive controllers used a 2-second interval. These measurements do not establish a general scheduling speedup.