> ## Content Index
> Fetch the complete content index at: https://jonathancanales.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Infraestructura de IA: la cocina detrás del chef
- URL: https://jonathancanales.com/infraestructura-de-ia-cocina-detras-del-chef/
- Published: 2026-10-16T14:00:00.000Z
- Updated: 2026-10-19T01:02:04.000Z
- Description: El modelo es el chef; la infraestructura es la cocina. Un recorrido sin prisa por las cinco piezas que hacen que una aplicación de IA funcione todos los días.
- Author: Jonathan Canales
- Tags: Tecnología y herramientas

Infraestructura de IA: la cocina detrás del chef

0:00

/782

1×

[![Escucha en Spotify](https://jonathancanales.com/content/images/2026/10/image-ebade917.jpg)](https://open.spotify.com/show/5cVfvljDnEEZ322kIJEs9Q?ref=jonathancanales.com)

## La IA no vive sola: el edificio que nadie ve

Cuando alguien usa un asistente de IA, ve una caja de texto y una respuesta que llega en segundos. Parece magia ligera, casi sin peso. Pero detrás de esa caja hay un edificio completo: computadoras muy potentes, almacenes de datos, cables que mueven información a toda velocidad, equipos que vigilan que todo funcione y puertas con llave para que solo entre quien debe.

A ese edificio se le llama **infraestructura de IA**. No es tan famoso como los modelos, pero es el que decide si una aplicación de IA responde rápido, cuesta lo razonable y sigue funcionando un martes a las tres de la tarde cuando llegan mil personas al mismo tiempo.

Este artículo es un recorrido sin prisa por ese edificio. La idea es que, al terminar, tengas un mapa mental claro: qué piezas hay, para qué sirve cada una y qué preguntas conviene hacer cuando alguien te dice "[vamos a montar esto con IA](https://jonathancanales.com/construir-una-empresa-con-agentes-de-ia-cuatro-etapas/)".

## La cocina y el chef

Una forma sencilla de verlo: el modelo de IA es el chef. Tiene talento, receta y buen gusto. Pero un chef sin cocina no sirve de nada. Necesita estufas potentes, un refrigerador lleno, ayudantes que le pasen los ingredientes en el momento justo, un sistema de pedidos y alguien que revise que la comida salga caliente y a tiempo.

La infraestructura es la cocina. Y igual que en un restaurante, una cocina bien diseñada hace que el mismo chef sirva más platillos, más rápido y con menos desperdicio.

![Una estufa cuyas cuatro hornillas son racks de servidores dibujados a mano, un gorro de chef sobre uno, vapor que se convierte en palomita y una sola flama naranja.](https://jonathancanales.com/content/images/2026/10/vrq-doodle-1-pagegray.png)

💡

Idea para quedarte: un modelo es solo una parte. Para que una aplicación de IA funcione de verdad hacen falta cómputo, datos, almacenamiento, red y una plataforma que lo coordine.

## Las cinco piezas del edificio

Casi toda la infraestructura de IA se puede ordenar en cinco bloques.

- **Datos.** Son los ingredientes: textos, imágenes, registros, documentos. Antes de usarse hay que limpiarlos, ordenarlos y moverlos hacia donde se necesitan. A ese recorrido se le llama "pipeline de datos".
- **Cómputo.** Son las estufas. Aquí entran los procesadores (CPU) y, sobre todo, las tarjetas gráficas (GPU), que son muy buenas haciendo millones de cuentas a la vez. También existen chips especializados llamados TPU.
- **Almacenamiento.** Es la despensa y el refrigerador: dónde viven los conjuntos de datos, los archivos del modelo y los puntos de guardado del entrenamiento.
- **Red.** Son los pasillos de la cocina. Si son angostos, todo se atora. Por eso en IA importan tanto el ancho de banda y la baja espera entre máquinas.
- **Plataforma.** Es el jefe de cocina que coordina: contenedores, orquestadores, herramientas de seguimiento, monitoreo y control de acceso.

Lo bonito de esta lista es que funciona igual para un proyecto pequeño y para uno gigante. Cambia el tamaño, no el mapa.

## Dos trabajos distintos: entrenar y servir

Hay dos momentos en la vida de un modelo, y cada uno pide cosas distintas.

**Entrenar** es enseñarle al modelo. Es un trabajo largo, intenso y con fecha de término: se le dan muchos datos, se ajusta una y otra vez, y al final se guarda el resultado. Aquí lo que más importa es tener mucha potencia durante un rato.

**Servir** (en inglés, "inference") es usar el modelo ya entrenado para responder a personas reales. Es un trabajo que nunca se apaga: tiene que estar disponible todo el día, contestar rápido y crecer cuando llega más gente. Aquí lo que más importa es la constancia y el tiempo de respuesta.

Pensar en estos dos trabajos por separado ayuda a decidir bien. Entrenar se parece a una obra con inicio y final; servir se parece a atender un local abierto todos los días.

## Contenedores y Kubernetes: cajas ordenadas

Para que algo corra igual en tu computadora, en la de un colega y en un centro de datos, se usan **contenedores**. Un contenedor es una caja cerrada que lleva dentro el programa y todo lo que necesita para funcionar. Si funciona en una caja, funciona en todas.

Cuando tienes muchas cajas, alguien tiene que acomodarlas. Ese es el trabajo de **Kubernetes**, una plataforma de código abierto que reparte, escala y repara aplicaciones en contenedores. Algunas palabras que vas a escuchar:

- **Pod:** la unidad más pequeña; corre uno o más contenedores.
- **Deployment:** mantiene varias copias de una aplicación, por ejemplo, un servicio que responde preguntas.
- **Job:** una tarea que corre hasta terminar, como un entrenamiento.
- **Service e Ingress:** la puerta por donde entran las peticiones.
- **Volumen persistente:** un espacio de guardado que sobrevive aunque el contenedor se reinicie.

La regla práctica: los servicios que atienden a la gente se montan como Deployments; los entrenamientos, como Jobs.

![Una grúa de puerto baja un contenedor naranja sobre una fila de contenedores blancos apilados, dibujado a mano.](https://jonathancanales.com/content/images/2026/10/vrq-doodle-2-pagegray.png)

## Pedir una GPU: una regla curiosa

En Kubernetes cada contenedor puede pedir una cantidad de CPU y de memoria, con un mínimo garantizado ("request") y un máximo permitido ("limit"). Esto evita que una aplicación se coma todos los recursos de la máquina.

Con las GPU hay un detalle que la documentación oficial explica con claridad: las GPU se indican en la sección de límites. Puedes poner solo el límite y Kubernetes lo usará también como mínimo; si pones ambos, deben ser iguales. Es decir, una GPU no se reparte "a pedacitos" como la memoria: se asigna completa a un contenedor.

Para que el clúster sepa que existen GPU, hace falta software que las exponga. Herramientas como el NVIDIA GPU Operator automatizan la instalación de lo necesario: controladores, el plugin de dispositivos, el kit de contenedores y el etiquetado de nodos. Es como contratar a alguien que deja las estufas listas antes de que llegue el chef.

💡

Dato para recordar: en Kubernetes, una GPU se pide en "limits"; si también se pone en "requests", ambos valores deben coincidir.

## Cómo es un entrenamiento por dentro

Un entrenamiento tiene una secuencia bastante ordenada: se preparan los datos, se envían a los aceleradores (GPU o TPU), el modelo aprende por rondas llamadas "épocas", se evalúa con datos que no vio y, si todo va bien, se guarda el resultado final.

Dos ideas lo hacen manejable:

**Puntos de guardado (checkpoints).** Entrenar puede tardar horas o días. Un checkpoint es una foto del estado del modelo en un momento dado. Si la máquina se reinicia, retomas desde la última foto y no desde cero. Es como guardar la partida en un videojuego.

**Entrenamiento en varias GPU.** Cuando el modelo o los datos son grandes, se reparte el trabajo. En PyTorch, la herramienta DistributedDataParallel recomienda lanzar un proceso por cada copia del modelo, y una misma GPU no se comparte entre esos procesos. En cristiano: cada ayudante tiene su propia estufa.

Además, conviene decidir los recursos según el trabajo: tamaño del modelo, tamaño de los datos y tiempo disponible. Y revisar el uso de GPU, memoria, red y almacenamiento mientras corre, para ajustar a tiempo.

## MLOps: ordenar la receta

MLOps junta tres mundos: aprendizaje automático, desarrollo de software y manejo de datos. Su meta es que un modelo pase de ser un experimento a ser algo confiable en producción. Se apoya en prácticas sencillas:

- **Versionar el modelo.** Saber cuál es la versión 1.0, cuál la 1.1 y cuál es la que está en uso hoy.
- **Registrar los experimentos.** Herramientas como MLflow guardan parámetros, métricas, versión del código y archivos de salida de cada corrida, para comparar y entender qué funcionó.
- **Poder repetir resultados.** Guardar el código en Git, anotar dependencias, usar contenedores y fijar semillas aleatorias.
- **Automatizar.** Que el entrenamiento, las pruebas y el despliegue corran con un botón y no con un manual de veinte pasos.

Es lo mismo que hace una buena cocina con sus recetas: escritas, probadas, con fecha y fáciles de repetir.

## Seguridad: puertas con llave, cada una a su medida

Los datos, los modelos y las claves son un tesoro, así que la infraestructura incluye un buen sistema de acceso. Algunas prácticas, todas con respaldo en documentación oficial:

- **Dar solo el acceso necesario.** Cada persona o programa recibe permisos para lo que le toca y nada más.
- **Usar credenciales temporales.** La guía de buenas prácticas de AWS recomienda que las aplicaciones usen roles con credenciales temporales y que las personas usen verificación en dos pasos.
- **Correr contenedores sin permisos de administrador.** Los estándares de seguridad de Kubernetes piden que los contenedores corran como usuario no administrador, y las guías de Docker explican cómo crear ese usuario dentro de la imagen.
- **Guardar secretos en un lugar propio,** no pegados dentro del código.

La seguridad se disfruta más cuando se planea desde el principio. Agregarla al final siempre es más trabajo.

## Vigilar y cuidar el presupuesto

Una vez que todo corre, hay dos preguntas diarias: ¿está funcionando bien? y ¿cuánto estamos gastando? Para la primera sirven los paneles de monitoreo: tiempo de respuesta, uso de GPU, memoria y alertas. Para la segunda, apagar lo que no se usa, ajustar el tamaño de los recursos y escalar según la demanda real.

Las GPU son de lo más valioso del edificio, así que aprovecharlas bien suele ser el mayor ahorro posible.

## Un ejemplo de punta a punta

Imagina [un asistente para atender dudas de clientes](https://jonathancanales.com/necesitas-un-chatbot-un-copiloto-o-un-agente-de-ia/) en una página web.

1. Los documentos de la empresa se guardan y se ordenan en la capa de datos.
2. Un trabajo de entrenamiento corre en un clúster con GPU y guarda checkpoints cada cierto tiempo.
3. El resultado se versiona y se guarda en un registro de modelos.
4. El modelo se publica como un servicio con varias copias, detrás de una puerta de entrada con autenticación.
5. La gente escribe desde la página y la respuesta llega en segundos.
6. Los paneles de monitoreo muestran tiempos de respuesta y uso de GPU, y los datos nuevos alimentan la siguiente versión.

Fíjate que el modelo es un solo paso de seis. Los otros cinco son infraestructura.

![Seis cajas en fila unidas por flechas; la cuarta es naranja y brilla, y una llave abarca las seis por debajo.](https://jonathancanales.com/content/images/2026/10/vrq-doodle-3-pagegray.png)

## Cinco preguntas para llevar en el bolsillo

1. ¿Dónde vive el modelo y quién puede entrar a él?
2. ¿Qué pasa cuando llegan diez veces más personas de las esperadas?
3. ¿Cómo nos enteramos de que algo se está poniendo lento?
4. ¿Cuánto cuesta cada hora de GPU y cómo la aprovechamos mejor?
5. ¿Cómo publicamos una versión nueva sin interrumpir el servicio?

Con esas cinco preguntas ya puedes sostener una conversación útil sobre cualquier proyecto de IA, sin necesidad de ser ingeniero.

## Para cerrar

Los modelos son la parte que se ve y se comenta. La infraestructura es la parte que hace que funcionen todos los días, para todas las personas, sin sobresaltos. Entender el edificio, aunque sea a grandes rasgos, te da una ventaja enorme: dejas de ver la IA como una caja mágica y empiezas a verla como un sistema que se puede planear, medir y mejorar.

La próxima vez que una respuesta de IA te llegue en dos segundos, piensa en la cocina que hay detrás. Mucha gente trabajó para que esa estufa estuviera caliente.

## Fuentes

Kubernetes. Schedule GPUs: [https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/?ref=jonathancanales.com)

Kubernetes. Resource Management for Pods and Containers: [https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/?ref=jonathancanales.com)

Kubernetes. Pod Security Standards: [https://kubernetes.io/docs/concepts/security/pod-security-standards/](https://kubernetes.io/docs/concepts/security/pod-security-standards/?ref=jonathancanales.com)

NVIDIA. About the NVIDIA GPU Operator: [https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html?ref=jonathancanales.com)

PyTorch. Getting Started with Distributed Data Parallel: [https://pytorch.org/tutorials/intermediate/ddp\_tutorial.html](https://pytorch.org/tutorials/intermediate/ddp%5Ftutorial.html?ref=jonathancanales.com)

MLflow. ML Experiment Tracking: [https://mlflow.org/docs/latest/ml/tracking/](https://mlflow.org/docs/latest/ml/tracking/?ref=jonathancanales.com)

AWS. Security best practices in IAM: [https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html?ref=jonathancanales.com)

Docker. Building best practices: [https://docs.docker.com/build/building/best-practices/](https://docs.docker.com/build/building/best-practices/?ref=jonathancanales.com)