Latest Model Uploads (Gemma, MiniCPM, Nanbeige)
I started this website after I had already posted a first wave of models that we made NVFP4 versions for. I posted about them on Ko-Fi at the time, and here we wrote one post summarizing all of that. After that, we had some posts discussing feedback, evaluations, and recommended tiers per configuration.
While that was happening, we posted other model families. Three of them are up now.
Gemma-4-31B-IT-NVFP4-GGUF
https://huggingface.co/esatapedico/Gemma-4-31B-IT-NVFP4-GGUF
Five GGUFs of NVIDIA’s Gemma-4-31B-IT-NVFP4 (31B dense instruction model, 262K native context). It’s an NVFP4 family with a per-tier quality ladder for the embedding head and attention precision. Four tiers share a byte-identical 410-tensor native-NVFP4 backbone; HIGHEST keeps attention at Q8_0 for maximum task accuracy. Built for Blackwell sm_120.
The strengths here are that it’s built from NVIDIA’s official near-lossless NVFP4 checkpoint (not a third-party quant), it’s Apache-2.0 end-to-end (Gemma 4 left the Gemma Terms), it has 262K native context, it does text and vision, and it has a coding-adjacent profile (LiveCodeBench 82.27 at source precision). Measured MMLU across our tiers: 76.3 to 78.1% (HIGH leads), GSM8K 80 to 82%, roughly 28 t/s decode on our dual 16 GB setup.
I’d recommend it for long-context and agent-model work where you want a dense 31B with a clean license, plus a per-tier ladder for choosing between size, speed, and head precision.
Compared to Qwen3.8-27B: it’s a bigger dense model (31B vs 27B) with the same 262K context class, but no MTP head. So no built-in speculative decoding, and decode is far slower (about 28 t/s on our cards vs the roughly 200 tok/s Qwen3.8 LOW hits on a 5090). MMLU is also lower (76 to 78% vs 82.4%). Qwen3.8’s BUDGET and STARVED variants fit a single 16 GB card; Gemma’s tiers want dual 16 GB or offload.
MiniCPM-V-4.7-35B-A3B-NVFP4-GGUF
https://huggingface.co/esatapedico/MiniCPM-V-4.7-35B-A3B-NVFP4-GGUF
Six GGUFs of openbmb/MiniCPM-V-4.7-35B-A3B (35B MoE VLM, 256 experts per layer). Converted from our own NVFP4A16 self-converted checkpoint (experts and shared experts quantized at the source), with a per-tier attention/SSM promotion building a byte-identical 400-tensor native-NVFP4 backbone in every file. Needs mainline llama.cpp at or after 2026-10-10 (MiniCPM-V 4.7 support, PR #29416). Blackwell sm_120.
The strengths: it’s MoE with only about 3B active parameters, so decode is the fastest of the three (104 to 129 t/s on our dual 16 GB, roughly 7.4k t/s prefill). It’s a strong VLM with the mmproj included, thinking is on by default, MMLU is around 81 to 82% across all tiers, and there’s an optional DSpark speculative drafter (a small net win at a 5-token budget). Because so little is active, keeping experts on CPU is comparatively cheap.
I’d recommend it for fast multimodal chat and agentic use on dual 16 GB, and as the speed pick when you want vision without paying dense-model decode costs.
Compared to Qwen3.8-27B: it’s the opposite trade-off. Qwen3.8 is dense (all 27B active per token) with MTP built into the files, while MiniCPM is MoE with a separate DSpark drafter. MiniCPM decodes much faster; Qwen3.8 has the longer 262K native context, video support, and single-16GB BUDGET/STARVED tiers that MiniCPM cannot match (its tiers floor at about 18 GiB).
Nanbeige4.3-33B-NVFP4-GGUF
https://huggingface.co/esatapedico/Nanbeige4.3-33B-NVFP4-GGUF
MLP-only NVFP4A16 self-conversion of Nanbeige4.3-33B (dense 33B, 512K native context) into a 7-tier GGUF ladder (VERY-LOW to HIGHEST, 18.20 to 25.13 GB).
The strengths: it’s a dense 33B positioned at agentic coding and professional cowork work (vendor-reported: Terminal-Bench 2.1 at 80.9, DeepSWE at 65.5, AIME 2026 at 95.2), 512K native context, Apache-2.0, and it’s the only one of the three where HIGHEST measurably leads (72.5% MMLU, 93% GSM8K). Our MMLU/GSM8K harness shows strong reasoning (GSM8K 91 to 93%) with weaker factual recall (MMLU 67 to 73%), which is consistent with the MLP-only quantization.
I’d recommend it for agentic coding and tool-use in the 30B class, and as a teacher model (it was released as the teacher for a distillation line). It’s not a daily-driver speed pick.
Compared to Qwen3.8-27B: it attacks exactly the lane Qwen3.8 is judged on. The vendor’s own comparison beats Qwen3.8 on Terminal-Bench 2.1, DeepSWE, and Claw-Eval but loses SWE-Bench Pro (60.3 vs 61.7). It has no MTP head, so no speculative decoding, and all 33B are active per token. Decode is far below Qwen3.8-27B with MTP. Think quality and teacher, not the fast default.
I’ve been trying to bring models that are actually valuable, modern, and usable in 32GB VRAM or less, which is what I’m constrained to in my dual-GPU setup. I had a single 16GB VRAM setup for a long time though, so I feel you all in the same situation. When it’s feasible to push the limits of a model to fit 16GB VRAM with an NVFP4 backbone, I do my best to do it.
Expectations for the next weeks: as new models and fine-tunes that I consider worthwhile come through, I’ll make my NVFP4 families for them. If I don’t think they’re worth it, then I won’t. I can’t be aware of all models and fine-tunes though, so I’m always open for suggestions. Ping me in the Community tab of a similar model in HuggingFace or through my Telegram channel if that’s the case :).
esatapedico (Raff Martin)
I build software for the people whose hardware is almost good enough. Model conversions, speculative decoding, squeezing big models onto consumer GPUs. Everything I ship is free and Apache-2.0.