Added subfunction fix for gemma 4 with CB

[abhishek-singh591]

Summary

This PR fixes Gemma4 vision continuous-batching compilation with use_onnx_subfunctions=True.

The QAIC compiler was failing on the Gemma4 decoder ONNX with:

Range: limit input must be a constant tensor

The failing Range came from the Gemma4 sliding-window cache update path.

Root Cause

In the Gemma4 sliding cache update, the sliding context length was derived from the KV-cache tensor shape:

layer_ctx_len = self.keys.shape[2]

This value was then used to build cache indices with torch.arange(...).

With ONNX subfunctions enabled, this shape-derived value became a dynamic input inside the decoder-layer subfunction:

Shape(past_key) -> Gather -> Range limit

QAIC requires the Range limit inside subfunctions to be constant, so compilation failed.

Fix

Use the static Gemma4 sliding-window config value instead of deriving it from the runtime KV-cache shape.

For sliding-attention layers, the attention module now passes cache_kwargs["sliding_window"] = self.sliding_window into the cache update path.

The Gemma4 cache layer also stores the sliding-window length from config, so sliding cache indexing can use a compile-time constant instead of self.keys.shape[2].

Additionally, dummy KV cache creation for sliding layers now uses layer_seq_len = config.sliding_window instead of layer_seq_len = min(config.sliding_window, seq_len).

Validation

Validated using:

/home/abhishek/dynamo/bin/python examples/image_text_to_text/models/gemma_vision/gemma4/gemma4_cb.py

The script completed successfully with use_onnx_subfunctions=True.

[quic-hemagnih]

@abhishek-singh591 Can you run gemma4_diss.py script and ensure that perf for Gemma4-26B-A4B-IT model is not impacted with these changes.