Skip to content

Feature Request: Support for Microsoft's Phi-4-mini-flash-reasoning and Nvidia's Nemotron-nano-9b-v2 #16450

Closed

Description

@felipedilho

Prerequisites

  • I am running the latest code. Mention the version if possible as well.
  • I carefully followed the README.md.
  • I searched using keywords relevant to my issue to make sure that I am creating a new issue that is not already open (or closed).
  • I reviewed the Discussions, and have a new and useful enhancement to share.

Feature Description

The addition of Microsoft's Phi-4-mini-flash-reasoning, which is a hybrid Transformer/Mamba model in the SambaY architecture, using a combination of sliding window attention (SWA) with Mamba1 and gated memory units (GMU), which allow for arbitrary-length text exchanges where the sliding window attention limits reference to more recent tokens. I would request also the addition of Nvidia's Nemotron-nano-9b-v2, which is also a hybrid Transformer/Mamba model that uses a more usual attention with Mamba2 layers (which makes it particularly similar to IBM's Granite 4.0 models, which also use these same types of layers). Nemotron-nano-9b-v2 has been a very good small (under 10B) coding model with fast inference, which is unusual nowadays. I am very inclined to try to add support for these myself, but I am unfamiliar with the Llama.cpp codebase and would certainly accept pointers to where and what I should focus my efforts from people more experienced with the codebase.

Motivation

With the incorporation of support for hybrid models into Llama.cpp with IBM's Granite 4.0 models, the addition of other hybrid models can now be built over the codebase already implemented for Granite. The addition of other hybrid models would allow for better comparisons of different hybrid strategies under the same inference engine, allowing for a comparison of "apples to apples", so to speak, with relation to the amount of resource usage to model performance. Also, it is very interesting that in Microsoft's team paper for Phi-4-mini-flash-reasoning (https://arxiv.org/abs/2507.06607) they found that the Mamba1 layer was better than a Mamba2 layer for the SambaY architecture, which is intriguing since other hybrid models seem to just adopt Mamba2 as the mamba layer (possibly thinking that Mamba2 is necessarily better in every respect to Mamba1). The possibility of democratizing both these models with Llama.cpp support could instigate more people to investigate these questions of when Mamba2 is better than Mamba1 and vice versa. These models have been produced with several additional package requirements that are finnicky to get all working, so a streamlined implementation would allow more people to test these small LLM models.

Possible Implementation

For Nvidia's Nemotron-nano-9b-v2, a good amount of the code implemented for IBM's Granite 4.0 models could be reused since both are Transformer/Mamba2 hybrid models, which could make the implementation be more straightforward and worthwhile. Microsoft's Phi-4-mini-flash-reasoning could be a little more demanding since it uses Mamba1, which I don't think is currently explicitly supported by Llama.cpp, though the fact that Mamba2 now is certainly diminishes the workload for implementing Mamba1 support, and gated memory units (GMU) have not yet been implemented in Llama.cpp. Although sliding window attention (SWA) has been implemented for the Gemma-3 models that use this attention variant.

Activity

  1. pwilkin commented on Oct 7, 2025

    @pwilkin
    Member

    Nemotron is already supported.

  2. ghac101 commented on Oct 9, 2025

    @ghac101

    Nemotron is already supported.

    I am trying to find GGUF for this but was not successful. Can you help with this please? Thanks!

  3. pwilkin commented on Oct 9, 2025

    @pwilkin
    Member

    Nemotron is already supported.

    I am trying to find GGUF for this but was not successful. Can you help with this please? Thanks!

    https://huggingface.co/bartowski/nvidia_NVIDIA-Nemotron-Nano-12B-v2-GGUF
    https://huggingface.co/bartowski/nvidia_NVIDIA-Nemotron-Nano-9B-v2-GGUF

  4. github-actions commented on Nov 23, 2025

    @github-actions
    Contributor

    This issue was closed because it has been inactive for 14 days since being marked as stale.

  5. weblearner21-code commented on Apr 3, 2026

    @weblearner21-code

    CPU Inference Rewrite Available (PyTorch, partial)

    While waiting for native llama.cpp support, I've created a pure PyTorch CPU rewrite of Phi-4-mini-flash-reasoning that replaces all CUDA dependencies:

    Repo: https://github.com/weblearner21-code/phi4-flash-cpu-rewrite

    What's replaced:

    • flash_attn_func/varlen_func → F.scaled_dot_product_attention (with GQA + explicit causal mask)
    • selective_scan_cuda → Pure PyTorch scan loop (float64 accumulation)
    • causal_conv1d_cuda → Model's built-in CPU fallback
    • SwiGLU CUDA jiterator → x * sigmoid(x) * y
    • MambaInnerFn fused path → Disabled, uses unfused fallback

    Status:

    • Model loads and runs on CPU (tested on Intel Xeon Skylake 2.29GHz, 16 cores)
    • Simple prompts produce correct answers (e.g., "2+2" → "4", <think> reasoning activates)
    • ~1.7-2.0 tok/s on 16-core Xeon at float32
    • Complex prompts produce degraded output — the model is sensitive to precision differences between flash_attn and SDPA across 32 layers

    Key finding:

    The SambaY differential attention (attn1 - lambda * attn2) amplifies small numerical differences between fused CUDA kernels and non-fused PyTorch ops. The SDPA math itself is verified correct to float epsilon — the issue is that model weights were optimized with flash_attn's specific numerical behavior.

    This reinforces that native llama.cpp/GGML support (with quantized kernels designed to preserve model behavior) is the right path for production CPU inference. The hybrid Mamba+attention infrastructure from Granite 4 (PR #13550) provides most of the foundation needed — the remaining pieces are Mamba1, GMU, and SambaY model registration.

    The PyTorch rewrite may still be useful as a reference implementation for anyone working on the native support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions