Una vez tuve que sacar los respaldos de configuración de seis mil equipos de red. A mano, una vez al mes.
Aguanté un tiempo y después hice lo que haría cualquiera: aprendí lo suficiente de programación para hacerlo en lote. Funcionó. Y ahí descubrí dos cosas sobre mí que resultaron ser permanentes: que programar me desespera, y que aun así tenía perfectamente claro qué quería que hiciera ese programa.
Ya no escribo código y no pienso volver. Pero de esa experiencia me quedó algo que uso todo el tiempo: no hace falta escribir el software para tener una opinión firme sobre en qué software te estás metiendo.
Este artículo es sobre la capa que casi nunca aparece en las propuestas de centros de datos de IA. No es el hardware, no es la red. Es el software que hace correr los entrenamientos. Y es, con diferencia, donde está el candado de proveedor más serio de todos.
🔑 Lo esencial en 20 segundos
- Debajo de tu modelo hay tres capas de software que compras sin darte cuenta: el entorno de programación, la biblioteca que coordina a las GPUs, y el marco de trabajo.
- CUDA es el foso: NVIDIA reporta más de 4 millones de desarrolladores registrados y más de 40.000 organizaciones usándolo.
- NCCL es el candado que casi nadie mira, y solo funciona sobre GPUs NVIDIA. Es de quien depende que miles de GPUs se pongan de acuerdo.
- Los candados son dos, no uno: puedes migrar todo el código de tu modelo a otro fabricante y seguir amarrado en la capa de comunicación.
- En 2026 el foso se está aflojando, pero no por donde la gente cree.
Las tres capas que compras sin cotizarlas
Cuando alguien dice “vamos a entrenar un modelo”, debajo de esa frase hay una pila de software con dueños distintos. Vale la pena verla ordenada, porque cada nivel tiene su propia trampa:
| La capa | Qué hace | De quién depende |
|---|---|---|
| Tu modelo | Lo que tu equipo escribe y considera “el proyecto” | De ti. Es la punta del iceberg |
| El marco de trabajo | PyTorch, JAX y compañía. Donde tu gente pasa el día | Comunidad abierta, en principio portable |
| La biblioteca de colectivos | Coordina a miles de GPUs para que se pongan de acuerdo | NCCL, de NVIDIA. Solo corre sobre sus GPUs |
| El entorno de cómputo | CUDA y sus bibliotecas matemáticas. Veinte años de acumulación | NVIDIA, con cuatro millones de desarrolladores encima |
Mira la tercera fila con cuidado, porque es la que se salta en toda conversación de portabilidad.
CUDA: el foso que todos nombran
Con la cocina de la serie: CUDA es el idioma en el que está escrito todo el recetario. No una receta: el recetario entero, más las notas al margen de veinte años, más la forma en que los cocineros aprendieron a moverse.
NVIDIA reporta más de cuatro millones de desarrolladores registrados en CUDA y más de 40.000 organizaciones usando aplicaciones aceleradas con él. Ese es el foso del que habla todo el mundo, y es real: no es un formato de archivo del que te puedas salir, es una generación de gente que sabe hacer las cosas de una manera.
Cifras de ecosistema reportadas por NVIDIA y análisis del bloqueo por software: CUDA lock-in: el foso de software y los costos reales de cambiar.
Y aquí está el detalle que a mí me parece el más honesto de todo el tema: el candado no es un contrato, son miles de decisiones pequeñas. Ajustes de precisión afinados contra las bibliotecas matemáticas de un fabricante. Caminos de entrenamiento distribuido optimizados suponiendo cómo se comporta NCCL. Tuberías de integración construidas alrededor de herramientas de un solo proveedor.
Nadie firmó eso. Se acumuló. Es deuda técnica con forma de dependencia comercial, y para cuando alguien la nota, ya cuesta una migración.
NCCL: el candado que casi nadie mira
En el artículo de la topología conté que el diseño por rails existe para que la operación colectiva más frecuente entre GPUs se resuelva dentro de una sola hoja de la red, sin subir de nivel.
Esa operación tiene dueño, y se llama NCCL.
NCCL es la biblioteca que implementa las operaciones colectivas: juntar los resultados parciales de todas las GPUs, promediarlos y repartir el resultado. En entrenamiento distribuido eso pasa constantemente, y de ello depende que el clúster funcione como uno o como muchas piezas sueltas.
Tres cosas hay que saber de ella:
- Todo lo demás se apoya en ella. Los marcos y bibliotecas de entrenamiento distribuido más usados —PyTorch en su modo distribuido, Megatron-LM, DeepSpeed— dependen de NCCL para mover datos entre GPUs.
- Es más que una tubería. Junta la comunicación y el cálculo en una sola operación sobre la GPU, en lugar de separarlos, y eso es parte de por qué rinde como rinde.
- Solo corre sobre GPUs NVIDIA.
Papel de NCCL y su dependencia en los marcos de entrenamiento: documentación oficial de NCCL y NVIDIA Collective Communications Library.
AMD tiene su equivalente, RCCL, con un diseño y una interfaz modelados sobre NCCL — hasta el punto de que se describen como casi el mismo código construido para otra marca de GPU. Eso es una buena noticia y una mala al mismo tiempo: demuestra que la pieza es reemplazable, y también que el diseño de referencia sigue siendo el de NVIDIA.
Los candados son dos, y por eso las migraciones decepcionan
Esta es la parte que quiero que se lleve cualquiera que esté evaluando un proyecto de estos, porque es un error de razonamiento que cuesta muy caro.
La conversación de portabilidad casi siempre se plantea así: “si algún día queremos cambiar de fabricante, migramos el código y listo”. Y el bloqueo no vive en una capa, vive en dos a la vez:
| Capa | Qué te ata | Se puede migrar |
|---|---|---|
| Software | Bibliotecas, herramientas, la forma en que tu equipo trabaja | Sí, con esfuerzo. Hay capas de abstracción que ayudan |
| Comunicación | NCCL y el interconector del que depende | Aquí es donde se atoran las migraciones |
Dicho sin rodeos: un equipo puede llevar todo el código de su modelo a la plataforma de otro fabricante y seguir amarrado en el momento en que ejecute entrenamiento distribuido, porque la coordinación entre nodos sigue pasando por la biblioteca del primero.
Es exactamente el patrón que ya conté cuando hablé de RDMA y RoCE, y el que viví respondiendo por la calidad de voz de una fusión bancaria sin poder tocar las políticas que la controlaban: la parte que puedes cambiar no es la parte que te limita.
Qué está cambiando en 2026, con matices
Aquí voy a ser cuidadosa, porque este tema atrae titulares y yo no tengo un clúster de estos para comprobar nada. Lo que sí puedo hacer es distinguir entre lo que se afirma y lo que está demostrado.
Hay tres movimientos reales:
- La plataforma alternativa de AMD ha cerrado distancia en rendimiento con sus versiones recientes. Ya no es una comparación cómoda para nadie.
- Aparecieron capas intermedias en la capa de software que permiten escribir una vez y ejecutar en hardware de varios fabricantes, y están incorporadas dentro de los marcos más usados.
- En enero de 2026 apareció el primer candidato serio para abstraer la capa de comunicación, que es justo el candado que nadie había podido abrir.
Evolución del bloqueo por software y de la capa de comunicación en 2025-2026: SoftwareSeni.
Y ahora el matiz, que es lo que yo diría en una reunión: que exista un candidato no significa que esté probado en producción a escala. El último punto es el interesante y el más joven de los tres. Yo no diseñaría una estrategia de cinco años apostando a que ya funciona; sí exigiría que la arquitectura no impida usarlo cuando madure.
💡 La lección que se repite
El foso no se está muriendo: está cambiando de mecanismo. Y eso es peor de gestionar que una muerte anunciada, porque un candado que se mueve obliga a reevaluar la decisión cada año en lugar de tomarla una vez.
La portabilidad no es ideología: es poder de negociación
Cuando escribí sobre cómo se dispara la factura de observabilidad en la nube llegué a una conclusión que aplica igual aquí, y creo que es lo más útil que tengo que decir en toda la serie:
Poder irte es lo que te da precio, aunque nunca te vayas.
No estoy diciendo que haya que evitar a un fabricante. Estoy diciendo que la conversación de renovación es distinta según si al otro lado de la mesa se sabe que migrar te costaría dieciocho meses o que te costaría tres. Ese número no se decide el día de la renovación: se decide en la arquitectura, años antes, en decisiones que nadie registró como estratégicas.
Y hay una asimetría incómoda que conviene nombrar: quien construye el sistema optimiza por que funcione, no por que sea portable. Es lo correcto desde ingeniería y es lo que después te deja sin margen. Por eso la portabilidad tiene que ser un requisito explícito de alguien, con nombre y apellido, o no existe.
Qué preguntar antes de firmar
| La pregunta | Por qué |
|---|---|
| ¿Qué pasa con el entrenamiento distribuido si cambiamos de fabricante de GPU? | Es la pregunta que separa una respuesta ensayada de una real. Si solo hablan del código del modelo, no han mirado la capa de comunicación |
| ¿Nuestro código depende de comportamientos específicos de un fabricante? | Ajustes de precisión y optimizaciones afinadas a una plataforma son el candado invisible. Se acumulan sin decisión |
| ¿Quién es el dueño de la decisión de portabilidad? | Si no tiene nombre, no existe. Ingeniería optimiza por rendimiento, y hace bien |
| ¿Podemos evaluar la alternativa sin rehacerlo todo? | No para migrar mañana: para tener un número real que llevar a la renovación |
| ¿Qué versiones estamos fijando y quién las actualiza? | Esta pila tiene varias capas con calendarios distintos. Una actualización desalineada rompe entrenamientos que ya funcionaban |
| ¿La arquitectura impide adoptar una capa de abstracción cuando madure? | No hay que apostar a lo nuevo. Hay que no cerrarse la puerta |
Preguntas frecuentes
¿Qué es CUDA y por qué se habla de él como un candado?
Es el entorno con el que se programan las GPUs de NVIDIA, junto con sus bibliotecas matemáticas. Se le llama candado porque alrededor suyo se acumularon veinte años de herramientas, optimizaciones y personas formadas: NVIDIA reporta más de cuatro millones de desarrolladores registrados y más de 40.000 organizaciones usándolo. El costo de cambiar no está en un contrato, sino en miles de decisiones técnicas pequeñas que se tomaron suponiendo esa plataforma.
¿Qué es NCCL y por qué importa tanto?
Es la biblioteca de NVIDIA que coordina las operaciones colectivas entre GPUs: juntar resultados parciales, promediarlos y repartirlos. Los marcos de entrenamiento distribuido más usados dependen de ella para mover datos entre GPUs, y solo funciona sobre GPUs NVIDIA. Es la pieza que hace que miles de GPUs se comporten como una sola.
¿Se puede migrar un clúster de IA a otro fabricante?
El código del modelo, sí, y hay capas de abstracción que ayudan. El problema es la capa de comunicación: un equipo puede migrar todo su código y seguir dependiendo de la biblioteca de colectivos del fabricante original en el momento en que ejecute entrenamiento distribuido. Por eso las migraciones se atoran donde nadie las estaba mirando.
¿Existe una alternativa a NCCL?
AMD tiene RCCL, con un diseño y una interfaz modelados sobre NCCL, hasta el punto de describirse como casi el mismo código construido para otra marca de GPU. Y en enero de 2026 apareció el primer candidato serio para abstraer esa capa entre fabricantes. Que exista no significa que esté probado a gran escala en producción, y conviene tratarlo así.
¿Hay que evitar a NVIDIA para no quedar atrapado?
No es la conclusión. La conclusión es que poder irse es lo que te da precio, aunque nunca te vayas, y que ese margen se decide en la arquitectura años antes de la renovación. La portabilidad tiene que ser un requisito con dueño explícito, porque quien construye el sistema optimiza por que funcione, no por que sea portable.
Lo que me llevo de esto
Me hace gracia terminar aquí, porque este es el artículo de la serie que habla de programación y lo escribe alguien que descubrió, sacando respaldos de seis mil equipos, que programar no es lo suyo.
Y resulta que no hacía falta. Las preguntas que de verdad deciden este proyecto no son de código. Son de quién depende de quién, qué se puede cambiar y qué no, cuánto cuesta salir y quién es el dueño de que salir siga siendo posible. Eso es trabajo de Producto, y se hace leyendo bien y preguntando mejor.
La próxima semana, quién vigila todo esto: el software con el que NVIDIA propone ver la infraestructura completa. Después de tres artículos hablando de piezas que se pueden degradar sin avisar, toca preguntarse con qué se miran. 🔭
Que los sistemas estén con ustedes. ✦
Imagen destacada generada con inteligencia artificial.
Ethel Méndez
Senior Product Manager en observabilidad y redes B2B, con 20 años de campo, NOC y servicios administrados en LATAM. Escribo lo que aprendí operando sistemas de verdad, no en un curso.