tff.learning.Model

View source on GitHub

Represents a model for use in TensorFlow Federated.

Used in the notebooks

Each Model will work on a set of tf.Variables, and each method should be a computation that can be implemented as a tf.function; this implies the class should essentially be stateless from a Python perspective, as each method will generally only be traced once (per set of arguments) to create the corresponding TensorFlow graph functions. Thus, Model instances should behave as expected in both eager and graph (TF 1.0) usage.

In general, tf.Variables may be either:

• Weights, the variables needed to make predictions with the model.
• Local variables, e.g. to accumulate aggregated metrics across calls to forward_pass.

The weights can be broken down into trainable variables (variables that can and should be trained using gradient-based methods), and non-trainable variables (which could include fixed pre-trained layers, or static model data). These variables are provided via the trainable_variables, non_trainable_variables, and local_variables properties, and must be initialized by the user of the Model.

In federated learning, model weights will generally be provided by the server, and updates to trainable model variables will be sent back to the server. Local variables are not transmitted, and are instead initialized locally on the device, and then used to produce aggregated_outputs which are sent to the server.

All tf.Variables should be introduced in __init__; this could move to a build method more inline with Keras (see https://www.tensorflow.org/api_docs/python/tf/keras/layers/Layer) in the future.

return {
    'num_examples': tff.federated_sum(local_outputs.num_examples),
    'loss': tff.federated_mean(local_outputs.loss)
}

Methods

forward_pass

View source

@abc.abstractmethod
forward_pass(
    batch_input, training=True
) -> tff.learning.BatchOutput

Runs the forward pass and returns results.

This method must be serializable in a tff.tf_computation or other backend decorator. Any pure-Python or unserializable logic will not be runnable in the federated system.

This method should not modify any variables that are part of the model parameters, that is, variables that influence the predictions (exceptions being updated, rather than learned, parameters such as BatchNorm means and variances). Rather, this is done by the training loop. However, this method may update aggregated metrics computed across calls to forward_pass; the final values of such metrics can be accessed via aggregated_outputs.

Uses in TFF:

• To implement model evaluation.
• To implement federated gradient descent and other non-Federated-Averaging algorithms, where we want the model to run the forward pass and update metrics, but there is no optimizer (we might only compute gradients on the returned loss).
• To implement Federated Averaging.

metric_finalizers

View source

@abc.abstractmethod
metric_finalizers() -> MetricFinalizersType

Creates an OrderedDict of metric names to finalizers.

This method and the report_local_unfinalized_metrics() method should have the same keys (i.e., metric names). A finalizer returned by this method is a function (typically a tf.function decorated callable or a tff.tf_computation decoreated TFF Computation) that takes in a metric's unfinalized values (returned by report_local_unfinalized_metrics()), and returns the finalized metric values.

This method and the report_local_unfinalized_metrics() method will be used together to build a cross-client metrics aggregator. See the documentaion of report_local_unfinalized_metrics() for more information.

predict_on_batch

View source

@abc.abstractmethod
predict_on_batch(
    batch_input, training=True
)

report_local_outputs

View source

@abc.abstractmethod
report_local_outputs()

Returns tensors representing values aggregated over forward_pass calls.

In federated learning, the values returned by this method will typically be further aggregated across clients and made available on the server.

This method returns results from aggregating across all previous calls to forward_pass, most typically metrics like accuracy and loss. If needed, we may add a clear_aggregated_outputs method, which would likely just run the initializers on the local_variables.

In general, the tensors returned can be an arbitrary function of all the tf.Variables of this model, not just the local_variables; for example, this could return tensors measuring the total L2 norm of the model (which might have been updated by training).

This method may return arbitrarily shaped tensors, not just scalar metrics. For example, it could return the average feature vector or a count of how many times each feature exceed a certain magnitude.

report_local_unfinalized_metrics

View source

@abc.abstractmethod
report_local_unfinalized_metrics() -> OrderedDict[str, Any]

Creates an OrderedDict of metric names to unfinalized values.

For a metric, its unfinalized values are given as a structure (typically a list) of tensors representing values from aggregating over all previous forward_pass calls. For a Keras metric, its unfinalized values are typically the tensor values of its state variables. In general, the tensors can be an arbitrary function of all the tf.Variables of this model.

The metric names returned by this method should be the same as those expected by the metric_finalizers(); one should be able to use the unfinalized values as input to the finalizers to get the finalized values. Taking tf.keras.metrics.CategoricalAccuracy as an example, its unfinalized values can be a list of two tensors (from its state variables): total and count, and the finalizer function performs a tf.math.divide_no_nan.

In federated learning, this method returns the local results from clients, which will typically be further aggregated across clients and made available on the server. This method and the metric_finalizers() method will be used together to build a cross-client metrics aggregator. For example, a simple "sum_then_finalize" aggregator will first sum the unfinalized metric values from clients, and then call the finalizer functions at the server.

Because both of this method and the metric_finalizers() method are defined in a per-metric manner, users have the flexiblity to call finalizer at the clients or at the server for different metrics. Users also have the freedom to defined a cross-client metrics aggregator that aggregates a single metric in multiple ways.