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

  • Tema de agenda propuesto: Jeremy Lewi presentará sus ideas basadas en TFF para nuevos componentes que podrían construirse
  • [JL] Centrándose en escenarios de análisis federados simples, conectando TFF con hojas de Google para hacer promedios alimentados simples. Trabajando en Kubernetes, leyendo de hojas.
  • [JL] Un desafío es que actualmente se requiere que los trabajadores tengan puntos de ingreso.
    • A menudo, este no es el caso, por lo que se necesita una capa de transporte que permita establecer la conectividad en la dirección opuesta, los trabajadores llaman a un servidor.
    • Dicho componente no se encuentra actualmente en el ecosistema.
  • [BC] También vio la necesidad de esto. Actualmente usa TFF de manera limitada, en la nube interna donde los clientes cargan datos. Pero, necesitaría algo como JL descrito anteriormente para migrar a una configuración de centro de datos múltiple.
  • [JL] Pensando en una capa que permitiría a los trabajadores "extraer" elementos de trabajo de una cola en un servidor, en caso de que reemplace el tiempo de ejecución existente.
  • [KO] No tiene que pensar en esto en términos de "reemplazo": puede mantener la creación de cómputo y el 98% del tiempo de ejecución igual, y simplemente cambiaría el nuevo componente que funciona de la manera que propone en su lugar. fuera del ejecutor remoto como un mecanismo para retransmitir las solicitudes del ejecutor de arriba hacia abajo.
  • [BC] ¿Necesitaría que fuera asíncrono o funcionaría dentro del paradigma de sincronización existente?
  • [BC] Además, algunas de las plataformas existentes utilizan un enfoque de "cola de tareas", por lo que parece una idea establecida.
  • [BC] La introducción de tiempos de espera quizás también ayudaría a cerrar la brecha (para lidiar con trabajadores lentos o rezagados).
  • [KO] Con respecto a la sincronización frente a la sincronización, tenemos abstracciones colectivas en TFF que requieren la noción de una "cohorte". Como tal, debe haber un momento en que algunos de los clientes decidan unirse a una "cohorte", y el servidor deberá desempeñar un papel en la orquestación de que esto suceda. Mientras se hace eso, la forma en que las solicitudes de los ejecutores individuales se transmiten a los clientes puede variar. El ejecutor remoto que llama de arriba hacia abajo es una forma de hacerlo, pero no la única; un patrón de comunicación basado en elementos de trabajo como el que se propuso anteriormente también podría encajar definitivamente en esta estructura. ¿Parece material para una pequeña propuesta de uno o dos paginadores para que alguien la redacte?
  • [JL] Ofreciéndome como voluntario para escribir una propuesta para un nuevo componente para que todos lo iteremos.
  • [JL] Por cierto, ¿hay otros repositorios adyacentes con funciones relacionadas?
  • [KO] FYI, 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 y no contiene la funcionalidad que está describiendo aquí, por lo que definitivamente tiene sentido tratar de formular una pequeña propuesta en este grupo.
  • [BD] Algunas preguntas para abordar: almacenamiento en caché de resultados, cuándo agregar.
  • [Hao] Tal vez no necesite almacenamiento en caché en este escenario si no es asíncrono
  • [KO] Para escenarios que se ajustan a un patrón de MapReduce simple, tenemos cierto soporte en TFF, consulte https://www.tensorflow.org/federated/api _docs/python/tff/backends/mapreduce. Esta biblioteca le permite traducir cálculos TFF a un formulario similar a MapReduce que podría ejecutar en una plataforma más simple. Sin embargo, hay cierta pérdida de expresividad, y algunas de las ideas discutidas anteriormente que requerían múltiples rondas de comunicación de ida y vuelta entre sevrr y los clientes no serían expresables en este marco. Y, la configuración de silos cruzados hace que ese tipo de ideas sean posibles de manera única, ya que estamos tratando con grupos de clientes bien provistos (silos) que pueden mantener conexiones duraderas.
  • [Hao] ¿Qué pasa con las operaciones colectivas, allreduce? ¿Son compatibles o compatibles?
  • [KO] Actualmente no. Allreduce tendría un uso algo limitado, ya que si bien podría aprovecharse en un único escenario promedio alimentado, asume que no se está realizando ningún trabajo en el servidor entre las rondas de procesamiento. No funcionará en casos más generales. Pero, tener las dos mitades: modo eficiente de transmisión y modo eficiente de agregación, tal vez incluso con aceleración de hardware, sería algo que podemos aprovechar en TFF.
  • [KO] Parece que JL está listo para lanzar un borrador de una propuesta para un nuevo componente, y otros tienen opiniones sobre lo que debería contener: colaboremos (+1 de todos en la sala). Volver a reunirnos en 2 semanas, posiblemente con un borrador para discutir.