Notas de la reunión de colaboradores de TFF del 11/08/2022

• Tema propuesto para la agenda: Jeremy Lewi presentará sus ideas basadas en TFF para los componentes nuevos que se podrían crear.

• [JL] Enfocarnos en escenarios de análisis federados simples, conectando TFF con las Hojas de cálculo de Google para lograr un promedio federado simple. Trabajar en Kubernetes, leyendo a partir de las hojas de cálculo.

• [JL] [JL] Una dificultad es que, en este momento, se requieren trabajadores con puntos de entrada ingress.

  • No siempre es así, por lo tanto, necesitamos contar con una capa de transporte que habilite que la conectividad se establezca en la dirección opuesta, en el caso de que los trabajadores llamen a un servidor.

  • No hay un componente así en el ecosistema, en este momento.

• [BC] También vimos la necesidad de que esto sea así. Ahora usamos TFF con una nube interna, de manera restringida donde los clientes cargan los datos. Pero necesitaríamos algo como los que JL describió antes para migrar a un entorno de múltiples centros de datos (datacenter).

• [JL] Pienso en una capa que permitiera a los trabajadores extraer (pull) los elementos de trabajo de una cola de un servidor, en caso de que reemplace el tiempo de ejecución actual.

• [KO] No tenemos por qué pensarlo en términos de "reemplazar", podemos conservar la autoría del cálculo y el 98% del tiempo de ejecución igual, y, simplemente, intercambiar el componente nuevo que funciona de la forma en que proponen, en vez de usar del ejecutor remoto como mecanismo del que dependan las solicitudes del ejecutor (de arriba abajo).

• [BC] ¿Necesitará que sea asincrónico o funcionaría dentro del paradigma sincrónico existente?

• [BC] También, parte de las plataformas de salida usan un método de “cola de tareas”, así que suena como una idea consolidada.

• [BC] Si incorporamos límites de tiempo, tal vez también ayudaría a acortar la brecha (para abordar el tema de los trabajadores lentos o los rezagados).

• [KO] Con respecto a la sincronía vs. la asincronía, tenemos abstracciones colectivas en TFF que requieren ser tratadas con la noción de "cohorte". En tal caso, debe haber un momento en que algunos de los clientes que andan por ahí decidan todos juntos unirse en una "cohorte", y el servidor deberá jugar un papel en la orquestación para que esto suceda. Siempre y cuando se produzca esto, la manera en que las solicitudes del ejecutor individual dependan de los clientes podrá variar. Que un ejecutor remoto llame de arriba abajo es una de las formas en que se puede trabajar, pero no es la única; un patrón de comunicaciones basado en elementos de trabajo como el que se propuso arriba también podría encajar, definitivamente, en esta estructura. ¿Les parece material suficiente como para que alguien prepare el borrador de una pequeña propuesta de dos páginas?

• [JL] Me propongo como voluntario para escribir una propuesta de un componente nuevo a partir del que todos iteremos.

• [JL] Por cierto, ¿hay otros repositorios adyacentes con funcionalidades por el estilo?

• [KO] Para que estén al tanto, https://github.com/google/federated-compute (también de Google). Pero se centra, principalmente, en un escenario móvil, no está conectado a TFF en este momento, ni contiene la funcionalidad que están describiendo aquí, así que definitivamente tiene sentido hacer el intento y formular una pequeña propuesta en este grupo.

• [BD] Algunas cuestiones para abordar: los resultados en caché, cuándo agregar.

• [Hao] Tal vez no necesitamos almacenar en caché con este escenario si no es asincrónico.

• [KO] En los escenarios que se ajusta a un patrón MapReduce simple, sí tenemos algo de soporte en TFF, veamos https://www.tensorflow.org/federated/api_docs/python/tff/backends/mapreduce. Esta biblioteca permite traducir los cálculos de TFF a un formato del estilo MapReduce que se podría ejecutar en una plataforma más simple. Sin embargo, hay cierta pérdida en la expresividad y, probablemente, algunas de las ideas sobre las que conversamos antes (para las que se requieren varias rondas de comunicaciones de ida y vuelta entre el servidor y los clientes), no sean expresables en este marco de trabajo. Y el entorno intersilos exclusivamente hace que esos tipos de ideas se vuelvan posibles, ya que se trabaja con grupos de clientes bien provistos (silos) que pueden mantener conexiones de duración prolongada.

• [Hao] [Hao] ¿Qué hay de las operaciones colectivas? ¿Las "allreduce"? ¿Se admiten? ¿Son compatibles?

• [KO] Actualmente, no. "allreduce", en cierto modo, tendría un uso limitado; es que si bien es cierto que se podría aprovechar en un escenario promedio federado simple, esta opción supone que en el servidor no se trabaja entre rondas de procesamiento. No funcionará en casos más generales. Pero, si tenemos ambas mitades (los modos eficientes de emisión (broadcasting) y de agregación) tal vez incluso con la aceleración del hardware, sería algo que podríamos aprovechar en TFF.

• [KO] Parece que JL está listo para comenzar con el borrador de una propuesta para un componente nuevo y que los demás tienen sus opiniones sobre lo que debería contener. Empecemos a colaborar (más de uno, de todos los que estamos en la sala). Para volver a reunirnos en 2 semanas, posiblemente con un borrador para analizar.