tuxevil-benchmark
tuxevil-benchmark es una plataforma de benchmarking y red-teaming para modelos LLM locales (SLM). Permite medir TTFT, tok/s y latencia mientras un juez automatizado evalúa precisión, gramática e inyección de prompts en tiempo real.
Ficha actualizada 22 sept 2026, 19:49 · upstream 22 sept 2026, 19:47 · release sin release detectada
Qué es tuxevil-benchmark
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
tuxevil Benchmark es un entorno de evaluación de modelos de lenguaje pequeños (SLM) diseñado para evaluaciones locales seguras. Su arquitectura combina una interfaz web moderna con un backend robusto que soporta tanto modo local (SQLite) como producción (PostgreSQL + Redis). El sistema ejecuta escenarios estandarizados, captura métricas de rendimiento en tiempo real mediante streaming SSE, y evalúa respuestas mediante un modelo de juicio externo compatible con OpenAI. Incluye capacidades avanzadas como pruebas de seguridad canary, detección de anomalías, experimentos de churn controlado y exportación de datos.
La plataforma se estructura en cinco módulos principales: Arena Leaderboard para visualización pública, Test Suites para creación de matrices de prueba, Churn Lab para experimentos de cambio controlado, Live Monitor para observación técnica en tiempo real, y Settings para configuración. Cada módulo sigue principios de UX progresiva, con navegación por niveles (Model Profile → Inspector Drawer) que permite a usuarios técnicos y no técnicos acceder a información relevante según sus necesidades.
El sistema soporta múltiples modos de ejecución: modo local sin dependencias externas y modo durable con workers separados, lo que facilita la escalabilidad. Se integra mediante MCP Server para permitir integración con agentes autónomos como Hermes, y ofrece un dashboard de detección automática de anomalías basado en z-score y límites de Samuelson.
- Evaluación comparativa de modelos LLM locales antes de despliegue en producción
- Pruebas de seguridad para modelos SLM con inyección de prompts controlada
- Monitoreo técnico continuo de inferencias locales sin necesidad de infraestructura externa
- Experimentos de churn y mejora continua mediante experimentos controlados
- Integración con agentes autónomos (ej. Hermes) a través del MCP Server para automatización de pruebas
- Evaluación de modelos en entornos multi-inferencia con soporte para múltiples modelos simultáneamente
- Soporte completo de modo local sin dependencias externas mediante SQLite, ideal para entornos aislados o locales
- Arquitectura dual (SQLite vs PostgreSQL + Redis) que permite transición entre desarrollo y producción con persistencia duradera
- Streaming SSE en tiempo real para token-by-token observación del proceso de inferencia
- Detección automática de anomalías mediante z-score y límites de Samuelson, incluyendo alertas para respuestas vacías o estancadas
- Soporte MCP Server que permite integración con agentes autónomos para ejecución programática de pruebas
- Dashboard de detección de anomalías con visualización en tiempo real del estado de cada inferencia
- El modo local depende exclusivamente de la memoria RAM del sistema, lo que limita el uso a entornos con recursos limitados (CPU y VRAM)
- La persistencia duradera requiere configuración adicional de PostgreSQL y Redis, aumentando la complejidad operativa
- No incluye capacidades de entrenamiento o fine-tuning de modelos; se enfoca exclusivamente en evaluación y benchmarking
- El sistema no soporta inferencias paralelas masivas ni escalabilidad horizontal significativa sin workers adicionales
- La detección de anomalías es heurística basada en z-score, lo que puede generar alertas falsas positivas para patrones normales
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Para producción, se recomienda configurar el modo durable con PostgreSQL y Redis. Se debe establecer un worker dedicado (src/worker.ts) que procese las tareas de benchmarking asincrónicamente. Es obligatorio definir APP_ENCRYPTION_KEY para proteger datos sensibles almacenados en la base de datos. El servidor web debe estar configurado con HTTPS y una configuración segura de CORS. Para el modo local, se recomienda usar un contenedor Docker con recursos limitados (CPU: 4, RAM: 8192 MB) y evitar ejecutar múltiples instancias simultáneas para prevenir sobrecarga del sistema.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.