Define the workload. Measure the fit.

An evaluation is four steps, scope to review. Each one has a deliverable you keep and an input it needs from you. We measure your configuration before quoting a number for it — the result is an evidence pack, not a promise.

No fixed duration, free proof-of-concept or guaranteed speed-up is implied by this page. What an evaluation guarantees is a measurement you can reproduce, with its conditions.

1. 1 — Scope. We write down the workload before measuring it: the target device(s), the model or checkpoint, the task (interactive, batch or streaming) and the outcome that counts as success. Deliverable a one-page workload definition we both sign off. You provide your target hardware, the model, and what “good enough” means — a latency ceiling, a memory budget or a quality bar. A model name is enough to start; a confidential dataset is not required at this step.
2. 2 — Protocol. We fix how the measurement is judged: the baseline to beat, the timing boundary (what is inside the measured window and what is excluded), the quality threshold, and how many repeats. Deliverable a written measurement protocol. You provide the reference you compare against — your current stack, or a named engine — and the quality check that has to hold.
3. 3 — Run. We measure on the same device: timing paired against the baseline, failures and out-of-memory points, and sustained behaviour across a real segment rather than a single peak. Deliverable paired measurements with their conditions. You provide access to the target device (or an equivalent we agree on) and representative inputs.
4. 4 — Review. We hand back an evidence pack — conditions, raw runs, the quality/latent check and the commands to reproduce it — name the integration gaps, and state the next decision. Deliverable the evidence pack and a go / no-go reading. You provide your decision criteria.