Recreating a Fine-Tune's Training Config on a New Provider

The config from your last tuning run is three numbers, and all three of them are meaningless on the new platform. Not wrong — meaningless, in the specific sense that they are defined relative to values the platform does not publish.

The surface each platform exposes

Start with what is actually settable. OpenAI’s fine-tuning API nests the knobs under the tuning method: a supervised job carries n_epochs, batch_size and learning_rate_multiplier inside method.supervised.hyperparameters, and all three are optional. A minimal job body looks like this.

POST /v1/fine_tuning/jobs
{
  "model": "gpt-4o-mini-2024-07-18",
  "training_file": "file-abc123",
  "validation_file": "file-def456",
  "suffix": "support-triage-v3",
  "method": {
    "type": "supervised",
    "supervised": {
      "hyperparameters": {
        "n_epochs": 3,
        "batch_size": 8,
        "learning_rate_multiplier": 1.8
      }
    }
  }
}

The field names and their nesting are documented by OpenAI in its fine-tuning API reference. Other platforms expose a different set at a different altitude: managed cloud tuning services typically surface an epoch count and a learning rate, sometimes an adapter size; open-weight tuning that you run yourself surfaces everything, including the optimiser, the warmup schedule, the sequence length and the precision. The general shape of the problem is that you are moving from a small opinionated surface to a different small opinionated surface, with no guarantee the two overlap.

The multiplier problem

A learning rate multiplier is not a learning rate. It scales an internal default that the platform selects, and that default is a function of the base model, the tuning method and whatever the platform’s current tuning stack does. Two consequences follow and both bite.

First, a multiplier of 1.8 does not port. On a platform that asks for an absolute learning rate you cannot compute the equivalent, because you were never told what it was multiplying. Second, the same multiplier does not necessarily reproduce your own run on the same platform against a different base model, since the base changes the default it scales. Anyone who has been surprised that re-running last quarter’s config on a newer base produced a differently behaved model has met this.

The practical move is to stop treating the number as the artefact. What is worth carrying across is the relationship you discovered: that this dataset overfits after roughly this many epochs, that raising the rate destabilised the loss curve, that holding out this slice caught the regression. Those are statements about your data, and data is the thing that actually migrated.

What auto means, and why it moves

Leave a hyperparameter unset on a managed platform and it is chosen for you, usually from dataset size. This is normally the right choice and it has one nasty property: it is not pinned. The same job body, submitted three months apart, can select different values, so a config in version control does not fully describe the run that produced the model you are serving.

Whatever else you do during a migration, record the resolved values the job actually used, not the values you requested. Read them back from the completed job object and store them next to the model identifier. If you are recreating a tuned model on a new platform without those resolved numbers from the old one, you are not recreating a run — you are running a new experiment that happens to use the same data, and it should be treated and evaluated as one. The same recording discipline is what makes the eval comparison afterwards possible at all.

There is a second, less obvious thing to read back off the finished job. Most managed platforms produce intermediate checkpoints and then hand you one model, and the rule by which that one was chosen — last epoch, or best validation loss — is part of the configuration in every sense that matters, even though it is not a field you set. If the outgoing platform selected on validation loss and the incoming one hands you the final epoch, an otherwise identical run gives you a different model, and the difference will look like a data problem. If the platform exposes its checkpoints, evaluate more than one rather than accepting the default choice.

Different tuning methods, different knobs

Supervised tuning on chat transcripts, preference tuning on pairs, and adapter-based tuning are three different procedures with disjoint controls. A platform offering low-rank adaptation exposes a rank and often a scaling factor, which have no counterpart at all in a full-parameter supervised job; a preference-tuning method exposes something governing how far the tuned policy may drift from the reference model, which has no counterpart in a supervised one. If the target platform implements your tuning objective with a different method, the config does not translate because the procedure does not.

Data format is the other silent difference. Chat-format tuning files are usually JSON Lines with one conversation per line, but the exact message shape, whether a system message is permitted, how tool calls and tool results are represented, and whether you can mask which turns contribute to the loss all vary. A converter that maps records but silently drops, say, the assistant tool-call turns will train something that looks fine until it stops calling tools. Validate converted files by reading a few back rather than by counting lines, and keep the general treatment of dataset construction in the dataset page in view while you do it.

Porting the run instead of the numbers

1. Pull the completed job object from the outgoing platform and record the resolved hyperparameters, the exact base model string, the training and validation file identifiers, and the checksums of both files.
2. Convert the dataset to the target format and validate a sample of converted records field by field, including tool-call turns and any system message.
3. Submit a first job on the new platform with everything left at default. This is the reference point, and it is more informative than a job configured from stale numbers.
4. Evaluate that job against a frozen held-out set — not the platform’s reported loss — and only then change one hyperparameter at a time.
5. Store the resolved config, the base model string and the eval result together, so the next migration starts from a record rather than from a config file that describes a request rather than a run.

That sequence looks slower than copying three numbers across. It is faster, because the alternative is a tuned model whose behaviour nobody can attribute to either the data or the config, on a base model nobody has characterised.