Qué es una Factoría de IA y cómo montarla open source
Qué es una Factoría de IA y cómo montarla con open source en tu datacenter
El concepto de AI Factory lleva dos años en boca de todos, pero pocas organizaciones entienden qué implica técnicamente ni cómo montarla sin depender de un proveedor cloud. Aquí lo explicamos sin rodeos, y con el stack concreto que usamos en producción.
Un poquito de contexto
Qué es exactamente una factoría de IA
El término “AI Factory” lo popularizó Jensen Huang de NVIDIA en 2023 para describir lo que los centros de datos están convirtiéndose: máquinas que producen inteligencia de forma continua, como una fábrica produce bienes. La metáfora no es poética; es técnicamente precisa.
Una factoría de IA clásica tiene cuatro componentes diferenciados: un sistema de almacenamiento para guardar los pesos de los modelos y los datasets (que pesan decenas o cientos de gigabytes), una capa de cómputo GPU para ejecutar la inferencia, un orquestador que gestiona qué modelo corre en qué hardware, y una API que expone los modelos al resto de la organización. Cuando esos cuatro componentes funcionan juntos de forma eficiente, tienes una factoría de IA.
Lo que la diferencia de “tener un LLM corriendo en un servidor” es la escala, la fiabilidad y la gestión. En una factoría de IA se sirven múltiples modelos en paralelo, se gestionan colas de peticiones, se garantiza disponibilidad y se monitoriza el uso de recursos. Es infraestructura de producción, no un entorno de pruebas.
Dato relevanteLa Comisión Europea ha comprometido más de 1.500 millones de euros para construir AI Factories distribuidas por los estados miembros bajo el programa EuroHPC. El objetivo explícito es que Europa tenga infraestructura soberana de IA sin depender de proveedores estadounidenses o asiáticos. España participa a través del BSC con su AI Factory en Barcelona. La misma tecnología que ellos usan, tú puedes montarla en tu datacenter.
¿Por qué recurrir a una factoría de IA?
Por qué las organizaciones se traen la inferencia a casa
Hay tres motivos que aparecen siempre en todas las conversaciones que tenemos con clientes cuando evalúan montar su propia infraestructura de IA. No son argumentos de marketing: son realidades operativas y financieras.
Costes predecibles
Las facturas de GPU en cloud público pueden variar un 30–40% entre ciclos según la demanda. Con infraestructura propia, el coste es fijo, amortizable y sin sorpresas. A partir de un volumen medio de inferencia, la inversión se recupera en 12–18 meses frente a cloud.
Sin vendor lock-in
APIs propietarias, formatos cerrados, modelos fine-tuneados que viven en infraestructura ajena. Con un stack open source, tus modelos y tus datos son tuyos. Siempre puedes moverlo todo, sin negociaciones ni contratos de salida.
Cumplimiento regulatorio
El RGPD y el EU AI Act exigen saber exactamente dónde se procesan los datos. Si tu inferencia toca datos de pacientes, ciudadanos o clientes bancarios, necesitas control total sobre la infraestructura. On-premise es la única respuesta válida.
La pregunta ya no es si montar infraestructura propia de IA, sino cuándo y cómo hacerlo sin repetir los errores del cloud hace diez años: velocidad sin arquitectura.
— Equipo técnico SIXE
Dicho esto, montar una factoría de IA on-premise no es para todo el mundo. Si procesas diez peticiones de inferencia al día y no tienes requisitos regulatorios estrictos, probablemente cloud es lo correcto ahora mismo. La infraestructura propia empieza a tener sentido cuando el volumen de uso es sostenido, cuando los datos son sensibles, o cuando necesitas correr modelos fine-tuneados propietarios sin exponerlos a terceros.
Vale pero y esto… ¿cómo lo monto exactamente?
El stack open source: tres tecnologías, cero dependencias propietarias
Existe una combinación de tres tecnologías que ha emergido como estándar de facto para construir factorías de IA on-premise en entornos europeos. Las mismas que usa el BSC. Las mismas que impulsan infraestructuras soberanas en Francia, Alemania e Italia. Y las mismas con las que trabajamos en SIXE.
Ceph: el almacenamiento distribuido para IA
Los modelos de lenguaje son voluminosos. Llama 3 70B ocupa unos 40 GB en precisión float16. Mixtral 8x7B ronda los 90 GB. Un catálogo razonable de modelos para una organización mediana puede superar fácilmente los 500 GB, sin contar los datasets de fine-tuning ni los registros de inferencia.
Ceph resuelve esto con almacenamiento distribuido que unifica object storage (compatible con S3 de forma nativa), block storage y filesystem en un mismo cluster. Escala de terabytes a petabytes sin interrupciones, soporta erasure coding para eficiencia de almacenamiento y tiene integración nativa con Kubernetes via CSI. Para una factoría de IA, Ceph actúa como el backbone donde viven los pesos de los modelos, los datasets y los resultados.
Perspectiva SIXESomos Canonical Partner y llevamos años desplegando clusters Ceph en producción, incluyendo entornos de IA y HPC. Ceph no es “activar un checkbox”: requiere dimensionamiento cuidadoso, diseño de red y políticas de replicación adaptadas a la carga. En clusters de 3 nodos hay consideraciones de quórum que conviene no improvisar. Ofrecemos formación específica en administración Ceph y soporte para que tu equipo opere Ceph con autonomía real.
OpenStack: tu cloud privado con gestión nativa de GPUs
OpenStack es lo que convierte tu hardware en un cloud privado enterprise. Para una factoría de IA, su función principal es la gestión de recursos GPU: PCI passthrough para acceso directo a la GPU desde la VM, vGPU para compartir una GPU física entre múltiples cargas de trabajo, y NVIDIA MIG (Multi-Instance GPU) para particionar GPUs A100 y H100 en instancias independientes.
Bajo la Linux Foundation desde 2024, OpenStack opera en producción con más de 45 millones de cores en organizaciones como Walmart, GEICO o LINE Corp. No es una tecnología emergente: es infraestructura probada a escala real, con gobernanza independiente que garantiza continuidad.
Detalle importanteOpenStack no es trivial. Comprende más de 30 proyectos de servicio y requiere equipos con experiencia en sistemas distribuidos. Si tu equipo viene de VMware, la curva de aprendizaje existe. Nuestro servicio incluye formación práctica específica para que puedan operar el stack de forma autónoma, sin dependencia de consultoría a largo plazo.
Kubernetes + vLLM: la capa de orquestación de inferencia
Kubernetes es el estándar CNCF para orquestar cargas de trabajo en contenedores, y tiene soporte nativo para GPU scheduling mediante el NVIDIA GPU Operator. Sobre Kubernetes se despliegan los motores de inferencia, siendo vLLM el más relevante en este momento para modelos de lenguaje.
vLLM implementa PagedAttention, una técnica que gestiona la memoria KV cache de forma eficiente y permite servir múltiples peticiones en paralelo sin desperdiciar VRAM. En benchmarks representativos, vLLM supera entre 3 y 5 veces el throughput de una implementación naive del mismo modelo. Expone una API compatible con OpenAI, lo que facilita la migración de aplicaciones que ya consumen GPT-4 o similares.
Para modelos de visión o embedding, Triton Inference Server (NVIDIA) complementa vLLM y permite optimizaciones específicas por hardware como TensorRT-LLM.
¿Y cómo le damos forma a la factoría de IA?
Arquitectura de referencia: del dato al modelo en producción
Una factoría de IA on-premise con este stack sigue un flujo de cuatro capas. No es el único diseño posible, pero sí el que mejor balancea complejidad operacional, rendimiento y portabilidad.
01 — Datos
Ceph S3
Modelos, datasets, resultados de inferencia. API compatible S3 para integración con pipelines MLOps.
02 — Cómputo
OpenStack
GPU scheduling, bare metal, redes aisladas por proyecto. PCI passthrough y MIG para máxima eficiencia.
03 — Orquestación
Kubernetes
GPU Operator, autoscaling de pods de inferencia, gestión del ciclo de vida de los deployments.
04 — Producción
vLLM / Triton
APIs de inferencia, RAG, agentes. Compatibilidad OpenAI para integración sin fricción.
La clave de este diseño es que cada capa es independiente y reemplazable. Si mañana aparece un orquestador mejor que Kubernetes para cargas de IA, puedes sustituirlo sin tocar el almacenamiento ni la capa de cómputo. Eso es lo que significa no tener vendor lock-in: no es solo que el software sea open source, sino que la arquitectura tiene separación de responsabilidades real.
¿Sirve para mi empresa?
Quién necesita una factoría de IA on-premise
No todos los sectores tienen la misma urgencia ni las mismas restricciones. Hay cuatro ámbitos donde la infraestructura propia no es una opción: es la única respuesta posible.
Sanidad y farmacéutica
Historiales clínicos, imágenes diagnósticas, datos genómicos. El RGPD y el Reglamento de Datos Sanitarios de la UE prohíben transferencias a terceros países sin salvaguardias explícitas. La inferencia on-premise es la arquitectura de cumplimiento por defecto. Ceph para IA y HPC ofrece el almacenamiento masivo que estos entornos necesitan.
Banca y seguros
Scoring crediticio, detección de fraude, análisis de riesgo. Las directrices de la EBA sobre uso de IA en servicios financieros y el EU AI Act clasifican estos sistemas como de alto riesgo, con requisitos de trazabilidad y control que solo se cumplen on-premise.
Sector público y defensa
Soberanía tecnológica, ENS, datos clasificados. La Estrategia Nacional de Inteligencia Artificial de España exige que los sistemas de IA de uso público se operen sobre infraestructura europea o nacional. Sin discusión posible.
Industria y manufactura
Visión artificial en línea de producción, mantenimiento predictivo, control de calidad. La latencia de cloud no es viable cuando necesitas respuesta en milisegundos en la planta. La inferencia edge o datacenter propio es el único modelo que funciona.
FAQ
Las preguntas que hay que responder antes de empezar
Montar una factoría de IA on-premise no es un proyecto de fin de semana. Requiere análisis previo honesto sobre cuatro dimensiones que determinan si tiene sentido y cómo hacerlo bien.
¿Qué modelos vas a servir y cuántas peticiones?
El dimensionamiento de GPU depende directamente del tamaño de los modelos (número de parámetros y precisión) y del throughput objetivo (peticiones por segundo, latencia P99 aceptable). Un modelo de 7B parámetros en float16 cabe en una GPU L40S de 48 GB. Un modelo de 70B necesita varias GPUs con tensor parallelism. No hay atajos aquí: el dimensionamiento correcto requiere conocer las cargas reales, no estimaciones optimistas.
¿Tiene tu equipo la capacidad para operar este stack?
La pregunta más importante y la que menos se hace. Un equipo con experiencia en Linux, Kubernetes y sistemas distribuidos puede aprender a operar este stack. Pero si partes de cero, la curva de aprendizaje tiene que estar dentro del plan, no fuera. En SIXE ofrecemos formación certificada en Ceph, OpenStack y Kubernetes (como IBM BP y Canonical Partner) precisamente para que la transición no dependa de consultoría indefinida.
¿Cuál es el TCO real a 3 años?
El software es open source, así que no hay coste de licencias. La inversión es hardware (GPUs, servidores, networking de alta velocidad) más la formación del equipo. Comparado con el coste de GPU en cloud a ese mismo volumen de inferencia, los números suelen hablar solos. Pero el modelo financiero tiene que incluir mantenimiento, actualizaciones y el tiempo de operación del equipo. Nada es gratis, y los proyectos que parten de esa premisa acaban teniendo sorpresas desagradables.
Cómo trabajamos en SIXEAntes de cualquier despliegue, hacemos una evaluación de arquitectura donde auditamos tus cargas de trabajo reales, requisitos de latencia, volumen de datos y obligaciones regulatorias. Entregamos un diseño completo: dimensionamiento GPU, topología de red, almacenamiento Ceph y plan de capacidad a 12–24 meses. Sin humo, sin promesas de ahorro que no hemos calculado. Solo un análisis técnico sobre si tiene sentido y cómo ejecutarlo.
Tu factoría de IA, con el stack que usamos nosotros
IBM Business Partner y Canonical Partner. Más de 15 años desplegando open source en producción. Diseñamos la arquitectura, formamos a tu equipo y te acompañamos hasta que la infraestructura funciona sola. Nuestro trabajo termina cuando el tuyo empieza de verdad.
