Overview
Builds a comprehensive LLM benchmark harness focused on practical production metrics: latency (TTFT, time-per-output-token, end-to-end), cost (input + output tokens × price), accuracy/quality on task-specific tests, token efficiency, streaming vs non-streaming, and batch performance. Produces comparable numbers across models and a decision framework.
When to Use This Skill
- Choosing which model(s) to use for a new feature or product.
- Comparing a new model release against your current one.
- Optimizing the cost/quality/latency tradeoff for a specific workload.
- The user says "which model should we use?" or "benchmark these models".
Prerequisites
- Access to the models you want to compare (API keys or local inference server).
- A representative test set for the target task (quality eval) + a set of typical prompts for latency/cost.
- (Optional) A quality evaluation harness (see
evaluation-harness skill).
Steps
Define the benchmark dimensions:
- Quality / accuracy on your task.
- Latency: TTFT (time to first token), TPS (tokens per second), total time.
- Cost: $ per 1M input + output tokens (use current published prices).
- Token usage: input + output tokens per request.
- Reliability: error rate, timeout rate.
Prepare test sets:
- Quality set: 50-200 examples with ground truth or strong judge.
- Latency set: 20-50 representative prompts of varying lengths (short, medium, long context).
- Run multiple times and average (warm up, then measure).
Measurement:
- For streaming APIs: capture TTFT and per-token timestamps.
- For non-streaming: just wall time.
- Use the provider's usage metadata for exact token counts when available.
- Calculate cost from token counts + published prices.
Run the benchmark:
- Same prompts, same temperature (usually 0 or 0.2 for consistency), same max_tokens.
- Same system prompt / few-shot across models when fair.
- Record raw results + aggregates.
Analysis & visualization:
- Table: Model | Quality Score | Avg TTFT | Avg TPS | Avg Cost per request | Tokens in/out.
- Pareto frontier (quality vs cost, quality vs latency).
- Failure cases per model.
Output:
- Benchmark script (Python) that is easy to extend with new models.
- Results JSON + summary table (Markdown or pandas).
- Visualization code (matplotlib or Plotly).
- Decision framework: "If quality delta < X% and cost savings > Y%, switch to cheaper model."
- Recommendations for your specific use case.
Examples
A full benchmark script comparing Claude 3 Haiku / Sonnet, GPT-4o-mini / 4o, Gemini Flash / Pro on a customer support classification + draft task, with streaming latency measurement, cost calculation, quality via LLM judge, and a summary report with charts is included.
Edge Cases & Error Handling
- Rate limits during benchmark: Add sleeps or run sequentially with backoff.
- Context length differences: Note max context and test at realistic lengths.
- Pricing changes: The script should take prices as input or fetch from a config.
Verification
- The script runs cleanly against at least two models.
- Latency numbers are stable across repeated runs (low variance).
- Cost calculation matches what you see in the provider dashboard for the test calls.
- Quality scores align with your intuition (cheaper models are usually a bit worse).
- The report clearly shows tradeoffs.
- Success: You have objective data to make a model selection decision and can re-run the benchmark easily when new models are released.
References
1---2name: model-benchmarker3description: Benchmarks LLM performance on speed, cost, accuracy, and token efficiency. Use when selecting a model for a use case or comparing model versions.4license: Apache-2.05---67## Overview89Builds a comprehensive LLM benchmark harness focused on practical production metrics: latency (TTFT, time-per-output-token, end-to-end), cost (input + output tokens × price), accuracy/quality on task-specific tests, token efficiency, streaming vs non-streaming, and batch performance. Produces comparable numbers across models and a decision framework.1011## When to Use This Skill1213- Choosing which model(s) to use for a new feature or product.14- Comparing a new model release against your current one.15- Optimizing the cost/quality/latency tradeoff for a specific workload.16- The user says "which model should we use?" or "benchmark these models".1718## Prerequisites1920- Access to the models you want to compare (API keys or local inference server).21- A representative test set for the target task (quality eval) + a set of typical prompts for latency/cost.22- (Optional) A quality evaluation harness (see `evaluation-harness` skill).2324## Steps25261. **Define the benchmark dimensions**:27 - Quality / accuracy on your task.28 - Latency: TTFT (time to first token), TPS (tokens per second), total time.29 - Cost: $ per 1M input + output tokens (use current published prices).30 - Token usage: input + output tokens per request.31 - Reliability: error rate, timeout rate.32332. **Prepare test sets**:34 - Quality set: 50-200 examples with ground truth or strong judge.35 - Latency set: 20-50 representative prompts of varying lengths (short, medium, long context).36 - Run multiple times and average (warm up, then measure).37383. **Measurement**:39 - For streaming APIs: capture TTFT and per-token timestamps.40 - For non-streaming: just wall time.41 - Use the provider's usage metadata for exact token counts when available.42 - Calculate cost from token counts + published prices.43444. **Run the benchmark**:45 - Same prompts, same temperature (usually 0 or 0.2 for consistency), same max_tokens.46 - Same system prompt / few-shot across models when fair.47 - Record raw results + aggregates.48495. **Analysis & visualization**:50 - Table: Model | Quality Score | Avg TTFT | Avg TPS | Avg Cost per request | Tokens in/out.51 - Pareto frontier (quality vs cost, quality vs latency).52 - Failure cases per model.53546. **Output**:55 - Benchmark script (Python) that is easy to extend with new models.56 - Results JSON + summary table (Markdown or pandas).57 - Visualization code (matplotlib or Plotly).58 - Decision framework: "If quality delta < X% and cost savings > Y%, switch to cheaper model."59 - Recommendations for your specific use case.6061## Examples6263A full benchmark script comparing Claude 3 Haiku / Sonnet, GPT-4o-mini / 4o, Gemini Flash / Pro on a customer support classification + draft task, with streaming latency measurement, cost calculation, quality via LLM judge, and a summary report with charts is included.6465## Edge Cases & Error Handling6667- **Rate limits during benchmark**: Add sleeps or run sequentially with backoff.68- **Context length differences**: Note max context and test at realistic lengths.69- **Pricing changes**: The script should take prices as input or fetch from a config.7071## Verification72731. The script runs cleanly against at least two models.742. Latency numbers are stable across repeated runs (low variance).753. Cost calculation matches what you see in the provider dashboard for the test calls.764. Quality scores align with your intuition (cheaper models are usually a bit worse).775. The report clearly shows tradeoffs.786. Success: You have objective data to make a model selection decision and can re-run the benchmark easily when new models are released.7980## References8182- [Artificial Analysis](https://artificialanalysis.ai/)83- [LMSYS Chatbot Arena](https://chat.lmsys.org/)84- [HELM](https://crfm.stanford.edu/helm/latest/)85- [LiteLLM](https://github.com/BerriAI/litellm) (for unified benchmarking across providers)86- [OpenTelemetry for LLM observability](https://opentelemetry.io/)