Read the results
The run is finished. This part reads it.
The summary
Open the run from Benchmarks. It opens on Summary.
The screenshots on this page come from a finished run that compares two models on one device, so there is something to read in every section. A single-model run shows the same sections with one bar in each.
The header states what the run was: the models, the devices, when it started and finished, and how long it took.
The headline cards answer the three questions people ask first. Best accuracy is the highest quality score in the run. Fastest is the highest throughput, with the device it was measured on. Most lightweight is the smallest peak memory, again with its device. Each names the model, so a two-model run tells you which one won each question at a glance.
Quality compares every model in the run on the selected quality metric, with the direction stated ("higher is better") so a number is never ambiguous.
Performance carries one tab per metric.
| Metric | What it measures | Direction |
|---|---|---|
| Tokens/sec | Decode throughput, the tokens the model produced per second. | Higher is better. |
| TTFT | Time to first token, the wait before output starts appearing. | Lower is better. |
| Total latency | End to end time for the request. | Lower is better. |
| Peak Memory | The most memory the run held at once. | Lower is better. |
Where a metric was measured over many samples, the result also carries its minimum, median and maximum, so you can see whether an average hides a long tail.
The evidence behind a score
A score on its own is a claim. View output data opens the per-sample record behind it.
Each card is one item the model was given: the input it saw, what it answered, what the expected answer was, and whether that counted as correct. The filters at the top narrow to correct, incorrect or unanswered items, which is the fastest way to understand a score that surprised you. A multiple-choice test shows the choices in the order the model saw them; a transcription test shows the audio reference, the predicted text and the word error rate; a coding test shows the program and its test outcome.
This is the difference between "the model scored 33 percent" and knowing which kind of question it missed.
Share it
Share Results turns the run into something you can hand to someone who has no account on your deployment.
The dialog previews the card the recipient sees: the run's name, its models and devices, and the three headline numbers. Under it are the ways to pass it on.
- Share publishes the run and gives it a link. From then on the state line reads that anyone with the link can view it, and the run is readable without signing in.
- Copy link puts that link on your clipboard, which is what you paste into a message or a ticket.
- Download Image saves the preview card as a picture, for a slide or a chat where a link would not render. It is a snapshot: it does not update when the run does, and it carries no link back to the platform.
- Make private revokes the link. Anyone holding it stops being able to open the run, immediately.
There is one live link per run, so re-sharing does not accumulate links behind your back, and revoking is a single action rather than a hunt.
Reading two runs against each other
Inside one run, the platform draws the comparison for you. The quality section puts every model side by side, and the performance section groups the same metric per model or per device, so a two-model run answers "which one, on this hardware" without any work from you.
The grouping control switches between all results, by model and by device. By model reads naturally when you are choosing between models on one device; by device when you are choosing where to run one model.
Across two separate runs, you read the two pages against each other, and two habits make that reliable. Performance metrics compare cleanly across devices, which is the point of measuring on the real hardware. Quality scores are safest compared within one device, because a test's score depends on the engine and the settings that device ran; when two devices disagree on a quality score, the per-item view is what turns the disagreement into an explanation, since you can compare the actual answers rather than the totals.
What you have now
A measured model, on real hardware, with the evidence attached.
- Full detail: Benchmark and Read benchmark results.
- Next: What to read next.