Instead of having one module per tokenizer (which we generated with a macro, since they were the same except for some defaults), we now have a single Bumblebee.Text.PreTrainedTokenizer module with a :type field, somewhat similar to how we have models with multiple architectures. We use the type to pick the right set of defaults.
Also, instead of passing options to Bumblebee.apply_tokenizer, they need to be set on the tokenizer itself via Bumblebee.configure. I added a deprecation notice, and also for serving users it's handled transparently either way. This is primarily a small optimisation as mentioned in https://github.com/elixir-nx/bumblebee/pull/307#discussion_r1426527482, but also aligns with featurizers.
Closes #143.
Instead of having one module per tokenizer (which we generated with a macro, since they were the same except for some defaults), we now have a single
Bumblebee.Text.PreTrainedTokenizermodule with a:typefield, somewhat similar to how we have models with multiple architectures. We use the type to pick the right set of defaults.Also, instead of passing options to
Bumblebee.apply_tokenizer, they need to be set on the tokenizer itself viaBumblebee.configure. I added a deprecation notice, and also for serving users it's handled transparently either way. This is primarily a small optimisation as mentioned in https://github.com/elixir-nx/bumblebee/pull/307#discussion_r1426527482, but also aligns with featurizers.