Skip to content

fix(metal): GDN bfloat16, PA scheduler, error handling, MLX SDPA fixes#2047

Open
emanueleDiVizio wants to merge 9 commits into
EricLBuehler:masterfrom
emanueleDiVizio:fix/metal-fixes
Open

fix(metal): GDN bfloat16, PA scheduler, error handling, MLX SDPA fixes#2047
emanueleDiVizio wants to merge 9 commits into
EricLBuehler:masterfrom
emanueleDiVizio:fix/metal-fixes

Conversation

@emanueleDiVizio

@emanueleDiVizio emanueleDiVizio commented Apr 2, 2026

Copy link
Copy Markdown

Summary

This PR fixes multiple correctness, performance, and stability issues encountered while running mistral.rs on Apple Silicon (M-series) with real multi-user inference workloads (Qwen3.5 MoE + Mixtral).

The changes focus on:

  • Metal backend correctness (GDN + KV cache)
  • Scheduler behaviour under load (PagedAttention)
  • Robustness in concurrent serving scenarios
  • MLX integration improvements for attention kernels

Several of these issues only surface under concurrent decode or long-running sessions.

Key changes

Scheduler (from upstream PRs #2031/#2034)

  • Fix O(N²) thrashing in PagedAttention scheduler under mixed waiting/active workloads
  • Introduce FCFS priority ordering to prevent starvation

GDN / Metal

  • Fix dtype mismatch (bfloat vs bfloat16_t) in Metal kernels
  • Add per-sequence fallback for concurrent decode when recurrent offsets diverge

Stability

  • Replace panic on client disconnect with error handling
  • Return error instead of panic on block allocation failure (race condition)

Performance / Features

  • Increase Metal KV cache default max_seq_len (4K → 16K)
  • Add optional MLX SDPA backend with Metal flash attention (head_dim=256 support)

Test plan

  • Validated on Apple Silicon (M-series)
  • Tested with Qwen3.5 MoE (GDN) and Mixtral
  • Scheduler fixes verified under concurrent request load

ljchang added a commit to ljchang/mistral.rs that referenced this pull request May 25, 2026
The GDN (Gated Delta Net) kernels in mistralrs-core/src/metal/kernels/gdn.metal
instantiate templates with `bfloat16_t` — the ggml/llama.cpp convention
inherited from the CUDA port. Apple Metal's stdlib exposes the
IEEE bfloat16 type as `bfloat` (Metal 3.1+, macOS 14+), with `bfloat16`
also present as a forward-only struct (`__Reserved_Name__Do_not_use_bfloat16`)
in the extended_vector private header. Neither name is `bfloat16_t`.

The precompiled metallib path works because it's built against
build-time headers that may resolve `bfloat16_t` differently. But the
runtime-compiled path (used when MISTRALRS_METAL_PRECOMPILE=0, the only
working mode on Apple Silicon GPUs whose precompiled-metallib function
variants don't match the current device) bails with:

    error: unknown type name 'bfloat16_t'; did you mean 'bfloat16'?
    instantiate_conv1d_update(bfloat16_t);

This blocks Qwen 3.5 / 3.6 inference on Metal under precompile=0 since
those models hit the GDN path for their hybrid (FullAttention +
LinearAttention) layers — Gemma 4 and dense-only models are unaffected.

Fix: typedef `bfloat16_t` to the public `bfloat`. Aliasing to `bfloat16`
also resolves the original parse error but then explodes at template
instantiation with "incomplete type" errors because the extended_vector
declaration is forward-only.

Tested end-to-end with `Qwen/Qwen3.6-27B` + AFQ4 ISQ on Apple Silicon /
macOS 26 — GDN kernels compile cleanly and inference produces tokens.

Note: this fix overlaps with PR EricLBuehler#2047 (fix/metal: GDN bfloat16, PA
scheduler, error handling, MLX SDPA fixes) which has been open since
2026-04-02 and contains the same typedef plus several unrelated
improvements. Either this fix or that PR (whichever lands first) closes
the precompile=0 GDN gap; happy to drop this commit if EricLBuehler#2047 is
prioritized.
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