fix: eliminate non-constant Slice ends in Gemma4 sliding-window CB subfunction

[quic-amitraj]

Problem

When compiling Gemma4ForConditionalGeneration with use_onnx_subfunctions=True and continuous_batching=True, the QAIC compiler fails with:

QAIC_ERROR:
Error message:  [Operator-'Slice_520'] : Slice: Non-constant ends tensor not supported.
Unable to AddNodesToGraphFromModel

This occurs during language-decoder QPC compilation when -sub-functions is passed. The vision encoder compiles successfully; only the decoder fails.

Root Cause

In QEffGemma4DynamicLayer.update() (cache_utils.py), the sliding-window rolling-index computation was:

all_indices     = torch.arange(layer_ctx_len) + kv_position_ids.max() + 1
rolling_indices = torch.where(all_indices > layer_ctx_len - 1, all_indices % layer_ctx_len, all_indices)
rolling_indices = rolling_indices[:ctx_len]   # ← generates Slice_520

The rolling_indices[:ctx_len] slice translates to an ONNX Slice node inside the QEffGemma4TextDecoderLayer subfunction. Its ends tensor is ctx_len = Shape(past_key.0)[2] (= sliding_window), which is pre-computed in the outer ONNX graph as Gather(Shape(past_key.0), 2) and injected into the subfunction as an opaque INT32 argument (onnx::Cast_1033). Inside the subfunction body, the QAIC compiler sees this as a dynamic value — not a shape-derived constant — and rejects it.

This is the same class of bug as the CtxGatherCB comp_ctx_len regression fixed in c89c4f7.

Fix

Replace torch.arange(layer_ctx_len)[:ctx_len] with torch.arange(ctx_len) directly.

# Before
all_indices     = torch.arange(layer_ctx_len) + kv_position_ids.max() + 1
rolling_indices = torch.where(all_indices > layer_ctx_len - 1, all_indices % layer_ctx_len, all_indices)
rolling_indices = rolling_indices[:ctx_len]

# After
all_indices     = torch.arange(ctx_len) + kv_position_ids.max() + 1
rolling_indices = torch.where(all_indices > layer_ctx_len - 1, all_indices % layer_ctx_len, all_indices)
# rolling_indices already has ctx_len elements — no Slice needed

arange(n)[:n] == arange(n) identically, so there is no behavioural change. The Range op with a dynamic upper bound is already permitted in QAIC subfunction lowering — the existing ctx_indices = torch.arange(ctx_len)[None, None, ...] line in the same method demonstrates this. Slice_520 is eliminated entirely from the exported subfunction body.

The fix is also correct for the CCL case: torch.arange(min(sliding_window, CCL)) naturally produces CCL elements without any slice.

Changes

File	Change
QEfficient/transformers/cache_utils.py	Replace arange(layer_ctx_len)[:ctx_len] with arange(ctx_len) in QEffGemma4DynamicLayer.update()
examples/image_text_to_text/models/gemma_vision/gemma4/gemma4_cb.py	Update example to use_onnx_subfunctions=True to exercise the now-working path

Test Plan

• gemma4_cb.py with use_onnx_subfunctions=True, continuous_batching=True, full_batch_size=4, 2-layer reduced config — compiles and runs end-to-end on AI100
• gemma4_cb.py with use_onnx_subfunctions=False — continues to pass (no regression)
• Verified Slice_520 is absent from the re-exported subfunction ONNX body

[quic-hemagnih]

@quic-amitraj - Can you please post the following, you can use Gemma4-E2B-IT model (quick for testing)

1. Issue reproducer
2. Fix validation
3. PR on mainline.

Lets get it ready by Monday, so that we can merge your changes.