Capítulo 10 — La capa del motor LLM

Décima entrega del recorrido capítulo por capítulo de LLM Primer VI: Scaling AI Systems. El capítulo que nombra la frontera entre el motor y la plataforma, y recorre los cinco motores que dominan esa capa en 2026.

Por qué existe este capítulo

Los Capítulos 1–9 recorrieron la maquinaria que toca un único forward pass: el bucle autorregresivo, la caché KV, el sustrato GPU, la cuantización que lo reduce, el batching que oculta su tiempo muerto y la decodificación especulativa que rompe su dependencia secuencial. Nada de eso se despacha como una librería que puedes pip install y olvidar. Alguien lo cablea en un runtime de un solo nodo que envuelve un modelo, es dueño de la caché KV, planifica peticiones sobre un batch continuo y expone una API de inferencia. Ese runtime es el motor. El Capítulo 10 nombra el trabajo de la capa de motor, la distingue de la capa de plataforma (Capítulo 11), y recorre los cinco motores — vLLM, TensorRT-LLM, SGLang, TGI, Ollama — que hacen intercambios mecánicos distintos sobre el mismo trabajo.

10.1 vLLM es el default Python-nativo

vLLM es el motor por el que la mayoría de equipos de producción deberían empezar, porque toma la decisión por defecto correcta en cada eje que alguien que empieza no sabría cómo pensar, y lo hace en Python. PagedAttention le da colapso de fragmentación del 60–80 por ciento a un dígito, lo que aproximadamente dobla el tamaño de batch alcanzable en la misma GPU. El batching continuo se apila encima de forma natural, con chunked prefill mezclando trabajo de prefill y de decode en la misma iteración para que la frontera entre ambos no sea tiempo muerto. La compartición copy-on-write de prefijos es gratis por el diseño de la tabla de bloques. La interfaz es genuinamente batch offline o HTTP compatible con OpenAI en unas pocas líneas, y cada nueva arquitectura de modelo aterriza allí rápido porque la comunidad es amplia. Es el motor sobre el que estandarizar cuando el operador no tiene una razón específica para elegir otra cosa.

10.2 TensorRT-LLM compra throughput con un pipeline de build

El pitch de TensorRT-LLM es estrecho. Si la flota es exclusivamente NVIDIA, si cada punto porcentual de throughput por dólar importa, y si el equipo pagará un impuesto de ingeniería para compilar archivos de engine específicos de modelo por generación de hardware, TRT-LLM extrae entre un 15 y un 35 por ciento más de throughput que vLLM sobre el mismo hardware. El mecanismo está a nivel de kernel: baja el grafo del transformer a una IR específica de NVIDIA, fusiona kernels adyacentes (layernorm + matmul + activación en un único launch), selecciona kernels óptimos por shape de una librería pre-tuneada, produce un engine serializado y lo corre bajo Triton Inference Server. La fusión importa porque el overhead de lanzamiento de kernel es de 5–10 μs cada uno y un forward pass ingenuo de 70B dispara miles por token. El impuesto es el propio pipeline de build — un paso de compilación por modelo, por GPU y por régimen de batch cuyo coste operativo la mayoría de los equipos subestima. SGLang es la otra especialización: RadixAttention guarda la caché KV para cada prefijo de prompt que el motor haya visto en un árbol radix, así que dos peticiones que compartan un prefijo de k tokens comparten la KV para exactamente esos k tokens entre batches y en el tiempo. En cargas agénticas con system prompts largos compartidos y sufijos variantes cortos, SGLang entrega 2–6× de throughput sobre vLLM, y su DSL de salida estructurada refuerza esquemas JSON a nivel de logit para que la salida esté garantizada de validar.

10.3 El árbol de decisión pasa por la forma de la carga, no por el titular de throughput

Los cinco motores se despliegan en un pequeño árbol de decisión. Portátil de desarrollador o edge con aceleradores mixtos → Ollama. Flota GPU de producción, exclusivamente NVIDIA, alto QPS, ROI de throughput que justifica el pipeline de build → TensorRT-LLM. Hardware mixto o cambios frecuentes de modelo, carga dominada por patrones estructurados con prefijos pesados (agentes, tool calls, prompts compartidos largos) → SGLang. Hardware mixto, carga general de chat, integración profunda con Hugging Face → TGI. Todo lo demás → vLLM. La decisión no es permanente: los motores son intercambiables en la frontera de API — todos hablan HTTP al estilo OpenAI — así que un router de capa de plataforma puede desplazar tráfico por modelo, por carga o por región sin cambiar el código del cliente. Muchos stacks de producción corren dos o tres motores en paralelo. Cuidado con el benchmark titular: "tokens por segundo en Llama-2-7B con batch 1" responde a una pregunta que ninguna carga de producción se hace. Benchmarkea sobre tu propio modelo, tu propia distribución de prompts y tu propio perfil de concurrencia; medio día, ahorra meses.

Lo que prepara el Capítulo 10

Cada motor descrito en este capítulo se detiene en la misma frontera. Sabe de kernels, de bloques KV y de batching continuo; no sabe de réplicas, de tenants, de cadenas ni de autenticación. El Capítulo 11 recorre la capa de plataforma que se ocupa de esas preocupaciones — Ray Serve, KServe, BentoML, Triton Inference Server — y muestra que la elección tiene mucho menos que ver con features que con qué modelo operativo encaja con la infraestructura y las competencias existentes del equipo.

Próximamente — Capítulo 11: La capa de plataforma y orquestación. Ray Serve, KServe, BentoML, Triton — las cuatro plataformas que se sientan sobre el motor, elegidas por encaje con la cultura de operaciones.