Diseñar un stack local seguro y mantenible

Descargar un modelo y ejecutar un comando demuestra inferencia. No demuestra que exista un servicio empresarial.

Un stack local debe resolver serving, identidad, red, almacenamiento, versiones, monitorización y recuperación.

La arquitectura debe ser la mínima que cumpla requisitos.

Capas

1. Hardware y sistema

• CPU/GPU/NPU;
• RAM/VRAM;
• almacenamiento;
• OS;
• drivers.

Versiona:

• firmware;
• driver;
• runtime.

2. Artefactos

Guarda:

• model ID;
• hash;
• cuantización;
• tokenizer;
• licencia;
• origen;
• fecha.

No descargues desde Internet en cada arranque de producción.

3. Runtime de inferencia

Opciones como llama.cpp o vLLM resuelven perfiles diferentes.

llama.cpp soporta ejecución CPU/GPU y modelos cuantizados sobre múltiples plataformas.

vLLM se orienta al serving con batching, caché y escalado.

No hay «runtime mejor» universal.

4. API interna

Expón un contrato estable:

POST /v1/inference

La aplicación no necesita saber dónde vive el modelo.

Puedes ofrecer una interfaz compatible con APIs existentes, pero mantén autenticación y política propias.

Autenticación

No expongas el puerto de inferencia a toda la LAN.

Incluye:

• gateway;
• API key interna;
• mTLS/SSO según entorno;
• autorización.

La compatibilidad OpenAI de un servidor no significa que todos sus endpoints estén protegidos automáticamente.

Red

Define:

• inbound;
• outbound;
• administración;
• cluster.

En multi-node, vLLM advierte de comunicaciones internas que deben protegerse mediante red aislada.

Segmenta.

Si prometes «sin salida», prueba egress.

Datos temporales

Revisa:

• prompts;
• caches;
• KV cache;
• archivos;
• swap;
• dumps;
• crash reports.

Pregunta:

• ¿persisten?
• ¿quién accede?
• ¿se borran?

Local no significa «nada se guarda».

Logs

Por defecto:

• request ID;
• modelo;
• tokens;
• latencia;
• error.

Evita contenido.

Permite debug controlado y temporal.

Observabilidad

Mide:

• health;
• queue;
• TTFT;
• generation latency;
• throughput;
• memory;
• temperature;
• utilization;
• errors;
• OOM;
• restarts.

Incluye métricas de negocio:

• tareas;
• success;
• quality sample.

Capacity management

Define:

max_concurrency
max_context
max_output
queue_limit
timeout

Sin límites, una petición enorme puede monopolizar memoria.

Model registry

Estados:

candidate
approved
production
retired

Promoción:

eval → security scan → license review → staging → canary → production

No sobrescribas production/model.gguf.

Actualización

Cambiar:

• runtime;
• driver;
• modelo;
• quantization;

puede cambiar resultados.

Ejecuta regression.

Backups

¿Necesitas backup del modelo?

Quizá no si puedes reconstruirlo desde un repositorio verificado.

Sí necesitas preservar:

• configuración;
• hashes;
• evals;
• prompts;
• políticas.

Para modelos privados, define backup.

Alta disponibilidad

Si el servicio es crítico:

• segundo host;
• failover;
• API fallback.

No implementes HA si el proceso tolera horas offline.

Vulnerabilidades

Mantén:

• inventario;
• patches;
• CVEs;
• imágenes;
• dependencias.

No dejes el server congelado «porque el modelo funciona».

Ejemplo mínimo

Para 10 usuarios internos:

reverse proxy
    ↓
auth
    ↓
llama.cpp/vLLM
    ↓
GPU

Más:

• Prometheus/OTel;
• model registry;
• firewall;
• runbook.

No Kubernetes si no necesitas Kubernetes.

Contenedores y orquestación

Un contenedor puede mejorar reproducibilidad, pero no es obligatorio.

Usa:

• systemd;
• Docker;
• Kubernetes;

según complejidad real.

Kubernetes tiene sentido si necesitas:

• varias réplicas;
• scheduling;
• rolling updates;
• clusters.

Para un único servidor, puede añadir más superficie operativa que valor.

Storage

Separa:

• modelos;
• configuración;
• logs;
• datasets de evaluación;
• outputs temporales.

Define permisos.

Un modelo de 20 GB no debería compartir una carpeta world-writable con uploads.

Supply chain

Los artefactos llegan de:

• model hub;
• container registry;
• pip;
• OS packages.

Controla:

• origen;
• hash;
• version;
• scan.

Evita curl | bash en producción.

Egress policy

Si el requisito es local estricto, configura:

• DNS;
• firewall;
• proxy;
• allowlist.

Prueba con captura de tráfico.

Algunos runtimes pueden intentar:

• descargar tokenizer;
• metadata;
• models.

Pre-cachea.

Secrets

El servidor puede necesitar:

• registry token;
• auth key;
• observability credentials.

Usa secret store o permisos de filesystem.

No los incluyas en:

• command history;
• unit files públicas;
• logs.

Health

Distingue:

liveness el proceso está vivo.

readiness puede servir correctamente.

Un proceso puede estar activo mientras el modelo no cargó.

Graceful shutdown

En updates:

• dejar de aceptar;
• terminar requests;
• cerrar;
• actualizar.

Evita cortar outputs en mitad.

Capacity admission

Antes de aceptar una request:

• input size;
• queue;
• tenant quota.

Puedes rechazar temprano con un estado claro.

Esto es mejor que provocar OOM.

Staging

No actualices directamente producción.

Mantén un entorno donde probar:

• driver;
• runtime;
• modelo.

No necesita replicar toda infraestructura, pero sí la ruta crítica.

Runbook de upgrade

1. snapshot config;
2. deploy candidate;
3. regression;
4. load test;
5. canary;
6. promote;
7. rollback si falla.

Documenta cuánto tarda.

Asset inventory

Mantén:

host
GPU
driver
runtime
model
license
owner
expiry/review

Si no puedes responder qué modelo corre en un host, el stack no está gobernado.

Ejercicio

Dibuja tu stack y escribe para cada componente:

• owner;
• version;
• data;
• port;
• permission;
• metric;
• failure;
• recovery.

Elimina un componente. Si todo sigue cumpliendo requisitos, era innecesario.

Resultado de la lección

Debes terminar con una arquitectura operable y mínima. La siguiente lección comprobará si esa arquitectura satisface calidad y rendimiento bajo la carga real, no solo en una demo.