Transformers 5.23 Export Migration: Replace output_path Safely

Hugging Face Transformers 5.23.0, released November 13, changes the model export interface. If your ONNX or OpenVINO export script still passes output_path into its config, update it: saving now happens through the returned ExportedModel. The more important check is whether your deployment pipeline still packages everything that loading needs.

The release notes identify both changes: export() returns a wrapper, and the old config-level destination options are gone. This is a migration guide for that interface, not a claim that every model now exports successfully or that switching runtimes makes your application faster.

Replace output_path with an explicit save step

Keep your existing model preparation and representative inputs. The structural change looks like this:

from transformers.exporters import OnnxConfig, OnnxExporter

artifact = OnnxExporter().export(
    model, inputs, config=OnnxConfig(dynamic=True)
)
artifact.save_pretrained("artifacts/candidate-onnx")

This is an API adaptation example, not a model export I have run. Keep your application's required export settings rather than replacing them wholesale with this minimal config. In particular, a successful example on one model does not establish support for your attention implementation, cache behavior or target device.

For OpenVINO, the same separation applies: configure the export first, then save the returned object. Avoid treating the destination directory as an inference setting.

ExportedModel is not the raw backend program

A script that handed the old return value directly to another library needs a second review. For a single-graph export, the backend object is available through .program; the ONNX object is now an onnx_ir.Model, according to the release notes. Check what the next consumer actually accepts instead of changing the variable name and hoping the types align.

The tagged 5.23.0 implementation makes an important distinction: .program and direct calls require a single-component export. Multi-component exports must be handled through their named components. Do not use this single-graph example as a complete migration for a generation pipeline with several stages.

The wrapper also filters call arguments to the inputs recorded during tracing and warns when dropping others. A request can therefore run without using an input you thought mattered. Read the warnings and compare the traced inputs with your production preprocessing output, particularly when adding a mask or a new optional field.

Deploy the artifact directory, not just model.onnx

The version-tagged exporter guide describes a saved bundle containing backend files, an export.json manifest and model configuration. ONNX weights can also live in an external data file. Copying only the graph is a poor default for a packaging script.

Keep different formats in different directories because the manifest and configuration names are fixed. Treat a candidate export as one versioned deployment unit, and retain the previously working unit until the candidate passes your checks.

The exporter remains experimental. Hugging Face ties its compatibility patches to tested dependency versions, so record the full backend environment alongside the Transformers version. A lockfile is more useful here than a note saying that the machine has ONNX installed.

Test the saved artifact in a fresh process

My suggested acceptance test has three boundaries. First, run the prepared model on a small fixed input set and preserve the outputs relevant to your application. Second, export and save it. Third, start a separate process, load only the saved candidate and run the same inputs on the intended runtime and device.

Include a short input, a typical input and one near your supported size limit. Decide numerical tolerances before comparing results, especially if precision changes. For an embedding service, also compare retrieval ordering on a small known query set; matching tensor shapes alone will miss a change that matters to users.

Finally, exercise the actual container or packaging job. If the local reload works but deployment fails, compare the files copied, dependency versions and runtime configuration before changing the model again. This separates an export failure from an incomplete deployment artifact.

The useful migration boundary is a saved model that survives a clean reload and your application checks. Removing output_path gets the script past one interface change. It does not establish that the replacement is ready to serve traffic.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn migrations, product updates and engineering decisions into clear stories developers can use.

Book a 30-minute call