What concretely breaks when you try to load a pretrained model checkpoint with a different tokenizer vocabulary?

A tokenizer assigns every text piece an integer **token ID**, and the model learns one embedding vector per ID. The input embedding table has shape `[vocab_size, d_model]`, so there is exactly one row for each ID. When you swap to a new tokenizer, the IDs remap. The word "hello" might have been ID 4891 and is now ID 72145. The model still looks up row 4891 for that text, but row 4891 now belongs to some other token. So every lookup pulls the wrong learned vector, and the forward pass produces nonsense. There is a second component that breaks the same way. The output head, `lm_head`, has shape `[d_model, vocab_size]`. Going from 50k to 100k tokens means 50,000 new output rows with no trained weights, so the model cannot produce those new tokens sensibly. The fixes range from cheap to expensive: keep the old IDs and only append new ones, or initialize the new rows by averaging their subword pieces and continue training, or retrain the whole model from scratch. The reason this is a hard question is that tokenizer choice is effectively locked once the model is pretrained.

Two model components carry `vocab_size` as a dimension, and both break when the vocabulary changes. The input embedding table has shape `[vocab_size, d_model]`, one learned row per token ID. The output projection `lm_head` has the mirror shape `[d_model, vocab_size]`. Growing from 50k to 100k tokens reshapes both. The first failure is **ID remapping**. "hello" was ID 4891, now it is 72145, but the model still fetches row 4891 for that text. Every embedding lookup returns the wrong learned vector, so the forward pass is garbage. The second failure is on the output side: the 50,000 new rows of the head have never been trained. The remediation ladder has three rungs. Vocabulary expansion keeps existing IDs intact, appends the new ones, and trains only the new rows; this works when you extend rather than replace. Vocabulary adaptation initializes each new token's embedding from the average of its old subword pieces, then runs continued pretraining. Full retraining is correct but pays the entire pretraining bill. The senior point is that tokenizer choice is sticky: it is fixed at pretraining time, so a multilingual upgrade is a training project, not a config change.