View Source Nx.Serving behaviour (Nx v0.5.1)

Serving encapsulates client and server work to perform batched requests.

Servings can be executed on the fly, without starting a server, but most often they are used to run servers that batch requests until a given size or timeout is reached.

More specifically, servings are a mechanism to apply a computation on a Nx.Batch, with hooks for preprocessing input from and postprocessing output for the client. Thus we can think of an instance of Nx.Serving.t() (a serving) as something that encapsulates batches of Nx computations.

inline-serverless-workflow

Inline/serverless workflow

First, let's define a simple numerical definition function:

defmodule MyDefn do
  import Nx.Defn

  defnp print_and_multiply(x) do
    print_value({:debug, x})
    x * 2
  end
end

The function prints the given tensor and doubles its contents. We can use new/1 to create a serving that will return a JIT or AOT compiled function to execute on batches of tensors:

iex> serving = Nx.Serving.new(fn opts -> Nx.Defn.jit(&print_and_multiply/1, opts) end)
iex> batch = Nx.Batch.stack([Nx.tensor([1, 2, 3])])
iex> Nx.Serving.run(serving, batch)
{:debug, #Nx.Tensor<
  s64[1][3]
  [
    [1, 2, 3]
  ]
>}
#Nx.Tensor<
  s64[1][3]
  [
    [2, 4, 6]
  ]
>

We started the serving by passing a function that receives compiler options and returns a JIT or AOT compiled function. We called Nx.Defn.jit/2 passing the options received as argument, which will customize the JIT/AOT compilation.

You should see two values printed. The former is the result of Nx.Defn.Kernel.print_value/1, which shows the tensor that was actually part of the computation and how it was batched. The latter is the result of the computation.

When defining a Nx.Serving, we can also customize how the data is batched by using the client_preprocessing as well as the result by using client_postprocessing hooks. Let's give it another try:

iex> serving = (
...>   Nx.Serving.new(fn opts -> Nx.Defn.jit(&print_and_multiply/1, opts) end)
...>   |> Nx.Serving.client_preprocessing(fn input -> {Nx.Batch.stack(input), :client_info} end)
...>   |> Nx.Serving.client_postprocessing(&{&1, &2, &3})
...> )
iex> Nx.Serving.run(serving, [Nx.tensor([1, 2]), Nx.tensor([3, 4])])
{:debug, #Nx.Tensor<
  s64[2][2]
  [
    [1, 2],
    [3, 4]
  ]
>}
{#Nx.Tensor<
   s64[2][2]
   [
     [2, 4],
     [6, 8]
   ]
 >,
 :server_info,
 :client_info}

You can see the results are a bit different now. First of all, notice that we were able to run the serving passing a list of tensors. Our custom client_preprocessing function stacks those tensors into a batch of two entries and returns a tuple with a Nx.Batch struct and additional client information which we represent as the atom :client_info. The default client preprocessing simply enforces a batch was given and returns no client information.

Then the result is a triplet tuple, returned by the client postprocessing function, containing the result, the server information (which we will later learn how to customize), and the client information. From this, we can infer the default implementation of client_postprocessing simply returns the result, discarding the server and client information.

So far, Nx.Serving has not given us much. It has simply encapsulated the execution of a function. Its full power comes when we start running our own Nx.Serving process. That's when we will also learn why we have a client_ prefix in some of the function names.

stateful-process-workflow

Stateful/process workflow

Nx.Serving allows us to define an Elixir process to handle requests. This process provides several features, such as batching up to a given size or time, partitioning, and distribution over a group of nodes.

To do so, we need to start a Nx.Serving process with a serving inside a supervision tree:

children = [
  {Nx.Serving,
   serving: Nx.Serving.new(Nx.Defn.jit(&print_and_multiply/1)),
   name: MyServing,
   batch_size: 10,
   batch_timeout: 100}
]

Supervisor.start_child(children, strategy: :one_for_one)

Now you can send batched runs to said process:

iex> batch = Nx.Batch.stack([Nx.tensor([1, 2, 3]), Nx.tensor([4, 5, 6])])
iex> Nx.Serving.batched_run(MyServing, batch)
{:debug, #Nx.Tensor<
  s64[2][3]
  [
    [1, 2, 3],
    [4, 5, 6]
  ]
>}
#Nx.Tensor<
  s64[2][3]
  [
    [2, 4, 6],
    [8, 10, 12]
  ]
>

In the example, we pushed a batch of 2 and eventually got a reply. The process will wait for requests from other processes, for up to 100 milliseconds or until it gets 10 entries. Then it merges all batches together and once the result is computed, it slices and distributes those responses to each caller.

If there is any client_preprocessing function, it will be executed before the batch is sent to the server. If there is any client_postprocessing function, it will be executed after getting the response from the server.

partitioning

Partitioning

You can start several partitions under th same serving by passing partitions: true when starting the serving. The number of partitions will be determined according your compiler and for which host it is compiling.

For example, when creating the serving, you may pass the following defn_options:

Nx.Serving.new(computation, compiler: EXLA, client: :cuda)

Now when booting up the serving:

children = [
  {Nx.Serving,
   serving: serving,
   name: MyServing,
   batch_size: 10,
   batch_timeout: 100,
   partitions: true}
]

If you have two GPUs, batched_run/3 will now gather batches and send them to the GPUs as they become available to process requests.

distribution

Distribution

All Nx.Servings are distributed by default. If the current machine does not have an instance of Nx.Serving running, batched_run/3 will automatically look for one in the cluster. The nodes do not need to run the same code and applications. It is only required that they run the same Nx version.

The load balancing between servings is done randomly, however, the number of partitions are considered if the partitioned: true option is also given. For example, if you have a node with 2 GPUs and another with 4, the latter will receive the double of requests compared to the former.

batched_run/3 receives an optional distributed_preprocessing callback as third argument for preprocessing the input for distributed requests. When using libraries like EXLA or Torchx, the tensor is often allocated in memory inside a third-party library so it is necessary to either transfer or copy the tensor to the binary backend before sending it to another node. This can be done by passing either Nx.backend_transfer/1 or Nx.backend_copy/1 as third argument:

Nx.Serving.batched_run(MyDistributedServing, input, &Nx.backend_copy/1)

Use backend_transfer/1 if you know the input will no longer be used.

Similarly, the serving has a distributed_postprocessing callback which can do equivalent before sending the reply to the caller.

The servings are dispatched using Erlang Distribution. You can use Node.connect/1 to manually connect nodes. In a production setup, this is often done with the help of libraries like libcluster.

advanced-notes

Advanced notes

module-based-serving

Module-based serving

In the examples so far, we have been using the default version of Nx.Serving, which executes the given function for each batch.

However, we can also use new/2 to start a module-based version of Nx.Serving which gives us more control over both inline and process workflows. A simple module implementation of a Nx.Serving could look like this:

defmodule MyServing do
  @behaviour Nx.Serving

  defnp print_and_multiply(x) do
    print_value({:debug, x})
    x * 2
  end

  @impl true
  def init(_inline_or_process, :unused_arg, [defn_options]) do
    {:ok, Nx.Defn.jit(&print_and_multiply/1, defn_options)}
  end

  @impl true
  def handle_batch(batch, 0, function) do
    {:execute, fn -> {function.(batch), :server_info} end, function}
  end
end

It has two functions. The first, init/3, receives the type of serving (:inline or :process) and the serving argument. In this step, we capture print_and_multiply/1as a jitted function.

The second function is called handle_batch/3. This function receives a Nx.Batch and returns a function to execute. The function itself must return a two element-tuple: the batched results and some server information. The server information can be any value and we set it to the atom :server_info.

Now let's give it a try by defining a serving with our module and then running it on a batch:

iex> serving = Nx.Serving.new(MyServing, :unused_arg)
iex> batch = Nx.Batch.stack([Nx.tensor([1, 2, 3])])
iex> Nx.Serving.run(serving, batch)
{:debug, #Nx.Tensor<
  s64[1][3]
  [
    [1, 2, 3]
  ]
>}
#Nx.Tensor<
  s64[1][3]
  [
    [2, 4, 6]
  ]
>

From here on, you use start_link/1 to start this serving in your supervision and even customize client_preprocessing/1 and client_postprocessing/1 callbacks to this serving, as seen in the previous sections.

Note in our implementation above assumes it won't run partitioned. In partitioned mode, init/3 may receive multiple defn_options as the third argument and handle_batch/3 may receive another partition besides 0.

Link to this section Summary

Callbacks

Receives a batch, a partition, and returns a function to execute the batch.

The callback used to initialize the serving.

Functions

Runs the given input on the serving process given by name.

Sets the client postprocessing function.

Sets the client preprocessing function.

Sets the defn options of this serving.

Sets the distributed postprocessing function.

Creates a new function serving.

Creates a new module-based serving.

Sets the process options of this serving.

Runs serving with the given input inline with the current process.

Starts a Nx.Serving process to batch requests to a given serving.

Link to this section Types

@type client_info() :: term()
Link to this type

client_postprocessing()

View Source
@type client_postprocessing() ::
  (Nx.Container.t(), metadata(), client_info() -> term())
Link to this type

client_preprocessing()

View Source
@type client_preprocessing() :: (term() -> {Nx.Batch.t(), client_info()})
Link to this type

distributed_postprocessing()

View Source
@type distributed_postprocessing() :: (term() -> term())
Link to this type

distributed_preprocessing()

View Source
@type distributed_preprocessing() :: (term() -> term())
@type metadata() :: term()
@type t() :: %Nx.Serving{
  arg: term(),
  client_postprocessing: client_postprocessing(),
  client_preprocessing: client_preprocessing(),
  defn_options: keyword(),
  distributed_postprocessing: distributed_postprocessing(),
  module: atom(),
  process_options: keyword()
}

Link to this section Callbacks

Link to this callback

handle_batch(t, partition, state)

View Source
@callback handle_batch(Nx.Batch.t(), partition :: non_neg_integer(), state) ::
  {:execute, (-> {Nx.Container.t(), metadata()}), state}
when state: term()

Receives a batch, a partition, and returns a function to execute the batch.

In case of serving processes, the function is executed is an separate process.

@callback init(type :: :inline | :process, arg :: term(), [defn_options :: keyword()]) ::
  {:ok, state :: term()}

The callback used to initialize the serving.

The first argument reveals if the serving is executed inline, such as by calling run/2, by started with the process. The second argument is the serving argument given to new/2. The third argument option is a list of compiler options to be used to compile each partition the serving will run.

It must return {:ok, state}, where the state can be any term.

Link to this section Functions

Link to this function

batched_run(name, input, distributed_preprocessing \\ &Function.identity/1)

View Source

Runs the given input on the serving process given by name.

name is either an atom representing a local or distributed serving process. First it will attempt to dispatch locally, then it falls back to the distributed serving. You may specify {:local, name} to force a local lookup or {:distributed, name} to force a distributed one.

The client_preprocessing callback will be invoked on the input which is then sent to the server. The server will batch requests and send a response either when the batch is full or on timeout. Then client_postprocessing is invoked on the response. See the module documentation for more information. In the distributed case, the callbacks are invoked in the distributed node, but still outside of the serving process.

Note that you cannot batch an input larger than the configured :batch_size in the server.

distributed-mode

Distributed mode

To run in distributed mode, the nodes do not need to run the same code and applications. It is only required that they run the same Nx version.

If the current node is running a serving given by name locally and {:distributed, name} is used, the request will use the same distribution mechanisms instead of being handled locally, which is useful for testing locally without a need to spawn nodes.

This function receives an optional distributed_preprocessing callback as third argument for preprocessing the input for distributed requests. When using libraries like EXLA or Torchx, the tensor is often allocated in memory inside a third-party library so it is necessary to either transfer or copy the tensor to the binary backend before sending it to another node. This can be done by passing either Nx.backend_transfer/1 or Nx.backend_copy/1 as third argument:

Nx.Serving.batched_run(MyDistributedServing, input, &Nx.backend_copy/1)

Use backend_transfer/1 if you know the input will no longer be used.

Similarly, the serving has a distributed_postprocessing callback which can do equivalent before sending the reply to the caller.

Link to this function

client_postprocessing(serving, function)

View Source

Sets the client postprocessing function.

The default implementation returns the first element given to the function.

Link to this function

client_preprocessing(serving, function)

View Source

Sets the client preprocessing function.

The default implementation creates a single element batch with the given argument and is equivalent to &Nx.Batch.stack([&1]).

Link to this function

defn_options(serving, defn_options)

View Source

Sets the defn options of this serving.

These are the options supported by Nx.Defn.default_options/1.

Link to this function

distributed_postprocessing(serving, function)

View Source

Sets the distributed postprocessing function.

The default implementation is Function.identity/1.

Link to this function

new(function, defn_options \\ [])

View Source

Creates a new function serving.

It expects a function that receives the compiler options and returns a JIT (via Nx.Defn.jit/2) or AOT compiled (via Nx.Defn.compile/3) one-arity function as argument.

The function will be called with the arguments returned by the client_preprocessing callback.

Link to this function

new(module, arg, defn_options)

View Source

Creates a new module-based serving.

It expects a module and an argument that is given to its init callback.

A third optional argument called defn_options are additional compiler options which will be given to the module. Those options will be merged into Nx.Defn.default_options/0.

Link to this function

process_options(serving, process_options)

View Source

Sets the process options of this serving.

These are the same options as supported on start_link/1, except :name and :serving itself.

Runs serving with the given input inline with the current process.

Starts a Nx.Serving process to batch requests to a given serving.

options

Options

  • :name - an atom with the name of the process

  • :serving - a Nx.Serving struct with the serving configuration

  • :batch_size - the maximum batch size. A value is first read from the Nx.Serving struct and then it falls back to this option (which defaults to 1)

  • :batch_timeout - the maximum time to wait, in milliseconds, before executing the batch. A value is first read from the Nx.Serving struct and then it falls back to this option (which defaults to 100ms)

  • :partitions - when true, starts several partitions under this serving. The number of partitions will be determined according to your compiler and for which host it is compiling. See the module docs for more information

  • :shutdown - the maximum time for the serving to shutdown. This will block until the existing computation finishes (defaults to 30_000ms)

  • :hibernate_after and :spawn_opt - configure the underlying serving workers (see GenServer.start_link/3)