Upload README.md with huggingface_hub

README.md

@@ -16,12 +16,6 @@ inference: false
 
 # DeepSeek-V4-Flash — Config-I (GGUF)
 
-> 🔧 **KNOWN ISSUE, FIX IN PROGRESS (2026-08-03).** These files were quantized on a
-> branch where `Q2_0` carries ggml type ID **47**; the canonical TurboQuant fork uses
-> **42**. As a result the current files fail to load with an error like
-> `tensor 'blk.0.ffn_gate_inp.weight' has offset X, expected Y`. The tensor data is
-> fine, only the type field is wrong. Corrected files are being re-uploaded now.
-> **Please hold off downloading until this notice is removed.**
 
 
 
@@ -34,19 +28,16 @@ Config-I quantization of [deepseek-ai/DeepSeek-V4-Flash-0731](https://huggingfac
 
 ## ⚠️ Runtime requirement
 
-This GGUF uses fork-specific ggml types and **requires this exact branch**:
+This GGUF uses the TurboQuant `TQ3_1S` weight type, so it needs the [TurboQuant llama.cpp fork](https://github.com/TheTom/llama-cpp-turboquant) rather than stock llama.cpp:
 
 ```bash
 git clone https://github.com/TheTom/llama-cpp-turboquant
-cd llama-cpp-turboquant
-git checkout tom/merge-upstream-dsv4
+cd llama-cpp-turboquant          # default branch is what you want
+cmake -B build -DGGML_CUDA=ON    # or -DGGML_METAL=ON on a Mac
+cmake --build build -j
 ```
 
-Stock llama.cpp and earlier fork tips **cannot load it**. They lack both the `deepseek4` architecture and the type table this file was written against: the expert tensors are ggml type 47 (`Q2_0` in this branch), which older builds read as out of range, producing shifted tensor offsets and a load failure like `tensor 'blk.0.ffn_gate_inp.weight' has offset X, expected Y`. If you see that error, you are on the wrong build, not a corrupt download. Tracking PR: https://github.com/TheTom/llama-cpp-turboquant/pull/256
-
-**Metal (Mac) users:** run with `TQ_NO_ROTATE=1` in the environment. The fused rotate-act Metal kernel currently produces incorrect batched-prefill results on this architecture (decode is unaffected); the env var routes through the safe dequant path at a modest prefill-speed cost.
-
-**CUDA users:** use the `tom/merge-upstream-dsv4` branch above — earlier fork builds route TQ3_1S through a fused kernel that produces incorrect output on this architecture (fixed by routing through the verified dequant path; costs some decode speed, correctness first).
+Verified against the fork's default branch (`feature/turboquant-kv-cache`): loads and generates correctly on both Metal and CUDA.
 
 ## Recipe