IA local para empresa: modelos, privacidad, coste y viabilidad · Módulo 3: Prueba y decisión
Evaluar calidad, rendimiento y operación
Benchmark reproducible que combina calidad de tarea, TTFT, latencia total, throughput, memoria, concurrencia, estabilidad y recuperación.
Objetivo de aprendizaje
Ejecutar una prueba comparable de local y API bajo diferentes cargas y verificar que la arquitectura satisface umbrales de calidad y servicio.
El benchmark relevante no es «cuántos tokens por segundo da mi GPU». Es:
«¿Esta arquitectura completa la tarea con la calidad y el nivel de servicio que necesitamos?»
La evaluación debe combinar calidad, rendimiento, capacidad y operación.
Congela una configuración
Registra:
- model hash;
- quantization;
- runtime;
- version;
- driver;
- hardware;
- prompt;
- dataset;
- context;
- batch;
- concurrency.
Sin esto, no puedes reproducir.
Calidad
Usa el dataset de C06 o crea uno equivalente.
Mide según la tarea:
- accuracy;
- F1;
- groundedness;
- exactitud de extracción;
- pass@rubric;
- tool selection.
No uses perplexity como sustituto de calidad de negocio.
Si pruebas cuantización, compara con la misma referencia.
Rendimiento: fases
Prefill
Procesa el prompt inicial.
La métrica visible suele ser:
- TTFT.
Decode
Genera tokens.
Mide:
- inter-token latency;
- tokens/s;
- total generation.
NVIDIA documenta estas métricas por separado porque describen fases distintas.
Una configuración puede tener buen throughput agregado y mal TTFT.
Concurrencia
Prueba:
1
2
5
10
20 usersMide:
- p50;
- p95;
- queue;
- memory;
- errors.
El punto de saturación importa más que el máximo teórico.
Longitud
Ejecuta:
- short;
- median;
- long.
La memoria de KV cache crece con el contexto y concurrencia.
No declares capacidad usando solo prompts cortos.
Warm/cold
Mide:
- model load;
- first request;
- warmed service.
Si el servicio se reinicia cada noche, startup importa.
Batch
Para procesamiento offline:
- batch throughput;
- tasks/hour.
Para interactivo:
- latency.
No optimices un chatbot con una métrica offline.
Calidad bajo presión
Con carga alta, comprueba:
- timeouts;
- truncation;
- degradación;
- queue.
El modelo no debería devolver respuestas parciales sin señal.
Operación
Simula:
- restart;
- OOM;
- driver crash;
- disk full;
- model corrupt;
- network isolation.
Mide:
- detection;
- recovery;
- data loss.
Energía
Si el coste energético es relevante, mide consumo del sistema completo, no TDP teórico.
Puedes usar:
- power metrics;
- PDU;
- telemetry.
Calcula energía por tarea.
No asumas que cuantizar reduce siempre energía en la misma proporción que memoria; hardware y kernel importan.
Comparación API
Ejecuta el mismo suite contra API.
Registra:
- calidad;
- p95;
- throughput;
- cost.
No ejecutes en horas diferentes si la carga externa puede sesgar; repite.
Statistical variability
Para salidas no deterministas:
- múltiples trials.
Para rendimiento:
- warm-up;
- varias ventanas;
- percentiles.
No publiques un único run.
Acceptance table
| Métrica | MUST | Local | API |
|---|---|---|---|
| Calidad | >= | ||
| p95 | <= | ||
| Throughput | >= | ||
| Coste/task | <= | ||
| Critical errors | 0 |
Metodología de prueba
Evita benchmarks «de escritorio» donde cambias modelo y hardware al mismo tiempo.
Diseña experimentos:
E1 mismo modelo, quantization diferente.
E2 mismo modelo, hardware diferente.
E3 local vs API, mismo dataset.
Esto permite atribuir cambios.
Warm-up
Los primeros requests pueden incluir:
- carga;
- compilación;
- cache.
Ejecuta warm-up y reporta por separado cold start.
No descartes cold start si ocurre frecuentemente.
Percentiles
No uses solo media.
Ejemplo:
p50: 1.2 s
p95: 4.8 s
p99: 12 sUna media de 1,8 s escondería los peores usuarios.
Throughput bajo SLO
No midas el máximo antes de colapsar.
Pregunta:
«¿Qué throughput sostiene mientras p95 < objetivo?»
Esa es capacidad útil.
Error rate
Registra:
- OOM;
- timeout;
- 5xx;
- truncation;
- invalid outputs.
Una configuración muy rápida con 5 % errores no es superior.
Calidad por cuantización
Para cada precisión:
- score;
- critical cases.
Puede mantener media y fallar en una categoría.
No uses solo promedio.
Repetibilidad
Ejecuta el benchmark:
- tres ventanas;
- mismo hardware;
- temperatura controlada si importa.
Registra:
- procesos;
- carga;
- GPU clocks.
No necesitas un laboratorio, pero sí evitar mediciones accidentales.
Monitoring overhead
Observabilidad consume recursos.
Mide con:
- telemetry normal.
No benchmarkees con todo desactivado si producción lo tendrá activado.
Failure injection
Prueba:
- kill server;
- fill queue;
- disconnect client;
- invalid input.
Mide si:
- recupera;
- devuelve estado;
- no pierde datos.
Acceptance report
Incluye:
configuration
quality
latency
throughput
memory
energy
errors
recovery
costAñade raw data.
Una tabla sin datos fuente es difícil de auditar.
Ejercicio
Diseña un benchmark de 60 minutos:
- warm-up;
- 1 user;
- 5;
- 10;
- long context;
- failover;
- quality sample.
Genera:
- CSV;
- gráficos;
- logs;
- report.
Criterio de salida
Al finalizar, debes contar con evidencia reproducible sobre calidad, latencia, throughput, memoria, capacidad y operación. La última lección convertirá esa evidencia en una decisión y un piloto con criterios de salida.