Translating a Fine-Tune When You Change Base Providers

No. A fine-tuned model produced through a hosted fine-tuning API does not transfer to another provider in any form — not as a file, not as an import, not as a conversion. What transfers is the training data, and that turns out to be most of what you need.

The short answer, and the useful one

The flat answer to the question is no, and if that is all you needed you can stop reading. The answer worth having is about what “a fine-tune” is made of, because the thing people usually mean when they ask this is “how much of the last three months do I lose, and how long does it take to get it back?” That question has a much better answer than the first one.

A supervised fine-tune is not a model. It is a modification to a specific base model — a set of adjusted parameter values that only mean anything in the context of the parameters they adjusted. When a hosted provider hands you back an identifier like a ft:-prefixed model string, that string names a deployment on their infrastructure, sitting on top of a base checkpoint that is theirs and that you have never had a copy of. There is no file. There is nothing to export.

Three artefacts, three different fates

Every fine-tuning run, on every platform, produces exactly three things worth naming. Being precise about which is which is the whole of the migration plan.

• The dataset. The JSONL you uploaded — typically one conversation per line, the assistant turn being the target. This is yours, it is portable, and it is the expensive artefact. Whatever it cost to collect, clean, deduplicate and label, you pay that once. Reformatting it for a different provider’s schema is mechanical; see the field-by-field conversion.
• The recipe. Epoch count, batch size, learning-rate multiplier, any validation split, the base model you chose and why. These transfer as intent rather than as values: the numbers are defined relative to one platform’s defaults and its optimiser, so “three epochs” on one is not the same training budget as “three epochs” on another. Carry the reasoning, re-derive the numbers.
• The weights. These do not transfer. On a hosted platform you never had them; even if you did, they would be meaningless without the base checkpoint they modify.

A fourth artefact usually goes unrecorded and matters more than the recipe: the evaluation set you used to decide the fine-tune was good enough to ship. If that exists as a file, the rebuild has a finish line. If it only ever existed as somebody looking at outputs and nodding, the rebuild has no way to end, and building it is the first task — before any retraining.

Why the weights cannot move

It is worth understanding the mechanism rather than treating this as a commercial restriction, because the mechanism is why no vendor could offer the import even if they wanted to.

Fine-tuning adjusts parameters in a network with a fixed architecture: a specific number of layers, a specific hidden dimension, a specific attention configuration, and a specific tokenizer with a specific vocabulary. The adjustment is expressed as changes to those exact tensors. Move it to a model with a different hidden dimension and the shapes do not even match; move it to one with the same shapes but a different vocabulary and every token index means something else. The delta is defined against a coordinate system that the other model does not share.

This also explains a smaller surprise inside a single provider: when a base model is deprecated, fine-tunes built on it usually go with it rather than migrating to its successor. The successor is a different coordinate system too. Treat a fine-tune’s lifetime as bounded by its base model’s, and keep the dataset somewhere that outlives both.

The open-weights case is different

If your fine-tune is an adapter over open weights — a LoRA, in practice — the picture changes, though less than people expect. Here you genuinely do have a file: a small set of low-rank matrices plus an adapter_config.json naming the base model, the rank, the alpha and the target modules. The Hugging Face PEFT library documents this format, and it is readable by anything that implements it.

What that buys you is portability between hosts, not portability between models. The adapter is still defined against one base checkpoint. You can take it from a self-hosted vLLM deployment to a managed endpoint that accepts adapter uploads and back, and it will behave identically, because the base is the same weights in both places. You cannot take it to a different base model at all. Practically the question to ask when evaluating an open-weights host is not “can I export my fine-tune” but “does this host let me upload an adapter it did not train, and against which base checkpoints exactly”.

What a rebuild actually costs you

Given the above, a provider switch with a fine-tune in it decomposes into a sequence with one genuinely uncertain step:

1. Reformat the dataset into the new platform’s schema. Mechanical, scriptable, and the field mapping is finite.
2. Re-run training. Costs compute time and money, both roughly proportional to dataset size times epochs, and both knowable in advance from the new provider’s published fine-tuning rate.
3. Re-tune the hyperparameters, because the defaults differ. This is the uncertain step and it is where the schedule slips.
4. Re-evaluate against the held-out set, and compare to the old model’s score on the same set — which is why step zero is scoring the incumbent before you turn it off.

The part nobody budgets is that the fine-tune may not be needed at all on the new base. A fine-tune is often compensating for a weakness in a particular model — format compliance, tone, a domain vocabulary — and a newer or different base may not have that weakness. Run your evaluation set against the new provider’s stock model first. If it clears the bar, the cheapest migration of a fine-tune is not migrating it, and you have removed a dependency rather than moved one. Where it does not clear the bar, the gap tells you what the fine-tune was actually for, which is useful information you probably did not have.

One thing does not survive under any plan: reproducibility of specific outputs. Even with the same data and the same recipe, a retrained model on a different base will not reproduce the incumbent’s exact strings. If anything downstream compares model output to stored golden text byte for byte, that comparison breaks on the day you cut over, and it breaks for reasons unrelated to quality. Plan the prompt-level fallout in the same pass.