Aprendizaje federado entre dispositivos aislados y multidispositivo en Google Cloud

Last reviewed 2024-06-03 UTC

En este documento, se describen dos arquitecturas de referencia que te ayudan a crear una plataforma de aprendizaje federado en Google Cloud a través de Google Kubernetes Engine (GKE). Las arquitecturas de referencia y los recursos asociados que se describen en este documento admiten lo siguiente:

  • Aprendizaje federado entre silos
  • Aprendizaje federado multidispositivo, sobre la base de la arquitectura multiaislamiento

Los públicos objetivos para este documento son arquitectos de la nube y, también, ingenieros de IA y AA que desean implementar casos de uso de aprendizaje federado en Google Cloud. También está dirigido a los encargados de tomar decisiones que evalúan si implementan el aprendizaje federado en Google Cloud.

Arquitectura

En los diagramas de esta sección, se muestra una arquitectura de varios sistemas aislados y una arquitectura multidispositivo para el aprendizaje federado. Para obtener información acerca de las diferentes aplicaciones de estas arquitecturas, consulta Casos de uso.

Arquitectura entre silos

En el siguiente diagrama, se muestra una arquitectura que admite el aprendizaje federado de varios sistemas aislados:

Arquitectura de varios silos, componentes que se describen en el siguiente texto.

En el diagrama anterior, se muestra un ejemplo simple de una arquitectura entre silos. En el diagrama, todos los recursos se encuentran en el mismo proyecto en una organización de Google Cloud. Estos recursos incluyen el modelo de cliente local, el modelo de cliente global y sus cargas de trabajo de aprendizaje federado asociadas.

Esta arquitectura de referencia se puede modificar para admitir varias configuraciones para silos de datos. Los miembros del consorcio pueden alojar sus silos de datos de las siguientes maneras:

  • En Google Cloud, en la misma organización de Google Cloud y en el mismo proyecto de Google Cloud.
  • En Google Cloud, en la misma organización de Google Cloud, en diferentes proyectos de Google Cloud.
  • En Google Cloud, en diferentes organizaciones de Google Cloud.
  • En entornos privados, locales o en otras nubes públicas.

Para que los miembros participantes colaboren, deben establecer canales de comunicación seguros entre sus entornos. Para obtener más información sobre la función de los miembros que participan en el esfuerzo de aprendizaje federado, cómo colaboran y qué comparten entre sí, consulta Casos de uso.

La arquitectura incluye los siguientes componentes:

  • Una red de nube privada virtual (VPC) y una subred.
  • Un clúster de GKE privado que te ayuda a hacer lo siguiente:
    • Aísla los nodos del clúster de Internet.
    • Limita la exposición de los nodos del clúster y el plano de control a Internet mediante la creación de un clúster de GKE privado con redes autorizadas.
    • Usa nodos protegidos del clúster que utilicen una imagen de sistema operativo endurecido.
    • Habilita Dataplane V2 para las herramientas de redes de Kubernetes optimizadas.
  • Grupos de nodos de GKE dedicados: crea un grupo de nodos dedicado para alojar exclusivamente los recursos y las apps de usuarios. Los nodos tienen taints para garantizar que solo las cargas de trabajo de los usuarios estén programadas en los nodos de los usuarios. Otros recursos de clúster se alojan en el grupo de nodos principal.

  • Encriptación de datos (habilitada de forma predeterminada):

  • Encriptación de datos en uso, a través de la habilitación opcional de Confidential Google Kubernetes Engine Nodes.

  • Reglas de firewall de VPC que aplican lo siguiente:

    • Reglas del modelo de referencia que se aplican a todos los nodos del clúster.
    • Reglas adicionales que solo se aplican a los nodos del grupo de nodos de usuario. Estas reglas de firewall limitan la entrada a los nodos de usuario y su salida.

  • Cloud NAT para permitir la salida a Internet.

  • Registros de Cloud DNS para habilitar el Acceso privado a Google, de modo que las aplicaciones dentro del clúster puedan acceder a las APIs de Google sin pasar por Internet

  • Cuentas de servicio, que son las siguientes:

    • Una cuenta de servicio dedicada para los nodos del grupo de nodos de usuario.
    • Una cuenta de servicio dedicada para que las apps de usuarios se usen con la federación de identidades para cargas de trabajo.

  • Compatibilidad con el uso de Grupos de Google para el control de acceso basado en roles (RBAC) de Kubernetes.

  • Un repositorio de Git para almacenar descriptores de configuración.

  • Un repositorio de Artifact Registry para almacenar imágenes de contenedor.

  • El Sincronizador de configuración y Policy Controller para implementar la configuración y las políticas.

  • Puertas de enlace de Cloud Service Mesh para permitir el tráfico de entrada y salida del clúster de forma selectiva.

  • Buckets de Cloud Storage para almacenar pesos de modelos globales y locales.

  • Acceso a otras APIs de Google y Google Cloud. Por ejemplo, es posible que una carga de trabajo de entrenamiento necesite acceder a los datos de entrenamiento almacenados en Cloud Storage, BigQuery o Cloud SQL.

Arquitectura multidispositivo

En el siguiente diagrama, se muestra una arquitectura que admite el aprendizaje federado multidispositivo:

Arquitectura multidispositivo, componentes que se explican en el siguiente texto.

La arquitectura multidispositivo anterior se basa en la arquitectura de varios sistemas aislados con la adición de los siguientes componentes:

  • Un servicio de Cloud Run que simule dispositivos que se conectan al servidor
  • Un Certificate Authority Service que crea certificados privados para que el servidor y los clientes se ejecuten
  • Vertex AI TensorBoard para visualizar el resultado del entrenamiento
  • Un bucket de Cloud Storage para almacenar el modelo consolidado
  • El clúster de GKE privado que usa nodos confidenciales como su grupo principal para ayudar a proteger los datos en uso

La arquitectura multidispositivo usa componentes del proyecto de plataforma federada de Compute (FCP) de código abierto. En este proyecto, se incluye lo siguiente:

  • Código de cliente para comunicarse con un servidor y ejecutar tareas en los dispositivos
  • Un protocolo para la comunicación entre cliente y servidor
  • Puntos de conexión con TensorFlow Federated para facilitar la definición de tus cálculos federados.

Los componentes de FCP que se muestran en el diagrama anterior se pueden implementar como un conjunto de microservicios. Estos componentes hacen lo siguiente:

  • Agregador: este trabajo lee los gradientes del dispositivo y calcula el resultado agregado con privacidad diferencial.
  • Colector: este trabajo se ejecuta de forma periódica para consultar las tareas activas y los gradientes encriptados. Esta información determina cuándo comienza la agregación.
  • Cargador de modelos: este trabajo escucha los eventos y publica los resultados para que los dispositivos puedan descargar modelos actualizados.
  • Asignación de tareas: este servicio de frontend distribuye las tareas de entrenamiento a los dispositivos.
  • Administración de tareas: este trabajo administra tareas.
  • Programador de tareas: Este trabajo se ejecuta de forma periódica o se activa por eventos específicos.

Productos usados

Las arquitecturas de referencia para ambos casos de uso de aprendizaje federado usan los siguientes componentes de Google Cloud:

GKE también proporciona las siguientes capacidades a tu plataforma de aprendizaje federado:

  • Alojar el coordinador de aprendizaje federado: el coordinador de aprendizaje federado es responsable de administrar el proceso de aprendizaje federado. Esta administración incluye tareas como la distribución del modelo global a los participantes, agregar actualizaciones de los participantes y actualizar el modelo global. GKE se puede usar para alojar el coordinador de aprendizaje federado de forma con alta disponibilidad y escalable.
  • Alojar participantes de aprendizaje federado: los participantes de aprendizaje federado son responsables de entrenar el modelo global en sus datos locales. GKE se puede usar para alojar a los participantes de aprendizaje federado de forma segura y aislada. Este enfoque puede ayudar a garantizar que los datos de los participantes se mantengan locales.
  • Proporcionar un canal de comunicación seguro y escalable: los participantes de aprendizaje federado deben poder comunicarse con el coordinador de aprendizaje federado de forma segura y escalable. GKE se puede usar para proporcionar un canal de comunicación seguro y escalable entre los participantes y el coordinador.
  • Administrar el ciclo de vida de las implementaciones de aprendizaje federado: GKE se puede usar para administrar el ciclo de vida de las implementaciones de aprendizaje federado. Esta administración incluye tareas como el aprovisionamiento de recursos, la implementación de la plataforma de aprendizaje federado y la supervisión del rendimiento de la plataforma de aprendizaje federado.

Además de estos beneficios, GKE también proporciona una serie de funciones que pueden ser útiles para las implementaciones de aprendizaje federado, como las siguientes:

  • Clústeres regionales: GKE te permite crear clústeres regionales, lo que te ayuda a mejorar el rendimiento de las implementaciones de aprendizaje federado a través de la reducción de la latencia entre los participantes y el coordinador.
  • Políticas de red: GKE te permite crear políticas de red, lo que ayuda a mejorar la seguridad de las implementaciones de aprendizaje federado a través del control del flujo de tráfico entre los participantes y el coordinador.
  • Balanceo de cargas: GKE proporciona varias opciones de balanceo de cargas, lo que ayuda a mejorar la escalabilidad de las implementaciones de aprendizaje federado a través de la distribución del tráfico entre los participantes y el coordinador.

TFF proporciona las siguientes funciones para facilitar la implementación de casos de uso de aprendizaje federado:

  • La capacidad de expresar de forma declarativa cálculos federados, que son un conjunto de pasos de procesamiento que se ejecutan en un servidor y un conjunto de clientes. Estos cálculos se pueden implementar en diversos entornos de ejecución.
  • Los agregadores personalizados se pueden compilar con código abierto de TFF.
  • Compatibilidad con una variedad de algoritmos de aprendizaje federado, incluidos los siguientes algoritmos:
    • Promedio federado: Un algoritmo que promedia los parámetros del modelo de los clientes participantes. Es especialmente adecuado para casos prácticos en los que los datos son relativamente homogéneos y el modelo no es demasiado complejo. Los casos de uso típicos son los siguientes:
      • Recomendaciones personalizadas: una empresa puede usar un promedio federado para entrenar un modelo que recomiende productos a los usuarios según su historial de compras.
      • Detección de fraudes: un consorcio de bancos puede usar el promedio federado para entrenar un modelo que detecte transacciones fraudulentas.
      • Diagnóstico médico: un grupo de hospitales puede usar un promedio federado para entrenar un modelo que diagnostica el cáncer.
    • Descenso de gradientes estocástico federado (FedSGD): un algoritmo que usa el descenso de gradientes estocástico para actualizar los parámetros del modelo. Es adecuado para los casos de uso en los que los datos son heterogéneos y el modelo es complejo. Los casos de uso típicos son los siguientes:
      • Procesamiento de lenguaje natural: una empresa puede usar FedSGD para entrenar un modelo que mejore la exactitud del reconocimiento de voz.
      • Reconocimiento de imágenes: una empresa puede usar FedSGD para entrenar un modelo que pueda identificar objetos en imágenes.
      • Mantenimiento predictivo: Una empresa puede usar FedSGD para entrenar un modelo que prediga cuándo es probable que una máquina falle.
    • Adam federado: Un algoritmo que usa el optimizador Adam para actualizar los parámetros del modelo. Los casos de uso típicos son los siguientes:
      • Sistemas de recomendador una empresa puede usar Adam federado para entrenar un modelo que recomiende productos a los usuarios en función de su historial de compras.
      • Clasificación: una empresa puede usar Adam federado para entrenar un modelo que clasifique los resultados de la búsqueda.
      • Predicción de la tasa de clics: una empresa puede usar Adam federado para entrenar un modelo que prediga la probabilidad de que un usuario haga clic en un anuncio.

Casos de uso

En esta sección, se describen casos de uso en los que las arquitecturas de varios sistemas aislados y multidispositivo son adecuadas para tu plataforma de aprendizaje federado.

El aprendizaje federado es una configuración de aprendizaje automático en la que muchos clientes entrenan un modelo de forma colaborativa. Un coordinador central lidera este proceso y los datos de entrenamiento permanecen descentralizados.

En el paradigma de aprendizaje federado, los clientes descargan un modelo global y lo mejoran a través del entrenamiento local en sus datos. Luego, cada cliente envía sus actualizaciones de modelos calculados de vuelta al servidor central en el que se agregan las actualizaciones del modelo y se genera una iteración nueva del modelo global. En estas arquitecturas de referencia, las cargas de trabajo de entrenamiento de modelos se ejecutan en GKE.

El aprendizaje federado incorpora el principio de privacidad de la minimización de datos, ya que restringe los datos que se recopilan en cada etapa del procesamiento, limita el acceso a los datos y los procesa para descartarlos lo antes posible. Además, la configuración del problema del aprendizaje federado es compatible con técnicas adicionales de preservación de la privacidad, como el uso de la privacidad diferencial (DP) para mejorar la anonimización del modelo para garantizar que en el modelo final no se memorizan los datos de usuarios individuales.

Según el caso de uso, entrenar modelos con aprendizaje federado puede tener beneficios adicionales:

  • Cumplimiento: En algunos casos, las reglamentaciones pueden limitar la forma en que se pueden usar o compartir los datos. El aprendizaje federado puede usarse para cumplir con estas reglamentaciones.
  • Eficiencia de la comunicación: En algunos casos, es más eficiente entrenar un modelo en datos distribuidos que centralizarlos. Por ejemplo, los conjuntos de datos sobre los que se necesita entrenar el modelo son demasiado grandes para moverse de forma centralizada.
  • Hacer que los datos sean accesibles: El aprendizaje federado permite que las organizaciones mantengan los datos de entrenamiento descentralizados en silos de datos por usuario o por organización.
  • Exactitud del modelo más alta: El entrenamiento con datos del usuario real (a la vez que garantiza la privacidad) en lugar de datos sintéticos (a veces denominados datos proxy), a menudo da como resultado una mayor exactitud del modelo.

Existen diferentes tipos de aprendizaje federado, que se caracterizan por dónde se originan los datos y dónde se producen los cálculos locales. Las arquitecturas de este documento se enfocan en dos tipos de aprendizaje federado: de varios sistemas aislados y multidispositivo. Otros tipos de aprendizaje federado están fuera del alcance de este documento.

El aprendizaje federado se clasifica aún más según la forma en que se particionan los conjuntos de datos, que puede ser de la siguiente manera:

  • Aprendizaje federado horizontal (HFL): Conjuntos de datos con las mismas características (columnas), pero diferentes muestras (filas). Por ejemplo, varios hospitales pueden tener historiales de pacientes con los mismos parámetros médicos, pero poblaciones de pacientes diferentes.
  • Aprendizaje federado vertical (VFL): Conjuntos de datos con las mismas muestras (filas), pero diferentes características (columnas). Por ejemplo, un banco y una empresa de comercio electrónico pueden tener datos de clientes con personas superpuestas, pero con información financiera y de compra diferente.
  • Aprendizaje por transferencia federado (FTL): superposición parcial en las muestras y las funciones entre los conjuntos de datos. Por ejemplo, dos hospitales pueden tener historiales de pacientes con algunas personas superpuestas y algunos parámetros médicos compartidos, pero también funciones únicas en cada conjunto de datos.

El procesamiento federado de varios sistemas aislados es en el que los miembros participantes son organizaciones o empresas. En la práctica, la cantidad de miembros suele ser pequeña (por ejemplo, dentro de cien miembros). El procesamiento de varios sistemas aislados suele usarse en situaciones en las que las organizaciones participantes tienen diferentes conjuntos de datos, pero desean entrenar un modelo compartido o analizar resultados agregados sin compartir sus datos sin procesar entre sí. Por ejemplo, los miembros participantes pueden tener sus entornos en diferentes organizaciones de Google Cloud, como cuando representan diferentes entidades legales o en la misma organización de Google Cloud, como cuando representan diferentes departamentos de la misma entidad legal.

Es posible que los miembros participantes no puedan considerar las cargas de trabajo de los demás como entidades de confianza. Por ejemplo, es posible que un miembro participante no tenga acceso al código fuente de una carga de trabajo de entrenamiento que recibe de un tercero, como el coordinador. Debido a que no puede acceder a este código fuente, el miembro participante no puede asegurarse de que la carga de trabajo sea completamente confiable.

Para evitar que una carga de trabajo no confiable acceda a tus datos o recursos sin autorización, te recomendamos que hagas lo siguiente:

  • Implementa cargas de trabajo que no sean de confianza en un entorno aislado
  • Otorga a las cargas de trabajo no confiables solo los derechos y permisos de acceso estrictamente necesarios para completar las rondas de entrenamiento asignadas a la carga de trabajo.

Para ayudarte a aislar cargas de trabajo que puedan no ser confiables, estas arquitecturas de referencia implementan controles de seguridad, como la configuración de espacios de nombres aislados de Kubernetes, en los que cada espacio de nombres tiene un grupo de nodos dedicado de GKE. La comunicación entre espacios de nombres y el tráfico entrante y saliente de clúster están prohibidos de forma predeterminada, a menos que anules de forma explícita esta configuración.

Estos son algunos casos de uso de ejemplo para el aprendizaje federado de varios sistemas aislados:

  • Detección de fraudes: el aprendizaje federado se puede usar para entrenar un modelo de detección de fraudes en los datos que se distribuyen en varias organizaciones. Por ejemplo, un consorcio de bancos podría usar el aprendizaje federado para entrenar un modelo que detecte transacciones fraudulentas.
  • Diagnóstico médico: El aprendizaje federado se puede usar para entrenar un modelo de diagnóstico médico con datos distribuidos en varios hospitales. Por ejemplo, un grupo de hospitales podría usar el aprendizaje federado para entrenar un modelo que diagnostica el cáncer.

El aprendizaje federado multidispositivo es un tipo de procesamiento federado en el que los miembros participantes son dispositivos de usuario final, como teléfonos celulares, vehículos o dispositivos de IoT. La cantidad de miembros puede alcanzar una escala de millones o incluso decenas de millones.

El proceso de aprendizaje federado multidispositivo es similar al de aprendizaje federado de varios sistemas aislados. Sin embargo, también requiere que adaptes la arquitectura de referencia para que se adapte a algunos de los factores adicionales que debes tener en cuenta cuando trabajas con miles o millones de dispositivos. Debes implementar cargas de trabajo administrativas para manejar las situaciones que se encuentran en los casos de uso de aprendizaje federado multidispositivo. Por ejemplo, la necesidad de coordinar un subconjunto de clientes que se llevará a cabo en la ronda de entrenamiento. La arquitectura multidispositivo proporciona esta capacidad, ya que te permite implementar los servicios de FCP. Estos servicios tienen cargas de trabajo que tienen puntos de conexión con TFF. TFF se usa para escribir el código que administra esta coordinación.

Estos son algunos casos de uso de ejemplo de aprendizaje federado multidispositivo:

  • Recomendaciones personalizadas: puedes usar el aprendizaje federado multidispositivo para entrenar un modelo de recomendación personalizado en los datos que se distribuyen en varios dispositivos. Por ejemplo, una empresa podría usar el aprendizaje federado para entrenar un modelo que recomiende productos a los usuarios en función de su historial de compras.
  • Procesamiento de lenguaje natural: el aprendizaje federado se puede usar para entrenar un modelo de procesamiento de lenguaje natural en datos que se distribuyen en varios dispositivos. Por ejemplo, una empresa podría usar el aprendizaje federado para entrenar un modelo que mejore la exactitud del reconocimiento de voz.
  • Predicción de necesidades de mantenimiento de vehículos: El aprendizaje federado se puede usar para entrenar un modelo que prediga cuándo es probable que un vehículo necesite mantenimiento. Este modelo podría entrenarse con datos recopilados de varios vehículos. Este enfoque permite que el modelo aprenda de las experiencias de todos los vehículos, sin comprometer la privacidad de ningún vehículo individual.

En la siguiente tabla, se resumen las funciones de las arquitecturas de varios sistemas aislados y multidispositivo, y se muestra cómo categorizar el tipo de situación de aprendizaje federado que se aplica a tu caso de uso.

Función Cálculos federados entre sistemas aislados Cálculos federados multidispositivo
Tamaño de la población Por lo general, pequeño (por ejemplo, dentro de cien dispositivos) Escalable a miles, millones o cientos de millones de dispositivos
Miembros participantes Organizaciones o empresas Dispositivos móviles, dispositivos perimetrales y vehículos
Partición de datos más común HFL, VFL y FTL HFL
Sensibilidad de los datos Datos sensibles que los participantes no quieren compartir entre sí en formato sin procesar Datos demasiado sensibles para compartirlos con un servidor central
Disponibilidad de los datos Los participantes casi siempre están disponibles Solo una fracción de los participantes está disponible en cualquier momento
Casos de uso de ejemplo Detección de fraudes, diagnósticos médicos, previsión financiera Seguimiento de actividad física, reconocimiento de voz y clasificación de imágenes

Consideraciones del diseño

En esta sección, se proporciona orientación para ayudarte a usar esta arquitectura de referencia para desarrollar una o más arquitecturas que cumplan con tus requisitos específicos de seguridad, confiabilidad, eficiencia operativa, costo y rendimiento.

Consideraciones de diseño de la arquitectura entre silos

Para implementar una arquitectura de aprendizaje federado de varios sistemas aislados en Google Cloud, debes implementar los siguientes requisitos previos mínimos, que se explican con más detalle en las siguientes secciones:

  1. Establece un consorcio de aprendizaje federado
  2. Determina el modelo de colaboración para que el consorcio de aprendizaje federado implemente.
  3. Determina las responsabilidades de las organizaciones participantes

Además de estos prerrequisitos, hay otras acciones que el propietario de la federación debe realizar y que están fuera del alcance de este documento, como las siguientes:

  • Administra el consorcio de aprendizaje federado.
  • Diseña e implementa un modelo de colaboración.
  • Prepara, administra y opera los datos de entrenamiento del modelo y el modelo que el propietario de la federación desea entrenar.
  • Crea, aloja en contenedores y organiza flujos de trabajo de aprendizaje federado.
  • Implementa y administra cargas de trabajo de aprendizaje federado.
  • Configura los canales de comunicación para que las organizaciones participantes transfieran datos de forma segura.

Establece un consorcio de aprendizaje federado

Un consorcio de aprendizaje federado es el grupo de organizaciones que participan en un esfuerzo de aprendizaje federado de varios sistemas aislados. Las organizaciones del consorcio solo comparten los parámetros de los modelos de AA, y puedes encriptarlos para aumentar la privacidad. Si el consorcio de aprendizaje federado permite la práctica, las organizaciones también pueden agregar datos que no contienen información de identificación personal (PII).

Determina un modelo de colaboración para el consorcio de aprendizaje federado

El consorcio de aprendizaje federado puede implementar diferentes modelos de colaboración, como los siguientes:

  • Un modelo centralizado que consiste en una única organización coordinante, denominada organizador o propietario de federación, y un conjunto de organizaciones participantes o propietarios de datos.
  • Un modelo descentralizado que consta de organizaciones que se coordinan como un grupo.
  • Un modelo heterogéneo que consiste en un consorcio de diversas organizaciones participantes, las cuales aportan diferentes recursos al consorcio.

En este documento, se supone que el modelo de colaboración es un modelo centralizado.

Determina las responsabilidades de las organizaciones participantes

Después de elegir un modelo de colaboración para el aprendizaje federado, el propietario de la federación debe determinar las responsabilidades de las organizaciones participantes.

El propietario de la federación también debe hacer lo siguiente cuando comienza a compilar un consorcio de aprendizaje federado:

  • Coordinar el esfuerzo de aprendizaje federado.
  • Diseñar y, luego, implementar el modelo de AA global y los modelos de AA para compartir con las organizaciones participantes.
  • Definir las iteraciones de aprendizaje federado: El enfoque para la iteración del proceso de entrenamiento del AA.
  • Seleccionar las organizaciones participantes que contribuyen a cualquier ronda de aprendizaje federado determinada. Esta selección se denomina colocación.
  • Diseñar e implementar un procedimiento de verificación de membresía del consorcio para las organizaciones participantes.
  • Actualizar el modelo de AA global y los modelos de AA para compartir con las organizaciones participantes.
  • Proporcionar a las organizaciones participantes las herramientas para validar que el consorcio de aprendizaje federado cumpla con sus requisitos de privacidad, seguridad y reglamentos.
  • Proporcionar a las organizaciones participantes canales de comunicación seguros y encriptados.
  • Proporcionar a las organizaciones participantes todos los datos agregados no confidenciales que necesiten para completar cada ronda de aprendizaje federado.

Las organizaciones participantes tienen las siguientes responsabilidades:

  • Proporcionar y mantener un entorno aislado y seguro (un aislamiento). El almacén es donde las organizaciones participantes almacenan sus propios datos y donde se implementa el entrenamiento de modelos de AA.
  • Entrenar los modelos que proporciona el propietario de la federación mediante su propia infraestructura de procesamiento y sus propios datos locales.
  • Compartir los resultados del entrenamiento de modelos con el propietario de la federación en forma de datos agregados, después de quitar cualquier PII.

El propietario de la federación y las organizaciones participantes definen mejor el entrenamiento de modelos de AA hasta que el modelo cumpla con sus requisitos.

Implementa el aprendizaje federado en Google Cloud

Después de establecer el consorcio de aprendizaje federado y determinar cómo colaborará el consorcio de aprendizaje federado, recomendamos que las organizaciones participantes hagan lo siguiente:

  1. Aprovisiona y configura la infraestructura necesaria para el consorcio de aprendizaje federado.
  2. Implementa el modelo de colaboración.
  3. Comienza el esfuerzo de aprendizaje federado.

Aprovisiona y configura la infraestructura para el consorcio de aprendizaje federado

Cuando aprovisionas y configuras la infraestructura para el consorcio de aprendizaje federado, es responsabilidad del propietario de la federación crear y distribuir las cargas de trabajo que entrenan los modelos de AA federado a las organizaciones participantes. Debido a que un tercero (el propietario de la federación) creó y proporcionó las cargas de trabajo, las organizaciones participantes deben tomar precauciones cuando implementan esas cargas de trabajo en sus entornos de ejecución.

Las organizaciones participantes deben configurar sus entornos según sus prácticas recomendadas de seguridad individuales y aplicar controles que limiten el alcance y los permisos otorgados a cada carga de trabajo. Además de seguir sus prácticas recomendadas de seguridad individuales, recomendamos que el propietario de la federación y las organizaciones participantes consideren vectores de amenazas específicos del aprendizaje federado.

Implementa el modelo de colaboración

Una vez que se prepara la infraestructura del consorcio de aprendizaje federado, el propietario de la federación diseña e implementa los mecanismos que permiten a las organizaciones participantes interactuar entre sí. El enfoque sigue el modelo de colaboración que el propietario de la federación eligió para el consorcio de aprendizaje federado.

Inicia el esfuerzo de aprendizaje federado

Después de implementar el modelo de colaboración, el propietario de la federación implementa el modelo de AA global que se entrenará y los modelos de AA para compartir con la organización participante. Una vez que esos modelos de AA están listos, el propietario de la federación comienza la primera ronda del esfuerzo de aprendizaje federado.

Durante cada ronda del esfuerzo de aprendizaje federado, el propietario de la federación hace lo siguiente:

  1. Distribuye los modelos de AA para compartir con las organizaciones participantes.
  2. Espera a que las organizaciones participantes entreguen los resultados del entrenamiento de los modelos de AA que el propietario de la federación compartió.
  3. Recopila y procesa los resultados del entrenamiento que produjeron las organizaciones participantes.
  4. Actualiza el modelo global del AA cuando reciben los resultados de entrenamiento adecuados de las organizaciones participantes.
  5. Actualiza los modelos de AA para compartirlos con los otros miembros del consorcio cuando corresponda.
  6. Prepara los datos de entrenamiento para la próxima ronda de aprendizaje federado.
  7. Comienza la próxima ronda de aprendizaje federado.

Security, privacy, and compliance

En esta sección, se describen los factores que debes tener en cuenta cuando usas esta arquitectura de referencia para diseñar y compilar una plataforma de aprendizaje federado en Google Cloud. Esta guía se aplica a las dos arquitecturas que se describen en este documento.

Las cargas de trabajo de aprendizaje federado que implementas en tus entornos pueden exponerte a ti, tus datos, tus modelos de aprendizaje federado y tu infraestructura a amenazas que podrían afectar tu empresa.

Para ayudarte a aumentar la seguridad de tus entornos de aprendizaje federado, estas arquitecturas de referencia configuran controles de seguridad de GKE que se enfocan en la infraestructura de tus entornos. Es posible que estos controles no sean suficientes para protegerte de las amenazas específicas para tus cargas de trabajo de aprendizaje federado y casos de uso. Dada la especificidad de cada caso de uso y carga de trabajo de aprendizaje federado, los controles de seguridad destinados a proteger la implementación de aprendizaje federado están fuera del alcance de este documento. Para obtener más información y ejemplos sobre estas amenazas, consulta Consideraciones de seguridad de aprendizaje federado.

Controles de seguridad de GKE

En esta sección, se analizan los controles que aplicas con estas arquitecturas para ayudarte a proteger tu clúster de GKE.

Seguridad mejorada de los clústeres de GKE

Estas arquitecturas de referencia te ayudan a crear un clúster de GKE que implementa la siguiente configuración de seguridad:

Para obtener más información acerca de la configuración de seguridad de GKE, consulta Endurece la seguridad del clúster y Acerca del panel de postura de seguridad.

Reglas de firewall de VPC

Las reglas de firewall de la nube privada virtual (VPC) determinan qué tráfico se permite a o desde las VMs de Compute Engine. Las reglas te permiten filtrar el tráfico con el nivel de detalle de la VM, según los atributos de la capa 4.

Debes crear un clúster de GKE con las reglas de firewall de clúster de GKE predeterminadas. Estas reglas de firewall permiten la comunicación entre los nodos del clúster y el plano de control de GKE, y entre los nodos y los Pods en el clúster.

Aplicas reglas de firewall adicionales a los nodos en el grupo de nodos de usuario. Estas reglas de firewall restringen el tráfico de salida de los nodos de usuario. Este enfoque puede aumentar el aislamiento de los nodos de usuario. De forma predeterminada, se rechaza todo el tráfico de salida de los nodos de usuario. Cualquier salida necesaria debe configurarse de forma explícita. Por ejemplo, puedes crear reglas de firewall para permitir la salida desde los nodos de usuario al plano de control de GKE y a las APIs de Google mediante el Acceso privado a Google. Las reglas de firewall se orientan a los nodos de usuario a través de la cuenta de servicio para el grupo de nodos de usuario.

Espacios de nombres

Los espacios de nombres te permiten proporcionar un permiso para los recursos relacionados dentro de un clúster, por ejemplo, pods, servicios y controladores de replicación. Si usas espacios de nombres, puedes delegar la responsabilidad de administración de los recursos relacionados como una unidad. Por lo tanto, los espacios de nombres son una parte integral de la mayoría de los patrones de seguridad.

Los espacios de nombres son una función importante para el aislamiento del plano de control. Sin embargo, no proporcionan aislamiento de los nodos, del plano de datos ni de la red.

Un enfoque común es crear espacios de nombres para aplicaciones individuales. Por ejemplo, puedes crear el espacio de nombres myapp-frontend para el componente de IU de una aplicación.

Estas arquitecturas de referencia te ayudan a crear un espacio de nombres dedicado para alojar las apps de terceros. El espacio de nombres y sus recursos se tratan como un usuario dentro de tu clúster. Aplicas políticas y controles al espacio de nombres para limitar el alcance de los recursos en el espacio de nombres.

Políticas de red

Las políticas de red aplican los flujos de tráfico de red de capa 4 mediante el uso de reglas de firewall a nivel del pod. Las políticas de red tienen permisos en un espacio de nombres.

En las arquitecturas de referencia que se describen en este documento, aplicas políticas de red al espacio de nombres del usuario que aloja las apps de terceros. De forma predeterminada, la política de red rechaza todo el tráfico hacia y desde los Pods en el espacio de nombres. Cualquier tráfico necesario debe agregarse de forma explícita a una lista de entidades permitidas. Por ejemplo, las políticas de red en estas arquitecturas de referencia permiten de forma explícita el tráfico a los servicios obligatorios del clúster, como el DNS interno del clúster y el plano de control de Cloud Service Mesh.

Sincronizador de configuración

El Sincronizador de configuración mantiene los clústeres de GKE sincronizados con los parámetros de configuración almacenados en un repositorio de Git. El repositorio de Git actúa como la única fuente de información para la configuración y las políticas de tu clúster. El Sincronizador de configuración es declarativo. Comprueba el estado del clúster de forma continua y aplica el estado declarado en el archivo de configuración para aplicar políticas, lo que ayuda a evitar el desvío de configuración.

Instalas el Sincronizador de configuración en tu clúster de GKE. Puedes configurar el Sincronizador de configuración para sincronizar las políticas y la configuración del clúster desde un Cloud Source Repository. Los recursos sincronizados incluyen los siguientes:

  • Configuración de Cloud Service Mesh a nivel de clúster
  • Políticas de seguridad a nivel del clúster
  • Configuración y política a nivel del espacio de nombres del usuario, incluidas las políticas de red, las cuentas de servicio, las reglas de RBAC y la configuración de Cloud Service Mesh

Policy Controller

Policy Controller de la edición Enterprise de Google Kubernetes Engine (GKE) es un controlador de admisión dinámico para Kubernetes que aplica políticas CustomResourceDefinition (basadas en CRD) que ejecuta Open Policy Agent (OPA).

Los controladores de admisión son complementos de Kubernetes que interceptan solicitudes al servidor de la API de Kubernetes antes de que se conserve un objeto, pero después de que se autentica y autoriza la solicitud. Puedes usar controladores de admisión para limitar el uso de un clúster.

Instala Policy Controller en tu clúster de GKE. Estas arquitecturas de referencia incluyen políticas de ejemplo para ayudar a proteger un clúster. Aplicas de forma automática las políticas a tu clúster mediante el Sincronizador de configuración. Debes aplicar las siguientes políticas:

Cloud Service Mesh

Cloud Service Mesh es una malla de servicios que te ayuda a simplificar la administración de comunicaciones seguras entre servicios. En estas arquitecturas de referencia, se configura Cloud Service Mesh para que haga lo siguiente:

  • Inserta proxies de sidecar automáticamente.
  • Aplica la comunicación mTLS entre los servicios en la malla.
  • Limita el tráfico saliente de la malla solo a los hosts conocidos.
  • Limita el tráfico entrante solo de ciertos clientes.
  • Te permite configurar políticas de seguridad de redes según la identidad del servicio en lugar de la dirección IP de los pares en la red.
  • Limita la comunicación autorizada entre los servicios de la malla. Por ejemplo, las aplicaciones en el espacio de nombres del usuario solo pueden comunicarse con aplicaciones en el mismo espacio de nombres o con un conjunto de hosts externos conocidos.
  • Se enruta todo el tráfico entrante y saliente a través de puertas de enlace de malla en las que puedes aplicar más controles de tráfico.
  • Admite la comunicación segura entre clústeres.

Taints y afinidades de nodos

Los taints de nodo y la afinidad de nodos son mecanismos de Kubernetes que te permiten influir en la forma en que se programan los pods en los nodos del clúster.

Los nodos con taint repelen Pods. Kubernetes no programará un Pod en un nodo con taint, a menos que el Pod tenga una tolerancia al taint. Puedes usar los taints de nodos para reservar nodos a fin de que los usen solo ciertas cargas de trabajo o usuarios. Los taints y las tolerancias suelen usarse en clústeres de multiusuarios. Para obtener más información, consulta la documentación sobre nodos dedicados con taints y tolerancias.

La afinidad de nodos te permite restringir los Pods a nodos con etiquetas específicas. Si un Pod tiene un requisito de afinidad de nodos, Kubernetes no programa el Pod en un nodo, a menos que el nodo tenga una etiqueta que coincida con él. Puedes usar la afinidad de nodos para asegurarte de que los Pods se programen en nodos adecuados.

Puedes usar los taints de nodo y la afinidad de nodo a fin de garantizar que los Pods de carga de trabajo de los usuarios se programen exclusivamente en los nodos reservados para el usuario.

Estas arquitecturas de referencia te ayudan a controlar la programación de las aplicaciones de usuario de las siguientes maneras:

  • Crear un grupo de nodos de GKE dedicado al usuario. Cada nodo del grupo tiene un taint relacionado con el nombre del usuario.
  • Aplicar de forma automática la tolerancia adecuada y la afinidad de nodos a cualquier Pod que se oriente al espacio de nombres del usuario. Aplicas la tolerancia y la afinidad mediante mutaciones de PolicyController.

Privilegio mínimo

Es una práctica recomendada de seguridad adoptar un principio de privilegio mínimo para tus proyectos y recursos de Google Cloud, como los clústeres de GKE. Con este enfoque, las apps que se ejecutan dentro del clúster y, los desarrolladores y operadores que usan el clúster, solo tienen el conjunto mínimo de permisos necesarios.

Estas arquitecturas de referencia te ayudan a usar las cuentas de servicio con privilegios mínimos de las siguientes maneras:

  • Cada grupo de nodos de GKE recibe su propia cuenta de servicio. Por ejemplo, los nodos del grupo de nodos de usuario usan una cuenta de servicio dedicada a esos nodos. Las cuentas de servicio de nodo se configuran con los permisos mínimos necesarios.
  • El clúster usa Workload Identity para asociar las cuentas de servicio de Kubernetes a las cuentas de servicio de Google. De esta manera, las apps de usuario pueden tener acceso limitado a cualquier API de Google requerida sin descargar y almacenar una clave de cuenta de servicio. Por ejemplo, puedes otorgar a la cuenta de servicio permisos para leer datos de un bucket de Cloud Storage.

Estas arquitecturas de referencia te ayudan a restringir el acceso a los recursos del clúster de las siguientes maneras:

  • Debes crear un rol de muestra de RBAC de Kubernetes con permisos limitados para administrar aplicaciones. Puedes otorgar este rol a los usuarios y grupos que operan las aplicaciones en el espacio de nombres del usuario. Si se aplica este rol limitada de usuarios y grupos, esos usuarios solo tienen permisos para modificar los recursos de la aplicación en el espacio de nombres del usuario. No tienen permisos para modificar los recursos a nivel de clúster ni la configuración de seguridad sensible, como las políticas de Cloud Service Mesh.

Autorización binaria

Autorización Binaria te permite aplicar políticas que definas sobre las imágenes de contenedor que se implementan en tu entorno de GKE. La autorización binaria solo permite que se implementen imágenes de contenedor que se ajusten a las políticas definidas. No permite la implementación de ninguna otra imagen de contenedor.

En esta arquitectura de referencia, Autorización Binaria está habilitada con su configuración predeterminada. Para inspeccionar la configuración predeterminada de Autorización Binaria, consulta Exporta el archivo de políticas en formato YAML.

Para obtener más información sobre cómo configurar las políticas, consulta la siguiente guía específica:

Verificación de certificación entre organizaciones

Puedes usar Autorización Binaria para verificar las certificaciones que genera un firmante externo. Por ejemplo, en un caso de uso de aprendizaje federado entre entornos aislados, puedes verificar las certificaciones que creó otra organización participante.

Para verificar las certificaciones que creó un tercero, haz lo siguiente:

  1. Recibe las claves públicas que el tercero usó para crear las certificaciones que necesitas verificar.
  2. Crear los certificadores para verificar las certificaciones.
  3. Agrega las claves públicas que recibiste de terceros a los certificadores que creaste.

Para obtener más información sobre cómo crear certificadores, consulta la siguiente guía específica:

Panel de cumplimiento de GKE

El panel de cumplimiento de GKE proporciona estadísticas prácticas para fortalecer tu posición de seguridad y te ayuda a automatizar los informes de cumplimiento para estándares y comparativas de la industria. Puedes inscribir tus clústeres de GKE para habilitar los informes de cumplimiento automáticos.

Para obtener más información, consulta Acerca del panel de GKE Compliance.

Consideraciones de seguridad del aprendizaje federado

A pesar de su estricto modelo de uso compartido de datos, el aprendizaje federado no es inherentemente seguro contra todos los ataques dirigidos, y debes tener en cuenta estos riesgos cuando implementes cualquiera de las arquitecturas descritas en este documento. También existe el riesgo de filtraciones de información no deseadas sobre los modelos del AA o los datos de entrenamiento de modelos. Por ejemplo, un atacante podría comprometer de forma intencional el modelo de AA global o las rondas del esfuerzo de aprendizaje federado, o podría ejecutar un ataque de tiempo (un tipo de ataque de canal lateral) para recopilar información sobre el tamaño de los conjuntos de datos de entrenamiento.

Las amenazas más comunes contra una implementación de aprendizaje federado son las siguientes:

  • Memorización intencional o involuntaria de datos de entrenamiento. Tu implementación de aprendizaje federado o un atacante pueden almacenar datos de manera intencional o involuntaria de maneras que podrían ser difíciles de usar. Un atacante podría recopilar información sobre el modelo de AA global o las rondas anteriores del esfuerzo de aprendizaje federado mediante la ingeniería inversa de los datos almacenados.
  • Extracción de información de actualizaciones al modelo global de AA. Durante el esfuerzo de aprendizaje federado, un atacante podría aplicar ingeniería inversa a las actualizaciones del modelo de AA global que el propietario de la federación recopila de las organizaciones y los dispositivos participantes.
  • El propietario de la federación podría comprometer rondas. Un propietario de una federación vulnerada puede controlar un almacén o dispositivo aislado y comenzar una ronda del esfuerzo de aprendizaje federado. Al final de la ronda, el propietario de la federación vulnerada podría recopilar información sobre las actualizaciones que recopila de los dispositivos y organizaciones participantes legítimos mediante la comparación de esas actualizaciones con la que produjo el almacén aislado.
  • Las organizaciones y los dispositivos participantes pueden comprometer el modelo de AA global. Durante el esfuerzo de aprendizaje federado, un atacante podría intentar afectar de forma maliciosa el rendimiento, la calidad o la integridad del modelo de AA global a través de la producción de actualizaciones sospechosas o irrelevantes.

Para ayudar a mitigar el impacto de las amenazas descritas en esta sección, recomendamos las siguientes prácticas recomendadas:

  • Ajustar el modelo para reducir al mínimo la memorización de los datos de entrenamiento.
  • Implementar mecanismos de preservación de la privacidad.
  • Auditar con regularidad el modelo de AA global, los modelos de AA que deseas compartir, los datos de entrenamiento y la infraestructura que implementaste para lograr tus objetivos de aprendizaje federado.
  • Implementar un algoritmo de agregación segura para procesar los resultados del entrenamiento que producen las organizaciones participantes.
  • Generar y distribuir de forma segura claves de encriptación de datos mediante una infraestructura de clave pública.
  • Implementar la infraestructura en una plataforma de computación confidencial.

Los propietarios de la federación también deben seguir los siguientes pasos adicionales:

  • Verificar la identidad de cada organización participante y la integridad de cada silo en el caso de arquitecturas de varios sistemas aislados, así como la identidad y la integridad de cada dispositivo en el caso de las arquitecturas multidispositivo.
  • Limitar el alcance de las actualizaciones al modelo de AA global que pueden producir las organizaciones y los dispositivos participantes.

Confiabilidad

En esta sección, se describen los factores de diseño que debes tener en cuenta cuando usas cualquiera de las arquitecturas de referencia de este documento para diseñar y compilar una plataforma de aprendizaje federado en Google Cloud.

Cuando diseñes tu arquitectura de aprendizaje federado en Google Cloud, te recomendamos que sigas las instrucciones de esta sección para mejorar la disponibilidad y escalabilidad de la carga de trabajo, y ayudar a que la arquitectura sea resistente a las interrupciones y los desastres.

GKE: GKE admite varios tipos de clústeres diferentes que puedes adaptar a los requisitos de disponibilidad de tus cargas de trabajo y a tu presupuesto. Por ejemplo, puedes crear clústeres regionales que distribuyan el plano de control y los nodos en varias zonas dentro de una región, o clústeres zonales que tengan el plano de control y los nodos en una sola zona. Las arquitecturas de referencia de varios sistemas aislados y multidispositivo dependen de los clústeres de GKE regionales. Para obtener más información sobre los aspectos que se deben tener en cuenta cuando se crean clústeres de GKE, consulta Opciones de configuración del clúster.

Según el tipo de clúster y la forma en que el plano de control y los nodos del clúster se distribuyen entre regiones y zonas, GKE ofrece diferentes capacidades de recuperación ante desastres para proteger tus cargas de trabajo contra interrupciones zonales y regionales. Si deseas obtener más información sobre las funciones de recuperación ante desastres de GKE, consulta Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube: Google Kubernetes Engine.

Google Cloud Load Balancing: GKE admite varias formas de tráfico de balanceo de cargas a las cargas de trabajo. Las implementaciones de GKE de las APIs de puerta de enlace de Kubernetes y servicio de Kubernetes te permiten aprovisionar y configurar automáticamente Cloud Load Balancing para exponer de forma segura y confiable las cargas de trabajo que se ejecutan en tus clústeres de GKE.

En estas arquitecturas de referencia, todo el tráfico de entrada y salida pasa por las puertas de enlace de Cloud Service Mesh. Estas puertas de enlace significan que puedes controlar con precisión cómo fluye el tráfico dentro y fuera de los clústeres de GKE.

Desafíos de confiabilidad para el aprendizaje federado multidispositivo

El aprendizaje federado multidispositivo tiene varios desafíos de confiabilidad que no se encuentran en situaciones de varios sistemas aislados. Se incluyen las siguientes:

  • Conectividad del dispositivo poco confiable o intermitente
  • Almacenamiento limitado en el dispositivo
  • Procesamiento y memoria limitados

Una conectividad poco confiable puede generar problemas como los siguientes:

  • Actualizaciones inactivas y divergencia de modelos: cuando los dispositivos experimentan una conectividad intermitente, las actualizaciones de su modelo local pueden volverse inactivas, lo que representa información desactualizada en comparación con el estado actual del modelo global. Agregar actualizaciones inactivas puede llevar a una divergencia del modelo, en la que el modelo global se desvía de la solución óptima debido a inconsistencias en el proceso de entrenamiento.
  • Contribuciones desequilibradas y modelos sesgados: la comunicación intermitente puede dar como resultado una distribución desigual de contribuciones de los dispositivos participantes. Los dispositivos con conectividad deficiente pueden contribuir con menos actualizaciones, lo que genera una representación desequilibrada de la distribución de datos subyacente. Este desequilibrio puede sesgar el modelo global hacia los datos de dispositivos con conexiones más confiables.
  • Aumento de la sobrecarga de comunicación y del consumo de energía: la comunicación intermitente puede aumentar la sobrecarga de comunicación, ya que los dispositivos podrían necesitar reenviar actualizaciones perdidas o dañadas. Este problema también puede aumentar el consumo de energía en los dispositivos, en especial, aquellos con una duración de batería limitada, ya que es posible que necesiten mantener conexiones activas durante períodos más largos para garantizar una transmisión exitosa de actualizaciones.

Para ayudar a mitigar algunos de los efectos que causa la comunicación intermitente, las arquitecturas de referencia de este documento se pueden usar con FCP.

Una arquitectura del sistema que ejecuta el protocolo FCP puede diseñarse para cumplir con los siguientes requisitos:

  • Manejar rondas de larga duración.
  • Habilitar la ejecución especulativa (las rondas pueden comenzar antes de que se ensamble la cantidad necesaria de clientes en previsión de más verificaciones a tiempo).
  • Habilitar los dispositivos para elegir en qué tareas quieren participar. Este enfoque puede habilitar funciones como el muestreo sin reemplazo, que es una estrategia de muestreo en la que cada unidad de muestra de una población tiene solo una oportunidad de seleccionarse. Este enfoque ayuda a mitigar las contribuciones desequilibradas y modelos sesgados.
  • Es extensible para técnicas de anonimización, como la privacidad diferencial (DP) y la agregación de confianza (TAG).

Para mitigar las capacidades limitadas de procesamiento y almacenamiento del dispositivo, las siguientes técnicas pueden ayudar:

  • Comprender cuál es la capacidad máxima disponible para ejecutar el procesamiento de aprendizaje federado
  • Comprender cuántos datos se pueden conservar en un momento determinado
  • Diseñar el código de aprendizaje federado del cliente para operar dentro del procesamiento y la RAM disponibles en los clientes
  • Comprender las implicaciones de quedarse sin almacenamiento y, luego, implementa un proceso para administrarlo

Optimización de costos

En esta sección, se proporciona orientación para optimizar el costo de crear y ejecutar la plataforma de aprendizaje federado en Google Cloud que estableces a través de esta arquitectura de referencia. Esta guía se aplica para ambas arquitecturas que se describen en este documento.

Ejecutar cargas de trabajo en GKE puede ayudarte a que tu entorno esté más optimizado para los costos a través del aprovisionamiento y la configuración de tus clústeres según los requisitos de recursos de tus cargas de trabajo. También habilita funciones que vuelven a configurar de forma dinámica los clústeres y los nodos de los clústeres, como el ajuste de escala automático de los nodos y los Pods del clúster, y a través del redimensionamiento de los clústeres.

Si deseas obtener más información acerca de la optimización del costo de los entornos de GKE, consulta Prácticas recomendadas para ejecutar aplicaciones de Kubernetes con optimización de costos en GKE.

Eficiencia operativa

En esta sección, se describen los factores que debes tener en cuenta para optimizar la eficiencia cuando usas esta arquitectura de referencia a fin de crear y ejecutar una plataforma de aprendizaje federado en Google Cloud. Esta guía se aplica para ambas arquitecturas que se describen en este documento.

Para aumentar la automatización y la supervisión de tu arquitectura de aprendizaje federado, te recomendamos que adoptes principios de MLOps, que son principios de DevOps en el contexto de sistemas de aprendizaje automático. La práctica de MLOps implica abogar por la automatización y la supervisión en todos los pasos de la construcción del sistema de AA, incluida la integración, las pruebas, el lanzamiento, la implementación y la administración de la infraestructura. Para obtener más información sobre las MLOps, consulta MLOps: canalizaciones de automatización y entrega continua en el aprendizaje automático.

Optimización del rendimiento

En esta sección, se describen los factores que debes tener en cuenta para optimizar el rendimiento de las cargas de trabajo cuando usas esta arquitectura de referencia a fin de crear y ejecutar una plataforma de aprendizaje federado en Google Cloud. Esta guía se aplica para ambas arquitecturas que se describen en este documento.

GKE admite varias funciones para redimensionar y escalar de forma automática y manual tu entorno de GKE para satisfacer las demandas de tus cargas de trabajo y ayudarte a evitar el aprovisionamiento excesivo de recursos. Por ejemplo, puedes usar el recomendador para generar estadísticas y recomendaciones para optimizar el uso de los recursos de GKE.

Cuando pienses en cómo escalar tu entorno de GKE, te recomendamos que diseñes planes a corto, medio y largo plazo sobre cómo pretendes escalar tus entornos y cargas de trabajo. Por ejemplo, ¿cómo planeas aumentar tu huella de GKE en unas semanas, meses y años? Tener un plan listo te ayuda a aprovechar al máximo las funciones de escalabilidad que proporciona GKE, optimizar los entornos de GKE y reducir los costos. Para obtener más información acerca de la planificación de la escalabilidad de clúster y carga de trabajo, consulta Acerca de la escalabilidad de GKE.

Para aumentar el rendimiento de tus cargas de trabajo de AA, puedes adoptar Cloud Tensor Processing Unit (Cloud TPU), aceleradores de IA diseñados por Google que están optimizados para el entrenamiento y la inferencia de modelos de IA grandes.

Implementación

Para implementar las arquitecturas de referencia de varios sistemas aislados y multidispositivo que se describen en este documento, consulta el repositorio de GitHub sobre aprendizaje federado en Google Cloud.

¿Qué sigue?

Colaboradores

Autores:

Otros colaboradores: