TITAN: la infraestructura de IA de un instituto

Del metal al chat de clase: inferencia local, pool elástico, RAG y las lecciones de cada decisión

Esta página es la versión técnica de cómo está montado el sistema de IA del IES Simarro: el servidor, el modelo, el balanceador, el gateway, la plataforma y la red. Está pensada para gente que ya sabe de qué va un token, un batch o un índice de similaridad: cada bloque va al detalle —flags concretos, métricas reales extraídas de la máquina en vivo y las decisiones que costaron un incidente—. Los números de esta página se extrajeron del sistema en marcha el 5 de noviembre de 2026, no de una presentación comercial.

01El servidor TITAN

Un único nodo físico en el centro hace de motor de todo: inferencia LLM, síntesis de voz, OCR, embeddings y la plataforma web. No es un rack de datacenter: es una workstation de gama profesional reconvertida en servidor.

La idea de «una máquina, todo dentro» es deliberada: el centro no paga API por token, no saca datos del edificio y no depende de Internet para que un claustro entero use la IA a la vez. El coste real es la disciplina operativa que describe esta página: pools elásticos, watchdogs y runbooks, porque aquí no hay un equipo SRE de un proveedor detrás.

02El modelo: por qué este y no una API

El modelo cabecero es Qwen3.8-Flash-Next con checkpoint mixed-NVFP4-FP8 —revisión pinneada, montada solo lectura; 183,8 GB en disco, 72,07 GiB de pesos por GPU según el log de arranque del motor—. No se eligió por el ranking de moda, sino por tres propiedades verificables en su config.json:

La aritmética del KV cache, con cifras de la máquina

Cada token en contexto cuesta KV en las 12 capas completas: 2 cabezas × 256 dimensiones × 2 (K y V) × 2 bytes (bf16) ≈ 24,6 KB/token. La reserva se fija a mano con --kv-cache-memory=15569256448 (14,5 GiB, sin dejar que el perfilado automático decida), y el motor lo traduce en 604.705 tokens de KV —literal del log—: cuadra con el coste por token. Con esa reserva la máxima concurrencia para una petición del contexto completo es 1,15×: una conversación puede ocupar los 512k enteros, pero entonces la tarjeta queda llena de contexto y las demás esperan. La reserva de KV es, literalmente, el presupuesto de memoria compartida entre todas las conversaciones vivas.

Cuánto cuesta «no usar la API» (y por qué sale a cuenta)

La pregunta de todo experto: ¿por qué no una API de terceros, que no obliga a mantener nada? Cuatro razones que sostienen esto en un centro público: protección de datos con menores (los datos del alumnado no salen del edificio); coste marginal cero (una tanda de ~25 exámenes generados por agentes, con ≈21k tokens de salida cada uno, sería una factura considerable en cualquier API: aquí son horas de GPU amortizada); disponibilidad soberana (la IA funciona con la fibra del instituto caída); y valor docente: el alumnado del ciclo puede auditarlo todo —del cmdline de vLLM a los percentiles de latencia— porque el sistema es suyo.

03El pool elástico: tres réplicas, un endpoint

Sobre las 3 GPU corren réplicas idénticas de vLLM con TP=1 (una tarjeta cada una: el reparto de tensores entre GPUs solo compensa cuando el modelo no cabe, y aquí cabe cuantizado; además TP añade comunicación inter-GPU y acopla los fallos). Un HAProxy 3.0 en red host las agrega tras un único endpoint OpenAI-compatible, :8000/v1, con balance leastconn —cada petición va a la réplica con menos conexiones vivas, que en streaming LLM es el proxy correcto de «menos carga»—.

La palabra elástico es la parte interesante: las réplicas no tienen el mismo estatus.

El ciclo de vida lo gobierna un runbook con tres verbos: titanctl release N --purpose X (drena sin cortar: espera hasta 30 minutos a que terminen las generaciones en vuelo, y solo entonces para y libera la GPU para otro modelo), titanctl restore N (arranca, espera, smoke test y alta en el pool) y titanctl reconcile (ajusta el pool a la realidad de las GPUs). Un timer systemd cada 30 s hace de guardián: si el endpoint muere o la realidad y la configuración divergen, lo reconcilia él.

Los flags de cada réplica, tal cual corren

vllm serve /model --served-model-name qwen3.8-flash-next
  --tensor-parallel-size=1          # una GPU por réplica, sin TP
  --max-model-len=524288            # 512k vía YaRN (hf-overrides factor 2.0)
  --gpu-memory-utilization=0.97     # 94,4 GiB de los 96
  --kv-cache-memory=15569256448     # 14,5 GiB A MANO → 604.705 tokens de KV
  --max-num-seqs=32                 # techo por réplica → 96 secuencias en el pool
  --enable-prefix-caching           # 87 % de acierto medido (§04)
  --enable-auto-tool-choice --tool-call-parser=qwen3_coder
  --reasoning-parser=qwen3          # razonamiento visible en el stream
  env: VLLM_PLE_CPU_OFFLOAD=1       # pesos PLE (Per-Layer Embeddings) en RAM del host
  env: HF_HUB_OFFLINE=1             # imposible «tirar de la descarga»: aire puro

Leer /proc/1/cmdline como fuente de verdad no es un truco cosmético: cuando se cambian flags de rendimiento de noche sobre varias réplicas, lo normal es que una quede con el flag nuevo y las otras con el viejo. La auditoría de uniformidad se hace al proceso, no al compose.

04Números medidos (no estimados)

Todo esto sale de /metrics de vLLM, del CSV de stats de HAProxy y de docker logs, con el método anotado —que es la mitad del dato—. La regla de oro de la medición en casa: un pico con 1-2 peticiones corriendo no es un techo de throughput, y un bench de 5 hilos no es la carga real.

05Gateway: quién llama a qué

Entre los consumidores y el pool hay dos puertas con funciones distintas:

frontend openai_front
  bind 0.0.0.0:8000
  monitor-uri /haproxy-health
  default_backend qwen_pool

backend qwen_pool
  balance leastconn
  option httpchk
  http-check send meth GET uri /health
  http-check expect status 200
  default-server check inter 3s fall 2 rise 2
  retries 2
  option redispatch
  server qwen0 127.0.0.1:8100            # chat: siempre en el pool
  server qwen1 127.0.0.1:8101 disabled   # prestada: entra con smoke test
  server qwen2 127.0.0.1:8102 disabled

06La plataforma del centro

La interfaz que usa el claustro y el alumnado —chat con voz, resúmenes, corrección de exámenes, corpus, grabadora de clases— es un monorepo desplegado en el mismo titan:

El flujo del chat, entero: navegador → nginx (TLS, CA propia) → FastAPI → HAProxy → réplica vLLM → stream SSE de vuelta. Todo local, todo en la misma máquina, todo auditable.

07RAG, OCR y voz: el resto del stack

Vector search: Qdrant + BGE-M3 híbrido

El gateway RAG (servicio propio, FastAPI en :8001) usa Qdrant con cuatro colecciones separadas por semántica de recuperación, no por capricho: materiales del centro (la que consulta el chat), normativa —allí la recuperación significa otra cosa: manda la vigencia, las fuentes se enseñan con enlace y todo se re-ingesta por curso—, exámenes y ejercicios. Los embeddings los produce BAAI/bge-m3 (1024 dimensiones, denso + sparse + multilingüe) servido por vLLM en CPU: es IO-bound y no debe comer VRAM del chat. La recuperación es híbrida (BM25 + vectorial + reranking): en un corpus normativo con términos exactos, el vectorial puro pierde frente a lo que siempre supo Lucene.

El corpus del centro: cinco decisiones que dan clase

La herramienta con la que el centro mete documentos en su base de conocimiento tiene detalles que merecen explicarse uno a uno: (1) va a la misma colección que consulta el chat, por eso un documento subido a las 10:00 cuenta a las 10:01 sin tocar el camino crítico; (2) el texto se extrae dónde toca —txt/csv/ xlsx los lee el backend in-process, y PDF/DOCX/imágenes van al gateway, que tiene el OCR por GPU DeepSeek-OCR— porque la GPU que presta el OCR se libera a veces y el corpus no puede depender de eso para un simple .txt; (3) dos modos de ingesta, inmediata o nocturna (barrido a las 02:30: un despliegue a media mañana no se pone a vectorizar cuarenta documentos en horario de clase); (4) metadatos obligatorios desde el día 1 —departamento, nivel, etiquetas—, porque nadie rellena una taxonomía después sobre cien documentos ya subidos; y (5) verificación de ingesta con búsqueda de prueba desde el panel, en vez de «ya saldrá o no saldrá» en una conversación.

Voz y vídeo: TTS y render como servicios

Qwen3-TTS (1,7 B, 9 voces, 10 idiomas) sirve la API de audio de OpenAI (POST /v1/audio/speech) en seis réplicas de ~4,8 GiB de VRAM cada una —la co-localización forzada de §03; el modelo cabe en cualquier GPU libre—. El renderizador produce las vídeo-lecciones (guion → render → locución) en otro contenedor, y la grabadora de clase sube solo audio: faster-whisper en GPU transcribe con semáforo=1 para no pisar el pool, y el resumen se genera contra el mismo pool de siempre. Cada capacidad es un servicio con su puerto, su healthcheck y su palanca de apagado —nada de librerías incrustadas que solo puedas usar «aquí»—.

08Segunda línea: los DGX Spark

Titan es un punto de fallo único, y eso en una infraestructura de centro no se lamenta: se combate con una segunda línea barata. Dos pares de NVIDIA DGX Spark (módulos GB10, 128 GB unificados CPU+GPU), cada par con su HAProxy propio (:8400 y :8401), y LiteLLM repartiendo entre pares por least-busy: la misma clave de usuario vale en cualquiera de los dos; si un par se apaga, el otro absorbe sin que nadie cambie nada.

Detalles que a un experto le van a gustar: cada par puede correr el modelo en perfil DUAL —paralelismo entre los dos nodos por fibra ConnectX-7 con NCCL— o en perfil independiente (dos máquinas pequeñas separadas, cada una con su pool). El par B todavía no puede con el DUAL: el cable funciona —los dos nodos se ven por IPv6 link-local a 0,9 ms—, pero su netplan no declara la dirección IPv4 link-local que NCCL necesita. Y un clásico del campo: los hostnames van cruzados respecto a las IPs (spark1 es la .114); el alias SSH manda, nunca el orden de las direcciones. Es un clúster de cuatro nodos sin presupuesto de clúster de cuatro nodos, con sus runbooks gemelos del de titan.

09Red y seguridad: perímetro sin nube

El sistema vive en una red privada del centro. La superficie expuesta está pensada al revés que la de un SaaS: por defecto nada, y lo que se saca se saca con identidad.

10Operación: el sistema se defiende solo (porque le obligamos)

Infraestructura local en un centro no es «montar y olvidar»: es un ciclo de vigilancia, medición y runbooks. Lo que hay en marcha hoy:

Y el cierre, que es también la demostración: quien ha redactado esta ficha es un modelo corriendo sobre la máquina que describe, leyendo sus propios logs y métricas —la infraestructura auditándose a sí misma—. Eso es exactamente lo que ninguna API de terceros te deja hacer, y es la mejor diapositiva de la tarde.