[shengliangxu]

Note

Re-parented on 2026-10-30 with #2742 onto #3136, #2741 [2/3] (the expert-parallel loader). #2741 was split into three PRs on review: #3131 [1/3], #3136 [2/3] and #2741 [3/3], its post-load refusals. This PR stays on #2742, whose dense-sharding rule it extends. The series first became a tree on 2026-10-27 (this PR was [11/21]).

Base: #2742. The diff below is this PR's alone, and it merges after #2742.

Re-parent: this PR's diff is unchanged, except that its FP8 refusals run inside #3136's checks guard, so a rank refusing alone fails every rank. That includes the per-tensor and unverifiable FP8-config refusals, with their read of the checkpoint's config.json. The PR's 25 commits are condensed into one.

Series layout

• main ([OMNIML-6073] [2/3] Quantize fused experts under grouped_mm; leave transposed layouts unquantized #2745, [OMNIML-6064] Load each rank's checkpoint shard straight into a meta-built model #2739, [OMNIML-6052] Add the distribution plan, a run-scoped process group, and collectives that fail together #2736, [OMNIML-6054] Decide how a model is distributed, from the model built on the meta device #2737, [OMNIML-6082] [1/3] Let a reverse conversion record a merge rule no key matched #3100, [OMNIML-6082] [2/3] Move each tensor of a sharded model whole to one owner rank #3101, [OMNIML-6081] [1/2] Pack sharded weights in FSDP2 weight-update windows, and NVFP4 DTensor shards #3099, [OMNIML-6073] [1/2] Calibrate and fold expert-parallel fused experts on each rank's own experts #3122, [OMNIML-6060] [1/3] Add require_transformers, and build a VLM without its LM head #3131 [1/3] and [OMNIML-6082] [3/3] Write a sharded model's HF checkpoint shards from each tensor's owner rank #2751 have merged)
  • [OMNIML-6073] [2/2] Calibrate fused experts on grouped_mm and torch_a2a instead of forcing eager #3074 → {[OMNIML-6073] Quantize Nemotron-H's experts under grouped_mm, with their wrapper in its model folder #3067, [OMNIML-6071] Calibrate a distributed model on per-rank data #2740}; [OMNIML-6054] [1/2] Move fsdp2_wrap out of distributed.py into fsdp2_utils #3140 → [OMNIML-6054] [2/2] Route load_pretrained by the distribution plan #2779
  • shengliangx/hfep-base-6a-ep-loader = [OMNIML-6054] [2/2] Route load_pretrained by the distribution plan #2779 + [OMNIML-6073] Quantize Nemotron-H's experts under grouped_mm, with their wrapper in its model folder #3067 + [OMNIML-6071] Calibrate a distributed model on per-rank data #2740
    • [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136 [OMNIML-6060] [3/3] Refuse an expert-parallel load that would calibrate the experts wrong #2741 [2/3] expert-parallel loader
      • [OMNIML-6060] [3/3] Refuse an expert-parallel load that would calibrate the experts wrong #2741 [3/3] the loader's post-load refusals
      • [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 dense sharding
        • [OMNIML-6062] Dequantize block-FP8 checkpoints as they load expert-parallel #2743 block-FP8 dequantization (this PR)
      • [OMNIML-6060] Load an expert-parallel plan through load_pretrained #2780 expert-parallel load routing (merges after [OMNIML-6060] [3/3] Refuse an expert-parallel load that would calibrate the experts wrong #2741 [3/3])
        • [OMNIML-6076] [3/3] Apply the model spec when deciding and loading expert-parallel #2746 expert parallelism in the model specs
      • [OMNIML-6063] [3/3] Load a checkpoint its model spec decompresses through the expert-parallel loader #2747 on-the-fly decompression
  • [OMNIML-6081] [2/2] Fold fused experts' quantizers into their weights shard-locally #2750 keep-fused fold
  • [OMNIML-6082] [3/3] Write a sharded model's HF checkpoint shards from each tensor's owner rank #2751 distributed-writer pieces
    • [OMNIML-6083] Write a sharded model's HF checkpoint without gathering it #2752 no-gather export → [OMNIML-6084] Export an expert-parallel model through the no-gather writer #2753 expert-parallel export

What does this PR do?

Type of change: New feature

A native block-FP8 checkpoint, such as DeepSeek-V3, is dequantized to bf16 while it loads expert-parallel, through transformers' FineGrainedFP8Config(dequantize=True). Quantizers attach to bf16 weights.

• A block-FP8 checkpoint keeps its dense part replicated (moved here from [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742, where block FP8 did not load at all): DCP, which loads a sharded dense part, cannot dequantize it: it reads the checkpoint as stored. Left to decide, the plan ([OMNIML-6054] Decide how a model is distributed, from the model built on the meta device #2737) replicates it and says so; an explicit fsdp is refused by the decision, naming MODELOPT_FSDP_SIZE=1, and by the loader.

• Per-tensor FP8 is refused. AutoFP8's per-tensor checkpoints name the same quant_method without a weight_block_size; transformers' dequant would read them as 128x128 blocks and load their weights unscaled, without an error. The load refuses them, before anything loads, as fp8-per-tensor, naming the weight_block_size they lack. A config handed in as transformers' FP8 config object, which fills in a 128x128 block, is read against the checkpoint's own config.json, and refused when the path holds none to read (a Hub ID the load has not made local yet). A tiny per-tensor FP8 Llama, loaded that way on transformers 5.18:

  Weights	Largest absolute value
  original	0.079
  loaded as block FP8	448

On transformers older than 5.10.1, the loader also patches that dequantization in three ways:

• Partial last block. Stock dequantization infers the block size by dividing the weight shape by the scale grid's, so it raises on a weight whose last 128x128 block is partial, such as DeepSeek-V3's kv_a_proj_with_mqa: (576, 7168) with a (5, 56) grid. It also raises on an empty scale grid. The patch tiles each block's scale and crops to the weight, using the checkpoint's weight_block_size.
• Output dtype. Stock dequantization does not take the destination dtype. The patch emits the destination dtype the loader passes, else the model's dtype.
• Routed experts. The FP8 quantizer prepends its dequantization to every weight converter, so the fused-experts converter no longer starts with a MergeModulelist. The loader then assigns no per-expert index, and the expert-parallel shard slices each expert's rows instead of whole experts: a DeepSeek-V3 gate_up_proj loads as (256, 32, 7168) and fails calibration. The patch fuses the dequantization into the merge, so the converter starts with a MergeModulelist again and runs as upstream intends.

The patch installs once and survives a re-imported module. From transformers 5.10.1 it keeps upstream's dequantization, which takes the destination dtype and decodes E8M0 scales, and only pads a weight with a partial last block to whole blocks for it, in its own fp8 dtype, since upstream still infers the block from the scale grid: (448, 7168) under a (4, 56) grid would otherwise be scaled in blocks of 112 rows.

The pre-5.10.1 dequantization scales its own fp32 copy of the weight in place, through a view of its whole column blocks, against scales tiled over the rows only, so no full-size fp32 tile is built. It is rebound only once the expert converter's fuse is in, so a refused patch leaves transformers as it was. Against scaling by a full-size fp32 tile, on CPU with one thread:

Weight	Peak memory growth: full tile	Peak memory growth: row-tiled	Time: full tile	Time: row-tiled
(18432, 7168)	1014 MiB (8.0 B/elem)	759 MiB (6.0 B/elem)	1.13 s	0.89 s
(7168, 2048)	116 MiB	88 MiB	127 ms	99 ms

Usage

Automatic: load_and_prepare_ep reads the checkpoint's quantization_config and picks this path for quant_method: fp8 with a weight_block_size.

Testing

• In tests/unit/torch/utils/test_model_load_utils.py (first written as test_fp8_dequant_patch.py), on CPU:

  • the patched dequant against a blockwise reference, a weight narrower than one block included;
  • block size from the scale grid or the DeepSeek default;
  • the requested output dtype;
  • an empty scale grid refused for a non-empty weight, rather than passing it through unscaled;
  • idempotent installs that keep the latest dtype;
  • no double-wrapping of a re-imported module;
  • a clean undo;
  • transformers 5.10.1 keeping its own dequant, padded for every partial-block weight, a grid-divisible one included ((192, 256) on a (2, 2) grid);
  • the fused expert converter, run on a real fused-experts converter: it starts with a MergeModulelist, and per-expert block-FP8 weights come out as the blockwise reference. It fails without the fusion, and if the fused op skips the dequantization or the merge. Skipped on transformers 5.5, which has no update_weight_conversions.

• Mutation-checked: each test fails on at least one deliberate break of the code.

• The block-size cases join the blockwise-reference table, and dtype and version cases that took the same branch as a kept one are dropped.

• A refused fuse leaves transformers' dequant as it was.

• The block-FP8 dense layout: the loader refuses a plan that shards the dense part (test_model_load_utils.py); the decision replicates it, or refuses an explicit fsdp, naming MODELOPT_FSDP_SIZE=1 (test_model_load_utils.py).

• Per-tensor FP8 refused before anything loads and read as fp8-per-tensor (test_ep_loader.py; both rows fail without the fix); the block-FP8 configs in the tests carry their weight_block_size.

• Locally on this revision, the stack rebased on main c6fa613: pre-commit over the whole PR against main, at every PR of the stack; and at the stack's tip the full tests/unit on transformers 5.18 and 5.5 and on torch 2.8, and the hf_ptq example tests, each with the same failures as main in that environment. CI runs the full unit suite.

• GPU results at a named head are under "GPU runs, 2026-10-30" at the end of this section; the other GPU results here were measured on earlier revisions of this branch.

• On GPUs: DeepSeek-V3 (block FP8) loads, calibrates and exports expert-parallel through this path (see [OMNIML-6085] [3/3] Run expert-parallel PTQ from hf_ptq.py #2754).

• Re-cut on 2026-10-27 (see the note at the top): pre-commit, mypy included, passes at this head over the whole change against main, and the series' PRs merged together give a tree byte-identical to the former stack's tip. This PR's own unit tests pass at this head on CPU (torch 2.14, transformers 5.18); CI runs the full unit suite.

• Review fixes, 2026-10-27: a dequant dtype the config names as a string is read as the dtype it names; the test file's dead Fp8Dequantize skip is gone. Each behaviour fix has a test that fails without it; pre-commit, mypy included, and this PR's own unit tests pass at this head.

• Review fixes, 2026-10-27, round 2: the block-FP8 case of the replicated-dense-part test expects the out-of-memory warning [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 now gives when the plan replicates a dense part it cannot shard. Pre-commit, mypy included, and this PR's own unit tests pass at this head.

• Review fixes, 2026-10-27, round 3: the pre-5.10.1 dequant override takes the destination dtype the loader passes (5.10.1 is the first release to pass one); a partial-block weight is padded in its own fp8 dtype; the 5.10.1 wrapper does not wrap itself on a re-import; a test pins that transformers' config merge keeps the checkpoint's weight_block_size; a comment says why the block-fp8 dense rule applies under expert parallelism only; the per-tensor FP8 refusal names the missing weight_block_size. Each behaviour fix has a test that fails without it; pre-commit, mypy included, and this PR's own unit tests pass at this head.

• Review fixes, 2026-10-27, round 4: a per-tensor FP8 checkpoint whose config comes in as transformers' FP8 config object is refused too, its block read from the checkpoint's own config.json; for a block-fp8 checkpoint, the several-replicas remedy names only MODELOPT_FSDP_SIZE=1; both dequant patches check a weight's dims before unpacking its shape, and the pre-5.10.1 override drops an FP4 branch it could not run. Each behaviour fix has a test that fails without it; pre-commit, mypy included, and this PR's own unit tests pass at this head.

• Review fixes, 2026-10-27, round 5: an FP8 config object whose checkpoint has no readable config.json (a Hub ID not yet made local) is refused rather than read as 128x128 blocks; for a block-fp8 dense part within several replicas the remedy also names starting from an unquantized copy. Each behaviour fix has a test that fails without it; pre-commit, mypy included, and this PR's own unit tests pass at this head.

• Rebased on 2026-10-27 onto main 7c3c868, after [OMNIML-6064] Load each rank's checkpoint shard straight into a meta-built model #2739 merged: pre-commit, mypy included, and this PR's own unit tests pass at this head, and the series' PRs merged together add no unit-test failure over main (tests/unit/torch utils, export, quantization and models, on transformers 5.18 and 5.5.4 and on torch 2.8).

• Re-cut on 2026-10-29 (see the note at the top): rebased onto the re-cut [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 with no source conflict. Its edits of the deleted test_resolve_distribution_plan.py moved to test_model_load_utils.py. Pre-commit, mypy included, passes at this head over the whole change against main. On CPU at this head (torch 2.14), this PR's tests with test_ep_dense_sharding.py, test_ep_load_warmup.py, test_ep_loader.py, test_meta_dcp_load.py and test_model_load_utils.py pass on transformers 5.18 and 5.5.4.

• Rebased 2026-10-29 onto [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742's review fixes (0350840) with no conflict; this PR's own diff is unchanged. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head on transformers 5.18 and 5.5.4.

• Re-parented 2026-10-30 with [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 onto [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136 ([OMNIML-6060] [3/3] Refuse an expert-parallel load that would calibrate the experts wrong #2741 [2/3]). The FP8 refusals now run inside the loader's checks guard. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18 and 5.5.4.

• Rebased 2026-10-30 with [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 onto main 99c3834. The block-FP8 load notice now prints through print_rank_0, since [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742's loader no longer imports is_master; the rest of this PR's diff is unchanged. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18 and 5.5.4.

• Rebased 2026-10-30 with [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 onto [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136 96be72d; this PR's own diff is unchanged. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18 and 5.5.4.

• Review fix, 2026-10-30 (kevalmorabia97's review): below transformers 5.10.1, the block-FP8 override hands any weight that is not fp8 to transformers' own dequant, in the model dtype. From 5.9 that dequant unpacks packed FP4 (float4_e2m1fn_x2 or int8, with [1, 32] scales, as DeepSeek-V4 stores its routed experts), which the override returned at half its width. test_a_weight_that_is_not_fp8_keeps_transformers_dequant covers both dtypes and fails without the fix. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.9.0, 5.18 and 5.5.4.

• Rebased 2026-10-30 onto [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 201e2a5 (module-scope imports, a hook-signature warning, one more remedy in a refusal); this PR's own diff is unchanged. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18, 5.9.0 and 5.5.4.

• GPU runs, 2026-10-30, at c44d5c1: NVIDIA GB200, torch 2.11.0a0 (nv26.02), transformers 5.9.0, pytest with -p no:rerunfailures.

  Test file	2 GPUs	4 GPUs
  tests/gpu/torch/utils/test_expert_parallel_load.py	8 passed, 4 skipped (123 s)	12 passed (144 s)

  These results were taken at c44d5c1. Since then this PR moved its unit tests into test_model_load_utils.py and was rebased with [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742, last on 2026-10-30 onto the rebuilt base below; its source diff is unchanged, and the file was re-run at this head (the last entry here).

• Rebased 2026-10-30 onto [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 004de2a, which moved test_ep_dense_sharding.py and test_ep_load_warmup.py into test_model_load_utils.py; this PR's edit of the block-FP8 dense-layout test moved with it, and its own diff is otherwise unchanged. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18, 5.9.0 and 5.5.4.

• 2026-10-30: test_fp8_dequant_patch.py, which covered model_load_utils alone, moved into test_model_load_utils.py as one section with its fixtures, marks and parametrization, as CONTRIBUTING.md's naming rule asks (c884757). No test was added or dropped: tests/unit/torch/utils gives the same counts on CPU on transformers 5.18, 5.9.0 and 5.5.4, and pre-commit, mypy included, passes against main.

• Rebased 2026-10-30 with [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 onto the rebuilt shengliangx/hfep-base-6a-ep-loader, which after [OMNIML-6060] [1/3] Add require_transformers, and build a VLM without its LM head #3131 merged holds [OMNIML-6054] [2/2] Route load_pretrained by the distribution plan #2779 (on [OMNIML-6054] [1/2] Move fsdp2_wrap out of distributed.py into fsdp2_utils #3140, which moves fsdp2_wrap into modelopt/torch/utils/fsdp2_utils.py), [OMNIML-6073] Quantize Nemotron-H's experts under grouped_mm, with their wrapper in its model folder #3067 and [OMNIML-6071] Calibrate a distributed model on per-rank data #2740 on main 62a5c48. This PR's own diff is unchanged. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18, 5.9.0 and 5.5.4.

• GPU run, 2026-10-30, at this head, 9c917ae: tests/gpu/torch/utils/test_expert_parallel_load.py on transformers 5.18.0, the test file unchanged since the run at c44d5c1.

  GPUs	Passed	Skipped	Failed
  2	8	4	0
  4	12	0	0

  On 1 GPU every case skips, so it is no evidence. On 2 GPUs the four cases with expert parallelism over half the GPUs skip; on 4 GPUs all 12 run: each rank's experts and the logits against the whole model, and FP8 and NVFP4 quantized training (scales and gradients), with the experts over every GPU or half of them and the dense part replicated or FSDP2-sharded.

• Rebased 2026-10-30 with [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 onto [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136 e251f6c (meenchen's review round); this PR's own diff is unchanged. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18, 5.9.0 and 5.5.4.

• Review fix, 2026-10-30 (juhi10071998's comment): the expert-parallel load refuses a block-fp8 checkpoint below transformers 5.8, inside its checks guard. 5.7.0 has neither Fp8Dequantize._dequantize_one nor FineGrainedFP8HfQuantizer.update_weight_conversions, so its experts would load unscaled (7c83230). test_a_block_fp8_checkpoint_needs_the_transformers_that_dequantizes_its_experts presents 5.7.0 and fails without the check.

• Rebased 2026-10-30 with [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 onto [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136 1491b66, which refuses MXFP4: _EP_SOURCE_FORMATS is {None, "fp8"}, this PR's MXFP4 branch went with [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136's, and the hub-id test lost its mxfp4 row. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18, 5.9.0 and 5.5.4.

• GPU run, 2026-10-30, at 7192e05: tests/gpu/torch/utils/test_expert_parallel_load.py on transformers 5.18.0.

  GPUs	Passed	Skipped	Failed
  1	0	12	0
  2	8	4	0
  4	12	0	0

  On 4 GPUs every case runs, the four with expert parallelism over half the GPUs included, as at the run before. 1 GPU skips everything, so it is no evidence.

• GPU run, 2026-10-30, at this head, 7c83230: tests/gpu/torch/utils/test_expert_parallel_load.py on transformers 5.18.0.

  GPUs	Passed	Skipped	Failed
  1	0	12	0
  2	8	4	0
  4	12	0	0

  The same result as the run before, with the same test file, so it speaks for the code underneath. The file loads an unquantized checkpoint on transformers 5.18, so it cannot show the MXFP4 refusal or the block-FP8 floor of 5.8 firing: test_a_block_fp8_checkpoint_needs_the_transformers_that_dequantizes_its_experts (5.7.0) covers the block-FP8 floor, and [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136's mxfp4 refusal row the MXFP4 refusal, on CPU.

• Review suggestion, 2026-10-30 (Claude's review, approved): a checkpoint config.json holding valid JSON other than an object reads as one naming no FP8 block, so an FP8 config object meets the fp8-unverified refusal instead of an AttributeError (5000023). The new config-json-not-an-object row fails without the check. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18, 5.9.0 and 5.5.4. The GPU run above was at 7c83230; this one-line change is on a path the GPU test does not take.

• Rebased 2026-10-30 onto [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 a8ba054, with [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136 ad9559d (meenchen's review, round 3, on the base rebuilt with [OMNIML-6054] [2/2] Route load_pretrained by the distribution plan #2779 47ca6d1); this PR's own diff is unchanged. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18, 5.9.0 and 5.5.4. The GPU tests have not run on this head.

• Rebased 2026-10-30 onto [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 6415c94, with [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136 eb6c382 on main 059588b, on shengliangx/hfep-base-6a-ep-loader rebuilt there from [OMNIML-6054] [2/2] Route load_pretrained by the distribution plan #2779 3b814a6, [OMNIML-6073] Quantize Nemotron-H's experts under grouped_mm, with their wrapper in its model folder #3067 fbff3f3 and [OMNIML-6071] Calibrate a distributed model on per-rank data #2740 186efae. [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136 now also refuses a rank not yet bound to its GPU. This PR's own diff is unchanged. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18, 5.9.0 and 5.5.4. The GPU tests have not run on this head.

• Rebased 2026-10-30 onto [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 02388f9, with [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136 56353ef, whose new commits change only tests and one comment; this PR's own diff is unchanged. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18, 5.9.0 and 5.5.4.

• GPU run, 2026-10-30, at [OMNIML-6062] Dequantize block-FP8 checkpoints as they load expert-parallel #2743's head 7540a2e, which contains this PR's own commits as they are at this head: tests/gpu/torch/utils/test_expert_parallel_load.py on transformers 5.18.0.

  GPUs	Passed	Skipped	Failed
  1	0	12	0
  2	8	4	0
  4	12	0	0

  The same result as the runs before. On 4 GPUs every case runs, the four with expert parallelism over half the GPUs included; 1 GPU skips everything, so it is no evidence. Since that head, [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136 changed only tests and one comment, so the result speaks for this head's code.

• Rebased 2026-10-30 onto [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 72f1e49, with [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136 75bc2d6, which trims the docstring and comments this PR edits. This PR's own diff is unchanged but for its docstring lines, now on the trimmed docstring: it loads block-FP8 checkpoints on 5.8 or later, and a sharded dense part cannot load one. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18, 5.9.0 and 5.5.4. The GPU tests have not run on this head.

• At b1cec70 on a host with one visible GPU, tests/unit/torch/utils/test_ep_loader.py passed 57 of 57.

• Rebased 2026-10-30 onto [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 591b986, with [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136 ab06860 on main d464d30, on shengliangx/hfep-base-6a-ep-loader rebuilt there from [OMNIML-6054] [2/2] Route load_pretrained by the distribution plan #2779 8f9d877, [OMNIML-6073] Quantize Nemotron-H's experts under grouped_mm, with their wrapper in its model folder #3067 d452768 and [OMNIML-6071] Calibrate a distributed model on per-rank data #2740 9a87d15; this PR's own diff is unchanged. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18, 5.9.0 and 5.5.4.

• GPU runs, 2026-10-30, at an earlier head with the same own diff ([OMNIML-6062] Dequantize block-FP8 checkpoints as they load expert-parallel #2743's 6f5391d, which contains this PR's own commits as they are at this head), on transformers 5.18.0:

  • tests/gpu/torch/utils/test_expert_parallel_load.py:

  GPUs	Passed	Skipped	Failed
  1	0	12	0
  2	8	4	0
  4	12	0	0

  On 4 GPUs every case runs, the four with expert parallelism over half the GPUs included; 1 GPU skips everything, so it is no evidence.

  • tests/unit/torch/utils/test_ep_loader.py on a host with one visible GPU: 59 of 59 passed.

• Rebased 2026-10-31 onto [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 00a592d, with [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136 7747c5d, which moves test_ep_loader.py's cases into test_model_load_utils.py and the expert_parallel_mesh ones into test_moe_a2a.py. This PR's test edits moved with those cases, unchanged, and its own source diff is unchanged. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils collects and passes the same cases as before on CPU, on transformers 5.18, 5.9.0 and 5.5.4.

• Rebased 2026-10-31 onto [OMNIML-6061] Load the dense part sharded, and size the load warmup to each rank #2742 7ea4ac7, with [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136 930bb0f on main e352cac, on shengliangx/hfep-base-6a-ep-loader rebuilt there from [OMNIML-6054] [2/2] Route load_pretrained by the distribution plan #2779 c78d2e5, [OMNIML-6073] Quantize Nemotron-H's experts under grouped_mm, with their wrapper in its model folder #3067 adb9757 and [OMNIML-6071] Calibrate a distributed model on per-rank data #2740 dea9b79; this PR's own diff is unchanged. Pre-commit, mypy included, passes against main, and tests/unit/torch/utils passes on CPU at this head, on transformers 5.18, 5.9.0 and 5.5.4.

• GPU run, 2026-10-31, at [OMNIML-6062] Dequantize block-FP8 checkpoints as they load expert-parallel #2743's head 939bf6e on main e352cac, which contains this PR's head: tests/gpu/torch/utils/test_expert_parallel_load.py on transformers 5.18.0.

  GPUs	Passed	Skipped	Failed
  1	0	12	0
  2	8	4	0
  4	12	0	0

  The same 12 cases as before, now over the rebuilt base, which includes main's fused-MoE GPTQ change. On 4 GPUs every case runs, the dense-sharded ones included: each rank's experts and the logits against the whole model, and both quantized formats' training. 1 GPU skips everything, so it is no evidence.

Before your PR is "Ready for review"

• Is this change backward compatible?: ✅ Additive; runs only on the expert-parallel load of a block-FP8 checkpoint.
• If you copied code from any other sources or added a new PIP dependency, did you follow guidance in CONTRIBUTING.md: N/A
• Did you write any new necessary tests?: ✅
• Did you update Changelog?: N/A. The feature's entry lands with [OMNIML-6085] [3/3] Run expert-parallel PTQ from hf_ptq.py #2754.
• Did you get Claude approval on this PR?: ✅ Approved 2026-10-28 at a4609752e39. The 2026-10-29 re-cut only moved its edits of a deleted test file to test_model_load_utils.py (Testing).

Additional Information

Part 11 of 21 of expert-parallel PTQ for Hugging Face MoE models; merges after #2742.

Summary by CodeRabbit

• New Features
  • Added support for loading models from native block-FP8 checkpoints, converting weights to the model’s configured dtype during loading.
  • Improved handling of partial or empty scale grids, varied tensor shapes, and per-expert weights.
  • Added compatibility with older Transformers versions while preserving built-in behavior in newer versions.

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

• Last reviewed commit: 78b3825
• Latest commit, not reviewed: 939bf6e

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

The loader now configures dequantization for native FP8 checkpoints. For Transformers versions before 5.10.1, a compatibility patch handles scale grids and expert merging. Unit tests cover dequantization cases, patch behavior, and version gating.

Changes: FP8 checkpoint loading

Layer / File(s)	Summary
FP8 dequantization and validation modelopt/torch/utils/plugins/model_load_utils.py, tests/unit/torch/utils/test_fp8_dequant_patch.py	Adds dequantization support for partial and empty scale grids on Transformers versions before 5.10.1. Tests compare varied block shapes and output dtypes with reference results, and verify that newer versions bypass the patch.
Expert conversion and patch lifecycle modelopt/torch/utils/plugins/model_load_utils.py, tests/unit/torch/utils/test_fp8_dequant_patch.py	Combines FP8 dequantization with expert merging to preserve per-expert indexing. Tests cover converter ordering, repeated patching, hook wrapping, and restoration.
FP8 loader configuration modelopt/torch/utils/plugins/model_load_utils.py	Configures FP8 checkpoint loading with FineGrainedFP8Config(dequantize=True), applies the patch with the model dtype, and logs the selection. The MXFP4 configuration remains the alternative branch.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant load_and_prepare_ep
  participant from_pretrained
  participant CompatibilityPatch
  load_and_prepare_ep->>from_pretrained: load FP8 checkpoint with FineGrainedFP8Config(dequantize=True)
  load_and_prepare_ep->>CompatibilityPatch: apply patch with model dtype

Loading

Merge Risk: Moderate · up to 78b38

Loading block-FP8 checkpoints with older Transformers versions can silently produce incorrectly scaled weights in edge cases. Those weights would then be used for calibration and export. Before merging, make the patch reject scale grids that do not match their weights, or document why the current fallbacks are valid.

Pre-merge checks: 5

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Security Anti-Patterns		No listed security anti-pattern was introduced. The PR changes only modelopt/torch/utils/plugins/model_load_utils.py and a unit test; no modelopt/example dependency manifests changed. The added code…
Title check		The title names the main change: block-FP8 checkpoints are dequantized as they load under expert-parallel loading. The raw summary and PR objectives both center on the FP8 dequantization patch in load…
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.

Full details: Security Anti-Patterns

Explanation

No listed security anti-pattern was introduced. The PR changes only modelopt/torch/utils/plugins/model_load_utils.py and a unit test; no modelopt/example dependency manifests changed. The added code contains no torch.load(..., weights_only=False), numpy.load(..., allow_pickle=True), hardcoded trust_remote_code=True, external-input eval()/exec(), or # nosec comment. Existing trust_remote_code handling remains caller-configurable with a default of False.

Full details: Title check

Explanation

The title names the main change: block-FP8 checkpoints are dequantized as they load under expert-parallel loading. The raw summary and PR objectives both center on the FP8 dequantization patch in load_and_prepare_ep, which matches the title. The title is specific, uses the ticket tag, and is a single sentence of 8 words.

Finishing Touches

Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

Fix failing CI checks

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

[codecov]

Codecov Report

❌ Patch coverage is 93.54839% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 61.86%. Comparing base (aea6150) to head (adc762a).

Files with missing lines	Patch %	Lines
modelopt/torch/utils/plugins/model_load_utils.py	93.54%	6 Missing ⚠️

Additional details and impacted files

@@                            Coverage Diff                            @@
##           shengliangx/hfep-6b-ep-dense-sharding    #2743      +/-   ##
=========================================================================
+ Coverage                                  61.83%   61.86%   +0.03%     
=========================================================================
  Files                                        649      649              
  Lines                                      72969    73059      +90     
=========================================================================
+ Hits                                       45117    45195      +78     
- Misses                                     27852    27864      +12     

Flag	Coverage Δ
unit	61.86% <93.54%> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://NVIDIA.github.io/Model-Optimizer/pr-preview/pr-2743/
Built to branch gh-pages at 2026-10-27 00:04 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[shengliangxu]

/ok to test ed1ebbf

[shengliangxu]

/ok to test 6db2eb0

[shengliangxu]

/ok to test 14f1610

[shengliangxu]

/ok to test f647855

[shengliangxu]

@kevalmorabia97, an update: the GPU path you couldn't run passed at c44d5c1, on GB200 with torch 2.11.0a0 and transformers 5.9.0. That commit includes the packed-FP4 fix.

Test file at c44d5c1	2 GPUs	4 GPUs
tests/gpu/torch/utils/test_expert_parallel_load.py	8 passed, 4 skipped (123 s)	12 passed (144 s)

This head, 54430ac, is only a rebase onto #2742's two new commits, and this PR's own diff is unchanged. The tied-head question above is still open: a traceback and your torch, accelerate and safetensors versions would let me reproduce it.

[shengliangxu]

/ok to test 54430ac

[kevalmorabia97]

I reviewed this independently, with a focus on block-FP8 dequant correctness, per-rank expert and dense slices, and memory during load. It looks good to me at 54430ac.

• FP4 experts on transformers 5.9 (fixed in 54430ac). At e5ded19, the pre-5.10.1 override read packed-FP4 (int8) expert weights as plain integers and returned them at half width, with no error. Transformers 5.9's own dequant does unpack FP4, and DeepSeek-V4 stores its routed experts that way under a block-FP8 config. At this head, any weight that is not fp8 goes to transformers' own dequant. I checked on 5.9.0: a (256, 512) FP4 weight now matches stock up to bf16 rounding.
• The dequant matches a blockwise reference for a partial last block, a weight narrower than one block, and E8M0 scales.
• Under expert parallelism, each expert's weight and scale get the same expert index and are taken whole, and an expert held on another rank drops both. The dense part stays replicated for block FP8, both in the plan and in the loader's refusal, so a scale never meets a sharded tensor.
• Memory is about 6 B/elem per weight on the pre-5.10.1 path, and the 5.10.1+ path pads in fp8.
• Mutation checks: each of four deliberate breaks fails tests (the expert fuse, block-size choice, per-tensor refusal, partial-column scaling).

Ran on CPU (transformers 5.9.0, torch 2.12): test_fp8_dequant_patch, test_ep_loader, test_model_load_utils and test_ep_load_warmup at 54430ac (204 passed).

[shengliangxu]

/ok to test a73d523

[shengliangxu]

@kevalmorabia97 thanks for the re-review and the mutation checks. Your green run answers my tied-head question. This head, a73d523, only rebases onto #2742's docstring commit, so this PR's own diff is unchanged.

[shengliangxu]

/ok to test 09e3d73

[shengliangxu]

/ok to test c884757

[shengliangxu]

/ok to test 9c917ae

[shengliangxu]

/ok to test 7192e05

[juhi10071998]

Blocker (probable): the block-FP8 path is admitted on transformers 5.7, where none of this PR's fixes install.

load_and_prepare_ep only requires transformers 5.7 (require_transformers("5.7", ...), model_load_utils.py), and this PR adds "fp8" to _EP_SOURCE_FORMATS with no further version check. But FineGrainedFP8HfQuantizer.update_weight_conversions and Fp8Dequantize._dequantize_one first appear in transformers 5.8 (checked v5.7.0 vs v5.8.0: v5.7.0 has neither, v5.8.0 has both). On 5.7 the _dequantize_one override is bound but never called and the expert-converter fuse is skipped because the hook does not exist.

What 5.7 does instead: get_weight_conversions appends one generic ["weight$", "weight_scale_inv", ...] dequant converter after the model's own converters. rename_source_key stops at the first matching converter, and the expert converter's pattern (mlp.experts.*.gate_proj.weight) is searched without an end anchor, so it claims the expert weights first. The likely result is that routed experts are merged as raw fp8 and cast to bf16 with no scales applied, and their *_scale_inv keys are renamed to a target the model lacks and dropped.

Who hits it silently: a block-FP8 MoE whose dimensions are all multiples of 128 (e.g. a Qwen3-MoE FP8 checkpoint). DeepSeek-V3 fails loudly instead, since 5.7's inline dequant raises on (576, 7168).

Tests/GPU runs here cover 5.5, 5.9 and 5.18 only; the author's replies name 5.8-5.10.0 as the releases the fuse installs on, and 5.7 has not been discussed. I traced this from the transformers sources and did not run it, so confidence is medium.

Suggested fix: require transformers >= 5.8 for quant_method == "fp8" inside the checks guard, or add a 5.7 test showing it loads correctly.

[shengliangxu]

/ok to test 7c83230

[shengliangxu]

/claude review

[shengliangxu]

@juhi10071998 thanks, confirmed and fixed in 7c83230. transformers 5.7.0 has neither Fp8Dequantize._dequantize_one nor FineGrainedFP8HfQuantizer.update_weight_conversions; 5.8.0 has both. On 5.7, this PR's override is never called and its fuse doesn't install, as you traced.

The expert-parallel load now refuses a block-fp8 checkpoint below transformers 5.8, inside the load's checks guard, so every rank refuses it before anything loads. test_a_block_fp8_checkpoint_needs_the_transformers_that_dequantizes_its_experts presents 5.7.0 and fails without the check. Unquantized checkpoints keep the 5.7 floor.

[claude]

[SUGGESTION] raw.get(...) is evaluated eagerly to build the tuple, so a config.json whose top-level JSON is not an object escapes the guard below it. json.load accepts [], "x" or 3 as valid JSON, and the isinstance(c, dict) check on the next line only protects the inner levels — the two raw.get calls run first and raise AttributeError: 'list' object has no attribute 'get'.

Why it matters: the function is deliberately defensive (except (OSError, ValueError) → None) precisely so an unreadable or malformed config.json degrades to the "fp8-unverified" refusal with its actionable message. A top-level non-object skips that and surfaces a bare AttributeError from inside _ckpt_quant_method, on the path that now runs for every expert-parallel load that reads an FP8 config object — the one place the user has no hint what went wrong. Low likelihood, but the fix is one line and keeps all malformed-config cases on the same route.

Suggested change

	for c in (raw, raw.get("text_config"), raw.get("llm_config")):
	if not isinstance(raw, dict):
	return None
	for c in (raw, raw.get("text_config"), raw.get("llm_config")):

[shengliangxu]

Taken in 5000023: _config_json_quantization now returns None for a config.json whose top level isn't a JSON object, so an FP8 config object meets the same fp8-unverified refusal as with an unreadable file. test_an_fp8_config_object_is_read_against_the_checkpoints_own_config gained a config-json-not-an-object row ([]), which fails without the check with the AttributeError you describe.

[claude]

Claude review — block-FP8 dequant on the expert-parallel load

Scope: full review (the trigger comment carried no scoping instructions). All 3 changed files reviewed against shengliangx/hfep-6b-ep-dense-sharding: modelopt/torch/utils/plugins/model_load_utils.py (+339/-8), tests/unit/torch/utils/test_model_load_utils.py (+413/-16), tests/unit/torch/utils/test_ep_loader.py (+81/-21). For composition I also read the _refused_together helper (:509), the sharded load's own quantized-checkpoint refusal (:586) that the new elif block_fp8 comment leans on, the dtype resolution at :2566, and the _decide_distribution call site at :1746.

Findings: CRITICAL: 0, IMPORTANT: 0, SUGGESTION: 1

What changed since the last approved round

The source diff is the previously reviewed arithmetic plus four deltas, all of which I re-derived:

• The FP8 refusals moved inside [OMNIML-6060] [2/3] Load an MoE expert-parallel: shard the experts at load time #3136's _refused_together("the expert-parallel load's checks", alone=False) guard. Verified this is right rather than merely compiling: all four refusals (require_transformers("5.8"), the fsdp-dense refusal, fp8-per-tensor, fp8-unverified) are version/config/plan-derived, so they are already rank-identical; wrapping them only removes the window where a rank that read a different config refuses alone. The guard re-raises via dist.all_reduce(label, refuse, combine=...), which every rank reaches, so no rank is left in a collective. quant_method is read inside the with and used at :2628 outside it — same function scope, no with-scoping trap.
• require_transformers("5.8", ...) for block FP8 sits after the unconditional "5.7" floor and before every other FP8 check, so a 5.7 run gets the specific message rather than the generic format refusal. Consistent with the pre-5.10.1 branch's assumption that vars(Fp8Dequantize)["_dequantize_one"] exists at the gate.
• print_rank_0 replaces the is_master() print. Issues no collective; print_rank_0/warn_rank_0 are already imported at :72.
• The non-fp8 passthrough (kevalmorabia97's round). quantized.dtype not in fp8_dtypes → stock(self, quantized, scales).to(out_dtype) is the correct shape for packed FP4: fp8_dtypes is built from float8_e4m3fn/e5m2/e4m3fnuz/e5m2fnuz only, so float4_e2m1fn_x2 and int8 both miss it, and the .to(out_dtype) keeps the model-dtype contract the override exists for. stock is None (5.5) raising rather than returning the half-width tensor is the right failure direction.

Verified fresh this round (no finding; recorded so it isn't re-derived)

• The in-place column scaling really is in place. q[..., : whole * block_n] is a stride-1-in-the-last-dim slice, so unflatten(-1, (whole, block_n)) is viewable (computeStride permits splitting a contiguous dim regardless of the outer strides) — mul_ writes through to q, not to a reshape copy. If that slice ever became non-viewable the mutation would silently land on a temporary and the whole-block columns would load unscaled, so it is worth having pinned: whole-blocks, partial-last-blocks and narrower-than-a-block (where whole == 0, i.e. unflatten(-1, (0, 4))) all go through this line and all compare against the blockwise reference.
• The partial-column tail broadcasts correctly in every reachable case. whole < scale_cols can only hold with scale_cols - whole == 1 when the grid is the configured block's ceil grid, and with an exact split whole == scale_cols and the branch is skipped — so s[..., whole:] is always a single column broadcasting over the remainder.
• The >= 5.10.1 bypass clause now gates on block alignment, not grid divisibility — the inverse of the rule that was the CRITICAL two rounds ago. (448, 7168) under a (4, 56) grid hits the pad path instead of stock's block_m = 112, and partial-dividing-the-grid ((192, 256) on (2, 2)) is the regression test for exactly that class.
• The pad path cannot be handed work it does not implement. quantized.view(torch.uint8) is legal on a non-contiguous fp8 tensor (same itemsize, no stride constraint), F.pad fills bit-zero = fp8 0.0 so the padded tail dequantizes to zeros and is cropped off, and scales passes through untouched so upstream's E8M0 decode is unaffected. FP4 and non-2-D inputs are excluded before the geometry is read.
• _DequantThenMerge is idempotent under a second update_weight_conversions. The second call prepends a fresh Fp8Dequantize, and because the fused op is a MergeModulelist the ops[0]/ops[1] match fires again and collapses it — the new outer dequant does the work and the inner one is dropped, so operations[0] can never be left an Fp8Dequantize. That is the failure mode the whole patch exists to prevent.
• The dense-layout rule and its two enforcement points agree. block_fp8 is computed after ep_size is resolved from "auto" (:1588 precedes :1601), so it is never compared against the string; "fp8-per-tensor" / "fp8-unverified" deliberately miss it and are caught by the load's own refusals; and the elif block_fp8 branch's comment ("the FSDP2 load refuses a quantized checkpoint itself") checks out against :586, which refuses any quantization_config on the sharded route — so the ep_size=1 hole the comment waves at is genuinely closed elsewhere.
• No new rank divergence. _patch_finegrained_fp8_dequant runs unconditionally on every rank for quant_method == "fp8" and can only raise on import/attribute conditions that are identical across ranks; _config_json_quantization reads a file every rank can read (or that every rank fails to read the same way), and in resolve_distribution_plan it runs under dist.broadcast_from, so only the deciding rank touches it at all.

Suggestion (non-blocking, 1 inline)

• _config_json_quantization builds its level tuple with eager raw.get(...) calls, so a config.json whose top-level JSON is valid but not an object raises AttributeError past the except (OSError, ValueError) that is there to route every unreadable config to the "fp8-unverified" refusal. One-line isinstance(raw, dict) guard.

What reads well

• _blk refusing to guess rather than deriving a block from divisibility, with the two misleading cases (576 % 5, 9 % 3) written into the comment and into the parametrization (grid-divides-the-rows) — a divide-the-shape rule passes that row, which is why it is the one that pins the fix.
• Rebinding Fp8Dequantize._dequantize_one only after the converter fuse is in, so a refused patch leaves transformers byte-identical — and test_an_expert_converter_it_cannot_fuse_stops_the_load asserting that over the full _PATCH_TARGETS tuple rather than one attribute.
• The three FP8 refusals each naming the specific missing thing (weight_block_size, a readable config.json, MODELOPT_FSDP_SIZE=1) instead of a generic "cannot dequantize fp8", and landing ahead of ensure_local_checkpoint so a refused load downloads nothing.
• The replicated-dense-part test asserting the absence of MODELOPT_EP_DEGREE and the presence of unquantized copy as functions of the parametrization, so the block-FP8 and export-layout remedies cannot drift into each other.
• test_the_dequantize_config_keeps_the_checkpoints_block_size pinning the merge_quantization_configs behaviour the entire block-size story depends on — an upstream change there would otherwise show up as silently mis-scaled weights, not a failing test.

Risk

Low. Additive and reached only on the expert-parallel load of a block-FP8 checkpoint; every path that could load wrong weights silently (empty grid, unplaceable grid, non-fp8 dtype, per-tensor scales, an unfusable expert converter) raises instead, and each is pinned by a test the author reports fails without the fix. The remaining item is a robustness one-liner on a malformed-config path.

🤖 Generated with Claude Code

[claude]

Claude review passed — no blocking issues found. LGTM

[shengliangxu]

/ok to test 5000023

[shengliangxu]

/ok to test 80cabec

[shengliangxu]

/ok to test 76e0338

[shengliangxu]

/ok to test 7540a2e

[shengliangxu]

/ok to test b1cec70

[shengliangxu]

/ok to test 6f5391d

[shengliangxu]

/ok to test 8787a4d

[shengliangxu]

/ok to test c032300

[shengliangxu]

/ok to test 939bf6e