TypeError when passing "tokenizer_name" to "FastVisionModel.from_pretrained" due to parameter conflict

[AhmadAlmustadi]

Hi

I am trying to load a vision model using FastVisionModel.from_pretrained where the model and the tokenizer/processor are located in different Hugging Face repositories. When I pass the tokenizer_name parameter to specify a different tokenizer, I get a TypeError: got multiple values for keyword argument 'tokenizer_name'.

model, processor = FastVisionModel.from_pretrained(
    "unsloth/Qwen2.5-VL-3B-Instruct",
    load_in_4bit = False, 
    use_gradient_checkpointing = "unsloth",
    tokenizer_name="unsloth/Qwen2.5-VL-3B-Instruct"  
    )

the error:

TypeError Traceback (most recent call last)
/tmp/ipython-input-1738901268.py in <cell line: 0>()
----> 1 model, processor = FastVisionModel.from_pretrained(
--> 857 model, tokenizer = FastBaseModel.from_pretrained(
858 model_name = model_name,
859 max_seq_length = max_seq_length,

TypeError: unsloth.models.vision.FastBaseModel.from_pretrained() got multiple values for keyword argument 'tokenizer_name'

After checking the source code and I think this error occurs because the tokenizer_name parameter is passed twice internally: once from the user's kwargs and once from the internal logic in FastModel.from_pretrained.

Environment:
Python: 3.12.11
OS: Linux 6.1.123+
PyTorch: 2.8.0+cu126
CUDA: 12.6
GPU: Tesla T4
Unsloth: 2025.9.1
Transformers: 4.55.4
Accelerate: 1.10.1
Bitsandbytes: 0.47.0

[rjarun8235]

That's right - there is a name conflict between the function parameter and **Kwargs unpacking "tokenizer_name". on it! @AhmadAlmustadi

[mmathew23]

Hi @AhmadAlmustadi can you help us understand why the need to pass a tokenizer_name for a different tokenizer? At least in your example you seem to be passing the same tokenizer as model.

[AhmadAlmustadi]

Hi @mmathew23
Thanks for the question!
Short answer: I usually fine-tune many models but don’t upload the processor/tokenizer with every fine-tuned checkpoint because I didn’t change it — I keep using the base model’s processor for testing

I fixed it locally by always uploading the processor with each test (so each model repo contains a processor) but I just wanted to point out the bug.