[None][refactor] AutoDeploy: Use PyTorch-native format for NVFP4 weight_scale in IR ops, defer kernel-specific swizzling to fusion passes

Summary

The AutoDeploy IR op torch_fake_quant_nvfp4_linear currently stores weight_scale as swizzled uint8 — a CUTLASS-specific format applied during the weight loading transform (quantization.py load hook). This causes problems for downstream consumers (e.g., ONNX export in EdgeLLM, PR #11946) that expect scales in a PyTorch-native dtype (torch.float8_e4m3fn) and un-swizzled layout.

The uint8 dtype is used as a generic byte buffer because the CUTLASS FP4 kernel expects a specific memory layout that doesn't map to any native PyTorch floating-point type. However, coupling the IR op to a specific kernel's format leaks backend assumptions into the shared representation.

Problem

1. ONNX export misinterprets uint8 weight scales — TensorRT rejects the exported model because it expects float-typed scales (PR #11946).
2. Swizzled layout is kernel-dependent — different backends (CUTLASS FP4, trtllmgen NVFP4) require different swizzling, so baking one kernel's format into the IR op creates coupling issues.
3. MoE flow uses torch_quant_nvfp4_linear (the CUTLASS-bound op) directly in quantize_nvfp4_moe instead of the IR op torch_fake_quant_nvfp4_linear, further entangling the IR with a specific backend.

Proposed Design

As discussed, the long-term design should be:

1. torch_fake_quant_nvfp4_linear everywhere until post-load fusion stage — this is the AutoDeploy IR op for NVFP4 GEMM. Weight scales should be stored in PyTorch-native format (e.g., torch.float8_e4m3fn, un-swizzled, matching the modelopt/unified checkpoint format).
2. Post-load fusion passes (the ones that swap the IR op for performant kernel backends) are responsible for:
   • Converting weight scales to the kernel-expected format (e.g., CUTLASS swizzled uint8)
   • No runtime modification needed (no performance drop)
   • Different transforms can apply different swizzling as needed
3. Load hooks should load into the PyTorch-native format (may simplify to no-op if it matches modelopt-native format).

Naming Cleanup

• Rename torch_quant_nvfp4_linear → trtllm_quant_nvfp4_linear (or similar) to indicate it's a CUTLASS/TRT-LLM-specific op, aligning with AutoDeploy IR naming convention.
• Rename torch_fake_quant_nvfp4_linear → torch_quant_nvfp4_linear to reflect that it is the canonical IR op (not "fake").

Affected Code

Phased Approach

Phase 1 (unblocks EdgeLLM / PR #11946)

• Handle transforms that use torch_fake_quant_nvfp4_linear: remove swizzling from load hook, move it to the post-load fusion pass that replaces with torch_quant_nvfp4_linear.
• MoE transforms can use a small workaround for now.

Phase 2

• Update MoE transforms to use torch_fake_quant_nvfp4_linear as the IR op.
• Revisit MoE unit tests (may need hand-written inputs to avoid fake-quant vs real-quant numerical drift).
• Apply the op renaming cleanup.

Context

• EdgeLLM ONNX export PR: #11946
• Models using swiglu fusion (e.g., GLM 4.7 Flash) — any model with shared experts + silu/mul activation
• trtllmgen NVFP4 also required re-doing swizzling, confirming it is not standardized across kernels