NVIDIA FLARE baja el tráfico federado de 28,6 GB a 94 MB

Los modelos de visión y lenguaje modernos pueden resolver tareas como respuesta visual a preguntas, generación de descripciones y razonamiento entre imagen y texto. En la práctica, sin embargo, los datos necesarios para adaptarlos suelen estar repartidos entre instituciones u organizaciones que no pueden centralizar sus registros crudos.

El aprendizaje federado ofrece una forma de coordinar el entrenamiento entre esos sitios sin mover los datos. Para los modelos de visión y lenguaje el desafío no es solo la orquestación: cada sitio puede aportar mezclas distintas de tareas o modalidades, y las actualizaciones del modelo pueden ser lo bastante grandes como para tensionar el ancho de banda de la red y la memoria del servidor.

Este artículo de NVIDIA se concentra en dos decisiones de diseño: qué estado del modelo debe cruzar la red, y cómo transferirlo y combinarlo de manera eficiente.

¿Por qué es difícil federar un modelo de visión y lenguaje?

En un experimento centralizado, las imágenes, las descripciones, los ejemplos de respuesta visual a preguntas y los prompts de generación alimentan un solo flujo de entrenamiento. En un esquema federado, esos ejemplos están distribuidos entre sitios con datos, mezclas de tareas y restricciones operativas distintas.

Eso genera dos problemas de ingeniería. Primero, como los sitios pueden entrenar sobre mezclas distintas, el flujo debe definir qué actualiza cada cliente y cómo se combinan esas actualizaciones. Segundo, las actualizaciones de modelo completo son caras de serializar, de transferir y de sostener en la memoria del servidor.

La primera decisión es entonces qué federar. Algunos enfoques intercambian conocimiento destilado en vez de pesos del modelo. Otros congelan un modelo base preentrenado y combinan únicamente los componentes entrenables livianos. CreamFL ilustra el primer camino, mientras que FedCLIP, FedPIA y FedUMM ilustran el segundo.

NVIDIA FLARE es un SDK y marco de trabajo abierto y extensible en Python para aprendizaje federado y computación colaborativa, y soporta ambos patrones de comunicación, tanto el eficiente en parámetros como el de modelo completo.

Cómo se coordina el entrenamiento entre clientes

Cada trabajo de NVIDIA FLARE separa la coordinación global de la ejecución local. El servidor agenda las rondas y combina las actualizaciones, mientras cada cliente entrena o evalúa contra sus datos locales. El preprocesamiento propio del sitio, la construcción de prompts y el agrupamiento en lotes quedan dentro del cliente.

La Recipe API de NVIDIA FLARE ofrece un punto de partida conciso. La receta FedAvg empareja un modelo con un script de entrenamiento del cliente, y la misma receta puede correr en simulación o en un despliegue real de varios sitios.

Antes de implementar el modelo conviene definir el contrato de actualización del cliente: qué permanece local, qué puede salir del sitio, qué componentes del modelo puede actualizar cada cliente y qué métricas vuelven al servidor. Cuando los clientes actualizan componentes distintos, el contrato debe especificar además cómo se combinan esas actualizaciones a nivel de componente.

Tres mecanismos para mover actualizaciones grandes

El método base habitual para entrenar un modelo de visión y lenguaje federado es ajustar y combinar todos los parámetros, lo que produce actualizaciones enormes. Con muchos clientes en la federación aparecen dos presiones de memoria distintas: serializar y transferir una actualización, y sostener varias en memoria durante la combinación.

• Externalizar objetos grandes. FLARE reemplaza los objetos grandes de un mensaje por referencias livianas y transfiere los datos subyacentes por separado. Así el mensaje de control queda chico y se admiten cargas que exceden el límite ordinario de mensaje serializado. Los descomponedores incorporados cubren tensores de PyTorch, arreglos de NumPy y las estructuras comunes de FLARE.
• Transmitir tensores por partes. Para flujos de PyTorch, el Tensor Downloader transmite los tensores de forma incremental con un protocolo de extracción. Solo se serializa el trozo solicitado a la vez, lo que reduce el peak de memoria durante la distribución del modelo. El tamaño de trozo se puede ajustar para equilibrar la sobrecarga de solicitudes contra la memoria por trozo. Los flujos de TensorFlow usan la ruta de serialización tradicional.
• Descargar la combinación a disco. La transmisión reduce la presión de memoria durante la transferencia, pero el servidor todavía puede necesitar sostener varias actualizaciones al combinarlas, y su peak de memoria crece linealmente con el número de clientes. En NVIDIA FLARE 2.8.0, la descarga de tensores a disco escribe las actualizaciones entrantes de PyTorch FedAvg en archivos temporales safetensors y las carga a demanda, evitando ese crecimiento lineal.

¿Cuánto se ahorra realmente con los adaptadores?

FedUMM, desarrollado en una colaboración entre William & Mary y NVIDIA, es el ejemplo concreto de minimizar lo que cruza la red. Cada cliente simulado mantiene un modelo base BLIP congelado y entrena adaptadores LoRA en local. FLARE coordina las rondas y combina únicamente las actualizaciones de los adaptadores. FedUMM está diseñado con vocación general, con codificadores específicos para visión, audio y texto, aunque sus experimentos actuales se concentran en visión y lenguaje.

Los experimentos reportados evalúan VQA v2 y GenEval bajo heterogeneidad controlada por distribución de Dirichlet, con hasta 16 clientes. En una comparación de ocho clientes, la federación de solo adaptadores redujo la comunicación por cliente de 28,6 GB a 0,094 GB por ronda y mejoró VQA v2 en 0,7 puntos respecto de FedAvg de modelo completo. Con ocho clientes, el rendimiento se mantuvo en torno al 97% de la referencia centralizada en ambas pruebas.

Esa reducción de 304 veces es lo que separa un experimento de laboratorio de algo desplegable fuera de un centro de datos. Mover 28,6 GB por cliente y por ronda supone un enlace dedicado; mover 94 MB cabe en la conexión de una clínica, un laboratorio universitario o una planta industrial sin renegociar el contrato de internet. Para instituciones de la región que trabajan con datos sensibles y no pueden sacarlos de su infraestructura, esa diferencia es la que decide si el proyecto es viable o queda en la presentación.

El propio artículo acota el alcance: la evaluación usa sitios simulados, particiones sintéticas y pruebas públicas de dominio general. No establece rendimiento clínico ni garantías formales de privacidad; solo muestra que los datos crudos de entrenamiento permanecen locales dentro del flujo federado simulado.

FedUMM fue apoyado por el Programa de Becas Académicas de NVIDIA y recibió el premio a artículo estudiantil destacado en el taller FL@FM de TheWebConf 2026.

Lista de verificación para diseñar uno

• Definir el contrato de actualización: qué queda local, qué envía cada cliente y cómo se combinan las actualizaciones.
• Minimizar la carga: intercambiar adaptadores livianos cuando se pueda, y actualizaciones de modelo completo solo cuando la tarea lo exija.
• Elegir cómo se mueven y combinan: externalización y transmisión de tensores para actualizaciones grandes en memoria, más descarga a disco en el servidor cuando combinar varias excedería su memoria.
• Evaluar de punta a punta: medir la calidad del modelo junto con la comunicación, el tiempo de ejecución, el uso de memoria, la heterogeneidad de los datos y las fallas.