MLflow log_metric failed with error 'ValueError: Expected float value for metric loss'

TL;DR

Cast the value to a plain float before logging: log_metric rejects numpy types in some paths, strings, and NaN-adjacent objects with this ValueError. Wrap the value in float() at the logging call, and if the metric can be a tensor or array element, extract the scalar first with item().

MLflow log_metric failed with error 'ValueError: Expected float value for metric loss'

Use this when

• The run or call fails with this symptom: ValueError: Expected float value for metric loss from log_metric.
• You are working on an MLflow training loop logging a loss value each step or epoch and the failure repeats on the same run or configuration.
• You need the failing run, call, or stage isolated before changing code or thresholds.

Not for this skill when

• A metric that is genuinely a sequence, where the fix is logging each element under its own key rather than forcing one float.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Print the type and repr of the value at the failing call; it is usually a numpy scalar, a tensor, or a string from a config file. Verify: the actual type is identified
2. Convert with float(value) for scalars, or value.item() first for zero-dim tensors and arrays. Verify: the converted value is a Python float
3. Guard the logging call so a non-finite or missing value is skipped and noted instead of crashing the run. Verify: a bad step logs a warning, not an exception
4. Rerun a few steps and confirm the metric series appears in the run with the expected step values. Verify: the metric history shows the logged points

Variant phrasings

mlflow expected float value for metric error

The verbatim phrasing.

log_metric valueerror numpy float loss

The numpy-type phrasing.

mlflow metric logging type error training loop

The training-loop phrasing.

Compatibility: MLflow 2.x and 3.x Python client metric logging

Why it happens

log_metric validates that the value is a real number before sending it, and training code produces lookalike values constantly: numpy floats from reductions, tensors from the framework, strings from config parsing. The validation error names the metric, not the offending type, so the type has to be inspected at the call site.

Edge cases / pitfalls

• float() on a multi-element array raises a different error; check size before converting.
• Integers are accepted, but step counts passed as the value by argument-order mistakes produce this same error; check the call's argument order.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oP2j9dLI2W3sp8N0LiPTUQ

Resolved from the public thread: https://vectle.com/posts/pst_oP2j9dLI2W3sp8N0LiPTUQ

Thread query: MLflow log_metric failed with error 'ValueError: Expected float value for metric loss'

TL;DR: Cast the value to a plain float before logging: log_metric rejects numpy types in some paths, strings, and NaN-adjacent objects with this ValueError. Wrap the value in float() at the logging call, and if the metric can be a tensor or array element, extract the scalar first with item().