Major Unsloth Update: NVFP4 Quantization Export and DeepSeek-V4 Training Support

Unsloth v0.1.48-beta adds NVFP4 quantization export, API hot-swapping, and major MoE/GRPO training speedups.
Unsloth's v0.1.48-beta brings NVFP4/FP8 quantization export, OpenAI-compatible model hot-swapping APIs, 3-5x faster MoE training, and 1.3x faster GRPO. The update integrates efficient fine-tuning, flexible quantization, and local inference serving into a complete pipeline, ideal for developers working with DeepSeek-V4 and other next-gen models on limited hardware.
Background on the Unsloth Framework
Unsloth is an open-source framework for efficient fine-tuning of large language models, developed by brothers Daniel Han and Michael Han. Its core innovation lies in using hand-written Triton kernels and computation graph optimization to boost fine-tuning speed by 2-5x and reduce memory usage by 50-80%, all without sacrificing accuracy.
This performance advantage stems from deep customization of low-level computation: Triton is an open-source GPU programming language and compiler framework released by OpenAI in 2021, filling the gap between CUDA (professional but complex) and high-level frameworks (easy to use but inefficient). Traditional CUDA programming requires developers to manually manage low-level details such as shared memory, thread block layout, and memory alignment, resulting in an extremely steep learning curve. While the automatic operators in frameworks like PyTorch are easy to use, their generality means they cannot perform deep optimizations tailored to specific model architectures. Triton uses Python syntax as its interface, with the compiler automatically handling memory access pattern optimization and thread scheduling, allowing researchers to write GPU kernels approaching peak performance at relatively low cost. Through hand-written Triton kernels, Unsloth performs deep fusion of hotspot operations in LLM training (such as FlashAttention, RMSNorm, and SwiGLU activation) to reduce the number of memory read/write operations. In LLM training scenarios, the Triton implementations of these operations can reduce memory bandwidth consumption by over 50% compared to PyTorch's native operators. Computation graph optimization further reduces kernel launch overhead by eliminating redundant operators and merging small ones. The combination of these two techniques enables Unsloth to achieve efficiency close to professional training frameworks on consumer-grade GPUs.
Fully compatible with the Hugging Face PEFT/TRL ecosystem—the PEFT library standardizes LoRA and its variants, while the TRL library provides infrastructure for alignment training such as RLHF; together they form the foundation of the open-source community's fine-tuning ecosystem, on top of which Unsloth builds a more efficient execution layer—Unsloth is favored by resource-constrained researchers and developers. The recently released v0.1.48-beta version (corresponding to unsloth>=2026.7.1) brings a series of major updates. The most notable is that Unsloth Studio now supports exporting to multiple quantization formats such as NVFP4, FP8, and imatrix GGUF after training, while also being able to run as a llama-swap-style API service system. This series of improvements marks Unsloth's evolution from a purely efficient fine-tuning tool into a one-stop local LLM platform covering the full pipeline of training, export, and inference serving.

NVFP4: A Quantization Format for the Next Generation of Hardware
The core highlight of this update is support for NVFP4 quantization export. NVFP4 is a 4-bit floating-point quantization format designed by NVIDIA for the Blackwell architecture (B100/B200/RTX 50 series). It uses E2M1 encoding (1 sign bit, 2 exponent bits, 1 mantissa bit), with a representable numerical range of approximately ±6.0.
The NVIDIA Blackwell architecture (released in 2024) is the next-generation data center GPU architecture following Hopper (H100), deeply optimized for AI inference and training workloads. Blackwell's fifth-generation NVLink, HBM3e memory, and dedicated FP4 tensor cores enable a 2-4x throughput improvement over the H100 in inference-intensive scenarios. Its consumer-grade counterparts, the RTX 5090/5080 series (GeForce 50 series), also feature native hardware support for FP4 operations. Before Blackwell, while INT4 quantization could reduce model size, it required dequantizing weights back to high-precision formats before inference, and this extra dequantization step offset some of the bandwidth savings from reduced storage. Blackwell's FP4 tensor cores can perform matrix multiplication directly at FP4 precision, truly achieving the dual benefits of "small storage, fast computation," which is the hardware foundation for deploying the NVFP4 format.
Understanding E2M1 encoding requires a bit of floating-point format background: the 2 exponent bits allow representing 4 different orders of magnitude, while the 1 mantissa bit distinguishes two precision levels within each order of magnitude. By comparison, FP16 uses E5M10, and common FP8 formats use E4M3 or E5M2. E2M1 is far inferior to higher-bit formats in terms of absolute precision, but its non-uniform quantization characteristics (allocating more representation space to small values) make it superior to same-bit-width INT4 integer formats in neural network weight quantization scenarios. Compared to traditional INT4 quantization, FP4 can preserve better numerical dynamic range at extremely low bit counts, effectively reducing precision loss while compressing model size (saving 75% storage relative to FP16) and reducing memory usage.
Traditional INT4 quantization uses pure integer encoding with a completely fixed dynamic range, making it prone to larger quantization errors for network layers with uneven weight distributions. FP4, on the other hand, uses floating-point encoding, which can adaptively represent values of different magnitudes even at extremely low bit counts. Combined with a grouped quantization strategy where every group of 16 or 32 weights shares a single FP8 scaling factor, it theoretically better fits the symmetric bell-shaped distribution characteristics of neural network weights. NVIDIA specifically designed the FP8 scaling factor mechanism for this: each group of 16-32 FP4 weights shares a high-precision scaling value to compensate for the limited representation range, keeping overall quantization precision loss within an acceptable range. The NVIDIA Blackwell architecture natively supports FP4 tensor operations at the hardware circuit level, meaning that models are not only smaller in size but can also achieve hardware-level computational acceleration during inference, rather than relying solely on software emulation.
For developers looking to deploy large models on consumer-grade or data center GPUs, this means they can compress fine-tuned models to extremely small sizes while enjoying Blackwell hardware's native acceleration for FP4 computation. It's worth noting that this update also specifically fixes the logic for selecting llama.cpp prebuilt packages on data center Blackwell (sm_100 / sm_103) GPUs, ensuring that new hardware correctly matches the corresponding runtime environment.
A More Flexible Quantization Export Pipeline
Beyond NVFP4, the overall export functionality has also become more flexible and powerful. It's worth noting that GGUF (GPT-Generated Unified Format) is a model storage format introduced by the llama.cpp project in 2023. It supports packaging quantized weights, model metadata, and tokenizer vocabularies into a single file, and supports various quantization variants such as Q4_K_M and Q8_0. imatrix (importance matrix) quantization is an advanced method within this, which precomputes an importance score for each weight's contribution to the model output and allocates higher precision to important weights during quantization. Compared to naive uniform quantization, it can preserve better model quality at the same compression ratio, making it especially suitable for precision-sensitive task scenarios. Improvements to the export functionality in this update include:
- Support for selecting multiple export formats at once
- New portable FP8/INT8 export, GGUF LoRA, and source-matched export
save_pretrained_mergednow supports compressed FP8/FP4 export- Avoids re-downloading the base model when exporting multiple checkpoints
- FP8, INT8, and GGUF-LoRA export now correctly respect the
trust_remote_codesetting
These improvements directly address pain points in previous fine-tuning workflows such as repeated downloads, format limitations, and wasted memory, making the path from training to deployment much smoother.
A Smarter OpenAI-Compatible Local API Service
Another major highlight of this update is turning Unsloth Studio into a reliable local inference service backend, with a design philosophy borrowed from the llama-swap project. Created by developer mostlygeek, llama-swap is a lightweight solution in the field of local LLM service orchestration and represents an important design paradigm: in local development scenarios, developers often need to frequently switch between models of different scales or specializations. Traditional approaches require manually stopping the old service, modifying the configuration, and starting the new service—an extremely tedious process. llama-swap introduces a model-name routing mechanism at the OpenAI-compatible API layer, completely hiding the lifecycle management of the underlying llama.cpp processes—a single process virtualizes multi-model access at the API level, starting/stopping underlying llama.cpp instances on demand. To address the constraint of limited memory on a single machine, its key design is: only one model instance runs at a time, and when switching, the old model is unloaded before the new one is loaded, trading latency for memory savings. Users don't need to maintain multiple service ports; they simply specify different model names in the request's model field, and the proxy layer automatically handles the loading and unloading lifecycle of the models. This design pattern aligns with the philosophy of cloud-based model routing gateways (such as LiteLLM) but optimizes resource scheduling strategies specifically for local single-machine scenarios. On this foundation, Unsloth Studio adds more security mechanisms, making it better suited to the practical use cases of local developers.
API requests can optionally enable automatic model switching—when a request points to another downloaded local GGUF model, the system automatically loads and serves it. This switching path is safe by default: unknown model names will continue using the current model rather than triggering unexpected downloads, avoiding large file downloads caused by misoperation.
Additionally, the /v1/models endpoint now returns concise model IDs and local GGUF directories, no longer exposing local .gguf file paths. The idle auto-unloading feature can free memory after a period of inactivity and reload the previous model on the next request. For agent scenarios, clients can also control tool-call "healing" behavior on a per-request basis—when a model attempts to call a tool but returns malformed markers, the system can perform additional retries.
Enhanced RAG and File Chat Capabilities
For document processing scenarios, Unsloth has also made significant optimizations. RAG (Retrieval-Augmented Generation) is the most mainstream document Q&A technical approach in enterprise-grade AI applications: its basic principle is to vectorize documents and store them in a vector database, then when a user asks a question, first retrieve the most relevant fragments and feed them along with the question into the large language model to generate an answer. Early Naive RAG relied on fixed-size chunking (typically 512-1024 tokens) and cosine similarity retrieval, performing poorly in cross-paragraph reasoning scenarios.
Unsloth's improvement to RAG attachments now supports using entire documents as context, which essentially represents a preferential choice between two mainstream document Q&A paradigms. The advantage of traditional chunked RAG lies in its scalability—even with a document library reaching terabyte scale, relevant fragments can be quickly located through vector retrieval, but the "recall ceiling" problem always exists: chunk boundary truncation and semantically similar but topically irrelevant noise fragments both degrade answer quality. The long-context approach stuffs the entire document into the context window, completely avoiding the recall problem, at the cost of a moderate increase in memory and latency during inference. The emergence of models supporting ultra-long context, such as Gemini 1.5 Pro, has made this approach practical for small-to-medium documents (<500 pages), and Unsloth's move aligns with this technological trend. For complex document Q&A scenarios requiring cross-paragraph reasoning, this approach often yields more coherent answers with better global understanding.
The file chat feature's ability to parse real documents has been greatly enhanced: it can correctly read more PDF and Word documents, including right-to-left text (such as Arabic), Indic-script text, and DOCX tables.
Embedding models can now also be customized; users can select an appropriate embedding model through Hugging Face search, and the relevant settings page has been reorganized. These improvements significantly enhance Unsloth's usability in enterprise-grade document Q&A scenarios.
Comprehensive Improvements in Training Performance and Stability
In terms of core training capabilities, this update also delivers substantial gains:
- GRPO training is 1.3x faster, and sequence packing is now enabled by default for computing old/reference log probabilities
- MoE training is 3 to 5x faster; LoRA detection for mixture-of-experts models now correctly locates expert MLP layers, and grouped MoE can be automatically enabled for loaded and PEFT models
- HTTP fallback mechanism provided when downloads stall, with better offline mode performance
- Full fine-tuning now uses correct precision on GPUs that don't support bf16, such as the V100
- Fixed an issue where DDP training crashed due to CPU-resident RoPE buffers
- FP8 quantization handles odd tensor shapes and scale formats more reliably
Each of these optimizations involves important technical background. GRPO (Group Relative Policy Optimization) was formally proposed by the DeepSeek team in the DeepSeekMath paper (2024) and is an important simplified variant of the PPO algorithm in the LLM alignment field. Standard PPO requires additionally training a value network (Critic) with a parameter count comparable to the policy network, which in large-model scenarios means double the memory overhead. The key insight of GRPO is: by sampling multiple responses to the same problem and computing relative rewards within the group to estimate the baseline, it eliminates the overhead of separately training a value network, significantly reducing memory usage. The successful training of DeepSeek-R1 validated GRPO's effectiveness in eliciting reasoning capabilities, quickly making it one of the community's most closely watched RLHF alternatives.
Sequence Packing addresses the long-standing "padding waste" problem in NLP training. Large language model training typically processes data in fixed-length batches. For samples of varying lengths, the traditional approach is to pad short sequences with padding tokens up to the batch's maximum length—when a dataset's sample lengths vary greatly, padding computation can consume 30%-60% of GPU compute power, and this portion of computation contributes nothing to gradient updates. Sequence packing concatenates multiple short sequences end-to-end to fill a fixed window, using an attention mask (a block-diagonal matrix) to ensure that tokens from different sequences don't attend to each other, bringing GPU utilization close to 100%. In GRPO training, the multiple sampled responses to the same problem usually vary significantly in length, so the benefits of sequence packing are especially significant—which is why Unsloth set it as the default configuration for GRPO.
The MoE (Mixture of Experts) architecture is the mainstream approach to scaling large models today. Top-tier models such as DeepSeek-V3/V4 and Mixtral all adopt this design: each token dynamically selects a few "expert" sub-networks for computation through a routing mechanism, keeping the actually activated FLOPs within an acceptable range while maintaining an enormous parameter count. MoE models face unique engineering challenges during the fine-tuning phase: the sparse activation characteristics of expert layers often cause naive LoRA implementations to fail to correctly identify and inject into expert MLP layers. In a standard Transformer, each layer has a unique MLP module, whereas an MoE layer contains N parallel expert sub-networks (DeepSeek-V3 has 256 experts), with only a few activated per forward pass. Naive LoRA implementations inject adapters by matching module name prefixes, making them prone to mistaking all experts for the same module or completely skipping expert layers nested under the routing mechanism. A correct implementation requires recursively traversing the model architecture, identifying independent linear layers with naming patterns like experts.{i}.{w1,w2,w3}, and injecting a separate pair of LoRA matrices for each expert to preserve each expert's specialized characteristics. Unsloth's fix this time ensures that LoRA adapters are precisely injected into each independent expert's weight matrix, which is highly significant for users looking to fine-tune models like DeepSeek.
DDP (Distributed Data Parallel) is PyTorch's most commonly used multi-GPU training strategy. RoPE (Rotary Position Embedding), proposed by Jianlin Su in 2021, is the position encoding scheme adopted by mainstream large language models today (LLaMA, Qwen, DeepSeek, etc.)—it encodes positional information by applying a rotation transformation to the Query and Key vectors, so that attention scores naturally incorporate relative positional relationships, outperforming traditional absolute position encoding in long-context extrapolation. RoPE's buffers (precomputed rotation matrices) need to maintain device consistency with model parameters in multi-GPU DDP training. If a buffer is left on the CPU, the device check during the gradient synchronization phase will trigger a runtime error and crash the training—this fix resolves this known issue affecting multi-GPU training stability.
These optimizations cover multiple cutting-edge training paradigms from reinforcement learning (GRPO) to mixture-of-experts architectures (MoE), reflecting Unsloth's continued keeping-up with the latest advances in large model training technology.
Cross-Platform Reliability and Localization Support
To make the tool run stably in more environments, the team invested significant effort in the installer and platform adaptation. macOS no longer depends on CMake or Homebrew when prebuilt llama.cpp is available; on Apple Silicon, it better handles paths containing spaces and reasonably sets the GGUF context size based on unified memory; installation in enterprise TLS proxy environments is also smoother. ROCm-on-WSL now supports discrete Radeon RDNA 3/4 GPUs, not just the Strix Halo platform.
At the user experience level, the interface now supports Japanese and Brazilian Portuguese, training and chat progress are less prone to "silently freezing," and Hub browsing recovers better when encountering invalid Hugging Face tokens.
Summary
From NVFP4/FP8 compressed quantization export, to OpenAI-compatible model hot-swapping APIs, to multi-fold speedups in MoE training, this version of Unsloth demonstrates a clear product direction: integrating efficient fine-tuning, flexible quantization, and local inference serving into a complete closed loop. For developers focused on next-generation models like DeepSeek-V4 who want to complete the entire "fine-tune—quantize—deploy" workflow on limited hardware, this update is well worth close attention.
Updating is very simple—macOS/Linux/WSL users run curl -fsSL https://unsloth.ai/install.sh | sh, and Windows users run irm https://unsloth.ai/install.ps1 | iex to complete the upgrade.
Key Takeaways
Related articles

Should You Open Source Your Project? A Layered Open Source Strategy Using Project Replay as a Case Study
Should indie developers open source their projects? Using the game custom achievement tool Project Replay as a case study, this article analyzes the open source decision and offers a practical layered strategy.

130+ Open-Source Interactive Security Awareness Training: Reshaping Habit Formation Through 3D Office Scenarios
A project with 130+ free open-source interactive security awareness exercises using immersive 3D office scenarios to simulate phishing, vishing, MFA fatigue attacks and more, building employee security habits.

From Musk to Jefferson: Beware the Cognitive Trap of Cross-Domain Experts
Why do geniuses in one field often become overconfident in others? From Musk's controversial interview to Jefferson's blind spots, an exploration of cross-domain cognitive arrogance.