fix: recognize EXL3 base layers in LoRA device detection

[Nakanokensetsu]

Summary

Enabling --enable-lora on any EXL3-quantized model fails during LoRA layer construction with:

ValueError: Unsupported base layer: MergedColumnParallelLinear(in_features=..., output_features=..., ...)

Root cause

aphrodite/lora/layers/utils.py's _get_lora_device() determines where to place LoRA adapter tensors by checking a fixed allowlist of quant-method-specific weight attribute names:

if hasattr(base_layer, "weight"): ...
elif hasattr(base_layer, "weight_packed"): ...
elif hasattr(base_layer, "qweight"): ...
elif hasattr(base_layer, "ark_linear"): ...
elif hasattr(base_layer, "w2_weight"): ...
elif hasattr(base_layer, "w2_weight_packed"): ...
elif hasattr(base_layer, "w2_qweight"): ...
else:
    raise ValueError(f"Unsupported base layer: {base_layer}")

Exl3LinearMethod (in aphrodite/model_executor/layers/quantization/exl3.py) stores its quantized weights under EXL3-specific attribute names — suh, svh, trellis, mcg, mul1 — none of which are in this list. So EXL3 + LoRA has apparently never been exercised: any EXL3 model hits this ValueError as soon as LoRA layer wrapping runs, regardless of architecture.

Fix

Add a branch recognizing the trellis attribute. Exl3LinearMethod.create_weights() raises NotImplementedError on non-CUDA platforms (EXL3 is CUDA-only by construction), and process_weights_after_loading() always moves the per-shard tensors to torch.device("cuda", torch.cuda.current_device()). So using the current CUDA device directly is correct here — the placeholder trellis parameter's own .device wouldn't reflect where the real tensors actually live (they're stored in a separate exl3_tensors dict per shard, not in the parameter's .data), so checking for the attribute's presence (to select EXL3) and then querying the current device (rather than base_layer.trellis.device) is the correct approach.

Test plan

Verified end-to-end on Qwen3.6-27B-exl3-3.08bpw (TP=2, RTX 5070 ×2) with --enable-lora --max-lora-rank 64: LoRA layer construction now succeeds past this point instead of raising immediately. (A separate, GDN-architecture-specific EXL3 weight-loading issue was also found and fixed — see companion PR #1711; both were needed together to get a working EXL3+LoRA launch on this architecture.)

[Nakanokensetsu]

Good catch, thanks — updated to use torch.accelerator.current_device_index() instead of torch.cuda.current_device(). Verified it returns the same index on this setup (torch 2.11.0+cu130). Note the surrounding torch.device("cuda", ...) is left as-is since EXL3/trellis tensors are CUDA-only per the comment above — happy to generalize that too if you'd rather.