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

[quic-amitraj]

Problem

When compiling Gemma4-E2B or Gemma4-E4B with use_onnx_subfunctions=True in qaic-vllm disaggregated serving, the decode QPC compilation consistently fails:

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

The encoder QPC compiles successfully; only the decoder (with -sub-functions) fails.

JIRA:

Root Cause

In QEffHybridCache, QEffHybridChunkedCache, and QEffGemma4DynamicLayer (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 node

The rolling_indices[:ctx_len] slice becomes an ONNX Slice node inside the QEffGemma4TextDecoderLayer subfunction. Its ends tensor is ctx_len = Shape(past_key)[2] (= sliding_window), which is pre-computed in the outer ONNX graph as Gather(Shape(past_key), 2) and injected into the subfunction as an opaque INT32 argument. Inside the subfunction body, the QAIC compiler cannot resolve this as a compile-time constant and rejects the graph.

This is the same class of bug as the CtxGatherCB comp_ctx_len fix in commit c89c4f71.

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 — no behavioural change. The resulting Range op with a dynamic upper bound is already permitted in QAIC subfunction lowering (the existing ctx_indices = torch.arange(ctx_len) in the same function demonstrates this). The Slice node is eliminated entirely.

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

Changes

File	Change
QEfficient/transformers/cache_utils.py	Replace arange(layer_ctx_len)[:ctx_len] with arange(ctx_len) in QEffHybridCache.update(), QEffHybridChunkedCache.update(), and QEffGemma4DynamicLayer.update()

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 — no regression
• Verified Slice_520 absent from re-exported subfunction ONNX body
• Corresponding fix already merged to release/v1.22.0 as PR fix: eliminate non-constant Slice ends in Gemma4 sliding-window CB subfunction #1170

Sdk: 1.22.1.18

[quic-rishinr]

How is this working for the other models if we're using the same logic in the cache utilities?
all_indices = torch.arange(layer_ctx_len) + kv_position_ids.max() + 1.
The same change is already present in both HybridChunkedCache and HybridCache.