►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Building ML Products With Kubeflow - Jeremy Lewi, Google & Stephan Fabel, Canonical (Intermediate Skill Level)
ML researchers spend too much time building infrastructure to support their work. Kubeflow aims to solve that by using Kubernetes to build an open, scalable, and extensible platform for ML. Since our launch at Kubecon in December, Kubeflow has grown to a substantial Github community with over 2200 stars and contributors from companies across the Kubernetes ecosystem, including Red Hat, Canonical, Weaveworks, CoreOS, CaiCloud, Alibaba, NVidia and many more. In this talk, we discuss how Kubeflow enables machine learning workflows that are easy enough for anyone to deploy, and run anywhere Kubernetes runs. We will talk about our experience building Kubeflow by leveraging Kubernetes technologies like CRDs and ksonnet to build an extensible, community driven ecosystem. Finally, we will talk about how we are trying to grow the community around Kubeflow to continue evolving the platform.
About Jeremy Jeremy Lewi is a co-founder and lead engineer at Google for the Kubeflow project, an effort to help developers and enterprises deploy and use ML cloud-natively everywhere. He's been building on Kubernetes since its inception starting with Dataflow and then moving onto Cloud ML Engine and now Kubeflow.
About Stephan
Stephan Fabel is Product Manager for all things cloud at Canonical and has been working on enabling Kubeflow on Canonical’s Distribution of Kubernetes. Stephan has been working with OpenStack and Kubernetes for over four years and led some of the world’s most challenging cloud implementations.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
A
There
are
several
talks
regarding
coop
flow
I.
Don't
know
if
you've
noticed
this,
but
you
know
we're
all
about
machine
learning
just
these
days,
so
you
know
you,
you
missed
a
couple
already
if
you,
if
you
haven't
attended
them,
but
there's
a
couple
more
here.
So
Jeremy
is
gonna.
Do
a
deep
dive
into
coop
flow
intestines.
Yes,
all
the
way
in
so
a
little
later.
Today,
then
there
is
another
another
talk
about
data
management
and
finally,
tomorrow
we've
got
a
keynote.
That
I
would
encourage
you
to
attend.
A
So,
first
of
all,
the
recognition
is
that
machine
learning
is
everywhere
these
days.
You
see
this
in
connected
cars
in
smart
cities,
and
you
know
at
home
the
whole
you
know,
translation
engine
of
Google
is
built
on
on
machine
learning.
Obviously
you
have
you
know
you
connect
the
devices
at
home,
the
echos,
the
series
etc,
the
the
natural
language
processing,
the
image
processing,
the
image
recognition,
the
computer
vision.
All
of
those
things
obviously
now
are
backed
by
machine
learning.
The
self-driving
cars
is
a
huge
effort.
A
You
know,
Wayne
will
put
in
I
think
three
hundred
thousand
miles
last
year,
self-driving
cars
you've
had
you
have
a
hundred
fifty
thousand
miles,
you
know
with
Ford.
Gm
is
falling
closely
behind,
so
machine
learning
is
behind
all
of
those
decisions
and
obviously
now
there's
a
couple
of
issues
that
you
would,
as
you
can
imagine,
as
you
roll
this
out
at
scale
in
a
distributed
fashion.
A
So,
first
of
all,
people
assume
that
when
you
deploy
a
machine
learning
products
that
really
mainly
this
is
about
machine
learning
code,
you
would
expect
that
the
majority
of
the
code
that
you
write
would
have
something
to
do
with
machine
learning
and
that
the
other
things
that
are
sort
of
gathered
around
this.
The
central
block
here
would
just
be
sort
of
taken
care
of
right.
A
Your
machine
learning
code
gets
deployed
into
this
bubble
and
and
then
all
those
tools,
the
the
process,
management
to
feature
extraction,
the
monitoring,
the
infrastructure,
etc
is
sort
of
you
know
it's
there
right.
You
assume
it's
there,
but
actually
this
is.
This
is
very
far
from
the
truth.
The
machine
learning
code
is
actually
very,
very
small,
because
the
intelligence
is
often
expressed
in
only
a
couple
of
lines
of
code,
as
Jeremy
will
show
you
later
and
really
most
of
the
problems
that
you're
having
are
going
to
be
in
those
other
boxes.
A
A
B
Yeah,
so
with
cube
flow,
our
goal
was
to
take
advantage
of
kubernetes
to
solve
a
lot
of
these
DevOps
challenges,
and
so
we
started
building
cube
flow,
which
is
a
platform,
a
kubernetes
native
platform
for
ml
and
our
tagline,
and
our
goal
is
really
to
make
it
really
easy
to
use
kubernetes
to
build
ml
products
that
are
portable.
So
you
can
run
them
wherever
kubernetes
runs.
B
So
what
what
specifically
is
coop
flow?
It's
really
two
things,
first
and
foremost,
we're
a
community.
So
we
are
a
community
of
data
scientists
and
researchers,
DevOps
product
managers
and
what
we're
doing
is
a
COO
as
the
community
is
we're
all
coming
together
to
sort
of
work
together
to
build
a
community
driven
platform
that
takes
advantage
of
kubernetes
and
makes
kubernetes
the
best
platform
for
running
ml
and
the
reason
that
we're
doing
this
is
because
we
there's
a
growing
recognition.
B
I
think
that
building
an
ml
platform
is
a
really
big
problem
to
take
on
and
that
it
makes
much
more
sense
to
try
to
work
together
as
a
community
to
build
it
and
that's
inspiration.
That's
coming
from
kubernetes,
where
we've
seen
you
know
a
similar
effort
to
build
a
container
platform
worked
well
when
you
had
a
community
driven
platform
as
opposed
to
trying
to
do
it
all
yourself,
and
so
what
exactly?
Does
it
mean
to
be
a
k-8
native
platform
for
ml?
B
So,
first
and
foremost,
we
want
to
run
wherever
kate
kubernetes
runs
right,
so
we're
taking
a
hard
dependency
on
kubernetes,
and
we
assume
that
you
have
kubernetes
as
the
substrate
for
running
your
ml
platform
and
solutions
and
the
reason
we
want
to
do
that
is
because
we're
gonna
rely
on
kubernetes
to
take
it,
to
move
your
platform
from,
say
your
local
machine
for
doing
early
development
and
testing
to
your
on-prem
cluster
or
your
cloud
clusters
to
productionize
it.
And
so
that's
why
we
need
kubernetes,
the
others.
B
The
other
aspect
of
being
kubernetes
native
is
that
we're
taking
advantage
of
kubernetes
api
sand
patterns
to
solve
challenges
in
machine
learning.
So
a
concrete
example
of
that
is:
we've
built
custom
control
controllers
in
kubernetes
and
custom
resources
to
do
things
like
run
distributed
training
for
tensorflow.
So
if
you're
running
distributed
training
for
tensorflow,
you
have
multiple
processes
you
have
to
manage,
so
you
have
basically
masters
that
coordinate
training.
You
have
workers
that
actually
do
the
work,
and
then
you
have
parameter
servers
that
act
as
a
distributed
data
store
for
the
parameters
that
you're
learning.
B
A
So
when
you
get
started,
deploying
your
or
actually
creating
your
product,
the
first
and
most
important
thing
for
you
is
to
have
a
stable
community
substrate
that
you
can
use
to
actually
build
on
top
off
and
then
have
a
repeatable
way
to
deploy
cube
flow
on
top
to
actually
enable
the
platform
wherever
you,
wherever
you
run.
It.
A
So
you
can
run
it,
you
can
run
it
either
on
on-prem
or
you
can
run
it
in
the
cloud.
This
is
one
one
option
that
you
can
do
where
you
deploy
actually
the
canonical
distribution
of
kubernetes.
You
deploy
it
on
Prem.
You
select
your
your
credentials,
you
select
a
substrate,
you
select
the
networking
that
you
would
like.
You
then
go
fill
in
the
required.
A
So
once
you
have
the
kubernetes
deployed
and
you
you
have
cube
flow
installed,
which
is
part
of
that
installer
that
you
just
saw,
then
you
actually
have
a
problem
in
terms
of
in
terms
of
actually
establishing
a
data
scientist
or
a
developer
workflow.
So
how
does
that
workflow
look
like
in
the
context
of
of
cube
flow?
Now,
if
you
break
it
down
into
the
most
basic
components,
you
identify
a
problem,
then
your
experiment
train
your
model,
see
if
the
deployed
model
actually
works.
A
The
way
you
like,
if
it
does,
the
things
that
you
thought
it
would
do
oftentimes
in
the
subset
of
the
data
on
a
filtered
set
of
the
data,
not
under
full
data
set.
You
keep
doing
this
until
you're
you're
happy
with
you
know,
with
the
way
that
your
model
is
working
out
and
finally,
you
then
deploy
it
at
scale
and,
and
you
have
to
operate
it
once
it
is
deployed,
so
I
think
Jeremy
is
going
to
go
through
the
two.
The
ante
example
now,
okay.
B
So,
let's,
let's
identify
a
problem,
and
so
in
this
particular
case,
the
problem
that
we're
going
to
look
at
is
github
issues
with
uninformative
titles.
So
if
you're,
dealing
or
managing
a
project
on
github
or
even
with
your
internal
issue,
tracker
system
and
not
uncommon
problem
is
that
people
file
issues
that
have
uninformative
titles,
so
not
uncommon
for
a
user
to
report
a
bug
with
a
very
generic
title.
B
So
as
one
particular
example,
a
user
in
coop
flow
reported
a
bug
and
they
titled
that
some
setting
problems
a
new
guy
needs
a
little
help
and
then
you
go
and
you
do
a
little
bit
of
triage.
You
find
out
what
the
actual
issue
is
and
you
update
the
bug
or
issue
on
the
thread,
and
eventually
you
identify
what
the
particular
problem
is
and
you
would
like
to
go
back
and
update
the
title
to
sort
of
maintain
the
hygiene
of
your
project.
So
in
this
case
we
identified
the
particular
problem.
B
It
was
a
problem
with
the
KC
net
configuration
in
our
template,
so
we
went
ahead
and
updated
the
title
to
reflect
that.
So
this
is
so
keeping
github
issues.
Titles
up
to
date,
though,
is
a
lot
of
toil.
It's
a
lot
of
manual
labor.
So
this
is
an
area
where
we
would
like
to
think
about.
You
know
trying
to
automate
this
using
machine
learning,
and
so
so
that's
that's
the
goal.
So,
let's,
let's
switch
to
the
demo.
B
So
the
first
thing
is
to
is
you
need
to
sort
of
enable
your
data,
scientists
and
machine
machine,
lurcher,
machine
learning,
researchers
to
do
experimentation
and
exploration,
to
see
whether
that
whether
this
problem
is
actually
solvable,
and
so
the
tool
of
choice
for
this
type
of
exploration
in
the
AML
community
is
Jupiter.
Notebooks
Jupiter
notebooks
are
an
interactive
Python
environment
that
allows
for
easy,
interactive
and
ad-hoc
analysis
right.
So
after
you've
deployed
Kubb
flow,
one
of
the
things
that
we
deploy
as
part
of
Kubb
flow
is
jupiter
hub.
B
B
So
right
now
we
support,
provide
runtime
environments
for
tensorflow
and
we're
gonna.
Provide
runtime
environments,
for
other
frameworks
like
py
torch,
is
that
some
port
emerges
in
coop
flow
and
then
we're
also
integrating
this
with
other
packages
in
coop
flow
like
pachyderms.
So
pachyderm
provides
a
data.
Repository
get
four
data,
basically
as
well
as
a
pipelining
solution,
and
we
that's
a
nice
tool
to
integrate
with
Jupiter,
and
so
the
other
thing
that
you
can
do
is
you
can
specify
the
resources
and
take
advantage
of
kubernetes
to
launch
notebooks
with
more
CPU,
RAM
or
memory.
B
So
then
you
can
click
spawn
and
I'm
going
to.
After.
If
you
were
to
spawn
a
notebook,
what
you
would
end
up
getting
is
you
would
get
a
notebook
environment
like
this
and
from
here
you
can
go
ahead
and
select
your
particular
notebook,
so
I've
gone
ahead
and
loaded
up
a
notebook,
and
this
is
a
notebook
that
was
developed
by
home
hüseyin.
So
he
used
a
data
scientist
at
github
who
originally
had
the
idea
to
sort
of
tackle
this
problem,
and
this
is
the
notebook
that
he
developed
to
do
that.
B
So
you
can
see
if
we
scroll
down
here.
The
first
step
is
we're
downloading
a
little
bit
of
data,
so
in
this
case
we're
pulling
data
from
the
github
archive
which
publishes
you
know
an
archive
of
all
the
data
events
on
github.
So
we
can
get
issues
from
that
and
use
that
to
Train.
So
the
next
step
is
we
want
to
try
processing
the
data
and
one
of
the
things
I'll
note
here,
because
I
think
it's
going
to
be
important
later
on.
B
Is
that
we're
using
we're
using
a
small
subset
of
the
data,
we're
down
sampling
it
and
the
reason
we're
down
sampling?
The
data
is
because
we're
running
interactively
in
a
notebook,
and
we
want
to
get
feedback
pretty
quickly
so
that
we
can
iterate
quickly
and
see
whether
the
analysis
that
we're
doing
is
actually
promising.
B
So
you
can
see,
then
the
next
step
is
what
he's.
What
he's
done
here
is
he's
printed
out
and
taken
advantage
of
Jupiter
to
actually
sort
of
start.
Looking
at
the
data
get
a
sense
of
what
the
what
the
data
is,
so
we
can
figure
out
what
sort
of
transformations
and
pre-processing
he
needs
to
run
and
then
actually
down
here,
he's
doing
the
actual
pre-processing.
So
he's
doing
some
things
like
removing
stop
words
that
aren't
uninformative
he's
also
computing.
B
Once
we
have
the
the
model
trained,
we
can
actually
generate
predictions
on
the
on
the
model,
and
so
you
can
look
here.
We
have
the
body
of
an
issue,
we
have
its
original
title
and
then
we
have
the
actual
title
that
was
generated
by
the
machine
learning
algorithm.
So
this
is
pretty
great,
as
a
data
scientist
he's
proved
that
you
know
you
can
build
a
model
to
solve
this,
but
there's
a
couple
of
problems.
B
The
first
is
that
he
only
trained
on
a
subset
of
the
data,
so
if
you're
actually
going
to
put
this
into
production,
you'd
probably
want
to
train
on
all
the
data
and
sort
of
scale
out
to
see
if
you
can
improve
your
quality
of
your
model.
By
doing
that-
and
the
second
is
while
using
a
notebook,
is
great
for
experimentation
and
analysis.
B
It's
not
a
great
way
to
productize
the
this
model
and
make
it
consumable
so
we're
going
to
use
kubernetes
to
solve
both
of
those
problems,
so
kubernetes
makes
it
really
easy
to
scale
out
so
for
pre-processing.
You
could
run
that
as
a
batch
job
using
kubernetes
to
run
asynchronously
and
let
it
run
for
a
long
time,
and
then
we
can
also
take
advantage
of
our
tensorflow
job
operator
to
run
as
a
distributed
job
on
kubernetes
and
scale
out
horizontally,
and
so
that's
what
I'm
going
to
show
next.
B
B
So
it
looks
very
similar
to
your
normal
K
eights
manifest.
You
know.
We
have
a
pod
template
spec
and
we
specifically
provide
a
pod
template
spec,
because
we
want
people
to
take
advantage
of
the
familiar
kubernetes
api.
So
by
using
a
pod
template
spec,
you
can
use
volumes
to
attach
storage
to
your
pods.
B
You
can
set
environment
variables
to
inject
credentials
like
GCP
service
accounts,
er,
s3
service
accounts
and
then,
as
I
said,
you
basically
have
multiple
replicas,
so
you
have
like
the
master
replicas,
the
worker
replicas
and
then
the
parameter
server
replicas
and
for
each
one
of
those
you
specify
the
number
of
replicas
that
you
want
and
that's
how
you
scale
out
horizontally.
So
while
our
model
is
training,
we
would
like
to
see
the
performance
of
how
well
that
model
is
doing,
and
so
for
that
we
want.
We
launched
and
run
Tenzer
board.
B
So
Tenzer
board
is
part
of
the
the
tensorflow
ecosystem
and
it's
the
package
for
visualizing
all
the
metrics.
So
as
part
of
coop
flow
we've
made
it
really
easy
to
deploy
tens
our
board
on
kubernetes.
We
provide
Kayson
and
packages
for
doing
that,
and
then
we
integrate
that
into
our
ingress
story.
So
you
can
easily
access
that
remotely.
So
you
can
see
the
metrics
that
you're
running
and
see
how
well
your
models
doing
right.
B
So
once
you've
done
done
that
and
you've
trained
a
model,
you
actually
want
to
put
that
model
into
production,
and
so
to
do
that,
you
want
to
build
a
model
server.
So
a
model
server
is
basically
a
server.
That's
going
to
get
the
input
to
the
model
in
the
body
of
a
request,
and
then
Jenner
turned
the
prediction
in
the
body
of
the
response
right,
fairly,
straightforward,
and
so
for
that
we're
we're
taking
advantage
of
a
package
from
Selden
called
Selden
core,
which
provides
a
package
for
building
model
servers
right,
so
I'm
a
refresh.
B
So
what
you
do
to
take
advantage
of
Selden
is
they
provide
a
model
server
and
to
use
this
model
server?
You
basically
just
have
to
implement
the
predict
method
by
defining
a
Python
class
and
that
predict
method
basically
takes
the
function,
signature
that
they've
defined
and
you
define
the
body.
That's
it
call
your
actual
model
and
then
return
the
data
in
the
form
that
they
expect,
and
so
once
you've
defined
this
class.
B
You
can
basically
use
tooling
that
provide
that's
provided
by
Selden
to
to
build
a
docker
image
that
contains
your
model
and
the
server
that
will
deploy
that
can
be
used
to
serve
your
model
and
then
to
actually
deploy
your
model.
You
can
take
advantage
of
Selden,
has
a
custom
resource
and
that
custom
resource
takes
care
of
rolling
out
your
models
and
handling
model
deployments.
B
Let
me
zoom
in
here,
so
this
is
the
Selden
deployment.
Spec,
that's
used
by
Selden
to
control
model
deployments
and
really
the
thing
that
distinguishes
the
Selden
deployment
from
a
regular
deployment
in
k-8
is
that
they
allow
you
to
express
the
inference
graph
inference
as
a
graph
of
microservices.
So
you
basically
have
multiple
models
that
are
combined
to
generate
the
actual
prediction,
and
this
allows
you
to
do
some
very
complicated
things
very
easily.
So
as
an
example,
you
can
take
advantage
of
this
to
do
a/b
testing.
B
Decision
tree
model
and
pick
the
outputs
from
both
of
those
two,
this
said,
use
both
models
to
generate
the
actual
prediction.
So
we
use
this
to
actually
deploy
the
model
and
then
to
actually
make
this
consumable.
You
might
want
to
have
an
actual
web
app
that
you
go
ahead
and
deploy,
and
so
we
built
a
simple
web
app
to
sort
of
illustrate
this,
and
then
we
went
ahead
and
deployed
that
in
kubernetes
and
then
this
takes
an
input
from
the
user.
B
So
in
this
case
the
user
intent
as
a
github
issue,
the
web
app
goes
and
fetches.
The
relevant
data
from
github
then
makes
the
RPC
to
the
cert,
the
Selden
server
to
actually
generate
the
request.
And
so,
if
we
do
this,
we
can
click
generate
title.
So
we
we
fetched
the
body
of
the
issue
and
down
here
we
have
the
actual
the
title
that
was
actually
draining
it
generated
by
the
machine
learning
algorithm,
which
is
pretty
accurate
in
this
case,
and
the
title
is
training
stuck
on
waiting
for
workers.
B
B
You
know
we
started
by
deploying
Jupiter
to
give
our
data
scientists
ml
researchers
the
tools
they
needed
to
actually
build
and
develop
their
models
once
they
were
done,
developing
their
model,
they
needed
to
train
at
scale,
and
so
for
that
we
provided
them
the
TF
job
controller
that
they
had
to
go
ahead
and
deploy
and
then
to
support
training.
We
have
both
a
coming
up
and
Kubb
flow.
We
have
a
UI,
that's
going
to
help.
You
manage
your
TF
jobs.
We
also
had
to
launch
and
manage
Tenzer
board.
B
Then
we
had
to
actually
deploy
the
Seldon
controller
to
manage
our
model
deployments
and
inference,
and
then
we
had
to
actually
roll
out
the
actual
model
that
was
serving
them.
The
model
server
for
this
particular
model
and
connect
it
with
our
web
app
and
then,
of
course,
we
need
like
things
like
sto
that
were
integrating
with
to
provide
monitoring
and
DevOps
for
your
logging
for
your
for
your
apps.
So
we
have
multiple
web
applications
that
users
need
access
to.
B
So
this
is
our
roadmap
for
coop
flow.
We
just
released
our
0.1
release
in
April,
and
this
basically
contains
some
some
core
components.
So
we
have
a
bunch
of
existing
packages
that
we're
integrating
with
so
we're
integrating
with
our
go
for
workflow
management,
we're
integrating
with
Jupiter
hub
for.
B
Notebooks,
we
also
have
our
TF
job
operator,
we're
integrating
with
Selden
and
TNT.
Observing
T
observing
is
another
package
for
doing
model
serving,
and
we
also
integrate
with
pachyderm
for
our
0.2
release.
We
have
a
bunch
of
new
components
coming,
so
we
have
cat
tip
for
HP
tuning.
We
have
the
py
torch
operator,
we're
gonna.
Hopefully,
support
batch
inference
vaad,
which
is
a
framework
using
MPI
for
distributed
training.
B
Then
we
have
a
central
UI
that
we're
also
adding
for
coop
flow
and
then
we're
going
to
also
be
making
some
improvements
to
our
existing
functionality
and
packages.
Then
we're
targeting
a
1.0
release,
hopefully
a
coop
con
USA,
which
will
be
in
about
December
and
the
core
cuj
that
we're
kind
of
targeting
for
our
wonder
release
is
continuous
integration
in
the
ml
space,
so
in
ml,
what
can
integration
means?
Is
every
night
as
you
get
more
more
data.
A
Right
thanks
Jeremy,
so
in
summary,
first,
the
first
problem
you
have
to
solve
is
deploy
cube
flow
in
order
to
deploy
Q
flow
repeatedly.
There's
a
couple
of
options:
you've
got,
you
need
a
community
somewhere
that
can
be
on
Prem
or
it
can
be
in
the
cloud
if
it
is
on
Prem,
because
you
you
want
to
do
your
training
with
a
limited
data
set
that
might
be
in-house
or
if
you
have
a
problem
where
your
data
has
to
stay
in
a
house
because
you're
you
know
you
have
compliance,
concerns,
etc.
A
Then
there's
a
couple
of
things
that
are
important
for
you
to
to
consider.
First,
you
have
to
consider
two
compliance
or
the
compatibility
of
your
kubernetes
with
the
communities
in
the
cloud
that
you're
going
to
eventually
deploy
to.
Does
it
support
the
same?
Is
it
the
same
version?
Does
it
support
the
same
primitives?
Is
that
a
smooth
story
number
one
number
two?
A
You
need
to
expose
the
GP
GPUs
in
a
correct
in
the
correct
way,
so
that
both
queue
flow
work
on
Prem
as
well
as
in
the
cloud,
and
this
is
a
little
bit
more
complicated.
It
requires
something
it.
It
requires
deep
kernel,
integration,
it
requires
the
CUDA
library
compatibility
and
it
requires
obviously
the
the
right
way
to
expose
those
NVIDIA
GPUs
inside
your
docker
containers
that
are
running
on
top
of
communities.
So
all
of
that
work
needs
to
be
done
correctly,
and
so
does.
A
These
are
some
of
the
data
points
that
you
should
look
at
when
deploying
communities
on
Prem.
For
that
purpose
and
to
make
that
story
smooth
once
you've
deployed,
you
then
can
go
through
this
data
science
process
that
Jeremy
just
illustrated
in
terms
of
this
end-to-end
example.
So
you
can
experiment
in
Jupiter,
build
the
docker
image,
stand
train
at
scale
and
then
deploy
wherever
wherever
you
like,
with
the
model
server
of
your
choice,.
A
So
here's
just
a
couple
of
links
where
you
can
find
out
more
so
the
code
for
the
end-to-end
example
is
on
the
top.
This
is
really
the
github
issue.
Summarization
you
can
try
it
on
captor
coda,
there's
a
blog
post
about
the
application
that
we
just
showed
and
then
obvious.
Also
there's
the
acute
flow
mailing
list,
as
well
as
the
github
link.
D
B
So
we
support
tensorflow
serving
as
well.
We
didn't
use
it
in
this
particular
example,
but
we
support
tens
of
flow
servings.
We
provide
doctor
images,
for
example,
for
for
tensorflow
serving
and
case
Annette
packages
that
make
it
easy
to
deploy
tons
of
pho
serving
so
you
can
choose
which,
which
package,
which
which
models.
However,
you
want
to
use.
C
B
We
just
purchased
running
Jupiter,
so
if
Jupiter
supports
our
and
these
other
frameworks-
and
we
get
that
support
out
of
the
box
and
we
can
add
other
packages
potentially
if
there
were
people
that
wanted
to
integrate
like
our
support,
because
that
is
a
very
popular
tool
in
the
in
the
in
the
data
science
community.
So
we'd
be
happy
to
integrate
that.
If
there
was
a
good
package
for
that
to
do
so,
yeah.