Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Núcleo federado

Este documento presenta la capa central de TFF que sirve como base para el aprendizaje federado , y posibles futuros algoritmos federados sin aprendizaje.

Para una introducción suave a Federated Core, lea los siguientes tutoriales, ya que presentan algunos de los conceptos fundamentales a modo de ejemplo y demuestran paso a paso la construcción de un algoritmo de promediado federado simple.

También lo alentamos a que se familiarice con el aprendizaje federado y los tutoriales asociados sobre clasificación de imágenes y generación de texto , ya que los usos de la API de Federated Core (FC API) para el aprendizaje federado proporcionan un contexto importante para algunas de las elecciones que hemos hecho en diseñando esta capa.

Visión general

Objetivos, usos previstos y alcance

Federated Core (FC) se entiende mejor como un entorno de programación para implementar cálculos distribuidos, es decir, cálculos que involucran múltiples computadoras (teléfonos móviles, tabletas, dispositivos integrados, computadoras de escritorio, sensores, servidores de bases de datos, etc.) que cada uno puede realizar procesamiento trivial localmente y comunicación a través de la red para coordinar su trabajo.

El término distribuido es muy genérico, y TFF no apunta a todos los tipos posibles de algoritmos distribuidos, por lo que preferimos usar el término menos genérico de cómputo federado para describir los tipos de algoritmos que se pueden expresar en este marco.

Si bien definir el término cómputo federado de una manera totalmente formal está fuera del alcance de este documento, piense en los tipos de algoritmos que podría ver expresados ​​en pseudocódigo en una publicación de investigación que describe un nuevo algoritmo de aprendizaje distribuido.

El objetivo de FC, en pocas palabras, es permitir una representación igualmente compacta, con un nivel de abstracción similar a un pseudocódigo, de la lógica del programa que no es pseudocódigo, sino que es ejecutable en una variedad de entornos de destino.

La característica clave que define los tipos de algoritmos para los que está diseñado el FC es que las acciones de los participantes del sistema se describen de manera colectiva. Por lo tanto, tendemos a hablar sobre cada dispositivo que transforma los datos localmente, y los dispositivos que coordinan el trabajo de un coordinador centralizado que transmite , recopila o agrega sus resultados.

Si bien TFF se ha diseñado para poder ir más allá de las arquitecturas simples de cliente-servidor , la noción de procesamiento colectivo es fundamental. Esto se debe a los orígenes de TFF en el aprendizaje federado, una tecnología diseñada originalmente para admitir cálculos sobre datos potencialmente confidenciales que permanecen bajo control de los dispositivos del cliente, y que no se pueden descargar simplemente a una ubicación centralizada por razones de privacidad. Si bien cada cliente en dichos sistemas aporta datos y poder de procesamiento para calcular un resultado del sistema (un resultado que generalmente esperaríamos que sea de valor para todos los participantes), también nos esforzamos por preservar la privacidad y el anonimato de cada cliente.

Por lo tanto, si bien la mayoría de los marcos para la computación distribuida están diseñados para expresar el procesamiento desde la perspectiva de los participantes individuales, es decir, a nivel de intercambios de mensajes punto a punto individuales, y la interdependencia de las transiciones de estado local del participante con los mensajes entrantes y salientes , El núcleo federado de TFF está diseñado para describir el comportamiento del sistema desde la perspectiva global de todo el sistema (de manera similar a, por ejemplo, MapReduce ).

En consecuencia, mientras que los marcos distribuidos para fines generales pueden ofrecer operaciones como enviar y recibir como bloques de construcción, FC proporciona bloques de construcción como tff.federated_sum , tff.federated_reduce o tff.federated_broadcast que encapsulan protocolos distribuidos simples.

Idioma

Interfaz de Python

TFF utiliza un lenguaje interno para representar cálculos federados, cuya sintaxis se define mediante la representación serializable en computation.proto . Sin embargo, los usuarios de FC API generalmente no necesitarán interactuar con este idioma directamente. Más bien, se proporciona una API de Python (la tff espacio de nombres) que envuelve Arounds como una manera de definir los cálculos.

Específicamente, TFF proporciona decoradores de funciones de Python como tff.federated_computation que rastrean los cuerpos de las funciones decoradas y producen representaciones serializadas de la lógica de cálculo federada en el lenguaje de TFF. Una función decorada con tff.federated_computation actúa como portadora de dicha representación serializada, y puede incrustarla como un bloque de construcción en el cuerpo de otro cálculo, o ejecutarla bajo demanda cuando se invoca.

Aquí hay solo un ejemplo; Se pueden encontrar más ejemplos en los tutoriales de algoritmos personalizados .

 @tff.federated_computation(tff.FederatedType(tf.float32, tff.CLIENTS))
def get_average_temperature(sensor_readings):
  return tff.federated_mean(sensor_readings)
 

Los lectores familiarizados con TensorFlow no ansioso encontrarán este enfoque análogo a la escritura de código Python que usa funciones como tf.add o tf.reduce_sum en una sección del código Python que define un gráfico TensorFlow. Aunque el código se expresa técnicamente en Python, su propósito es construir una representación serializable de un tf.Graph debajo, y es el gráfico, no el código de Python, el que ejecuta internamente el tiempo de ejecución de TensorFlow. Del mismo modo, uno puede pensar en tff.federated_mean como insertar una tff.federated_mean federada en un cálculo federado representado por get_average_temperature .

Una parte de la razón por la cual FC define un lenguaje tiene que ver con el hecho de que, como se señaló anteriormente, los cálculos federados especifican comportamientos colectivos distribuidos y, como tal, su lógica no es local. Por ejemplo, TFF proporciona operadores, cuyas entradas y salidas pueden existir en diferentes lugares de la red.

Esto requiere un lenguaje y un sistema de tipos que capturen la noción de distribución.

Sistema de tipo

Federated Core ofrece las siguientes categorías de tipos. Al describir estos tipos, señalamos a los constructores de tipos e introducimos una notación compacta, ya que es una forma práctica de describir tipos de cálculos y operadores.

Primero, aquí están las categorías de tipos que son conceptualmente similares a las que se encuentran en los idiomas principales existentes:

  • Tipos de tensor ( tff.TensorType ). Al igual que en TensorFlow, estos tienen dtype y shape . La única diferencia es que los objetos de este tipo no se limitan a tf.Tensor instancias de tf.Tensor en Python que representan salidas de operaciones de TensorFlow en un gráfico de TensorFlow, sino que también pueden incluir unidades de datos que pueden producirse, por ejemplo, como salida de una fuente distribuida protocolo de agregación. Por lo tanto, el tipo de tensor TFF es simplemente una versión abstracta de una representación física concreta de dicho tipo en Python o TensorFlow.

    La notación compacta para los tipos de tensor es dtype o dtype[shape] . Por ejemplo, int32 e int32[10] son los tipos de enteros y vectores int, respectivamente.

  • Tipos de secuencia ( tff.SequenceType ). Estos son equivalentes abstractos de TFF del concepto concreto de TensorFlow de tf.data.Dataset s. Los elementos de las secuencias se pueden consumir de manera secuencial y pueden incluir tipos complejos.

    La representación compacta de los tipos de secuencia es T* , donde T es el tipo de elementos. Por ejemplo, int32* representa una secuencia entera.

  • Tipos de tuplas con nombre ( tff.StructType ). Esta es la forma en que TFF construye tuplas y estructuras tipo diccionario que tienen un número predefinido de elementos con tipos específicos, con o sin nombre. Es importante destacar que el concepto de tupla con nombre de TFF abarca el equivalente abstracto de las tuplas de argumento de Python, es decir, colecciones de elementos de los cuales algunos, pero no todos, se nombran, y algunos son posicionales.

    La notación compacta para tuplas con nombre es <n_1=T_1, ..., n_k=T_k> , donde n_k son nombres de elementos opcionales y T_k son tipos de elementos. Por ejemplo, <int32,int32> es una notación compacta para un par de enteros sin nombre, y <X=float32,Y=float32> es una notación compacta para un par de flotadores llamados X e Y que pueden representar un punto en un plano . Las tuplas se pueden anidar y mezclar con otros tipos, por ejemplo, <X=float32,Y=float32>* sería una notación compacta para una secuencia de puntos.

  • Tipos de funciones ( tff.FunctionType ). TFF es un marco de programación funcional, con funciones tratadas como valores de primera clase . Las funciones tienen como máximo un argumento y exactamente un resultado.

    La notación compacta para funciones es (T -> U) , donde T es el tipo de argumento y U es el tipo de resultado, o ( -> U) si no hay argumento (aunque las funciones sin argumento son degeneradas concepto que existe principalmente en el nivel de Python). Por ejemplo (int32* -> int32) es una notación para un tipo de funciones que reducen una secuencia entera a un solo valor entero.

Los siguientes tipos abordan el aspecto de sistemas distribuidos de los cálculos de TFF. Como estos conceptos son algo exclusivos de TFF, le recomendamos que consulte el tutorial de algoritmos personalizados para obtener comentarios y ejemplos adicionales.

  • Tipo de ubicación Este tipo aún no está expuesto en la API pública, excepto en la forma de 2 literales tff.SERVER y tff.CLIENTS que puede considerar como constantes de este tipo. Sin embargo, se usa internamente y se introducirá en la API pública en futuras versiones. La representación compacta de este tipo es la placement .

    Una ubicación representa un colectivo de participantes del sistema que juegan un papel particular. La versión inicial está dirigida a los cálculos cliente-servidor, en los que hay 2 grupos de participantes: clientes y un servidor (puede pensar en este último como un grupo único). Sin embargo, en arquitecturas más elaboradas, podría haber otras funciones, como agregadores intermedios en un sistema de varios niveles, que podrían estar realizando diferentes tipos de agregación, o utilizar diferentes tipos de compresión / descompresión de datos que los utilizados por el servidor o los clientes.

    El objetivo principal de definir la noción de ubicaciones es la base para definir tipos federados .

  • Tipos federados ( tff.FederatedType ). Un valor de un tipo federado es aquel alojado por un grupo de participantes del sistema definido por una ubicación específica (como tff.SERVER o tff.CLIENTS ). Un tipo federado se define por el valor de ubicación (por lo tanto, es un tipo dependiente ), el tipo de constituyentes miembros (qué tipo de contenido aloja cada uno de los participantes localmente) y el bit adicional all_equal que especifica si todos los participantes son localmente Hospedar el mismo artículo.

    La notación compacta para el tipo de valores federados que incluyen elementos (componentes miembros) de tipo T , cada uno alojado por el grupo (ubicación) G es T@G o {T}@G con el all_equal bits all_equal establecido o no establecido, respectivamente.

    Por ejemplo:

    • {int32}@CLIENTS representa un valor federado que consta de un conjunto de enteros potencialmente distintos, uno por dispositivo cliente. Tenga en cuenta que estamos hablando de un único valor federado que abarca múltiples elementos de datos que aparecen en múltiples ubicaciones en la red. Una forma de pensarlo es como un tipo de tensor con una dimensión de "red", aunque esta analogía no es perfecta porque TFF no permite el acceso aleatorio a los constituyentes miembros de un valor federado.

    • {<X=float32,Y=float32>*}@CLIENTS representa un conjunto de datos federados , un valor que consta de múltiples secuencias de coordenadas XY , una secuencia por dispositivo cliente.

    • <weights=float32[10,5],bias=float32[5]>@SERVER representa una tupla nombrada de peso y tensores de polarización en el servidor. Como hemos eliminado las llaves, esto indica que se ha establecido el bit all_equal , es decir, solo hay una tupla (independientemente de cuántas réplicas de servidor pueda haber en un clúster que aloja este valor).

Bloques de construcción

El lenguaje de Federated Core es una forma de cálculo lambda , con algunos elementos adicionales.

Proporciona las siguientes abstracciones de programación actualmente expuestas en la API pública:

  • Cálculos de TensorFlow ( tff.tf_computation ). Estas son secciones del código TensorFlow envueltas como componentes reutilizables en TFF utilizando el decorador tff.tf_computation . Siempre tienen tipos funcionales y, a diferencia de las funciones en TensorFlow, pueden tomar parámetros estructurados o devolver resultados estructurados de un tipo de secuencia.

    Aquí hay un ejemplo, un cálculo de TF de tipo (int32* -> int) que usa el operador tf.data.Dataset.reduce para calcular una suma de enteros:

 @tff.tf_computation(tff.SequenceType(tf.int32))
def add_up_integers(x):
  return x.reduce(np.int32(0), lambda x, y: x + y)
 
  • Intrínsecos u operadores federados ( tff.federated_... ). Esta es una biblioteca de funciones como tff.federated_sum o tff.federated_broadcast que constituyen la mayor parte de FC API, la mayoría de las cuales representan operadores de comunicación distribuidos para su uso con TFF.

    Nos referimos a estos como intrínsecos porque, de manera similar a las funciones intrínsecas , son un conjunto de operadores extensible y abierto que TFF entiende y compila en código de nivel inferior.

    La mayoría de estos operadores tienen parámetros y resultados de tipos federados, y la mayoría son plantillas que se pueden aplicar a varios tipos de datos.

    Por ejemplo, tff.federated_broadcast puede considerarse como un operador de plantilla de un tipo funcional T@SERVER -> T@CLIENTS .

  • Expresiones lambda ( tff.federated_computation ). Una expresión lambda en TFF es el equivalente de una lambda o def en Python; consiste en el nombre del parámetro y un cuerpo (expresión) que contiene referencias a este parámetro.

    En el código Python, se pueden crear decorando las funciones de Python con tff.federated_computation y definiendo un argumento.

    Aquí hay un ejemplo de una expresión lambda que ya mencionamos anteriormente:

 @tff.federated_computation(tff.FederatedType(tf.float32, tff.CLIENTS))
def get_average_temperature(sensor_readings):
  return tff.federated_mean(sensor_readings)
 
  • Colocación de literales . Por ahora, solo tff.SERVER y tff.CLIENTS para permitir la definición de cálculos simples de cliente-servidor.

  • Invocaciones de funciones ( __call__ ). Cualquier cosa que tenga un tipo funcional se puede invocar utilizando la sintaxis estándar de Python __call__ . La invocación es una expresión, cuyo tipo es el mismo que el tipo del resultado de la función que se invoca.

    Por ejemplo:

    • add_up_integers(x) representa una invocación del cálculo de TensorFlow definido anteriormente en un argumento x . El tipo de esta expresión es int32 .

    • tff.federated_mean(sensor_readings) representa una invocación del operador de promedio federado en sensor_readings . El tipo de esta expresión es float32@SERVER (asumiendo el contexto del ejemplo anterior).

  • Formando tuplas y seleccionando sus elementos. Expresiones de Python de la forma [x, y] , x[y] o xy que aparecen en los cuerpos de funciones decoradas con tff.federated_computation .