benchmarks/ — Métricas reproducibles¶

Resultados de tok/s, memoria y latencia en hardware concreto. Tu primer benchmark debe correr ANTES de comprometerte con un MVP.

Cómo correr un benchmark¶

# Default: 10 queries con gemma4:e4b
./scripts/bench.sh

# Modelo y número de queries específicos
./scripts/bench.sh gemma4:e2b 20
./scripts/bench.sh gemma3:12b 5

Los resultados se guardan en benchmarks/runs/<modelo>_<timestamp>.md.

Estructura¶

benchmarks/
├── README.md                  ← este archivo
├── m4-pro-24gb.md             ← resultados verificados en este hardware
├── results-template.md        ← plantilla para nuevos benchmarks
└── runs/                      ← outputs de ./scripts/bench.sh
    └── ...

Qué medir¶

Métrica	Por qué importa
tok/s con prompt corto (<200 tok)	Baseline; lo que ven los usuarios en chat interactivo
tok/s con prompt largo (8K+ tok)	RAG real; suele ser 30-50% menor
TTFT (time to first token)	UX percibida; <500ms = se siente snappy
Memoria residente	Cuántos modelos puedes correr a la vez
Memoria pico	Si causa OOM bajo carga sostenida
Latencia p95 vs p50	Variabilidad; alta = malo para SLA

Comparativas relevantes¶

Para tu producto necesitas decidir entre: - E2B vs E4B vs 26B vs 31B (tamaño) - Q4_K_M vs Q5_K_M vs Q8 (cuantización) - Ollama vs llama.cpp vs MLX (runtime) - prompt corto vs prompt largo (RAG) - single query vs batched (throughput)

Corre benchmarks para los pares relevantes a tu caso antes de fijar arquitectura.

Resultados verificados M4 Pro 24 GB¶

Ver m4-pro-24gb.md. Resumen:

Modelo	tok/s (prompt corto)	tok/s (prompt 8K)	Memoria
Gemma 4 E2B Q4	95	~70	4 GB
Gemma 4 E4B Q4	57	~38	5.5 GB
Gemma 4 26B-A4B Q4	2	OOM	18 GB

Refs: Anass Kartit (kartit.net, mayo 2026).