Esta página foi traduzida pela API Cloud Translation.
Switch to English

Módulo: tf.distribute

TensorFlow 1 versão

Biblioteca para a execução de um cálculo em vários dispositivos.

A intenção desta biblioteca é que você pode escrever um algoritmo de uma forma estilizada e será utilizável com uma variedade de diferentes tf.distribute.Strategy implementações. Cada descendente irá implementar uma estratégia diferente para distribuir o algoritmo em vários dispositivos / máquinas. Além disso, essas mudanças podem ser escondidos dentro das camadas específicas e outras classes de biblioteca que necessitam de tratamento especial para funcionar em um ambiente distribuído, para que o código definição do modelo da maioria dos usuários podem executar inalterado. O tf.distribute.Strategy API funciona da mesma maneira com a execução ansioso e gráfico.

Guides

tutoriais

Glossário

  • Dados paralelismo é onde nós executar várias cópias do modelo em diferentes fatias de dados de entrada. Isto está em contraste com o modelo de paralelismo onde nós dividir uma única cópia de um modelo em vários dispositivos. Nota: só apoiar o paralelismo de dados, por agora, mas a esperança para adicionar suporte para o modelo de paralelismo no futuro.
  • Um dispositivo é uma CPU ou acelerador (por exemplo, as GPUs, TPUs) em uma máquina que TensorFlow pode executar operações sobre (ver, por exemplo tf.device ). Você pode ter vários dispositivos em uma única máquina, ou ser ligado a dispositivos em várias máquinas. Dispositivos usados para cálculos de execução são chamados de dispositivos de trabalho. Dispositivos usados para armazenar variáveis são dispositivos de parâmetro. Para algumas estratégias, como tf.distribute.MirroredStrategy , os dispositivos de trabalhadores e de parâmetros será o mesmo (ver variáveis espelhados abaixo). Para outros, será diferente. Por exemplo, tf.distribute.experimental.CentralStorageStrategy coloca as variáveis em um único dispositivo (que pode ser um dispositivo trabalhador ou pode ser o CPU), e tf.distribute.experimental.ParameterServerStrategy coloca as variáveis em máquinas separadas chamados de servidores de parâmetros (ver abaixo).
  • Uma réplica é uma cópia do modelo, rodando em uma fatia dos dados de entrada. Agora cada réplica é executado em seu próprio dispositivo de trabalho, mas uma vez que adicionar suporte para o modelo de paralelismo uma réplica pode se estender por vários dispositivos de trabalho.
  • Um hospedeiro é o dispositivo de CPU em uma máquina com dispositivos de trabalho, tipicamente utilizados para a execução de condutas de entrada.
  • Um trabalhador é definida como sendo a máquina física (s) contendo os dispositivos físicos (por exemplo, as GPUs, TPUs) em que o cálculo é executado replicado. Um trabalhador pode conter um ou mais réplicas, mas contém, pelo menos, uma réplica. Tipicamente um trabalhador corresponderá a uma máquina, mas no caso de muito grandes modelos com modelo paralelismo, um trabalhador pode abranger várias máquinas. Nós normalmente executar um pipeline de entrada por trabalhador, alimentando todas as réplicas em que trabalhador.
  • Síncrono, ou mais comumente sincronização, o treinamento é onde as atualizações de cada réplica são agregados juntos antes de atualizar as variáveis do modelo. Isto está em contraste com a formação assíncrona, ou assíncrona, onde cada réplica atualiza as variáveis do modelo de forma independente. Também pode ter réplicas particionado em grupos que estão em sincronização dentro de cada grupo, mas assíncrona entre grupos.
  • Servidores de parâmetros: Estas são máquinas que possuem uma única cópia de parâmetros / variáveis, usado por algumas estratégias (agora apenas tf.distribute.experimental.ParameterServerStrategy ). Todas as réplicas que querem operar em uma variável recuperá-la no início de uma etapa e enviar uma actualização para ser aplicado no final da etapa. Estes podem, em apoio priniciple qualquer sincronização ou treinamento assíncrono, mas agora só temos o apoio à formação assíncrona com servidores de parâmetro. Compare com tf.distribute.experimental.CentralStorageStrategy , o que coloca todas as variáveis em um único dispositivo na mesma máquina (e faz treinamento sync), e tf.distribute.MirroredStrategy , que espelha variáveis para vários dispositivos (veja abaixo).

  • Contexto réplica vs. contexto Cross-réplica vs contexto Atualização

    Um contexto réplica se aplica quando você executar a função de computação que foi chamado com strategy.run . Conceitualmente, você está no contexto réplica ao executar a função de computação que está sendo replicado.

    Um contexto de atualização é inserido em um tf.distribute.StrategyExtended.update chamada.

    Um contexto cross-réplica é inserido quando você entra em um strategy.scope . Isso é útil para chamar tf.distribute.Strategy métodos que operam através das réplicas (como reduce_to() ). Por padrão, você começar em um contexto réplica (o "contexto única réplica default") e, em seguida, alguns métodos podem mudar você e para trás.

  • Valor distribuído: Distribuído valor é representado pela classe base tf.distribute.DistributedValues . tf.distribute.DistributedValues é útil para representar valores em vários dispositivos, e que contém um mapa de ID de réplica para valores. Dois tipos representativos de tf.distribute.DistributedValues são "PerReplica" e valores "espelhados".

    existem valores "PerReplica" nos dispositivos de trabalho, com um valor diferente para cada réplica. Eles são produzidos por iteração através de um conjunto de dados distribuídos retornado por tf.distribute.Strategy.experimental_distribute_dataset e tf.distribute.Strategy.experimental_distribute_datasets_from_function . Eles também são o resultado típico retornado por tf.distribute.Strategy.run .

    valores "espelhadas" são como valores "PerReplica", exceto nós sabemos que o valor em todas as réplicas são os mesmos. Podemos ler com segurança um valor "Mirrored" em um contexto cross-réplica usando o valor em qualquer réplica.

  • Desembrulhar e fusão: Considere chamar uma função fn em várias réplicas, como strategy.run(fn, args=[w]) com um argumento w que é um tf.distribute.DistributedValues . Isto significa w terá um mapa tomar id réplica 0 para w0 , id réplica 1 a w1 , etc. strategy.run() desembrulha w antes de chamar fn , por isso chama fn(w0) no dispositivo d0 , fn(w1) no dispositivo d1 , etc., em seguida, funde-se os valores de retorno de fn() , o que leva a um objecto comum se os valores devolvidos são o mesmo objecto de cada réplica, ou um DistributedValues objeto de outro modo.

  • Reduções e todo-redução: A redução é um método de agregação de vários valores para um valor, como "soma" ou "significativo". Se a estratégia é fazer o treinamento de sincronização, vamos realizar uma redução nos gradientes para um parâmetro de todas as réplicas antes de aplicar a atualização. All-reduzir é um algoritmo para a realização de uma redução nos valores a partir de múltiplos dispositivos e fazer o resultado disponível em todos os dispositivos.

  • Variáveis espelhadas: São variáveis que são criadas em vários dispositivos, onde mantemos as variáveis em sincronia, aplicando as mesmas atualizações para cada cópia. Variáveis espelhados são criados com tf.Variable(...synchronization=tf.VariableSynchronization.ON_WRITE...) . Normalmente, eles só são usados ​​na formação síncrona.

  • variáveis SyncOnRead

    Variáveis SyncOnRead são criados por tf.Variable(...synchronization=tf.VariableSynchronization.ON_READ...) , e eles são criados em vários dispositivos. No contexto de réplicas, cada variável componente na réplica local pode realizar lê e escreve sem sincronização com o outro. Quando a variável SyncOnRead é lido no contexto cruzada réplica, os valores de variáveis dos componentes são agregadas e devolvido.

    Variáveis SyncOnRead trazer muita dificuldade configuração personalizada com a lógica subjacente, de modo que não incentivar os usuários a variável instanciar e uso SyncOnRead por conta própria. Temos usado principalmente variáveis SyncOnRead para casos de uso, como norma lote e métricas. Por motivos de desempenho, que muitas vezes não é necessário manter estas estatísticas em sincronia cada passo e podem ser acumulados em cada réplica de forma independente. A única vez que deseja sincronizar-los está relatando ou pontos de verificação, o que normalmente acontece em contexto cross-replica. Variáveis SyncOnRead também são frequentemente utilizados por usuários avançados que querem controlar quando os valores das variáveis são agregados. Por exemplo, os usuários às vezes querem manter gradientes de forma independente em cada réplica de um par de passos sem agregação.

  • Camadas distribuir-aware

    As camadas são geralmente chamado num contexto réplica, excepto quando se define um modelo funcional Keras. tf.distribute.in_cross_replica_context vai deixar você determinar qual caso você está. Se em um contexto réplica, o tf.distribute.get_replica_context função irá retornar o contexto réplica default fora de um escopo estratégia, None dentro de um escopo estratégia, e uma tf.distribute.ReplicaContext objecto dentro de um âmbito estratégia e dentro de um tf.distribute.Strategy.run função. O ReplicaContext objeto tem um all_reduce método para agregar em todas as réplicas.

Note que nós fornecemos uma versão padrão do tf.distribute.Strategy que é utilizada quando nenhuma outra estratégia está no escopo, que oferece a mesma API com um comportamento padrão razoável.

módulos

cluster_resolver módulo: importações biblioteca para ClusterResolvers.

experimental módulo: Distribuição Experimental biblioteca Estratégia.

Aulas

class CrossDeviceOps : Classe base para redução cruzada dispositivo e algoritmos de radiodifusão.

class DistributedDataset : Representa um conjunto de dados distribuída entre os dispositivos e máquinas.

class DistributedIterator : Um iterador sobre tf.distribute.DistributedDataset .

class DistributedValues : Classe base para a representação de valores distribuídos.

class HierarchicalCopyAllReduce : Redução usando cópia hierárquica de todos os reduzir.

class InputContext : Uma classe de informação de embrulho necessário por uma função de entra