Requisitos
Saptiva instala la plataforma sobre un clúster Kubernetes que provee el Cliente. Antes de la instalación, Saptiva ejecuta una verificación previa que comprueba cada punto de esta lista y reporta lo que falta.
Clúster
| Pieza | Requisito |
|---|---|
| Kubernetes | Versión 1.32 o 1.33. |
| Gestión de certificados | cert-manager 1.20 o superior con un emisor disponible. |
| Almacenamiento | Una clase de almacenamiento por defecto para volúmenes de usuario y artefactos. Snapshots (CSI) recomendados para respaldo. |
| Nodos GPU | Controladores NVIDIA y operador de GPU instalados; métricas de GPU (DCGM) expuestas. |
| Monitoreo | Operador de Prometheus (para métricas y alertas de la plataforma). |
Lista de verificación previa
Lo que comprueba Saptiva antes de instalar, y cómo puedes comprobarlo tú antes para que el informe salga limpio:
| Punto | Cómo verificarlo | Resultado esperado |
|---|---|---|
| Versión de Kubernetes | kubectl version | 1.32 o 1.33 en servidor. |
| Nodos GPU visibles | kubectl get nodes -o custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu | Cada nodo GPU reporta su número de dispositivos. |
| Clase de almacenamiento por defecto | kubectl get storageclass | Una clase marcada (default). |
| Snapshots | kubectl get volumesnapshotclass | Al menos una clase (recomendado, no obligatorio). |
| Emisor de certificados | kubectl get clusterissuer | Un emisor en estado Ready. |
| Métricas de GPU | El tablero de GPU del operador muestra utilización por dispositivo | Cada GPU reporta. |
| DNS | nslookup studio.<dominio base> desde la red de usuarios | Resuelve al ingreso del clúster. |
| Registro de imágenes | docker login <registro> o equivalente desde un nodo | Acceso de lectura desde todos los nodos; unos 200 GB libres. |
Firmware de los nodos GPU
En servidores con GPUs de generación reciente, el perfil de firmware decide si el sistema operativo puede reservar el espacio de direcciones que las tarjetas piden al arrancar. Un cambio de perfil hecho después de la instalación puede dejar las ocho GPUs sin inicializar aunque nada haya cambiado en el clúster.
Caso real (instalación de referencia, 2026-07-11): alguien cambió el perfil de un servidor con 8 GPUs a uno orientado a gráficos, que desactiva la virtualización de E/S; el controlador dejó de cargar en las ocho tarjetas y el nodo quedó sin cómputo hasta que se restauró el perfil de virtualización recomendado por el fabricante. Dos reglas que salen de ahí:
- Documenta el perfil de firmware con el que se instaló cada nodo GPU y trátalo como parte de la configuración, no como ajuste libre.
- Si una GPU o un nodo entero deja de reportar tras un reinicio, revisa el firmware antes que el clúster.
Dimensionamiento orientativo
Depende del número de laboratorios simultáneos y de los modelos a servir. Como referencia para un laboratorio universitario: 8 GPUs de 96 GB (unos 760 GB de memoria de GPU en total) permiten unos 10 a 15 laboratorios activos con GPU compartida más dos o tres modelos de lenguaje en servicio.
Regla rápida para estimar: suma la VRAM est. de los modelos que quieras servir (la muestra el Catálogo de modelos), añade la VRAM de la talla por defecto multiplicada por los laboratorios simultáneos que esperas, y deja un 15 % libre para picos. Si el resultado supera la capacidad, sirve menos modelos o reduce la talla por defecto. Saptiva dimensiona con el Cliente a partir de su plan de uso.
Red
- Un dominio base (por ejemplo
laboratorioia.<institucion>) con subdominios para Studio, la API, InferNode y el panel de laboratorios, resueltos desde la red de los usuarios. - Certificados TLS para esos nombres, o un emisor interno que cert-manager pueda usar.
- Acceso de los usuarios por HTTPS al ingreso del clúster.
- Si hay proveedor de identidad corporativo (SSO), conectividad desde el clúster a él.
Registro de imágenes
Todas las imágenes de la plataforma se sirven desde un registro dentro de la red del Cliente, espejadas por Saptiva y fijadas por versión. El Cliente aporta el registro (o Saptiva lo instala) y el espacio: unos 200 GB para la plataforma más lo que ocupen los modelos.
Salidas a internet
En una instalación con salida controlada, estas son las únicas conexiones externas que la plataforma puede necesitar, todas opcionales y desactivables:
| Destino | Para qué | Si no se permite |
|---|---|---|
| Proveedores de modelos externos (Anthropic, Google, OpenRouter) | Agentes que usen modelos fuera de la infraestructura | Solo modelos locales vía InferNode. |
| WhatsApp Business (Meta) | Canal WhatsApp en workflows | El canal queda deshabilitado. |
| Registro público de modelos | Descargar modelos al catálogo | Los modelos se cargan desde un medio local. |
Sin ninguna de ellas la plataforma funciona completa con modelos locales. Ver Instalación sin internet.