Skip to content

[Kernels] Add swiglu and geglu MLP across models - #48335

Open
vasqu wants to merge 9 commits into
huggingface:mainfrom
vasqu:kernels-swi-geglu
Open

[Kernels] Add swiglu and geglu MLP across models#48335
vasqu wants to merge 9 commits into
huggingface:mainfrom
vasqu:kernels-swi-geglu

Conversation

@vasqu

@vasqu vasqu commented Aug 26, 2026

Copy link
Copy Markdown
Collaborator

CPU CI GPU run-slow

As per title, adds the tiled mlp kernels for swiglu / geglu across the models cc @kashif @qgallouedec

Quoting Quenting on the effects:

On Qwen3-8B's MLP shape at 131k tokens, forward+backward peak goes 22.56 GB to 7.97 GB, gradient error 3.5e-03 and flat across sequence lengths.

NOTE:

  1. There is the potential to pass this to vision backbones as well
  2. Dependent on kernels: support conditions on use_kernel_forward_from_hub kernels#796 for proper guarding the kernelization

@HuggingFaceDocBuilderDev

Copy link
Copy Markdown

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@kashif

kashif commented Aug 26, 2026

Copy link
Copy Markdown
Contributor

On NOTE 2 — there's no guard today, and the failure mode is silent rather than loud. The hub layers hardcode the activation (LigerSiLUMulFunction for SwiGLUMLP, GELU for GeGLUMLP) and never look at the config. And since kernelize only swaps forward, Liger's own __init__ validation can't run, so there's nowhere for the check to live right now — it'd have to move into forward or into kernelize().

Three concrete ones on this branch:

  • InklingMLP is decorated GeGLUMLP, but InklingTextConfig.hidden_act = "silu". Its forward also ends with * self.global_scale — the hub layer drops that, so a learned parameter silently disappears.
  • T5GemmaMLP and T5Gemma2MLP are GeGLUMLP and have self.dropout(...) between the gate/up product and down_proj. The hub layer has no dropout, so training quietly loses that regularization. (Activation is fine for both — they use gelu_pytorch_tanh.)

Might be worth a generic check that each decorated forward actually matches the canonical down_proj(act(gate(x)) * up(x)) shape, since anything extra just gets dropped.

Separately, a heads-up on the training path: it maps to LigerTiledSwiGLUMLP, which accumulated each weight once per shard and broke DDP with Expected to mark a variable ready only once (huggingface/kernels-community#1081). That's fixed in huggingface/kernels-community#1083, which is merged and rebuilt, so the v3 branch this PR pins has it and you're fine as-is. Worth knowing the kernel repo's main branch is still the pre-fix build though, so anyone pinning revision="main" rather than version=3 will still hit it.

@vasqu

vasqu commented Aug 26, 2026

Copy link
Copy Markdown
Collaborator Author

Yes, exactly why I want to have a kernels native condition/guard option before merging this. WIP

Inkling is a real regression, but also fine to drop t5gemmas - inkling at least could be refactored to be able to use the swiglu. Edit: fixed inkling and t5gemma (no inheritance)

If someone pins a wrong version then that's on them tbh and kernels also throws warnings if the not latest version is selected

@github-actions

Copy link
Copy Markdown
Contributor

[For maintainers] Suggested jobs to run (before merge)

run-slow: afmoe, aimv2, aria, axk1, axk2, bamba, bitnet, cohere, cohere2, cohere2_moe, cohere_compass, csm, cwm, deepseek_ocr2, deepseek_v2, deepseek_v3

@github-actions

Copy link
Copy Markdown
Contributor

CI recap

Dashboard: View test results in Grafana
Latest run: 33430805346:1
Result: success | Jobs: 16 | Tests: 184,774 | Failures: 0 | Duration: 16h 14m

kashif added a commit to kashif/Liger-Kernel that referenced this pull request Sep 3, 2026
…nel dispatch

transformers is adding @use_kernel_forward_from_hub(..., condition=...) to LlamaMLP
and the Gemma-family GEGLU MLPs (huggingface/transformers#48335), backed by a
kernels-community layer that itself maps to LigerTiledSwiGLUMLP/LigerSiLUMulFunction.
kernels.kernelize() walks modules by class and unconditionally rebinds `forward` on
every instance of a class carrying `kernel_layer_name` -- including one already
instance-patched by apply_liger_tiled_mlp -- even when no kernel mapping is
registered, silently falling back to the class's own forward. It records no marker
of having done so, so the only way to avoid the race is calling order: kernelize()
must run before apply_liger_tiled_mlp on an already-built model, never after.

Warn at patch time when this applies, and add regression tests that reproduce the
silent revert (simulating the future LlamaMLP decoration against a plain
use_kernel_forward_from_hub call) and confirm the correct order sticks.
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.

3 participants