Concerto Local (on-premise)
Concerto Local (999 €/mes) despliega Shara íntegramente en tu propia infraestructura: la base de datos, los agentes y el modelo principal (Concerto) corren en tu casa, sin ningún componente cloud. Pensado para sectores regulados, cláusulas de soberanía de datos y aislamiento completo respecto a clouds públicas. Todo incluido. Esta guía recoge los tres niveles de hardware, despliegue con Docker Compose, licenciamiento, periodo de gracia, copias de seguridad y soporte on-prem.
Cuándo elegir on-premise
Sección titulada «Cuándo elegir on-premise»Concerto Local tiene sentido cuando tus datos no pueden salir de tu perímetro: sanidad, sector público, finanzas, defensa o cualquier organización con cláusulas contractuales o normativas (RGPD estricto, secreto profesional, clasificación) que prohíban el tratamiento en clouds de terceros. También es la garantía última de continuidad: si AIGiner dejara de operar, tu despliegue sigue funcionando con Concerto sin depender de nuestros servidores (ver Sin lock-in).
En el resto de planes la inferencia se resuelve en la nube. En Concerto Local todas las llamadas se resuelven con Concerto sobre tus propias GPUs: no hay ningún componente cloud, ninguna delegación a la nube ni cuota de STU. Solo la verificación periódica de licencia contacta a la red de AIGiner (sin datos de negocio). El sistema funciona 100 % on-premise con soberanía total del dato.
| Componente | Dónde corre |
|---|---|
| Base de datos (tu información) | Tu infraestructura |
| Agentes departamentales y orquestador | Tu infraestructura |
| Concerto (modelo principal) | GPUs del cliente |
| Servicio de licencia | Solo firma de licencia, sin datos de negocio |
Todo se ejecuta 100 % local, sin ninguna llamada de inferencia a la nube. Soberanía total: Concerto resuelve cada tarea en tu infraestructura, incluida la orquestación del agente principal.
Los tres niveles de Concerto Local
Sección titulada «Los tres niveles de Concerto Local»Concerto Local se adapta a tres niveles según la infraestructura del cliente. El instalador detecta RAM y GPU y recomienda automáticamente el nivel; puedes sobreescribir la recomendación al ejecutarlo. Cada nivel sirve un modelo Concerto (alias) dimensionado al hardware disponible: cuantizado en Compacto, precisión completa con paralelismo tensorial en Estándar y Extendido.
| Nivel | RAM | GPU (VRAM) | CPU | Disco | Concurrencia | Encaje |
|---|---|---|---|---|---|---|
| Concerto Compacto | 16 GB | Integrada / opcional | 8c/16t mín · 12c/24t rec | 500 GB a 1 TB NVMe | ~5 usuarios | Oficina pequeña, un departamento |
| Concerto Estándar (recom.) | 64 GB DDR5 | 1 × 24 GB (tipo RTX 4090) | 16c/32t mín · 24c rec | 1 a 2 TB NVMe · RAID 1 rec | ~25 usuarios | Empresa mediana |
| Concerto Extendido | 256 GB (512 rec) por nodo | Servidor GPU de centro de datos | 32c/64t mín · 64c rec | 4 a 8 TB NVMe + WAL dedicado | 100+ usuarios | Enterprise / multi-departamento |
- UPS (alimentación ininterrumpida) recomendado en Estándar y requerido en Extendido.
- Concerto Compacto funciona con solo 16 GB de RAM y GPU integrada u opcional: pensado para equipos pequeños. La GPU dedicada mejora el throughput pero no es imprescindible en este nivel.
- Concerto Extendido exige un servidor GPU de centro de datos (al menos dos nodos físicos: primario + standby que recibe WAL por streaming) para alta disponibilidad real, más red de clúster dedicada (VLAN/10 a 100 Gbps).
- El runtime y los pesos de Concerto por nivel se resuelven internamente vía el registry de modelos on-prem; no requiere configuración manual salvo indicación de soporte.
Prerrequisitos del host
Sección titulada «Prerrequisitos del host»- Docker 24+ con el plugin Compose v2.
- NVIDIA Container Toolkit si el host tiene GPUs.
openssldisponible (el instalador genera secretos conopenssl rand).
# Docker + Compose v2
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker "$USER" # cerrar y reabrir sesión
docker compose version
# NVIDIA Container Toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker
# Verificar acceso a GPU desde un contenedor
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi
Concerto Estándar y Extendido ajustan además algunos límites de kernel para alta concurrencia:
sudo sysctl -w net.core.somaxconn=4096
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
echo 'net.core.somaxconn=4096' | sudo tee -a /etc/sysctl.d/99-shara.conf
Despliegue del stack
Sección titulada «Despliegue del stack»Copia el bundle de Concerto Local al servidor destino y lanza el bootstrap. El instalador detecta el nivel, genera los secretos vacíos, prepara el docker-compose.yml y levanta el stack.
# 1. Copiar el bundle al servidor destino
scp -r deployments/plan-local/ user@server:/opt/shara/
# 2. SSH al servidor y lanzar el bootstrap
ssh user@server
cd /opt/shara/plan-local
chmod +x scripts/*.sh
./scripts/install.sh
Qué hace scripts/install.sh, paso a paso:
- Detecta RAM/GPU y recomienda el nivel (puedes sobreescribirlo).
- Copia
docker-compose.<nivel>.yml→docker-compose.yml. - Crea
.envdesde.env.exampley rellena los secretos vacíos conopenssl rand. - Pide rellenar
SHARA_LICENSE_KEY,SHARA_DOMAINySHARA_TLS_EMAIL. - Ejecuta
docker compose pullydocker compose up -d. - Espera a los healthchecks (timeout 5 min) y corre un smoke test.
Variables de .env que el operador debe rellenar:
| Clave | Descripción |
|---|---|
SHARA_LICENSE_KEY | Clave de activación que entrega AIGiner al firmar contrato. Sin ella el orquestador no arranca. |
SHARA_DOMAIN | Host público. El reverse-proxy emite el certificado TLS. En redes air-gapped, usar nombre interno + TLS interno. |
SHARA_TLS_EMAIL | Email de contacto para avisos de renovación del certificado. |
LICENSING_URL | Servicio de licencias (https://licensing.aiginer.com). |
LICENSING_CHECK_INTERVAL_HOURS | Intervalo de verificación de licencia. Default 24. |
SHARA_MULTI_TENANT | false = una organización (recomendado PYME). true = varios departamentos aislados en la misma instalación. |
Componentes que levanta el stack: el motor de inferencia local (alias Concerto), Postgres 17 con tus datos, Redis 7 (colas, rate-limit, caché de sesión), el cliente de licencia, el backend de Shara con el orquestador embebido (1 réplica en Compacto, 2 en Estándar, 4 en Extendido), el reverse-proxy con TLS automático y, según nivel, Prometheus + Grafana para observabilidad.
Primer arranque de Concerto: la descarga inicial de los pesos del modelo tarda entre 20 y 40 minutos según el enlace de red; los arranques posteriores reutilizan el volumen local y son inmediatos.
Tras arrancar, apunta el DNS al servidor y verifica el health probe público:
# Debe devolver "ok" y los subsistemas en verde
curl https://<tu-dominio>/health
# Estado, logs y operación diaria
docker compose ps # estado de cada contenedor
docker compose logs -f shara-backend
docker compose logs -f concerto-llm
docker compose down # parar (conserva volúmenes)
scripts/healthcheck.sh # smoke test in situ
Licenciamiento (Ed25519 + clave de activación)
Sección titulada «Licenciamiento (Ed25519 + clave de activación)»Cada licencia es un JSON canonicalizado y firmado con Ed25519 (RFC 8032). El cliente local embebe la clave pública y puede verificar la licencia offline; el servicio cloud (licensing.aiginer.com) sigue siendo la autoridad para emitir y revocar. La clave de activación (SHARA_LICENSE_KEY) la entrega AIGiner al firmar el contrato y se introduce en .env.
API pública que puede consumir un cliente o integrador externo:
# Verificar una licencia (público · rate-limit 10 req/min/IP)
curl "https://licensing.aiginer.com/v1/licenses/verify?\
licenseId=<id>&hardwareFingerprint=sha256:<fp>"
# Obtener la clave pública para re-validar manualmente (público)
curl https://licensing.aiginer.com/v1/licenses/public-key
Ejemplo de respuesta de verify. El campo status puede ser active, grace, expired, revoked, hardware_mismatch o not_found. La respuesta incluye responseSignature (cubre licenseId, status y serverTime) para detectar manipulación en tránsito, y serverTime para medir el desfase de reloj:
{
"licenseId": "lic_8f3c...",
"status": "active",
"expiresAt": "2027-01-31T23:59:59Z",
"maxConcurrentUsers": 25,
"serverTime": "2026-06-15T10:22:31Z",
"responseSignature": "ed25519:9a1b..."
}
- El
hardwareFingerprintes opcional: omitirlo emite una licencia universal sin atadura a hardware (útil para clústeres HA, donde se confía enexpiresAt+maxConcurrentUsers). - Si
serverTimedifiere más de 5 minutos del reloj local, el cliente avisa al administrador (posible clock skew o intento de MITM). - La verificación offline re-canonicaliza el payload con las claves ordenadas alfabéticamente y comprueba la firma Ed25519 contra la clave pública embebida.
Periodo de gracia (30 días) y modo degradado
Sección titulada «Periodo de gracia (30 días) y modo degradado»El cliente de licencia consulta licensing.aiginer.com cada 24 h y guarda el estado. El backend lo lee y rechaza lanzar agentes en estado expired. Si el servidor de licencias está temporalmente inalcanzable, arranca una ventana de gracia de 30 días durante la cual el sistema opera con normalidad (y reintenta cada 1 h en vez de cada 24 h para recuperarse rápido). Si la gracia se agota, el orquestador se bloquea.
| Desde el último verify correcto | Estado | Qué se permite |
|---|---|---|
| 0 a 24 h | healthy | Operación normal. |
| 24 h a 30 d | degraded (grace) | Operación normal + aviso amarillo. Revisar conectividad de salida hacia el servicio de licencias. |
| 30 a 60 d | read-only | Solo lecturas; nuevos runs, aprobaciones y cambios de configuración bloqueados. Contactar soporte (urgente). |
| 60 d+ / revocada | locked | Solo la consola de administración queda accesible para introducir una licencia válida. |
El backend reintenta verificaciones puntuales con backoff (2×/4×/8×) sin intervención: en cuanto recupera conectividad con el servicio de licencias, vuelve a
healthyautomáticamente. Si tu red corporativa filtra el tráfico de salida, añadelicensing.aiginer.coma la allowlist del firewall.
Backups y retención
Sección titulada «Backups y retención»- Concerto Estándar y Extendido ejecutan un sidecar de backup que hace
pg_dump -F ccada noche y poda los ficheros más antiguos queBACKUP_RETENTION_DAYS(default 30 días). - Concerto Compacto no incluye el sidecar: se programa el script manual por cron.
- Concerto Extendido añade streaming de WAL a un volumen dedicado, habilitando point-in-time recovery (PITR) y base backups diarios. El runbook PITR completo se entrega a clientes enterprise vía soporte.
# Backup manual → ./backups/shara-<nivel>-<UTC>.dump
scripts/backup.sh
# Cron diario (Concerto Compacto)
0 3 * * * cd /opt/shara/plan-local && \
./scripts/backup.sh >> /var/log/shara-backup.log 2>&1
# Restore (DESTRUCTIVO: recrea la base de datos; pide confirmación salvo --yes)
scripts/restore.sh ./backups/shara-compact-20260615T030000Z.dump
Copia off-site según tu política interna (NAS, segundo servidor interno o destino S3-compatible si la política lo permite). Las credenciales de los conectores se cifran y nunca salen de tu infraestructura:
BACKUP_RETENTION_DAYS=30
BACKUP_OFFSITE_KIND=rsync # rsync | s3 | none
BACKUP_OFFSITE_TARGET=ops@nas.empresa.local:/srv/shara-backups
BACKUP_OFFSITE_ENCRYPTION_KEY=... # AES-256, cifrado en cliente
# Alternativa S3 directa:
BACKUP_S3_BUCKET=...
BACKUP_S3_REGION=...
BACKUP_S3_ACCESS_KEY=...
BACKUP_S3_SECRET_KEY=...
Actualizaciones
Sección titulada «Actualizaciones»El script de upgrade hace, en orden: backup de la base de datos, pull de las nuevas imágenes, migraciones y recreate del backend. La API es compatible hacia atrás dentro de una release menor; los upgrades mayores se anuncian en las notas de versión.
scripts/upgrade.sh # backup → pull → migraciones → recreate del backend
Qué incluye Concerto Local
Sección titulada «Qué incluye Concerto Local»- Todo incluido por 999 €/mes: sin cuotas de STU, sin excedentes, sin componente cloud.
- Despliegue inicial acompañado en tu infraestructura.
- Soporte dedicado y actualizaciones de seguridad.
- Catálogo de agentes completo: los 20 departamentales incluidos, sin cargo adicional por ninguno.
- Inferencia ilimitada on-premise: Concerto corre sobre tus GPUs, sin facturar por uso.
En Concerto Local los logs de auditoría se mantienen en tu propia infraestructura (retención que tú defines) y la inferencia no factura por uso: no hay STU ni kill-switches de gasto porque no hay componente cloud. Lee STU y cuotas.
Soporte y SLA on-prem
Sección titulada «Soporte y SLA on-prem»- Soporte por
soporte@aiginer.com: 24/7, SLA de 4 h de respuesta. - Estado de los servicios en
https://status.aiginer.com. - AIGiner no accede a tu instalación: si hace falta soporte remoto, se establece un túnel WireGuard inverso que controlas tú, temporal y revocable.
¿Quieres una propuesta a medida o un piloto? Escribe a
hola@aiginer.com.