[Draft][JAX] MoE block optimization

[jberchtold-nvidia]

Description

Please include a brief summary of the changes, relevant motivation and context.

Fixes # (issue)

Type of change

• Documentation change (change only to the documentation, either a fix or a new content)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Infra/Build change
• Code refactoring

Changes

Please list the changes introduced in this PR:

• Change A
• Change B

Checklist:

• I have read and followed the contributing guidelines
• The functionality is complete
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[greptile-apps]

Confidence Score: 2/5

[High risk] Adds MoE optimization paths with new kernel dispatch and weight handling.

Fix the bootstrap axis count, expert-weight ordering, and optional-dependency test failure before merging.

Findings

1.  Separate DP and FSDP fail ▶
2.  Tokens use wrong experts ▶
3.  Optional package breaks tests ▶
4.  Fusion switch does nothing ▶

Summary

Adds cuDNN grouped GEMM/SwiGLU execution, quantized FSDP weight gathering, resource-based MoE configuration, and checkpoint names.

• Separate DP and FSDP axes still conflict with bootstrap output sizes.
• FSDP-first expert sharding can select the wrong expert weights.
• The default test launcher now fails without optional cuDNN JAX support.
• The new environment-variable documentation does not match the implementation.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[MoE call and mesh resources] --> B[Route tokens]
  B --> C[EP dispatch]
  W[Expert weight shards] --> Q{Quantize before gather?}
  Q -->|Yes| G[Quantize local shards and gather data and scales]
  Q -->|No| H[Gather full-precision weights and quantize]
  G --> F{Selected FFN path}
  H --> F
  C --> F
  F -->|cuDNN| D[Fused grouped GEMM and SwiGLU]
  F -->|Fallback| E[TE grouped GEMM and activation]
  D --> I[Down projection]
  E --> I
  I --> J[EP combine]

Loading

_{Reviews (1) · Last reviewed commit: "Preserve gate/up pairing in quantized JA..."}

[greptile-apps]

Separate DP and FSDP fail

With distinct DP and FSDP axes larger than one, moe() now shards batches and EP outputs across both axes. But ep_bootstrap() still calculates num_ep_groups from just one outer axis. On a DP2/FSDP2/EP2 mesh, EP outputs have leading size 4 but are partitioned across 8 devices, so compilation fails. Update bootstrap group counting alongside the new resource API.

[greptile-apps]

Tokens use wrong experts

When logical rules place ("fsdp", "ep") on the expert dimension, gathering only FSDP does not recover the contiguous expert slice that EP routing expects. With 8 experts and EP2/FSDP2, EP rank 0 gathers experts [0, 1, 4, 5] instead of [0, 1, 2, 3]. The code accepts this order and uses those weights as EP-local experts, producing wrong outputs. Require EP before FSDP on this dimension, or restore the expected expert ownership before running the FFN.

[greptile-apps]

Optional package breaks tests

The launcher now always runs the cuDNN phase, but its tests import cudnn.jax without a skip. If that optional module is absent on a supported multi-GPU machine, the previously usable launcher fails with ModuleNotFoundError even when ordinary TE execution works. Skip the cuDNN-only tests when the required APIs are unavailable, or make this phase explicitly opt-in.

[greptile-apps]

Fusion switch does nothing

This entry documents an environment variable that the implementation never reads. It also says fusion defaults off and backward uses ordinary TE execution, while use_cudnn_fusion defaults to True and fused backward calls grouped_gemm_dswiglu. Replace this entry with the actual argument and execution behavior so users do not rely on an ineffective switch.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!