Out-of-the-box, MLServer exposes a set of metrics that help you monitor your machine learning workloads in production. These include standard metrics like number of requests and latency.

On top of these, you can also register and track your own custom metrics as part of your custom inference runtimes.

Default Metrics¶

By default, MLServer will expose metrics around inference requests (count and error rate) and the status of its internal requests queues. These internal queues are used for adaptive batching and communication with the inference workers.

Metric Name



Number of successful inference requests.


Number of failed inference requests.


Queue size for the adaptive batching queue.


Queue size for the inference workers queue.

REST Server Metrics¶

On top of the default set of metrics, MLServer’s REST server will also expose a set of metrics specific to REST.


The prefix for the REST-specific metrics will be dependent on the metrics_rest_server_prefix flag from the MLServer settings.

Metric Name



Number of REST requests, labelled by endpoint and status code.


Latency of REST requests.


Number of in-flight REST requests.

gRPC Server Metrics¶

On top of the default set of metrics, MLServer’s gRPC server will also expose a set of metrics specific to gRPC.

Metric Name



Number of gRPC requests, labelled by gRPC code and method.


Number of in-flight gRPC requests.

Custom Metrics¶

MLServer allows you to register custom metrics within your custom inference runtimes. This can be done through the mlserver.register() and mlserver.log() methods.

  • mlserver.register(): Register a new metric.

  • mlserver.log(): Log a new set of metric / value pairs. If there’s any unregistered metric, it will get registered on-the-fly.


Under the hood, metrics logged through the mlserver.log() method will get exposed to Prometheus as a Histogram.

Custom metrics will generally be registered in the load() method and then used in the predict() method of your custom runtime.

import mlserver

from mlserver.types import InferenceRequest, InferenceResponse

class MyCustomRuntime(mlserver.MLModel):
  async def load(self) -> bool:
    self._model = load_my_custom_model()
    mlserver.register("my_custom_metric", "This is a custom metric example")
    return True

  async def predict(self, payload: InferenceRequest) -> InferenceResponse:
    # TODO: Replace for custom logic to run inference
    return self._model.predict(payload)

Metrics Labelling¶

For metrics specific to a model (e.g. custom metrics, request counts, etc), MLServer will always label these with the model name and model version. Downstream, this will allow to aggregate and query metrics per model.


If these labels are not present on a specific metric, this means that those metrics can’t be sliced at the model level.

Below, you can find the list of standardised labels that you will be able to find on model-specific metrics:

Label Name



Model Name (e.g. my-custom-model)


Model Version (e.g. v1.2.3)


MLServer will expose metric values through a metrics endpoint exposed on its own metric server. This endpoint can be polled by Prometheus or other OpenMetrics-compatible backends.

Below you can find the settings available to control the behaviour of the metrics server:

Label Name




Path under which the metrics endpoint will be exposed.



Port used to serve the metrics server.



Prefix used for metric names specific to MLServer’s REST inference interface.



Directory used to store internal metric files (used to support metrics sharing across inference workers). This is equivalent to Prometheus’ $PROMETHEUS_MULTIPROC_DIR env var.

MLServer’s current working directory (i.e. $PWD)