The encoded tokens from the test look like this:

[4913, 70398, 788, 895, 11, 13265, 1313, 788, 330, 19337, 3323, 497, 330, 38460, 788, 830, 11, 330, 75, 13105, 788, 895, 11, 330, 1796, 788, 330, 151646, 497, 330, 15338, 13533, 788, 895, 92, 151644, 74785, 279, 23670, 15473, 4128, 13, 151645]

And the test target looks like this:

[151646, 151644, 74785, 279, 23670, 15473, 4128, 13, 151645]

But even when changing the test target to the actually encoded tokens, it still crashes, so I still need to investigate. In any case, I have already verified that the DeepSeek models work with the latest Jinja.

The test targets were obtained from the Python tokenizer, they correspond to <｜begin▁of▁sentence｜><｜User｜>Describe the Swift programming language.<｜Assistant｜>. The problem here is that the bos_token is passed in the context as a dictionary, not a String. This means that the result from applyChatTemplate won't be correct, as the test shows.

Looking into it.

As you can see here, the prompt from the test is being encoded correctly, and there are no problems interacting with the model, but as soon as you call decode on the encoded tokens, it crashes. I think the problem must be somewhere in swift-transformers. Perhaps it's a text encoding issue. I noticed that spaces are getting encoded as an unusual character.

@pcuenca, since you're more familiar with the library's internals than me, perhaps you have a better intuition about how to approach the solution. My initial attempts at solutions with Sonnet and the entire library as context were unsuccessful.

Merging this. As explained, the jinja upgrade will come momentarily as these changes are general.