Borrador para el equipo docente · octubre 2026
Servidor de IA del ITICBCN
Una propuesta para que el servidor de GPUs del centro dé servicio de modelos de lenguaje a las clases, aloje nuestras aplicaciones y sostenga el I+D+i, de forma estable, segura y sin que nadie tenga que entrar en la máquina.
01Para qué es el servidor
Proponemos que sirva para tres cosas, por este orden:
- Servicio de LLM al centro. Un chat y una API de modelos de lenguaje para las actividades de clase, que pueda usar el profesorado y el alumnado sin depender de servicios externos ni de cuentas personales.
- Alojar nuestras aplicaciones, como CoorDUAL (la gestión de la FP Dual) y las que vengan. Los datos personales del alumnado se quedan dentro del centro.
- I+D+i: modelos de vídeo e imagen para contenido propio del ITIC (ya aprobado) y entrenamiento o fine-tuning en proyectos de clase.
Principio: nadie se conecta al sistema operativo salvo para montar y configurar servicios. Profesorado y alumnado lo usan solo por web y por API.
02El hardware que tenemos
- GPU
- 2 × RTX 6000 Ada · 48 GB
- Memoria de GPU
- 96 GB en total
- CPU
- Xeon w5-2465X · 16 núcleos / 32 hilos
- RAM
- 128 GB · 4 ranuras libres
- Disco
- 1 × NVMe 2 TB
- Equipo
- HP Z4 G5
Ojo: las GPUs son Ada Lovelace de 48 GB, no Blackwell de 96 GB cada una como pensábamos. Siguen siendo muy capaces: soportan FP8 y caben modelos de 30 a 70 mil millones de parámetros (ver capacidad).
03Cómo está montado ahora
- Windows 11 Pro de escritorio como sistema base, con Ubuntu dentro de WSL.
- Una cuenta de administrador compartida por la que entra quien necesita algo.
- Dos Ollama, uno en Windows y otro en WSL, que se disputan el mismo puerto con modelos distintos.
- Open WebUI (el chat) lanzado a mano; tras un reinicio no vuelve solo.
- Proyectos de compañeros en carpetas dentro del Ubuntu de WSL.
En las últimas semanas ya se ha montado el acceso remoto de administración por un túnel cifrado (SSH solo con clave, ningún puerto abierto a internet), ComfyUI para el I+D+i de vídeo como servicio en la GPU 1, y CoorDUAL en contenedores con su base de datos y su repositorio git en el propio servidor.
Problemas de este montaje
- FrágilLos servicios dependen de una sesión de Windows abierta. Un reinicio por actualizaciones deja al centro sin chat.
- No escala a una claseOllama atiende bien a una persona; con 25-30 alumnos a la vez las respuestas se encolan.
- Sin control de usoNo hay claves por grupo, ni cuotas, ni registro de quién usa qué.
- InseguroUna cuenta compartida da acceso total, y el escritorio invita a "entrar a mirar".
- Sin copiasUn único disco. Si falla, se pierden chats, modelos y la base de datos de CoorDUAL.
- A ciegasSin monitorización ni rastro de cambios: nadie sabe si algo ha caído ni qué se tocó.
04Propuesta
Un servidor Linux sin escritorio. Todo corre en contenedores, se entra solo por web o API, y la configuración vive en un repositorio git.
Sistema operativo: Ubuntu Server 24.04 LTS
- Las herramientas de GPU son de Linux. vLLM, NVIDIA Container Toolkit y la monitorización de GPU funcionan de forma nativa; sobre WSL van peor y con más limitaciones.
- Servicios que arrancan solos tras un reinicio, sin que nadie inicie sesión.
- Sin escritorio, no hay nada que abrir.
- No hay alternativa razonable en Windows: pasar las GPUs a una máquina virtual Linux solo existe en Windows Server, no en Windows 11 Pro.
Arquitectura
Internet y red del ITIC · túnel cifrado de Cloudflare, sin puertos abiertos
↓
Proxy inverso + HTTPS
chat.<dominio>Open WebUILogin Google @iticbcn.catapi.<dominio>LiteLLMClaves por profe, grupo o alumno<app>.<dominio>AplicacionesCoorDUAL y las que venganadmin.<dominio>Grafana y panelSolo administradores↓
Capa LLM
LiteLLM reparte las peticiones, aplica cuotas y registra el uso.
GPU 0vLLM con el modelo de clase
GPU 12.º modelo, vídeo o entrenamiento
Aplicaciones
- Un stack de contenedores por aplicación
- Red y base de datos propias
- Copias cifradas si hay datos personales
Transversal
MonitorizaciónPrometheus, GPU, Grafana y avisos de caída
Copiasrestic a un 2.º disco y fuera del servidor
Configuraciónrepo git
infra-super, una carpeta por servicioLas piezas
| Pieza | Qué hace | Por qué |
|---|---|---|
| vLLM | Sirve los modelos en la GPU | Atiende muchas peticiones a la vez con batching continuo: lo que necesita una clase entera. |
| LiteLLM | Puerta única de la API, compatible con OpenAI | Claves por profesor, grupo o alumno, con cuota y registro de uso. Los ejercicios de Python o agentes funcionan igual que contra OpenAI, pero en local y gratis. |
| Open WebUI | Chat tipo ChatGPT | Login con la cuenta del centro y grupos por curso. Nadie necesita cuenta en el servidor. |
| Ollama | Probar modelos nuevos | Se queda como banco de pruebas, no para servir a clase. |
| ComfyUI | Imagen y vídeo | Ya funciona; pasa a ser un contenedor más. |
| Traefik o Caddy | Proxy inverso y HTTPS | Un único punto de entrada con certificados automáticos. |
| Cloudflare Tunnel + Access | Acceso desde fuera | Sin abrir puertos; las rutas de administración, solo para cuentas autorizadas. |
| Prometheus + Grafana | Monitorización | Uso de GPU, memoria y servicios; aviso si algo cae. |
| restic | Copias de seguridad | Copias cifradas e incrementales a otro disco y fuera del servidor. |
Reparto de las GPUs
- GPU 0, siempre: el LLM de clase. No se toca.
- GPU 1, flexible: un segundo modelo (código o multimodal), vídeo, entrenamiento y fine-tuning.
- Las dos juntas solo en ventanas planificadas, para un modelo grande.
Quién entra y cómo
| Quién | Cómo | A qué |
|---|---|---|
| Administradores (1-2) | SSH con clave, cuenta nominal, por el túnel | Sistema y configuración |
| Profesorado | Web con Google @iticbcn.cat y API con su clave | Chat, API y sus aplicaciones |
| Alumnado | Web con Google @iticbcn.cat y API con clave de grupo o personal | Chat y API, con cuota |
| Proyectos de compañeros | Contenedor propio o JupyterHub con GPU y cuota | Su entorno, sin tocar el sistema |
No hay cuentas compartidas. Los cambios se hacen en el repo infra-super y se aplican con docker compose up: cada cambio queda con autor, fecha y vuelta atrás.
Datos y RGPD
- Los datos no salen del centro. Conversaciones del chat y datos de aplicaciones (CoorDUAL tiene datos del alumnado) se quedan en el servidor.
- Copias cifradas, con la copia externa en un destino del centro (NAS o Drive institucional).
- Registro mínimo: LiteLLM guarda el consumo por clave, no el contenido.
Es un buen argumento frente a usar servicios externos de IA con el alumnado.
05Qué capacidad tendremos
Estimaciones orientativas, a validar con una prueba de carga con un grupo real.
| Escenario | GPU | Modelo de ejemplo | Uso |
|---|---|---|---|
| Modelo de clase | 1 × 48 GB | 24-32 B en FP8 (familias Qwen, Mistral, Gemma) | 25-30 alumnos a la vez con respuesta fluida |
| Dos modelos | 2 × 48 GB | Uno general + uno de código o visión | Dos grupos con necesidades distintas |
| Modelo grande | 2 × 48 GB juntas | ~70 B cuantizado a 4 bits | Demostraciones, evaluaciones, I+D |
| Vídeo e imagen | 1 × 48 GB | Modelos de vídeo en ComfyUI | Contenido propio e I+D |
06Comparativa
| Ahora | Propuesta | |
|---|---|---|
| Sistema | Windows 11 Pro de escritorio + Ubuntu en WSL | Ubuntu Server 24.04 LTS, sin escritorio |
| Cuentas | Una cuenta de administrador compartida | 1-2 administradores nominales, SSH con clave |
| Uso diario | Entrando al escritorio o a WSL | Solo web (chat) y API |
| Arranque | Depende de una sesión abierta | Todo arranca solo tras un reinicio |
| Servir LLM | Dos Ollama que chocan en el mismo puerto | vLLM para una clase entera; Ollama solo para pruebas |
| API para clase | No hay | LiteLLM compatible con OpenAI, con claves y cuotas |
| Chat | Open WebUI lanzado a mano | Open WebUI fijo, login del centro, grupos por curso |
| GPUs | Sin reparto | GPU 0 para clase, GPU 1 flexible, política escrita |
| Aplicaciones | Mezcladas en un Ubuntu compartido | Un stack aislado por aplicación |
| Copias | Ninguna, un solo disco | Nocturna a un 2.º disco + copia fuera |
| Monitorización | Ninguna | Grafana y avisos de caída |
| Configuración | Cambios a mano, sin rastro | Repo git con historial y vuelta atrás |
| Acceso remoto | Túnel cifrado + SSH con clave (ya hecho) | Igual, con control de acceso en las rutas de administración |
07Plan de migración
- Inventario y copia de usuarios y chats de Open WebUI, modelos, proyectos de compañeros y la base de datos de CoorDUAL.½ día
- Hablar con quien usa hoy la máquina para dar sitio a sus proyectos en la nueva arquitectura.—
- Reinstalar con Ubuntu Server, drivers NVIDIA, Docker y el túnel.½ día
- Montar el repo1-2 días
infra-super: proxy, LiteLLM, vLLM, Open WebUI, monitorización y copias. - Restaurar Open WebUI, CoorDUAL y ComfyUI como stacks.½ día
- Prueba de carga con un grupo real y ajuste de cuotas.1 sesión
Casi todo se hace en remoto. El corte de servicio se limita a la reinstalación.
08Qué necesitamos decidir
- Aprobar la reinstalación con Ubuntu Server.
- Subdominio del servicio, y si el chat se abre fuera del centro o solo dentro.
- Política de uso: cuotas por alumno y quién puede usar las dos GPUs.
- Administradores: quién, como máximo dos personas.
- Un segundo NVMe de 2-4 TB para copias y modelos: la mejora de hardware más rentable (unos 150-300 €).
- Opcional: ampliar la RAM (quedan 4 ranuras) para más contenedores o modelos en CPU.