Capítulo 11 — La capa de plataforma y orquestación

Undécima entrega del recorrido capítulo por capítulo de LLM Primer VI: Scaling AI Systems. El capítulo que sostiene que la elección de plataforma no es sobre features sino sobre qué modelo operativo encaja con la cultura de operaciones ya existente del equipo.

Por qué existe este capítulo

Un motor envuelve un modelo sobre una GPU y produce tokens. Esa es su descripción de trabajo completa. En el momento en que producción necesita dos réplicas tras un load balancer, o dos motores distintos bajo un endpoint, o un pipeline que corra embed→retrieve→rerank→generate como una única llamada lógica, o un sistema de cuotas que impida que un tenant deje sin recursos a otro, o un autoscaler que añada réplicas conforme la profundidad de cola sube, el motor se ha quedado sin respuestas. El Capítulo 11 recorre las cuatro plataformas que dominan ese trabajo en 2026 — Ray Serve, KServe, BentoML, Triton Inference Server — y sostiene que la elección entre ellas es una pregunta de encaje con la cultura de operaciones del equipo, no una pregunta de features.

11.1 Ray Serve es Python-first; KServe es Kubernetes-first

Ray Serve es la plataforma que emerge cuando la pregunta de partida es "¿cómo sería un framework de serving si nunca tuviera que salir de Python para componer, escalar y desplegar un pipeline de modelos?". La respuesta es clases Python decoradas como actores, cableadas entre sí mediante llamadas a funciones Python, replicadas, colocadas y autoescaladas por el runtime de Ray. Los deployments componen pipelines llamándose a los métodos entre sí; el pipeline es Python, la observabilidad es Python, la historia de operaciones es Python. Es la elección natural cuando el mismo cluster ya está corriendo Ray para entrenamiento. KServe emerge del punto de partida opuesto: Kubernetes-first, neutral respecto al proveedor, declarativo. Un InferenceService de KServe es un CRD que captura dónde viven los pesos, qué runtime los sirve y cómo debe comportarse el autoscaling. La plataforma cablea los pods a través de Knative para escala-a-cero y de Istio para enrutado de tráfico, y expone un endpoint HTTP estable. El intercambio es expresividad — la composición de pipelines en KServe es más orientada a YAML que en Ray Serve — a cambio de portabilidad y estandarización.

11.2 BentoML empaqueta; Triton batchea modelos heterogéneos

BentoML toma una tercera postura: el trabajo principal de la plataforma es hacer del modelo + código + dependencias un único artefacto coherente — un Bento — y hacer que desplegar ese artefacto a cualquier sitio (Kubernetes, Lambda, Cloud Run, una VM pelada) sea una operación de un solo comando. Es lo que una imagen Docker es a las aplicaciones generales, en la capa de serving de modelos. La experiencia de autoría tiene forma de FastAPI en Python; la historia de deploy es el movimiento centrado en artefacto. El mejor encaje es una huella de operaciones pequeña y un equipo que quiere el camino más rápido desde "clase Python" hasta "endpoint desplegado que corre en cualquier sitio". Triton Inference Server es el batcher dinámico de grado empresa que históricamente dominó el serving alineado con NVIDIA. Aloja TensorFlow, PyTorch, ONNX, TensorRT, TensorRT-LLM y backends Python codo con codo, aplica su batcher dinámico a cargas no-LLM (recomendadores, clasificadores, embedders) y usa el scheduler de batching continuo para LLMs bajo su backend TensorRT-LLM. El mejor encaje es cargas heterogéneas o un equipo ya profundo en el stack de NVIDIA.

11.3 Las cuatro elecciones se parten por encaje de cultura de operaciones

Las cuatro plataformas se parten limpiamente. Python y Ray como centro de gravedad → Ray Serve. Kubernetes, manifiestos declarativos, portabilidad multi-cloud, aislamiento multi-tenant → KServe. Huella de operaciones pequeña, camino más rápido de clase a endpoint → BentoML. Cargas heterogéneas o casa NVIDIA-first → Triton. No son mutuamente excluyentes a nivel organizativo: un patrón común en orgs más grandes es Triton para los LLMs de mayor volumen en producción, Ray Serve para los pipelines RAG y de agentes que componen varias llamadas a modelo, KServe como paraguas que refuerza la multi-tenancy, y BentoML dentro de los entornos de desarrollador. El ejercicio útil al elegir es listar tres propiedades operativas que el equipo necesita absolutamente y tres con las que puede vivir sin, y luego ordenar las plataformas contra esa lista. Resiste la plataforma que "soporta todo" — cada plataforma soporta bien su núcleo y mal su periferia, y aquella cuyo núcleo se solape con los imprescindibles es la que el equipo disfrutará operando.

Lo que prepara el Capítulo 11

La frontera motor/plataforma es limpia cuando la unidad de replicación es un pod con un modelo sobre un nodo con GPU. Deja de ser limpia en el momento en que honramos el hecho del Capítulo 1: prefill y decode son cargas contradictorias. El Capítulo 12 las parte en flotas GPU separadas, envía la caché KV entre las flotas por la red, y expresa la partición en primitivas de Kubernetes — LeaderWorkerSet, PodCliqueSet de Grove, conciencia de topología de KAI Scheduler. La capa de plataforma es lo que hace operable la partición; la capa de plataforma es por lo que la partición es siquiera expresable.

Próximamente — Capítulo 12: Serving desagregado y Kubernetes. Separar prefill y decode en pods distintos y las primitivas de Kubernetes que lo expresan.