
Chinese: 
德里克·莫雷：好的
大家好
希望大家都享受了很好的午餐
正如扎克说的，我是德里克·莫雷
我花了将近两年研发 TensorFlow
在这段时间里，我做过的最有趣的事情之一
是 Distributed TensorFlow
这就是我今天将要介绍的东西
在我开始之前
我想要了解一下这个会场
这里有多少人曾经编写或者运行
Distributed TensorFlow 程序？
好的
所以大概有 5% 的人
对在看直播的观众，很不好意思
你们不能举手给我即时的反馈
但假如你愿意在 Twitter 上关注我
这就是一个很积极的信号
好的
那为什么——谢谢你们
为什么我要这么关心
Distributed TensorFlow？
正是它让我们在谷歌的数据中心
提高这些看上去极其现代的
机器的学习和推断能力
因为我们在一年以前对它公开源代码

Japanese: 
DEREK MURRAY: OK
みなさん、こんにちは
素晴しいランチを召し上がりましたか。
ザックの紹介にあった通り、
私はデレック・マーリーです。
２年ほど TensorFlow で
業務に携わっています。
その間、最も素晴しいことを
１つ挙げるとすれば
TensorFlow のディストリビューションに
携わる業務に就いていることです。
今日、その話をしたいと思います。
話し始める前に、会場の雰囲気を
掴んでおきたいと思います。
TensorFlow プログラムに登録、
作動したことがある方はいらっしゃいますか。
分かりました、
おおよそ５％の方がそうですね。
Livestream をご覧になっていて、
手を挙げられない方
すぐにフィードバックを返せない方には
申し訳ないです。
私の Twitter をフォローしてくれれば、
それは力強いシグナルになります。
それでは、
ありがとうございます。
なぜ、分布された TensorFlow の
ことをこんなに気にかけるのか。
データセンター内の
これらの未来型マシーン上で Google を通じて
習得マシーンモデルとトレーニングの
インターフェア増幅が可能になるからです。
１年前にオープンソースを実行して以来、
自宅のクラスター上で
作動させることができるようになりました。

Korean: 
좋습니다
안녕하세요, 여러분
점심 식사 잘 하셨길 바랍니다
제크가 말했듯 저는 데릭 머레이입니다
제가 텐서플로우에 관한 일을
한지 2년이 조금 넘었습니다
이 기간동안 제가 해 온
가장 흥미로운 일 중 하나는
바로 분산 텐서플로우입니다
오늘 발표할 주제이죠
시작하기 전에 여기 계신 분들을
좀 이해해보자 합니다
분산 텐서플로우 프로그램을 쓰거나
실행해보신 분들 있을까요?
좋습니다
아마 5%정도 되는 것 같습니다
손을 못 들고 즉각적인
피드백을 주지 못하는
라이브스트림 시청자분들께는 죄송합니다
하지만 트위터에서 저를
팔로우하길 원하시면
아주 강력한 신호를 보내는 셈이죠
좋습니다
감사합니다
어째서 제가 분산 텐서플로우에
많은 관심을 가질까요?
이곳 Google에서 저희가 훈련과
데이터 센터에 있는
미래에서 온 듯한 기계에서
머신 러닝 모델의
추론을 확대할 수 있도록
해주는 것이기 때문이죠
일 년 전쯤 오픈소스화한 이후로

English: 
DEREK MURRAY: OK.
Hello, everyone.
I hope you all had a nice lunch.
So as Zach said,
I'm Derek Murray.
I've been working on TensorFlow
for a little over two years
now.
And in that time, one of
the most interesting things
I've worked on has been
distributed TensorFlow.
So that's what I'm going
to be talking about today.
Before I get
started, I just want
to get a sense of the room.
So how many people here
have ever written or run
a distributed
TensorFlow program?
All right.
I'm going to say that's,
like, 5% of you, maybe.
I'm sorry to the folks
on the livestream who
can't put your hands up and
give me this immediate feedback.
But if you want to
follow me on Twitter,
that would send a
very strong signal.
OK.
So why-- thank you.
So why do I care so much
about distributed TensorFlow?
Well, it's what enables
us here at Google
to scale up the training
and inference of machine
learning models on these
futuristic-looking machines
in our data centers.
And since we made it open
source just under a year ago,

Indonesian: 
Halo semuanya.
Semoga makan siangnya enak.
Seperti kata Zach, aku Derek Murray.
Aku bekerja di TensorFlow
selama dua tahun lebih sedikit.
Dan selama ini,
satu hal yang paling menarik
adalah TensorFlow terdistribusi.
Itulah yang akan kubicarakan kali ini.
Sebelum mulai,
aku ingin merasakan atmosfernya.
Berapa orang di sini yang
pernah menulis atau menjalankan
program TensorFlow terdistribusi?
Baiklah. Kurasa mungkin sekitar 5%.
Maaf untuk kalian yang menonton
siaran langsung
tak bisa memberikan
umpan balik langsung.
Tapi jika kau mengikutiku di Twitter
itu sinyal yang sangat kuat untukku.
Oke. Terima kasih.
Mengapa aku sangat peduli
dengan TensorFlow terdistribusi?
Karena itu membuat kami di Google
mampu meningkatkan latihan dan
inferensi model machine learning
pada mesin-mesin futuristis
di pusat data kami.
Karena dibuat sumber terbuka
hampir satu tahun lalu

Portuguese: 
Ok. Olá a todos.
Espero que o almoço tenha sido ótimo.
Então, como o Zach disse,
eu sou o Derek Murray.
Eu trabalho no TensorFlow há
pouco mais de dois anos.
E durante esse período, uma das coisas
mais interessantes das quais
eu trabalhei foi o 
TensorFlow distribuído.
Então é sobre isso que falarei hoje.
Antes de começar, eu gostaria
de ter uma noção sobre a plateia.
Quantas pessoas aqui 
já desenvolveram ou executaram
um programa de TensorFlow distribuído?
Certo.
Vou dizer que cinco 
por cento de vocês, talvez.
Desculpe aos colegas 
assistindo pelo livestream
e que não podem erguer as mãos e
me responderem diretamente.
Mas se quiserem me seguir no Twitter
isso seria algo bem importante.
Ok.
Então por que...obrigado.
Então por que eu me importo bastante
com o TensorFlow distribuído?
Bem, é o que permite nós, aqui no Google
de aumentar o treinamento
e a inferência de modelos
de aprendizagem automática
destas máquinas futurísticas
nos nossos centros de dados.
E desde que o fizemos 
um software livre, há menos de um ano

Spanish: 
Muy bien.
Hola a todos.
Espero que hayan comido bien.
Como dijo Zak, yo soy Derek Murray.
Llevo trabajando en Tensor Flow
por poco más de dos años.
En ese tiempo, algo interesante 
en lo que he trabajado
ha sido TensorFlow distribuido.
Hoy les voy a hablar de eso.
Antes de empezar quiero darme 
una idea de la audiencia.
¿Cuántos aquí han escrito
o ejecutado
un programa distribuido
de Tensor Flow?
Muy bien.
Diría que es quizás el 5 %.
Lamento por quienes 
nos siguen en la transmisión
y no pueden levantar la mano
y no pueden participar.
Pero si desean seguirme en Twitter,
eso me dará una idea
mucho más clara.
Bien.
Gracias.
¿Por qué me importa tanto
TensorFlow distribuido?
Porque es lo que nos permite en Google
aumentar el entrenamiento e inferencia
de modelos de aprendizaje automático
en las máquinas futurísticas 
de nuestros centros de datos.
Desde que hace un año 
lo hicimos de código abierto

Indonesian: 
kau juga dapat menjalankannya
di klaster milikmu di rumah.
Kenapa kau ingin menjalankan TensorFlow
pada banyak komputer dalam satu waktu?
Zach tadi memberi sedikit petunjuk.
Alasan umumnya adalah
kau ingin meningkatkan
hasil latihan modelmu agar
latihan lebih cepat
dengan memanfaatkan beban GPU dan
melakukan latihan model secara paralel.
Grafik ini diambil dari makalah OSDI
yang kami tulis tahun lalu.
Memperlihatkan hasil latihan
model Inception_V3
meningkat dengan menggunakan
hingga 200 GPU.
Sebenarnya kami memakai
TensorFlow versi .8, .9 untuk ini.
Makin tinggi angkanya,
makin baik perbaikannya
seperti yang kalian dengar pagi ini.
Model Inception ini bagus
karena pas untuk satu GPU.
Lebih kompleks, terjemahan mesin neural
yang disebutkan Megan saat keynote.
Model ini sangat besar
sehingga memfaatkan pembagian
ke hingga 8 GPU di server yang sama.
Lalu kami memakai beberapa server untuk
latihan model secara paralel.
Jika ingin tahu lebih tentang model ini

English: 
you've been able to run it on
your clusters at home as well.
And why might you want to run
TensorFlow on lots of computers
at the same time?
Zach kind of gave you a
clue in the introduction.
The most common
reason is that you
want to increase the
throughput of training
your models to train them faster
by harnessing a load of GPUs
and train that
model in parallel.
So this graph is taken
from our OSDI paper
that we wrote last year.
And it shows how the
training throughput
of the Inception_V3 model
scales up using up to 200 GPUs.
And actually this is, I
think, TensorFlow .8, .9,
was the version
we used for this.
So the numbers have
only gotten better
with all the improvements
you heard about this morning.
So the Inception model is
nice because it fits neatly
in a single GPU.
We also have more
complicated things
like the neural machine
translation model, which
Megan mentioned in the keynote.
And this model is
so big, it benefits
from being split across up to
eight GPUs in the same server.
And then we use multiple
servers to train
that model in parallel.
If you're interested
in finding out more
about models like
this, Eugene is
going to be talking
about the LSTMs that

Spanish: 
ustedes han podido ejecutarlo 
también en clústeres desde casa.
¿Por qué ejecutar TensorFlow
en muchas computadoras
al mismo tiempo?
Zak les dio una pista en la introducción.
La razón más común es 
para aumentar el rendimiento
del entrenamiento de tus modelos
para entrenarlos más rápido 
con cargas de GPU
y entrenar ese modelo en paralelo.
Este gráfico es 
de nuestro artículo sobre OSDI
que escribimos el año pasado.
Nos muestra cómo 
el rendimiento del entrenamiento
del modelo de Inception_v3
aumenta con hasta 200 GPU.
Y creo que la versión que usamos
fue TensorFlow .8 o .9.
De esta forma, 
mejoraron los números
junto con todas las mejoras
que escucharon esta mañana.
El modelo de Inception está bien
porque encaja muy bien en un GPU.
También hay cosas más complejas
como el modelo de traducción
de una máquina neuronal
que mencionó Megan en la apertura.
Este modelo es tan grande
que se beneficia de estar separado 
hasta en ocho GPU en el mismo servidor.
Luego empleamos muchos servidores
para entrenar ese modelo en paralelo.
Si les interesa saber más
de modelos como este,
Eugene hablará más adelante 
sobre los LSTM

Japanese: 
なぜ１度に多数のコンピューター上で
TensorFlow を動かしたいのでしょうか。
イントロ部分でザックが
ヒントを与えたと思います。
最も共通しているのは、トレーニングモデルの
情報処理量を増強するためです。
それによって、GPU の負担を抑制しながら
より迅速にモデルをトレーニングでき、
同時にそのモデルも
トレーニングできるからです。
去年作成した OSDI 文書から
抽出したグラフです。
Inception V3 モデルのトレーニング
情報処理量は 200 GPU まで増えました。
これに使っていたのが
TensorFlow .8, .9 のバージョンでした。
今朝お聞きになったように、全ての改善に伴って
数字も伸びてきています。
インセプションモデルは、シングル GPU に
ぴったりと収まるので素晴しいです。
ニューラルマシーン翻訳モデルのように、
複雑な事象もあります。
キーノート部分でメーガンが言及しました。
同モデルは非常に大きく、同一のサーバー内で
8 GPU まで分割できます。
そのモデルを並行してトレーニングするために、
複数のサーバーを使います。
このようなモデルについて知りたければ、

Chinese: 
你可以在家里运行自己的代码群
为什么你要在很多电脑上
同时运行 TensorFlow？
扎克在简介为你们提供了一些线索
最普通的原因是
你想要增强模型的吞吐量
通过加强图形处理器负荷
让它们运行更快
同时加强模型
这个图表来自我们
去年写的操作系统设计与实现论文
它显示了 Inception_V3 模型的
训练吞吐量
在最高使用 200 个
图形处理器的增强情况
事实上我觉得
TensorFlow .8, .9
就是我们使用的版本
这些数据在你们今早听说的提高后
才变得能好
Inception 模型很好
因为它能完美地
和一个图形处理器结合
我们也有更复杂的东西
比如神经系统机器翻译模型
也就是梅根在演示里提到的
这个模型非常大
它受益于把八个图形处理器
分布在同一个服务器中
我们用多个服务器
同时训练我们的模型
假如你有兴趣
了解更多像这个模型的情况
尤金接下来将要介绍 LSTMs

Portuguese: 
vocês são capazes de rodá-lo em vários
computadores na sua casa também.
E por que você iria querer
executar o TensorFlow
em vários computadores 
ao mesmo tempo?
Zach deu uma ideia na introdução.
A razão mais comum é que você
quer aumentar o rendimento
de treinamento dos seus modelos
para treiná-los mais rápido,
aproveitando a carga de GPUs
e treinar aquele modelo em paralelo.
Este gráfico foi tirado
do nosso artigo "OSDI"
que escrevemos no ano passado.
E mostra como o rendimento de
treinamento do modelo Inception_V3
aumenta usando até 200 GPUs.
E isso é, eu acho, TensorFlow.8, .9
foi a versão que usamos para isso.
Então os números só melhoraram
com todas as melhorias
as quais vocês escutaram de manhã.
Então o modelo Inception é legal porque
cabe perfeitamente em um único GPU.
Nós ainda temos coisas mais complicadas
como o modelo de rede neural de tradução
o qual a Megan mencionou 
na palestra inaugural.
E esse modelo é tão grande,
que se beneficia por se dividir
em até oito GPUs no mesmo servidor.
E então nós usamos vários servidores
para treinar esse modelo em paralelo.
Se estiver interessado em saber mais
sobre modelos como este
o Eugene falará mais tarde sobre LSTMs 

Korean: 
집에서 여러분의 클러스터에서도
실행할 수 있게 되었습니다
그럼 어째서 동시에
많은 컴퓨터에서 텐서플로우를
실행하고 싶은 걸까요?
소개에서 제크가
일종의 단서를 주었습니다
가장 흔한 이유는
많은 GPU를 이용해서 모델을
더 빨리 동시에 훈련하기 위해
모델 훈련의 처리율을
향상시키고 싶기 때문이죠
이 그래프는 작년에
제가 쓴 OSDI 논문에서
가져온 것입니다
이 논문은 어떻게
인셉션 V3 모델의 훈련 처리율이
최대 200개의 GPU를 사용해서
확장되었는지 보여줍니다
제 생각에 이는
텐서플로우 0.8, 0.9버전을
사용한 결과였습니다
따라서 오늘 오전에
들으신 모든 개선점에서
숫자는 더 나아졌을 뿐이죠
인셉션 모델은 단일
GPU에 잘 맞기 때문에
아주 좋습니다
인공 신경 머신 번역 모델과 같은
좀 더 복잡한 것도 있죠
키노트에서 메건이 말했던 내용이죠
이 모델은 너무 커서 같은 서버에서
최대 8개의 GPU로
나누는 것이 효과적입니다
그런 후 이 모델을
동시에 훈련시키기 위해
여러 서버를 사용하는 거죠
이와 같은 모델에 대해
더 많이 알고 싶으시면
유진이 나중에 번역 모델의 각 레이어를

Korean: 
구성하는 LSTM에 대해
이야기 할 겁니다
많은 컴퓨터가 필요한 또 다른 이유는
모델이 너무 커서 단일 머신에
안 맞기 때문이죠
이는 오늘 [청취불가]가
얘기할 여러 가지
넓고 깊은 모델의 경우에도 그렇습니다
이 모델은 그 크기가 기가바이트나
수십 기가바이트일 수 있는
큰 임베딩 행렬을 사용합니다
스파스 데이터를 맵핑하기
위해서인데 예컨대
사용자가 이를 전통적인
딥 인공신경망으로 훈련할 수 있는
[청취불가] 표상으로
맵 다운로드하기 위해
함께 사용하는 
몇 가지 앱과 같은 것이죠
그러면 왜 큰 모델에 만족할까요?
제 동료인 노암 샤지르는
훈련시키기에 실용적인
큰 모델을 만들기 위해
한계를 초월하는 것으로
명성이 자자합니다
노암은 굉장히 큰 아웃풋 클래스 세트로
확대되는 분산된 후보 샘플링과
같은 기술을 사용하죠
최근에 노암은 이 팀과
일을 같이 했습니다
2017년 ICLR에
논문을 낸 것으로 알고 있습니다
수백억의 파라미터로
인공신경망을 훈련시키기 위해

Chinese: 
它组成了翻译模型的每个层次
另一个你想在你的模型中
用很多个电脑的原因是
你的模型太大了，
一个机器不能承载你的模型
对很多有广度和深度的模型来说
都是如此
汉斯后来将会介绍这个
这用了大量内嵌矩阵
要追踪分散的数据
可能要千兆字节或万兆字节
在这个例子里面
用户一起用来追踪它们到[听不清]
的几个应用
这证明我们可以
使用一个传统深层神经网络进行训练
接下来，当你可以加强
这大得可怕模型的时候
为什么还要勉强接受非常大的模型呢？
我们的同事诺阿姆·萨泽尔知名于
挑战制作可加强的大型模型的极限
他使用了如分配候选人样品
来提高输出类集的方法
最近他和一个团队合作——
我认为他们刚写好了
ICLR 2017 的论文
用百亿的参数来加强神经网络

Spanish: 
que forman cada capa 
del modelo de traducción.
Otra razón por la que quieran 
usar muchas computadoras
es porque su modelo es tan grande
que no cabe en una sola máquina.
Esto es cierto para muchos 
modelos amplios y profundos
de los que Heng-Tze hablará más tarde.
Estos usan grandes matrices integradas
que pueden ser gigabytes o decenas 
de gigabytes en tamaño
para mapear datos dispersos
como en este ejemplo
en el que los usuarios usaron
parejas de apps para mapearlos
en una representación 
que podemos entrenar
con una red neuronal profunda.
¿Por qué quedarnos con modelos muy grandes
cuando puedes entrenar 
modelos mucho más grandes también?
Nuestro colega Noam Shazeer
tiene reputación por innovar
en hacer que modelos más grandes
sean más prácticos para entrenar.
Usa trucos como 
muestreo distribuido de candidatos
para aumentar resultados 
muy grandes de grupos de clases.
Recientemente ha trabajado 
con un equipo...
Creo que tienen un artículo en ICLR 2017
para entrenar redes neuronales
con decenas de miles 
de millones de parámetros.

Portuguese: 
os quais constituem cada camada
do modelo de tradução.
Outro motivo pelo qual você
queira usar muitos computadores
é que o seu modelo é tão grande
que não cabe em apenas uma máquina.
Então isso é verdade para
muitos dos modelos Wide e Deep
os quais serão discutidos mais tarde.
E estes usam grande matrizes
de códigos inseridos
podendo ser do tamanho de 
gigabytes ou de dezenas de gigabytes
para mapear dados escassos,
como neste exemplo
pares de aplicativos que os usuários
utilizaram em conjunto para mapeá-los
em uma representação
a qual possamos treinar
com uma rede neural Deep tradicional.
E então por que contentar-se
com modelos muito grandes
quando você também pode
treinar modelos excessivamente grandes?
O nosso colega Noam Shazeer
tem a reputação de inovar
no sentido de fazer modelos muito
grandes práticos para treinar.
E ele usa truques como uma 
amostragem de distribuição de candidatos
para aumentar o conjunto
de classes de saída.
Ele está trabalhando 
recentemente com um time...
acredito que eles acabaram
de fazer um artigo na ICLR 2017...
para treinar redes neurais com
dezenas de bilhões de parâmetros

Japanese: 
この後ユージンが、翻訳モデルの各レイヤーを
作成する LSTM について話をします。
多数のコンピューターを使用する
もう１つの理由は、
モデルがとても大きくて、
シングルマシーンに合わないからです。
ワイドでディープなモデルの多くに
当てはまることと思います。
これについては、後ほどハンスが話をします。
これらの膨大な配列埋め込みは、
ギガバイトや多量のギガバイトを
使用しています。
ユーザーが使用するアプリのように
散らばったデータを配置するため、
通常のディープニューラルネットワークで
トレーニングできる
（聞き取り不可）記号に至るまで
配置するために使われています。
膨大なモデルを無鉄砲にも
トレーニングできるにもかかわらず、
なぜこのように膨大なモデルを
落ち着かせたいのでしょうか。
同僚のノーム・シェジーアは
トレーニング可能な実用大型モデルを作るため
封筒を送りつけたらしいという
評判があります。
非常に膨大な
アウトプットクラスセットに増強するまで
分布された候補をサンプリングする
トリックを使います。
最近まで、言語モデリングと翻訳タスクの
より良いパフォーマンスを実現するために
様々なエキスパートを動員し、
条件付き算定法のような技術を用いて

Indonesian: 
Eugene nanti akan bicara tentang LSTM
yang membuat tiap layer model terjemahan.
Alasan lainnya menggunakan
banyak komputer adalah
modelmu sangat besar hingga
tak muat pada satu mesin.
Ini benar untuk model-model
yang lebar dan dalam
yang nanti akan dipresentasikan hari ini.
Ini menggunakan
matrik embedding yang besar
berukuran gigabyte atau puluhan gigabyte
untuk memetakan banyak data terpisah,
contohnya sepasang aplikasi
yang digunakan pengguna untuk
memetakan ini semua
yang dapat kita latih dengan
deep neural network tradisional.
Lalu, kenapa memilih
model yang sangat besar
ketika kau bisa melatih
model yang luar biasa besar juga?
Jadi rekan kami, Noam Shazeer,
terkenal karena
memaksa batas latihan
model praktis yang besar.
Pakai trik, pengambilan kandidat
sampel terdistribusi
untuk meningkatkan set kelas
output menjadi sangat besar.
Akhir-akhir ini dia bekerja dalam tim
kurasa mereka memasukkan
makalah ke ICLR 2017
tentang latihan jaringan neural
dengan puluhan milyar parameter

English: 
make up each layer of the
translation model later on.
Another reason you might
want to use lots of computers
is that your model is
so big that it doesn't
fit in a single machine.
So this is true for a lot
of the wide and deep models
that [INAUDIBLE] is going to
be talking about later today.
And these use large
embedding matrices,
that can be gigabytes or
tens of gigabytes in size,
to map sparse data like, in
this example, pairs of apps
that users have used
together to map those down
to [INAUDIBLE]
representation that we
can train with a traditional
deep neural network.
And then, why settle
for very large models
when you can train outrageously
large models as well?
So our colleague Noam Shazeer
has a bit of a reputation for,
like, pushing the envelope
on making large models
practical to train.
And he uses tricks like
distributed candidate
sampling to scale up to very
large output class sets.
Recently he's been
working with a team--
I think they just got a
paper into ICLR 2017--
to train neural networks with
tens of billions of parameters,

English: 
using techniques like
conditional computation
and mixtures of experts to
get even better performance
on some language modeling
and translation tasks.
So what all these
examples have in common
is that they take advantage
of the flexibility
distributed TensorFlow gives you
to train bigger models faster
and to better accuracy.
And this flexibility,
you know, it's
great if you're an
expert user, but it
can make distributed TensorFlow
look a little bit daunting.
It actually is a very
simple, very minimalist core,
but it wears a lot of the
complexity of distributed
computing on the outside.
So while we do have some nice
high-level APIs, sometimes
for the really
cutting-edge stuff
you have to kind of get in
there and move some tensors
around using the
low-level TensorFlow API.
And so my aim over the
next 20, 25 minutes or so
is to give you a bottom-up
introduction to distributed
TensorFlow.
I'm going to show you how the
core concepts you might be used
to in single-process TensorFlow
translate to the distributed
world.
I'll give you some ideas for
how to deal with the complexity
that ensues.

Spanish: 
usando técnicas como cómputo condicional
y varios expertos para tener
un mejor desempeño
en modelaje de lenguaje
y tareas de traducción.
Lo que todas ellas tienen en común
es que toman 
la ventaja de flexibilidad,
que TensorFlow distribuido te da,
para entrenar modelos 
más grandes más rápido
y con mayor exactitud.
Y esta flexibilidad está bien
si eres un usario experto
pero puede hacer ver al 
TensorFlow distribuido un poco abrumador.
Es de hecho un núcleo
minimalista y simple,
pero por fuera tiene 
mucha de la complejidad
del cómputo distribuido.
Si bien tenemos algunas
de las API agradables de alto nivel;
para las cosas realmente innovadoras
a veces tienes que adentrarte 
y mover algunos tensores
usando el API 
de TensorFLow de bajo nivel.
Mi objetivo para los próximos 
20 o 25 minutos
es darles una introducción general
de TensorFlow distribuido.
Les mostraré cómo se traducen
los conceptos principales
del proceso único de Tensor Flow
hacia el mundo distribuido.
Les daré algunas ideas para lidiar
con la complejidad que acarrea.

Japanese: 
莫大なパラメータを使い
ニューラルネットワークをトレーニングする
ICLR 2017 のタスクを受けたチームで
働いていたはずです。
これらの例すべてに
共通することは何でしょう。
それは、より大きなモデルを迅速に
より正確にトレーニングするための
TensorFlow が約束する
フレキシビリティという利点です。
このフレキシビリティというのは、
もしエキスパートであればいいのですが
TensorFlow を分布させるには、
少し気力をくじかせるよう印象を与えます。
それは実際、非常にシンプルで
非常にミニマムなコアなのですが
外部で分布されたコンピューターの複雑さ
という印象があります。
ハイレベルの API を使っていると、
最先端のもののためにそこまで行き、
ローレベルの TensorFlow API を使って
周囲のテンソルを幾つか動かす必要に
迫られます。
これから 20 から 25 分間で、
分布された TensorFlow について、
逆方向のイントロを行ないます。
シングルプロセス TensorFlow 内で見慣れた、
コアコンセプトが
どのように分布世界に
翻訳されているのかをお見せします。
存在し続ける複雑さにどう対処するのか、
幾つかのアイディアを紹介します。

Korean: 
조건부 계산과 같은 기술과
일부 언어 모델링에서
훨씬 더 좋은 성능을
내기 위한 전문가와
번역 엄무를 혼합 사용한 거죠
이 모든 예시가 가진 공통점은
더 큰 모델을 더 빨리
그리고 더 나은 정확성으로
훈련시키기 위해 분산 텐서플로우가
여러분께 제공하는
융통성을 이용한 것이죠
이러한 융통성은
전문가에게는 유용하지만
분산 텐서플로우가
좀 벅차 보이게 할 수도 있죠
사실은 아주 간단하고
최소화된 코어이지만
겉으로 보기에는
분산 계산의 복잡성을
많이 보이고 있죠
멋진 고등 API도 있고
최첨단일 때도 있지만
낮은 수준의 텐서플로우 API를 가지고
텐서를 이리저리 움직여야 하는 겁니다
따라서 다음 20-25분 동안의
제 목표는
분산 텐서플로우를 밑에서
위로 설명하는 겁니다
.
여러분들이 익숙할 수도 있는
핵심 개념을 단일 과정
텐서플로우 번역에서 분산 세계로
보내는 방법을 보여드릴 겁니다
.
이에 따르는 복잡성을 해결하는 법을
설명해 드리겠습니다
.

Indonesian: 
memakai teknik seperti
komputasi kondisional
dan gabungan teknik tingkat tinggi untuk
mendapatkan performa yang lebih baik
bagi pemodelan bahasa dan penerjemahan.
Semua contoh ini memiliki kesamaan
yaitu mereka memanfaatkan fleksibilitas
TensorFlow terdistribusi
untuk latihan model yang besar
dengan lebih cepat dan akurat.
Fleksibilitas ini bagus
jika kau pengguna yang ahli
tapi bisa membuat TensorFlow terdistribusi
terlihat agak menakutkan.
Sebenarnya ini sangat simpel dan
berinti minimalis
tapi diluarnya ada banyak sekali
komputasi terdistribusi yang kompleks.
Sementara kita punya API
tingkat tinggi, kadang
tapi untuk hal-hal yang canggih
kita perlu terlibat langsung dan
memindah beberapa tensor
memakai API TensorFlow tingkat rendah.
Tujuanku selama 20-25 menit
ke depan adalah
memberikan pengenalan
TensorFlow terdistribusi.
Akan kuperlihatkan bagaimana
konsep inti yang kau gunakan
dalam satu proses TensorFlow
menjadi distributed world.
Akan kuberi beberapa ide tentang
bagaimana mengatasi kompleksitas yang ada.

Chinese: 
使用技术如计算条件概率
结合多个专家团队
获得更好的语言建模和翻译任务的结果
这些例子的共同点就是
他们利用了
Distributed TensorFlow 的灵活性
让你可以更快地加强更大的模型
同时更加准确
你知道，这样的灵活性
很有利于专业用户
但是它使得 Distributed TensorFlow
看上去有点可怕
它实际上是很简单的，
有极简的核心的
但是它从外面看上去
充满了分散计算的复杂性
当我们有一些很好的高级应用程序接口
有时候是特别尖端的东西
你有时要深入里面
使用低级的 TensorFlow 应用程序接口
移动一些向量
所以我接下来
20 到 25 分钟的目标就是
给你们一个自下而上的
关于 Distributed TensorFlow 的介绍
我将要向你们展示
在 TensorFlow 翻译的单次过程
到分布的总体中
要怎样使用核心概念
我将要为你们提供一些
解决接下来发生的复杂情况的想法

Portuguese: 
usando técnicas como cálculo condicional
e uma mistura de experts
para obter performances melhores
em algumas modelagens de linguagem
e tarefas de tradução.
Então o que todos 
esses exemplos têm em comum
é que eles se aproveitam da flexibilidade 
que o TensorFlow distribuído oferece
para treinar modelos maiores
mais rápido e com melhor precisão.
E essa flexibilidade, vocês sabem
é ótima se você for um usuário experiente.
Mas pode fazer o TensorFlow distribuído
parecer um pouco assustador.
Na verdade, é um conceito
muito simples e minimalista
mas que utiliza da complexidade
do sistema de processamento distribuído.
Embora tenhamos ótimos níveis de APIs
às vezes, por questão de tecnologia
você tem que ir lá e mover alguns tensores
utilizando o TensorFlow API
de nível baixo.
Então, o meu objetivo pelos
próximos 20, 25 minutos mais ou menos
é dar a vocês uma introdução
bottom-up sobre o TensorFlow distribuído.
Vou mostrar a vocês como
os principais conceitos
que talvez já estejam acostumados
no processo único do TensorFlow
traduz ao distribuído.
Darei algumas ideias de como 
lidar com a complexidade resultante.

Korean: 
분산 텐서플로우가 최소화된 코어를
가진다고 방금 말씀드렸죠
이게 무슨 뜻일까요?
저한테 컴퓨터가
한 대만 있다고 가정해 보죠
그 안에 GCPU기기와
GPU 기기가 있죠
이 기기를 이용해서
텐서플로우 프로그램을 쓰고 싶다면
코드에 with_tf.device
주석을 달면 됩니다
그렇게 하면 예컨대
변수가 CPU로 가고
수학은 GPU로 가는 겁니다
거기에서 더 빨리 실행될 수 있죠
그리고 나서
이 프로그램을 실행할 때
텐서플로우가 기기 사이에서
그래프를 나누고
실행시킬 디바이스
사이의 필수 DNA를 넣는 거죠
.
제 리모컨의 배터리가
떨어지면 어떻게 될까요?
여기로 가 보겠습니다
제 생각에
다시 되는 건가요?
알겠습니다
약간의 지연이 있죠
죄송합니다
좋습니다
여러 대의 머신이 있으면
어떻게 될까요?
조금 있으면 분명해질 이유이지만

Spanish: 
He dicho que TensorFlow 
tiene un núcleo minimalista.
¿Qué quiero decir?
Digamos que tengo una computadora
que tiene un dispositivo GCPU 
y un dispositivo GPU.
Si quiero escribir 
un programa de TensorFlow
para usar estos dispositivos
puedo poner estas 
pequeñas notas "with_td.device".
en mi código.
En este ejemplo, las variables van 
al CPU y la matemática va al GPU
donde correrá más rápido.
Cuando ejecuto este programa,
TensorFlow divide el gráfico
entre los dispositivos
y lo pone en el ADN necesario
entre los dispositivos
para que lo ejecute por mi.
¿Qué sucede cuando se le acabe 
la batería a mi dispositivo?
Bien, nos movemos acá.
Creo.
En múlitiples...
¿No?¿Ya se puede ver?
Muy bien.
Un pequeño retraso.
Lo siento.
Muy bien.
¿Qué pasa si tenemos múltiples máquinas?
Si por razones que quedarán 
claras más tarde

English: 
So I just claimed that
distributed TensorFlow
has a minimalist core.
What did I mean by that?
Well, let's say I've
got just one computer,
and it's got a GCPU device
and a GPU device in it.
And if I want to write a
TensorFlow program to use these
devices, I can put these little
with_tf.device annotations
in my code, so that
for this example,
the variables go on the CPU,
and the math goes on the GPU,
where it's going to run faster.
Then, when I come
to run this program,
TensorFlow splits up the
graph between the devices
and it puts in the necessary
DNA between the devices
to run it for me.
Now what happens when my
clicker runs out of battery?
OK, we're moving over here.
I think.
So when we have multiple--
no, is it working again?
Ah, OK.
Just a little bit of lag.
Sorry about that, folks.
All right.
So what happens if you
have multiple machines?
Let's say, for reasons that
will become apparent later,

Indonesian: 
Aku baru saja berkata TensorFlow
terdistribusi berinti minimalis.
Apa maksudnya itu?
Katakanlah aku hanya punya satu komputer
dengan perangkat GCPU dan GPU di dalamnya.
Jika aku ingin menulis program
TensorFlow untuk untuk memakainya
aku tambahkan anotasi
with_tf.device ke kodeku
maka untuk contoh ini
variabel akan pergi ke CPU
dan proses matematikanya ke GPU
untuk diproses lebih cepat.
Ketika program ini dijalankan
TensorFlow membagi grafik
antara kedua alat
dan menaruh DNA yang diperlukan
di antara keduanya untuk dapat dijalankan.
Apa yang terjadi ketika clicker-ku
kehabisan baterai?
Oke, mari kita berpindah kemari.
Ketika kita punya multi--
tidak, apa tak beres lagi?
Oke.
Hanya sedikit tertunda.
Maaf, semuanya.
Baiklah.
Apa yang terjadi ketika
kau punya banyak mesin?
Katakan, karena alasan yang
nanti akan jelas

Chinese: 
我刚刚说
Distributed TensorFlow
有一个极简的内核
我这样说是什么意思呢？
比如我只有一部电脑
它有一个中央处理器板设备
和一个图形处理器设备
假如我想要写一个
TensorFlow 程序来用这些设备
我可以把这个
with_tf.device 注释
加到我的代码里，对于这个例子
变量存到中央处理器，
数据存储在图形处理器
它在那里运行得更快
接着，当我运行这个程序的时候
TensorFlow 在设备间把图表分开
它在设备间加入必要的 DNA
为我运行程序
假如我的发生器没电了会发生什么呢？
我们接下来就讲这个
我想
当我们有很多——它在运行吗？
好的
只是有一点延迟了
同志们，不好意思
好的
假如你有很多机器会怎么样呢？
比如说，因为后来会更加明显的原因

Portuguese: 
Eu acabei de afirmar
que o TensorFlow distribuído
tem um conceito minimalista.
O que eu quis dizer com isso?
Bem, digamos que eu tenha 
apenas um computador
o qual tem um aparelho GCPU e um GPU nele.
E se eu quiser escrever um programa
TensorFlow para usar esses aparelhos
eu posso colocar essas pequenas
anotações with_tf.device no meu código.
Então, neste exemplo,
as variáveis vão no CPU
e a matemática vai no GPU,
onde irá rodar mais rápido.
Então, quando vou rodar este programa
TensorFlow divide o gráfico 
entre os aparelhos
e coloca o DNA necessário
entre os aparelhos
para rodá-lo para mim.
Então o que acontece quando
meu dispositivo está sem bateria?
Ok, está funcionando agora.
Eu acho.
Então, quando temos múltiplos...
não, está funcionando de novo?
Ah, ok.
Apenas um pouco de atraso.
Desculpe, pessoal. Certo.
Então o que acontece quando
você tem várias máquinas?
Digamos que, por razões 
que ficarão visíveis mais tarde

Japanese: 
たった今、分布された TensorFlowが
最小限のコアを持っていると言いましたが
どんな意味だったのでしょうか。
コンピューターを１台持っています。
そこには GCPU デバイスと
GPU デバイスが入っています。
これらのデバイスを使うために、
TensorFlow プログラムを入力します。
コードにこれらの_tf.device という
注釈を付けることができます。
この例でいくと、変数記号は CPU へ
数字は GPU へ行きます。
その方がより速く作動します。
このプログラムを作動させると、
TensorFlow はデバイス間のグラフを
分割します。
そして作動できるように、デバイス間に
必要とされる DNA を入れます。
クリッカーのバッテリーが無くなった時
どうすればいいのでしょう。
大丈夫、ここに移動しました。
複数の、
また動かなくなったのですか。
OK
少しタイムラグがあります。
すみません。
もし複数のマシーンを持っていたら
どうなるでしょうか。
その理由は後で明らかにします。

Japanese: 
これらの変数記号を取り、異なるプロセスの
CPU デバイスに入れます。
TensorFlow はローカルと全く同じように
リモートデバイスを取り扱います。
では、これらのデバイス名に
少し情報を加えることにします。
そしてランタイムは
異なるプロセス内に整数記号を入力し、
異なるプロセス内の
デバイス間のグラフを分割し、
必要とされる情報を追加します。
この場合は、GRPC を使用して
GPU デバイスから、DNA の代わりに
プロセス間のテンソルを移動します。
ここまでいいですか。
分布された TensorFlow を使うことで、
デバイスの配置を全て正確に
行なうことが可能です。
ええ、くすくす笑いが聞こえました。
どれだけ簡単か
分かって頂けたと思います。
もし TensorFlow プログラムを
入力していたなら,
はい、では
皮肉のタグを付けなければいけませんね。
大丈夫です。
少し戻った方がいいでしょうね。
この問題をより簡単にすることが
できると思います。
DisBelief という１つ前のシステムも含め、
他のシステムからもインスピレーションを
受けることができます。

English: 
that we want to
take those variables
and put them on the CPU
device of a different process.
Well, TensorFlow treats the
remote devices exactly the same
as the local ones.
All I have to do is add just
a little bit of information
to these device
names, and the runtime
will put the variables
in a different process,
splitting up the graph
between the devices
in the different
processes and adding
the necessary communication.
In this case, it
will be using GRPC
to transfer tensors between
the processes instead of DNA
from the GPU device.
So there you have it.
Using distributed
TensorFlow is just
a simple matter of getting
all of your device placements
exactly right.
And yeah, I heard a wry chuckle.
Yeah, I'm sure you know
exactly how easy that can be,
if you've ever written
a TensorFlow program.
All right.
I should have put a sarcasm
tag in there or something.
But OK.
Maybe we should
back up a little bit
and see how we can make
this problem a bit simpler.
Well, one thing we can do
is we can take inspiration
from other systems, including
our previous system, which
was called DisBelief.

Spanish: 
queremos tomar esas variables
y ponerlas en un dispositivo CPU
de un proceso distinto.
TensorFlow trata los dispositivos remotos
igual que los locales...
Todo lo que tengo que hacer
es agregar un poco de información,
a estos nombres de dispositivo,
y el tiempo de ejecución
pondrá las variables
en un proceso diferente,
dividiendo el gráfico
entre los dispositivos
en los procesos distintos
y poniendo la comunicación necesaria.
En este caso, usará GRPC
para transferir tensores 
entre los procesos
en lugar de ADN 
desde el dispositivo GPU.
Ahí lo tienen.
Usar TensorFlow distribuido
es cuestión de tener correctas
todas las disposiciones del dispositivo.
Sí, oigo la sonrisita irónica.
Estoy seguro que saben
lo fácil puede ser
si han escrito un programa de TensorFlow.
Muy bien.
Debí haber puesto 
una etiqueta sarcástica ahí.
Pero bueno.
Regresemos un poco
y veamos cómo podemos hacer 
más fácil este problema.
Algo que podemos hacer
es inspirarnos de otros sistemas, 
incluyendo nuestro sistema anterior
que se llamaba DisBelief.

Korean: 
이 변수를 가지고
다른 과정의 CPU 기기에
넣고 싶다고 가정하겠습니다
텐서플로우는 원격 기기를
다른 로컬 기기와 완전히 똑같이
취급합니다
제가 해야 하는 것이라고는
기기의 이름에
약간의 정보를 더하는 것이죠
그러면 실행시간이
다른 과정에 변수를 넣을 것이고
다른 과정에서 이 기기 사이의 그래프를
나누고 필요한 소통을
더하는 겁니다
이 경우 GPU 기기로부터의
DNA를 사용하는 대신
과정 사이에서 텐서를 이동시키기 위해
GRPC를 사용할 겁니다
그러면 됐죠
분산 텐서플로우를 사용하는 것은 단지
여러분 기기의 위치를
모두 정확하게 만드는
간단한 일일 뿐입니다
그렇죠, 쓴웃음을 들었습니다
이것이 정확히 얼마나 쉬운가를
아시리라 확신합니다
텐서플로우 프로그램을
써보신 적이 있다면 말이죠
좋습니다
여기 어딘가 냉소라는
태그를 붙여야겠습니다
괜찮습니다
어쩌면 우리 모두 한걸음 물러나서
어떻게 이 문제를
좀 더 간단하게 만들지 봐야겠죠
우리가 할 수 있는 일은
다른 시스템에서
영감을 얻는 것으로 우리의 예전 시스템인
디스빌리프가 있죠

Portuguese: 
nós queremos pegar essas variáveis
e colocá-las em um dispositivo CPU
com um processo diferente.
Bom, o TensorFlow trata dispositivos 
remotos da mesma maneira que os locais.
Tudo o que eu preciso fazer 
é adicionar um pouco de informação
nos nomes destes dispositivos
e o tempo de execução
irá colocar as variáveis 
em um processo diferente
dividindo o gráfico entre os dispositivos
nos diferentes processos e adicionando
a comunicação necessária.
Neste caso, iremos usar GRPC
para transferir tensores
entre os processos, ao invés 
do DNA do dispositivo GPU.
Então aí está.
Usar o TensorFlow distribuído é apenas
uma questão de obter todas 
as implantações dos seus dispositivos
de maneira correta.
Eu ouvi uma risada irônica.
Tenho certeza que você
sabe exatamente o quão fácil pode ser
se você já escreveu uma
programação de TensorFlow.
Deveria ter colocado uma nota
de sarcasmo ali ou algo do tipo.
Ok, talvez devêssemos voltar um pouco
e ver como podemos deixar este
problema mais simples.
Uma coisa que poderíamos fazer
é nos inspirar em outros sistemas
incluindo nosso sistema anterior,
chamado de DisBelief.

Chinese: 
我们想要提取这些变量
把它们放在另一个过程的中央处理器
TensorFlow 对远处设备的处理
和本地的一模一样
我要做的所有事情就是
在这些设备名字中
加入一点信息
执行时间会把这些变量
放在不同的过程中
把设备间的不同过程的
图表分开
并加入必要的关联
在这个例子里，它会用到 GRPC
来在过程中传递 Tensor
而不是图形处理器设备里面的 DNA
你们现在会了
使用 Distributed TensorFlow
只是一个简单的
把你的设备放置到正确的地方的问题
我听到了讽刺的笑声
我肯定你们知道这有多简单
只要你们写过一个
TensorFlow 程序
好的
我应该在这里加一个讽刺标志之类的
但好吧
也许我们应该后退一步
看看我们能怎样
把这个问题变得更简单
我们能做的一件事就是
我们可以从其他系统中获得灵感
包括我们之前的系统
它叫做 DisBelief

Indonesian: 
kita ingin mengambil variabel itu
lalu menempatkannya
pada proses-proses berbeda di CPU.
TensorFlow perlakukan perangkat yang jauh
sama dengan yang lokal.
Yang perlu dilakukan ialah
menambahkan sedikit informasi
ke nama perangkat ini dan runtime
akan tempatkan variabel
pada proses yang berbeda
membagi grafik di antara ke dua alat
di proses berbeda
dan tambahkan komunikasi yang perlu.
Pada kasus ini, GRPC digunakan
untuk mentransfer tensor antara proses
daripada DNA dari alat GPU.
Sudah jadi.
Memakai TensorFlow tedistribusi 
itu sesederhana
menempatkan semua alat-alatmu
dengan sempurna.
Ya, aku dengar tawa garing itu.
Aku yakin kalian semua
paham sesimpel apa ini
jika pernah tulis
program TensorFlow.
Baiklah.
Harusnya itu aku beri tanda sarkasme.
Tak apa. Mungkin perlu mundur sedikit
memikirkan cara untuk
menyederhanakan masalah ini.
Yang bisa kita lakukan yaitu
mengambil inspirasi dari sistem lain
termasuk sistem kami sebelumnya,
yang disebut DisBelief.

Spanish: 
En DisBelief teníamos 
dos tipos de procesos distintos.
Teníamos servidor de parámetros
y replicas de "trabajador"
Los servidores de parámetros
son responsables de mantener
todo el estado del modelo
o los parámetros
y actualizarlos en respuesta
a los gradientes entrantes.
Mientras que las réplicas de "trabajador"
harían la parte intensiva del cómputo.
Harían el procesamiento de entrada.
Calcularían la pérdida para su red.
Harían la retropropagación 
para calcular esos gradientes.
En TensorFlow podemos 
imitar esta arquitectura
diseñando algunos de los procesos
que llamamos tareas 
de servidor de parámetro (PS).
Ponemos los nodos de la variable 
y los ops que las actualizan
en esas tareas.
Ponemos el resto del gráfico,
los nodos que hacen
el preprocesamiento, 
la propagación y la retropropagación
en las tareas del "trabajador"
las cuales suelen ser más potentes
y tiene multinúcleos CPU y GPU.
Una gran diferencia de cómo 
hacíamos las cosas en DisBelief
y en TensorFlow
es que en DisBelief
los parámetros de servidor
y las réplicas de "trabajador"
eran dos programas 
totalmente diferentes.
Eran básicamente 
dos sistemas distribuidos

Korean: 
디스빌리프에는 두 가지
상이한 과정이 있었습니다
파라미터 서버와 워커 복제가 있었죠
파라미터 서버는 모든
모델 상태를 유지하는
유지하는 역할을 했고
들어오는 기울기에 따라
업데이트 시키는 거죠
반면 워커 복제는
계산에서 집중적인
부분을 모두 했습니다
인풋 프로세싱을 하겠죠
네트워크의 손실을 계산할 겁니다
이러한 기울기를
계산하기 위해 백드랍도
할 겁니다
텐서플로우에서는 이러한
건축을 흉내낼 수 있습니다
PS 업무라고 부르는 것을
설계하면 되는 겁니다
변수 노드와 이러한 업무에서
이들을 업데이트하는
운영을 넣는 것이죠
그리고 나서 나머지 그래프와
미리 처리하는 노드, 포워드
그리고 아주 강력하고
여러 코스의 CPU와 GPU를
가지는 워커 업무상의
백드랍을 넣는 거죠
디스비리프와 텐서플로우에서 하는 일의
큰 차이점 중 하나는 디스빌리프에서는
파라미터 서버와 워커 복제가 두 개의
완전히 다른 프로그램이라는 점이죠
이들은 기본적으로 공통점이 거의 없는

English: 
And in DisBelief we had two
distinct kinds of processes.
We had parameter servers
and worker replicas.
And parameter servers are
responsible for holding
onto all of the model
state, so the parameters,
and updating them in response
to incoming gradients,
whereas the worker
replicas, they
would do all the intensive
part of the computation.
So they would do the
input processing.
They'd calculate the
loss for your network.
And they'd do the backprop
to actually calculate
those gradients.
In TensorFlow, we can
mimic this architecture
by designating some
of the processes
to be what we call PS tasks.
And we put the variable
nodes and the ops that
update them on those tasks.
And then we put the rest of
the graph, the nodes that
do the pre-processing, the
forward, and the backprop
on the worker tasks, which
tend to be more powerful
and have multi-course
CPUs and GPUs.
And one big difference
between how we did things
in DisBelief and
in TensorFlow is
that in DisBelief, the parameter
servers and the worker replicas
were two completely
different programs.
They were basically two
loosely-coupled distributed

Chinese: 
在 DisBelief 中我们有两个不同的过程
我们有参数服务器和复制工作区
参数服务器的责任是
存储所有模型的状态，也就是参数
并根据后来的梯度进行更新
然而复制工作区
会做集中的计算
所以它们会处理输入
它们会计算你的网络的损失
它们也会支持
准确地计算这些梯度
在 TensorFlow 里面
我们可以通过设计一些过程
来模拟这个结构
我们叫它为 PS 任务
我们写入变量节点和 ops
它能在任务过程中进行更新
然后我们把图表中的其余部分
预处理的节点，前进和支持
加入到以后的工作任务中
它会越来越有用
有多类中央处理器和图形处理器
我们在 DisBelief
和 TensorFlow 中
最大的不同就是
在 DisBelief 里，
参数服务器和复制工作区
是两个完全不同的程序
它们基本上是两个不相联的系统

Indonesian: 
DisBelief memiliki dua proses
yang sangat berbeda.
Ada parameter server
dan replika worker.
Parameter server bertugas
menjaga status semua model parameternya
dan memperbarui parameter sebagai
respon untuk gradien yang akan muncul
sedangkan replika worker
melakukan semua sisi intensif komputasi.
Replika worker akan memproses input.
Loss dari jaringan juga dihitungnya.
Backprop digunakan untuk
menghitung gradien tersebut.
Di TensorFlow,
kita bisa meniru arsitektur ini
dengan mendesain beberapa proses
menjadi apa yang disebut dengan PS tasks.
Kita tempatkan node variabel dan operasi
yang akan memperbarui task.
Lalu tempatkan sisa grafik,
node-node pre-process
forward dan backprop pada worker task
yang mana ini akan jauh lebih hebat
dan memiliki CPU dan GPU multi-course.
Satu perbedaan besar dari cara memakai
DisBelief dan TensorFlow ialah
di DisBelief,
parameter server dan replika worker
adalah dua program yang
benar-benar berbeda.

Japanese: 
DisBelief では、
２つの異なるプロセスがありました。
パラメータサーバーと、
ワーカーレプリカです。
パラメータサーバーはモデルステート全て、
パラメータを保持する役割を担っています。
そして参入勾配に対応して
パラメータのアップデートを行ないます。
一方で、ワーカーレプリカは
算定の集約作業すべてを担っています。
インプット処理を行ないます。
ネットワークのロスを計算します。
これらの勾配を計算するために
バックプロパゲーションを行ないます。
TensorFlow で、このアーキテクチャーを
模倣することができます。
幾つかのプロセスを PS タスクと呼ぶものに
書き換えるのです。
これらのタスク上でアップデートする、
変数のノードとオプスを入力します。
そしてグラフの残りと
事前処理を行なうノード、
ワーカータスク上の
バックプロパゲーションを入力します。
これはよりパワフルになる傾向があり、
CPU と GPU マルチコースを持ちます。
Disbelief と TensorFlow で
行なったことのうち、
それぞれの大きな違いは、
DisBelief ではパラメータサーバーと
ワーカーレプリカは
２つの全く異なるプログラムだと
いうことです。
基本的には２つのルーズな
組みを成す分布されたシステムで
共通事項がほぼない状態です。

Portuguese: 
E no DisBelief tínhamos dois
processos distintos.
Tínhamos servidores de 
parâmetros e réplicas worker.
E servidores de parâmetros são
responsáveis por manter
todos os modos de "estado",
ou seja, os parâmetros
e atualizá-los em resposta 
ao gradiente de rendimento.
Enquanto as réplicas worker
farão a parte mais intensa do cálculo.
Então eles fariam o processamento 
de entrada de dados.
Eles calculariam a perda da sua rede.
E fariam a retropropagação
para calcular aqueles gradientes.
No TensorFlow nós podemos
simular esta estrutura
designando alguns dos processos
para serem o que chamamos de tarefas PS.
E colocamos os nós variáveis
e os OPS que os atualizarão
nessas tarefas.
E depois colocamos o resto 
do gráfico, os nós que fazem
o pré-processamento, a propagação
direta e a retropropagação
nas tarefas worker, as quais
tendem a ser mais potentes
e ter CPUs e GPUs multinúcleo.
E uma grande diferença entre
como nós fizemos as coisas
no DisBelief e no TensorFlow
é que no DisBelief, os servidores 
de parâmetros e as réplicas worker
eram dois programas 
completamente diferentes.
Eram, basicamente, dois sistemas
distribuídos fracamente acoplados

English: 
systems that had very
little in common.
And you would program them
by very different APIs.
In TensorFlow, the PS
and the worker tasks
run exactly the same code.
They are just
servers that you can
send little bits of
TensorFlow graph to,
and it will react to
those bits of graph
and execute them very quickly.
And this gives us a
lot of flexibility.
So a PS task, for
example, we could
have it use a GPU to accelerate
some of the parameter update
computations.
Or we could have the workers
store some state locally
to avoid network traffic,
to cache some of the reads.
Or we could even cut
out the PS altogether
and use direct connections
between the workers,
if we had a network that
was fast enough to deal
with that communication.
But with that said,
the old PS-worker split
has been really useful for
training a lot of our models.
And so we've developed a decent
amount of software support
around this idea.
And I'm going to show you
now some examples of how we
do that in the next few slides.
All right.
So the first idea
that works pretty well
for distributed
training, particularly

Spanish: 
débilmente acoplados
que tenían poco en común.
Y los programan con diferentes API.
En TensorFlow, los PS 
y las tareas del "trabajador"
ejecutan el mismo código.
Solo son servidores 
a los que puedes enviar
pequeños bits al gráfico TensorFlow
y reaccionará a ellos
y los ejecutará muy rápido.
Esto nos da mucha flexibilidad.
Una tarea PS, por ejemplo,
la podemos usar con un GPU
para acelerar algunas 
de las actualizaciones
de parámetros de cálculos.
O podemos hacer que trabajadores
guarde algún estado localmente
para evitar tráfico en la red,
que guarde algunas de las lecturas.
Incluso podemos retirar todo el PS
y usar conexiones directas 
entre los trabajadores
si tuviéramos una red que fuera 
lo bastante rápida para lidiar
con esa comunicación.
La antigua separación
de PS - trabajador
ha sido muy útil para entrenar 
muchos de nuestros modelos.
Por eso hemos desarrollado
una cantidad considerable
de ayuda de software
basada en esta idea.
Les daré algunos ejemplos
de cómo hacerlo
en las siguientes presentaciones.
Muy bien.
La primera idea 
que funciona muy bien

Indonesian: 
Sebenarnya keduanya merupakan
sistem distribusi dengan sedikit kesamaan.
Dan kau memprogram keduanya
dengan API yang jauh berbeda.
Di TensorFlow, PS dan worker task
berjalan dengan kode yang sama.
Keduanya hanya server tempat kau
mengirim secuil grafik TensorFlow
yang membuat sedikit reaksi
pada grafik-grafik ini
dan mengeksekusinya amat cepat.
Inilah fleksibilitas.
PS task contohnya
kita bisa memakai GPU untuk mempercepat
komputasi pembaruan parameter.
Atau buat worker menyimpan
beberapa status secara lokal
untuk menghindari kepadatan jaringan,
cache beberapa proses baca.
Bahkan menghilangkan proses PS
dengan koneksi langsung antar worker.
Punya jaringan cukup cepat
untuk memproses komunikasi seperti itu.
Tapi, pemisahan PS-worker
jadi sangat berguna untuk
melatih banyak model kami.
Karenanya kami mengembangkan banyak
dukungan software untuk kasus seperti ini.
Akan kuperlihatkan beberapa contoh
bagaimana kami melakukannya nanti.
Baik. Ide pertama yang bagus
untuk latihan terdistribusi

Korean: 
느슨하게 묶어진
두 개의 분산 체계이죠
또한 굉장히 다른 API로
프로그래밍할 겁니다
텐서플로우에서는 PS와 워커 업무가
완전히 같은 코드를 실행합니다
이들은 그저 텐서플로우 그래프로
보낼 수 있는 서버일 뿐이고
이러한 약간의 그래프에 반응할 것이며
굉장히 빨리 실행하겠죠
그리고 굉장히 많은 융통성을 줍니다
따라서 PS 업무는 예컨대
파라미터 업데이트 계산의
일부를 가속화하기 위해
GPU를 사용하도록 할 수 있죠
혹은 네트워크 트래픽을 피하기 위해
또 약간의 리드를 캐시하기 위해
워커가 일부 스테이트를
로컬로 저장하도록할 수도 있죠
또는 심지어 PS 전체를 잘라내서
워커 사이의 직접 연결을
사용할 수도 있죠
이러한 소통을 다루기에 충분히 빠른
네트워크가 있다면 말이죠
하지만 그렇기 때문에
옛날 PS 워커 분리는
저희의 많은 모델을
훈련하는 데에 아주 유용했습니다
그래서 이러한 아이디어에 대한
많은 양의 소프트웨어 지원을
개발한 것이죠
이제 다음 슬라이드 몇 장에서
이를 하는 방법에 대한
예시 몇 개를 보여드리겠습니다
좋습니다
분산 훈련의 경우에 잘 맞는
첫 번째 아이디어는

Portuguese: 
que tinham muito pouco em comum.
E você programaria eles
por diferentes APIs.
No TensorFlow, os PS e
as tarefas worker
rodam exatamente os mesmos códigos.
Eles são apenas servidores
que você pode enviar
partes de gráficos do TensorFlow
e eles reagirão a 
essas partes dos gráficos
e executá-los muito rápido.
E isso nos dá muita flexibilidade.
Uma tarefa PS, por exemplo,
nós poderíamos fazê-la utilizar
um GPU para acelerar
algumas das atualizações
de parâmetros de cálculo.
Ou poderíamos ter os workers
armazenando "estados" localmente
para evitar tráfego de rede
ou leituras de alguns caches.
Ou poderíamos até eliminar todos os PS
e usar conexões diretas entre os workers
se tivéssemos uma rede que fosse
rápida suficiente
para lidar com essa comunicação.
Dito isso, a antiga divisão PS-worker
foi muito útil para treinar 
muitos dos nossos modelos.
Pensando nisso, nós desenvolvemos 
uma quantidade razoável
de suporte para software.
Irei mostrar a vocês agora alguns 
dos exemplos de como nós fazemos isso
nos próximos slides.
Certo.
A primeira ideia que funciona muito bem
para o treinamento de distribuição

Japanese: 
非常に異なる API で
プログラムすることになります。
TensorFlow では、PS とワーカータスクは
全く同一のコードを作動します。
TensorFlow グラフを少量送ることが
できるサーバーです。
そして、それらのグラフに反応し
非常に迅速に実行します。
そして多くのフレキシビリティを
与えてくれます。
例えば PS タスクは、
パラメータアップデート算定を
加速するために GPU を
使用することができます。
また、ネットワーク通信を回避し
読み出しをキャッシュするために
ローカルにステートを保存する
ワーカーを持つことができます。
また、PS をひとまとめに
カットアウトすることもできます。
ワーカー間のダイレクトコネクションを
使うこともできます。
その情報を充分な速度で処理できる
ネットワークを持っていたらの話です。
こう述べましたが、
分断された古い PS ワーカーは
多くのモデルをトレーニングするのに
とても役に立ちます。
このアイディアに基づいて、
相当のソフトウェアサポートを開発しました。
次のスライドで、どのように実現したか
その例を紹介します。
分布したトレーニングに上手に活用できる、
アイデアの１番目に

Chinese: 
基本没有共同点
你能够通过很不一样的应用程序接口
为它们编程
在 TensorFlow 里
PS 和工作任务的
运行代码完全相同
它们只是你可以
发送一点 TensorFlow
图表的服务器
它会对图表进行反应
并快速执行
这为我们提供很大的灵活性
比如对一个 PS 任务
我们可以用一个图形处理器
来加速一些参数更新计算
或者我们可以让工作者
存储一些本地状态
防止网络堵塞，来缓存部分读取
或者我们可以总体删掉 PS
使用工作者之间的直接联系
只要我们有一个足够快的
能够处理这些交流的网络
根据上面说到的，
以前的 PS -工作者分割
对加强我们很多模型非常有用
所以我们根据这个想法，研发了
相当不错数量的软件支持
在接下来的几张幻灯片中，
我要向你们展示一些例子
说明我们是怎样做到的
好的
第一个对于加强分布
实现得很好的想法

Spanish: 
para entrenamiento distribuido,
en especial cuando un solo modelo
cabrá en una sola máquina,
es la replicación.
Así como en DisBelief,
tomamos la parte del cómputo intensivo
del modelo de entrenamiento,
la propagación y la retropropagación,
e hicimos una copia de ello
en múltiples tareas worker,
para que cada tarea funcione
en un subgrupo diferente de datos.
Es entrenamiento paralelo de datos
como lo hicimos al inicio
en el ejemplo de Inception.
La forma más fácil de lograrlo
es haciendo algo que llamaré
"replicación dentro del gráfico".
Espero que este nombre
se entienda por sí mismo
cuando yo...
O que se entienda cuando les diga
lo que hace el código.
Empezamos poniendo 
las variables en la tarea PS
como en este ejemplo.
De tal forma que estén 
en una ubicación central
que pueda ser accedida 
por todos los trabajadores.
Luego, la forma más fácil de hacer
una replicación dentro del gráfico
es separando un lote de datos de entrada
en fragmentos de igual tamaño,
hacer un bucle en las tareas worker
y usar la cadena tf.device.
para poner un subgráfico 
en cada worker

Korean: 
특히 단일 모형이
단일 머신에 맞는 경우는
복제입니다
디스빌리프에서와
마찬가지로 모델 훈련의
계산 집중적 부분인 포워드와 백드랍을
다양한 워커 업무에서 복제해서
각 업무가 데이터의
다른 부분집합에서 이뤄지도록 한 것이죠
이는 데이터 평행 훈련으로
시작할 때 인셉션 예시를
하던 것과 같은 경우죠
이를 이루는 가장 간단한 방법은
인 그래프 복제라는 것을 하는 겁니다
이 이름을 지은 이유는
이름에서 설명이 되길
바라던 것이죠
어쩌면 코드를 말씀 드리면
설명이 되겠죠
PS 업무에서 변수를
넣는 것으로 시작합니다
이전 예시와 같죠
이는 변수를 중앙위치에 놓아서
모든 워커가 접근할 수
있도록 하기 위한 것이죠
그리고 나서 인 그래프 복제를
하는 가장 쉬운 방법은
인풋 데이터 베치를 그냥
같은 크기의 덩어리로
만들어서 워커 업무에
루프하도록 만들고
여기 이 tf.device
스트링을 사용하는 겁니다

English: 
when a single model will
fit in a single machine,
is replication.
So just like in DisBelief, we
take the compute-intensive part
of the model training, the
forwards and the backprop,
and we make a copy of it
in multiple worker tasks,
so that each task works on a
different subset of the data.
This is data parallel
training, like we
were doing for that Inception
example back at the start.
And the simplest thing,
simplest way we can achieve this
is by doing something I'm going
to call in-graph replication.
The reason for this name
will hopefully become
self-explanatory when I--
or maybe just explanatory when
I tell you what the code does.
We start by putting the
variables on a PS task,
like the earlier example.
And this is just so that
they're in a central location
that they can be accessed
by all of the workers.
And then the easiest way to
do the in-graph replication
is just to split up
a batch of input data
into equal-sized chunks,
loop over the worker tasks,
and use this
tf.device string here

Chinese: 
是重复
特别是一个模型
能和一个机器匹配的时候
就像在 DisBelief，
我们提取加强模型的
计算集中的部分，也就是前进和支持
我们在多个工作任务制作了它的副本
那么每一个任务都处理
数据的不同子集
这是数据平行训练
就像我们一开始在
Inception 例子里面做的
我们可以实现这个的最简单的方法
就是通过我称之为表内复制的方法
叫这个名字的原因
就希望你们能顾名思义
或者当我告诉你们代码的作用，
你们能理解这个名字
我们开始时在 PS 任务加入变量
就像之前的例子
这就是为了它们存在于中央地址
它们可以被所有工作任务引用
做表内复制的最简单方法
就是把一批输入数据分开为
等量数据块，在工作任务中循环
在这里使用 tf.device 字符串

Indonesian: 
khususnya jika satu model cukup
diproses satu mesin,
adalah replikasi.
Seperti di DisBelief, kami menghapus
bagian komputasi intensif latihan model
forwards serta backprop
dan membuat salinannya
di banyak task worker
sehingga tiap task memproses
subset data yang berbeda.
Inilah latihan data secara paralel
seperti contoh Inception kita
di awal tadi.
Cara paling sederhana yaitu
memakai yang kusebut dengan
in-graph replication.
Latar belakang nama ini akan
mudah ditebak ketika aku--
atau akan jelas ketika kuceritakan
apa yang kode ini lakukan.
Kita mulai dengan
menaruh variabel di PS task
seperti contoh tadi.
Ini untuk menempatkan varibel
di lokasi sentral
sehingga mudah diakses oleh semua worker.
Cara termudah untuk melakukan
in-graph replication yaitu
bagi data input menjadi
dua bagian yang sama
putarkan di task worker
dan gunakan tf.device string ini

Japanese: 
シングルモデルがシングルマシーンに
適合する場合になりますが、
レプリケーションが挙げられます。
DisBelief 内でモデルトレーニングの
集約算定パートとフォワード、
そしてそバックプロパゲーションを取り、
マルチワーカータスク内にコピーします。
すると、それぞれのタスクはデータの
異なる部分集合に作用します。
これはデータパラレルトレーニングで、
スタート時に、インセプションサンプル
バック用に行なうのと同じものです。
そして最もシンプルなこと、
達成できる最もシンプルな方法は
「イン・グラフ・レプリケーション」と
私が呼んでいるものです。
このネーミングの理由は、名前自体が
その機能を表現することを願って付けました。
もしくは、コードとは何かを説明する時に
その意味を分かってもらえると思います。
前述のサンプルのように、
PS タスクに変数記号を入力します。
ワーカー全てを使ってアクセスできる
センターロケーションに存在します。
イン・グラフレプリケーションの
最も簡単な方法は、
インプットデータを分割して、
イコールサイズ部分に入れる方法です。
ワーカータスクの周辺をループして、
ここにある tf.device 列を使って

Portuguese: 
especialmente quando apenas um
modelo irá servir em uma única máquina
é a replicação.
Então, assim como no DisBelief,
nós pegamos a parte de computação intensa
do modelo de treinamento,
a propagação direta e a retropropagação
e fazemos uma cópia disso
em diversas tarefas worker
para que cada tarefa trabalhe em um
subconjunto diferente dos dados.
Isto é o treinamento de dados paralelo
como fizemos no exemplo inicial.
E a coisa mais fácil, a maneira 
mais fácil de conseguirmos isso
é fazendo algo que chamarei
de "replicação em gráfico".
Com sorte, o motivo para esse nome
será auto-explicativo quando eu...
ou talvez apenas explicativo,
quando eu contar-lhes o que o código faz.
Começamos colocando
as variáveis na tarefa PS
como no exemplo anterior.
E isso é apenas para que
eles fiquem numa localização central
que possa ser acessada por
todos os workers.
E a forma mais fácil de fazer
a replicação em gráfico
é apenas dividir um lote
de dados de entrada
em partes de tamanhos iguais,
repetir as tarefas worker
e utilizar esta série tf.device aqui
para colocar um "subgráfico"
em cada worker para computar
um resultado parcial.

English: 
to put a subgraph on each worker
to compute a partial result.
And then finally,
we combine together
all of the partial
results into a single loss
value that we optimize by
using a standard TensorFlow
optimizer.
And sure enough, when you
tell it to compute the loss,
TensorFlow will split up the
graph across the workers,
and it will run across these
worker tasks and the PS all in
parallel.
So in-graph replication
is pretty easy to achieve.
It's not a big modification
to your existing programs.
And it works pretty well up
to a small number of replicas.
If you want to replicate
across all the GPUs
in a single machine, then
maybe in-graph replication
is the way to go.
But one of the
things we found out
when we tried to apply this
technique to a large model
like Inception_V3, and
we tried to scale it up
to a couple of
hundred machines, was
that this graph gets really
big if you have to materialize
all the replicas in it.
And the client gets
bogged down trying
to coordinate the computation
and to build this whole graph.
And that's why we came up with
an alternative approach, which
is called between-graph
replication.

Spanish: 
para computar un resultado parcial.
Finalmente, combinamos 
todos los resultados parciales
en uno solo valor loss
que optimizamos
usando un optimizador estándar 
de TensorFlow.
Seguro que cuando le digas
que compute loss
TensorFlow separará el gráfico 
a través de los trabajadores
y la ejecutará a través 
de las tareas worker y de PS
todo en paralelo.
En la replicación dentro 
del gráfico es fácil de hacer.
No es un gran cambio 
para tus programas existentes.
Y funciona muy bien
para un número pequeño de réplicas.
Si quieres replicar 
a través de todos los GPU
en una sola máquina, entonces 
la replicación dentro del gráfico
es la forma de hacerlo.
Pero encontramos que
cuando intentamos aplicar 
esta técnica a un modelo grande
como Inception_v3, cuando intentamos
ampliarlo a unas cientos de máquinas,
fue que este gráfico
se vuelve realmente grande
si tienes que materializar 
todas las réplicas en ella..
El cliente se traba 
intentando coordinar el cómputo
y de construir todo el gráfico.
Por eso inventamos un enfoque alternativo
que se llama 
"replicación dentro del gráfico".

Portuguese: 
E, finalmente, nós combinamos
todos os resultados parciais
em um único valor de perda
o qual nós otimizamos utilizando
um otimizador padrão TensorFlow.
De fato, quando você
pede para computar as perdas
o TensorFlow dividirá
o gráfico entre os workers
e irá rodar entre estas tarefas
workerse PS em paralelo.
Replicação em gráfico 
é muito fácil de realizar.
Não é uma grande mudança
no seu programa já existente.
E funciona muito bem com 
pequenas quantidade de réplicas.
Se você quiser replicar através
de todos os GPUs
em uma única máquina, talvez a
"replicação em gráfico" seja a solução.
Mas uma das coisas que descobrimos
quando tentamos aplicar
essa técnica a um modelo maior
como o Inception_V3, e tentamos aumentar
para algumas centenas de máquinas
esse gráfico fica muito grande
se você tiver que materializar
todas as réplicas nele.
E o cliente fica preso tentando
coordenar a computação
e construir este gráfico todo.
E é por isso que criamos um
método alternativo
o qual se chama 
"replicação entre gráficos".

Japanese: 
部分的な結果を算定するために、
サブグラフをそれぞれのワーカーに入れます。
標準 TensorFlow オプティマイザーを使い
最適化したシングルロスバリューの中に、
最終的に、部分的結果を結合させます。
確かに、 ロスを算定するよう指示した場合
TensorFlow はワーカーを通じて
グラフを分割し、
並行して、これらのワーカータスクと
PS すべてを通じて作動します。
イン・グラフレプリケーションは
かなり容易に達成できます。
既存プログラムに対する
大幅な修正ではありません。
少数のレプリカに至るまで、
適切に作動します。
GPU すべてを通じて、
シングルマシーン内に複製したい場合は
イン・グラフレプリケーションが
適切だと思います。
Inception V3 のような大型モデルに
このテクニックを適用させたい時、
また数百台のマシーンに増幅させたい時、
そこに全てのレプリカを
具現化しなければならない時、
このグラフはかなり大きくなります。
クライアントは行き詰まって
算定を調整しようとし、
このグラフ全体を構築しようとします。
そして代替アプローチというものに
辿り着きました。
ビトウィーン・グラフレプリケーションと
呼ばれるものです。

Chinese: 
在每个工作任务加入子图表
计算部分结果
最后，我们把所有
部分结果合成一个损耗值
我们可以用标准 TensorFlow 优化器
进行优化
当然，当你命令它计算损耗值时
TensorFlow 将会把图表分给工作区
他会同时运行这些工作任务
和 PS 任务
所以要实现表内复制非常简单
不需要对你已有的程序进行很大的修改
对于少量副本它都能运行得很好
假如你想要在一台机器里面
复制图形处理器的所有数据
也许表内复制
是一个好方法
但是当我们把这个技术
应用在大的模型里时
比如 Inception_V3，
我们把它扩展到
几百台机器的时候，
我们发现了一件事情
假如你要实现里面的所有副本
这个图表会变得很大
客户不能协调计算
和建立起整个图表
这就是我们提出另一个方法的原因
这被称为跨表复制

Indonesian: 
untuk menempatkan sub grafik di tiap
worker untuk penghitungan hasil parsial.
Terakhir, kita satukan semua
hasil parsial menjadi satu nilai loss
yang kami optimasi dengan
optimizer TensorFlow standar.
Tentu saja, ketika kau minta
menghitung loss
TensorFlow akan membagi grafik
ke semua worker
dan menjalankan semua
task worker dan PS secara paralel.
In-graph replication mudah diperoleh.
Modifikasi yang tak besar untuk
program yang sudah ada.
Juga bekerja sangat baik hingga
sejumlah kecil replika.
Jika kau ingin replikasi pada
semua GPU dalam satu mesin,
mungkin in-graph replication adalah
salah satu caranya.
Tapi satu hal yang kami temukan
ketika coba aplikasikan
teknik ini untuk model yang lebih besar
seperti Inception_V3 dan
meningkatkannya jadi ribuan mesin
yaitu grafik ini jadi sangat besar
jika perlu mematerialisasi
replika di dalamnya.
Dan klien jadi menyerah untuk mencoba
mengkordinasi komputasinya
dan membangun keseluruhan grafiknya.
Karena itu kami beri
pendekatan alternatif
yang disebut between-graph replication.

Korean: 
부분 결과를 계산하기 위해 각 워커에
대한 부분 그래프를 넣기 위해서이죠
마지막으로 모든 부분 결과를
단일 손실값으로 함께 묶고
표준 센서플로우 최적화를
사용해서 최적화하는 겁니다
.
물론 손실을 계산하라고 말하면
텐서플로우가 워커의 그래프를 나누고
이러한 워커 업무와 PS 모두를 동시에
실행하겠죠
인 그래프 복제는 하기 쉽습니다
현존하는 프로그램을
많이 고치는 것이 아니죠
또한 적은 수의 복제까지는
작동이 잘 됩니다
단일 머신에서 모든
GPU에 걸쳐 복제하고 싶다면
아마 인 그래프 복제가
좋은 방법일 겁니다
.
하지만 저희가 이 기술을
인셉션 V3와 같은 큰 모델에
적용하려고 했을 때
그리고 수백가지의 머신으로
확대하려고 시도했을 때
그 안의 모든 복제를
물질화해야 한다면
이 그래프가 정말
커진다는 사실을 발견했습니다
.
클라이언트는 계산을 조정하고
이 그래프 전체를 만들기 위해
노력하느라 허우적되게 된 거죠
저희가 대안적 접근법을
가져온 것도 이 때문입니다
바로 그룹간 복제라고 불리는 겁니다

Spanish: 
Actualmente lo usamos más 
de forma interna.
Lo recomendamos en Cloud ML.
También es lo que 
nuestras API de alto nivel
tienen diseñado hacer.
Si han escrito un programa NPI, 
un concepto similar debe ser
el de "replicación entre gáficos".
En lugar de ejecutar un programa 
de cliente todo potencia
que sepa todo sobre réplicas,
ejecutamos un cliente más pequeño
en cada tarea.
Y ese programa de cliente
realiza el gráfico
para una réplica del modelo.
Este programa de cliente
hace básicamente lo mismo
con una diferencia clave
en la disposición de dispositivo.
Toma parte del no-parámetro del gráfico
y lo pone en los dispositivos locales
o en los dispositivos que son locales
a esa réplica de trabajador.
Cuando lo ejecutan,
cada programa
ejecuta su gráfico más pequeño
de forma independiente
y son mapeados
en diferentes subgrupos
de los dispositivos que intersectan
la tarea PS en medio.
Hay un truco 
que debería explicar
en pro de la total divulgación.
Cada réplica coloca sus variables
en la misma tarea PS.
Cuando por defecto la ejecutas 
en el modo distribuido,

Chinese: 
这是我们内部用得最多的
这就是我们在 Cloud ML 里
建议的
也是我们的高级的应用程序接口
设计来实现的事情
假如你曾经写过一个 NPI 程序
表间复制应该是一个熟悉的概念
我们不运行一个很强大的客户程序
它了解所有的工作区副本
我们在每个任务运行一个更小的客户程序
建立一个客户程序
之针对一个模型副本
这个客户程序做的是
一样的事情，只是在
设备放置上有一个主要差别
它使用的是图表里的非参数部分
它把数据放到本地设备里
或者是工作副本的本地设备
现在当你运行它的时候
每一个程序都在独立运行它更小的图标
它们能追踪到设备的不同子集
在 PS 任务中间交集运算
这听起来很神奇
我应该要解释一下
为了全面披露信息
每一个副本把它的变量
放在同一个 PS 任务中
当你运行默认分布模式时
每两个在同一个设备上创建了

Portuguese: 
No momento, isso é o que nós 
mais usamos internamente.
É o que recomendamos no Cloud ML.
E é também o que nossos APIs
de alto nível foram projetados para fazer.
Se você já escreveu algum programa NPI
a "replicação entre gráficos" 
deve ser um conceito familiar.
Então, em vez de rodar 
um programa poderoso de cliente
que sabe tudo sobre as réplicas worker
nós rodamos um programa 
de cliente menor para cada tarefa.
E este programa de cliente
apenas cria o gráfico
para uma única réplica de um modelo.
E este programa de cliente
está, essencialmente
fazendo a mesma coisa,
com apenas uma diferença chave
na posição do aparelho.
Ele pega a parte
não paramétrica do gráfico
e a coloca na implantação do dispositivo
ou nos aparelhos que são locais
para aquela réplica worker.
Então agora, quando você
rodá-lo, cada programa
está rodando o seu gráfico
menor independentemente
e eles são mapeados
em diferentes subconjuntos
dos dispositivos, os quais cruzam
com a tarefa PS no meio.
Tem um truque especial aqui
o qual eu provavelmente 
deveria explicar para fazer
uma exposição completa.
Cada réplica coloca as 
suas variáveis na mesma tarefa PS.
E quando estamos rodando 
no modo distribuído, por padrão
dois clientes quaisquer 
que criam a variável

Korean: 
현재 내부적으로 저희가 가장 많이 사용하는 것이고
클라우드 ML에서도 추천하고 있죠
또한 저희 고등 API가 사용하도록 설계된
것이기도 합니다
NPI 프로그램을 써 본 적 있으시다면
그래프 간 복제가
낯익은 개념일 겁니다
모든 워커 복제에 대해
알고 있는 하나의
완전히 강력한 클라이언트
프로그램을 실행하는 대신에
각 업무에서 더 작은
클라이언트 프로그램을 실행하고
그 클라리언트 프로그램은
그 모델을 위한
단일 복제의 그래프를 만들어 내는 거죠
클라이언트 프로그램은
궁극적으로 같은 일을
하지만 기기 위치에서
핵심적인 차이점이 있죠
.
그래프의 비파라미터 부분을 가지고
로컬 기기나 그 워커 복제에 대해
로컬인 기기에 넣는 거죠
이제 실행시키면 각 프로그램이
그 더 작은 그래프를
독립적으로 실행시키고
PS 업무에서 중간에서 교차하는
기기의 다른 부분으로 맵핑되는 거죠
여기 약간의 마술이 있죠
아마 제가 완전히 밝히기 위해
설명해야겠죠
각 복제품은 같은 PS 업무에
그것의 변수를 놓습니다
그리고 기본값인 분산 모드로 실행할 때
같은 기기에서 같은 이름을
가진 변수를 만드는

Japanese: 
一般には内部で使用しています。
これは Cloud ML 内で
推奨しているものです。
ハイレベル API に求められている
役割でもあります。
これまでに NPI プログラムを
入力していれば
ビトウィーン・グラフレプリケーションは
お馴染みのコンセプトだと思います。
ワーカーレプリカ全てを理解している、
オール・パワフルクライアントプログラムを
作動する代わりに、
それぞれのタスク上で、より小さい
クライアントプログラムを作動させます。
そのクライアントプログラムは、モデルの
シングルレプリカ用にグラフを構築します。
このクライアントプログラムは、
基本的にはデバイス配置内で
異なる１つのキーを使って、
同じ動作を行ないます。
ですから、ノン・パラメータグラフ部分を取り
それをローカルデバイスに置きます。
もしくは、そのワーカーが複製する
ローカルのデバイスに置きます。
では、作動させるとそれぞれのプログラムが
より小さなグラフを独自に作動させます。
中間の PS タスク上で交わるデバイスの
異なる部分集合の上に配置します。
打ち明け話の観点から、お話ししたい
マジックがあります。
それぞれのレプリカは同一の PS タスク上で
各々の変数記号を配置します。
分布モードで作動させていると、

English: 
This is currently what
we use most internally.
It's what we
recommend in Cloud ML.
And it's also what
our high-level APIs
are designed to do.
So if you've ever
written an NPI program,
between-graph replication should
be a kind of familiar concept.
So instead of running one
all-powerful client program
that knows about all
of the worker replicas,
we run a smaller client
program on each task.
And that client
program just builds up
the graph for a single
replica of the model.
And this client
program is essentially
doing the same thing, with one
key difference in the device
placement.
So it takes kind of the
non-parameter part of the graph
and it puts it on
the local devices,
or the devices that are
local to that worker replica.
And so now when you
run it, each program
is running its smaller
graph independently,
and they get mapped
to different subsets
of the devices that intersect
on the PS task in the middle.
There's a little bit
of magic here which
I should probably
explain, in the interest
of full disclosure.
So each replica places its
variables on the same PS task.
And when you're running in
distributed mode, by default,
any two clients that
create a variable

Indonesian: 
Kami pakai dan rekomendasikan di Cloud ML.
Ini juga apa yang API level tinggi kami
rancang untuk dikerjakan.
Jika kau pernah menulis program NPI
between-graph replication
adalah konsep yang tak asing.
Daripada menjalankan
satu program klien canggih
yang tahu tentang semua replika worker
kami menjalankan
program klien kecil bagi tiap task.
Program klien ini juga membuat grafik
untuk satu replika model.
Kerja program klien dasarnya sama
tapi satu bedanya di device placement.
Jadi butuh seperti bagian
non-parameter grafik,
ditempatkan di perangkat lokal
atau perangkat yang tersedia lokal
bagi replika worker.
Ketika dijalankan,
tiap program menjalankan
grafik yang lebih kecil secara independen
dan terpetakan ke subset
perangkat yang berbeda
yang memotong task PS tepat di tengah.
Di sini agak ajaib,
mungkin harus kujelaskan
sebagai informasi bagi semuanya.
Tiap replika menempatkan variabelnya
di task PS yang sama.
Ketika mode terdistribusi di jalankan,
secara default, dua klien yang

Japanese: 
デフォルトで、同一のデバイスに同一の名前で
変数記号を作る２つのクライアントが、
その変数記号用に同一の
バックアップ記憶装置をシェアします。
複製トレーニングを実行しているのであれば、
それで問題ありません。
その勾配を適用している時に
タスク 0 からのアップデートであれば、
タスク 1 そして逆方向でも
可視化することができます。
だから、より速くトレーニングできます。
しかし、これは別の問題をもたらします。
変数記号を配置する場所を
どのように決めるのかについてです。
これまで、Job PS タスク 0 上に
変数記号を置いてきました。
そして変数記号用に陽関数表示の
デバイス列を設定してきました。
ある特定のロケーションに
オプス全てを配置するのであれば、
デバイス列は全く問題ありません。
しかし、頻繁に PS タスクを
複数持ちたいのであれば
また変数記号の更新作業を分布したい場合、
またワーカーにネットワークロードを渡して
分布したい場合などです。
tf.device にデバイス列を
パスする代わりに
デバイス機能をパスすることも可能です。
より複雑で、より洗練された配置計画を
構築するためにこれらを使います。
デバイス機能は非常に一般的で
またパワフルなので、

Indonesian: 
membuat variabel dengan
nama yang sama pada perangkat yang sama
akan berbagi penyimpanan variabel itu.
Jika melakukan latihan
replikasi, inilah yang kau butuhkan.
Perbaruan dari task 0,
ketika gradien diaplikasikan
akan terlihat di task 1 dan sebaliknya.
Jadi latihan akan lebih cepat.
Tapi ada isu lain yang muncul
bagaimana kau memutuskan
penempatan variabel?
Selama ini, aku hanya
menempatkannya di jobPS task 0
dan menyetelnya sebagai device string
yang eksplisit bagi variabelnya.
Tapi device string berguna ketika
kau ingin menempatkan semua ops
pada satu lokasi tertentu.
Tapi kadang kau ingin ada
lebih dari satu task PS
misal kau ingin mendistribusikan
kerja pembaruan variabel
atau mendistribusikan beban jaringan untuk
mendapatkan hasilnya untuk worker.
Daripada menyerahkan
device string ke tf.device
kau juga bisa memakai device function.
Kami menggunakannya untuk
membangun strategi placement
yang lebih kompleks dan canggih.
Device function cukup umum
dan sangat efektif.

Spanish: 
cualquier par de clientes 
que crean una variable
con el mismo nombre,
en el mismo dispositivo
compartirá el mismo almacenamiento 
de respaldo para esa variable.
Si hacen entrenamiento replicado,
es exactamente lo que buscan.
Las actualizaciones de la tarea 0,
cuando aplica sus gradientes
serán visibles en la tarea 1 y viceversa.
Entrenarán más rápido.
Pero esto nos lleva a otra cuestión.
¿Cómo decidimos
dónde poner las variables?
Hasta ahora las he puesto
en job:ps/task:0
y lo establezco como
la cadena de dispositivo explícita
para las variables.
Pero las cadenas del dispositivo
están bien si quieres poner
todas tus ops en un lugar en específico.
Pero a menudo quieres hacer cosas
como tener más de una tarea PS.
Es decir, si quieres distribuir
el trabajo de actualización de variables
o distribuir la carga de la red 
de llevarlos a los trabajadores.
En lugar de pasar 
un cadena device a tf.device
también puedes pasar
función device.
Solíamos hacer estrategias de disposición
más complicadas, más sofisticadas.
Las funciones device
son muy generales y poderosas.
Básicamente te dejan personalizar

Portuguese: 
com o mesmo nome, no mesmo dispositivo
irão compartilhar o mesmo armazenamento 
de apoio para aquela variável.
E se você estiver
fazendo um treinamento de réplica
isso é exatamente o que você quer.
As atualizações da task 0,
quando está aplicando seus gradientes
estará visível na task 1 e vice-versa.
Então você treinará mais rápido.
Mas isso nos leva a outro problema
que é como decidir onde
colocar as variáveis?
Até agora eu as coloquei
no jobPS task 0
e configurei como um
dispositivo em série explícito
para as variáveis.
Mas, aparelhos em série, vocês sabem
são muito bons se você 
quiser colocar todas as suas opções
em um lugar específico.
Mas, muitas vezes, você quer fazer coisas
como ter mais que uma tarefa PS,
digamos que você queira distribuir
a tarefa de atualizar as variáveis
ou distribuir a carga de rede
na busca deles pelos workers.
Então, em vez de passar
um dispositivo em série para tf.device
você também pode passar 
uma função de dispositivo.
E usamos isso para criar estratégias 
de implantação mais complicadas
mais sofisticadas.
Funções de dispositivo são,
no geral, muito poderosas.
Elas lhe permitem, basicamente,
personalizar a implantação

Chinese: 
有同样名字的变量的客户
会分享这个变量的同样内存
假如你在进行复制训练
这就是你想要的
当任务 0 的更新适用它的梯度的时候
它在任务 1 是可见的，反之亦然
所以你能运行得更快
但这为我们带来了另一个问题
你要怎么决定存放变量的地址呢？
到现在我把它们放在
jobPS task 0
把它设定为变量的
详细设备字符串
但是设备字符串是很好的
尤其当你想要把你的所有 ops
放在一个特定地址的时候
但你有时想要实现
不止一个 PS 任务
比如
你们是否想要分配更新变量的工作
或者分配工作区抓取它们的
网络负载
你不用把设备字符串传递到
tf.device
你可以使用一个设备函数
我们使用这个来创建更多复杂巧妙的
放置策略
设备函数是总体的，非常强大
它让你自定义图表里

English: 
with the same name
on the same device
will share the same backing
storage for that variable.
And if you're doing
replicated training,
this is exactly what you want.
So the updates from task 0, when
it's applying its gradients,
will be visible in
task 1, and vice versa.
So you'll train faster.
But this brings us
to another issue,
which is how do you decide
where to put the variables?
So far, I've just been
putting them on jobPS task 0
and setting that as
the explicit device
string for the variables.
But device strings,
you know, they're
all very good if you want
to put all of your ops
in one particular location.
But you often want to
do things like have
more than one PS task, say
if you want to distribute
the work of updating
the variables
or distribute the network
load of fetching them
to the workers.
So instead of passing a
device string to tf.device,
you can also pass
a device function.
And we use these to build more
complicated, more sophisticated
placement strategies.
Device functions are pretty
general, very powerful.
They let you basically
customize the placement

Korean: 
어떠한 두 고객이더라도
그 변수에 대한 같은 저장소를
공유하게 되는 거죠
여러분들이 복제된 훈련을 한다면
이것이 바로 여러분들이 원하는 일이죠
업무 0로부터의 업데이트는
기울기를 적용할 때
업무 1에서 보일 것이고
반대도 그렇겠죠
따라서 더 빨리 훈련할 겁니다
하지만 이는 또다른 문제를 가져오죠
즉 변수를 어디에 넣을지
어떻게 결정할까요?
지금까지 전 그냥
jobPS 업무 0에 넣어왔고
변수를 위한 외현적 기기 스트링으로
설정했죠
하지만 기기 스트링은
여러분이 특정 한 지역에서
운영을 넣고 싶다면
모두 잘 되겠죠
하지만 여러분이
하나 이상의 PS 업무를
종종 원한다면 즉 변수를
업데이트 하는 작업을
분산하고 싶다거나
워커로 페치하는 네트워크 로드를
분산하고 싶다면 말이죠
따라서 기기 스트링을
tf.device로 패스하는 대신에
기기 기능을 패스할 수도 있죠
이를 더 복잡하고
섬세한 위치 전략을 만드는 데에
사용하면 되죠
기기 기능은 아주
일반적이고 매우 강력합니다
기본적으로 그래프에서
각 단일 운영의 위치를

Chinese: 
每一个 ops 的放置
这让它们在使用时有一点复杂
我们已经做了的事情之一是
提供一些已写好的设备函数
让你的生活更加轻松
它们中最简单的被称为
tf_train_replica_device_setter
它的作用是向 PS 任务
循环分配变量，就像它们创建时一样
这个设备函数的优点是
你可以把你的整个建模代码
用这个模块包起来
它只会影响到变量，
把它们放在 PS 任务里
其余图表里的 ops 会进入工作区
所以当你使用表间复制的时候
它都为你做好了
所以对于这个程序，它会把设备
分配给参数，就像它们被创建时一样
第一个加权矩阵会进入任务 0
一个偏权向量会进入任务 1
第二个加权矩阵在任务 2
接下来第二个偏权向量回到任务 0
对于这些变量来说，这明显
不是一个最优的平衡荷载
对于内存使用
和要更新这些变量要做的工作来说
也是如此
想象一下，假如我们这里
只有两个 PS 任务

Indonesian: 
Membuatmu mampu menyesuaikan placement
tiap op pada grafik.
Ini membuatnya agak sulit digunakan.
Jadi hal yang kami lakukan adalah
menyediakan sejumlah device function
sehingga pekerjaanmu sedikit lebih mudah.
Yang paling sedernana ialah
tf_train_replica_device_setter.
Tugasnya yaitu menugaskan variabel
ke task PS dengan cara round-robin
ketika mereka dibuat.
Bagusnya device function ini yaitu
kau bisa membungkus seluruh
kode model dengan blok ini.
Efeknya hanya pada variabel pada task PS.
Sisa operasi grafik akan diproses worker.
Jika lakukan between-graph replication,
inilah jawabannya.
Untuk program ini,
device function akan menugaskan perangkat
ke parameter saat dibuat.
Matrik pembobotan pertama
akan jatuh pada task 0.
Vektor bias akan jatuh pada task 1.
Pembobotan kedua akan ada di task 2.
Lalu bias kedua akan kembali ke task 0.
Jelas ini bukan pembobotan
yang seimbang bagi variabel ini
begitu halnya dengan penggunaaan memori
atau kerja yang diperlukan
untuk memperbarui variabel ini.
Jika kita hanya punya dua task PS--

Japanese: 
グラフ内で各々のシングル OP 配置を
基本的にカスタマイズすることができます。
多少、扱いにくい印象を与えます。
そこで取り組んだのが、
より扱いやすくなるように、
Pre-canned デバイス機能を付けました。
tf_train_replica_device_setter が
最も簡単な呼び名になります。
その役割は、変数記号が作られたように
回状型の PS タスクに
変数記号を割り当てることです。
このデバイス機能の魅力の１つは、
このブロック内にモデル構築コード全体を
ラップするだけという事です。
変数記号に影響を与え、
これらを PS タスクに配置します。
グラフ内のオプスの残りは、
ワーカー上に行きます。
ビトイーン・グラフレプリケーションを
実行していれば、
これらすべてに配慮が行き届きます。
このプログラムに関しては、
パラメータが作られたように
パラメータに
デバイスが割り当てられます。
１番目のウェイト配列は、
タスク 0 へ向かいます。
バイアスベクトルは、
タスク 1 へ向かいます。
２番目のウェイトは、
タスク 2 へ向かいます。
そして２番目のバイアスは、
タスク 0 へ戻ります。
これらの変数記号のための
最適なバランス負荷ではなく、
メモリー処理のたぐいでもなく、
これらの変数記号の更新のために行なわれる
作業量でもありません。
ここにはたった２つしか
PS タスクがありません。

Portuguese: 
de cada operação no gráfico.
Isso os faz um pouco difícil de usar.
Então uma das coisas que fizemos
foi fornecer funções 
de aparelhos pré-elaboradas
para facilitar a vida de vocês.
E o mais simples desses é chamado de
tf_train_replica_device_setter.
A sua função é designar variáveis
para tarefas PS, pelo método 
Round-Robin, assim que são criadas.
Uma coisa legal 
sobre essa função de aparelho
é que você pode envolver todo 
o seu código de criação modelo nele
com bloco.
Irá apenas afetar as variáveis,
coloque-as nas tarefas PS.
E o resto das suas operações
no gráfico irão no worker.
Então, se você está fazendo 
a "replicação entre gráficos"
isso cuidará de tudo para você.
Então, para este programa,
ele irá atribuir dispositivos
para os parâmetros que vão sendo criados.
Então, a primeira matriz
de ponderação irá na task 0.
O vetor oblíquo irá na task 1.
A segunda ponderação na task 2.
E então, o segundo viés 
de volta na task 0.
Isso não é, obviamente,
um balanceamento de carga ideal
para estas variáveis, tampouco
em termos de uso de memória
ou a quantidade de trabalho
que seria necessário para atualizar
essas variáveis.

English: 
of every single op in the graph.
That makes them a little
bit tricky to use.
So one of the
things we've done is
to provide a few
pre-canned device functions
to make your life a bit easier.
And the simplest
of these is called
tf_train_replica_device_setter.
And its job is to
assign variables
to PS tasks in a round-robin
fashion as they're created.
One nice thing about
this device function
is you can just wrap your
entire model building
code in this with block.
It only affects the variables,
puts them on PS tasks.
And the rest of your ops in
the graph will go on a worker.
So if you're doing
between-graph replication,
this takes care
of it all for you.
So for this program,
it will assign devices
to the parameters
as they're created.
So the first weight
matrix will go on task 0.
A bias vector will go on task 1.
The second weight's on task 2.
And then the second
bias is back on task 0.
This is obviously not
an optimal balanced load
for these variables, neither
in terms of the memory usage
or the amount of work
that would need to be
done to update these variables.
And just think, if we only
had two PS tasks here--

Korean: 
맞춤화할 수 있게 해주죠
이 때문에 사용하기
까다로울 수도 있습니다
그래서 저희가 한 일은
여러분의 삶을 쉽게 만들어
드리기 위해 미리 만들어진
기기 기능을 약간 제공한 것입니다
그리고 이 중 가장 간단한 것은
tf_train_replica_device_setter이죠
이것이 하는 일은 이들이 만들어지면
라운드 로빈 방식으로
PS 업무에 변수를 할당하는 겁니다
이 기기 기능의 좋은 점은
이 블락으로 여기에
전체 모델 빌딩 코드를
적으면 된다는 것이죠
변수에만 영향을 미치고
변수는 PS 업무에 넣는 겁니다
그래프에서의 나머지
운영은 워커에게 가겠죠
따라서 그래프간 복제를 하신다면
이것이 전부 해결해 줄 겁니다
이 프로그램의 경우 만들면서
파라미터에 기기를 할당할 겁니다
첫번째 무게 행렬은 업무 0에 가겠죠
편향 벡터는 업무 1에 갈 겁니다
두 번째 무게는 업무 2에 있고
두 번째 편향은 다시
업무 0으로 돌아가죠
이는 분명 이 변수들을 위해
최상의 균형잡힌 부하량은 아니죠
메모리 사용이나 이 변수를
업데이트 하기 위해 필요한
작업 양에 있어서 말이죠
두 개의 PS 업무만 있다면 말이죠

Spanish: 
el lugar de cada op en el gráfico.
Eso las hace un poco complicado de usar.
Por eso, una de las cosas que hicimos
es darles funciones device preelaboradas
para hacerles la vida más fácil.
La más sencilla se llama
tf_train_replica_device_setter.
Su trabajo es asignar variables
a las tareas PS en forma circular
mientras se crean.
Una cosa agradable de esta función
es que pueden abarcar toda 
la elaboración de su código modelo
en este bloque with.
Solo afecta las variables.
Las pone en tareas PS.
El resto de sus ops en la gráfica 
irán en un worker.
Si hacen replicación entre gráficos,
esto se hace cargo de todo por ti.
Para este programa, 
asignará dispositivos a los parámetros
mientras son creados.
La primera matriz irá en task 0.
Un vector sesgado irá en task 1.
El segundo irá a task 2.
Luego, el segundo sesgo regresa a task0.
Obviamente, esta no es 
una carga balanceada óptima
para estas variables 
ni en términos de uso de memoria
ni de la cantidad de trabajo
que necesita hacerse
para actualizar estas variables.
Piensa que si solo 
tuviéramos dos tareas PS...

English: 
I guess I should have
drawn a diagram--
we'd end up with an even worse
case, because all the weights
would be on task 0, and all the
biases would be on the other.
We'd have an even bigger
imbalance between those tasks.
So clearly, we can
do better here.
And one of the ways that we've
provided to achieve a more
balanced load is to use
something called a load
balancing strategy.
And this is an optional argument
to the replica device setter.
Right now we only have, I think,
a simple greedy strategy that
does a kind of
online bin packing
based on the number of
bytes in your parameters.
And it leads to this
more balanced outcome.
Each of the weight matrices
is put on a separate PS task,
and the biases get packed
together on task 1.
It's a lot more balanced,
and this should give you
a lot better performance.
And so far, I've only talked
about relatively small
variables that all
fit in a single task.
But what about these
outrageously large model
parameters, things like
the large embeddings
that might be tens
of gigabytes in size?
Well, to deal with
these, we have
something called partitioners.
They do exactly what it
sounds like they would do.

Spanish: 
Creo que debí dibujar un diagrama...
...terminaríamos peor
porque todos los de importancia
estarían en la tarea 0
y todos los sesgos en otro.
Tendríamos incluso un mayor 
desbalance entre esas tareas.
Claramente podemos hacerlo mejor.
Una forma que ofrecemos para lograr
una carga más balanceada 
es usar algo llamado
LoadBalancingStrategy.
Es un argumento opcional
a replica_device_setter.
Ahora mismo, creo que solo tenemos
una simple estrategia ambiciosa
que hace un tipo de estrategia 
de empaquetamiento en línea
basado en el número de bytes 
en tus parámetros.
Y lleva a este resultado más balanceado.
Cada matriz de peso se pone 
en una tarea PS por separado
y cada margen de error
se empaca en task 1.
Es más balanceado
y debería darte un mejor desempeño.
Hasta ahora solo he hablado 
de un número relativamente pequeño
de variables que caben en una sola tarea.
Pero ¿qué sucede con estos parámetros 
de modelos mucho más grandes?
¿cosas como las grandes incrustaciones,
que pueden tener
decenas de gigabytes de tamaño?
Para lidiar con estas
tenemos algo llamado como "particiones".
Hacen exactamente lo que su nombre dice.

Japanese: 
ダイアグラムを抽出すべきでしたが、
より悪いケースで終了しました。
全ウェイトがタスク 0 上に
全バイアスが別のタスク上にあるはずでした。
未だにこれらのタスクの間には、
より大きな不均等があります。
明らかに、ここでベターを
尽くせると思います。
より多くのバランスロードを
達成することができた方法の１つは、
ロードバランシングストラテジーと
呼ばれるものを使うやり方です。
これはレプリカデバイスセッターに対する
オプショナルな話題です。
オンラインビンパッキングを行なう
シンプルな切望的な計画があります。
それはパラメータ内のバイト数に
基づいているものです。
より均等のとれた、この成果へと導きます。
ウェイト配列はそれぞれ、
独立した PS タスク上に配置されます。
そしてバイアスはタスク 1 上に
ひとまとめにされます。
より均等が取れているため、
より良いパフォーマンスを約束します。
これまでシングルタスクに全て収まる、
比較的小さい変数について話しました。
これらの大型のモデルパラメータについては
どうでしょうか。
サイズが莫大なギガバイトになる、
大型の埋め込みのようなものでしょうか。
パーティショナーと呼ばれるものの
取扱いについてはどうでしょうか。
その言葉の通りのことをします。

Chinese: 
我想我应该画一个示意图
我们的情况会更糟糕
因为所有的加权都会在任务 0
而所有的偏权都会在另一个任务
我们在这些任务之间的不平衡会更严重
明显地，我们能在这里做得更好
我们提供的一个
实现更加平衡的负荷的方法
就是使用一个称为
负载平衡策略的方法
这是复制设备创建的另一个参数
我想现在我们有了一个
简单的贪婪的策略
完成类似在线垃圾收集的工作
根据你参数的内存字节
这能带来更平衡的结果
每一个加权矩阵
都存放在单独的 PS 任务里
偏向整理在任务 1 里
这样更加平衡了
它应该会给你们更好的工作表现
到目前，我只是讲了相对比较小的变量
它们都能存放在单独的任务
但对这些极端大的模型参数
这些极大的嵌入数据
可能几万兆字节的数据怎么样呢？
要解决这个问题
我们需要叫做分割符的东西
它们的作用就是名字听起来那样

Indonesian: 
mungkin baiknya diagram--
kita akan mendapatkan kasus terburuk
karena semua pembobotan jatuh pada task 0
dan semua bias di task lainnya.
Ketidakseimbangannya akan lebih besar.
Jelas, kita bisa memperbaikinya.
Salah satu cara untuk
menyeimbangkan beban kerja yaitu
menggunakan sesuatu yang disebut
dengan load balancing strategy.
Ini pilihan lain untuk
replica device setter.
Saat ini kita hanya punya strategi biasa
dengan online bin packing
berdasarkan jumlah byte di parametermu.
Sehingga hasilnya akan lebih seimbang.
Tiap matrik pembobotan ditempatkan
pada task PS yang berbeda
dan biasnya di jadikan satu pada task 1.
Jauh lebih seimbang dan mestinya
performanya jauh lebih baik.
Sejauh ini aku baru bicara tentang
variabel yang relatif kecil
yang bisa muat dalam satu task.
Bagaimana dengan parameter model
yang luar biasa besar
hal seperti embedding yang masif
dan mungkin berukuran puluhan gigabyte?
Untuk mengatasi hal ini,
kami punya partitioner.
Kerjanya sama seperti namanya.

Korean: 
표를 그려 왔으면 좋을 뻔 했죠
훨씬 더 안 좋은 결과가
나오게 될 겁니다
모든 무게는 업무0에 있을 것이고
모든 편향은 반대에 있을 테니 말이죠
저희는 이 업무들 사이에서 훨씬 더 큰 불균형을 볼 겁니다
따라서 분명 더 나은 방법이 있을 겁니다
좀 더 균형된 부하량을 얻기 위해
저희가 제공했던
방식 중 하나는 부하량
균형잡기 전략이라고
불리는 것입니다
이는 복제 기기 세터에
선택적 아규먼트입니다
지금 제 생각에 저희가 가진 것은
간단한 욕심많은 전략일 뿐이죠
이는 파라미터에서 바이트의 수에 기초한
온라인 빈 패킹을 합니다
이러한 더 균형잡힌 결과를 초래하죠
각각의 무게 행렬은 별도의
PS 업무에 놓여지고
편향은 업무 1에서 함께
모이게 되는 거죠
훨씬 균형잡혔고 더 나은 성능도
보일 겁니다
지금까지 전
단일 업무에 모두 다 들어가는
상대적으로 작은 변수에
대해서만 말했습니다
하지만 이 터무니없이 큰
모델 파라미터는 어떻게 할까요?
크기가 수십 기가바이트가 될지도 모르
큰 임베딩 같은 것 말이죠
이를 해결하기 위해
칸막이라는 것이 있습니다
칸막이는 그 이름에서
알 수 있을 일을 합니다

Portuguese: 
E pensem, se tivéssemos
apenas duas tarefas PS aqui...
deveria ter desenhado um diagrama aqui...
nós acabaríamos com um caso ainda pior,
porque todas as ponderações
estariam na task 0, e todos
os viés estariam em outra.
Teríamos um desequilíbrio
ainda maior entre essas tarefas.
Claramente podemos fazer melhor.
Uma das formas que
proporcionamos para alcançar
uma carga mais equilibrada
é usando o que chamamos
de estratégia de balanceamento de carga.
E isso é um argumento opcional
para o replica_device_setter.
Neste momento, acho que temos 
uma simples estratégia gananciosa
que faz um tipo de empacotamento online
baseado no tamanho 
de bytes nos seus parâmetros.
E leva a esse resultado mais balanceado.
Cada matriz de ponderação
é colocada em uma tarefa PS separada
e os vieses são colocados
juntos na task 1.
É muito mais equilibrado 
e isso te propicia
uma performance melhor.
E até agora eu só falei sobre 
variáveis relativamente pequenas
que cabem em apenas uma tarefa.
Mas e o que acontece
com esses parâmetros muito grandes
coisas como grandes códigos inseridos
que podem ser do tamanho 
de dezenas de gigabytes?
Bom, para lidar com isso, nós temos
algo que chamamos de "particionadores".
Eles fazem exatamente o que parecem fazer.

Japanese: 
ここにあるようなパーティショナーとの
変数記号を作った場合、
TensorFlow は大型の
ロジカル変数を３つの具現的な要素に分割し、
そして、異なる PS タスクに
割り当てます。
このような方法を使うことで
得られる有益な点は、
その埋め込み変数を取り、
関連する埋め込み機能にパスした場合
例えば、ルックアップ埋め込みのように
ファクトに関する知識を
利用することになります。
それはパーティションされるでしょう。
そして埋め込みルックアップ算定の
一部をオフロードし、
パラメータサーバーデバイス自体に
勾配をオフロードします。
いいですか。
デバイス配置に関する
大量の詳細情報でした。
しかしかなり重要な議題であり
解決する必要に迫られた、
コンビネーション的に大がかりな問題を抱えた
ドメインと思われるでしょう。
皆さんに知って頂きたい重要なことは、
tf_train_replica_device_setter が
分布されたトレーニング使用ケースの
多くに貢献する、まったく発見的なもの
だということです。
必要であれば、ロードバランシング用に
これらのオプショナル計画を提供したり、
パーティションしたり、設定した簡単な方針に
優先するデバイス機能を入力したり、
また設定した簡単な方針に優先する、
デバイス機能を入力しながら
カスタマイズすることが可能です。

Indonesian: 
Jika kau membuat variabel dengan
partitioner, seperti ini
TensorFlow akan membagi
variabel logika yang besar
menjadi tiga bagian konkrit dan
menugaskannya pada task PS yang berbeda.
Yang menyenangkan adalah
jika kau mengambil varibel embedding
dan memberikannya pada
fungsi yang berkaitan dengan embedding
misalnya embedding look-up
ini akan memanfaatkan informasi
tentang proses partisi ini
dan akan mentransfer beberapa komputasi
pencarian embedding dan gradien
ke server parameter perangkat itu sendiri.
Baiklah.
Tadi itu detail penempatan perangkat.
Ini topik yang sangat luas.
Bisa dibilang domain
masalah gabungan yang besar
yang harus kita pecahkan.
Hal utama yang ingin kau hilangkan adalah
tf_train_replica_device_setter
merupakan heuristik sederhana untuk
banyak kasus latihan terdistribusi.
Kau bisa menyesuaikannya jika perlu
dengan memberikan strategi
opsional untuk, misalnya
load balancing dan partition atau
bahkan tulis device function-mu sendiri
yang menimpa peraturan sederhana
yang kami sediakan.

Spanish: 
Si creas una variable con una partición 
como esta, entonces TensorFlow
separará la variable lógica grande
en tres partes concretas
y las asignará a diferentes tareas PS.
Algo bueno de hacerlo de esta forma
es que si tomas esa variable incrustada
y luego la pasas a algunas de las funciones
incrustadas relacionadas
como, por ejemplo, embedding_lookup
se beneficiará de saber
que será particionada
y terminará con algunos de los cómputos
de embedding_lookup
y también con los gradientes 
del parámetro de servidor de dispositivo.
Bien.
Se detalló bastante
la disposición de dispositivo.
Pero es un tema muy importante.
Creo que podría decir que el problema
de este dominio es muy grande
y tenemos que resolverlo.
Lo principal que quiero que entiendan
es que tf_train_replica_device_setter
es una heurística sencilla 
que funciona para muchos usos de casos
de entrenamiento distribuido.
Pueden personalizarlo si lo necesitan
con estas estrategias opcionales como
balanceamiento de carga o particionamiento
o incluso escribiendo sus propias 
funciones de dispositivo
que ignoren nuestras 
reglas sencillas que ofrecemos.

Portuguese: 
Se você criar uma variável
com um "particionador", como este aqui
TensorFlow irá dividir
a grande variável lógica
em três partes concretas e designá-las
a diferentes tarefas PS.
E uma coisa boa em 
fazer as coisas desse jeito
é que se você pega aquela
variável de código inserido
e depois passa para algumas 
das funções inseridas relacionadas
como, por exemplo, embedding look-up.
Irá se beneficiar
por saber que será particionada.
E irá descarregar alguns
dos cálculos embedd look-up.
E também os gradientes
de servidores de parâmetros
de dispositivos.
Certo.
Foram muitos detalhes
sobre a implantação do dispositivo
Mas é um assunto muito importante.
Acredito que poderiam dizer
que é um problema de domínio
muito grande que temos que resolver.
O mais importante que 
quero que vocês entendam
é que o tf_train_replica_device_setter
é um simples heurístico
que funciona para muitos casos
de treinamento distribuído.
E você pode personalizá-lo, se necessário
fornecendo essas estratégias
opcionais para balanceamento de carga
e particionamento, ou até mesmo
escrever as suas próprias funções
de dispositivo que substituem
as diretrizes que fornecemos.

Korean: 
여기 있는 것과 같은
칸막이가 있는 변수를 만드는 거죠
텐서플로우는 구체적인
세 부분으로 큰 논리 변수를
나눌 것이고 다른 PS 업무에
할당할 것입니다
이 방법의 좋은 점 중 하나는
임베드한 변수를 가지고
임베드와 관련된 기능으로 보낸다면
예컨대 임베딩 찾기 같은 것이죠
이는 칸이 나눠질 것이라는
사실에 대한 지식을
활용할 것이고
임베딩 찾기 계산의 일부와
파라미터 서버 기기 자체로의 기울기를
없애겠죠
좋습니다
기기 위치에 대한
자세한 설명이었지만
이는 아주 큰 주제이기도 합니다
우리가 풀어야 할 결합적으로
아주 큰 문제 영역이라
할 수 있겠죠
여기서 중요한 점은
tf_train_replica_device_setter가
많은 분산 훈련 사용 사례에
적용되는 간단한
휴리스틱이라는 점이죠
필요하면 맞춤화할 수 있습니다
이러한 선택적 전략을 제공할 수 있죠
예컨대 부하량 균형이나 칸막이
혹은 저희가 제공한 간단한 정책을
치환하는 여러분 각자의
기기 기능을 적을 수도 있죠

English: 
If you create a variable with
a partitioner, like this one
here, TensorFlow will split
the large logical variable
into three concrete
parts and assign them
to different PS tasks.
And one nice thing about
doing things this way
is if you take that
embedding variable
and then you pass it to some
of the embedding-related
functions, like
embedding look-up,
for example, it
will take advantage
of the knowledge about
the fact that it's
going to be
partitioned, and it will
offload some of the
embedding look-up computation
and the gradients to
the parameter server
devices themselves.
All right.
That was a lot of detail
about device placement.
But it is a very big topic.
I guess you could say it's a
combinatorially large problem
domain that we have to solve.
The main thing I
want you to take away
is that the
tf_train_replica_device_setter
is this simple heuristic that
works for a lot of distributed
training use cases.
And you can customize
it if you need
to by providing these optional
strategies for things like load
balancing and partitioning, or
even writing your own device
functions that override the
simple policies we provide.

Chinese: 
假如你用分隔符创建了变量，
就像这里这个
TensorFlow 将会
分隔大的逻辑变量
为三个具体部分
并分配到不同的 PS 任务中
这样做的好处是
你可以提取嵌入变量
然后你把它传递到一些
和嵌入有关的函数
比如嵌入查询
它的好处在于
知道它将会被分割的事实
这会减轻一些嵌入查询计算
和参数服务器设备自己的梯度的任务
好的
这是很多关于设备放置的细节
但这是一个很大的话题
我想你们可以说这是我们要去解决的
组合的大型问题领域
我想你们学到的主要事情
就是
tf_train_replica_device_setter
是能帮助到很多分配训练情况的
简单的启发性工具
你可以根据需要自定义它们
通过提供这些选择性策略
针对负荷平衡和分割，或者
甚至是编写你自己的
覆盖我们提供的简单规则的设备函数

English: 
And this is definitely an
area where we're always
on the lookout for new and
better device placement
policies.
So if you do end up
implementing your own
and you think it might
be generally useful,
we really encourage you to
send it as a pull request,
and we can add it
to the set of tools
that people have to
make their lives easier.
All right.
So you've built your graph.
You've got all of
the devices set.
And now you want to
go ahead and run it.
But when you create a TensorFlow
session using code like this,
that session will only
know about the devices
in a local machine.
And let's say you have
200 computers sitting
idle over there.
How do you make it
use those computers?
The answer is that you create
this thing called a TensorFlow
server in each of
those machines.
And you configure those
servers in a cluster
so that they can communicate
over the network.
Now, looking at
it in more detail,
the first thing we need to do
is to provide a cluster spec.
This is something that tells
TensorFlow about the machines
that you want to run on.
A cluster spec is
really just a dictionary
that maps the names of jobs--

Indonesian: 
Bagian inilah yang selalu kami pantau
untuk dapatkan peraturan
peletakkan perangkat yang lebih baik.
Jika implementasikan milikmu sendiri
dan kau pikir dapat bermanfaat
kami anjurkan mengirimnya
sebagai pull request
dan kami bisa menambahkannya
ke serangkaian alat
yang membuat kehidupan ini lebih mudah.
Baiklah.
Jadi kau sudah membuat grafikmu.
Kamu sudah setel semua perangkat.
Sekarang kau mau langsung menjalankannya.
Tapi ketika kau membuat
sesi TensorFlow dengan kode seperti ini
sesi ini hanya akan tahu
perangkat yang ada di mesin lokal.
Katakanlah kau punya
200 komputer diam di sana.
Bagaimana menggunakan
komputer-komputer itu?
Jawabannya adalah kau buat
server TensorFlow pada tiap mesin itu.
Konfigurasi servernya dalam klaster
sehingga dapat berkomunikasi
dalam jaringan.
Lebih detail lagi
hal pertama yang diperlukan ialah
menyediakan spesifikasi klaster.
Untuk memberitahu TensorFlow tentang
mesin-mesin yang akan kau gunakan.
Spesifikasi klaster hanyalah
kamus berisi peta kerja--

Chinese: 
在这个领域，我们总要注意
新的和更好的设备放置政策
所以假如你最后实现了自己的函数
而且你觉得它总体来说可能很有用
我们真的希望你
把它作为拉拽请求发给我们
我们可以把它加到工具集
让人们的生活变得更简单
好的
现在你建立了自己的图表
你也有了所有设备集
现在你想继续运行
但当你用这个代码
创建了 TensorFlow 模块
这个模块只会知道
本地机器的模块
比如说你在那边有
200 部闲置的电脑
你要怎么让它使用这些电脑呢？
答案就是你在每个机器里面
创建了称为
TensorFlow 服务器的东西
你把这些服务器安排在群里
那么它们可以用网络交流
现在，从更细节的方面研究它
我们要做的第一件事就是
提供一个 ClusterSpec
它能告诉 TensorFlow
你想要使用的机器
一个 ClusterSpec
真的只是一个字典
它能追踪作业的名字

Korean: 
이는 또한 분명 새롭고 더 나은
기기 위치 정책을 위해
저희가 항상 눈여겨보는
분야입니다
여러분 각자의 것을 실행하게 되었고
일반적으로 유용하다고 생각되시면
풀 요청으로 보내주시길 권장합니다
그러면 사람들의 생활을
더 쉽게 만들어 줄
도구 세트에 첨가할 수 있죠
좋습니다
이제 여러분이 그래프를 그렸죠
모든 기기가 준비됐습니다
이제 가서 실행하고 싶으시겠죠
이러한 코드를 사용해서
텐서플로우 세션을 만들 때
그 세션은 로컬 머신에서의 기기에 대해서만 알겠죠
.
저쪽에 200대의 컴퓨터가 가만히
앉아 있다고 가정해 봅시다
이 컴퓨터를 어떻게 활용할까요?
정답은 각각의 머신에
텐서플로우 서버라는 것을
만드는 겁니다
이 서버를 클러스터에서 컨피겨해서
네트워크로 소통할 수 있는 거죠
이제 좀 더 자세히 보면
먼저 해야 할 일은
클러스터 스펙을 제공하는 겁니다
이는 텐서플로우에게
운영하고 싶은 머신에 대해
말해주는 것이죠
클러스터 스펙은 일의
이름을 지도에
나타내는 사전과 같은 거죠

Portuguese: 
E esta é, definitivamente,
uma área que nós sempre
estamos buscando por novas e melhores
diretrizes de implantações
de dispositivos.
Se você acabar implementando 
a sua própria e achar que pode ser útil
te encorajamos a nos 
enviar como uma pull request
e nós podemos adicionar
ao conjunto de ferramentas
que as pessoas têm para facilitar a vida.
Certo. Você construiu o seu gráfico.
Você já tem todos
os dispositivos configurados.
E agora você quer prosseguir e rodá-lo.
Mas quando você cria uma sessão 
TensorFlow usando um código como este
esta sessão apenas saberá
sobre os dispositivos
em uma máquina local.
E digamos que você tenha 
200 computadores inativos por lá.
Como você as faz
ativar estes computadores?
A resposta é você criar uma 
coisa chamada servidor TensorFlow
em cada uma destas máquinas.
E você configura esses
servidores em um conjunto
para que eles possam
se comunicar através da rede.
Agora, olhando mais detalhadamente
a primeira coisa que precisamos fazer é 
fornecer uma especificação do conjunto.
Algo que informe o TensorFlow 
sobre as máquinas
que você deseja executar.
A especificação do conjunto
é apenas um dicionário
que mapeia os nomes das jobs

Japanese: 
ここは、新たな、より良い
デバイス配置計画を模索する
明確なゾーンです。
実装を終え、一般的に役に立つと思った時は
プルリクエストとして、
送ってくれることを期待しています。
そうすれば、ツールセットに追加しますので
多くの人に役立つものとなるでしょう。
それでは、
グラフを作成しました。
デバイスセットを全て手に入れました。
先に進んで、作動させたいと思っています。
けれど、このようなコードを使って
TensorFlow のセッションを作った場合
そのセッションは、ローカルマシーンの
デバイスしか知りません。
200 台のコンピューターが
手持ちぶたさにしています。
これらのコンピュータを
どのように活用しますか。
TensorFlow サーバーと呼ばれるものを
これらのマシーンごとに作ります。
クラスター内に
これらのサーバーを環境設定すると
ネットワークを通じて、
コンピューターが通信できます。
より細かい部分を注目してみましょう。
最初に必要なのは、
クラスタースペックを用意することです。
作動させたいマシーンに関する
TensorFlow の役割です。
クラスタースペックはまさに
仕事名を配置するディクショナリーです。

Spanish: 
Es un área en la que a menudo
buscamos nuevas y mejores reglas
de disposición de dispositivo.
Si implementan la suya
y creen que puede ser útil,
los alentamos que nos la envíen
como petición de subida
y nosotros la agregaremos
a nuestro grupo de herramientas
que la gente puede tener 
para facilitar las cosas.
Bien.
Ya hicieron su gráfico.
Ya tienen dispuestos 
todos sus dispositivos.
Ahora quieren avanzar y ejecutarlo.
Pero cuando crean 
una sesión en TensorFlow
usando código como este
esa sesión solo conoce 
los dispositivos de una máquina local.
Digamos que tienen 200 computadoras
desocupadas por acá.
¿Cómo las usas?
La respuesta es que tienes que crear 
algo llamado "servidor de TensorFlow"
en cada una de las máquinas.
Configuras esos servidores en un clúster
para que se comuniquen a través de la red.
Viéndolo con más detalle,
la primer cosa que necesitamos hacer
es dar una especificación del clúster.
Esto le comunica a TensorFlow
de las máquinas que quieres activar.
Una especificación 
es en realidad un diccionario

English: 
so that's things like worker
and PS, in this example--
to a list of one or more network
addresses that correspond
to the tasks in each job.
Now, we don't
actually expect you
to type in all of these
addresses by hand.
It gets kind of error prone.
But in the next talk,
Jonathan's going
to be showing you how a
cluster manager like Kubernetes
or Mesos will do this for you.
And if you're using
a cluster manager,
internally we use a
cluster manager called Borg
that a lot of this
stuff was inspired by.
So typically, your
cluster manager
will run an instance
of your program
on each machine in the cluster,
giving it the same cluster
spec.
And then it'll start
a TensorFlow server
in each program.
It'll pass it a particular
job name and task
index that matches the
address of the local machine
in that cluster.
And then finally, when
you create your session,
you specify the local
server's address
as the target, which is
what enables it to connect
through that server to any
of the machines mentioned
in the cluster spec.
And then you're good to go.
So your session run
call can run code
on any device in
the entire cluster.

Indonesian: 
seperti worker dan PS, pada contoh ini--
daftar satu atau lebih alamat jaringan
yang terkait dengan task tiap pekerjaan.
Kita tidak berharap kau mengetik
semua alamat ini secara manual.
Karena rentan kesalahan.
Di sesi berikutnya,
Jonathan akan memperlihatkan
bagaimana pengelola klaster
seperti Kubernetes atau Mesos
melakukannya untukmu.
Jika memakai pengelola klaster
kami memakai pengelola klaster
bernama Borg
yang banyak menginspirasi kami.
Tipikalnya pengelola klastermu akan
menjalankan secuil programmu
pada tiap mesin di klaster,
jika spesifikasi klaster yang sama.
Lalu ini akan mulai menjalankan
server TensorFlow pada tiap program.
Lalu memberikan nama pekerjaan
dan indeks task khusus
yang sesuai dengan
alamat mesin lokal di klaster itu.
Lalu ketika kau membuat sesimu
kau spesifikkan
alamat server lokal sebagai target
sehingga dapat berhubungan dengan
semua mesin yang disebutkan
melalui server itu.
Kau bisa memulainya.
Run call sesimu dapat menjalankan kode
pada perangkat manapun di seluruh klaster.

Portuguese: 
coisas como worker e PS,
neste exemplo
a uma lista de um ou mais
endereços de rede que correspondem
às tarefas em cada job.
Nós não esperamos que vocês digitem
todos esses endereços.
É meio suscetível a erros.
Mas na próxima palestra,
o Jonathan vai mostrar a vocês
como um gerenciador
de conjuntos, como o Kubernetes
ou o Mesos irá fazer isso por você.
E se você estiver usando 
um gerenciador de conjuntos
nós usamos um gerenciador chamado Borg
o qual inspirou muitas dessas coisas.
Normalmente, o seu
gerenciador de conjuntos
irá rodar uma instância do seu programa
em cada máquina do conjunto,
considerando as mesmas diretrizes.
E então irá iniciar um servidor TensorFlow
em cada programa.
Irá passar um determinado
nome de job e um índice
de tarefa que combine com o
endereço da máquina local
naquele conjunto.
E quando você finalmente 
criar a sua sessão
você especifica o
endereço do servidor local
como uma meta, 
o que possibilita conectar
através do servidor,
qualquer máquina descrita
nas especificações do conjunto.
E então você está pronto para começar.
A sua chamada de execução
pode executar o código
em qualquer dispositivo no conjunto todo.

Spanish: 
que mapea los nombres de trabajos,
cosas como worker y ps
a una lista de una 
o más direcciones de red
que corresponden 
a las tareas en cada trabajo.
No esperamos que ingreses a mano
todas estas direcciones.
Da un error por defecto.
Pero en la siguiente plática, 
Jonathan va a mostrarles
cómo un administrador de clúster,
como Kubernetes o Mesos, 
lo hace por ustedes.
Si usan un administrador de clúster...
Nosotros usamos uno llamado Borg.
Y mucho de esto fue inspirado por él.
Normalmente, su administrador de clúster
ejecutaria una instancia de su programa
en cada máquina en el clúster,
dándole la misma especificación
al clúster.
Luego iniciará un servidor 
TensorFlow en cada programa.
Pasará un determinado 
nombre de trabajo
y un índice de tarea que es igual
a la dirección de la máquina local
en ese clúster.
Finalmente, cuando crean su sesión
especifican la dirección 
del servidor local como el objetivo
lo cual permite conectar 
a través del servidor
cualquiera de las máquinas mencionadas
en la especificación del clúster.
Ahora pueden continuar.
La llamada de ejecución de su sesión
puede ejecutar código
en cualquier dispositivo
por todo el clúster.

Japanese: 
例えば、ワーカーや PS などを
それぞれの仕事のタスクに相当する
ネットワークアドレスのリストに配置します。
手動でこれらのアドレス全てを
入力する必要はありません。
これは間違っている傾向です。
しかし、次のスピーチではジョナサンが
Kubernetes もしくは Mesos のような
クラスターマネジャーについて
みなさんに説明します。
クラスターマネジャーを
使っているのであれば、
Borg と言うクラスターマネージャーを
内部で使っています。
そこからインスピレーションを受けて
多くのものが生まれました。
大抵は、クラスターマネージャーは
同一のクラスタースペックを渡して、
クラスター内でそれぞれのマシーン上で
プログラムのインスタンスを作動します。
そしてそれぞれのプログラム内で
TensorFlow サーバーを始動します。
特定の仕事名、またそのクラスター内の
ローカルマシーンのアドレスと一致する、
タスクインデックスを渡します。
その後、セッションを作った時
ターゲットとして、
ローカルサーバーアドレスを指示します。
そのサーバーを通じて
クラスタースペック内で言及された、
マシーンに接続させることができます。
順調に行っています。
セッションランコールは、クラスター全体内の
あらゆるデバイスのコードも作動させます。

Korean: 
이 예시에서 워커와 PS 같은 겁니다
즉 각 일에서 업무로 상응하는
하나 혹은 그 이상의 네트워크
주소의 목록인거죠
손으로 이 모든 주소를 칠 것을
바라지는 않습니다
실수가 많아지겠죠
쿠버네티스나 메소스 같은
클러스터 매니저가 이를 어떻게 해줄지
보여줄 겁니다
클러스터 매니저를 사용 중이시라면
내부적으로 저희는
이 많은 것들에 영향을 준
보르그라는 클러스터 매니저를 사용합니다
보통 클러스터 매니저는
클러스터에 있는 각 머신에서
같은 클러스터 스펙을 주면서
프로그램의 예시를 실행하겠죠
.
그리고 나서 각 프로그램에서
텐서플로우 서버를
시작할 겁니다
그 클러스터에 있는 로컬 머신의 주소와
일치하는 특정 작업 이름과
업무 인덱스를 주겠죠
.
마지막으로 세션을 만들었을 때
로컬 서버의 주소를 표적으로 구체화하면
그 클러스터 스펙에서
언급된 어떠한 머신으로도
그 서버를 통해 연결될 수
있게 하는 거죠
.
그러면 된 겁니다
따라서 세션 실행 콜은
클러스터 전체에서
어떠한 기기 상의 코드도
실행할 수 있습니다

Chinese: 
在这个例子里面就像工作者和 PS
直到一个或多个对应每个作业的任务的
网络地址名单
现在我们不是想要你
手动输入所有地址
这很容易导致错误
但在下一个演讲里，乔纳森将会
向你们展示像
Kubernetes 或者 Mesos 的
群管理者将怎样帮你实现这个
假如你在使用群管理者
内部我们使用一个
叫 Borg 的群管理者
它启发了很多其他东西
一般你的群管理者
会在群的每个机器里
运行一段你的程序实例
给它们同样的 ClusterSpec
接下来它会在每个程序里
启动一个 TensorFlow 服务器
它会传递一个特定的
作业名称和任务指数
它和群里本地机器的
地址相互匹配
最后，当你创建了自己的模块
你指定了本地服务器的地址作为靶
靶使得它能通过服务器连接到
ClusterSpec 里提到的每一个机器
接下来你就可以运行了
你的模块运行命令可以
在整个群的每一个设备上运行代码

Indonesian: 
Umumnya, worker akan mulai
perulangan latihan yang hanya
mengulangi partisi data
menjalankan operasi latihan lagi dan lagi.
Seperti itulah worker.
Task PS jauh lebih sederhana.
Sederhananya--
Task PS tak punya kode klien.
Task PS hanya merespon bit grafik
yang dikirim oleh worker lain ke sana.
Pada kasus ini,
kau hanya perlu membuat server.
Kau tulis job name PS.
Lalu kau panggil untuk
bergabung di server.
Kerjanya hanya memblok menunggu koneksi
yang datang dari node lain di klaster.
Jujur saja ini agak aneh.
Aku mendapat banyak pertanyaan
di Stack Overflow.
Satu yang sering ditanyakan yaitu
bisa berikan contoh di mana
kode parameter server
pada implementasi server.join?
Jika kau melihatnya,
hanya lima, sepuluh baris C++.
Kerjanya hanya mengecek eror
lalu membloknya dengan dua utas.
Ini menggabungkan dua utas.
Karena itu disebut join.
Tapi memang ini salah paham
yang dapat dipahami karena ini task PS-mu.
Jadi apa sebenarnya kerjanya?
Sebenarnya ini menyoroti
hal penting di TensorFlow terdistribusi.

Portuguese: 
E, normalmente, o que o worker irá fazer
é um ciclo de treinamento que se repete
através das partições dos dados,
executando uma operação de treinamento
várias e várias vezes.
Ok. Então é assim que
um worker funciona.
A tarefa PS é muito mais simples.
Então a tarefa PS é simplesmente...
elas basicamente não 
têm um código de cliente.
Elas apenas respondem
a partes do gráfico de entrada
que são enviadas a elas
por outros workers.
Neste caso, vocês
apenas constroem o servidor.
Escreve job_name=ps
e então você chama join no servidor.
E tudo o que isso faz é bloquear,
esperando que conexões
venham de outros nós do conjunto.
E, na verdade, é um pouco estranho.
Eu lido com bastantes questões
a respeito de Stack Overflow.
E uma das mais comuns é
"Você pode me mostrar onde
fica o código de servidor de parâmetro
na implementação de server.join?"
E se vocês forem observar,
são cinco, dez linhas de C++.
Faz apenas uma conferência de erros
e bloqueia algumas linhas de execução.
Junta-se a algumas linhas de execução.
Por isso se chama join.
Mas é um equívoco razoável
porque é a sua tarefa PS.
Então o que está realmente fazendo?
Bom, isso destaca
algo muito importante sobre

Spanish: 
Típicamente, lo que el trabajador hará
será empezar un bucle de entrenamiento
que itera en su partición de los datos
corriendo así un op
de entrenamiento una y otra vez.
Muy bien.
Así se ve un trabajador.
La tarea PS es mucho más simple.
Los PS...
Básicamente no tienen código de cliente.
Responden a los bits de gráfico entrantes
que son enviados a ellos 
por los trabajadores.
En este caso, 
solo desarrollas el servidor.
Escribes job_name="ps".
Luego llamas join en el servidor.
Lo que hace es que bloquea 
para esperar que entren conexiones
de otros nodos en el clúster.
De hecho, es un poco raro.
Por eso contesté muchas preguntas
en Stack Overflow.
Una común es,
"¿puedes mostrarme en qué parte
de la implementación de server.join
se ubica el código 
del servidor de parámetro?"
Si van y la revisan
son como cinco o diez líneas de C++.
Aparecerá un error al revisar
y luego se boqueará en un par de hilos.
Se une a un par de hilos.
Por eso se llama join.
Pero es una confusión razonable
porque este es su tarea PS .
¿Qué hace en realidad?
Esto nos dice algo muy importante

Chinese: 
一般工作者会做的是
它会启动一个训练循坏
它只是重复数据的分割
一遍又一遍地运行训练 op
好的
这就是一个工作区的样子
PS 任务更加简单
那么 PS 任务只是——
它们基本上没有客户代码
它们只会回应
收到别的工作者
发给它们的图表
所以在这个例子里，
你只是建立了服务器
你说它的作业名称是 PS
然后你在服务器调用连接符
它的作用就是防止
等待群里的其他节点的连接进来
事实上这有一点奇怪
我经常遇到栈溢出的问题
最常见的一个是
你能不能为我展示
server.join
参数服务器代码作用在哪里？
假如你去看它
它由大概 5 到 10 行 C++
它只做一些查错
然后它在一些指针上标志块
它连接一些指针
这就是为什么它叫连接符
但这也是一个合理的误解
因为这是你的 PS 任务
它事实上在做什么呢
这标志关于 Distributed TensorFlow
怎样工作的

English: 
And typically, what
the worker will do
is it'll start a training
loop that just iterates
over its partition of the
data, running a training
op over and over again.
OK.
So that's what a
worker looks like.
PS task is much simpler.
So PS tasks simply--
they have basically
no client code.
They just respond to
incoming bits of graph
that are sent to them
by other workers.
So in this case, you
just build the server.
You say it's job name PS.
And then you call
join on the server.
And all that does is it
blocks waiting for connections
to come in from other
nodes in the cluster.
And actually, it's a bit weird.
So I deal with a lot of
questions on stack overflow.
And one of the common
ones is, can you
show me where in the
implementation of server.join
the parameter server code lives?
And if you go and look
at it, it's like, five,
10 lines of C++.
It just does some
error checking,
and then it blocks on
a couple of threads.
It joins a couple of threads.
That's why it's called join.
But it's a reasonable
misconception,
because this is your PS task.
Well, what's that
actually doing?
Well, this highlights something
quite important about how

Korean: 
데이터의 칸막이까지 그저 왕복하는
훈련 루프를 시작할 것이고
훈련 운영을 반복해서
실행하겠죠
좋습니다
이것이 워커의 모습이죠
PS 업무는 훨씬 더 간단합니다
PS 업무는 단순히
기본적으로 클라이언트 코드가 없습니다
다른 워커가 보낸
그래프의 입력 비트에 반응할 뿐이죠
따라서 이 경우
서버를 짓기만 하면 되죠
PS라는 이름의 작업인 거죠
그러면 서버로 조인 기능을 불러 옵니다
그리고 이는 클러스터에서
다른 노드로부터
들어오는 연결을 기다리는 것을
막는 역할을 할 뿐이죠
사실 조금 이상하죠
전 스택 오버플로우에서
많은 질문을 다룹니다
흔한 질문 중 하나는
server.join 실행에서
파라미터 서버 코드가
어디 있는지 보여줄 수 있냐는 겁니다
가서 보시면 10줄 정도의 C++입니다
.
오류 확인을 조금 하고
스레드 몇 개를 막죠
스레드 몇 개에 조인합니다
그래서 조인이라고 부르죠
하지만 일리있는 오해입니다
이건 PS 업무이니까 말이죠
이것이 실제로 하는 일은 뭘까요?
이는 분산 텐서플로우가
어떻게 작동하는지에 대해

Japanese: 
通常、ワーカーが行なうのは
データのパーテションを単純に反復する
トレーニングループを始め、
何度も何度も OP を作動させ、
トレーニングします。
これがワーカーが行なっていることです。
PS タスクはもっと簡単です。
PS タスクは単純に、基本的に
クライアントコードを持っていません。
別のワーカーから送られてきた、
グラフの参入ビットに反応するだけです。
この場合は、サーバーを構築するだけです。
仕事の名前は PS で、
サーバー上に集まるように呼び出します。
クラスター内で別のノードから送られる、
接続を待ちながらブロックします。
事実、少しユニークな働きをします。
ですから、スタックオーバーフローに
関する数多くの質問に対処します。
共通する質問の１つとして、
server.join の実装内のどこに、
生きているパラメーターサーバーコードが
あるか教えてくれますか、というものです。
C++ の 5 行目か 10 行目を見ると
単純なチェックエラーであったり、
スレッドをブロックしていたり
スレッドを結合していたり、
「Join」と呼ばれる所以です。
しかし、これは妥当な思い違いです。
なぜなら、これは PS タスクだからです。
それでは、現実に何が起きているでしょう。
分布された TensorFlow がどのように動くのか、
かなり重要な点をハイライトします。

Chinese: 
一些重要的事
参数服务器，所有东西
所有参数服务器的行为
在这些服务器的低级层次都没有实现
在执行器也没有
然而它是在 TensorFlow
原始程序上建立起来的
就像这些数据流图表的小点
由一个工作区传递到服务器
为我管理和更新参数
这代表我们把参数服务器编制为
一个数据流图表的小碎片
这给了我们灵活性
除非你把所有
关于参数管理是怎样实现的东西都改掉
假如你想要自定义最优算法
或者也许改变应用更新的
同步程序
你可以只通过改变图表实现这点
我们通过在一些我们的算法里使用这个
实现了很好的表现
好的
现在你的服务器已经在待命
你的模块已经构建好
你的训练循环也在运行，我们结束了吗？
每当你在一系列机器上
运行一些长时间运行的训练作业

Spanish: 
de cómo funciona TensorFlow distribuido.
Los servidores de parámetros,
todo el comportamiento
de un servidor de parámetro,
no se implementa a bajo nivel
en estos servidores
o en el motor de ejecución,
sino que se desarrolla fuera
de las primitivas de programación 
de TensorFLow como pequeños bits
de flujos de datos de gráfico
que un trabajador 
lleva a un servidor y le dice:
"maneja algunos parámetros por mi
y actualízalos de esta forma".
Al representar la forma
en que programamos 
los servidores de parámetros
como pequeños fragmentos de datos, 
es lo que nos da flexibilidad.
A menos que cambien todo sobre cómo
se implementa el manejo de parámetros.
Si quieren personalizar 
el algoritmo de optimización
o cambiar el esquema de sincronización
para aplicar las actualizaciones,
pueden hacerlo cambiando el gráfico.
Ganamos mucho en desempeño
al hacerlo en algunos 
de nuestros algoritmos.
Muy bien.
Ahora que sus servidores escuchan,
se crean todas sus sesiones
y su bucle de entrenamiento se ejecuta,
¿hemos acabado?
Siempre que ejecutan 
un trabajo de entrenamiento largo
en un grupo de máquinas, espero
que escuchen de corazón

Indonesian: 
Parameter server, semuanya,
semua perilaku parameter server
tidak diimplementasikan pada
level rendah server-server ini
atau di execution engine
tapi di luar
TensorFlow programming primitives
seperti bit-bit grafik aliran data
dikirimkan worker ke server
seolah berkata
atur beberapa parameter untukku
dan perbarui seperti ini.
Itu merepresentasikan cara kami
memprogram parameter server
sebagai fragmen-fragmen kecil
grafik aliran data grafik
yang memberi kami fleksibilitas.
Kecuali kau mengubah semua cara
implementasi pengelolaan parameter
jika kau ingin mengatur algoritma optimasi
atau mengubah skema sinkronisasi
untuk mengaplikasikan pembaruan
bisa melakukannya dengan
hanya mengubah grafiknya.
Kami berhasil meningkatkan
banyak performa dengan ini
pada beberapa algoritma kami.
Sekarang servermu sedang mendengarkan
semua sesimu dibuat,
perulangan latihanmu bekerja,
apa sudah selesai?
Kapan pun kau menjalankan latihan lama
pada seperangkat mesin

Korean: 
아주 중요한 부분을 강조합니다
모든 파라미터 서버
파라미터 서버의 모든 행동은
이 서버나 실행 엔진에서
낮은 수준에서
실행되지 않고 대신
텐서플로우 프로그래밍 프리미티브에서 만들어졌죠
이 워커가 서버에게 보내는
약간의 데이터 플로우 그래프로 말이죠
파라미터 일부를 관리하고
이렇게 업데이트 하라고 말하는 거죠
저희가 파라미터 서버를
작은 조각의 데이터 플로우 그래프로
프로그램하는 방식을
상징하는 바로 이것이
저희에게 융통성을 주는 겁니다
파라미터 관리가 실행되는 법에 대한
모든 것을 바꾸지 않는 한
최적화 알고리듬을 맞춤화하고 싶으시거나
업데이트를 적용하기 위한
싱크로라이즈 스킴을 바꾸길 원한다면
그래프를 바꾸기만 하면 되는 거죠
저희 알고리듬 일부에서
이렇게 함으로써 많은 성능을 얻었죠
좋습니다
이제 여러분의 서버가 듣고 있고
세션이 모두 만들어졌으며 훈련 루프가
운행되고 있으니 다 된 건가요?
장기 실행중인 훈련 작업을
머신 세트에서 실행할 때마다
레실 람포트의 현명한 말을 깊게

Japanese: 
パラメータサーバーはすべて、
パラメータサーバの様式に影響されます。
サーバー内では、ローレベルで
実装されているわけではありません。
エンジン実行中に実装されているのでもなく
代わりに、これは TensorFlow の
初期プログラミングから構築されたものです。
ワーカーが「パラメータを管理し、
このやり方で更新しなさい」と
サーバーに渡した、これらの少量の
データフローグラフなのです。
パラメータサーバーをプログラムする方法を
データフローグラフの数少ない
フラグメントとして描写することで、
フレクシビリティが得られます。
パラメータ管理の実装経過に関して
何も変えないかぎり、
アルゴリズムの最適化をカスタマイズする場合、
もしくは更新の適用のために
シンクロスキームを変えれば、
グラフを変更することで、
それが可能になります。
複数のアルゴリズムでこれを実行し、
多くのパフォーマンスを得ました。
サーバーが耳を傾けており、
セッションはすべて作られ、
トレーニングループは作動しています。
作業は完了しました。
マシーンセット上で、ロングランニング
トレーニング作業を行なう時は

Portuguese: 
como o TensorFlow distribuído funciona.
Os servidores de parâmetros, tudo...
todo o comportamento de 
um servidor de parâmetros
não é implementado em um
nível mais baixo nesses servidores
ou no motor de execução.
Mas, em vez disso, é construído fora 
da programação inicial do TensorFlow
como estes pedaços
do gráfico de fluxo de dados
que um worker envia
a um servidor para lhe dizer
"Administre alguns parâmetros
para mim e atualize-os desta maneira."
Representando como programamos
os servidores de parâmetros
como pequenos fragmentos do gráfico
de fluxo de dados nos dá flexibilidade.
A menos que você mude
como a gestão de parâmetros
é implementada, se você quiser
customizar o algoritmo de otimização
ou talvez mudar o esquema
de sincronização
para aplicar as atualizações.
Você pode fazer isso apenas
mudando o gráfico.
E tivemos um significativo
ganho de desempenho
fazendo isso em alguns 
de nossos algoritmos.
Agora que os seus
servidores estão ouvindo
as suas sessões estão todas criadas,
o seu ciclo de treinamento está rodando.
Então, terminamos?
Bom, sempre que você executar 
algum trabalho de treinamento longo
em um conjunto de máquinas,
eu espero que vocês levem em consideração

English: 
distributed TensorFlow works.
So parameter
servers, everything,
all the behavior of
a parameter server,
is not implemented at the
low level in these servers
or in the execution
engine, but instead it's
built out of TensorFlow
programming primitives,
as these little bits
of data flow graph
that a worker ships
to a server to say,
manage some parameters for
me and update them this way.
And that, representing the
way we program the parameter
servers as little fragments
of data flow graph,
is what gives us
the flexibility.
So unless you change everything
about how parameter management
is implemented, if you want
to customize the optimization
algorithm, or maybe
change the synchronization
scheme for applying
the updates, you
can do that just by
changing the graph.
And we've gained a
lot of performance
by doing that in some
of our algorithms.
All right.
So now that your
servers are listening,
your sessions are all created,
and your training loop
is running, are we done?
Well, whenever you run some
long-running training job
on a set of machines, I hope you
take the wise words of Leslie

Spanish: 
las palabras sabias de Leslie Lamport
y usen siempre un protector
en cualquier proceso 
de entrenamiento largo.
Un protector, para quienes 
no lo han visto antes, es
lo que usan para escribir un control 
de sus parámetros de modelo al disco.
El mismo protector puede utilizarse
para entrenamiento local y distribuido
pero tiene un par 
de características útiles
en el modo distribuido 
y quiero señalar.
La primera es que casi con seguridad
querrán poner sharded=True
cuando crean su protector.
En este ejemplo, tenemos tres tareas PS
y sharded=True le dice a TensorFlow
que escriba el control en tres fragmentos,
cada uno con todas las variables
de un servidor de parámetro en particular.
Eso quiere decir 
que los servidores de parámetros
pueden escribir directamente 
en el sistema de archivo
y no tenemos que recoger
todos los valores en un lugar
para escribirlos.
Por defecto. la conducta 
es algo pésima porque si estableces
sharded=False, 
traerá todas las variables
a un op guardado.
Lo que significa que tienen 
que materializarse en la memoria
en un proceso, antes 
de que escriba el primer byte.
Si tienes estos modelos muy grandes,

Indonesian: 
kuharap kau mengingat
kata mutiara Leslie Lamport
dan selalu menggunakan saver
dalam tiap proses latihan yang lama.
Saver, bagi kalian
yang belum pernah melihatnya
hanyalah alat untuk menuliskan
checkpoint parameter modelmu.
Saver yang sama dapat digunakan untuk
latihan lokal dan terdistribusi
tapi ada beberapa fitur yang berguna
pada mode terdistribusi yang mau kusoroti.
Pertama kau hampir pasti ingin menyetel
sharded=true saat kau membuat saver-mu.
Pada contoh ini, kita punya tiga task PS
sehingga sharded=true
berkata pada TensorFlow
tulis checkpoint di tiga shard
tiap checkpoint berisi semua variabel
dari satu parameter server tertentu.
Itu berarti parameter server dapat
langsung menulis di sistem fail
dan tak perlu mengumpulkan
semua nilanya pada satu tempat
untuk menuliskannya.
Sebenarnya perilaku default tidak berarti
karena saat kau menyetel sharded=false
semua variabel akan ada di satu save op
yang berati itu tak harus
jadi memori pada satu proses
sebelum menuliskan byte pertamanya.
Dan jika kau punya
model yang amat sangat besar

English: 
Lamport to heart, and
always use a saver
in any long-running
training process.
So a saver, for those of you
who haven't seen that before,
is just what you use to write
out a checkpoint of your model
parameters to disk.
The same saver can be used for
local and distributed training,
but it has a couple of useful
features in distributed mode
that I want to highlight.
The first one is that
you'll almost certainly
want to set sharded equals true
when you create your saver.
So in this example, we
have three PS tasks,
and so sharded equals
true tells TensorFlow,
write the checkpoint
in three shards,
each containing all
the variables from one
particular parameter server.
And that means that the
parameter servers can
write directly to
the file system,
and we don't have to collect
all of the values in one place
in order to write them out.
So actually the default
behavior is kind of pessimal,
because if you set
sharded equals false,
it will bring all of the
variables into one save op,
meaning they have to be
materialized in memory at one
process before it
writes the first byte.
And if you have these
really big models,

Korean: 
새기시길 바라고
어떠한 장기 실행 훈련 과정에서든
세이버를 항상 사용하시길 바랍니다
이를 처음 보시는 분들을 위해
설명하면 세이버는
모델 파라미터의 체크포인트를
디스크에 적을 때
사용하는 것입니다
같은 세이버가 로컬과
분산 훈련에서 사용될 수 있지만
제가 강조하고 싶은
분산 모드에서의 유용한 피쳐가
몇 가지 있습니다
먼저 세이버를 만들 때 거의 대부분
shared=true를 설정하길 바랄 겁니다
이 예시에서 저희는
세 가지 PS 업무가 있었고
따라서 share=true는
텐서플로우에게
이 세 가지 샤드에서
체크포인트를 적으라고 하겠죠
각각은 하나의 특정 파라미터
서버에 있는 모든 변수를
포함하는 겁니다
이는 파라미터 서버가
파일 시스템으로 직접
적을 수 있다는 의미이고
이를 쓰기 위해
한 장소에 있는 모든 값을
모을 필요가 없다는 거죠
따라서 기본 행동은 좀 안 좋습니다
왜냐하면 shared=false라고
설정하면
하나의 저장 운영으로
모든 변수를 가져올테고
이는 첫 바이트를
쓰기 전에 하나의 과정으로 메모리에서
물질화되어야 함을 의미하기 때문이죠
이렇게 큰 모델을 가지고 있다면

Portuguese: 
as sábias palavras de Leslie Lamport,
e usem sempre um protetor
em qualquer processo de treinamento longo.
Um protetor, para aqueles
que não viram isso antes
é aquilo que você usa para
escrever um ponto de verificação
dos seus parâmetros modelo
para o disco.
O mesmo protetor pode ser usado para
treinamentos locais e de distribuição
mas tem algumas funções
úteis no modo distribuído
que eu quero destacar.
A primeira é que você, 
certamente, irá querer configurar
sharded=True quando criar o seu protetor.
Neste exemplo nós temos três tarefas PS
e então sharded=True diz ao TensorFlow
"Escreva o ponto de 
verificação em três fragmentos
cada um contendo todas as variáveis
 de um servidor de parâmetros específico".
E isso significa que os
servidores de parâmetros
podem escrever diretamente
no sistema de arquivos
e não temos que coletar todos
os valores em um lugar
a fim de escrevê-los.
Na verdade, o comportamento
padrão é um pouco ruim
porque se você configurar sharded=False
trará todas as variáveis
em uma operação save
o que significa que elas terão
que ser materializadas em um processo
antes de escrever o primeiro byte.
E se você tiver esses 
modelos muito grandes

Japanese: 
Leslie Lamport の賢明な言葉を
思い出してもらえば嬉しいです。
「いかなるロングランニングトレーニング
プロセスの時も、常にセーバーを使え」
セーバーとは、まだ見た事がない方のために
説明します。
ディスクにモデルパラメータの
チェックポイントを書き出す時に使います。
同じセーバーはローカル、
そして分布トレーニングに使われます。
分布モードでは有益な特徴があることを
強調しておきます。
第一に、セーバーを作った時
「sharded equal true」をセットする予定である。
この例では、
３つの PS タスクがあります。
「sharded equal true」は TensorFlow に
３つのシャードにチェックポイントの入力を指示します。
それぞれ、特定のパラメータサーバーからの
変数を全てを包括しています。
パラメータサーバーがファイルシステムに
直接書き込めることを意味しています。
それらを書き込むために１つの場所に
すべての値を集約する必要はありません。
デフォルトの反応は、
基本的に良くありません。
「sharded equals false」をセットしたら、
すべての変数記号を
セーブ OP に持ってきます。
最初のバイトを書き込む前に、１プロセスで
メモリー内に具現化しなければなりません。
これらの大型のモデルを持っていたら、

Chinese: 
我希望你打心底里接受
莱斯利·林宝的智慧的话
总是在每个长时间运行的训练过程中
使用一个储存器
对那些之前没有见过储存器的人来说
它就是你用来把你模型参数的
检查点存到盘里的东西
同一个服务器可用来做本地和分配训练
但它在分配模式下有很多有用的特点
我将要指明
第一个就是你绝对会想
在你创建储存器是把分片的值设为真
在这个例子里，我们有三个 PS 任务
分片的值为真意味着告诉 TensorFlow
把检查点定位三个分片
每一个包含着来自
一个特定参数服务器的全部变量
这意味着参数服务器可以
直接写入文件系统
我们不需要在一个地方收集所有的值
只是为了输出它们
事实上这默认行为是不好的
因为假如你把分片的值设为假
它会把所有变量存放在一个存储 op
意味着它们在写入第一个字节前
不得不已经占有巨大的内存
假如你有这些非常大的模型

English: 
well, that's a sure way
to have a memory error.
So always use
sharded equals true.
That's if you
remember one thing.
OK, second, if you are using
between-graph replication,
you now have a choice
of several worker tasks
that could be responsible
for writing this checkpoint.
And by convention, we give
some extra responsibilities
to worker task 0.
We just picked that because
there's always a worker task
0 in our jobs, because that's
where the numbering starts.
And we call it the chief worker.
And so the chief worker has a
few important maintenance tasks
that it has to carry out,
doing things like writing
checkpoints, in this case.
Also things like
initializing the parameters
at the start of day and logging
summaries for TensorBoard.
These are all done by the chief.
And then the last
thing to note is
that savers now support a
variety of distributed file
systems.
So instead of writing
to a local file,
you can write to
Google Cloud Storage,
let's say if you're
running on Cloud ML.
Or if you're running on
top of a Hadoop cluster,
you can write straight to HDFS.
And using a distributed
file system here
is a smart idea, because it
gives you more durable storage.

Japanese: 
確実にメモリーエラーが起きているでしょう。
いつも「sharded equals true」を
使いましょう。
覚えておいて下さい。
次に、ビトイーン・グラフレプリケーションを
使っていたら
複数のワーカータスクを選ぶことができます。
このチェックポイントの書き込みを
担当します。
通常、ワーカータスク 0 に
追加の役割を持たせます。
仕事内にはワーカータスク0 が常にあるので、
例に挙げました。
ナンバーリングがここから始まります。
それをチーフワーカーと呼びます。
チーフワーカーは複数の重要な
メインテナンスタスクを持ち、
この場合だと、チェックポイントの
書き込みなどを遂行します。
一日の始めにパラメータの初期化や
TensorBoard に要約を記録します。
これは全てチーフによって行なわれます。
気がついた最後の点は、
今、サーバーは豊富な分布
ファイルシステムをサポートしています。
ローカルファイルに書き込む代わりに、
Google Cloud Storage に
書き込む事ができます。
Cloud ML を使っているなら
Hadoop cluster のトップを
動かしているのなら
直接 HDFS に書き込めます。
ここで分布ファイルシステムを使うのは、
素晴しいアイディアです。
なぜなら、より持続性のある保管場所が
得られるからです。

Spanish: 
seguro tendrán
un error de memoria.
Por eso siempre usa sharded=true.
Para que recuerden una cosa.
Segundo, si usan 
una replicación entre gráficos
ahora pueden tener 
varias tareas de trabajador
que pueden ser responsables 
de escribir este control.
Por convención, damos
responsabilidades de más
a worker task 0.
Lo hicimos así porque 
siempre hay una worker task 0
en nuestros trabajos.
Porque ahí empieza el número.
Y lo llamamos el trabajador jefe.
El trabajador jefe tiene algunas
tareas de mantenimiento a su cargo,
en este caso
escribir controles.
También como iniciar 
parámetros al comienzo del día
y registrar resúmenes para TensorBoard.
Todos los hace el jefe.
Lo último que hay que notar
es que soportan una variedad 
de sistemas de archivos.
En lugar de escribir 
en un archivo local, puedes escribirlo
en Google Cloud Storage
si, por ejemplo, lo ejecutas en CloudML.
Si lo ejecutas en un clúster Hadoop
puedes escribirlo directamente a HDFS.
Usar aquí un sistema 
de archivo distribuido
es apropiado porque 
dura más el almacenamiento.

Chinese: 
这肯定会造成内存错误
所以总是令分片值为真
假如你只能记得一件事
好的，第二，假如你在使用跨表复制
你只能选择几个工作任务
它们可以负责编写这检查点
按照惯例，我们给工作任务 0
一些格外的任务
我们选它是因为在我们的作业里面
总有一个工作任务 0
因为这就是数字开始的地方
我们称它为主要工作者
那么主要工作者要负责
一些重要的维护任务
比如写入检查点
对这个例子来说就是这样
还有其他事情比如
在一开始初始化参数
和向 TensorBoard 录入总结
这些都由主要工作者完成
最后一个要注意的事情是
存储器现在在支持很多分配文件系统
你不用写入一个本地文件
你可以写在谷歌云上
比如说你将要在 Cloud ML 上运行
或者假如你在 Hadoop 群上运行
你可以直接写入 HDFS
用那里的分配文件系统是很好的想法
因为它给你更持续的内存

Indonesian: 
itu cara pasti untuk dapat memory error.
Jadi selalu gunakan sharded=true.
Itu jika kau mengingatnya.
Kedua, jika kau memakai
between-graph replication
kau punya beberapa pilihan worker task
yang bisa bertanggungjawab untuk
menulis checkpoint ini.
Berdasarkan kesepakan,
kami berikan ke worker task 0.
Kami memilihnya karena selalu ada
worker task 0 di pekerjaan kami
karena dari sana penomorannya dimulai.
Kami memanggilnya chief worker.
Chief worker punya beberapa tugas
pemeliharaan penting yang harus dikerjakan
contohnya dalam kasus ini,
menulis checkpoint.
Juga hal lain seperti
menginisiasi parameter di awal
dan ringkasan logging TensorBoard.
Semua ini dikerjakan chief worker.
Hal terakhir ialah
saver sekarang mendukung
variasi sistem fail terdistribusi.
Daripada menulis di file lokal
kau bisa menulis ke Google Cloud Storage
jika kau menjalankannya di Cloud ML.
Atau jika menjalankannya
di atas klaster Hadoop
kau bisa langsung menulis di HDFS.
Memakai sistem fail terdistribusi
adalah ide bagus,
bisa beri penyimpanan lebih kokoh.

Korean: 
메모리 오류가 생길 가능성이 높으니
항상 shared=true를 쓰십시오
이것 하나 기억하세요
두 번째는 그래프 간 복제를
사용 중이라면
이 체크포인트를 쓰는 것을
책임질 수 있는
몇 가지 워커 업무를
선택할 수 있습니다
관례상 워커 업무0이
조금 더 많은 책임을 집니다
.
이걸 고른 이유는 워커 업무 0은 숫자가
시작하는 곳이므로 항상 있기 때문입니다
저희는 이를 치프 워커라고 부릅니다
치프 워커는 해결해야 할 몇 가지 중요한
유지보수 업무가 있고 이 경우
체크포인트를 쓰는 것과 같은 일이죠
또한 하루가 시작할 때
파라미터를 초기화하고
텐서보드에 요약을
로그하는 것과 같은 일입니다
이 모든 것이 치프가 하는 일이죠
마지막으로 언급할 내용은
이제 세이버가
다양한 분산 파일 시스템을
지원한다는 점입니다
로컬 파일에 쓰는 대신
Google 클라우드
저장소에 적을 수 있죠
클라우드 ML에서 실행한다고 합시다
혹은 하두 클러스터 상에서 실행한다면
HDFS에 바로 쓸 수 있는 거죠
이때 분산 파일 시스템을
사용하는 것은
더 오래 가는 저장소를
제공하기 때문애 좋은 생각입니다

Portuguese: 
é uma forma de assegurar
um erro de memória.
Então sempre use sharded=True.
Isto é, se vocês lembrarem
de alguma coisa.
Ok, em segundo lugar, se você 
está usando a "replicação entre gráficos"
você tem agora uma opção
em diversas tarefas worker
que poderiam ser responsáveis
por escreverem esse ponto de verificação.
Por convenção, nós damos 
algumas responsabilidades extras
para o worker task 0.
Nós escolhemos esse porque há sempre 
um worker task 0 em nossos trabalhos.
Porque é onde a numeração começa.
E nós o chamamos de worker "chefe".
O worker "chefe" tem algumas
tarefas de manutenção importantes
que ele tem que cumprir,
fazendo coisas como escrever
os pontos de verificação, neste caso.
Iniciar os parâmetros no começo do dia
e registrar resumos para o TensorBoard.
Isso é tudo feito pelo "chefe".
E então, a última coisa a observar
é que os protetores
agora suportam uma variedade
de sistemas de arquivos distribuído.
Em vez de escrever para um arquivo local
você pode escrever para o
armazenamento Google Cloud
digamos que você esteja
executando no Cloud ML.
Ou se você estiver executando
em um conjunto Hadoop
você pode escrever 
diretamente para o HDFS.
E utilizando um 
sistema de arquivos distribuído

Spanish: 
No perderás controles de modelo
si una de las máquinas falla.
También hace más fácil leer un control
desde otra máquina.
Un patrón común que usamos es que tenemos
una tarea de evaluación por separado
que se ejecuta en una máquina aparte
y que va y escoge 
el último control del modelo
y que evalúa la prueba en ella.
Esto hace que sea un poco más fácil
el tipo de coordinación 
débilmente acoplada.
Muy bien.
Ahora ya escriben puntos de control.
Es un buen paso.
Nos previene contra las fallas.
¿Pero qué es lo que sucede
cuando experimentan una falla?
En el mejor de los casos...
Hay varios casos.
Pero el más importante es que uno
de tus trabajadores comunes falle.
La razón de su importancia
es porque estos trabajadores
comúnmente no tienen estado.
Cuando un trabajador común regresa,
todo lo que tiene que hacer es contactar
todas las tareas PS de nuevo
y seguir como si nada hubiera pasado.
Comúnmente tenemos 
un admnistrador de clúster
que reiniciará un proceso fallido
tan pronto como este suceda.
Si una tarea PS falla,
es un poco peor
porque las tareas PS tienen estado.

Portuguese: 
é uma ótima ideia, porque lhe dá
um armazenamento mais durável.
Você não vai perder os seus 
modelos de pontos de verificação
se uma das máquinas pegar fogo.
E também deixa mais fácil ler
um ponto de verificação de outra máquina.
Um padrão comum que 
usamos é que temos uma tarefa
de avaliação separada sendo
executada em uma máquina diferente
que vai e escolhe o último
ponto de verificação do modelo
e avalia o conjunto de testes nela.
Então isso torna mais fácil o tipo
de coordenação fracamente acoplada.
Certo. Vocês estão escrevendo
os pontos de verificação agora.
É um bom passo.
Isso nos previne contra falhas.
Mas o que realmente acontece
quando você vivencia uma falha?
Na melhor das hipóteses...
há alguns casos a se considerar.
E o melhor é aquele em
que o seu worker normal falha.
E a razão que esse é o melhor caso
é porque esses workers são, normalmente
um tipo de "protocolo sem estado".
Então, quando um worker normal
regressa, tudo o que ele tem que fazer
é contatar todas as tarefas PS
de novo e seguir como se nada
tivesse acontecido.
E, normalmente, nós temos
um administrador de conjunto
que irá reiniciar um processo
falho assim que acontecer.
Se uma tarefa PS falhar,
é um pouco pior
porque as tarefas PS têm "estados".

Japanese: 
マシーンの１つが故障したからといって、
モデルチェックポイントは失われません。
別のマシーンからチェックポイントを読むのが
より速くなります。
使われている共通パターンは、
別のマシーンで作動する独立したタスク評価を
持っているということです。
モデルの最新チェックポイントを拾い上げ、
それについてのテストセットを評価します。
ルーズで組み合わされた調整を
多少容易にします。
チェックポイントを書き込んでいますね、
いい調子です。
失敗を防ぎます。
失敗を経験したら
実際に何が起こるのでしょうか。
最善の場合は、
考慮すべきケースが幾つかあります。
ベストなケースは、チーフではないワーカーが
失敗した場合です。
これがベストなケースの理由は、
これらのワーカーは大抵
現実的には、ステートレスだからです。
だから、もしチーフではないワーカーが
戻ってきたら
すべての PS タスクに再度コンタクトし、
何事もなかったように進めることです。
通常は、クラスターマネージャーがいます。
クラッシュすれば直ぐに、
失敗したプロセスをやり直します。
もし PS タスクが間違えたのであれば、
事態はちょっと悪いです。
PS タスクはステートフルだからです。

Korean: 
여러분 머신 중 하나에
불이 난다 하더라도
모델 체크포인트를 잃지 않는 거죠
다른 머신에서 체크포인트를 읽는 것도
더 쉽게 해 줍니다
저희가 사용하는 흔한 패턴은
별도의 머신에서
실행되는 별도의 평가 업무가 있고
이는 모델의 가장 최근
체크포인트를 뽑아서
그에 대한 테스트 세트를 평가합니다
따라서 이는 느슨하게
연결된 조합을 더 쉽게 만들어 주죠
.
좋습니다
이제 여러분은 체크포인트를 쓰고 있죠
좋은 단계입니다
실패를 막아주죠
하지만 결함이 생기면
실제로 어떻게 될까요?
최상의 경우
몇 가지 고려해야 할 사항이 있죠
최상의 경우는 취프가 아닌 워커 중
하나가 결함이 생기는 겁니다
이것이 최상의 경우인 이유는
이러한 워커들은 대체로 효율적이게도
스테이가 없기 때문이죠
치프가 아닌 워커가
백업되면 해야할 일은
PS 업무 모두에 다시 연락해서
아무 일도 없던 것처럼
지나가면 됩니다
그리고 보통 클러스터 매니저가
이것이 고장나는 순간 결함이
생긴 과정을 다시 시작합니다
PS 업무가 실패하면
조금 더 안 좋습니다
PS는 스테이트가 있으니 말이죠

Indonesian: 
Kau tak kan kehilangan checkpoint modelmu
jika satu mesin terbakar.
Juga menyederhanakan membaca
checkpoint dari mesin lain.
Satu pola umum yang kami pakai
yaitu task evaluasi terpisah
yang dijalankan di mesin terpisah
yang langsung mengambil
checkpoint terakhir dari model
dan mengevaluasi set tesnya.
Ini membuat kordinasi
dua proses tak serasi jadi lebih mudah.
Sekarang kau menulis checkpoint.
Langkah bagus.
Itu menjaga dari kegagalan.
Tapi apa yang sebenarnya terjadi
ketika kau mengalami fault?
Paling baiknya--
ada hal yang perlu dipertimbangkan.
Yang paling baik yaitu salah satu
non-chief worker gagal.
Kenapa ini paling baik karena worker ini
umumnya efektif tak berstatus.
Ketika non-chief worker kembali,
ini akan mengontak
semua task PS lagi dan melanjutkan proses
seperti tak terjadi apa-apa.
Biasanya kami punya pengelola klaster
yang me-restart proses yang gagal
secepat mungkin setelah crash.
Jika task PS gagal, jadi agak lebih buruk
karena task PS berstatus.

English: 
You're not going to lose
your model checkpoints if one
of the machines goes on fire.
It also makes it easier
to read a checkpoint
from another machine.
So one common pattern we use is
we have a separate evaluation
task that's running
on a separate machine,
and it just goes and
picks up the latest
checkpoint of the model and
evaluates the test set on that.
So this makes that kind of
loosely-coupled coordination
a bit easier.
All right.
So you're writing
checkpoints now.
That's a good step.
That guards against failure.
But what actually happens
when you experience a fault?
In the best case--
there are a few
cases to consider.
And the best case is that one
of your non-chief workers fails.
And the reason this
is the best case
is because these
workers are typically
sort of effectively stateless.
So when a non-chief worker
comes back up, all it has to do
is contact all the PS
tasks again and carry on
as if nothing happened.
And usually we have
a cluster manager
that will restart a failed
process as soon as it crashes.
If a PS task fails,
that's a little worse,
because PS tasks are stateful.

Chinese: 
假如一个设备烧了
你不会失去你模型的检查点
它也让从另一个机器读入检查点
变得更加简单
我们用的一个常用模式就是
我们建立一个独立的评估任务
它在一个独立的机器上运行
它只负责运行
并提取模型的最后一个检查点
根据它来评价测试
那么它使得不太紧密的协调
变得更加简单了
好的
你现在正在编写检查点
这是很好的一个步骤
它能防止出错
让你遇到错误的时候会发生什么呢？
最好的情况是——
我们只需要考虑有限的情况
最好的情况就是
你的非主要工作区之一出错了
它是最好的情况的原因是
这样的工作者通常是
和作业无关的
所以当一个非主要工作者恢复之后
它做的就是再次连接所有 PS 任务
并像没有事情发生一样继续工作
通常我们有一个群管理者
它会在出错时立刻重启出错的过程
假如一个 PS 任务出错了，
情况没这么好
因为 PS 任务是全状态的

English: 
All the workers are relying on
them to send their gradients
and get the new values
of the parameters.
So in this case, the chief
is responsible for noticing
the failure.
It interrupts training
on all of the workers,
and restores all the PS tasks
from the last checkpoint.
The trickiest case is when
the chief fails, because we've
given it all of these
extra responsibilities,
and we need to make sure that
we get back to a good state
when it comes back up.
So training could continue
when the chief is down,
but when it comes
back up, we don't
know if, for example,
another task has failed.
So it has to go and restore
bits from the last checkpoint.
So the thing we do is
just to interrupt training
when the chief fails.
And when it comes back up,
we restore from a checkpoint,
just like a parameter
server fails.
This is a pretty simple and
a pretty conservative scheme.
And it only really works if your
machines are reliable enough
that they aren't
failing all the time.
And it keeps the logic for
recovery really, really simple.
But depending on how common
failures are in your cluster
environment, maybe it
would be beneficial to use

Spanish: 
Todos los trabajadores confían en ellos
para enviar sus gradientes y obtener
los valores de los parámetros.
En este caso, el jefe es responsable
de notar la falla.
Interrumpe el entrenamiento
en todos los trabajadores
y restaura todas las tareas PS
desde el último control.
El caso más engañoso 
es cuando el jefe falla.
Porque se le dan
responsabilidades extra y debemos
asegurarnos de que regresemos
a un buen estado cuando este regrese.
El entrenamiento podría seguir
cuando el "jefe" falla
pero cuando regresa
no sabemos, p. ej.,
si otra tarea ha fallado
y tiene que ir y restaurar 
bits desde el último control.
Lo que hacemos es interrumpir 
el entrenamiento cuando el jefe falla.
Y cuando regresa, restauramos
desde un punto de control
tal como cuando falla
un servidor de parámetro.
Este es un esquema muy simple
y muy conservador.
Solo funciona si sus máquinas
son lo bastante confiables
como para que no fallen siempre.
Conserva bastante simple
la lógica de recuperación.
Pero dependiendo 
de qué tan comunes
sean las fallas en el entorno
de su clúster, tal vez sería benéfico

Korean: 
모든 워커가 그들의 기울기를 보내고
파라미터의 새 값을 얻는 데에
PS에 의존합니다
따라서 이 경우 치프의 임무가 결함을
눈치채는 것이죠
모든 워커의 훈련을 멈추게 하고
마지막 체크포인트에서의
모든 PS 업무를 복구합니다
가장 까다로운 경우는 치프에
결함이 생겼을 때이죠
이 모든 여분의 의무를
생각했을 때 말입니다
이것이 다시 고쳐졌을 때
좋은 상태로 돌아가도록
확인할 필요가 있죠
치프가 다운되더라도
훈련은 계속될 수 있지만
백업을 생각하면
예컨대 또다른 업무가
고장났는지 모르는 거죠
따라서 마지막 체크포인트로 가서
복구해야 합니다
저희가 하는 일은 치프에
결함이 생겼을 때
훈련을 방해하는 것 뿐이죠
다시 고쳐졌을 때 체크포인트에서
복구하는 거죠
파라미터 서버에
오류가 생겼을 때처럼 말이죠
이는 굉장히 간단하고
꽤 보수적인 스킴입니다
그리고 이는 머신이
항상 결함이 생기지 않을 만큼
충분히 믿을만 할 때만 되는 거죠
또한 복구에 대한 논리를
굉장히 간단하게 유지합니다
하지만 클러스터 환경에서 결함이
얼마나 자주 일어나는가에 따라
방해 없이 훈련이
계속 실행되도록 노력하는

Portuguese: 
Todos os workers estão contando
com eles para enviar os seus gradientes
e pegar os novos valores dos parâmetros.
Então, nesse casso, o "chefe"
é responsável por notar a falha.
Ele interrompe o treinamento
em todos os workers
e restaura todas as tarefas PS
do último ponto de verificação.
O caso mais difícil é quando
o "chefe" falha, porque nós lhe demos
todas essas responsabilidades extras
e precisamos ter certeza que
voltaremos a um bom estado
quando ele voltar.
Então, o treinamento poderia
continuar quando o "chefe" falha
mas quando ele volta, não sabemos
se, por exemplo, outra tarefa falhou.
Então temos que restaurar partes
do último ponto de verificação.
Então o que fazemos é interromper
o treinamento quando o "chefe" falha.
E quando volta, nós restauramos
do ponto de verificação
assim como quando um
servidor de parâmetros falha.
Isso é um esquema bastante
simples e conservador.
E funciona somente se as suas
máquinas são suficientemente confiáveis
que não estejam falhando a todo momento.
E mantém a lógica de 
restauração muito simples.
Mas, dependendo de quão comum
são as falhas no ambiente do seu conjunto
talvez seria favorável
utilizar uma política diferente

Indonesian: 
Semua worker bergantung PS
untuk mengirim gradiennya
dan dapat nilai baru bagi parameter.
Pada kasus ini, chief bertugas
memperhatikan kegagalan.
Hal ini mengganggu latihan semua worker
dan mengembalikan semua task PS
dari checkpoint terakhir.
Kasus tersulit yaitu ketika chief gagal
karena kita memberinya
semua tugas tambahan ini
dan kita perlu pastikan semua statusnya
baik ketika kembali dijalankan.
Latihan dapat terus berjalan
ketika chief down.
Jika sudah kembali,
kami tak tahu kalau
misalnya, ada task lain yang gagal.
Sehingga chief worker perlu mengembalikan
semuanya dari checkpoint terakhir.
Yang kami lakukan hanyalah
menyela latihan ketika chief gagal.
Ketika sudah bisa kembali,
kembalikan dari checkpoint
seperti saat parameter server gagal.
Ini skema yang cukup simpel
dan konservatif.
Hanya dapat berhasil jika
mesinmu dapat diandalkan
sehingga tidak gagal tiap waktu.
Sehingga logika pemulihannya
amat sederhana.
Tergantung pada seberapa sering
kegagalan dalam klastermu
mungkin lebih baik jika
menggunakan peraturan

Chinese: 
所有的工作者都依赖它们发送自己的梯度
并得到参数的新的值
所以在这个情况，主要工作者要负责
找出错误
它暂停所有工作者的作业
并在上一个检查点
恢复所有 PS 任务
最复杂的情况就是主要工作者出错了
因为我们给它赋予了很多额外的功能
我们需要保证当它恢复时
我们能重回到好状态
所以当主工作者出错时训练也能继续
但是当它恢复时
比如我们不知道另一个任务出错了
所以它一定要
回到上一个检查点恢复数据
我们要做的事情只是
在主工作者出错时停下训练
当它恢复时，我们从检查点开始修复
就像一个参数服务器出错了一样
这是一个很简单也很保守的方法
假如你的机器非常可靠，不会总是出错
这都是一个很好的方法
它修复的原理真的很简单
但是取决于你的群环境出错的概率多大
也许使用另外的方法也是有好处的

Japanese: 
すべてのワーカーは、勾配を送るため
そしてパラメータの新しい値を得るために
彼らを頼っているからです。
この場合は、チーフが失敗を察知する
役割を担っています。
全てのワーカーのトレーニングを中断します。
すべての PS タスクを最後の
チェックポイントから回復させます。
惑わされるのが、チーフが失敗した時です。
なぜならこれらの追加の役割を
すべて負わせていたからです。
それが復帰する時には、よい状態を作って
おかなければいけません。
チーフがダウンした時は、
トレーニングは継続可能です。
しかし復帰した時には、
他のタスクが失敗したかどうか分かりません。
行って、最後のチェックポイントから
回復させなければなりません。
ですから、チーフが失敗した時は
トレーニングは中断させます。
復帰した時は、
パラメータサーバーが落ちたと同じく
チェックポイントから回復させます。
これは非常にシンプルで、
非常に慎重なスキームです。
これは、すべてのマシーンが日頃から
失敗しないという信頼がある場合は
機能します。
非常にシンプルなリカバリーロジックを
保持していることが前提です。
しかし、クラスター環境内でどんな傾向の
失敗が起きたかにもよります。

Indonesian: 
yang membuat proses latihan
berjalan tanpa interupsi.
Aku hanya ingin memancing beberapa ide.
Yang bisa kau lakukan mungkin
memakai server manajemen konfigurasi
seperti misalnya
Apache ZooKeeper atau Etcd
untuk memilih chief worker lewat pemilihan
daripada selalu worker 0.
Ketika kau melakukannya
kau bisa memberikan tugas chief
ketika salah satu worker gagal
dan melakukan failover tanpa
mengganggu proses latihan.
Jika ada yang mau mencoba dan
memberikan kontribusinya
pasti akan keren.
Tapi jika kau memakai peraturan simpel itu
kami punya sesuatu untukmu.
Kau bisa menambahkan
class MonitoredTrainingSession
yang baru ditambahkan untuk
otomasi proses pemulihan.
Kembali ke contoh sederhana,
satu proses kita
ketika kau membuat sesi TensorFlow,
yang kau lakukan biasanya
menginisiasi variabel secara eksplisit
atau mengembalikannya dari checkpoint
sebelum memulai latihan.
MonitoredTrainingSession
sangat mirip dengan sesi tf reguler
tapi sedikit mengambil informasi
dari constructor-nya--
perlu dipastikan apa ini chief atau bukan
pastikan server yang digunakan.

Portuguese: 
que tenta manter o trabalho 
de treinamento rodando
sem interrupções.
Quero apenas que pensem por um momento.
Uma coisa que poderiam fazer é usar
um servidor de gestão de configuração
algo como Apache ZooKeeper ou Etcd
para escolher um chefe por
eleição de líder
ao invés de dizer que
sempre será o worker 0.
E se você fez isso
você pode passar a responsabilidade
de "chefe" quando um deles falhar
e fazer um failover sem interromper 
o processo de treinamento.
Se alguém quiser testar isso
e compartilhar de volta
seria muito interessante.
Mas, se você gosta da política simples
nós temos algo para você.
Vocês podem usar esta aula 
recentemente adicionada
MonitoredTrainingSession
para automatizar 
o processo de restauração.
Voltando para o nosso 
simples exemplo de processo único
quando você cria uma sessão TensorFlow,
normalmente o que você faz
é iniciar explicitamente as variáveis
ou restaurá-las do ponto de verificação
antes de iniciar o treinamento.
E a MonitoredTrainingSession parece
bastante com a sessão normal tf.
Mas você verá que usa um pouco 
mais de informação no seu construtor
precisa saber se é o "chefe" ou não

Korean: 
다른 정책을 사용하는 것이
더 나을 수도 있죠
.
그리고 전 여기에서
약간의 생각을 일으키고 싶습니다
여기서 할 수 있는 일은
항상 워커 0이어야 한다고 하기보다는
어쩌면 리더 선출에 의해
치프를 선택하기 위해
예컨대 아파치 주키퍼나 Etcd 같은
컨피겨레이션 관라 서버를
사용하는 것일 수도 있죠
그렇게 했다면 그 중 하나에
결함이 생겼을 때
치프가 되는 책임을 물려줄 수 있고
훈련 과정을 방해하지 않은 채 갑작스럽게
중단하는 거죠
누군가 이를 시도해보고
다시 기여하길 원한다면
그저 좋은 일이죠
하지만 간단한 정책을 좋아하는 분들께
드릴 것이 있습니다
복구 과정을 자동화할 최근에 추가된
MonitoredTrainingSession
클래스를 사용할 수 있죠
.
따라서 간단한
단일 과정 예시로 돌아가면
텐서플로우 세션을 만들 때 보통
훈련을 시작하기 전
변수를 외현적으로 초기화하거나
체크포인트에서 복구하겠죠
MonitoredTrainingSession는
일반적인 tf 세션 같아 보이지만
컨스트럭터에
조금 더 많은 정보를 가져가는 걸
볼 수 있을 겁니다
치프인지 아닌지 알아야 하는 거죠

Chinese: 
可以不暂停作业
保持训练作业继续运行
我想在这里引发一点思考
你可以做的事也许是
使用一个结构管理服务器
比如 Apache ZooKeeper
或者 Etcd
或者通过领导选举选择一个主工作者
而不是说它总是工作者 0
假如你这样做了
你可以在工作者之一出错的时候
把成为主工作者的责任传递下去
就像不暂停训练过程就能实现故障切换
假如有人愿意尝试这个并把它传回来
这就太棒了
假如你真的喜欢这个简单的方法
我们有一个给你的礼物
你可以用这个最近新加的类
MonitoredTrainingSession
来自动处理修复过程
回到我们简单的，单个过程的例子
当你建立一个 TensorFlow 模块
通常你要做的是在开始训练前
明确地初始化变量
或者从检查点恢复它们
MonitoredTrainingSession
看上去很像一个规律的 tf 模块
但你会发现它在它的构造器处
提取了更多的信息
它需要知道自己是不是主工作者

English: 
a different policy that tries
to keep the training job running
without interruption.
And I just want to sort of
provoke some thinking here.
One thing you could do is maybe
use a configuration management
server, something like
Apache ZooKeeper or Etcd,
to choose a chief
by leader election,
rather than saying it
always has to be worker 0.
And then if you
did that, you could
pass on the responsibility of
being a chief when one of them
fails, and kind of do a
failover without interrupting
the training process.
If somebody wanted to try that
out and contribute it back,
that would be just great.
But if you do like
that simple policy,
we've got something for you.
So you can use
this recently added
MonitoredTrainingSession
class to automate the recovery
process.
So going back to our simple,
single-process example,
when you create a TensorFlow
session, usually what you do
is you explicitly
initialize the variables,
or restore them
from a checkpoint,
before you start training.
And MonitoredTrainingSession
looks a lot like a regular tf
session, but you'll see that
it kind of takes a little bit
more information in
its constructor-- needs
to know if it's
the chief or not,

Japanese: 
トレーニング作業を中断することなく
実行し続けるという、
異なるポリシーも良策です。
ここで議論を呼ぶような考えを
紹介したいと思います。
環境設定管理サーバーを使えば、
良かったのかもしれません。
Apache ZooKeeper や
Etcd のようなものです。
ワーカー 0 であるべきだと言わずに、
リーダー選考によってチーフを
決めるべきだったのかもしれません。
そうしていれば、チーフの１つが失敗しても
その役割を他に渡して
トレーニングプロセスを中断することには
ならなかったかもしれません。
だれかがトライして、それを持ち帰れば
それは素晴しいことです。
しかし、シンプルポリシーを実践するなら
何か役に立つことをシェアできました。
リカバリー処理の自動化を学ぶ、
最近追加した MonitoredTrainingSession 
クラスをご利用下さい。
シンプルなシングルプロセス
サンプルに戻りましょう。
TensorFlow セッションを作る時、
普通実行するのが
トレーニングを始める前に、
明確に変数を初期化するか
もしくはチェックポイントから
回復させる作業となります。
MonitoredTrainingSession は
tf レギュラーセッションのようです。
しかし、そのコンストラクターに関する情報を
より多く伝えています。
それがチーフかそうでないか、どんな
サーバーを使っているかを知るためです。

Spanish: 
usar diferentes reglas 
que intenten mantener
el trabajo de entrenamiento
ejecutándose sin interrupción.
Quiero que piensen un momento.
Lo que pueden hacer es usar
un servidor de la gestión de configuración
algo como Apache Zookeeper o Etcd
para escoger un jefe 
por elección del líder
y para que no siempre 
sea el trabajador 0.
Si lo haces así, podrías pasar
la responsabilidad de jefe
cuando alguno de ellos falle
y hacer una conmutación automática
sin interrumpir 
el proceso de entrenamiento.
Si alguien lo quiere intentar
y luego lo comparte, sería grandioso.
Pero si les gusta esa simple regla,
tenemos algo para ustedes.
Pueden usar esta clase 
recientemente añadida
MonitoredTrainingSession
para automatizar 
el proceso de recuperación.
Regresando a nuestro 
ejemplo sencillo de proceso único
cuando crean una sesión de TensorFlow
lo que hacen por lo general es 
que inician explícitamente las variables
o las restauran desde un punto de control
antes de empezar el entrenamiento.
MonitoredTrainingSession
se parece mucho a una sesión regular tf
pero verán que usa un poco más 
de información en su constructor.
Necesita saber si es el jefe o no.

Portuguese: 
precisa saber que servidor 
você está usando.
E você notará que não tem mais um
init op no programa.
Em vez disso, o que a
MonitoredTrainingSession
irá fazer é assegurar automaticamente
que todas as variáveis foram iniciadas
pelos seus valores iniciais,
como as variáveis iniciais aleatórias
ou restaurando-as do último 
ponto de verificação, se disponível
antes de retornar o controle ao usuário.
E faz algo um pouco diferente
dependendo se você é o "chefe" ou não.
Então, se você é o "chefe"
ele vai verificar se há 
um ponto de verificação
ou vai executar os iniciadores.
Se você não é "chefe",
ele irá apenas aguardar
até que o chefe faça o trabalho.
E então, assim que estiver pronto
ele pode continuar a executar
o ciclo de treinamento.
Há um grande potencial aqui
para personalização.
Então nós apoiamos 
estes "ganchos" instaláveis
os quais você pode anexar
quando cria uma sessão
antes ou depois de 
iniciar a execução de uma sessão.
E a MonitoredTrainingSessios é
um tipo de conjunto desses "ganchos"
que deixam o treinamento 
distribuído mais fácil.
Então vem com "ganchos" padrões
para escrever os pontos de verificação

Japanese: 
もはやプログラムの中に init op が
ないことに気がつくでしょう。
そして MonitoredTrainingSession は
どんなことをするのかというと、
すべての変数が初期化することを
自動的に確認するということです。
無作為な初期値変数のように初期値から、
ユーザーにコントロールが戻る前に、
チェックポイントが入手可能であれば
最後のチェックポイントから回復させるという
方法を使います。
チーフかそうでないかによって、
わずかに異なってきます。
もしチーフであれば、
チェックポイントはあるか見に行き、
もしくは初期化を作動させることになります。
チーフでなければ、チーフが回復するまで
じっと待つことになります。
そして完了したら直ぐに、
トレーニングループを作動させます。
カスタマイズの可能性がたくさんあります。
セッションを作る時、もしくは
セッションランコールする前後に付けれる
インストール可能な
これらのフックをサポートします。
MonitoredTrainingSession は
これらのフックのセットが配置されています。
分布トレーニングを少し容易にするものです。
10 分ごとにチェックポイントを書き、
100 工程ごとにサマリーを書くための

Spanish: 
Necesita saber qué servidor usas.
Se darán cuenta que ya no hay 
init op en el programa.
En su lugar, lo que hará
MonitoredTrainingSession
será que asegurará automáticamente
que todas las variables
hayan sido iniciadas.
Sea desde sus valores iniciales,
como las variables iniciadas al azar
o restaurandolas 
desde el último control
si hay uno disponible,
antes de que le regrese 
el control al usuario.
Y hace algo un poco distinto
dependiendo de si eres el jefe o no.
Si eres el jefe, irá a buscar
un punto de control
o va a ejecutar los iniciadores.
Si no eres el jefe, espera
hasta que el jefe haga su trabajo.
Tan pronto termine
puede llevar a cabo la ejecución 
del bucle de entrenamiento.
Hay mucho potencial 
para la personalización.
Admitimos estos ganchos instalables
que puedes colocar cuando creas una sesión
o antes o después de llamar 
la ejecución de una sesión.
MonitoredTrainingSession es un tipo
de ganchos preelaborados que hacen
que el entrenamiento distribuido 
sea un poco más fácil.
Viene con ganchos estándar
para escribir un control cada 10 minutos

Indonesian: 
Kau akan melihat tak ada lagi
init op dalam programnya.
Daripada itu, yang akan dilakukan
MonitoredTrainingSession
adalah memastikan semua variabel
telah diinisiasi secara otomatis
baik dari nilai awalnya
seperti variabel inisiasi random atau
mengembalikannya dari checkpoint terakhir
saat tersedia, sebelum mengembalikan
kontrolnya ke pengguna.
Kerjanya berbeda,
bergantung chief atau bukan.
Jika chief, akan mencari adanya checkpoint
atau menjalankan penginisialisasi.
Jika bukan chief, ini akan menunggu
hingga chief mengerjakan tugasnya.
Ketika selesai, ini dapat
melanjutkan proses perulangan latihan.
Banyak sekali potensi
kustomisasi untuk ini.
Jadi kami mendukung installable hooks
yang bisa kau tempelkan
baik saat kau membuat sesi
atau sebelum atau setelah
melakukan run call sesi.
MonitoredTrainingSession seakan
seperti hasil kurasi hook ini
yang membuat latihan terdistribusi
jadi lebih mudah.
Hook standar menulis
checkpoint tiap 10 menit

Chinese: 
还需要知道你在使用什么服务器
你会发现现在程序里再也没有 init op
MonitoredTrainingSession
将要做的是
它会自动确保
所有的变量要不已经是初始化的值
比如一个初级初始化的变量
或者假如有最新的检查点的话
它在把控制权还给用户前会确认
参数已经存了最新检查点的值
取决于你是主工作者与否
它还会做一点稍微不同的事情
所以假如你是主工作者
它就会去搜索是否有检查点
或者它将会运行初始化器
假如你不是主工作者
它只会停在那里
等到主工作者开始工作
它结束的同时
它能继续运行训练循环
这里还有很多自定义的机会
我们支持这些可安装挂件
你可以在你完成创建模块的时候
或者是运行模块运行命令前后加入它们
MonitoredTrainingSession
是这些挂件的精美的策划组合
它让分配训练更加容易
每十分钟它都随着
编写检查点的挂件出现一次

Korean: 
어떤 서버를 사용하고
있는지 알아야 하죠
또한 더이상 프로그램에서
초기 운영이 없음을 눈치채실 겁니다
대신 MonitoredTrainingSession은
무작위로 초기화된 변수와
같은 초기 값이나
사용자로 컨트롤이 돌아오기 전
가장 최근의
체크포인트로부터 복구함으로써
모든 변수가 자동으로 초기화되도록
확실히 할 겁니다
.
또한 이는 치프인가 아닌가에 따라
조금 다른 일을 합니다
치프라면
체크포인트가 있는지 확인하거나
이니셔라이저를 실행할 겁니다
치프가 아니라면
치프가 일을 끝낼 때까지
앉아서 기다리기만 하겠죠
그리고 나서 일이 끝나자마자
훈련 루프를 계속해서 실행하면 됩니다
여기에는 맞춤화를 위한
잠재력이 많습니다
따라서 저희는 여러분이
세션을 만들 때나
세션 실행 콜을 하기
전후에 첨부할 수 있는
설치가능한 후크를 지원합니다
MonitoredTrainingSession은
분산 훈련을 조금 더 쉽게 만들어주는
이러한 후크의 멋있게
만들어진 세트인 겁니다
이는 매 10분마다 체크포인트를 쓰고

English: 
needs to know what
server you're using.
And you'll note that there's no
init op in the program anymore.
Instead, what the
MonitoredTrainingSession
is going to do is it
will automatically
ensure that all of the variables
have been initialized either
from their initial
values, like the randomly
initialized variables, or by
restoring them from the latest
checkpoint if one is available,
before it returns control back
to the user.
And it does something slightly
different depending on
if you're the chief or not.
So if you're the
chief, it's going
to go and look and see
if there is a checkpoint,
or it's going to run
the initializers.
If you're not the chief,
it just sits there waiting
until the chief does its work.
And then as soon
as it's done, it
can carry on running
the training loop.
There's a lot of potential
for customization here.
So we support these
installable hooks
that you can attach either
when you create the session
or before or after doing
a session run call.
And the
MonitoredTrainingSession is
sort of a tastefully
curated set of these hooks
that makes distributed
training a bit easier.
So it comes with standard
hooks for writing a checkpoint

Portuguese: 
a cada dez minutos, escrevendo
resumos a cada 100 passos.
E se você quiser, você pode
personalizar seu comportamento
adicionando mais "ganchos" 
ou substituindo os que já estão lá.
Ok, por fim, neste momento
alguns de vocês devem estar pensando
"Uau, é preciso muito esforço
para executar o treinamento
em um conjunto distribuído".
"Pode ser mais fácil?"
Sim, se você fizer as coisas do zero
e se você usar uma API de nível baixo
há muitas coisas que você precisa cuidar.
Mas não tenha medo, porque,
como vocês podem lembrar
da palestra do Martin de manhã
nós temos agora esses API de nível alto, 
os quais têm um grande suporte
para treinamento e avaliação 
em uma única máquina.
E há um nível de suporte 
tf contrib para treinamento
em um conjunto distribuído.
Então como isso se parece?
Bom, este suporte 
de treinamento distribuído
utiliza uma classe recentemente
adicionada chamada de Experiment
para "empacotar" o treinamento
e a avaliação estimador usando o conjunto.
Então, quando você cria um experimento
você integra um estimador
com algumas funções de entrada.
Você irá dizer a ele como
ler um conjunto de dados

Indonesian: 
menulis ringkasan tiap 100 langkah.
Jika mau, kau bisa
menyesuaikan perilakunya
dengan menambahkan hook
atau mengganti hook yang ada.
Terakhir, saat ini
kalian mungkin berpikir,
wow, banyak sekali langkah
untuk sekadar menjalankan latihan
di klaster terdistribusi.
Apa bisa lebih mudah?
Ya, jika kau mulai dari nol
dan jika kau memakai API level rendah
ada banyak sekali hal yang
harus kau kerjakan.
Jangan takut, karena jika kau ingat
sesi Martin pagi ini
sekarang kami punya API level tinggi
yang sangat mendukung
latihan dan evaluasi pada satu mesin.
Ada juga tf contrib level support
untuk latihan pada klaster terdistribusi.
Seperti apa itu?
Dukungan latihan
terdistribusi ini memakai
kelas yang baru ditambahkan
bernama Experiment untuk
membungkus latihan dan evaluasi
estimator memakai klaster.
Ketika kau membuat experiment
bungkus estimator
dengan beberapa fungsi input.
Kau perintahkan untuk membaca
set data tertentu

English: 
every 10 minutes, writing
summaries every 100 steps.
And if you want to, you
can customize its behavior
by adding more
hooks or replacing
the ones that are there.
OK, finally, by this
point, some of you
might be thinking, wow,
that is a lot of effort
that you have to go to
just to run training
on a distributed cluster.
Can it be easier?
And yeah, well, if you
do things from scratch,
and if you use
the low-level API,
there are a lot of things
that you have to take care of.
But fear not, because
as you might remember
from Martin's talk
this morning, we now
have these high-level
APIs that have
great support for training and
evaluation on a single machine.
And there's tf contrib
level support for training
on a distributed cluster.
So what does that look like?
Well, this distributed
training support
uses a recently added class
called Experiment to package up
the training and evaluation of
an estimator using a cluster.
So when you create
an experiment,
you bundle together an estimator
with some input functions.
You tell it how to read
a particular data set

Spanish: 
y escribir resúmenes cada 100 pasos.
Si lo desean, pueden 
personalizar su conducta
agregando más ganchos 
o reemplazando los que hay.
Finalmente llegados a este punto,
algunos pensarán que es mucho esfuerzo
el que tienen que hacer 
solo para ejecutar el entrenamiento
en un clúster distribuido.
¿Puede ser más fácil?
Sí, si lo hacen desde cero
y si usan un API de bajo nivel
tendrán que encargarse de muchas cosas.
Pero no teman porque como recordarán
de la plática de Martín de esta mañana,
ahora tenemos estos API de alto nivel
que apoyan bastante
el entrenamiento
y la evaluación 
en una máquina.
Tenemos el nivel de soporte
tf contrib para entrenar
en un clúster distribuido.
¿Cómo se ve?
Este soporte de entrenamiento distribuido
usa una clase 
recientemente ingresada
llamada experiment para empaquetar 
el entrenamiento y la evaluación
de un estimador usando un clúster.
Cuando crean un experimento
integran un estimador 
junto con algunas funciones de entrada.
Le dicen como leer 
un grupo particular de datos

Chinese: 
每 100 步会写一次总结
假如你愿意，你可以通过添加更多挂件
或者替换已经存在的挂件
自定义它的行为
好的，最后到了这里
你们中的一些人可能会想
哇，要训练一个分配群
你真的要做很多东西
它能变得更简单吗？
是的，假如你从头做起
假如你使用低级的应用程序接口
你还要关心很多事情
但不要害怕，因为你可能还记得
马丁今天早上的演讲
我们现在有了高级的应用程序接口
它们能在一个机器上
极大地支持训练和评估
还有 tf contrib 级的
支持在分配群内的训练
这看起来像什么呢？
这分配训练支持
使用新加入的叫做实验的类
使用群来打包估计量的训练和评估
当你创建了一个实验
你把一个估计量
和一些输入函数组合在一起
你告诉他要如何读取特定的数据集

Korean: 
100 단계마다 요약을 하는
표준 후크와 함께 옵니다
그리고 원하시면
더 많은 후크를 추가하거나
이미 있는 것을 대체함으로써 행동을
맞춤화할 수 있죠
마지막으로 이쯤 되면
여러분들 중 일부는
이렇게 생각하실 겁니다
분산 클러스터에서 훈련 실행만 하는데
너무 많은 노력이 든다고 말이죠
더 쉬울 수는 없을까요?
처음부터 시작하고
저수준 API를 사용하면
해결해야 할 일들이 많죠
하지만 두려워 마십시오
오늘 아침 마틴의 발표를 기억하시겠지만
저희는 이제 단일 머신에 대한
훈련과 평가를 위해 아주 훌륭한
지원이 되는 고등 API가 있습니다
또한 분산 클러스터에서 훈련을 위한
tf contrib 레벨의 지원도 있죠
어떻게 생겼을까요?
이 분산 훈련 지원은
클러스터를 사용한 에스티메이터의
훈련과 평가를 패키지화 한
실험이라고 불리는 최근에
추가된 클래스를 사용합니다
실험을 만들 때
에스티메이터와 다른 인풋 기능
몇 가지를 함께 묶겠죠
여러분이 훈련과 평가를 위해
특정 데이터 세트를

Japanese: 
標準フックを装備しています。
必要ならば、より多くのフックを追加し
また１つずつの配置を換えて、
様式をカスタマイズすることができます。
それではこの段階で、非常に苦労すると
思っているのではないでしょうか。
分布クラスター上でトレーニングを
作動させるだけです。
もっと簡単にならないでしょうか。
ありあわせのもので対処し、
ローレベルの API を使うならば、
たくさんのことを
気に掛けなくてはいけません。
心配しないで下さい、今朝マーティンが
話したことを覚えていれば
これらのハイレベルの API を
持っていれば、
シングルマシーンでトレーニングと
評価の多大なサポートが得られます。
そして分布クラスター上でのトレーニングに
tf contrib レベルのサポートがあります。
いかかでしょうか。
この分布トレーニングサポートは、
Experiment と呼ばれる最新のクラスを用いて
クラスターを使ったエスティメーターの
トレーニングと評価をパッケージした物です。
実験を作った時、
インプット機能を持つエスティメーターを
バンドルし、

English: 
for training and for evaluation.
You give it some more
configuration options.
And here you could specify
a little canned estimator
in a few lines, so this is
a pre-canned DNN classifier
with two hidden layers.
You could do
something more fancy
by passing in a
custom model function,
or you could even pass
a Keras model in there
to do distributed training.
And you wrap that in an
experiment function and pass
that function to something
called learn_runner.run, which,
if you're running on Cloud ML,
will pick up the configuration
from the environment and it will
run the appropriate low-level
APIs for you.
So your code can be
almost as simple as this.
It's probably, like,
five lines of boilerplate
that you'd need at the top
to run distributed training.
Actually, I've been told--
Martin told me that the contrib
function learn_runner is
going to change its name soon.
So I know we're
1.0, but we still
like changing names of things.
This code example is a
little bit more aspirational
than some of the
others, but hopefully it
gets across the idea
that the high-level APIs
can take care of a lot of
the gory details for you.
And so yeah.

Japanese: 
トレーニングと評価用に独特のデータセットを
どのように読むか指示できます。
さらなる環境設定オプションを指示できます。
数行で Canned エスティメーターを
例示できます。
これは２つの隠しレイヤーを伴う
pre-canned DNN classifier です。
カスタムモデル機能内で、もしくは Keras モデルを
分布トレーニングにパスして
より高度なことを実現することができます。
実験的機能内で包み、機能を learn_runner.run と
呼ばれるものにパスします。
Cloud ML 上で作動しているなら、
環境から環境設定を抽出し
適切なローレベルAPI を作動させます。
コードがこのようにかなり
シンプルになっているなら、
ボイラープレートの５行に
なっているでしょう。
頂点て分布トレーニングを作動させる
必要があります。
事実、マーティンが contrib 機能 learn_runner は
名前が変わると言っていました。
今は 1.0 ですが、
名前を変えるのが好きなのです。
このコードサンプルは、
他に比べて多少上昇志向です。
ハイレベル API が難しい詳細の多くを
考慮することができるという、
アイディアが実現することを祈っています。
トレーニングプロセスが標準様式に従えば
これらのエスティメーターは、

Korean: 
읽는 법을 말해주는 겁니다
더 많은 컨피겨레이션 옵션을 주는 거죠
작은 이미 만들어진
에스티메이터를 몇 줄의 라인으로
구체화할 수 있으므로
이는 두 가지 숨겨진 레이어가 있는
미리 정해진 DNN 클래시파이어입니다
맞춤 모델 기능을 전함으로써
더욱 고급스러운 것을 할 수도 있고
분산 훈련을 하기 위해
심지어 케라스 모델을
보낼 수도 있습니다
이를 실험 기능으로 싸서 그 기능을
learn_runner.run이라고
불리는 것으로 전해주는 거죠
이는 클라우드 ML에서 실행하면
환경에서 컨피겨레이션을 뽑아서
적절한 저수준의 API를
실행시킬 겁니다
.
따라서 코드가 이 정도로 간단할 수 있죠
아마 분산 훈련을
실행하기 위해 제일 위에
필요한 표준 문안의 다섯 라인정도겠죠
사실 제가 들은 바로는
마틴이 말하길
contrib 기능 learn_runner는
이름을 곧 바꾼다고 합니다
저희가 1.0버전인 걸 알지만
여전히 이름 바꾸는 걸 좋아하죠
이 코드 예시는 다른 것보다 조금 더
영감을 주지만 바라건데
고등 API가 굉장한 세부사항을
해결해줄 수 있다는
생각을 가지게 하는 시간이었으면 좋겠습니다
네

Portuguese: 
para treinamento e avaliação.
Você dá mais opções de configuração.
E você pode especificar um pequeno
estimador elaborado em poucas linhas.
Então isso é um 
classificador DNN pré-elaborado
com duas camadas ocultas.
Você pode fazer algo mais sofisticado
passando em um modelo 
de função personalizado
ou você até mesmo poderia
passar um modelo Keras
para realizar o treinamento distribuído.
E você envolve isso
em uma função experiment
e passa essa função para algo
chamado learn_runner.run
o qual, se você está executando no
Cloud ML, irá escolher a configuração
do entorno e irá executar
a API de nível baixo adequada para você.
Então o seu código pode 
ser tão simples quanto este.
São, provavelmente, 
cinco linhas de boilerplate
que você precisará no início
para executar o treinamento distribuído.
Na verdade, me disseram...
o Martin me disse que a função
contrib learn_runner
irá mudar de nome em breve.
Eu sei que estamos no 1.0
mas ainda gostamos de mudar
as coisas de nome.
Este exemplo de código é um
pouco mais ambicioso do que outros
mas esperamos que transmita a ideia
de que APIs de nível alto
podem cuidar de muitos 
detalhes pesados para vocês.
E então...

Indonesian: 
untuk latihan dan evaluasi.
Berikan juga beberapa
opsi konfigurasi.
Kau bisa menentukan canned estimator
dalam beberapa baris
jadi ini pre-canned DNN classifier
dengan dua layer tersembunyi.
Kau bisa lebih gaya dengan
menambahkan fungsi model custom
atau bahkan menambahkan model Keras
untuk melakukan latihan terdistribusi.
Lalu bungkus semuanya
di fungsi eksperimen
dan memberikan fungsi itu ke
learn_runner.run
yang jika kau jalankan di Cloud ML
akan ambil konfigurasinya dari lingkungan
dan menjalankan API level rendah
yang sesuai untukmu.
Jadi kodemu dapat sesederhana ini.
Mungkin sekitar lima baris boilerplate
yang kau perlukan di atas untuk
menjalankan training terdistribusi.
Aku diberitahu--
Martin bilang fungsi contrib learn_runner
akan segera berganti nama.
Aku tahu kami masih 1.0 tapi
kami suka mengubah nama-nama.
Contoh kode ini sedikit
lebih aspiratif dibanding yang lain
tapi harapannya ini dapat menyampaikan
pesan bahwa API level tinggi
dapat menyelesaikan masalah besar bagimu.

Chinese: 
用于训练和评估
你给予它更多的结构选择
在这里你可以在几行内
指定一个小封装估计量
所以这里有一个带有两个隐藏层的
预制 DNN 分类器
你可以通过传递一个自定义模型函数
实现更高级的功能
你甚至可以传递一个克拉斯模型
进行分配训练
你把它们组合为实验函数
并把这个函数传递到一个叫做
learn_runner.run
假如你在 Cloud ML 上运行
它会从环境中提取结构
还有为你运行合适的低级应用程序结构
所以你的代码可以像这个一样简单
这大概是创建样板的五行
就是你运行分配训练最初需要的东西
事实上，有人对我说——
马丁对我说 contrib 函数
learn_runner
很快就会改名
我知道我们只是 1.0
但我们还是很爱为东西改名字
这个代码实例比其他的更加梦寐以求
希望它能获取
高级应用程序结构
可以为你完成很多
麻烦的细节的想法
是的

Spanish: 
para el entrenamiento 
y para la evaluación.
Le dan algunas 
opciones de configuración más.
Aquí pueden especificar
un pequeño estimador
en unas cuantas líneas.
Este es un clasificador DNN preelaborado
con dos capas ocultas.
Podrían hacer algo más sofisticado
pasando un modelo 
de función personalizado
o podrían pasar un modelo Keras
para hacer el entrenamiento distribuido.
Lo envuelven en una función experiment
y la pasan a algo llamado
learn_runner.run, el cual
si usan Cloud ML,
escogerá la configuración
desde el entorno y ejecutará por ti
las API de nivel bajo apropiadas.
Por lo que tu código 
puede ser así de simple.
Son probablemente cinco líneas 
de elementos repetitivos
que necesitarias al inicio para ejecutar 
el entrenamiento distribuido.
Me han dicho...
Martin me dijo que la función 
contriblearn runner
cambiará su nombre muy pronto.
Se que estamos aún en 1.0
pero nos gusta cambiarle 
el nombre a las cosas.
Este ejemplo de código tiene 
más aspiraciones que algunos otros
pero esperamos que se deje la idea
de que los APIS de alto nivel
pueden llevar a cargo muchos 
de los detalles pesados por ustedes.
Sí.

Spanish: 
Estos estimadores son geniales
si su proceso de entrenamiento
sigue un patrón estándar.
Nueve de diez veces
son lo que querrán usar
cuando ejecuten TensorFlow distribuido.
Pueden comenzar ejecutando su programa
en centros de datos como estos
de forma inmediata.
Pero a veces querrán
cambiar las reglas
si tienen requisitos más complicados
o si quieren ir fuera de lo convencional.
En esta plática, les he mostrado
cómo TensoFlow distribuido
te da la flexibilidad para hacerlo.
Pueden aumentar el entrenamiento
a cientos de GPU.
Pueden entrenar una cantidad
enorme de modelos
con decenas de miles de millones 
de parámetros.
Y pueden elegir entre personalizar
cada detalle de la ejecución
o definir todo el proceso de entrenamiento
en solo unas cuantas líneas de código.
Si les interesa aprender más
sobre TensorFlow distribuido
los invito a que revisen estos vínculos,
que cubren este tipo de arquitectura 
de sistema de bajo nivel,
el API distribuido de bajo nivel.
Ahora quiero agradecerles 
a todos ustedes
y a los que nos siguen en vivo,
por escucharme.
Muchas gracias a todos.

Portuguese: 
esses estimadores são ótimos
se o seu processo de treinamento
segue um padrão normal.
E nove em cada dez vezes
eles, provavelmente, são o que você
vai querer usar quando executando
o TensorFlow distribuído.
Então vocês podem começar
a rodar os seus programas
em centros de dados
como estes, imediatamente.
Mas às vezes você vai querer
quebrar as regras.
Se você tiver alguns 
requisitos mais complicados
ou se você quiser sair da...
pensar um pouco fora da caixa.
Nessa palestra eu mostrei 
a vocês como o TensorFlow distribuído
te proporciona flexibilidade
para fazer isso.
Você pode aumentar o treinamento
para centenas de GPUs.
Você pode treinar modelos gigantescos
com dezenas de bilhões de parâmetros.
E você pode escolher entre
personalizar cada último detalhe
da execução ou definir todo
o processo de treinamento
em apenas algumas linhas de código.
Se estiverem interessados 
em aprender um pouco mais
sobre o TensorFlow distribuído,
eu os convido a conferir estes links
os quais cobrem esse tipo de 
arquitetura de sistema de nível baixo
API distribuído de níveis baixo e alto
Mas agora eu gostaria de agradecer
a todos aqui presentes
e àqueles no livestream
por terem nos acompanhado.
Muito obrigado a todos!

Korean: 
여러분의 훈련 과정이 표준 패턴을 따른다면
이 에스티메이터는 훌륭하죠
열에 아홉은
분산 텐서플로우를 실행할 때 사용하고 싶은
경우일 겁니다
이제 바로 이러한
잘 밝혀진 데이터 센터에서
실행되는 여러분의 프로그램을
시작할 수 있는 거죠
.
하지만 때로는
좀 더 복잡한 요구사항이 있다면
규칙을 바꾸길 원하시겠죠
혹은 조금 독창적인 생각을
하고 있다면 말이죠
이번 발표에서 저는 분산 텐서플로우가
이렇게 하기 위한 융통성을 준다는 점을
보여 드렸습니다
훈련을 수백개의 GPU로 확장할 수 있죠
수백억개의 파라미터가 있는
말도 안 되게 많은 모델을
훈련시킬수도 있습니다
실행의 모든 세부사항을 맞춤화하거나
모든 훈련 프로세스를 몇 줄의 코드로 정하는 것
사이에서 선택할 수 있죠
분산 텐서플로우에 대해
좀 더 알고 싶으시면
이 링크를 확인해 보시길 바랍니다
이러한 저수준 시스템 건축과
저수준 분산 API와
고수준 API를 다룹니다
이 시점에서 이 방에 계신 모든 분들과
라이브스트림 시청자분들께
감사드리고 싶습니다
모두 감사드립니다

Indonesian: 
Ya. Estimator ini hebat jika proses
training-mu mengikuti pola standar.
Sembilan dari sepuluh mereka mungkin
apa yang ingin kau pakai saat kau
jalankan TensorFlow terdistribusi.
Jadi kau bisa mulai menjalankan programmu
pada pusat data berpenerangan baik
seperti ini dengan segera.
Tapi kadang kau bosan mengikuti aturan
jika kau punya persyaratan
yang lebih rumit
atau sedikit keluar dari--
berpikir sedikit di luar kotak.
Kuperlihatkan cara
TensorFlow terdistribusi
memberimu fleksibilitas untuk itu.
Kau bisa meningkatkan training
ke ratusan GPU.
Kau bisa training model yang luar biasa
besar dengan puluhan milyar parameter.
Dan kau bisa memilih antara
menyesuaikan semua detail eksekusi
atau definisikan keseluruhan proses
latihan dalam beberapa baris kode.
Jika kau tertarik mempelajari
TensorFlow terdistribusi lebih jauh
kusarankan kau menuju tautan-tautan ini
yang menjelaskan arsitektur sistem
tingkat rendah seperti ini
API terdistribusi tingkat rendah
dan API tingkat tinggi.
Sampai di sini.
Terima kasih pada semua yang di sini
dan yang menonton siaran langsung.
Terima kasih banyak semuanya.

Chinese: 
我的意思是，假如你的训练过程
跟着标准格式的话，这些估计量就很好
十之八九
它们可能是你在运行
分配 TensorFlow 时
你将要用到的东西
所以你可以立刻开始
让你的程序在
如这样精致的数据中心上运行
但有时候你想改变规则
假如你有一些更复杂的请求
或者你想要另辟蹊径
在这个演讲里，我向你们展示了
分配 TensorFlow
如何给你们提供了
实现这些的可能性
你可以把训练扩展到上百的图形处理器
你可以用百亿的参数
训练大得可怕的模型
你可以选择自定义执行过程的每个细节
或者仅用几行代码
就定义整个训练程序
假如你有兴趣学习更多
关于 TensorFlow 的知识
我希望你们点击这个链接
它涵盖了这类低级系统结构
低级分配应用程序接口
和高级应用程序接口
但现在，我想要感谢现场的你们
还有在收看直播的观众
非常感谢你们

English: 
I mean, these estimators are
great if your training process
follows a standard pattern.
And nine times
out of 10, they're
probably what you're going
to want to use when you're
running distributed TensorFlow.
So you can start
getting your program
running on nicely-lit data
centers like these in no time
at all.
But sometimes you're going
to want to bend the rules,
if you have some more
complicated requirements,
or you want to go
slightly outside the--
think slightly outside the box.
So in this talk,
I've shown you how
distributed TensorFlow
gives you the flexibility
to do just that.
You can scale training
out to hundreds of GPUs.
You can train outrageously large
models with tens of billions
of parameters.
And you can choose between
customizing every last detail
of the execution or defining
the whole training process
in just a few lines of code.
If you're interested in learning
a bit more about distributed
TensorFlow, I'd encourage
you to check out
these links, which cover
this sort of low-level system
architecture, the
low-level distributed
API and the high-level API.
But at this point, I'd like to
thank all of you in the room
and on the livestream
for listening.
Thanks, all, very much.

Japanese: 
素晴しい結果を出します。
分布された TesorFlow を作動している時、
10 回のうち 9 回は使いたくなると思います。
すぐに、これらのような
非常に軽いデータセンターで
プログラムを作動し始めることが
できるでしょう。
時々、ルールを破りたくなるかもしれません。
より複雑な要件を手にした時、
または少しだけ道を逸れたい時など
少しだけ外の世界を考えている時など、
このスピーチでは、みなさんに
分布された TensorFlow が
フレキシビリティを与えてくれるか
お話ししました。
トレーニングを膨大な GPU に達するまで
増長することができます。
法外に大きなモデルを莫大な数のパラメータで
トレーニングすることができます。
実行情報の最新の詳細すべてを
カスタマイズするか、
数行のコードでトレーニングプロセス全体を
限定するかを選ぶことができます。
分布された TensorFlow について
さらなる情報が必要であれば、
これらのリンクをぜひご覧になって下さい。
ローレベルシステムアーキテクチャー、
ローレベル分布 API
ハイレベル API についての情報を
網羅しています。
そして会場にいらっしゃる皆さん、
そして livestream でお聞きになられた
皆さんに感謝申し上げます。
ご清聴ありがとうございました。

Korean: 
[박수]
.

English: 
[APPLAUSE]

Chinese: 
[鼓掌]
