Skip to content

[RDY] feat: add basic MoE support - #55

Open
JulienBalianSonos wants to merge 42 commits into
mainfrom
feat/moe-ffn-export
Open

[RDY] feat: add basic MoE support#55
JulienBalianSonos wants to merge 42 commits into
mainfrom
feat/moe-ffn-export

Conversation

@JulienBalianSonos

@JulienBalianSonos JulienBalianSonos commented Mar 27, 2026

Copy link
Copy Markdown
Collaborator

Implementation of #16.
Compatible with the tract PR sonos/tract#2084 .
Waiting for more efficient 'tract' implementation of a kind of 'routed_matmul' that handle the combine (scatter-add weighted results) internally.

This PR is complete.
As of now we have in tract a good enough implementation, but still a bit suboptimal.
Hence PR is 'blocked' since no urgent "needs" identified.

@JulienBalianSonos JulienBalianSonos changed the title feat: add basic MoE support [WIP] feat: add basic MoE support Mar 27, 2026
@JulienBalianSonos JulienBalianSonos changed the title [WIP] feat: add basic MoE support [RDT] feat: add basic MoE support Apr 8, 2026
@JulienBalianSonos JulienBalianSonos changed the title [RDT] feat: add basic MoE support [RDY] feat: add basic MoE support Apr 8, 2026
@JulienBalianSonos
JulienBalianSonos force-pushed the feat/moe-ffn-export branch 5 times, most recently from ecfd12a to 933a04a Compare July 10, 2026 09:00
…was emitting [1,T,D] and breaking tract IO check)
…pert biases, interleaved gate-up, and clamped-swiglu activation
…ze_gates and reject the unsupported norm_topk_prob=False
…n top of tract_moe_ffn; add Mixtral + Qwen2 shared-expert end-to-end tests
…stale harness regen script (norm_topk_prob + seeded init + built-tract); guard shared-expert non-SiLU activation
…ffn; 0.23.0-0.23.3 already shipped without it), keep explicit-tract escape
…m_topk_prob=False) now exports instead of raising
…ng the Qwen fused-expert layout (input_linear/output_linear, router.layer)
…nemo[asr] 2.7.2 needs setuptools>=79 / py3.13 numba, absent on the torch index)
…a resolves (pre-installed numpy 2.5 forced backtrack to unbuildable numba 0.53.1)
The GPT-OSS handler only remapped the experts implementation; it never
overrode build_forward_inputs, so it inherited the default handler's
single 4D causal mask.

That silently loses the sliding window. GPT-OSS alternates
sliding_attention and full_attention layers, and
masking_utils._preprocess_mask_arguments returns any 4D mask as-is, so
both create_causal_mask and create_sliding_window_causal_mask hit that
early exit. The model's mask mapping ends up holding the same unwindowed
tensor under both keys and every layer attends over the whole context.

The failure is invisible below the window, where the two masks agree,
and grows as the sequence extends past it, so short smoke tests do not
catch it. On gpt-oss-20b (window 128, 12 of 24 layers sliding) output
stays correct for roughly the first 128 positions, then decays into
repeated fragments; a prompt longer than the window is degenerate from
the first generated token.

Build both masks from token positions and pass them as the
{full_attention, sliding_attention} mapping the model accepts directly.
Masks use float arithmetic rather than boolean ops, for the same tracing
reason noted in gemma3_vl.

Models with no sliding layers keep the base handler's single mask.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant