Servir modelos LLM en producción es difícil de afinar porque cada despliegue es un stack de decisiones que interactúan: backend del modelo, forma del tensor-parallel, separación prefill/decode, número de workers, configuración del scheduler, política de routing, comportamiento del KV cache, umbrales de autoescalado y topología. Esas decisiones se interconectan a través de capas: una mejora local puede mover el cuello de botella a otra parte. Para modelos grandes, incluso un experimento realista puede requerir muchas GPUs o nodos antes de saber si la idea valía la pena.
Esa es la motivación detrás de DynoSim, presentado como un gemelo digital del stack de servicio NVIDIA Dynamo. Es una simulación de eventos discretos guiada por workloads que combina timing medido del forward-pass del motor, los núcleos del scheduler Mocker, los comportamientos de Router y Planner, efectos del KV cache y trazas de carga sobre una sola línea temporal virtual. La meta no es una estimación analítica pura ni un emulador bit a bit del hardware: es una simulación fiel del servicio al nivel atómico de forward-passes que escala al stack completo.
¿Qué tan rápido corre DynoSim?
Implementado completamente en Rust, DynoSim es velozmente rápido. En una MacBook Air con chip Apple M4, el replay offline single-threaded simuló la traza completa Mooncake de 23.608 requests con ocho workers round-robin y bloques de 512 tokens en 2,41 segundos de wall time. La ventana de servicio simulada fue de 60,1 minutos, alrededor de 1.500× más rápido que tiempo real.
Con DynoSim un sweep puede mapear la frontera de Pareto para una carga de trabajo sobre hardware existente, y un workflow estilo autoresearch puede proponer cambios algorítmicos a los componentes: una mejor función de costo del Router, una heurística del Planner o una política de caché.
Arquitectura: componer Dynamo como eventos
Una decisión clave del diseño es la composición. DynoSim no es un modelo monolítico: es un conjunto de componentes de servicio que corren sobre la misma línea temporal simulada. Un harness de replay maneja la llegada de cargas de trabajo, las simulaciones single-engine modelan el scheduling local del worker y el timing del forward-pass, y las simulaciones multi-engine agregan comportamientos del sistema que sólo existen entre workers: routing, caching distribuido y decisiones del Planner.
Replay sobre un reloj virtual
La simulación de eventos discretos (DES) le da a DynoSim un reloj virtual y una cola de eventos. Los componentes no esperan en tiempo real, sino que programan eventos futuros con duraciones modeladas: llegada de request, paso del scheduler, forward-pass, transferencia KV, arranque de worker o acción del Planner. El runtime salta al siguiente timestamp, actualiza el estado del sistema y deja que los componentes afectados programen más trabajo.
El viaje de un request por el gemelo digital
- Un generador de carga (por ejemplo Dynamo AIPerf) emite un request desde una traza o un workload sintético.
- El router decide a dónde va el request, o si debe esperar.
- El scheduler del motor seleccionado lo agrupa en un pase prefill o decode.
- Timing informado por hardware, como el respaldado por AI Configurator (AIC), estima la duración del pase.
- Eventos de handoff KV, caché u offload pueden agendarse en la misma timeline.
- El decode produce tokens de salida visibles.
- El recolector de trazas registra métricas a nivel request y sistema.
Lo importante es que cada decisión de un componente cambia eventos futuros. Una decisión de routing afecta la cola del worker, una decisión de escalado del Planner retrasa la capacidad, y una decisión de movimiento KV puede cambiar cuándo empieza el decode.
Single engine: la fidelidad del scheduler importa
Un motor único no es sólo una estimación de tokens-por-segundo. El scheduler decide qué requests entran en cada pase, cómo se agrupa el trabajo de prefill y decode, y cómo la presión KV cambia el progreso. DynoSim mantiene eso específico por backend: el path vLLM modela un scheduler waiting/running con presupuesto compartido de tokens y preempción/recompute, mientras que el path SGLang modela admisión consciente del radix-cache, presupuestos chunked-prefill y retracción de decode con preservación de prefijos.
AIConfigurator (AIC) cumple el rol de timing en el motor: dado el modelo, el backend, el sistema, la forma de tensor-parallel y la forma del pase, estima cuánto debería demorar el trabajo de prefill o decode.
Multi engine: de workers a sistemas
El poder de Dynamo viene de componentes que toman decisiones online a partir de retroalimentación del sistema en vivo. Un Router necesita el estado actual del caché y la carga de decode. El Planner necesita tráfico, estado de workers y señales de SLA. KVBM necesita presión de transferencia, capacidad por tier y disponibilidad futura del caché.
Para los resultados concretos de Router y KVBM, NVIDIA usa el mismo baseline: la traza Mooncake FAST25 toolagent completa de 23.608 requests, MiniMax-M2.5 FP8 sobre NVIDIA HGX B200, timing vLLM 0.14.0 desde AIC, TP=4 y replay offline.
¿Por qué KVBM importa?
KVBM gestiona bloques KV a lo largo de la jerarquía de memoria del servicio: HBM local, memoria host, SSD y caché distribuido o remoto. El comportamiento de caché en tier bajo a menudo se modela como timing y presión de recursos: G1 (memoria GPU), G2 (memoria host), ancho de banda de transferencia, capacidad por tier y eventualmente G3 (disco). El caché distribuido es donde la simulación se vuelve más interesante: offload, onboard, lectura remota y decisiones de placement afectan routing, scheduling, queueing y estado futuro del caché.
¿Cómo se usa DynoSim para optimización y descubrimiento?
Una vez que DynoSim puede correr una carga a través de componentes compuestos, el replay se vuelve una función de scoring para optimización y descubrimiento: proponer un layout o política, correr la carga, recolectar métricas y comparar resultado contra objetivo.
El optimizador actual usa un descenso por coordenadas crudo pero práctico sobre los knobs de despliegue: elige una forma TP, elige un split de workers para esa forma y elige la configuración de router. Funciona porque el espacio de búsqueda actual es pequeño y localmente suave. A medida que el espacio crezca, el mismo loop de scoring podría conectarse a optimizadores black-box más ricos como búsqueda Bayesiana estilo Hyperopt, algoritmos genéticos o Vizier.
Más interesante aún: el loop no se limita a knobs estructurados. En el estilo del autoresearch de Karpathy, un harness agéntico puede proponer un cambio de código no trivial, reconstruir Dynamo, volver a correr la misma traza y conservar sólo cambios que mejoren el objetivo. Eso convierte al replay en un loop de investigación acotado para funciones de costo del router, heurísticas del Planner y políticas de caché.
Aplicación al Planner: el caso de uso más fuerte
El comportamiento interesante del autoscaling es macro: emerge de minutos de tráfico, arranque demorado de workers, churn de capacidad y retroalimentación entre decisiones de escalado, colas y routing. Evaluarlo en un setup Kubernetes completo es caro por cambio de política, tanto en GPU-hours como en tiempo de ingeniero. DynoSim deja barrer agresivamente esos efectos antes de levantar el entorno completo: comparar setups estáticos vs dinámicos, afinar parámetros del Planner y cuantificar cuánto importa el tiempo de arranque del worker antes de decidir si vale la pena más velocidad de arranque, escalado predictivo o capacidad pre-calentada.
Para equipos chilenos y latinoamericanos que renten GPUs A100/H100 por hora vía proveedores cloud, el ahorro potencial es directo: una semana de barrido de configuración en simulación local cuesta menos que una hora de H100, y el resultado permite llegar al cluster con un set acotado de configuraciones que vale la pena verificar empíricamente.
