Spaces:

---

IsValorum

/

MiniPlus-NanoPlus-Requests

Like 2

Running

CyberTiel

1. Link: peculiar-ragdoll/Cyber-Tiel-Coder-35B-A3B-GGUF-MTP (https://huggingface.co/peculiar-ragdoll/Cyber-Tiel-Coder-35B-A3B-GGUF-MTP)
2. Just like Tiel , agentic coding tasks, but stronger, less thinking(in my opinion) and uncensored
3. Miniplus like what you did on Tiel

The MiniPlus V2.1 and NanoPlus quantizations are already underway; they will be available within an hour at most—follow me to get notified.

Wow
Thanks for your hard works and very fast reply, really impressive, this is the fastest model request i've seen on hf (or maybe you had already worked on this model from before :))

I will definitely check and test for if the Apex Miniplus CyberTiel work good too

Request for next model.
Reason: I've personally used k2 and it's the closest thing to match or exceed Qwen intelligence:
IFM/K2-Horizon-MoVA-36B-A4B

Need of Speed) https://huggingface.co/IFM/K2-Horizon-MoVA-36B-A4B

I personally tried the K2-Horizon, the smaller versions and that MoVA, and they didn't convince me because of the cost of the KV Cache.

I could barely get it to 8K context in Q4_0, not enough to properly test it, is it really any good?

For me, the fact that it had such an absurdly expensive KV cache was enough to completely rule it out. Did you guys test it in real-world use?

You were using Q4_0 KV?
How much VRAM on the rig?
I assume your models were tested on 24gb ram?

I tried it on an RTX 3090 and I simply didn't find that series of models appealing; the KV cache was too expensive.

Gotcha, no worries. Thanks for the responses, love your work.

Gotcha, no worries. Thanks for the responses, love your work.

If you find another model that you consider good, don't hesitate to let me know so I can quote it immediately.

are you interested in some thing called "Ternary-Bonsai-2-27B-gguf" (*edit:oh i tried result really bad, rather choose ornith 1.5)

Yeah, despite Prism-ML claiming over 90% retention, in practice they perform terribly. Ornith 1.5 is just way better.

among all 35b model, which provide you the best performance in agentic coding tasks ?
atm i'm using Tiel/CyberTiel

Tiel and CyberTiel are definitely great for that, but Occamy fits right in there as well.

While Tiel is very focused on direct syntax and fast tool execution, Occamy handles agentic coding equally well while offering a bit more balance on broader architectural context, complex debugging, and multi-file reasoning.

If you want to give it a spin to compare against your Tiel setup, here is the MiniPlus V2.1 release:
https://huggingface.co/IsValorum/Occamy-1.0-APEX-I-MiniPlus-V2.1-GGUF

Between Tiel/CyberTiel and Occamy, you're pretty much looking at the best options in the 35B tier for agentic workflows right now.

Yeah i see
But maybe i still go with tiel until qwen 4 35b a3b(just guess lol)
The author optimize this model kv cache really good so it take less vram/ram for large context amount
And it have mtp too
After apex miniplus exist so i change to mini plus when need quality, and comeback to iq3 xxs when need 262k context

Totally fair point. That DeltaNet KV cache efficiency plus MTP makes it a great daily driver for long context. Enjoy Tiel!

If you're dropping to flat IQ3_XXS just to fit the full 262K context, check out the NanoPlus release of Tiel:
https://huggingface.co/IsValorum/Tiel-Coder-35B-A3B-APEX-I-NanoPlus-GGUF

That's actually why I built NanoPlus: to give you that lower memory footprint for massive context while still maintaining Q4_K_M/L-class practical quality instead of the flat degradation of standard IQ3_XXS, keeping routers in F32 and output in Q6_K.

Yeah, but i think miniplus with 131k still work good, even can upto 180-190k if i reduce some prefill boost parameter and disable mtp

Thoughts on the new European Model? Aleph-Alpha/Kolibri-1 https://huggingface.co/Aleph-Alpha/Kolibri-1

78B with ~4B active, gets decent benchmark

Hi @userr99 ,

I looked into it as soon as it dropped today, but unfortunately it is physically impossible to make GGUFs for it right now.

The main blocker is that Aleph Alpha built a completely custom architecture from scratch (Kolibri1ForCausalLM). llama.cpp has zero support for it: the GGUF converter will simply crash because it cannot map the tensors, and the C++ engine has no kernels to execute its specific 4:1 sliding-window attention (4 SWA layers for every 1 GQA layer) or route across 384 micro-experts per layer (that is 19,200 expert FFN blocks across its 50 layers). It does not even run on standard vLLM without installing Aleph Alpha's own proprietary plugin package (aleph-alpha-inference).

On top of the architecture gap, the base weights are 145.5 GB in BF16. Even if someone in the community spends weeks writing a custom C++ PR to get kolibri1 into llama.cpp, a 78B MoE would still land around 32 to 35 GB in a MiniPlus quant, meaning it would not fit into a single 24 GB VRAM card anyway without spilling into RAM.

So for now, until upstream llama.cpp actually writes and merges full native support for the architecture, it is completely out of reach for GGUF.

i see something called "Xing4.0-29B-A4B" ,does it have any advantage when comparing to 35b models (coding, speed, weight,...)

Tiel seem still very op

And Cyber-Tiel is practically the same but Abliterated; I also have it under the MiniPlus and NanoPlus recipes if you want to try them.

Hello, thanks for your work! Have you tested your mini models at 512k–1M context, especially in llama.cpp? Does the quantization remain stable or accurate that deep into the context, or is 160k–256k currently the validated range?

Hello! Honestly, I have only tested and validated them up to 256K tokens, which is the range where I can verify stability and accuracy. Beyond that (512K to 1M), I haven't tested them directly.

Thanks for your work IsValorum, fan of your VAL-APEX Mini and Nano. I would really like to see https://huggingface.co/agentionai/Qwen3.8-27B-AP-GGUF with VAL-APEX Abliterated. Reason being is that it requires fewer thinking tokens for similar output, also outperforms ISTA and Unsloth. Agention seems to be among the models for its size I've come across. It also has adaptive speculative decoding. Would really like it to be abliterated and with VAL-Apex applied to see it be reduced in size further with it being uncensored.

Here is the full report from his work with substantiation of why I'd like specifically this model VAL-APEX abliterated: https://share.fieldworkledger.com/tTkQDHijE_Anj0yv79bsIw

Hi @smolboon ,

Thanks a lot for the support on the Mini and Nano builds!

I checked out the Fieldwork Ledger report you linked. It is actually a benchmark comparing different GGUF quantizers (Agention vs Unsloth, ISTA, etc.) on stock Qwen3.8-27B, rather than a new fine-tuned model.

Because Agention only released final .gguf files and there are no unquantized BF16 weights, it is physically impossible to abliterate their files (abliteration has to be calculated directly on raw 16-bit weights before quantizing).

That said, we already have models in the catalog that cover exactly what you are looking for:

• If you want an uncensored model that uses significantly fewer thinking tokens, check out Qwen3.8-27B-EfficientThink-Uncensored (available in both MiniPlus and NanoPlus). It was tuned specifically to cut down thinking bloat while keeping full reasoning.
• If you just want the stock 27B base fully abliterated, Huihui-Qwen3.8-27B-Abliterated is already available.
• Plus, our MiniPlus and NanoPlus V3 builds already include the native MTP speculative decoding head directly in the GGUF.

Give EfficientThink a spin, it is probably the exact fit for what you have in mind!

hi
i try your Qwen3.8-27B-EfficientThink-Uncensored NanoPlus V3 but got this error

Do you know how to fix

Good catch @nmh2k3 , and thanks for the screenshot!

That happened because the main GGUF has the standard 64 layers (0-63) while the MTP head was packaged separately in the draft file, but the conversion script left block_count = 65 in the header. llama.cpp saw that 65 and started looking for blk.64.* inside the main file, which obviously wasn't there.

I just pushed an update to both NanoPlus V3 and MiniPlus V3 fixing the header to block_count = 64.

If you already downloaded the ~11 GB file and don't feel like downloading it all over again, you can patch your local file in 2 seconds with this quick Python snippet:

import struct

filename = "Qwen3.8-27B-EfficientThink-Uncensored-VAL-APEX-I-NanoPlus-V3.gguf"

with open(filename, "r+b") as f:
    header = f.read(2048)
    idx = header.find(b"qwen35.block_count")
    if idx != -1:
        f.seek(idx + len(b"qwen35.block_count") + 4)
        f.write(struct.pack("<I", 64))
        print("Done! Fixed block_count to 64.")

After that it will load right away. And if you want to run MTP speculative decoding with it, just add --model-draft mtp-Qwen3.8-27B-Q4_0.gguf to your command!