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

  • Soporte de tensor disperso en TFF:
    • EW: tenemos modelos de Keras que queremos portar a TFF, tienen tensores escasos
      • El simple mapeo a tensores densos da como resultado un costo de memoria y una lentitud inaceptables en nuestro caso de uso, por lo que buscamos evitar eso.
    • ZG sobre el soporte de tensor disperso existente en TFF
      • Problemas mencionados en GitHub principalmente relacionados con tf.data.Dataset
      • La mayoría de las veces funciona de otra manera, pero requiere algunas agregaciones de bricolaje, particularmente wrt, en las que no podemos hacer ingenuamente una suma escasa en el triple de los tensores constituyentes, que no tendría el resultado deseado.
    • (pregunta sobre la importancia relativa)
    • EW: esto no es un bloqueo para nosotros, sino una buena optimización de la huella de recursos/rendimiento
    • ZG: con respecto a los problemas de GitHub, podría funcionar ocultando el conjunto de datos dentro del cálculo TFF, por lo que no es parte del límite de entrada-salida
    • KO - aclarando que nuestro comentario "principalmente funciona" se refiere a la práctica común de representar/manejar tensores dispersos como tuplas de tensores densos. ¿Ha intentado tratar con escasos como tuplas de tensores densos para el uso de conjuntos de datos también?
      • EW - aún no lo he probado
    • KO: la escasez en esta conversación ha surgido en dos lugares: para los parámetros del modelo, pero también para los datos de entrada escasos, ¿son ambos igualmente importantes?
      • EW: idealmente tendría ambos
    • KO: un elemento de acción para que Ewan intente trabajar con tuplas de tensores densos que representan las partes constituyentes.
    • KO: esto aún deja una pregunta sobre mejores API/ayudantes para el manejo de tensores escasos, pero puede desbloquear este caso de uso particular. ¿Pensamientos sobre la API?
    • EW: idealmente, esto podría ser transparente (no es necesario que el cliente haga nada especial para que el cliente use TFF y simplemente funciona)
      • KO, ZG: en algunos casos, no es obvio, por ejemplo, para la agregación: existe potencialmente más de una forma de agregar las partes constituyentes de los tensores dispersos, una elección que idealmente debe hacer el cliente
      • KR: probablemente tener una pequeña familia de símbolos dedicados de "suma escasa" es lo más procesable
      • KO: tal vez podamos comenzar creando un prototipo de la versión de suma dispersa que necesita EW y enviarla a TFF como un operador genérico de suma dispersa para generar esto y construir sobre eso (para hacer un seguimiento de esto fuera de línea, tal vez en discordia)
      • EW +1
  • La propuesta de Jeremy, continuando desde hace 2 semanas:
    • Nota técnica de TFF: conexiones iniciadas por el cliente
    • (todo para que todos lo revisen más tarde, ya que se compartió poco antes de la reunión)
    • (Jeremy está presentando)
    • JL: propone la abstracción del "almacén de tareas" para intercambiar solicitudes entre una "nube" y los ejecutores por cliente (por ejemplo, en los navegadores), con este último extrayendo tareas de un "almacén de tareas" centralizado. ¿Se ha considerado algo así en algún otro contexto?
    • KR: sí, en escenarios de manejo de fallas
      • Sin embargo, hay problemas más espinosos: la transferencia de estado entre ejecutores es difícil, no estoy seguro de cuánto se transfiere al escenario presentado por Jeremy
    • HV - ¿Pueden los albaceas en las hojas ser apátridas?
      • JL: esto lo haría más parecido al documento de SysML en dispositivos cruzados
    • (pregunta sobre el rendimiento en este escenario, en comparación con la transmisión bidireccional de una manera que se parece más al protocolo TFF nativo)
    • JL: reconoce que hay consideraciones de latencia
    • la transmisión bidireccional no es compatible con algunos transportes, por lo que no siempre es una opción viable
    • (se acabó el tiempo)
    • (continuará en 2 semanas - primer punto de la agenda para la próxima reunión, Jeremy se unirá)