SMG: por qué separar CPU y GPU en el serving de LLMs

Servir un modelo de lenguaje a escala tiene un problema estructural que rara vez se discute fuera de los equipos de infraestructura: la GPU hace dos trabajos muy distintos —prefill y decode— con requisitos de memoria y cómputo completamente diferentes, y obligarlos a coexistir en el mismo hardware tiene un coste real. El equipo de LightSeek acaba de publicar en el blog oficial de PyTorch un análisis técnico detallado de SMG (Separated Memory and GPU), una arquitectura que propone desacoplar ambas fases para servirlas de forma independiente.

El artículo, disponible en pytorch.org/blog/lightseek-smg, llega en un momento en que el coste de inferencia sigue siendo uno de los cuellos de botella más citados por equipos que despliegan modelos en producción, y ofrece una perspectiva de ingeniería concreta sobre cómo reorganizar el stack de serving.

Prefill y decode: dos problemas distintos en el mismo hardware

Cuando se procesa una petición a un LLM, el trabajo se divide en dos fases bien diferenciadas. El prefill es intensivo en cómputo: procesa el prompt completo en paralelo y genera el primer token. El decode es iterativo y secuencial: genera un token a la vez, con alta presión sobre la memoria para mantener el KV cache. Mezclar ambas fases en las mismas GPUs genera lo que en la literatura se conoce como GPU bubbles: períodos en que el hardware queda infrautilizado porque los patrones de acceso a memoria de ambas fases se interfieren mutuamente.

SMG aborda este problema llevando la fase de decode —o partes de ella, especialmente la gestión del KV cache— hacia CPUs o memoria del sistema, liberando la GPU para concentrarse en el trabajo de cómputo denso del prefill. La idea no es nueva en su intuición, pero la propuesta de LightSeek añade detalles de implementación sobre cómo coordinar la transferencia de datos entre CPU y GPU sin introducir latencias que anulen el beneficio.

Qué propone SMG exactamente

La arquitectura SMG desacopla tres elementos clave:

• Gestión del KV cache en CPU: el KV cache crece con la longitud del contexto. Almacenarlo en memoria del sistema, más barata y abundante que la VRAM, permite atender contextos largos sin escalar el número de GPUs de forma lineal.
• Scheduling separado por fase: el planificador de peticiones diferencia entre jobs en fase de prefill y jobs en decode, asignándolos a recursos distintos y evitando la contención.
• Transferencia asíncrona: los bloques de KV cache se mueven entre CPU y GPU de forma asíncrona durante los ciclos en que la GPU no los necesita, minimizando el impacto en la latencia de generación.

El equipo reporta mejoras en throughput y una reducción del coste por token en sus pruebas internas, aunque los números concretos dependen del perfil de las peticiones —longitud del prompt, longitud de la respuesta, tasa de concurrencia— y no son directamente extrapolables a cualquier despliegue.

Para quién es relevante esto

Esta propuesta interesa principalmente a tres perfiles. Primero, equipos que despliegan modelos propios en infraestructura propia y tienen margen para modificar su stack de serving; para ellos, SMG ofrece una vía para exprimir más rendimiento del hardware existente antes de escalar horizontalmente. Segundo, proveedores de inferencia como servicio que facturan por token y donde cada punto de eficiencia tiene impacto directo en margen. Tercero, equipos que trabajan con ventanas de contexto largas —como las que ofrece Claude Opus 4.7 con su ventana de 1M de tokens— donde la presión sobre el KV cache es especialmente severa y el coste de mantenerlo en VRAM se vuelve prohibitivo.

Para proyectos pequeños o quienes usan APIs gestionadas, el impacto es indirecto: si los proveedores adoptan técnicas como SMG, el coste por token debería bajar con el tiempo.

Integración con el ecosistema PyTorch

Que el artículo aparezca en el blog oficial de PyTorch no es un detalle menor. Significa que LightSeek ha elegido publicar dentro del ecosistema de referencia para el desarrollo de modelos en Python, lo que facilita que la propuesta sea evaluada e integrada por otros proyectos que ya usan PyTorch como base. Frameworks de serving como vLLM o SGLang, que corren sobre PyTorch, son candidatos naturales para incorporar ideas de SMG si los resultados se sostienen en pruebas más amplias.

---

Desde EP, la propuesta nos parece sólida en su diagnóstico: la contención entre prefill y decode es un problema real y documentado, y abordarla a nivel arquitectural tiene más recorrido que seguir añadiendo VRAM. Que los detalles de implementación resistan el escrutinio de la comunidad es lo que determinará si SMG pasa de artículo interesante a práctica adoptada.