Skip to main content
Evaluations score a deployed model and give you both an aggregate score and per-sample results, so you can see exactly which inputs a model gets wrong — and compare checkpoints before promoting one. There are two ways to provide test data:
  • Your own dataset — a JSONL dataset you’ve uploaded, scored with scorers like exact_match and contains.
  • A curated benchmark — GSM8K, HumanEval, and friends. Benchmarks bring their own data, prompting, and scoring; you only pick a model.

How it works

  1. Create an eval — a reusable definition: a dataset + scorers, or a benchmark task.
  2. Start a run — the eval × a model target (deployment:<id>, a serving deployment).
  3. The eval engine fans samples out concurrently (up to 100 in flight) against your deployment’s serving replicas. Code benchmarks execute each completion in an isolated sandbox.
  4. Watch progress live; read the aggregate score and drill into per-sample items when it completes.
Runs are resumable: progress is checkpointed per item, so a run interrupted by a platform deploy picks up where it left off instead of starting over.

Quickstart (CLI)

Run GSM8K against a serving deployment — no dataset, no config file:
--follow streams progress and prints the score when the run completes:
To eval your own dataset instead:
Or keep the definition in a TOML config (veri run configs/eval.toml works too):

Quickstart (dashboard)

On the Evaluations page:
  1. Click + CreateRun a benchmark (or pick a dataset).
  2. Choose the benchmark and a sample limit, then Create.
  3. In the detail panel, pick a serving deployment and click Run eval.
  4. Progress updates live; scores appear in the runs table when done.

Quickstart (SDK)

Dataset format

Dataset evals expect JSONL rows with a prompt and a reference field (default label):
prompt is either a plain string or a chat-message array; label is what scorers compare against.

Results

A completed run carries per-scorer aggregates: Per-sample rows (items) include the input, the model’s output, the reference label, each scorer’s score, and inference latency.

Model targets

Runs target deployment:<id> — a deployment in the serving state. Inference cost is attributed through the deployment’s normal request accounting; there is no separate eval billing. Targeting a scaled_to_zero deployment triggers its wake, and the run fails immediately with a hint to retry: the engine doesn’t hold eval samples open through a multi-minute GPU cold start. Retry the run once the deployment is back to serving, or pre-warm it first with veri deployments wake <id> (scale to zero).

Next steps

  • Benchmarks — the curated catalog and how code execution is sandboxed
  • Scorers — configuration reference for every scorer type
  • CLI reference — every veri evals command and flag