Infraestructura de ML/AI: un vistazo rápido y las habilidades que necesitas (2026)

La mayoría de los equipos conoce la infraestructura de IA por el camino fácil: llaman a la API de un modelo alojado y lanzan su producto. Eso funciona hasta que la factura, la latencia o las reglas de residencia de datos obligan a plantear una pregunta más difícil: ¿qué se necesita realmente para ejecutar modelos por cuenta propia? La respuesta es un stack —cómputo, datos, orquestación, entrenamiento, serving y operaciones— y un cambio que la industria dejó claro a principios de 2026: lo difícil y costoso ya no es entrenar modelos, sino servirlos (inferencia de IA de NVIDIA).

Este artículo ofrece un vistazo práctico a ese stack. Alojaremos un LLM de pesos abiertos en Kubernetes con vLLM y KServe, interpretaremos las métricas importantes, haremos las cuentas de los costos de GPU y terminaremos con las habilidades que necesitan ingenieros y PMs para trabajar con este stack.

TL;DR

La infraestructura de IA es un sistema de capas, no un solo producto: cómputo con GPU → datos/almacenamiento → orquestación → entrenamiento → inferencia/serving → MLOps y observabilidad. Una combinación común de código abierto es Kubernetes + Ray + PyTorch + vLLM (Anyscale).
2026 es la «economía de la inferencia». NVIDIA afirma que su Blackwell Ultra (GB300 NVL72) ofrece un costo por token hasta 35x menor que Hopper para cargas de trabajo de agentes de baja latencia y presenta la inferencia —no el entrenamiento— como el costo dominante (inferencia de IA de NVIDIA).
La opción práctica habitual para alojar LLMs por cuenta propia es vLLM (el motor, con PagedAttention + continuous batching y una API compatible con OpenAI) integrado con KServe (autoescalado, despliegues canary, enrutamiento) en Kubernetes (documentación de vLLM, LLMInferenceService de KServe).
La utilización de GPU determina el presupuesto. Las GPU dedicadas suelen estar subutilizadas, al 25–35%; agregar una capa de gestión de colas como Kueue junto con MIG/time-slicing puede elevar la utilización al 60–85% (stack 2026 de KubernetesGuru).
Vigila dos cifras de latencia: tiempo hasta el primer token (TTFT) y tiempo por token de salida (TPOT). vLLM expone ambas mediante Prometheus (KubernetesGuru).
La madurez de MLOps depende de la automatización, no de las herramientas. Google Cloud define tres niveles: 0 (manual), 1 (automatización del pipeline / entrenamiento continuo), 2 (CI/CD completo) (MLOps de Google Cloud).
Las habilidades fundamentales son sencillas y duraderas: Python, SQL, Linux, Docker, Kubernetes, un proveedor de nube y la capacidad de razonar sobre GPU, latencia y costos.

Qué aprenderás aquí

Un modelo mental sencillo del stack de infraestructura de ML/AI, capa por capa
Por qué la industria pasó de centrarse en el entrenamiento a centrarse en la inferencia en 2026
Cómo alojar un LLM de pesos abiertos en Kubernetes con vLLM y KServe (con configuración real)
Cómo fluye una solicitud de inferencia a través del stack (prefill, decode, caché KV)
Las métricas de GPU y costos que determinan si tu despliegue funciona bien o pierde dinero
Un mapa concreto de habilidades para ingenieros y una breve perspectiva sobre «lo que necesitan saber los PMs»

Qué significa realmente «infraestructura de IA»

Si quitamos los logos, la infraestructura de IA no es más que el conjunto de capas que llevan un modelo de «pesos en disco» a «respuesta en producción», de forma confiable y a un costo razonable. Una forma útil de entenderla es de abajo hacia arriba:

+-------------------------------------------------------------+
|  Application layer                                          |
|  apps, internal tools, agent frameworks                    |
+-----------------------------+-------------------------------+
                              |
+-----------------------------+-------------------------------+
|  Inference / serving                                       |
|  vLLM (engine) wrapped by KServe; Triton for multi-model   |
+-----------------------------+-------------------------------+
                              |
+-----------------------------+-------------------------------+
|  Orchestration / scheduling                                |
|  Kubernetes + Kueue (GPU queueing) + Karpenter (nodes)     |
+-----------------------------+-------------------------------+
                              |
+-----------------------------+-------------------------------+
|  GPU compute layer                                         |
|  NVIDIA GPU Operator: drivers, runtime, MIG, DCGM metrics  |
+-----------------------------+-------------------------------+
                              |
+-----------------------------+-------------------------------+
|  Training / experimentation                                |
|  PyTorch + Ray (KubeRay); MLflow tracking + model registry |
+-----------------------------+-------------------------------+
                              |
+-----------------------------+-------------------------------+
|  Data / storage                                            |
|  object storage (S3/GCS), data pipelines, feature stores   |
+-------------------------------------------------------------+

Anyscale describe la combinación habitual de código abierto mediante tres roles reutilizables: un framework de entrenamiento/inferencia (PyTorch, vLLM) que ejecuta modelos rápidamente en GPU, un motor de cómputo distribuido (Ray) que programa el trabajo y gestiona las fallas de una tarea, y un orquestador de contenedores (Kubernetes) que asigna nodos y ejecuta tareas (Anyscale). Esa separación es el modelo mental que conviene recordar: los frameworks ejecutan los cálculos, un motor coordina una tarea y Kubernetes coordina el clúster.

Para PMs: piensen en un restaurante. La GPU es la estufa, Kubernetes es la distribución de la cocina, la capa de gestión de colas es quien decide qué pedidos se cocinan a continuación y vLLM/KServe es el cocinero que convierte los ingredientes crudos (tokens) en platos servidos (respuestas). Cuando la factura se dispara, casi siempre se debe a que la estufa está sin usarse, no a la receta.

El cambio de 2026: de la era del entrenamiento a la economía de la inferencia

Durante años, la infraestructura de IA se optimizó para el entrenamiento: modelos más grandes, más FLOPs y clústeres más grandes. En 2026, ese centro de gravedad cambió. La propia página de inferencia de NVIDIA lo plantea sin rodeos: cada token que produce un agente es una llamada de inferencia y, a escala, esa demanda se acumula, por lo que el costo de la IA pasa de crear modelos a ejecutarlos (inferencia de IA de NVIDIA).

Las afirmaciones sobre el hardware reflejan esa prioridad. NVIDIA afirma que el GB300 NVL72 (72 GPU Blackwell Ultra en un rack, conectadas mediante una red NVLink de 130 TB/s) ofrece hasta 50x más throughput por megavatio y un costo por token hasta 35x menor que Hopper para cargas de trabajo de agentes de baja latencia, citando los benchmarks InferenceX de SemiAnalysis del Q1 2026 (inferencia de IA de NVIDIA).

La conclusión práctica para quienes construyen estos sistemas no es «compra Blackwell». Es la lección de fondo:

La inferencia se rige por reglas distintas a las del entrenamiento: la latencia y el costo por token importan más que los FLOPs máximos.
Los equipos que destacan en infraestructura son los que sirven inteligencia de manera eficiente, no los que tienen más GPU.
Una técnica moderna importante es el serving desagregado: separar la fase de prefill, que exige mucho cómputo, y la fase de decode, sensible a la latencia, en diferentes GPU para optimizar cada una de manera independiente (NVIDIA Blackwell Ultra MLPerf).

Por eso, el resto de este artículo se centra principalmente en el serving.

Un stack de referencia práctico: alojar inferencia de LLMs en Kubernetes

En 2025–2026, AI/ML en Kubernetes se convirtió en una opción habitual para producción, consolidándose alrededor de un conjunto específico de herramientas respaldadas por la CNCF y por proveedores (KubernetesGuru). Este es el conjunto mínimo útil para alojar un LLM por cuenta propia y lo que hace cada componente.

Capa	Herramienta	Función
Motor de inferencia	vLLM	Carga el modelo, agrupa solicitudes en lotes y ofrece una API compatible con OpenAI
Framework de serving	KServe	Integra vLLM con autoescalado, despliegues canary, enrutamiento y escalado a cero
Programación de GPU	Kueue	Gestión de colas y cuotas de GPU con reparto equitativo entre equipos
Aprovisionamiento de nodos	Karpenter	Agrega o elimina nodos con GPU (incluidos los spot) según la demanda
Gestión de GPU	NVIDIA GPU Operator	Controladores, runtime de contenedores, MIG y métricas de DCGM
Observabilidad	DCGM + Prometheus + Grafana	Métricas y alertas de GPU e inferencia

Paso 1: El motor — vLLM

vLLM (del Sky Computing Lab de UC Berkeley) es el motor de inferencia de LLMs de referencia en 2026. Sus dos grandes ideas son PagedAttention (gestiona la caché KV como memoria virtual para no desperdiciar memoria de GPU) y continuous batching (las nuevas solicitudes se incorporan al lote en ejecución en lugar de esperar a que termine). También incluye una API HTTP compatible con OpenAI, por lo que el código cliente existente funciona en gran medida sin cambios (KubernetesGuru).

La forma más sencilla de ejecutarlo en una máquina con una sola GPU requiere un comando:

vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192 \
  --port 8000

Ahora habla el dialecto de OpenAI. Cualquier cliente de OpenAI puede apuntar a él cambiando la URL base:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed-self-hosted")

resp = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=[{"role": "user", "content": "Explain KV cache in one sentence."}],
)
print(resp.choices[0].message.content)

Ese es el objetivo de alojarlo por cuenta propia: el código de tu aplicación no cambia, solo cambia dónde se producen los tokens.

Paso 2: El framework de serving — KServe

Un pod de vLLM por sí solo no tiene autoescalado, despliegues canary, enrutamiento de múltiples modelos ni escalado a cero. KServe (un proyecto graduado de la CNCF) agrega esas capacidades nativas de Kubernetes y puede integrar vLLM, Triton o contenedores personalizados (KubernetesGuru). En KServe v0.17+, las cargas de trabajo generativas cuentan con un CRD diseñado específicamente para ellas, LLMInferenceService, construido sobre el framework llm-d para enrutamiento e inferencia distribuida (KServe).

Un despliegue mínimo de Llama-3.1-8B en un solo nodo se ve así:

apiVersion: serving.kserve.io/v1alpha1
kind: LLMInferenceService
metadata:
  name: llama-3-8b
  namespace: default
spec:
  model:
    uri: hf://meta-llama/Llama-3.1-8B-Instruct
    name: meta-llama/Llama-3.1-8B-Instruct
  replicas: 3
  template:
    containers:
      - name: main
        image: vllm/vllm-openai:latest
        resources:
          limits:
            nvidia.com/gpu: "1"
            cpu: "8"
            memory: 32Gi
  router:
    gateway: {}     # managed Gateway API ingress
    route: {}       # managed HTTPRoute
    scheduler: {}   # managed load-balancing scheduler

Aplicar ese archivo crea tres pods de réplica (1 GPU cada uno), un Gateway para el tráfico externo, un HTTPRoute y un programador inteligente para balancear la carga, además de un inicializador de almacenamiento para descargar el modelo (KServe). Para modelos de frontera demasiado grandes para un solo nodo (por ejemplo, 70B+), se agrega un bloque parallelism (paralelismo de tensores/datos) y una especificación worker, lo que hace que KServe utilice un LeaderWorkerSet para servir el modelo en varios nodos (lanzamiento de KServe v0.17).

Paso 3: No ignores la programación de GPU — Kueue

Este es el problema del que nadie te advierte: sin una capa de gestión de colas, la tarea enorme de un equipo acapara todas las GPU y los demás quedan bloqueados (head-of-line blocking). Kueue (CNCF) agrega programación con reparto equitativo, cuotas y gang scheduling para tareas distribuidas. El impacto reportado es considerable: la utilización de GPU pasa de una base de 25–35% a 60–85% (KubernetesGuru). En la factura de GPU, esa diferencia puede separar un servicio sostenible de un centro de costos fuera de control.

Cómo encajan las piezas

client request (OpenAI-format JSON)
        |
        v
  Gateway API  ──►  KServe scheduler (load balance / prefix-aware route)
        |
        v
  vLLM pod (replica)                 [scheduled by Kueue onto a GPU slot]
        |
        +--► PagedAttention KV cache  (GPU memory)
        +--► continuous batching      (joins in-flight batch)
        |
        v
  GPU  ── NVIDIA GPU Operator (driver, runtime, MIG slice) ──► DCGM metrics
        |
        v
  streamed tokens back to the client

El recorrido de una solicitud de inferencia

Conviene saber qué ocurre dentro de ese pod de vLLM, porque así se entienden todas las métricas y los factores de costo que veremos después.

PROMPT IN                                          TOKENS OUT
   |                                                   ^
   v                                                   |
[ Prefill ]  read the whole prompt, build KV cache     |
   |  compute-heavy, runs once per request             |
   v                                                   |
[ Decode  ]  generate one token, append to KV cache ---+
   |  memory-bandwidth-heavy, loops per output token
   |  continuous batching interleaves many requests here
   v
 stop (EOS or max tokens)

Dos fases, dos comportamientos:

Prefill está limitado por la capacidad de cómputo y ocurre una sola vez: lee el prompt y llena la caché KV. Esta fase determina principalmente el tiempo hasta el primer token (TTFT).
Decode está limitado por el ancho de banda de memoria y se repite una vez por cada token de salida. Esta fase determina principalmente el tiempo por token de salida (TPOT).

Esta es precisamente la razón de ser del «serving desagregado»: separar prefill y decode en distintas GPU permite que cada fase use el paralelismo y el hardware que mejor le convienen (NVIDIA Blackwell Ultra MLPerf). También explica por qué la caché KV es el recurso más preciado de la GPU: PagedAttention existe específicamente para evitar que se desperdicie.

Observabilidad: las métricas que importan

Los dashboards habituales de CPU y memoria de los pods no muestran la realidad de las GPU. Necesitas dos familias adicionales de métricas (KubernetesGuru).

De DCGM Exporter (estado de la GPU):

DCGM_FI_DEV_GPU_UTIL — % de utilización de GPU
DCGM_FI_DEV_FB_USED — memoria de GPU (frame buffer) utilizada
DCGM_FI_DEV_POWER_USAGE — consumo de energía
DCGM_FI_DEV_GPU_TEMP — temperatura / señal de throttling

De vLLM (estado de la inferencia):

vllm:time_to_first_token_seconds — TTFT (lo que ocurre en prefill)
vllm:time_per_output_token_seconds — TPOT (lo que ocurre en decode)
vllm:gpu_cache_usage_perc — presión sobre la caché KV
vllm:num_requests_running — concurrencia actual

La alerta individual más valiosa es un aumento del P95 de TTFT: suele ser la primera señal de que una actualización del modelo o un cambio en el patrón de tráfico hizo que superaras tu presupuesto de latencia:

ALERT  HighTTFT
  EXPR   histogram_quantile(0.95,
           sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le)) > 2
  FOR    10m
  LABELS severity = "page"
  ANNOT  "P95 time-to-first-token > 2s for 10m"

Un buen dashboard muestra la utilización de GPU junto a la latencia de inferencia. Si la utilización es baja y la latencia es alta, estás pagando por hardware inactivo mientras los usuarios esperan: lo peor de ambos mundos, y casi siempre un problema de programación o batching, no del modelo.

Costos y economía de las GPU

Las GPU son la partida que supera por mucho a todas las demás, así que unas pocas cuentas ayudan bastante. Estos son los factores que afectan la factura:

La utilización determina el presupuesto. Una H100 dedicada que funciona al 30% cuesta lo mismo por hora que una que funciona al 85%. Reducir esa brecha con Kueue + MIG suele ser la mayor oportunidad individual de ahorro (KubernetesGuru).
MIG / time-slicing permiten compartir una GPU física. MIG divide una A100/H100/H200 en hasta 7 instancias aisladas; time-slicing comparte una GPU entre pods con menos aislamiento, pero funciona en todas las generaciones (KubernetesGuru).
El escalado a cero ahorra dinero, pero aumenta la latencia. KServe puede reducir a cero las réplicas de los modelos inactivos, pero la primera solicitud posterior debe esperar un arranque en frío de 30–120s mientras se carga el modelo. Para rutas donde la latencia es crítica, mantén minReplicas > 0 (KubernetesGuru).
Spot + Karpenter reduce el precio de los nodos para entrenamiento y trabajo por lotes que pueden interrumpirse.
El hardware más reciente cambia la curva de costo por token, la métrica que realmente se traduce en una factura por solicitud a escala (inferencia de IA de NVIDIA).

Un cálculo aproximado que ilustra el efecto de la utilización:

def cost_per_million_tokens(gpu_hourly_usd, tokens_per_sec, utilization):
    effective_tps = tokens_per_sec * utilization
    tokens_per_hour = effective_tps * 3600
    return gpu_hourly_usd / (tokens_per_hour / 1_000_000)

# Same GPU, same throughput ceiling — only utilization changes.
idle  = cost_per_million_tokens(3.00, 2500, 0.30)  # ~$1.11 / M tokens
tuned = cost_per_million_tokens(3.00, 2500, 0.85)  # ~$0.39 / M tokens

Estas cifras son ilustrativas, no una cotización: el costo real por token depende del modelo, la longitud de la secuencia, el tamaño del lote, la cuantización y el hardware. Lo importante es la proporción: elevar la utilización de 30% a 85% redujo el costo unitario efectivo aproximadamente un 65% sin tocar el modelo. Por eso, la programación y el batching, no los cambios de modelo, suelen ser el primer lugar donde optimizar.

Para PMs: las tres cifras que vale la pena seguir son el costo por millón de tokens, P95 TTFT (¿la respuesta se siente instantánea?) y la utilización de GPU (¿estamos desperdiciando el presupuesto?). La mayoría de las solicitudes de «necesitamos más GPU» en realidad significan «estamos usando las GPU que tenemos al 30%».

Dónde encaja MLOps

El serving es solo una mitad de la historia; la otra es el ciclo de vida alrededor del modelo. El enfoque ampliamente utilizado de Google Cloud mide MLOps según el grado de automatización del proceso, en tres niveles (MLOps de Google Cloud):

Level 0  Manual         notebooks -> hand-built model -> manual deploy
Level 1  Pipeline auto  automated pipeline retrains on new data (continuous training)
Level 2  CI/CD          build, test, deploy pipeline components automatically

La mayoría de los equipos empieza en el Nivel 0: científicos de datos capaces, pero con un camino a producción manual y basado en scripts. El Nivel 1 automatiza el pipeline de entrenamiento para que los modelos se reentrenen continuamente con datos recientes y con validación automatizada de datos y modelos. El Nivel 2 agrega un sistema real de CI/CD para que puedas desplegar componentes nuevos del pipeline de forma rápida y confiable, no solo nuevos pesos del modelo (MLOps de Google Cloud). Las herramientas de apoyo —seguimiento de experimentos y registro de modelos (MLflow), orquestación de pipelines (Airflow/Kubeflow) y GitOps (ArgoCD)— te ayudan a avanzar por esos niveles (KubernetesGuru).

Una nota pragmática: si solo sirves modelos de pesos abiertos mediante vLLM/KServe y no entrenas los tuyos, puedes trabajar sin problemas entre el Nivel 0 y el Nivel 1, dedicando la mayor parte de tu esfuerzo a la evaluación, los despliegues canary y la observabilidad en lugar del entrenamiento continuo.

Las habilidades que necesitas

Las herramientas cambian; los fundamentos no. Este es el mapa por capa, ordenado aproximadamente desde «aprende esto primero» hasta «aprende esto cuando lo necesites».

Fundamentos (imprescindibles)

Python — la lengua franca de las herramientas de ML y datos (hoja de ruta de MLOps)
SQL — siempre estarás moviendo y transformando datos
Linux, la shell y Git — todo se ejecuta sobre estas herramientas
Conocimientos básicos de ML — qué son el entrenamiento, la inferencia, los tokens y las ventanas de contexto

Capa de datos

Pipelines de datos / enfoque ETL
Procesamiento distribuido (Spark / PySpark) para conjuntos de datos demasiado grandes para una sola máquina (hoja de ruta de Dataquest)
Almacenamiento de objetos (S3/GCS) y versionado de datos y features

Contenedores y orquestación

Docker — construye imágenes pequeñas y reproducibles
Conceptos de Kubernetes — pods, deployments, services (no necesitas administrar un clúster para aportar valor, pero sí debes hablar el mismo idioma) (hoja de ruta de Dataquest)
Un proveedor de nube (AWS, GCP o Azure) de principio a fin

GPU y cómputo

Cómo funciona la memoria de GPU y por qué la caché KV domina el serving de LLMs
Uso compartido de GPU: MIG vs time-slicing y cuándo conviene cada uno (KubernetesGuru)
Fundamentos de entrenamiento distribuido: paralelismo de datos, tensores y pipeline (PyTorch DDP, etc.)

Entrenamiento e inferencia

PyTorch para el código del modelo
Ray / KubeRay para entrenamiento distribuido y ajuste (documentación de Ray)
vLLM / KServe / Triton para serving, además de los parámetros de cuantización y batching

Operaciones

MLOps: seguimiento de experimentos, registro de modelos, CI/CD para ML (MLOps de Google Cloud)
Observabilidad: Prometheus/Grafana, DCGM, OpenTelemetry y SLOs
Costos/FinOps: costo por token, utilización, Kubecost/OpenCost, estrategia de instancias spot
Seguridad y gobernanza: secretos, residencia de datos, inventario de modelos

El consejo que se repite en todas las hojas de ruta: no intentes aprender todas las herramientas a la vez. Construye un proyecto de principio a fin —ingiere datos, entrena o ajusta un modelo pequeño, despliégalo detrás de una API y monitóralo— y prioriza entender la arquitectura del sistema, porque las herramientas específicas seguirán cambiando (hoja de ruta de MLOps, hoja de ruta de Dataquest).

Lo que necesitan saber los PMs (una perspectiva más ligera)

Los factores que determinan el costo son la utilización de GPU y el costo por token, no «el modelo es caro».
La latencia se resume en dos cifras: TTFT (rapidez de respuesta) y TPOT (velocidad de streaming).
La decisión de construir o comprar depende del costo a escala, el control de la latencia y la residencia de datos/el cumplimiento normativo.
La escasez de GPU y los arranques en frío son restricciones reales que condicionan las hojas de ruta y los SLA.

Por dónde empezar

Un camino rápido y realista que refleja cómo se incorporan a este trabajo los equipos de producción:

Ejecuta vllm serve en una GPU (o una GPU alquilada en la nube) y hazle una llamada con el cliente de OpenAI. Experimenta TTFT y TPOT por ti mismo.
Ponlo en un contenedor y luego despliégalo con el LLMInferenceService de KServe mostrado arriba en un clúster administrado (EKS/GKE/AKS).
Agrega NVIDIA GPU Operator y un dashboard de Grafana con métricas de DCGM + vLLM. Observa la utilización mientras ejecutas pruebas de carga.
Agrega Kueue y una segunda carga de trabajo; observa cómo sube la utilización y desaparece el head-of-line blocking.
Solo ahora pasa a las herramientas avanzadas: particionamiento con MIG, escalado a cero, despliegues canary y (para 70B+) serving multinodo con llm-d.

Ese orden pone primero lo que te enseña cómo funciona el sistema y deja para después lo que solo importa a escala.

Temas pendientes y aspectos a seguir

Para mantener este artículo como un «vistazo rápido», varios temas importantes se resumieron o quedaron fuera. Vale la pena señalarlos:

La profundidad del entrenamiento (paralelismo de datos, tensores y pipeline; checkpoints; tolerancia a fallas multinodo) recibe un párrafo, no el capítulo que merece.
El serving de modelos que no son LLMs (ML clásico, visión, sistemas de recomendación mediante Triton o el InferenceService estándar de KServe) apenas se menciona.
La red de interconexión (NVLink, InfiniBand, RDMA) es la protagonista oculta del rendimiento con múltiples GPU y solo aparece como nota al pie.
La seguridad y el cumplimiento normativo (inyección de prompts en el límite de la infraestructura, aislamiento entre tenants, registros de auditoría) merecen un tratamiento propio.
Las cifras de los proveedores son cifras de los proveedores. Las afirmaciones de NVIDIA sobre costo por token y throughput provienen de sus propios materiales y de los benchmarks citados; valídalas con tu carga de trabajo antes de planificar presupuestos (inferencia de IA de NVIDIA).
El stack es joven. llm-d y el serving desagregado evolucionan rápidamente en 2026; espera cambios en las API y las mejores prácticas (KServe).

Algunos buenos artículos para continuar: un despliegue práctico multinodo de 70B con llm-d; una guía para decidir entre servicios administrados y alojamiento propio (SageMaker/Vertex vs Kubernetes); y un análisis a fondo de la atribución de costos de GPU con Kubecost/OpenCost.

Infraestructura de ML/AI: un vistazo rápido y las habilidades que necesitas