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

• Soporte para tensores dispersos en TFF:

  • EW - Tenemos los modelos Keras que queremos portar a TFF. Tienen tensores dispersos.

    • Mapearlos simplemente a tensores densos tiene como resultado un coste de memoria y una lentitud inaceptables para nuestro caso de uso. Por lo tanto, buscamos evitar que esto suceda.

  • ZG sobre soporte existente para tensores dispersos en TFF

    • Muchos de los problemas mencionados en GitHub se relacionan con tf.data.Dataset

    • En general, en otras circunstancias funciona, pero requiere de algún trabajo manual, particularmente con respecto a las agregaciones, en las que no podemos simplemente sumar los dispersos (para triplicar los tensores que las componen). No se obtendría el resultado deseado.

  • (pregunta sobre la importancia relativa)

  • EW - No significa un bloqueo para nosotros, sino una optimización favorable para el impacto de los recursos o el rendimiento.

  • ZG - Con respecto a los problemas de GitHub, podría funcionar ocultar el conjunto de datos dentro del cálculo de TFF, para que no sea parte del límite de entrada/salida.

  • KO - Aclaremos que con el comentario "En general, en otras circunstancias funciona" nos referimos a la práctica común de representar o manipular tensores dispersos como tuplas de tensores densos. ¿Han intentado trabajar con tensores dispersos en tuplas de tensores densos para usar conjuntos de datos también?

    • EW - Todavía no.

  • KO - En esta conversación, los dispersos surgieron en dos oportunidades: para los parámetros del modelo y también para datos de entrada dispersos. ¿Ambos casos tienen la misma importancia?

    • EW - Lo ideal sería que sí.

  • KO - Una acción pendiente sería que Ewan intentara trabajar con tuplas de tensores densos que representen las partes que las componen.

  • KO - Entonces, aún queda sin resolver la cuestión sobre contar con mejores ayudantes o API para la manipulación de tensores dispersos. ¿Pero esto desbloquearía este caso de uso particular? ¿Qué opinan de la API?

  • EW - Lo ideal sería que, simplemente, fuera transparente (sin necesidad de hacer nada especial para los dispersos, sino que el cliente usara TFF y, sencillamente, funcionara).

    • KO, ZG - En algunos casos, no es tan obvio. P. ej. para la agregación. Potencialmente, hay más de una forma de agregar las partes constitutivas de los tensores dispersos, una elección que lo ideal sería que la hiciera el cliente.

    • KR - Probablemente, sería más viable tener una pequeña familia de símbolos de "suma de dispersos" exclusivos.

    • KO - Tal vez, podemos empezar por preparar una versión de prototipo de la suma de dispersos que necesita EW y subirla a TFF como un operador de suma de dispersos genérico para hacer de semilla y construir a partir de esa base (para darle seguimiento fuera de línea, tal vez en Discord).

    • EW +1

• La propuesta de Jeremy. Continúa lo iniciado dos semanas atrás:

  • TFF Tech Note: Client initiated connections (Nota técnica sobre TFF: conexiones iniciadas por el cliente).

  • (tarea pendiente para todos, revisar estas notas más adelante, ya que se compartieron con poco tiempo antes de la reunión)

  • (Jeremy está haciendo la presentación)

  • JL - Propone la abstracción de una "tienda de tareas" para intercambiar solicitudes entre una "nube" y los ejecutores por clientes (p. ej., en los buscadores), los últimos extrayendo tareas de una "tienda de tareas". ¿Se pensó en algo así en algún otro contexto?

  • KR - Sí, para los escenarios de manejo de fallos.

    • Sin embargo, en problemas más complejos, la transferencia de estado entre ejecutores es difícil. No sé bien cuánto arrastraría al escenario presentado por Jeremy.

  • HV - ¿Los ejecutores pueden estar sin estado cuando salen?

    • JL - Lo haría más parecido a la publicación de SysML sobre el funcionamiento entre dispositivos

  • (Pregunta sobre el rendimiento en este escenario, comparado con la transmisión (streaming) bidireccional de una forma que se asemeje más al protocolo TFF nativo).

  • JL - Reconozcamos que hay consideraciones sobre latencia que debemos tener en cuenta.

  • El streaming bidireccional no se admite en algunos transportes, así que no siempre es una opción viable.

  • (Nos quedamos sin tiempo).

  • (Continuaremos dentro de dos semanas. El primer punto de la agenda para la próxima reunión. Jeremy participará).