Instructions to use tngtech/Qwen3.6-27B-NVFP4-GGUF with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- llama.cpp
How to use tngtech/Qwen3.6-27B-NVFP4-GGUF with llama.cpp:
Install (macOS, Linux)
curl -LsSf https://llama.app/install.sh | sh # Start a local OpenAI-compatible server with a web UI: llama serve -hf tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4 # Run inference directly in the terminal: llama cli -hf tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4
Install from WinGet (Windows)
winget install llama.cpp # Start a local OpenAI-compatible server with a web UI: llama serve -hf tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4 # Run inference directly in the terminal: llama cli -hf tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4
Use pre-built binary
# Download pre-built binary from: # https://github.com/ggerganov/llama.cpp/releases # Start a local OpenAI-compatible server with a web UI: ./llama-server -hf tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4 # Run inference directly in the terminal: ./llama-cli -hf tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4
Build from source code
git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp cmake -B build cmake --build build -j --target llama-server llama-cli # Start a local OpenAI-compatible server with a web UI: ./build/bin/llama-server -hf tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4 # Run inference directly in the terminal: ./build/bin/llama-cli -hf tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4
Use Docker
docker model run hf.co/tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4
- LM Studio
- Jan
- vLLM
How to use tngtech/Qwen3.6-27B-NVFP4-GGUF with vLLM:
Install from pip and serve model
# Install vLLM from pip: pip install vllm # Start the vLLM server: vllm serve "tngtech/Qwen3.6-27B-NVFP4-GGUF" # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:8000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "tngtech/Qwen3.6-27B-NVFP4-GGUF", "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }'Use Docker
docker model run hf.co/tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4
- Ollama
How to use tngtech/Qwen3.6-27B-NVFP4-GGUF with Ollama:
ollama run hf.co/tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4
- Unsloth Studio
How to use tngtech/Qwen3.6-27B-NVFP4-GGUF with Unsloth Studio:
Install Unsloth Studio (macOS, Linux, WSL)
curl -fsSL https://unsloth.ai/install.sh | sh # Run unsloth studio unsloth studio -H 0.0.0.0 -p 8888 # Then open http://localhost:8888 in your browser # Search for tngtech/Qwen3.6-27B-NVFP4-GGUF to start chatting
Install Unsloth Studio (Windows)
irm https://unsloth.ai/install.ps1 | iex # Run unsloth studio unsloth studio -H 0.0.0.0 -p 8888 # Then open http://localhost:8888 in your browser # Search for tngtech/Qwen3.6-27B-NVFP4-GGUF to start chatting
Using HuggingFace Spaces for Unsloth
# No setup required # Open https://huggingface.co/spaces/unsloth/studio in your browser # Search for tngtech/Qwen3.6-27B-NVFP4-GGUF to start chatting
- Pi
How to use tngtech/Qwen3.6-27B-NVFP4-GGUF with Pi:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4
Configure the model in Pi
# Install Pi: npm install -g @mariozechner/pi-coding-agent # Add to ~/.pi/agent/models.json: { "providers": { "llama-cpp": { "baseUrl": "http://localhost:8080/v1", "api": "openai-completions", "apiKey": "none", "models": [ { "id": "tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4" } ] } } }Run Pi
# Start Pi in your project directory: pi
- OpenClaw new
How to use tngtech/Qwen3.6-27B-NVFP4-GGUF with OpenClaw:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4
Configure OpenClaw
# Install OpenClaw: npm install -g openclaw@latest # Register the local server and set it as the default model: openclaw onboard --non-interactive --mode local \ --auth-choice custom-api-key \ --custom-base-url http://127.0.0.1:8080/v1 \ --custom-model-id "tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4" \ --custom-provider-id llama-cpp \ --custom-compatibility openai \ --custom-text-input \ --accept-risk \ --skip-health
Run OpenClaw
openclaw agent --local --agent main --message "Hello from Hugging Face"
- Docker Model Runner
How to use tngtech/Qwen3.6-27B-NVFP4-GGUF with Docker Model Runner:
docker model run hf.co/tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4
- Lemonade
How to use tngtech/Qwen3.6-27B-NVFP4-GGUF with Lemonade:
Pull the model
# Download Lemonade from https://lemonade-server.ai/ lemonade pull tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4
Run and chat with the model
lemonade run user.Qwen3.6-27B-NVFP4-GGUF-NVFP4
List all available models
lemonade list
- Hermes Agent
How to use tngtech/Qwen3.6-27B-NVFP4-GGUF with Hermes Agent:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4
Configure Hermes
# Install Hermes: curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash hermes setup # Point Hermes at the local server: hermes config set model.provider custom hermes config set model.base_url http://127.0.0.1:8080/v1 hermes config set model.default tngtech/Qwen3.6-27B-NVFP4-GGUF:NVFP4
Run Hermes
hermes
- Atomic Chat
tngtech/Qwen3.6-27B-NVFP4-GGUF
An NVFP4 GGUF repackage of nvidia/Qwen3.6-27B-NVFP4 that runs on llama.cpp's native Blackwell (sm_120) FP4 tensor-core path. nvidia/Qwen3.6-27B-NVFP4 is itself derived from Alibaba's Qwen3.6-27B.
Qwen3.6-27B is one of the strongest models that fits a 24 GB consumer GPU, delivering Sonnet-4.5-class coding intelligence at that size. Its published quants are almost all standard GGUF (Q4_K_M etc.), which do not use the FP4 hardware on RTX 5090 / Blackwell cards.
This repackage keeps the model's original NVFP4 4-bit weights bit-exact and hands them to llama.cpp's FP4 tensor cores, so you get the speed of hardware FP4 plus MTP speculative decoding, while staying inside 24 GB with real room left for KV cache. There is no measurable quality loss versus the BF16 model on our benchmarks.
Highlights
- ~50 % faster decode than
Q4_K_M: 46.5 tok/s vs 31 tok/s on a 5090 laptop (24 GB), with MTP speculative decoding. - Quality on par with full precision: matches BF16 on terminal-bench 2.0 and MMLU-Pro (within noise) on our tng-benchmark subset runs.
- Native FP4 on Blackwell: MLP and
lm_headweights are repacked bit-exact from the source NVFP4 checkpoint (no re-rounding, no double quantization) and run onmma.syncFP4 tensor cores. - Fits 24 GB with headroom: 19.41 GB on disk leaves ~4.5 GB for KV cache + draft + compute buffers.
- Big usable context: 160K context comfortably on 24 GB (native 262K), thanks to the hybrid Gated-DeltaNet + attention architecture (only 16 of 64 layers keep a growing KV cache).
- MTP built in: the model's Multi-Token-Prediction head (
blk.64) is preserved, enablingdraft-mtpself-speculation for the throughput numbers above.
Model description
| Architecture | Qwen3_5ForConditionalGeneration (qwen3_5). Dense hybrid: Gated-DeltaNet linear attention + periodic full attention, with a Multi-Token-Prediction (MTP) head |
| Parameters | ~27B |
| Layers | 64 transformer + 1 MTP (blk.64); full_attention_interval = 4, so only 16 full-attention layers |
| Attention | GQA, 4 KV heads x head_dim 256 |
| Context | 262,144 native |
| Modality | Text only. The source is a vision-language model; the vision tower is not included in this GGUF |
How the weights are packed
| Component | Source dtype | In this GGUF | Notes |
|---|---|---|---|
MLP ffn_gate/up/down (all layers) and lm_head |
NVFP4 (E2M1 + FP8 block scales) | NVFP4 | bit-exact repack, ~4.25 bpw |
| Attention + GDN/SSM projections | FP8-E4M3 | Q8_0 | dequantized to 8-bit (lossless-or-better vs FP8) |
Token embedding (token_embd) |
BF16 | Q8_0 | --embd-as-q8, ~lossless (rel-RMSE 0.54 %) |
MTP layer (blk.64) |
BF16 | Q8_0 | --mtp-as-q8, draft-only; cannot affect final output |
| Norms, biases, FP4 global scales | F32 | F32 | tiny |
The NVFP4 path avoids the double-quantization penalty of the usual "dequantize to F16 then re-quantize to Q4_K_M" route: the 4-bit weights are copied through untouched.
Files
This repository ships a single file:
Qwen3.6-27B-NVFP4.gguf(19.41 GB): NVFP4 MLP andlm_head(bit-exact repack), Q8_0 attention/GDN projections, and Q8_0 token embedding and MTP head. 1252 tensors.
Usage (llama.cpp, deployment config for 24 GB)
Requires a llama.cpp build with sm_120 NVFP4 GEMM + CUDA Gated-DeltaNet (upstream ships both). The official CUDA server container works:
docker run --rm --gpus '"device=0"' \
-v $HOME/models:/models -p 8080:8080 \
ghcr.io/ggml-org/llama.cpp:server-cuda \
-m /models/Qwen3.6-27B-NVFP4.gguf \
-ngl 99 -c 160000 -fa on -np 1 \
--cache-type-k q4_0 --cache-type-v q4_0 \
--spec-draft-type-k q4_0 --spec-draft-type-v q4_0 \
--spec-type draft-mtp --spec-draft-n-max 3 --spec-draft-ngl 99 \
--temp 1 --top-p 0.95 --top-k 20 --presence-penalty 1.5 --min-p 0.0 \
--port 8080 --host 0.0.0.0
Notes:
--spec-type draft-mtp --spec-draft-n-max 3is what unlocks the headline throughput: the MTP head drafts, the model verifies.n_max 3is the sweet spot on this hardware.- Sampling (
--temp 1 --top-p 0.95 --top-k 20) matches the model's owngeneration_config.json.--presence-penalty 1.5is aggressive anti-repetition; drop to 0.5 to 1.0 if you see token-avoidance in long structured output. -fa on(flash attention) is required for quantized KV and works with this model's head_dim 256.- 160K < 262K native, so no RoPE scaling needed.
KV cache guidance (24 GB)
Only 16 layers keep a growing KV cache, so 160K fits, but it's tight alongside ~19 GB of weights. q4_0/q4_0 KV (~3 GB at 160K) is the safe default. K-cache precision matters more than V (K enters QK^T before softmax). If your prompts rarely exceed ~100K, --cache-type-k q8_0 --cache-type-v q4_0 with a lower -c buys better attention precision at the same VRAM.
Measurements
All measured on an RTX 5090 laptop (24 GB).
Size
| Model | Size on disk |
|---|---|
unsloth/Qwen3.6-27B:bf16 (full precision) |
54.7 GB |
Qwen3.6-27B-NVFP4.gguf |
19.41 GB |
unsloth/Qwen3.6-27B-MTP-GGUF:Q4_K_M |
17.1 GB |
Decode throughput (tok/s, with draft-mtp)
| Model | MTP 1 | MTP 2 | MTP 3 | MTP 4 |
|---|---|---|---|---|
unsloth/Qwen3.6-27B-MTP-GGUF:Q4_K_M |
31 | n/a | n/a | n/a |
Qwen3.6-27B-NVFP4.gguf |
39.2 | 46.2 | 46.5 | 45.9 |
Q4_K_M peaks at n_max 1 (31 tok/s); this model tolerates deeper speculation and peaks at n_max 3. The FP4 weight path plus a well-behaved MTP head gives ~1.5x the throughput of the standard quant.
Quality (tng-benchmark suite)
Evaluated against full-precision bf16 on terminal-bench 2.0 and MMLU-Pro (TNG distilled v0.1 subsets) and the full IFBench. Run with --reasoning-preserve and f16 KV cache (best-case quality config). The Qwen3.6-27B-NVFP4 gguf repack row is the straight repackage (BF16 embedding + MTP), included to show that shrinking those to Q8_0 costs no quality.
| Model | terminal-bench 2.0 | MMLU-Pro | IFBench |
|---|---|---|---|
bf16 (full-precision reference) |
46.7 % | 85.15 % | 72.00 % |
| Qwen3.6-27B-NVFP4 gguf repack (straight) | 40.0 % | 84.16 % | 66.67 % |
Qwen3.6-27B-NVFP4.gguf (this repo) |
46.7 % | 86.14 % | 66.67 % |
Qwen3.6-27B-NVFP4.gguf matches BF16 on terminal-bench and is within noise on MMLU-Pro. Shrinking the token embedding and MTP head to Q8_0 did not cost quality (it scores at or above the straight repack on all three), consistent with the near-lossless Q8_0 embedding and the MTP head being draft-only.
Caveat: quality was measured with f16 KV cache; the
q4_0/q4_0deployment config above is expected to score somewhat lower. The distilled subsets and small sample counts also make single-point differences noisy.
How this was made
Converted CPU-only with a modified llama.cpp/convert_hf_to_gguf.py. We patched the converter to add the --embd-as-q8 and --mtp-as-q8 flags below (which force the token embedding and MTP layer to Q8_0), on top of the existing --fp8-as-q8 path:
export PYTHONPATH=$PWD/llama.cpp/gguf-py # must be the repo-local gguf with GGML type NVFP4 (id 40)
python llama.cpp/convert_hf_to_gguf.py <SRC> \
--outfile Qwen3.6-27B-NVFP4.gguf --fp8-as-q8 --embd-as-q8 --mtp-as-q8
--fp8-as-q8: dequantize FP8 weights to Q8_0 (default would be larger BF16).--embd-as-q8: token embedding BF16 to Q8_0 (-1.16 GB, ~lossless).--mtp-as-q8: MTP layer BF16 to Q8_0 (-0.39 GB, draft-only).
Limitations and caveats
- Text only. The vision tower of the source VL model is not included. For multimodal use you would need a separate
--mmproj. - Requires FP4-capable hardware + build. Intended for Blackwell (
sm_120, e.g. RTX 5090). On other GPUs the FP4 GEMM path won't engage and there is no benefit over a standard quant. - Quality figures are the f16-KV best case. Real deployments using quantized KV cache will differ; benchmark subsets are distilled and noisy.
general.namein the GGUF metadata is the HF snapshot hash (cosmetic).
License and attribution
Licensed under the Apache License 2.0, inherited from the upstream models. See the LICENSE and NOTICE files in this repository.
This is a format repackage (not a retrain) of nvidia/Qwen3.6-27B-NVFP4 (Apache 2.0), which is itself derived from Alibaba's Qwen3.6-27B (Apache 2.0). The only changes are quantization/format conversion to GGUF, documented under How this was made (--fp8-as-q8 --embd-as-q8 --mtp-as-q8).
Attribution: please credit the Qwen team (Alibaba) for the base model and NVIDIA for the NVFP4 (Model Optimizer) export, alongside this repackage.
Trademarks: "Qwen" and "NVIDIA" are trademarks of their respective owners. The Apache 2.0 license does not grant trademark rights; these names are used here only to identify the upstream models. This repackage is not affiliated with, sponsored by, or endorsed by NVIDIA or Alibaba.
- Downloads last month
- 4,918
4-bit