Ollama Benchmark Tool
---------------------

A Go-based command-line tool for benchmarking Ollama models with configurable parameters, warmup phases, TTFT tracking, VRAM monitoring, and benchstat/CSV output.

## Features

 * Benchmark multiple models in a single run
 * Support for both text and image prompts
 * Configurable generation parameters (temperature, max tokens, seed, etc.)
 * Warmup phase before timed epochs to stabilize measurements
 * Time-to-first-token (TTFT) tracking per epoch
 * Model metadata display (parameter size, quantization level, family)
 * VRAM and CPU memory usage tracking via running process info
 * Exact prompt token length for reproducible benchmarks
 * Benchstat and CSV output formats

## Building from Source

```
go build -o ollama-bench ./cmd/bench
./ollama-bench -model gemma3 -epochs 6 -format csv
```

Using Go Run (without building)

```
go run ./cmd/bench -model gemma3 -epochs 3
```

## Usage

### Basic Example

```
./ollama-bench -model gemma3 -epochs 6
```

### Benchmark Multiple Models

```
./ollama-bench -model gemma3,gemma3n -epochs 6 -max-tokens 100 -p "Write me a short story" | tee gemma.bench
benchstat -col /name gemma.bench
```

### With Image Prompt

```
./ollama-bench -model qwen3-vl -image photo.jpg -epochs 6 -max-tokens 100 -p "Describe this image"
```

### Controlled Prompt Length

```
./ollama-bench -model gemma3 -epochs 6 -prompt-tokens 512
```

`-prompt-tokens N` makes every warmup and timed request exactly N prompt tokens
as the server counts them, chat template included. Prompt sizes are reproducible
across models and can be placed on a chosen boundary, which matters when prefill
cost depends on how the prompt divides into kernel tiles.

Sizing runs once per model before the timed epochs and costs about 6 extra
requests, 10 at worst. It packs whole HumanEval problems up to the largest set
measuring at or under N, then covers the remaining few tokens with single-letter
pad units in the header comment, one token each. Padding is around 1% of the
prompt at typical sizes; the coding request is always whole, untruncated
problems.

Limits:

 * a target below the smallest single problem is an error -- use `-p` instead
 * a target above what the problem set can build (~15-25k tokens, tokenizer
   dependent) warns and uses the full set, which stays under N
 * a request whose prompt size differs from N warns, since a size that moves
   after sizing leaves the prefill numbers incomparable

### Advanced Example

```
./ollama-bench -model llama3 -epochs 10 -temperature 0.7 -max-tokens 500 -seed 42 -warmup 2 -format csv -output results.csv
```

## Command Line Options

### Decision models

```sh
go run ./cmd/bench -model tev1:latest -decision cases.jsonl -format csv
```

Each JSONL line supplies a request and expected answers; datasets are external:

```json
{"id":"message","dataset":"example","request":{"state":"I am angry.","questions":{"angry":{"type":"noul","instructions":"Is the speaker angry?","criteria":{}}}},"expected":{"angry":{"noul":true}}}
```

Omit `request.model` and `keep_alive`. Each question needs an expectation:
`{"choice":"label"}`, `{"noul":true}`, `{"level":2}` (unique most probable score
class), or `{"min":1.5,"max":2}` (inclusive expected-score range). Optional
`image_files` paths are relative to the JSONL; inline `request.images` also works.

`-epochs` replays the corpus unchanged; `-warmup` counts untimed requests.
`score` reports accuracy; `regression` requires 100%. HTTP/invalid-response errors
fail either mode. Stderr summaries report accuracy, latency percentiles and
requests/questions per second; CSV retains per-request results and input sizes.
CSV separates label `mismatches` from HTTP/invalid-response `error` values.
Summary percentiles use HTTP round-trip latency, including server queueing.
For local warm decision runs, the stderr JSON summary also includes
`size_bytes`, `vram_bytes`, and `num_ctx` from `/api/ps`. The sample is taken
after warmup, or after the measured requests when `-warmup 0`. Benchstat output
also prints the usual model Size/VRAM comment; CSV columns remain per-request.
External endpoints and cold-load runs omit memory because the local Ollama
running-model list would not describe those requests.
Compare identical corpora, model artifacts and settings on the same host. HTTP
latency includes model lookup and request setup, so warm runs capture routing and
metadata-cache improvements as well as inference. Use `-k 0 -concurrency 1` and a
warmup pass (`-warmup` equal to the corpus length) for this comparison. A warm
model does not imply uncached prompts: replay may reuse prefixes; inspect
`cached_input_tokens`. Group latency by input size and question count when
comparing different workloads.

`-concurrency` currently requires `-decision`: 1 sends back-to-back requests;
higher values keep that many requests in flight. Cold runs (`-k > 0`) require 1.
Integration uses the same file via `OLLAMA_TEST_DECISION_FILE`, defaults to
`.cache/decision-data/regression.jsonl` in the repo, and skips when absent.
`OLLAMA_TEST_MODEL` selects the model. Integration requires every case to pass;
use bench in score mode with the broad corpus to evaluate model quality.

### Options

| Option  	| Description | Default |
|----------|-------------|---------|
| -model	| Comma-separated list of models to benchmark	| (required)		|
| -epochs	| Number of iterations per model		| 6			|
| -max-tokens	| Maximum tokens for model response		| 200			|
| -temperature	| Temperature parameter				| 0.0			|
| -seed		| Random seed					| 0 (random)		|
| -timeout	| Timeout in seconds				| 300			|
| -p		| Prompt text					| (default story prompt)	|
| -image	| Image file to include in prompt		| 			|
| -k		| Keep-alive duration in seconds		| 0			|
| -format	| Output format (benchstat, csv)		| benchstat		|
| -output	| Output file for results			| "" (stdout)		|
| -warmup	| Number of warmup requests before timing	| 1			|
| -prompt-tokens	| Generate a prompt of exactly N tokens (0 = use -p)	| 0		|
| -decision | External decision JSONL corpus instead of chat | "" |
| -decision-url | External System One endpoint; server manages loading | "" |
| -decision-mode | `score` reports accuracy; `regression` requires 100% | score |
| -concurrency | Maximum in-flight requests (currently requires `-decision`) | 1 |
| -num-ctx	| Context size (0 = server default)		| 0		|
| -openai	| OpenAI-compatible API base URL		| ""		|
| -api-key	| API key for OpenAI endpoint (or OPENAI_API_KEY)	| ""		|
| -v		| Verbose mode					| false			|
| -debug	| Show debug information			| false			|

## Output Formats

### Benchstat Format (default)

Compatible with Go's benchstat tool for statistical analysis. Uses one value/unit pair per line, standard `ns/op` for timing metrics, and `ns/token` for throughput. Each epoch produces one set of lines -- benchstat aggregates across repeated runs to compute statistics.

```
# Model: gemma3 | Params: 4.3B | Quant: Q4_K_M | Family: gemma3 | Size: 4080218931 | VRAM: 4080218931
BenchmarkModel/name=gemma3/step=prefill 1 78125.00 ns/token 12800.00 token/sec
BenchmarkModel/name=gemma3/step=generate 1 19531.25 ns/token 51200.00 token/sec
BenchmarkModel/name=gemma3/step=ttft 1 45123000 ns/op
BenchmarkModel/name=gemma3/step=load 1 1500000000 ns/op
BenchmarkModel/name=gemma3/step=total 1 2861047625 ns/op
```

Use with benchstat:
```
./ollama-bench -model gemma3 -epochs 6 > gemma3.bench
benchstat -col /step gemma3.bench
```

Compare two runs:
```
./ollama-bench -model gemma3 -epochs 6 > before.bench
# ... make changes ...
./ollama-bench -model gemma3 -epochs 6 > after.bench
benchstat before.bench after.bench
```

### CSV Format

Machine-readable comma-separated values:

```
NAME,STEP,COUNT,NS_PER_COUNT,TOKEN_PER_SEC
# Model: gemma3 | Params: 4.3B | Quant: Q4_K_M | Family: gemma3 | Size: 4080218931 | VRAM: 4080218931
gemma3,prefill,128,78125.00,12800.00
gemma3,generate,512,19531.25,51200.00
gemma3,ttft,1,45123000,0
gemma3,load,1,1500000000,0
gemma3,total,1,2861047625,0
```

## Metrics Explained

The tool reports the following metrics for each epoch:

 * **prefill**: Time spent processing the prompt (ns/token)
 * **generate**: Time spent generating the response (ns/token)
 * **ttft**: Time to first token -- latency from request start to first response content
 * **load**: Model loading time (one-time cost)
 * **total**: Total request duration

Additionally, the model info comment line (displayed once per model before epochs) includes:

 * **Params**: Model parameter count (e.g., 4.3B)
 * **Quant**: Quantization level (e.g., Q4_K_M)
 * **Family**: Model family (e.g., gemma3)
 * **Size**: Total model memory in bytes
 * **VRAM**: GPU memory used by the loaded model (when Size > VRAM, the difference is CPU spill)

Decision JSONL cases may include `"cache":{"min":0.95}` (and/or `"max"`) to assert
the reused fraction of input tokens. Run ordered cache scenarios with
`-concurrency 1 -k 0 -warmup 0`; missing telemetry or failed assertions fail the run
in either scoring mode. For a cold-cache first case, unload the model before the
run and use `-epochs 1`. CSV includes `cached_input_tokens` when the server reports it.