Make sliding_window for Qwen2 optional

[alvarobartt]

What does this PR do?

This PR makes the sliding_window to be Option<usize> instead of usize as it can be set to null; additionally, the model prefix is only pushed for FlashQwen2 if available, as the Qwen2 model does not come with the prefix since it's an instance of Qwen2Model not Qwen2ModelForCausalLM, meaning that it doesn't have neither the lm_head nor the model prefix.

This PR then enables models as e.g. https://huggingface.co/mims-harvard/ToolRAG-T1-GTE-Qwen2-1.5B (also Azure asked us to add support for this model and a recent discussion has been opened at https://huggingface.co/mims-harvard/ToolRAG-T1-GTE-Qwen2-1.5B/discussions/1, which is unrelated as they are trying to use TGI instead of TEI, but that would unlock serving this model).

Before submitting

• This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
• Did you read the contributor guideline, Pull Request section?
• Was this discussed/approved via a Github issue or the forum? Please add a link to it if that's the case.
• Did you make sure to update the documentation with your changes? Here are the documentation guidelines, and here are tips on formatting docstrings.
• Did you write any new necessary tests?

Who can review?

@Narsil (and @pagezyhf for context on the Azure support)

[alvarobartt]

@Narsil not sure if the contains_tensor approach is the best towards preventing pushing the prefix model when not there i.e. when the Transformers model instance is Qwen2Model instead of Qwen2ModelForCausalLM (not sure this also affects Mistral but I'll check and if that's the case submit a follow-up PR).

[Narsil]

We should update the non-flash version too I think.

[Narsil]

Checking for tensor name is not the best, but honestly there's no great way. The least worst is to know deterministically based on some other information (so the error checking works well).

[alvarobartt]

Checking for tensor name is not the best, but honestly there's no great way. The least worst is to know deterministically based on some other information (so the error checking works well).

Yes I agree with you, couldn't find of a better way, it seems that's tight to the arch in this case being Qwen2Model, so we could check the arch and if different that Qwen2Model then calling pp(model) before passing it to the Qwen2Attention? That may look cleaner, but still we would need to "manipulate" the VarBuilder in advance.