NVIDIA entrena un modelo propio para repartir sus escasos chips entre sus fábricas

De la oblea al primer token: dos relojes que corren a la vez

NVIDIA mide el rendimiento de su cadena de suministro en dos tramos. El primero, el time-to-rack (tiempo hasta el rack, el armario de servidores montado), va desde que el silicio sale de la fábrica de obleas hasta que un sistema ensamblado llega al suelo de un centro de datos. El segundo, el time-to-token (tiempo hasta el primer token), cubre todo lo que viene después: energía, refrigeración, red y la pila de software que hace productiva esa infraestructura desde el primer día.

La escala explica por qué el primer tramo es tan difícil de comprimir. Las plataformas NVIDIA Grace Blackwell NVL72 se apoyan en millones de piezas y miles de proveedores repartidos por todo el mundo, y el sistema final lo montan decenas de OEM y ODM. Una sola bandeja de cómputo —una de las dieciocho que caben en un rack— necesita dos CPU Grace, cuatro GPU Blackwell y treinta y dos pilas de memoria HBM3e. Y la cadena de suministro creada para Vera Rubin es el doble de grande que la de Grace Blackwell.

Cada uno de esos componentes críticos arrastra su propia lista de materiales, sus proveedores y sus plazos de entrega, y su disponibilidad cambia de una semana a otra: la pieza que frena un montaje esta semana puede sobrar la siguiente. Multiplicado por cada subconjunto del rack, el problema deja de parecerse a una cadena de suministro y empieza a parecerse a un problema de combinatoria.

El reloj que NVIDIA vigila: Time of Ownership

Los fabricantes por contrato no pueden empezar a ensamblar hasta que han llegado todos los componentes, y estos proceden de tres orígenes distintos: piezas que envía NVIDIA, piezas que NVIDIA deja en consignación y piezas de los proveedores. Lo ideal es que lleguen a la vez; cuando no ocurre, lo que llegó pronto espera a lo que llega tarde.

NVIDIA pone en marcha el cronómetro en el momento en que una planta recibe material y lo detiene cuando ese material sale convertido en subconjunto o producto. A esa métrica la llama Time of Ownership (TOO). De ahí nace lo que la compañía denomina el problema de asignación de material crítico: decidir qué material y cuánto va a cada planta, algo que se rehace a mano todas las semanas. La asignación cubre el trimestre en curso y el siguiente, con las semanas más próximas ya comprometidas, así que los datos nuevos de cada semana afectan sobre todo a lo que pasará más adelante.

Un centro de mando sobre Palantir Foundry

El equipo de operaciones de la cadena de suministro de NVIDIA trabajó con Palantir para construir una vista unificada de todo lo que entra en una decisión de asignación. Lo llaman Digital Supply Chain Intelligence, y su función es sacar a la superficie riesgos, bloqueos y otras señales que antes quedaban enterradas en fuentes de datos inconexas.

Por debajo, Palantir Foundry aporta el contexto operativo. Su Ontology conecta materiales, plantas de fabricación, compromisos, capacidad, asignaciones, producción y señales cualitativas no estructuradas en una única capa de datos gobernada. Está compuesta de objetos y enlaces en lugar de filas y tablas, lo que según NVIDIA forma una representación completa de la realidad operativa.

Esa representación permite a los planificadores simular y analizar escenarios distintos, con un acceso mucho más amplio al espacio de decisión.

cuOpt resuelve la parte cuantitativa

El reparto de material entre plantas empieza siendo un problema cuantitativo: cuánto de cada material restringido va a qué planta y cuándo. Alrededor de esa pregunta se acumula todo lo que acota la respuesta: qué fabricantes pueden montar un subconjunto Blackwell determinado, cuánto puede absorber cada planta una vez llega el material y el grafo de dependencias de cada pieza necesaria trazado hacia atrás, de modo que el solver (resolutor, el programa que busca la solución óptima) sepa que una bandeja de cómputo la bloquea su insumo más escaso, no el promedio.

Esa restricción que manda no es fija: se mueve entre GPU, CPU y memoria de una semana a otra, cambia con los tiempos de llegada por las tres rutas de suministro y depende de los compromisos ya adquiridos con clientes, que determinan cuánto cuesta realmente un déficit en una planta concreta. Miles de variables y restricciones acaban resolviéndose en una única asignación semanal.

De eso se encarga NVIDIA cuOpt, una librería de código abierto de optimización acelerada por GPU. Toma sus entradas de la Ontology y escribe el resultado de vuelta como decisión de asignación. El problema se plantea como un mixed-integer linear program (programa lineal entero mixto) cuyo objetivo es minimizar el TOO. cuOpt devuelve algo más que el reparto: informa de qué restricciones son las que limitan, de modo que un planificador puede ver que lo que frenó la cifra de la semana fue la capacidad en Taiwán y no el suministro de memoria. Como resuelve rápido, los planificadores pueden explorar el entorno de la respuesta —qué pasaría con un diez por ciento menos de memoria, o si entrara en servicio una planta nueva— y pasar de pedirle una respuesta al solver a preguntarle por los compromisos entre alternativas.

Donde las matemáticas se quedaban cortas

NVIDIA y Palantir contrastaron decisiones históricas de asignación con lo que después ocurrió de verdad, y el ejercicio reveló un factor humano que cuOpt no estaba capturando. Los planificadores trabajaban con información invisible para el solver: los correos intercambiados con los socios esa semana, un temporal previsto en una región clave o un acontecimiento geopolítico en curso, la transcripción de la última llamada de balance con un proveedor y años de experiencia acumulada.

Con ese diagnóstico, ambas compañías rediseñaron el flujo de trabajo alrededor de los expertos humanos. El sistema registra la decisión de asignación, el razonamiento que hay detrás, el resultado esperado y el resultado real. El conocimiento institucional se convierte así en lógica de decisión explícita y revisable, y como vive en la Ontology, sirve de base para entrenar un modelo de lenguaje con el criterio de los expertos.

Un modelo pequeño entrenado con decisiones reales

NVIDIA post-entrenó un modelo de lenguaje open-weight (de pesos abiertos: los parámetros del modelo se publican y cualquiera puede ajustarlos) para que aplicara ese mismo razonamiento y emitiera una recomendación. Tras evaluar varios modelos Nemotron, eligió Nemotron 3.5 Lightning por estar concebido para la capa de ejecución de un flujo agéntico, dentro de un sistema de modelos en el que las variantes mayores se ocupan de la orquestación y de las tareas generales.

Su arquitectura mixture-of-experts (mezcla de expertos: solo se activa una fracción de la red en cada paso) le da una inferencia muy eficiente. Con 30.000 millones de parámetros y unos 3.000 millones activos por pasada, es ligero pero todavía lo bastante grande para aprender una política concreta. Ese tamaño es lo que hace practicable el bucle de post-entrenamiento, porque los modelos pequeños aprenden antes y exigen mucho menos cómputo para entrenarse y desplegarse.

Al ser abierto, Nemotron puede post-entrenarse dentro del propio perímetro de cómputo de la organización, sin exponer los datos al exterior. El modelo aprende de las señales que usan los planificadores: cuánto material restringido se ofreció a una planta, qué se comprometió a producir el fabricante, qué produjo finalmente y qué evidencia operativa cualitativa había disponible cuando se tomó la decisión. El objetivo es codificar una política de asignación capaz de evaluar el riesgo de producción, recomendar un rango de asignación, identificar los factores que sustentan la recomendación y explicar su razonamiento al equipo.

De la Ontology al modelo especializado

El entrenamiento arranca con el historial operativo guardado en la Ontology de Palantir y pasa por cuatro etapas. NeMo Anonymizer elimina la información personal identificable y ofusca los campos sensibles antes de entrenar. NeMo Data Designer genera datos sintéticos para ampliar y equilibrar los ejemplos, de modo que el modelo vea no solo semanas rutinarias, sino también aumentos de asignación, limitaciones de capacidad y escenarios de disrupción. NeMo AutoModel realiza el ajuste supervisado entrenando un pequeño conjunto de parámetros LoRA mientras los pesos base permanecen congelados, lo que recorta tiempo de entrenamiento, memoria y tamaño de los puntos de control. Por último, un backtest point-in-time (retrospectiva con la información disponible en cada fecha) reproduce las mismas decisiones históricas con el modelo base y con el ajustado, para aislar qué aportó el post-entrenamiento.

Ese mismo registro hace de banco de pruebas. Cada decisión se reproduce solo con lo que era conocible aquel día, se oculta el resultado y se compara la recomendación del modelo con la del planificador y con lo que pasó de verdad. La pregunta que responde la evaluación es directa: si este modelo hubiera estado funcionando el mes pasado, ¿habría acertado la asignación?

Palantir Autopilot gestiona el ciclo de vida de punta a punta: lanza cada trabajo desde los datos de la Ontology, supervisa el modelo Nemotron personalizado ya desplegado y mantiene la trazabilidad desde el dato hasta la versión del modelo y la recomendación. Una vez en producción, el modelo lee el contexto operativo actual y devuelve una recomendación con su justificación y los riesgos asociados. El planificador la revisa y toma la decisión final.

Los números del banco de pruebas

NVIDIA comparó tres modelos sobre la misma tarea y los mismos datos de evaluación: el Nemotron 3.5 Lightning base (BF16), Nemotron 3 Ultra (NVFP4) y su propio Lightning post-entrenado (BF16). En el benchmark de desarrollo, el Lightning post-entrenado alcanzó un 86,7% de acierto en decisiones de asignación. Ultra se quedó en el 55,5% y el Lightning base en el 17,5%: 31,2 puntos porcentuales de ventaja sobre Ultra y 69,2 sobre su propia versión de partida.

También va por delante en las dos métricas que pesan igual todos los tipos de decisión en lugar de todos los ejemplos. La exactitud equilibrada, que promedia la sensibilidad por clase para que las decisiones raras cuenten tanto como las frecuentes, es del 58,6% frente al 42,0% de Ultra. El macro-F1, que promedia el F1 por clase e incorpora la precisión para que un modelo no pueda inflar la sensibilidad prediciendo de más una clase rara, queda en 57,5% frente a 39,5%. Ambas importan porque, con suministro restringido, los planificadores recortan asignaciones mucho más a menudo de lo que las suben, así que la exactitud a secas favorecería a quien se limitara a apostar siempre por la clase mayoritaria.

La propia NVIDIA acota el alcance del resultado: el modelo pequeño no es más capaz en general, sus mejoras se concentran en el dominio en el que fue post-entrenado, y la previsión de riesgo de producción futura siguió resultando difícil pese al ajuste fino. La especialización mejoró la tarea de decisión, pero no resolvió todos los problemas de predicción asociados a ella. Conviene recordar que estas cifras proceden del benchmark interno definido por las propias compañías, no de una evaluación independiente. El entrenamiento LoRA terminó en minutos sobre dos GPU NVIDIA B200, lo bastante ligero como para repetirlo a medida que se acumula retroalimentación.

Una cadena de suministro que aprende

Cada aceptación, edición, rechazo y resultado de producción se escribe de vuelta en la Ontology y se acumula hasta que hay datos representativos suficientes para justificar otra ronda de entrenamiento gobernada. NVIDIA apunta que en el futuro esa retroalimentación se usará para aprendizaje por refuerzo: las recomendaciones aceptadas y las rechazadas formarían pares de preferencia con recompensas por corrección de la asignación, cumplimiento de la política y fundamentación en evidencias. La compañía subraya que el modelo nunca se reentrena solo en producción.

El beneficio, según NVIDIA, se compone por dos vías: los planificadores dedican menos tiempo a reconstruir decisiones rutinarias, con lo que cubren más plantas y productos, y la experiencia de asignación pasa a ser conocimiento institucional, lo que acorta la incorporación de personal nuevo y propaga los aprendizajes por la organización.

El esquema no es exclusivo de los semiconductores. Cualquier operación en la que gente con experiencia reparta capacidad crítica a partir de señales fragmentadas puede montar el mismo bucle, siempre que disponga de tres cosas: una capa operativa gobernada, un registro de decisiones que incluya tanto el razonamiento como el resultado, y un modelo abierto que pueda post-entrenarse dentro de su propio perímetro de cómputo seguro.