Capítulo 7: Ecosistema, herramientas y hardware de la IA en 2026¶

Módulo 01 — FUNDAMENTOS · Capítulo 7 de 7 (último capítulo teórico del módulo)

Tiempo estimado de lectura: 90-120 minutos · Nivel: fundamentos (con Python básico)

Hasta ahora has aprendido qué es la inteligencia artificial, cómo aprende una máquina y has escrito tus primeras líneas de Python. Te falta una pieza fundamental antes de empezar a construir: el mapa del territorio.

La industria de la IA en 2026 es un ecosistema enorme, con cientos de empresas, decenas de frameworks y una avalancha constante de anuncios. Sin un mapa mental claro, es fácil perderse: no sabrás qué herramienta elegir, qué noticias importan y cuáles son ruido, ni dónde encajas tú profesionalmente.

Este capítulo es ese mapa. Al terminarlo sabrás:

Cómo se organiza la industria por capas, desde el silicio hasta las aplicaciones.
Por qué la IA moderna vive sobre GPUs y qué significa eso para ti.
Quiénes son los proveedores de modelos y cómo compararlos con criterio.
Qué papel juega el cloud y cuándo usar cada opción.
Qué framework o librería usar para cada propósito (y cuándo NO usarlos).
Qué es MCP y por qué los protocolos importan tanto como los modelos.
El stack de esta academia, justificado decisión a decisión.
Los roles profesionales del mercado y cómo prepararte para cada uno.
Cómo mantenerte actualizado sin ahogarte en hype.

Nota

este capítulo describe el panorama por familias y tendencias, no por versiones concretas. Los nombres de modelos, los precios y las cifras exactas cambian cada pocos meses; las estructuras que aprenderás aquí (capas, criterios de decisión, categorías de herramientas) son mucho más estables y te servirán durante toda la academia y tu carrera.

Índice¶

El mapa de la industria por capas
1.1 El diagrama completo
1.2 Capa por capa: qué hace cada una y quién vive ahí
1.3 ¿Dónde trabajarás tú?
Hardware: por qué la IA necesita GPUs
2.1 La intuición: cocineros expertos vs. miles de ayudantes
2.2 CPU vs GPU vs TPU vs NPU: tabla comparativa
2.3 NVIDIA y CUDA: la anatomía de un foso competitivo
2.4 VRAM: la memoria que manda
2.5 Entrenamiento vs. inferencia en hardware
2.6 Qué necesitas TÚ realmente como estudiante
Proveedores de modelos fundacionales
3.1 Los grandes laboratorios
3.2 Tabla comparativa de proveedores
3.3 Propietarios vs. open weights
3.4 Tabla de decisión empresarial
Cloud para IA
4.1 Los tres hyperscalers
4.2 Las alternativas especializadas
4.3 ¿API directa o cloud provider?
Frameworks y librerías por propósito
5.1 Tabla maestra de frameworks
5.2 Cada herramienta en profundidad
5.3 Qué framework se usa en qué módulo de la academia
Protocolos y estándares
6.1 MCP: el "USB-C de la IA"
6.2 Function calling
6.3 APIs REST y streaming
El stack de esta academia, decisión a decisión
Roles y mercado laboral
Cómo mantenerse actualizado sin ahogarse
Buenas prácticas
Errores comunes
Preguntas frecuentes (FAQ)
Resumen del capítulo
Bibliografía y enlaces oficiales

1. El mapa de la industria por capas¶

La mejor forma de entender la industria de la IA es verla como un edificio de capas apiladas: cada capa consume los servicios de la capa inferior y ofrece los suyos a la superior. Es la misma lógica que ya conoces de la informática tradicional (hardware → sistema operativo → aplicaciones), pero adaptada a la era de los modelos fundacionales.

1.1 El diagrama completo¶

flowchart TB
    subgraph L6["CAPA 6 — APLICACIONES"]
        direction LR
        A1["Productos de IA<br/>(asistentes, copilots,<br/>agentes verticales)"]
        A2["Software tradicional<br/>+ funciones de IA<br/>(CRM, ERP, ofimática)"]
        A3["Automatizaciones<br/>internas de empresa"]
    end

    subgraph L5["CAPA 5 — FRAMEWORKS Y ORQUESTACIÓN"]
        direction LR
        F1["LangChain / LangGraph<br/>LlamaIndex"]
        F2["SDKs oficiales<br/>(anthropic, openai)"]
        F3["Vercel AI SDK<br/>n8n"]
        F4["PyTorch / JAX<br/>Hugging Face<br/>scikit-learn"]
    end

    subgraph L4["CAPA 4 — APIs Y PLATAFORMAS DE ACCESO"]
        direction LR
        P1["APIs directas<br/>(Anthropic, OpenAI,<br/>Google, Mistral)"]
        P2["Plataformas cloud<br/>(Bedrock, Vertex,<br/>Azure AI Foundry)"]
        P3["Inferencia especializada<br/>(Together, Groq,<br/>Replicate, Modal)"]
    end

    subgraph L3["CAPA 3 — MODELOS FUNDACIONALES"]
        direction LR
        M1["Propietarios<br/>Claude · GPT · Gemini"]
        M2["Open weights<br/>Llama · Mistral<br/>DeepSeek · Qwen"]
    end

    subgraph L2["CAPA 2 — CLOUD E INFRAESTRUCTURA"]
        direction LR
        C1["Hyperscalers<br/>AWS · Google Cloud · Azure"]
        C2["Clouds de GPU<br/>especializados"]
        C3["Centros de datos<br/>propios de los labs"]
    end

    subgraph L1["CAPA 1 — HARDWARE"]
        direction LR
        H1["GPUs<br/>(NVIDIA, AMD)"]
        H2["TPUs y aceleradores<br/>a medida (Google,<br/>AWS, otros)"]
        H3["NPUs en dispositivos<br/>(móviles, portátiles)"]
    end

    L1 --> L2 --> L3 --> L4 --> L5 --> L6

    style L1 fill:#ffe5e5,stroke:#c0392b
    style L2 fill:#fff7d6,stroke:#b7950b
    style L3 fill:#ffe8d6,stroke:#ca6f1e
    style L4 fill:#f0e0ff,stroke:#7d3c98
    style L5 fill:#dbeeff,stroke:#2471a3
    style L6 fill:#e0f5e0,stroke:#1e8449

Léelo de abajo hacia arriba: el hardware alimenta al cloud, el cloud entrena y sirve los modelos, los modelos se exponen mediante APIs, las APIs se consumen con frameworks, y con los frameworks se construyen aplicaciones. El valor (y el dinero) fluye en ambas direcciones.

1.2 Capa por capa: qué hace cada una y quién vive ahí¶

Capa 1 — Hardware. Aquí se fabrican los chips que hacen posible todo lo demás. El actor dominante es NVIDIA con sus GPUs de centro de datos; AMD compite con su propia línea de aceleradores; Google diseña sus TPUs; AWS tiene chips propios de entrenamiento e inferencia; y fabricantes como Apple o Qualcomm integran NPUs en dispositivos de consumo. Es una capa intensiva en capital: construir una fábrica de semiconductores o un chip competitivo cuesta miles de millones y años de trabajo. Casi nadie que lea esto trabajará dentro de esta capa, pero entenderla es imprescindible (sección 2).

Capa 2 — Cloud e infraestructura. Los chips por sí solos no sirven: hay que agruparlos en centros de datos con redes de altísima velocidad, refrigeración y software de orquestación. Aquí viven los hyperscalers (AWS, Google Cloud, Microsoft Azure), los clouds especializados en GPU que alquilan capacidad de cómputo, y los centros de datos propios de los grandes laboratorios. Esta capa convierte hardware en un servicio que se alquila por horas.

Capa 3 — Modelos fundacionales. La capa más mediática. Laboratorios como Anthropic, OpenAI, Google DeepMind, Meta AI, Mistral, DeepSeek o el equipo Qwen de Alibaba entrenan modelos gigantes sobre la infraestructura de la capa 2. Algunos publican solo acceso por API (modelos propietarios); otros liberan los pesos para que cualquiera los ejecute (open weights). Sección 3 al completo.

Capa 4 — APIs y plataformas de acceso. El modelo entrenado hay que servirlo: recibir peticiones, ejecutar inferencia, facturar, controlar abusos. Puedes acceder a los modelos por API directa del laboratorio, a través de las plataformas de los hyperscalers (Bedrock, Vertex, Azure AI Foundry) o mediante proveedores de inferencia especializados que sirven modelos open weights con gran rendimiento. Sección 4.

Capa 5 — Frameworks y orquestación. Las librerías con las que un ingeniero conecta modelos con datos, herramientas y lógica de negocio: LangChain/LangGraph, LlamaIndex, los SDKs oficiales, Hugging Face, PyTorch, Vercel AI SDK, n8n… Es la capa donde un desarrollador pasa la mayor parte de su tiempo. Sección 5.

Capa 6 — Aplicaciones. Lo que ve el usuario final: asistentes, copilots de programación, agentes de atención al cliente, buscadores internos de documentos, automatizaciones. Es la capa con más empresas, más empleo y más oportunidades de emprendimiento, porque construir aquí no requiere entrenar modelos ni comprar GPUs: requiere entender un problema de negocio y saber orquestar las capas inferiores.

Nota

las fronteras entre capas son porosas. Google está en las capas 1, 2, 3, 4 y 6 a la vez. Meta entrena modelos (capa 3) y los libera para que otros los sirvan (capa 4). Esta integración vertical es una de las grandes dinámicas competitivas de la industria.

1.3 ¿Dónde trabajarás tú?¶

La inmensa mayoría de los profesionales de IA —y el foco de esta academia— trabajan en las capas 4, 5 y 6: consumir modelos vía API, orquestarlos con frameworks y construir aplicaciones que resuelven problemas reales.

Capa	¿Quién trabaja aquí?	¿Cuánta gente?	¿Te prepara esta academia?
1. Hardware	Ingenieros de semiconductores, física, electrónica	Muy pocos, ultra especializados	No (fuera de alcance)
2. Cloud/infra	SRE, ingenieros de plataforma, HPC	Pocos, especializados	Parcialmente (módulo de despliegue)
3. Modelos	Investigadores ML, ingenieros de entrenamiento	Muy pocos (los grandes labs contratan a cientos, no a millones)	Fundamentos sí; investigación no
4. APIs/plataformas	Ingenieros de plataforma e inferencia	Pocos	Como consumidor, a fondo
5. Frameworks	Ingenieros de IA, desarrolladores de herramientas	Bastantes	Sí, a fondo
6. Aplicaciones	AI Engineers, full-stack, consultores, founders	La gran mayoría	Sí, es el corazón de la academia

Consejo profesional

cuando leas una noticia de IA, pregúntate primero "¿de qué capa habla?". Un anuncio de un chip nuevo (capa 1) tardará años en afectarte; un cambio de precios en una API (capa 4) puede afectar a tu proyecto mañana; un framework nuevo (capa 5) merece una tarde de exploración, no una reescritura de tu stack. Clasificar por capas es el primer filtro antihype.

2. Hardware: por qué la IA necesita GPUs¶

2.1 La intuición: cocineros expertos vs. miles de ayudantes¶

Imagina dos cocinas:

La cocina CPU: tiene pocos cocineros, pero son chefs de élite. Cada uno puede ejecutar recetas complejísimas, tomar decisiones sobre la marcha, cambiar de plato en segundos. Si le pides un plato elaborado con veinte pasos dependientes entre sí, nadie lo hace mejor.
La cocina GPU: tiene miles de ayudantes de cocina. Ninguno sabe hacer un plato completo, pero si les pides "pelad un millón de patatas", cada uno pela las suyas a la vez y terminan en minutos lo que a los chefs les llevaría semanas.

¿Y qué es la IA moderna computacionalmente? Es, en su inmensa mayoría, multiplicar matrices gigantes: millones y millones de operaciones aritméticas sencillas (multiplicar, sumar) que no dependen unas de otras y pueden ejecutarse en paralelo. Es el trabajo de pelar patatas perfecto.

Una CPU moderna tiene del orden de decenas de núcleos muy potentes, optimizados para ejecutar lógica secuencial compleja con saltos, condiciones y acceso impredecible a memoria.
Una GPU moderna tiene miles de núcleos sencillos, optimizados para aplicar la misma operación a enormes bloques de datos simultáneamente (arquitectura llamada SIMT: single instruction, multiple threads).

Cuando en el capítulo 6 vimos que "aprender" es ajustar millones de pesos calculando gradientes, cada paso de ese ajuste son multiplicaciones de matrices. Por eso el descubrimiento (hacia 2012, con AlexNet) de que las GPUs —diseñadas originalmente para renderizar videojuegos, otro problema de "misma operación sobre millones de píxeles"— aceleraban el entrenamiento de redes neuronales en órdenes de magnitud fue uno de los detonantes del boom del deep learning.

Advertencia

"la GPU es más rápida que la CPU" es falso como afirmación general. La GPU es más rápida solo para cargas masivamente paralelas. Para lógica de negocio, servidores web, bases de datos o scripts normales de Python, la CPU sigue siendo la reina. Por eso tu aplicación de IA típica usa CPU para el backend y delega en GPUs remotas (vía API) solo la inferencia del modelo.

2.2 CPU vs GPU vs TPU vs NPU: tabla comparativa¶

Característica	CPU	GPU	TPU	NPU / aceleradores edge
Metáfora	Pocos chefs de élite	Miles de ayudantes	Fábrica dedicada a un solo plato	Microondas de casa: pequeño pero siempre disponible
Núcleos	Decenas, muy complejos	Miles, sencillos	Matrices sistólicas especializadas en multiplicación de matrices	Pequeños bloques dedicados dentro de otro chip
Optimizada para	Lógica secuencial, saltos, tareas generales	Paralelismo masivo de datos	Exclusivamente operaciones de redes neuronales a gran escala	Inferencia ligera y eficiente en el dispositivo
Fabricantes típicos	Intel, AMD, ARM (Apple, Qualcomm…)	NVIDIA (dominante), AMD	Google (uso propio y alquiler en Google Cloud)	Apple, Qualcomm, Samsung, Intel… integradas en móviles y portátiles
Dónde la encuentras	Todos los ordenadores	Gaming, workstations, centros de datos	Solo en centros de datos de Google	Tu móvil y tu portátil recientes
Rol en IA	Preprocesado, orquestación, backend	Entrenamiento e inferencia: el caballo de batalla	Entrenamiento e inferencia dentro del ecosistema Google	Inferencia local pequeña (dictado, cámara, modelos compactos)
Flexibilidad	Máxima	Alta (programable con CUDA y similares)	Baja (solo ML, mejor con JAX/TensorFlow)	Muy baja (modelos optimizados para el chip)
Consumo eléctrico por operación de IA	Alto	Medio	Bajo (a escala)	Muy bajo

Nota

existen además aceleradores de inferencia especializados de otras empresas (por ejemplo, arquitecturas orientadas a servir LLMs con latencias muy bajas, como las de Groq o Cerebras). No necesitas memorizar marcas: quédate con la idea de que cuanto más especializado el chip, más eficiente pero menos flexible.

2.3 NVIDIA y CUDA: la anatomía de un foso competitivo¶

Si la GPU es el caballo de batalla, ¿por qué NVIDIA en concreto domina el mercado de forma tan aplastante? La respuesta corta: no vende chips, vende un ecosistema. Y el corazón de ese ecosistema se llama CUDA.

CUDA (Compute Unified Device Architecture) es la plataforma de programación que NVIDIA lanzó en 2007 para que los desarrolladores pudieran usar sus GPUs para cómputo general, no solo gráficos. Casi dos décadas después, el resultado es un foso competitivo (moat) de manual:

Software acumulado: prácticamente todo el software de deep learning (PyTorch, TensorFlow, vLLM, los kernels optimizados de atención, las librerías de álgebra lineal cuDNN/cuBLAS…) fue escrito y optimizado primero —y a veces únicamente— para CUDA.
Conocimiento acumulado: una generación entera de ingenieros ML aprendió a programar y depurar sobre CUDA. Cambiar de plataforma significa reaprender herramientas, perfiles de rendimiento y trucos.
Efecto de red: como todo el mundo usa CUDA, las nuevas librerías se optimizan para CUDA, lo que hace que más gente use NVIDIA, lo que hace que… el círculo se refuerza solo.
Integración vertical: NVIDIA también vende la red de interconexión entre GPUs (clave para entrenar modelos que no caben en un solo chip) y sistemas completos listos para centro de datos.

¿Competencia? Existe y crece: AMD empuja su plataforma ROCm, Google ofrece TPUs, los hyperscalers diseñan chips propios para reducir su dependencia, y proyectos como Triton u OpenXLA intentan crear capas de software portables entre fabricantes. La presión para "des-CUDAizar" el ecosistema es real, sobre todo en inferencia (donde el software es más simple que en entrenamiento). Pero a día de hoy, cuando una empresa quiere entrenar en serio, la opción por defecto sigue siendo NVIDIA.

Consejo profesional

esto tiene una lección de carrera que va más allá del hardware: las plataformas ganan por su ecosistema, no por su ficha técnica. Lo verás repetirse en este capítulo con los clouds, los frameworks y los protocolos. Cuando evalúes una tecnología, pregunta siempre: ¿cuánta comunidad, documentación, tooling y talento hay alrededor?

2.4 VRAM: la memoria que manda¶

Cuando la gente compara GPUs suele mirar la velocidad de cómputo. Para trabajar con LLMs, el número que de verdad manda es otro: la VRAM, la memoria propia de la GPU.

¿Por qué? Porque para ejecutar un modelo, sus pesos tienen que estar cargados en la memoria de la GPU. Si no caben, el modelo directamente no se puede ejecutar (o hay que trocearlo entre varias GPUs, con gran complejidad y pérdida de velocidad).

La regla intuitiva que debes memorizar:

Cada parámetro del modelo ocupa memoria según su precisión numérica: - En precisión media (16 bits): ~2 bytes por parámetro → un modelo de 7.000 millones de parámetros (7B) necesita ~14 GB de VRAM solo para los pesos. - Cuantizado a 8 bits: ~1 byte por parámetro → ese mismo 7B baja a ~7 GB. - Cuantizado a 4 bits: ~0,5 bytes por parámetro → ~3,5-4 GB.

Y a eso hay que sumar memoria extra para el contexto de la conversación (la llamada KV cache, que crece con la longitud del contexto) y los buffers de trabajo. Regla de andar por casa: añade un 20-50 % sobre el tamaño de los pesos.

La cuantización (reducir la precisión de los números para que ocupen menos) es la razón por la que hoy es posible ejecutar modelos open weights pequeños y medianos en un portátil decente. Pierdes algo de calidad, ganas accesibilidad.

Ejemplos orientativos con la regla anterior:

Tamaño del modelo	16 bits	8 bits	4 bits	¿Dónde cabe?
~3B parámetros	~6 GB	~3 GB	~1,5-2 GB	Portátil normal, incluso sin GPU dedicada
~7-8B	~14-16 GB	~7-8 GB	~4-5 GB	Portátil con buena GPU o Mac con memoria unificada
~30-70B	60-140 GB	30-70 GB	15-35 GB	Workstation potente o varias GPUs / Mac de gama alta
Cientos de miles de millones (frontier)	Terabytes en la práctica (con contexto y paralelismo)	—	—	Solo clústeres de centro de datos

Advertencia

los modelos punteros (los "frontier" de Anthropic, OpenAI o Google) no se pueden ejecutar en casa y probablemente nunca podrás: requieren clústeres de GPUs interconectadas. Cualquier vídeo que te prometa "ejecuta GPT en tu portátil" habla en realidad de modelos open weights pequeños, que son útiles pero juegan en otra liga de calidad.

2.5 Entrenamiento vs. inferencia en hardware¶

Ya distinguiste conceptualmente entrenar de inferir en el capítulo 6. En hardware, la diferencia es abismal:

Dimensión	Entrenamiento	Inferencia
Qué hace	Ajustar los pesos con billones de ejemplos	Ejecutar el modelo ya entrenado para responder
Hardware típico	Clústeres de miles a cientos de miles de GPUs interconectadas	Desde una fracción de GPU hasta decenas, según demanda
Duración	Semanas o meses de cómputo continuo	Milisegundos a segundos por petición
Coste	De millones a cientos de millones por modelo frontier	Céntimos (o fracciones) por petición, pero se multiplica por millones de usuarios
Cuello de botella	Cómputo total y comunicación entre GPUs	Memoria (VRAM) y latencia
Quién lo hace	Solo los grandes laboratorios y empresas muy grandes	Todo el mundo, cada vez que llamas a una API
Frecuencia	Pocas veces (por versión de modelo)	Constante, 24/7

Dos consecuencias importantes para tu carrera:

El entrenamiento de modelos frontier está fuera del alcance de casi todas las empresas del mundo. No es tu mercado laboral realista, y no pasa nada: tampoco necesitas fabricar coches para ser un excelente ingeniero de automoción.
La inferencia es donde se gasta el dinero de forma recurrente y donde tú, como ingeniero de aplicaciones, tomas decisiones cada día: qué modelo usar, cuánto contexto enviar, si cachear respuestas, si usar un modelo pequeño para tareas simples. Optimizar inferencia = optimizar la factura.

Caso empresarial (adelanto)

en los módulos avanzados verás cómo una empresa puede reducir drásticamente su factura de IA con decisiones sencillas: enrutar el 80 % de las peticiones triviales a un modelo pequeño y barato, y reservar el modelo grande para el 20 % difícil. Esta técnica (model routing) solo se entiende si entiendes que la inferencia cuesta dinero por token procesado.

2.6 Qué necesitas TÚ realmente como estudiante¶

Respuesta corta: nada especial. En serio.

Para el 90 % de esta academia: cualquier ordenador razonable de los últimos años con navegador, Python y Docker. Trabajarás contra APIs (Anthropic, OpenAI, etc.), donde la GPU la pone el proveedor. Tu máquina solo ejecuta tu código de orquestación, que es trabajo de CPU ligero.
Para experimentar con modelos locales (lo haremos puntualmente con Ollama): un portátil con 16 GB de RAM te permite probar modelos pequeños cuantizados. Si tienes un Mac con memoria unificada amplia o un PC con GPU de gaming, podrás con modelos algo mayores. Es un extra interesante, no un requisito.
Para entrenar o hacer fine-tuning: alquilas GPU por horas en el cloud cuando llegue ese módulo, pagando solo lo que uses. Suele costar menos que una cena por experimento didáctico.

Advertencia

el error de novato más caro es comprarse una GPU potente "para aprender IA" antes de saber si la necesita. No lo hagas. Empieza con APIs (pago por uso, céntimos), usa niveles gratuitos, alquila GPU en cloud si algún día la necesitas. Compra hardware solo cuando tengas una necesidad concreta, recurrente y calculada — probablemente ese día no llegue nunca, porque el cloud casi siempre sale mejor.

Consejo profesional

invierte ese presupuesto en lo que sí marca la diferencia: crédito de API para experimentar sin miedo (unas decenas de euros dan para meses de aprendizaje), un buen editor, y tiempo. El activo escaso en IA no es la GPU: es el criterio, y eso es exactamente lo que estás construyendo aquí.

3. Proveedores de modelos fundacionales¶

3.1 Los grandes laboratorios¶

Conozcamos a los protagonistas de la capa 3. Para cada uno: qué es, qué ofrece, fortalezas, limitaciones y cuándo elegirlo o no.

Anthropic (Claude)¶

Qué es: laboratorio fundado en 2021 por ex-investigadores de OpenAI, con la seguridad y fiabilidad de la IA como principio fundacional. Su familia de modelos se llama Claude, tradicionalmente organizada en gamas por tamaño/coste (históricamente Haiku, Sonnet y Opus, de menor a mayor).
Qué ofrece: API directa, aplicaciones de consumo, herramientas para desarrolladores (como Claude Code, orientada a programación agéntica), y disponibilidad a través de AWS Bedrock y Google Cloud Vertex AI.
Fortalezas: reputación consistente en razonamiento complejo, escritura de calidad, programación y uso agéntico (seguir instrucciones largas, usar herramientas de forma fiable); contextos largos; fuerte cultura de seguridad y de comportamiento predecible del modelo; impulsor del protocolo MCP (sección 6).
Limitaciones: catálogo centrado en modelos de lenguaje/multimodales de gama alta (no cubre tantas modalidades periféricas como Google); solo modelos propietarios, sin open weights.
Cuándo elegirlo: asistentes y agentes donde la fiabilidad de instrucciones importa, programación asistida, análisis de documentos largos, aplicaciones empresariales con requisitos de comportamiento cuidadoso.
Cuándo NO: si necesitas pesos abiertos para ejecutar en tu propia infraestructura, o modalidades muy específicas que no ofrezca.

OpenAI (GPT)¶

Qué es: el laboratorio que detonó la era moderna con ChatGPT (2022). Familia de modelos GPT y modelos de razonamiento, más modelos de imagen, voz y vídeo.
Qué ofrece: API directa, la aplicación de consumo más famosa del mundo, y disponibilidad vía Azure (su socio principal).
Fortalezas: enorme base de usuarios y comunidad; catálogo amplio de modalidades (texto, imagen, audio, vídeo); mucha documentación, ejemplos y tutoriales de terceros; marca reconocida que facilita la aprobación de proyectos en empresas.
Limitaciones: solo propietario (salvo alguna liberación puntual de pesos); el ritmo de cambios de producto y nomenclatura puede ser mareante; historia de cambios de comportamiento entre versiones que obligan a re-evaluar prompts.
Cuándo elegirlo: prototipado rápido apoyado en abundancia de ejemplos, productos multimodales, o cuando el cliente ya está en el ecosistema Azure/OpenAI.
Cuándo NO: si necesitas open weights o control total de la infraestructura.

Google DeepMind (Gemini)¶

Qué es: la división de IA de Google (fusión de Google Brain y DeepMind). Familia Gemini (propietaria) y familia Gemma (open weights, más pequeña).
Fortalezas: integración profundísima con el ecosistema Google (Workspace, Android, Search, YouTube); multimodalidad nativa; contextos larguísimos que han sido su bandera; y la ventaja estructural de tener chips propios (TPUs) y cloud propio: controla toda la pila.
Limitaciones: la experiencia de desarrollador está repartida entre varias superficies (AI Studio, Vertex AI…) y puede confundir al principio; historial de productos renombrados o descontinuados que exige atención.
Cuándo elegirlo: procesamiento de contextos enormes (vídeo, colecciones de documentos), aplicaciones dentro del ecosistema Google, buena relación calidad/precio en gamas medias.
Cuándo NO: si tu empresa vive en AWS/Azure y no quiere añadir un tercer proveedor, evalúa si compensa.

Meta (Llama) — el campeón del open weights occidental¶

Qué es: Meta AI, con su familia Llama, fue quien normalizó que un gigante liberara pesos de modelos competentes (desde 2023).
Qué ofrece: pesos descargables (con licencia propia, ojo: abierta para la mayoría de usos pero con condiciones — no es open source clásico tipo MIT/Apache), que cualquiera puede servir en su infraestructura o consumir a través de proveedores de inferencia.
Fortalezas: control total (los pesos son tuyos de puertas adentro), privacidad (los datos no salen de tu infraestructura), sin coste de licencia por token, ecosistema enorme de fine-tunings y variantes de la comunidad.
Limitaciones: la calidad punta suele ir por detrás de los mejores propietarios del momento; servir modelos grandes bien es un proyecto de ingeniería en sí mismo; la estrategia de liberaciones de Meta ha ido variando, así que conviene verificar el estado actual antes de apostar.
Cuándo elegirlo: requisitos duros de privacidad/soberanía del dato, gran volumen con presupuesto ajustado, necesidad de fine-tuning profundo.
Cuándo NO: si tu equipo es pequeño y sin experiencia en infraestructura, el coste oculto de operar modelos propios supera con creces el ahorro aparente.

Mistral AI¶

Qué es: laboratorio francés (2023), el campeón europeo. Estrategia mixta: modelos open weights (con los que se hizo famoso, incluyendo pioneros en arquitectura mixture-of-experts abierta) y modelos propietarios comerciales.
Fortalezas: eficiencia (buena calidad por unidad de cómputo), opción europea relevante para soberanía del dato y cumplimiento del marco regulatorio de la UE (importante desde el AI Act), buena reputación en modelos compactos.
Limitaciones: menos recursos que los gigantes estadounidenses; catálogo y posicionamiento que han ido evolucionando — verifica el estado actual.
Cuándo elegirlo: empresas europeas con requisitos regulatorios, despliegues eficientes, estrategia multi-proveedor.

DeepSeek, Qwen y el open source chino¶

Qué es: la ola de laboratorios chinos que sacudió la industria. DeepSeek demostró (con enorme impacto mediático a inicios de 2025) que se podían entrenar modelos de razonamiento competitivos con presupuestos muy inferiores a los asumidos, y liberó los pesos. Qwen (Alibaba) mantiene una de las familias open weights más completas y descargadas del mundo, en múltiples tamaños y modalidades. Hay más actores (Moonshot/Kimi, Zhipu/GLM, MiniMax…).
Fortalezas: calidad sorprendentemente alta con pesos abiertos y licencias en general permisivas; variedad de tamaños; presión competitiva que ha abaratado toda la industria; excelente relación calidad/coste vía proveedores de inferencia.
Limitaciones: para algunas empresas occidentales existen consideraciones geopolíticas y de cumplimiento normativo al usar modelos de origen chino (aunque al ejecutar pesos abiertos en tu propia infraestructura, tus datos no viajan a China — la preocupación se centra más en sesgos de alineamiento y en políticas corporativas); soporte empresarial y documentación en inglés a veces más limitados.
Cuándo elegirlo: mejor calidad/precio en open weights, investigación, productos donde controlas la infraestructura.
Cuándo NO: sectores regulados occidentales cuyas políticas de compras excluyan estos orígenes; verifica siempre con el equipo legal.

Nota

hay más actores que debes conocer de nombre: xAI (Grok), Cohere (enfocado a empresa y RAG), AI21, y modelos especializados (código, voz, imagen: ElevenLabs, Stability, Black Forest Labs…). El ecosistema es grande; los de arriba son los que marcan el paso.

3.2 Tabla comparativa de proveedores¶

Advertencia

esta tabla compara posicionamientos estructurales, no versiones concretas. La foto fina (qué modelo exacto es mejor en qué benchmark este trimestre) cambia cada pocos meses: consúltala siempre en fuentes actualizadas antes de decidir.

Criterio	Anthropic (Claude)	OpenAI (GPT)	Google (Gemini)	Meta (Llama)	Mistral	DeepSeek / Qwen
Calidad gama alta	Punta, referente en código y agentes	Punta, referente en multimodal	Punta, referente en contexto largo	Alta pero por detrás de la punta propietaria	Media-alta	Alta, cerca de la punta en razonamiento
Coste relativo	Medio-alto en gama alta; gamas económicas disponibles	Medio-alto; gamas económicas disponibles	Competitivo, agresivo en gama media	Solo pagas infraestructura/inferencia	Competitivo	Muy bajo (open weights + inferencia barata)
Contexto	Largo	Largo	Muy largo (su bandera)	Medio-largo según versión	Medio	Medio-largo según versión
Open / Closed	Cerrado	Cerrado (con excepciones puntuales)	Cerrado (Gemini) + abierto (Gemma)	Abierto (licencia propia)	Mixto	Abierto en su mayoría
Dónde se consume	API, AWS Bedrock, GCP Vertex	API, Azure	API, Vertex, AI Studio	Donde quieras (self-host o proveedores de inferencia)	API propia + self-host	Self-host o proveedores de inferencia
Casos de uso típicos	Agentes, código, análisis de documentos, empresa	Prototipos, multimodal, consumo masivo	Contexto enorme, ecosistema Google	Privacidad, volumen, fine-tuning	Europa, eficiencia, regulación UE	Coste mínimo, investigación, self-host
Riesgo principal	Dependencia de proveedor	Dependencia de proveedor + cambios frecuentes	Dependencia + historial de renombrados	Operarlo bien es difícil	Menor escala	Políticas corporativas/geopolítica

3.3 Propietarios vs. open weights¶

Primero, precisión terminológica que te hará parecer profesional:

Modelo propietario (closed): solo accedes por API. Nunca ves los pesos. Ejemplos: Claude, GPT, Gemini.
Modelo open weights: los pesos se publican y puedes descargarlos y ejecutarlos, pero normalmente no se publican los datos de entrenamiento ni todo el proceso, y la licencia puede tener restricciones. Ejemplos: Llama, Qwen, DeepSeek, Gemma.
Open source estricto: pesos + datos + código + licencia libre de verdad. Es raro en modelos grandes (existen esfuerzos como OLMo del instituto Allen AI).

En la conversación cotidiana se dice "open source" para referirse a open weights. Tú sé preciso cuando importe (contratos, licencias).

Ventajas de los propietarios:

Máxima calidad disponible en cada momento (la frontera es propietaria).
Cero infraestructura: una clave de API y a producir en minutos.
Mejoras continuas sin esfuerzo por tu parte.
Soporte, SLAs y acuerdos empresariales.

Desventajas de los propietarios:

Tus datos viajan al proveedor (mitigable con acuerdos de no-entrenamiento y despliegues vía cloud empresarial, pero viajan).
Dependencia: precios, deprecaciones y cambios de comportamiento no los controlas tú.
Coste por token que escala linealmente con el uso, para siempre.

Ventajas de los open weights:

Control y privacidad totales: el modelo corre donde tú digas.
Sin coste de licencia por token: pagas solo la infraestructura.
Personalización profunda (fine-tuning sobre tus datos, cuantización a medida).
Inmunidad a deprecaciones: ese modelo será tuyo para siempre.

Desventajas de los open weights:

Calidad punta por debajo de lo mejor propietario (la brecha se estrecha, pero existe, sobre todo en tareas agénticas complejas).
Operarlos bien (servir con vLLM, escalar, monitorizar, actualizar) es un proyecto de ingeniería con coste de personal real.
La "gratuidad" es un espejismo si cuentas GPUs + DevOps + tiempo.

3.4 Tabla de decisión empresarial¶

Cuando una empresa te pregunte "¿propietario u open weights?", no respondas con opiniones: responde con esta matriz.

Criterio de negocio	Gana propietario (API)	Gana open weights (self-host)
Privacidad / soberanía del dato	Aceptable con acuerdos empresariales y despliegue vía Bedrock/Vertex/Azure en tu región	Imprescindible si los datos no pueden salir de tu infraestructura bajo ningún concepto (defensa, salud estricta, secretos industriales)
Coste a bajo volumen	Gana claramente: pagas céntimos, cero infraestructura	Pierde: la GPU y el personal cuestan aunque no haya tráfico
Coste a volumen masivo y estable	Puede dispararse	Puede ganar si el equipo sabe operarlo y la carga es predecible
Control y estabilidad de versiones	Limitado: deprecaciones marcadas por el proveedor	Total: congelas el modelo los años que quieras
Calidad máxima	Gana: la frontera es propietaria	Suficiente para muchas tareas, insuficiente para las más exigentes
Velocidad de salida al mercado	Gana: producción en días	Semanas/meses de infraestructura
Personalización profunda (fine-tuning a medida)	Limitada a lo que ofrezca el proveedor	Gana: acceso total a los pesos
Equipo pequeño sin MLOps	Gana sin discusión	Trampa: no lo intentes
Cumplimiento regulatorio UE / sectorial	Depende: revisa dónde se procesa y qué acuerdos hay	Ventaja si exige procesamiento local, pero el cumplimiento del modelo sigue siendo cosa tuya

Consejo profesional

la respuesta más frecuente en el mundo real es híbrida: API propietaria para las tareas de máxima calidad de cara al cliente, y un modelo open weights pequeño para tareas internas masivas (clasificación, extracción, resúmenes). Diseña tu código desde el día uno para poder cambiar de modelo (abstrae el proveedor detrás de una interfaz propia): esa flexibilidad vale oro.

Caso empresarial — La startup "Legalia" (ficticia pero realista)

tres fundadores lanzan un asistente que revisa contratos para pymes españolas. Decisiones: (1) Modelo: API de un proveedor frontier (eligen Claude por su fiabilidad con documentos largos e instrucciones complejas) — con tres personas no pueden permitirse operar GPUs, y la calidad es su único argumento de venta frente a despachos tradicionales. (2) Cloud: empiezan con la API directa de Anthropic por simplicidad; cuando su primer cliente grande exige que el procesamiento quede dentro de AWS en la región de la UE, migran las llamadas a Bedrock — mismo modelo, factura unificada y cumplimiento contentando al cliente. (3) Stack: FastAPI + Next.js + Postgres con pgvector para buscar cláusulas similares. (4) Coste: pagan por uso; los meses flojos la factura de IA es de decenas de euros. Moraleja: una startup compra velocidad y calidad; la infraestructura propia es su enemiga.

Caso empresarial — El banco "Meridian" (Fortune 500 ficticia)

un banco con 40.000 empleados quiere un asistente interno que responda sobre normativa y procedimientos. Decisiones: (1) Nada de APIs directas de consumo: el equipo de riesgo exige contratos empresariales, residencia de datos en la UE, auditoría y cifrado gestionado. Consumen modelos frontier a través de su cloud ya homologado (tienen convenio con Azure, así que usan Azure AI Foundry; el equipo de datos, que vive en AWS, accede a Claude vía Bedrock). (2) Además, para clasificar millones de correos internos (tarea simple, volumen enorme, datos sensibles) despliegan un modelo open weights en sus propios clústeres con vLLM: a ese volumen, el coste por token de un propietario no se justifica y los datos ni siquiera salen de su red. (3) La decisión tarda nueve meses e involucra a legal, compras, seguridad y arquitectura. Moraleja: una gran corporación compra control, cumplimiento y responsabilidades contractuales; la agilidad la sacrifica con gusto. Como consultor de IA, la mitad de tu trabajo será navegar exactamente este proceso.

4. Cloud para IA¶

4.1 Los tres hyperscalers¶

Los tres grandes clouds ofrecen dos cosas distintas que conviene no mezclar: (a) infraestructura bruta (máquinas con GPU, almacenamiento, redes) y (b) plataformas de IA gestionadas que te dan acceso a modelos y herramientas MLOps sin tocar una GPU.

AWS (Amazon Web Services)¶

Amazon Bedrock: plataforma gestionada para consumir modelos fundacionales de múltiples proveedores (Anthropic entre los principales, además de Meta, Mistral, Amazon Nova y otros) mediante una API unificada, con facturación integrada en tu cuenta AWS, controles de seguridad (IAM, redes privadas, guardrails) y residencia regional de datos. Es la vía habitual por la que las empresas "compran" Claude dentro de AWS.
Amazon SageMaker: la plataforma clásica de ML end-to-end — entrenar, hacer fine-tuning, desplegar y monitorizar modelos propios (incluidos open weights). Más orientada a equipos de ML que a desarrolladores de aplicaciones.
Ventajas: el cloud más adoptado en empresa; si tu cliente ya está en AWS, la fricción de compras/seguridad desaparece. Limitaciones: curva de aprendizaje y complejidad de servicios notoria; los modelos llegan a veces con algo de retraso respecto a la API directa del laboratorio.
Cuándo NO usarlo: para aprender y prototipar en solitario, la API directa es más simple y la documentación más directa.

Google Cloud (GCP)¶

Vertex AI: la plataforma unificada de Google: acceso gestionado a Gemini y también a modelos de terceros (incluido Claude) y open weights vía su Model Garden, más herramientas de entrenamiento, evaluación y despliegue. Ventaja diferencial: acceso a TPUs.
Ventajas: excelente para datos (BigQuery) + IA en un mismo sitio; fuerte en herramientas de evaluación. Limitaciones: menor cuota de mercado empresarial que AWS/Azure en muchos sectores; la dualidad AI Studio (ligero) / Vertex (empresarial) confunde al principio.

Microsoft Azure¶

Azure AI Foundry (evolución del Azure OpenAI Service): acceso empresarial a los modelos de OpenAI y un catálogo creciente de otros modelos, con la integración de seguridad y cumplimiento de Azure. Es la vía estándar por la que las corporaciones consumen GPT.
Ventajas: si la empresa vive en Microsoft 365/Teams/Active Directory (es decir, casi todas las grandes), Azure es el camino de menor resistencia política. Limitaciones: catálogo históricamente centrado en OpenAI; experiencia de desarrollador más burocrática.

4.2 Las alternativas especializadas¶

Fuera de los hyperscalers ha florecido un ecosistema de plataformas más pequeñas y ágiles, cada una con una especialidad:

Plataforma	Especialidad	Qué es en una frase	Cuándo usarla	Cuándo NO
Modal	Cómputo serverless con GPU	Escribes una función Python, la decoras, y se ejecuta en la nube con la GPU que pidas, pagando por segundo	Jobs de GPU esporádicos (fine-tuning, batch, modelos propios) sin gestionar servidores	Cargas 24/7 estables (sale más barato reservar)
Replicate	Catálogo de modelos como API	Miles de modelos de la comunidad (imagen, audio, vídeo, LLMs) ejecutables con una llamada HTTP	Prototipar con modelos exóticos sin instalar nada	Producción de alto volumen con SLAs estrictos
Together AI	Inferencia de open weights a escala	Servir los principales modelos abiertos (Llama, Qwen, DeepSeek…) por API a precios agresivos, más fine-tuning	Usar open weights sin operar GPUs propias	Si necesitas modelos propietarios frontier
Groq	Inferencia ultrarrápida	Hardware propio (LPUs) diseñado para servir LLMs con velocidad de generación excepcional	Aplicaciones sensibles a latencia (voz en tiempo real, UX instantánea)	Catálogo limitado a los modelos que ellos sirvan
Fireworks, DeepInfra, etc.	Inferencia de open weights	Competidores de Together en el mismo espacio	Comparar precios/latencias	—
OpenRouter	Agregador	Una sola API y una sola factura para acceder a decenas de proveedores y modelos	Experimentar y comparar modelos sin darse de alta en diez sitios	Producción empresarial con requisitos de compliance estrictos

Nota

no memorices esta lista; memoriza las categorías: (1) cómputo GPU flexible, (2) catálogo de modelos variados, (3) inferencia de open weights barata, (4) inferencia de latencia mínima, (5) agregadores. Los nombres concretos rotarán; las categorías permanecen.

4.3 ¿API directa o cloud provider?¶

La pregunta clave que te harán en cualquier empresa. Criterios:

Factor	API directa del laboratorio	Vía cloud provider (Bedrock/Vertex/Azure)
Velocidad para empezar	Minutos: clave de API y listo	Días/semanas: cuenta cloud, permisos, IAM
Novedades	Modelos y funciones nuevas primero	A veces con retraso
Compras/facturación empresarial	Otro proveedor que homologar	Se suma a la factura cloud existente (enorme ventaja política)
Seguridad y redes	Internet público (con TLS), controles del proveedor	Redes privadas, IAM corporativo, logging centralizado
Residencia de datos	Según el proveedor	Eliges región (clave para RGPD/AI Act)
Multi-modelo	Una API por laboratorio	Catálogo unificado de varios proveedores
¿Para quién?	Estudiantes, startups, prototipos, productos ágiles	Corporaciones, sectores regulados, equipos ya casados con un cloud

Consejo profesional

en esta academia usarás la API directa (simplicidad y últimas funciones) y aprenderás Bedrock en el módulo 11, porque en el mercado laboral hispanohablante la frase "lo necesitamos dentro de nuestro AWS/Azure" te la dirán en la primera semana de cualquier proyecto corporativo.

Nota

el detalle práctico de despliegue en cloud (IAM, redes, costes, infra como código) se trabaja a fondo en el módulo 11. Aquí solo necesitas el mapa.

5. Frameworks y librerías por propósito¶

Regla de oro antes de empezar: los frameworks se eligen por propósito, no por moda. La pregunta nunca es "¿cuál es el mejor framework?", sino "¿cuál es la herramienta correcta para ESTA tarea?".

5.1 Tabla maestra de frameworks¶

Herramienta	Propósito	Lenguaje	Úsalo cuando…	NO lo uses cuando…	Módulo de la academia
PyTorch	Entrenar redes neuronales / investigación	Python	Entrenes o modifiques modelos, hagas fine-tuning serio	Solo consumas APIs de LLM (no lo necesitas)	03 (conceptual), módulos ML
TensorFlow / JAX	Entrenamiento (legado / alto rendimiento)	Python	Mantengas sistemas TF existentes; JAX para investigación de rendimiento en TPU	Empieces de cero un proyecto estándar (la comunidad está en PyTorch)	Mención
scikit-learn	ML clásico (tabular)	Python	Datos tabulares: clasificación, regresión, clustering	El problema sea de lenguaje/imagen (usa deep learning o LLMs)	03
Hugging Face (hub + transformers)	Hub de modelos + ejecutarlos localmente	Python	Descargues, ejecutes o afinés modelos open weights	Solo llames a APIs propietarias	03, 07
SDKs oficiales (anthropic, openai)	Llamar a las APIs de los laboratorios	Python/TS	Siempre: son la base de todo	Nunca sobran; incluso con frameworks encima, entiende el SDK	02, 04 en adelante
LangChain	Orquestación de LLMs (cadenas, integraciones)	Python/TS	Necesites integraciones ya hechas y patrones comunes	El caso sea simple (SDK directo) o un grafo complejo (LangGraph)	06
LangGraph	Agentes como grafos de estado	Python/TS	Construyas agentes con ciclos, estado y control fino	Un pipeline lineal simple baste	06, 08, 09
LlamaIndex	RAG: conectar LLMs con tus datos	Python/TS	Ingesta, indexación y consulta de documentos propios	No haya recuperación de datos de por medio	05
Vercel AI SDK	IA en el frontend/full-stack TS	TypeScript	Construyas UIs con streaming de respuestas (Next.js/React)	Tu backend sea Python puro	10
Ollama	Ejecutar modelos locales fácil	CLI/API local	Experimentes en tu máquina, privacidad total, demos offline	Producción con tráfico real (usa vLLM)	07
vLLM	Servir open weights en producción	Python/servidor	Sirvas modelos abiertos con alto rendimiento en GPUs	No tengas GPUs que gestionar (usa un proveedor de inferencia)	11
n8n	Automatización visual de flujos	Low-code	Automatices procesos de negocio conectando SaaS + nodos de IA	La lógica sea compleja y necesite tests (código de verdad)	12

5.2 Cada herramienta en profundidad¶

PyTorch — el estándar del deep learning¶

Qué es: la librería de deep learning dominante, originada en Meta y hoy gobernada por una fundación. Define tensores, autodiferenciación y las piezas para construir y entrenar redes neuronales.
Para qué sirve: investigación, entrenamiento, fine-tuning. Prácticamente todos los modelos famosos que conoces se entrenaron con PyTorch o algo equivalente.
Ventajas: comunidad y documentación enormes, estilo "pythónico" e imperativo fácil de depurar, ecosistema gigante (torchvision, torchaudio, Lightning…).
Limitaciones: curva de matemáticas y GPU; para el ingeniero de aplicaciones de LLM es infraestructura que rara vez toca directamente.
Cuándo NO usarlo: si tu trabajo es llamar a Claude por API y orquestar agentes, no necesitas PyTorch más que conceptualmente. No te sientas culpable.
Alternativas: TensorFlow (legado; aún común en producción antigua y en móvil con TF Lite), JAX (Google; funcional, excelente en TPU, favorito de algunos labs de investigación), Keras (API de alto nivel).

TensorFlow y JAX — el otro linaje¶

TensorFlow dominó 2016-2019 y sobrevive en muchísimos sistemas en producción; hoy rara vez se elige para empezar algo nuevo. Si heredas un sistema TF, lo mantienes; no lo migras por deporte.
JAX es la apuesta de Google para investigación de alto rendimiento: composición funcional, transformaciones (grad, jit, vmap) y rendimiento sobresaliente en TPU. Nicho: investigadores y equipos con cargas muy exigentes.
Cuándo NO: no elijas ninguno de los dos para tu primer proyecto de deep learning en 2026 sin una razón concreta; la gravedad de la comunidad está en PyTorch.

scikit-learn — el veterano imprescindible del ML clásico¶

Qué es: LA librería de machine learning clásico de Python: regresiones, árboles, random forests, clustering, métricas, pipelines de preprocesado.
Por qué sigue importando en la era de los LLMs: porque la mayoría de los problemas de datos de las empresas son tabulares (¿este cliente se dará de baja? ¿cuánto venderé el mes que viene?) y para eso un gradient boosting entrenado en segundos sobre CPU sigue batiendo a cualquier LLM en coste, velocidad y a menudo en precisión.
Ventajas: API consistente y elegante (fit/predict), rapidez, sin GPU, interpretabilidad.
Limitaciones: no hace deep learning ni trabaja con texto/imagen crudos de forma competitiva.
Cuándo NO usarlo: problemas de lenguaje natural o visión — ahí viven los LLMs y las redes profundas.
Consejo profesional: un AI Engineer que propone un LLM carísimo para predecir bajas de clientes con datos tabulares queda retratado. Saber cuándo NO usar un LLM es una señal de seniority.

Hugging Face — el GitHub de los modelos¶

Qué es: dos cosas: (1) el Hub, la plataforma donde la comunidad publica y descarga cientos de miles de modelos, datasets y demos; (2) las librerías, sobre todo transformers, que dan una API unificada para cargar y ejecutar esos modelos en local.
Para qué sirve: encontrar el modelo abierto adecuado, probarlo, hacer fine-tuning (con peft, trl), publicar los tuyos.
Ventajas: es el punto de encuentro de facto de todo el ML abierto; documentación y cursos gratuitos excelentes; leaderboards y "model cards" para evaluar antes de descargar.
Limitaciones: la calidad en el Hub es desigual (cualquiera puede subir cualquier cosa — revisa descargas, licencia y procedencia); transformers ejecuta modelos pero no es un servidor de producción optimizado (para eso, vLLM).
Cuándo NO usarlo: si tu proyecto es 100 % APIs propietarias, lo usarás poco; aun así, crea una cuenta: es la mejor ventana al estado del open source.

SDKs oficiales (`anthropic`, `openai`) — tu pan de cada día¶

Qué son: las librerías oficiales de cada laboratorio para llamar a su API desde Python o TypeScript: autenticación, envío de mensajes, streaming, tool use, manejo de errores y reintentos.
Por qué son la base: todo lo demás (LangChain, LlamaIndex…) es una capa sobre esto. Si entiendes el SDK, entiendes qué hace cualquier framework por debajo y puedes prescindir de él cuando estorbe.
Ventajas: acceso día uno a las funciones nuevas, sin capas de abstracción que oculten errores, documentación oficial de primera.
Limitaciones: no traen orquestación (memoria, grafos, RAG): eso lo pones tú o un framework.
Consejo profesional: en esta academia la norma es "SDK primero": aprende a hacer cada cosa con el SDK crudo antes de aceptar la magia de un framework. Los frameworks se aprecian de verdad solo cuando sabes lo que te ahorran — y lo que te esconden.

LangChain y LangGraph — orquestación y agentes¶

LangChain — qué es: el framework de orquestación de LLMs más conocido: abstracciones para modelos, prompts, memoria, y sobre todo un catálogo enorme de integraciones (bases vectoriales, loaders de documentos, APIs de terceros).
Ventajas: ecosistema e integraciones inigualables; mucha documentación y comunidad; cambiar de proveedor de modelo es casi trivial.
Limitaciones: historial de cambios de API frecuentes; capas de abstracción que a veces ocultan lo que ocurre (difícil de depurar); para casos simples es sobreingeniería.
Cuándo NO usarlo: si tu app hace dos llamadas al modelo, el SDK directo es más claro, más rápido y más fácil de mantener.
LangGraph — qué es: del mismo equipo, pero un nivel por debajo y más serio: modela tu aplicación como un grafo de estado — nodos (pasos), aristas (transiciones, incluso cíclicas) y un estado tipado que fluye entre ellos. Es la herramienta con la que construiremos agentes de verdad: sistemas que deciden, usan herramientas, reintentan y piden aprobación humana.
Ventajas: control explícito del flujo (nada de magia), soporte de ciclos, persistencia de estado (checkpoints), human-in-the-loop, streaming de pasos intermedios.
Limitaciones: más verboso que un while con llamadas al SDK para casos triviales; conceptos (reducers, checkpointers) que requieren estudio.
Alternativas en el mismo espacio: LlamaIndex Workflows, CrewAI (multi-agente con roles, más rígido), AutoGen/AG2 (Microsoft), Agents SDK de OpenAI, o directamente el patrón "bucle + tool use" con el SDK (que también enseñaremos, porque a veces es TODO lo que necesitas).

LlamaIndex — especialista en RAG¶

Qué es: framework centrado en conectar LLMs con tus datos: ingesta de documentos (PDF, webs, bases de datos), troceado (chunking), indexación en bases vectoriales y consulta con recuperación (RAG, Retrieval-Augmented Generation).
Ventajas: para RAG puro suele ser más directo y con mejores utilidades por defecto que LangChain; excelente colección de loaders y estrategias de indexación.
Limitaciones: fuera del terreno datos/RAG su propuesta es menos diferencial; solapa con LangChain y no necesitas ambos en un mismo proyecto sin motivo.
Cuándo NO usarlo: si no hay recuperación de conocimiento en tu app; o si tu RAG es tan simple (unos cientos de documentos, una tabla pgvector) que unas decenas de líneas con el SDK + SQL te dan más control. En el módulo 05 haremos RAG primero a mano y luego con framework, exactamente por esta razón.

Vercel AI SDK — la IA en el frontend¶

Qué es: librería TypeScript (de Vercel, los creadores de Next.js) para construir interfaces de IA: hooks de React para chats, streaming de tokens a la UI, generación de objetos estructurados, agnóstica del proveedor de modelo.
Ventajas: la experiencia estándar de "chat que va escribiendo" resuelta con elegancia; se integra de forma natural con Next.js y React Server Components.
Limitaciones: es del mundo TypeScript/frontend; la lógica pesada de agentes y datos seguirá viviendo en tu backend Python.
Cuándo NO usarlo: apps sin frontend web propio, o si tu equipo es 100 % Python (expón tu backend por API y sirve el streaming tú mismo).

Ollama y vLLM — servir modelos localmente¶

Ollama — qué es: la forma más sencilla de ejecutar modelos open weights en tu máquina: un comando (ollama run …) descarga el modelo cuantizado y te da un chat local y una API compatible con el estándar de facto.
Ventajas: simplicidad absoluta, privacidad total (nada sale de tu máquina), gratis, funciona sorprendentemente bien en portátiles modernos con modelos pequeños.
Limitaciones: pensado para uso personal/desarrollo, no para servir a cientos de usuarios; rendimiento limitado por tu hardware.
vLLM — qué es: el motor de inferencia de referencia para servir open weights en producción: técnicas como PagedAttention y continuous batching le permiten exprimir las GPUs sirviendo a muchos usuarios simultáneos con API compatible con la de OpenAI.
Ventajas: rendimiento de referencia en el mundo abierto, estándar de la industria para self-hosting serio.
Limitaciones: necesitas GPUs y conocimientos de operación; es infraestructura de verdad.
Regla mnemotécnica: Ollama = tu portátil; vLLM = el servidor de la empresa.

n8n — automatización visual¶

Qué es: plataforma de automatización de flujos (estilo "cuando pase X, haz Y") con editor visual de nodos, self-hosteable y con código fuente disponible, que ha abrazado la IA con nodos de agentes y LLMs.
Ventajas: velocidad brutal para automatizaciones de negocio (correo → clasifica con IA → crea ticket → avisa por Slack); cientos de integraciones; lo pueden mantener perfiles no puramente de ingeniería; self-host = datos en casa.
Limitaciones: cuando la lógica se complica (tests, versionado fino, depuración compleja), el low-code se convierte en una maraña de nodos; rendimiento y control inferiores al código.
Cuándo NO usarlo: para el producto core de tu empresa o sistemas con lógica compleja — eso se escribe con código y tests. n8n brilla en la periferia: operaciones internas, prototipos de automatización, y como herramienta de consultoría rápida para pymes.
Alternativas: Zapier y Make (SaaS puros, más simples y menos flexibles), o código a medida.

5.3 Qué framework se usa en qué módulo de la academia¶

flowchart LR
    subgraph M0["Módulos 01-02<br/>Fundamentos y APIs"]
        T1["Python<br/>SDK anthropic<br/>SDK openai"]
    end
    subgraph M3["Módulo 03<br/>ML práctico"]
        T2["scikit-learn<br/>PyTorch (conceptos)<br/>Hugging Face"]
    end
    subgraph M45["Módulos 04-05<br/>Backend y RAG"]
        T3["FastAPI<br/>PostgreSQL + pgvector<br/>LlamaIndex"]
    end
    subgraph M6["Módulos 06-09<br/>Agentes y MCP"]
        T4["LangChain<br/>LangGraph<br/>MCP<br/>Redis"]
    end
    subgraph M10["Módulo 10<br/>Frontend"]
        T5["TypeScript<br/>Next.js<br/>Vercel AI SDK"]
    end
    subgraph M11["Módulos 11-12<br/>Despliegue y proyectos"]
        T6["Docker · AWS<br/>Bedrock · vLLM<br/>Ollama · n8n"]
    end

    M0 --> M3 --> M45 --> M6 --> M10 --> M11

    style M0 fill:#e0f5e0,stroke:#1e8449
    style M3 fill:#dbeeff,stroke:#2471a3
    style M45 fill:#fff7d6,stroke:#b7950b
    style M6 fill:#f0e0ff,stroke:#7d3c98
    style M10 fill:#ffe8d6,stroke:#ca6f1e
    style M11 fill:#ffe5e5,stroke:#c0392b

Nota

fíjate en la progresión: primero el SDK crudo (entender), luego los frameworks (productividad), luego la infraestructura (producción). Nunca al revés.

6. Protocolos y estándares¶

Los modelos y frameworks se llevan los titulares, pero las industrias maduran cuando aparecen estándares: acuerdos sobre cómo se conectan las piezas. Internet despegó con HTTP; la IA está viviendo su momento equivalente.

6.1 MCP: el "USB-C de la IA"¶

El problema: un LLM por sí solo es un cerebro en una caja: no puede leer tus archivos, consultar tu base de datos ni crear un ticket en Jira. Para que sea útil hay que conectarle herramientas. Antes de 2025, cada aplicación conectaba cada herramienta a cada modelo con código a medida: M aplicaciones × N herramientas = M×N integraciones. Un despilfarro combinatorio.

La solución: MCP (Model Context Protocol), un protocolo abierto creado por Anthropic (finales de 2024) y adoptado después por el resto de la industria —incluidos OpenAI, Google y Microsoft— hasta convertirse en el estándar de facto, con su gobernanza evolucionando hacia estructuras neutrales de la industria.

La intuición del USB-C: antes de USB-C, cada dispositivo tenía su cargador y su conector; hoy un solo puerto vale para (casi) todo. MCP hace lo mismo: define un contrato estándar entre:

Servidores MCP: programas que exponen capacidades — herramientas (acciones ejecutables: "consulta esta base de datos", "crea este ticket"), recursos (datos legibles) y prompts (plantillas reutilizables).
Clientes/hosts MCP: las aplicaciones con modelo dentro (asistentes de escritorio, IDEs, agentes) que consumen esos servidores.

Escribes un servidor MCP para tu sistema interno y, automáticamente, cualquier aplicación compatible con MCP puede usarlo, sea cual sea el modelo que lleve dentro. M+N en lugar de M×N.

Por qué te importa profesionalmente: "sé construir servidores MCP" se ha convertido en una línea de currículum real. Las empresas quieren exponer sus sistemas internos a los asistentes de IA de forma segura y estándar, y alguien tiene que construir esos conectores. Ese alguien serás tú: el módulo 08 completo está dedicado a MCP.

Advertencia

MCP también abre superficie de ataque: un servidor MCP malicioso o mal diseñado puede exfiltrar datos o ejecutar acciones indebidas (inyección de prompts a través de herramientas). La seguridad de MCP se trata en el módulo 08; por ahora, quédate con la regla: conecta solo servidores MCP en los que confíes, con los mínimos permisos posibles.

6.2 Function calling¶

Un nivel por debajo de MCP está el function calling (o tool use), la capacidad nativa de los modelos modernos que lo hace todo posible:

Tú le describes al modelo, en formato JSON Schema, qué funciones existen (get_weather(city), search_orders(customer_id)…).
El modelo, cuando lo considera necesario, responde no con texto sino con una petición estructurada de llamada: "llama a get_weather con city='Madrid'".
Tu código ejecuta la función real (el modelo nunca ejecuta nada por sí mismo) y le devuelve el resultado.
El modelo redacta la respuesta final usando ese resultado.

Este bucle es el átomo de todos los agentes. MCP no lo sustituye: lo estandariza y empaqueta — un cliente MCP traduce las herramientas de los servidores a definiciones de function calling para el modelo. Lo practicarás desde el módulo 02 con el SDK.

6.3 APIs REST y streaming¶

Por último, la fontanería que ya conoces de la web tradicional, con un matiz importante:

REST/HTTP: todas las APIs de modelos son, en el fondo, peticiones HTTP con JSON: envías mensajes, recibes la respuesta. Autenticación por clave de API en cabeceras. Nada nuevo si has consumido cualquier API.
Streaming (SSE): la peculiaridad de los LLMs es que generan token a token y tardan segundos. Esperar la respuesta completa arruina la experiencia; por eso las APIs ofrecen streaming mediante Server-Sent Events: el servidor va empujando fragmentos a medida que se generan y tu aplicación los pinta en pantalla al vuelo. Ese efecto "máquina de escribir" de los chats es SSE. Implementarlo bien (backend y frontend) es una habilidad básica del AI Engineer que trabajaremos en los módulos 04 y 10.
Otros conceptos de fontanería que irán apareciendo: rate limits (límites de peticiones), retries con backoff exponencial, timeouts, idempotencia, y APIs de batch (procesamiento en diferido más barato).

Nota

fíjate en el patrón de esta sección: function calling (capacidad del modelo) → MCP (estándar de conexión) → REST/SSE (transporte). Tres niveles de abstracción que juntos explican cómo cualquier agente moderno habla con el mundo.

7. El stack de esta academia, decisión a decisión¶

Ya tienes el mapa completo. Ahora podemos justificar, con argumentos y no por fe, cada pieza del stack que usarás durante el resto de la academia.

flowchart TB
    subgraph FE["FRONTEND"]
        NX["Next.js + TypeScript<br/>+ Vercel AI SDK"]
    end
    subgraph BE["BACKEND"]
        FA["Python + FastAPI"]
        LG["LangGraph<br/>(agentes)"]
        MCPS["Servidores MCP"]
    end
    subgraph DATA["DATOS"]
        PG["PostgreSQL<br/>+ pgvector"]
        RD["Redis<br/>(caché y colas)"]
    end
    subgraph MODELS["MODELOS"]
        CL["APIs: Anthropic / OpenAI"]
        OL["Ollama (local, experimentos)"]
    end
    subgraph INFRA["INFRAESTRUCTURA"]
        DK["Docker"]
        AWS_["AWS (+ Bedrock)"]
    end

    NX <-->|"HTTP / SSE"|FA
    FA --> LG
    LG --> MCPS
    LG --> CL
    FA --> PG
    FA --> RD
    LG -.-> OL
    DK --> AWS_
    FA -.->|"contenedores"|DK
    NX -.->|"contenedores"|DK

    style FE fill:#ffe8d6,stroke:#ca6f1e
    style BE fill:#dbeeff,stroke:#2471a3
    style DATA fill:#fff7d6,stroke:#b7950b
    style MODELS fill:#f0e0ff,stroke:#7d3c98
    style INFRA fill:#ffe5e5,stroke:#c0392b

Tecnología	Por qué esta	Por qué no la alternativa
Python + FastAPI	Python es la lengua franca de la IA (todos los SDKs y frameworks son Python-first). FastAPI: moderno, asíncrono (clave para streaming y llamadas concurrentes a APIs), tipado con Pydantic, documentación automática	Django: excelente para webs clásicas, pesado para APIs de IA. Flask: síncrono por diseño, envejecido para streaming. Node-solo: perderías el ecosistema ML de Python
TypeScript + Next.js	El frontend moderno es TypeScript; Next.js es el framework React dominante, con streaming y server components ideales para UIs de IA; enorme demanda laboral	SPA con React puro: peor streaming/SEO y más fontanería manual. Vue/Svelte: buenos, pero menor masa crítica de ejemplos de IA y de ofertas de empleo
PostgreSQL + pgvector	Una sola base de datos para lo relacional Y lo vectorial (RAG). Postgres es el estándar open source; pgvector añade búsqueda semántica sin operar otro sistema	Base vectorial dedicada (Pinecone, Weaviate, Qdrant…): potentes, pero un sistema más que operar y pagar; para el 90 % de los proyectos pgvector sobra. MySQL: sin ecosistema vectorial comparable
Redis	Caché de respuestas (ahorra tokens y latencia), sesiones, colas de trabajo, rate limiting: piezas que toda app de IA en producción necesita	Memcached: solo caché, sin estructuras ricas ni colas. "Nada": funciona hasta el primer pico de tráfico o la primera factura absurda por no cachear
Docker	Empaquetado reproducible: "en mi máquina funciona" deja de ser un problema; requisito de facto en cualquier empresa y base del despliegue en cloud	Instalar a mano en servidores: frágil e irrepetible. Kubernetes directo: lo tocaremos, pero es sobreingeniería para aprender y para proyectos pequeños
LangGraph	El estándar emergente para agentes serios: grafos de estado explícitos, ciclos, persistencia, human-in-the-loop; te obliga a pensar bien la arquitectura del agente	CrewAI: más fácil pero más rígido y opaco. AutoGen: fuerte en investigación multi-agente, menos en producción. Solo SDK: lo enseñamos primero, pero reescribir persistencia y checkpoints a mano en cada proyecto no escala
MCP	El estándar de la industria para conectar herramientas a modelos; construir servidores MCP es una habilidad demandada y transferible entre empleadores	Integraciones a medida: M×N conectores no reutilizables. Plugins propietarios de una sola plataforma: conocimiento no transferible
AWS (+ Bedrock)	El cloud con mayor cuota empresarial: la probabilidad de encontrártelo en un empleo es la más alta; Bedrock enseña el patrón "modelos vía cloud" que exigen las corporaciones	GCP/Azure: perfectamente válidos (y los entenderás por analogía: Vertex ≈ Bedrock ≈ Foundry); hay que elegir uno para profundizar y AWS maximiza empleabilidad media
APIs de Anthropic/OpenAI como modelos de cabecera	Calidad frontier sin infraestructura; tool use y streaming de primera; es como trabaja la industria real de aplicaciones	Solo open weights locales: te limitaría la calidad y te desviaría a problemas de infraestructura antes de tiempo. Los probaremos (Ollama) para entender el otro lado

Consejo profesional

este stack no es dogma, es un vehículo de aprendizaje optimizado para empleabilidad. Los conceptos (streaming, RAG, agentes, tool use, contenedores) son transferibles: quien domina FastAPI + LangGraph + AWS aprende Express + otro orquestador + GCP en semanas. Aprende los conceptos a través de las herramientas, no las herramientas como fin.

8. Roles y mercado laboral¶

La demanda de perfiles de IA sigue siendo de las más fuertes del mercado tecnológico, pero los títulos de los puestos son un caos: la misma oferta puede llamarse de tres formas distintas. Lo que importa es el contenido real del rol:

Rol	Qué hace realmente	Stack típico	Perfil de partida habitual	Cómo te prepara esta academia
AI Engineer (ingeniero de aplicaciones de IA)	Construye productos sobre modelos existentes: agentes, RAG, integraciones, APIs, evaluación de calidad	Python/TS, SDKs de modelos, LangGraph/LlamaIndex, FastAPI, bases vectoriales, MCP, cloud	Desarrollador de software que se especializa en IA	Es el rol objetivo central: los módulos 02-11 son literalmente su temario
ML Engineer	Entrena, afina, evalúa y despliega modelos propios; pipelines de datos y MLOps	PyTorch, scikit-learn, Hugging Face, SageMaker/Vertex, MLflow, vLLM	Perfil con más matemáticas/datos	Fundamentos sólidos (módulo 03) y despliegue (11); para la parte profunda de entrenamiento necesitarás estudio adicional específico
AI Solutions Architect	Diseña la arquitectura: qué modelo, qué cloud, qué patrón (RAG vs fine-tuning vs agente), costes, seguridad, compliance	Diagramas antes que código; conocimiento amplio de todas las capas; Bedrock/Vertex/Foundry	Ingeniero senior o preventa técnica	Este capítulo es su semilla: los criterios de decisión de las secciones 3, 4 y 7 son su día a día; los proyectos finales te dan el porfolio
AI Consultant	Ayuda a empresas (sobre todo pymes) a identificar casos de uso, elegir herramientas e implantar automatizaciones; mucha comunicación	n8n, APIs de modelos, RAG ligero, prompting avanzado, hojas de cálculo y presentaciones	Perfil híbrido negocio-técnico	Módulos 01-02, 05, 08 y 12 (automatización); los casos empresariales de la academia son tu material de venta
Founder / Indie hacker	Construye y vende su propio producto de IA de punta a punta	Todo lo anterior, versión mínima viable: Next.js + FastAPI + APIs + un cloud barato	Cualquiera con iniciativa y tolerancia al riesgo	La academia entera es un curso de "producto de IA de punta a punta"; los proyectos integradores son prototipos vendibles

Observaciones honestas sobre el mercado:

El rol que más crece es el AI Engineer: las empresas ya no quieren "hacer un modelo", quieren integrar los que existen en sus procesos. Esa integración es ingeniería de software + criterio de IA: exactamente esta academia.
El ML Engineer clásico no ha muerto pero se ha especializado: menos "entrenar desde cero", más fine-tuning, evaluación y servir modelos eficientemente.
La evaluación (evals) es la habilidad infravalorada: saber medir si un sistema de IA funciona bien (y demostrarlo) distingue a los profesionales de los aficionados. Aparecerá una y otra vez desde el módulo 04.
Advertencia: desconfía de los títulos rimbombantes en las ofertas ("Prompt Engineer" como rol aislado prácticamente ha desaparecido, absorbido por los demás roles). Lee siempre las responsabilidades, no el título.

9. Cómo mantenerse actualizado sin ahogarse¶

La IA avanza tan rápido que "estar al día de todo" es imposible y además innecesario. Lo que necesitas es un sistema de filtrado: pocas fuentes fiables + un método para separar señal de ruido.

Fuentes primarias (la verdad de primera mano)¶

Blogs y documentación oficiales de los laboratorios: Anthropic (anthropic.com/news y docs.claude.com), OpenAI (openai.com/news y platform.openai.com/docs), Google DeepMind (deepmind.google y ai.google.dev). Cuando algo importante pasa, aquí está la versión sin distorsión.
arXiv (arxiv.org): el repositorio de papers. No necesitas leer papers a diario; sí saber que cuando alguien afirma "un estudio demuestra que…", la fuente verificable está (o no está) aquí.
Hugging Face (huggingface.co): su blog, sus leaderboards y la actividad del Hub son el pulso del mundo open weights.
Documentación de tus herramientas (LangChain/LangGraph, FastAPI, MCP en modelcontextprotocol.io): los changelogs oficiales te afectan más que cualquier titular.

Fuentes secundarias (curación)¶

Newsletters de curación con reputación (por ejemplo, resúmenes semanales de noticias de IA de fuentes establecidas del sector; elige una o dos, no diez).
Ingenieros y investigadores concretos que publican análisis técnicos con código y evidencia (mejor seguir a 5 personas rigurosas que a 50 cuentas de hype).
Comunidades técnicas (foros de desarrolladores, Discords oficiales de las herramientas que uses).

El método antihype: cinco preguntas ante cada anuncio¶

Consejo profesional

ante cualquier titular de IA ("¡X lo cambia todo!"), pásalo por este filtro antes de dedicarle un minuto más:

¿Quién lo dice y qué vende? ¿Es el anuncio oficial, un paper revisable, o un tercero con un curso/newsletter/token que colocar?
¿Hay demo reproducible o solo cifras? ¿Puedo probarlo hoy con mi clave de API? ¿El benchmark es público y relevante para mi caso, o está elegido a medida?
¿De qué capa es y me afecta? (Usa el mapa de la sección 1.) ¿Chip nuevo? Años hasta afectarte. ¿Cambio de API que uso? Atención inmediata.
¿Cambia alguna decisión que yo tenga que tomar este mes? Si no cambia tu stack, tu presupuesto ni tu hoja de ruta, es información, no acción.
¿Sobrevivirá al fin de semana? La prueba del tiempo barata: apúntalo, espera unos días, y mira si la comunidad técnica seria sigue hablando de ello con evidencia.

Si un anuncio pasa las cinco, dedícale una tarde de laboratorio. Si no, a la lista de "revisar el mes que viene" (spoiler: la mayoría no sobrevive ni a la pregunta 2).

Sobre influencers y "cursos milagro"¶

Advertencia

el boom de la IA ha creado una industria paralela de humo. Señales de alarma inequívocas:

Promesas de dinero fácil: "gana miles al mes con IA sin saber programar", "hazte AI Engineer en 2 semanas".
Urgencia artificial: "esto desaparece MAÑANA", "quedan 3 plazas".
Titulares absolutos permanentes: cada semana algo "mata" a lo anterior y "lo cambia todo", sin que el autor muestre jamás código ni resultados propios verificables.
Autoridad sin obra: gurús cuya única credencial de IA es… vender cursos de IA.
Demostraciones no reproducibles: vídeos espectaculares que nunca vienen con repositorio.

El antídoto es el que practica esta academia: fuentes primarias, código que puedes ejecutar tú mismo, y criterio construido capa a capa. La buena noticia: como la barrera del ruido es alta, los profesionales con fundamentos reales destacan más que nunca.

10. Buenas prácticas¶

Piensa en capas. Ante cualquier tecnología o noticia, ubícala en el mapa de la sección 1 antes de opinar o decidir. Es el hábito mental número uno del arquitecto.
API primero, hardware nunca (de momento). Aprende y prototipa contra APIs; alquila GPU solo con una necesidad concreta; compra hardware prácticamente nunca.
SDK antes que framework. Domina la llamada cruda al modelo (mensajes, streaming, tool use) antes de aceptar abstracciones. Sabrás qué te ahorra el framework y podrás abandonarlo cuando estorbe.
Elige herramientas por propósito, no por moda. scikit-learn para tabular, LlamaIndex para RAG, LangGraph para agentes, n8n para automatización periférica. La pregunta es "¿para qué?", no "¿cuál es la mejor?".
Abstrae el proveedor de modelo. Encapsula las llamadas al LLM detrás de una interfaz tuya. Cambiar de modelo debe costar una tarde, no una reescritura.
Calcula el coste total, no el precio del token. Un open weights "gratis" + GPUs + DevOps puede costar más que una API "cara". Y al revés a volumen masivo. Haz números siempre.
Desconfía de las comparativas sin fecha. En IA, un benchmark de hace ocho meses es arqueología. Verifica siempre el estado actual en fuentes primarias antes de decidir.
Cachea y enruta. Respuestas repetidas → caché (Redis). Tareas simples → modelo pequeño. Tareas difíciles → modelo grande. Es la optimización con mejor ratio esfuerzo/ahorro que existe.
Mantén un radar pequeño y fiable. Dos newsletters, cinco voces rigurosas, los blogs oficiales de tu stack. Más volumen no es más información: es más ruido.
Construye en público tu criterio. Cada vez que evalúes una herramienta, escribe tres líneas: qué es, cuándo la usaría, cuándo no. Ese cuaderno de decisiones será tu activo profesional más diferencial (y material de entrevista).

11. Errores comunes¶

#	Error	Por qué pasa	Cómo evitarlo
1	Comprar una GPU cara "para aprender IA"	Confundir aprender IA con entrenar modelos	Empieza con APIs (céntimos); alquila GPU en cloud si algún día la necesitas de verdad
2	Creer que "open source = gratis"	Ignorar el coste de infraestructura y personal para operarlo	Calcula el coste total de propiedad (GPU + DevOps + tiempo) antes de decidir
3	Empezar por el framework sin entender el SDK	Los tutoriales venden magia	Regla "SDK primero": haz cada cosa a mano una vez antes de abstraerla
4	Usar un LLM para todo (incluso datos tabulares)	Martillo nuevo, todo parece clavo	Si el problema es tabular, scikit-learn; si es una regla fija, un `if`; el LLM es la última opción, no la primera
5	Perseguir cada modelo/framework nuevo reescribiendo el stack	FOMO alimentado por el ciclo de hype	Aplica las 5 preguntas antihype; programa "tardes de laboratorio" acotadas en lugar de migraciones impulsivas
6	Ignorar el coste por token hasta que llega la factura	En desarrollo el gasto parece invisible	Pon límites de gasto y alertas desde el día uno; registra tokens por petición; cachea
7	Elegir stack por moda de redes en vez de por requisitos	Los hilos viral-tecnológicos no conocen tu proyecto	Usa las tablas de decisión (secciones 3.4, 4.3, 5.1): requisitos → criterios → elección
8	Acoplarse a un solo proveedor sin capa de abstracción	Prisa al prototipar	Interfaz propia sobre el LLM desde el primer commit; te costará una hora y te salvará un trimestre
9	Descartar los modelos pequeños/locales por "malos"	Solo se prueban los frontier	Para clasificar, extraer o resumir en volumen, un modelo pequeño bien elegido rinde de sobra a coste mínimo
10	Aprender herramientas en vez de conceptos	Los cursos-lista-de-herramientas lo fomentan	Por cada herramienta pregunta: ¿qué concepto implementa? El concepto (RAG, streaming, tool use) sobrevive; la herramienta rota

12. Preguntas frecuentes (FAQ)¶

1. ¿Necesito comprarme una GPU para seguir esta academia? No. El 90 % de la academia trabaja contra APIs, donde la GPU la pone el proveedor. Para los experimentos locales con Ollama basta un ordenador razonable de los últimos años (idealmente 16 GB de RAM). Si algún módulo necesita GPU de verdad, la alquilaremos por horas en cloud por muy poco dinero.

2. ¿Qué es mejor: Claude, GPT o Gemini? Pregunta mal planteada: depende de la tarea, del presupuesto, del ecosistema de tu empresa y del trimestre en que preguntes. Lo profesional es (a) definir criterios (calidad en TU tarea, coste, contexto, compliance), (b) probar 2-3 candidatos con TUS datos, y (c) abstraer el proveedor en tu código para poder cambiar. En esta academia usamos principalmente Claude y también OpenAI, precisamente para que aprendas a trabajar multi-proveedor.

3. ¿"Open source" y "open weights" son lo mismo? No. Open weights significa que puedes descargar y ejecutar los pesos del modelo, pero normalmente no tienes los datos de entrenamiento ni una licencia libre clásica. Open source estricto (pesos + datos + código + licencia libre) es raro en modelos grandes. Coloquialmente se mezclan; en un contrato, no los mezcles.

4. ¿Puedo ejecutar un modelo tipo Claude o GPT en mi portátil? No: los modelos frontier requieren clústeres de GPUs de centro de datos. Lo que sí puedes ejecutar localmente (con Ollama) son modelos open weights pequeños y medianos cuantizados, que son útiles para muchas tareas pero no igualan a los frontier en las difíciles. La regla de la VRAM de la sección 2.4 te dice qué cabe en tu máquina.

5. ¿Debo aprender PyTorch o me basta con las APIs? Para el rol de AI Engineer (construir aplicaciones sobre modelos), las APIs + frameworks de orquestación son tu día a día y PyTorch es opcional. Para ML Engineer (entrenar/afinar modelos), PyTorch es imprescindible. Esta academia te da los fundamentos conceptuales de ambos mundos y profundiza en el primero, que concentra la mayor demanda laboral.

6. ¿LangChain no tenía mala fama? ¿Por qué lo enseñáis? Tuvo críticas justificadas (abstracciones excesivas, cambios de API). Lo enseñamos porque (a) su ecosistema de integraciones sigue siendo el mayor, (b) LangGraph, su evolución para agentes, es un estándar de facto en producción, y (c) te lo encontrarás en el mercado laboral sí o sí. Pero lo enseñamos DESPUÉS del SDK crudo, para que uses el framework por decisión y no por dependencia.

7. ¿Qué diferencia hay entre usar la API de Anthropic directamente y usar Claude vía AWS Bedrock? El modelo es el mismo; cambia el envoltorio. API directa: alta en minutos, funciones nuevas antes, ideal para aprender y para startups. Bedrock: facturación unificada con AWS, controles corporativos (IAM, redes privadas, residencia regional), homologación de compras más fácil — lo que exigen las grandes empresas. Aprenderás ambas vías.

8. ¿MCP sustituye al function calling? No: lo estandariza. Function calling es la capacidad del modelo de pedir que se ejecute una función; MCP es el protocolo que empaqueta herramientas, recursos y prompts en servidores reutilizables por cualquier aplicación compatible. Un cliente MCP traduce las herramientas de los servidores a function calling de cara al modelo. Son niveles distintos de la misma pila.

9. ¿Merece la pena n8n si sé programar? Sí, como herramienta táctica: para automatizaciones internas y proyectos de consultoría rápidos, montar un flujo visual en una hora gana a programarlo en un día. Para producto core, lógica compleja o cualquier cosa que necesite tests y versionado serio, escribe código. Saber cuándo usar cada uno es justo el criterio que vende un consultor.

10. Con la IA generando código, ¿tiene sentido estudiar todo esto? Más que nunca. La IA escribe código, pero alguien tiene que decidir QUÉ construir, con QUÉ arquitectura, QUÉ modelo, a QUÉ coste y con QUÉ garantías — todo lo que has visto en este capítulo. Los asistentes de código hacen más productivo al que tiene criterio y más peligroso al que no lo tiene. Esta academia construye el criterio; la IA será tu multiplicador, no tu sustituto.

11. ¿Cada cuánto se queda obsoleto lo que aprendo aquí? Separa tres niveles: los modelos concretos rotan cada pocos meses (por eso este capítulo evita versiones); las herramientas evolucionan en años (FastAPI, Postgres, Docker son muy estables; LangGraph y MCP maduran rápido pero sin rupturas constantes); y los conceptos (capas, RAG, agentes, streaming, trade-off propietario/abierto) duran una carrera. La academia está diseñada para cargar el peso en los dos últimos niveles.

12. ¿Qué cloud aprendo primero si mi objetivo es trabajar en España/Latinoamérica? AWS es la apuesta estadísticamente más segura por cuota de mercado empresarial, y es la que usa esta academia (módulo 11). Azure es muy fuerte en corporaciones ligadas a Microsoft; GCP en empresas data-first. La buena noticia: los conceptos (cómputo, IAM, redes, plataformas de modelos) son análogos — el segundo cloud se aprende en una fracción del tiempo del primero.

13. Resumen del capítulo¶

La industria de la IA se organiza en seis capas: hardware → cloud → modelos → APIs/plataformas → frameworks → aplicaciones. Tú trabajarás sobre todo en las tres superiores. Clasificar cualquier noticia o herramienta por capa es tu primer filtro profesional.
La IA necesita GPUs porque su cómputo es masivamente paralelo (miles de ayudantes pelando patatas, no pocos chefs). NVIDIA domina por CUDA, un foso de software y ecosistema, no solo de silicio. La VRAM determina qué modelo cabe dónde (~2 bytes/parámetro en 16 bits; la cuantización lo reduce). Entrenar es cosa de laboratorios con clústeres; inferir es lo que tú pagarás y optimizarás. Como estudiante no necesitas hardware especial: APIs y cloud.
Los proveedores de modelos se dividen en propietarios (Anthropic/Claude, OpenAI/GPT, Google/Gemini) y open weights (Meta/Llama, Mistral, DeepSeek, Qwen). Propietario = máxima calidad y cero infraestructura; open weights = control, privacidad y coste marginal bajo a cambio de operarlo tú. La decisión se toma con una matriz de criterios (privacidad, coste, control, calidad), y la respuesta empresarial más común es híbrida.
El cloud para IA tiene tres hyperscalers (AWS/Bedrock+SageMaker, Google/Vertex, Azure/AI Foundry) y un ecosistema de especialistas (Modal, Replicate, Together, Groq). API directa para agilidad; cloud provider para compliance corporativo. Profundizaremos en el módulo 11.
Los frameworks se eligen por propósito: PyTorch (entrenar), scikit-learn (tabular), Hugging Face (open weights), SDKs oficiales (siempre, y primero), LangChain/LangGraph (orquestación/agentes), LlamaIndex (RAG), Vercel AI SDK (frontend), Ollama/vLLM (local/producción self-host), n8n (automatización periférica).
MCP es el "USB-C de la IA": el estándar abierto (creado por Anthropic, adoptado por la industria) que convierte M×N integraciones en M+N. Se apoya en function calling y viaja sobre REST/SSE. Módulo 08 completo.
El stack de la academia (Python+FastAPI, TypeScript+Next.js, Postgres+pgvector, Redis, Docker, LangGraph, MCP, AWS) está elegido criterio a criterio para maximizar aprendizaje transferible y empleabilidad.
El mercado ofrece varios roles (AI Engineer —el central y el que más crece—, ML Engineer, Solutions Architect, Consultant, Founder); lee responsabilidades, no títulos.
Para mantenerte al día: fuentes primarias + poca curación buena + las cinco preguntas antihype. Huye de los cursos milagro; tu ventaja competitiva es exactamente lo que estás construyendo: criterio con fundamentos.

Con este mapa en la cabeza, el resto de la academia deja de ser una lista de herramientas y se convierte en un recorrido con sentido: sabrás en todo momento en qué capa estás, por qué usas lo que usas y qué alternativas existen. Eso es pensar como ingeniero.

Ahora toca consolidar: te esperan los ejercicios del módulo.

14. Bibliografía y enlaces oficiales¶

Documentación y blogs de laboratorios de modelos¶

Anthropic — Noticias: https://www.anthropic.com/news · Documentación de Claude: https://docs.claude.com · Ingeniería: https://www.anthropic.com/engineering
OpenAI — Noticias: https://openai.com/news · Documentación: https://platform.openai.com/docs
Google DeepMind: https://deepmind.google · Google AI for Developers: https://ai.google.dev
Meta AI (Llama): https://ai.meta.com · https://www.llama.com
Mistral AI: https://mistral.ai · Documentación: https://docs.mistral.ai
DeepSeek: https://www.deepseek.com · Qwen (Alibaba): https://qwen.ai y organización en Hugging Face: https://huggingface.co/Qwen

Protocolos y estándares¶

Model Context Protocol (MCP): https://modelcontextprotocol.io · Anuncio original: https://www.anthropic.com/news/model-context-protocol
Tool use / function calling (Anthropic): https://docs.claude.com/en/docs/agents-and-tools/tool-use

Cloud¶

AWS — Bedrock: https://aws.amazon.com/bedrock/ · SageMaker: https://aws.amazon.com/sagemaker/
Google Cloud — Vertex AI: https://cloud.google.com/vertex-ai
Microsoft — Azure AI Foundry: https://azure.microsoft.com/products/ai-foundry
Modal: https://modal.com · Replicate: https://replicate.com · Together AI: https://www.together.ai · Groq: https://groq.com

Frameworks y librerías¶

PyTorch: https://pytorch.org · TensorFlow: https://www.tensorflow.org · JAX: https://jax.dev
scikit-learn: https://scikit-learn.org
Hugging Face: https://huggingface.co · Curso gratuito: https://huggingface.co/learn
SDK de Anthropic (Python): https://github.com/anthropics/anthropic-sdk-python · SDK de OpenAI (Python): https://github.com/openai/openai-python
LangChain: https://www.langchain.com · LangGraph: https://langchain-ai.github.io/langgraph/
LlamaIndex: https://www.llamaindex.ai
Vercel AI SDK: https://ai-sdk.dev
Ollama: https://ollama.com · vLLM: https://docs.vllm.ai
n8n: https://n8n.io
FastAPI: https://fastapi.tiangolo.com · Next.js: https://nextjs.org
PostgreSQL: https://www.postgresql.org · pgvector: https://github.com/pgvector/pgvector · Redis: https://redis.io · Docker: https://www.docker.com

Hardware y ecosistema¶

NVIDIA CUDA: https://developer.nvidia.com/cuda-zone
Google Cloud TPU: https://cloud.google.com/tpu
arXiv (papers de IA): https://arxiv.org

Nota

todos los enlaces apuntan a fuentes oficiales. Si alguno cambia (pasa a menudo en esta industria), busca el nombre del proyecto + "docs" — y acostúmbrate a llegar siempre a la fuente primaria.

Anterior	Módulo	Siguiente
Capítulo 6: ¿Cómo aprende una máquina?	01-FUNDAMENTOS	Ejercicios del módulo

Capítulo 7: Ecosistema, herramientas y hardware de la IA en 2026¶

Índice¶

1. El mapa de la industria por capas¶

1.1 El diagrama completo¶

1.2 Capa por capa: qué hace cada una y quién vive ahí¶

1.3 ¿Dónde trabajarás tú?¶

2. Hardware: por qué la IA necesita GPUs¶

2.1 La intuición: cocineros expertos vs. miles de ayudantes¶

2.2 CPU vs GPU vs TPU vs NPU: tabla comparativa¶

2.3 NVIDIA y CUDA: la anatomía de un foso competitivo¶

2.4 VRAM: la memoria que manda¶

2.5 Entrenamiento vs. inferencia en hardware¶

2.6 Qué necesitas TÚ realmente como estudiante¶

3. Proveedores de modelos fundacionales¶

3.1 Los grandes laboratorios¶

Anthropic (Claude)¶

OpenAI (GPT)¶

Google DeepMind (Gemini)¶

Meta (Llama) — el campeón del open weights occidental¶

Mistral AI¶

DeepSeek, Qwen y el open source chino¶

3.2 Tabla comparativa de proveedores¶

3.3 Propietarios vs. open weights¶

3.4 Tabla de decisión empresarial¶

4. Cloud para IA¶

4.1 Los tres hyperscalers¶

AWS (Amazon Web Services)¶

Google Cloud (GCP)¶

Microsoft Azure¶

4.2 Las alternativas especializadas¶

4.3 ¿API directa o cloud provider?¶

5. Frameworks y librerías por propósito¶

5.1 Tabla maestra de frameworks¶

5.2 Cada herramienta en profundidad¶

PyTorch — el estándar del deep learning¶

TensorFlow y JAX — el otro linaje¶

scikit-learn — el veterano imprescindible del ML clásico¶

Hugging Face — el GitHub de los modelos¶

SDKs oficiales (anthropic, openai) — tu pan de cada día¶

LangChain y LangGraph — orquestación y agentes¶

LlamaIndex — especialista en RAG¶

Vercel AI SDK — la IA en el frontend¶

Ollama y vLLM — servir modelos localmente¶

n8n — automatización visual¶

5.3 Qué framework se usa en qué módulo de la academia¶

6. Protocolos y estándares¶

6.1 MCP: el "USB-C de la IA"¶

6.2 Function calling¶

6.3 APIs REST y streaming¶

7. El stack de esta academia, decisión a decisión¶

8. Roles y mercado laboral¶

9. Cómo mantenerse actualizado sin ahogarse¶

Fuentes primarias (la verdad de primera mano)¶

Fuentes secundarias (curación)¶

El método antihype: cinco preguntas ante cada anuncio¶

Sobre influencers y "cursos milagro"¶

10. Buenas prácticas¶

11. Errores comunes¶

12. Preguntas frecuentes (FAQ)¶

13. Resumen del capítulo¶

14. Bibliografía y enlaces oficiales¶

Documentación y blogs de laboratorios de modelos¶

Protocolos y estándares¶

Cloud¶

Frameworks y librerías¶

Hardware y ecosistema¶

SDKs oficiales (`anthropic`, `openai`) — tu pan de cada día¶