Join the conversation

Join the community of Machine Learners and AI enthusiasts.

Sign Up
satgeze 
posted an update 2 days ago
Post
3234
First GGUF quants of Tencent's Hy3 (299B MoE), built before official llama.cpp support exists.

Hy3 dropped ~30 hours ago with only MLX and MXFP4 quants, both datacenter-sized. So I converted it myself using a community llama.cpp fork that implements the hy_v3 architecture.

What's in the repo:

- IQ1_M (62GB, fits a 128GB MacBook), IQ2_M (90GB), Q2_K (101GB), all with 1M context baked in via YaRN
- IQ quants are importance-matrix: bootstrap style. The static Q2_K ran RAM-resident to compute the imatrix, then IQ1_M and IQ2_M were requantized from the archived f16 with it
- Fixed chat template (the stock one uses .format() calls llama.cpp's Jinja rejects)
- Build instructions for the fork, including the two gotchas that cost me three build attempts

Honesty section, because that is how these repos work: this is EXPERIMENTAL. Not needle-certified yet (1M is baked but unverified, certification ladder will be published either way). MTP layer exists in the checkpoint but no llama.cpp build can run hy_v3 MTP inference yet, so it is not included. Real gate outputs are on the card, misses and all, judge for yourself.

satgeze/Hy3-1M-GGUF

Full quant ladder (Q3 through Q8) is mirroring to ModelScope for bigger hardware.

Doing gods work. about to go to sleep. hope to wake up to a Q4 on ModelScope 😃

Trying to run this on 8x v100

·

by then hopefully I'll have MTP also baked in. Hopefully 🤞
If happens, I'll push MTP quants. But my resources are not VRAM rich so that's why it takes this long in building/testing stuff.

The imatrix bootstrap is the part worth underlining.

You measured the importance matrix through a 2-bit lens (Q2_K, RAM-resident), then requantized IQ1_M and IQ2_M from the archived f16 with it. So the low-bit quants inherit a salience signal that was itself quantized.

Did you sanity-check that against an imatrix computed from the f16 directly? A full-precision imatrix could flag different channels to protect, and IQ1_M is exactly where protecting the wrong ones hurts most.

What did a single needle run at 256K show before you certify the 1M?

·

You read it exactly right, and it's the part I'd poke at too. The bootstrap was physics, not preference: Hy3 f16 is 598GB and nothing I own can run it. I have two machines: a 5090 box (32GB VRAM, 128GB system RAM) and a MacBook Pro M3 Max with 128GB. I can only try what physically fits on these without a painfully slow dev experience. So the highest-fidelity runner available for computing the imatrix was my own Q2_K quant, loaded fully into the 5090 box's 128GB system RAM and running CPU-side (the card's 32GB can't hold it). A full-precision imatrix comparison doesn't exist yet, and I won't pretend otherwise. What does exist as sanity: all three quants passed coherence gates, and IQ2_M got a full day of hands-on today (reasoning converges at 2.5 bits, tool calls work, field notes are on the card including where IQ1_M breaks). imatrix v2 from a higher-fidelity runner is already on my list, and the low-bit rungs get requantized when it lands.

On 256K: correct, there are zero needle certifications on Hy3 yet, at any depth. That's why the card says EXPERIMENTAL in red and "1M baked but unverified." The NIAH ladder (262K first, then up) is queued right after the MTP work finishing now, and the numbers get published pass or fail, same as the gemma cards where I printed the misses too.

By the way, thanks to your earlier replies I went and adopted NVIDIA's RULER as the next test tier. First results are live on the Gemma4-12B card: five tasks at 131K, scored by NVIDIA's own evaluate.py, including a finding I didn't expect (thinking mode halves the score, and I published that too, zeros and all). Your kind of scrutiny is what pushed the testing up a level, so genuinely, thanks.

Since you're following this closely: MTP validated today on a llama.cpp fork port, 85.8% draft acceptance. Quants with the MTP head baked in are built and going through my own testing before I upload anything.

The physics constraint is fair, and it points at a cheaper test than the one I asked for.

You cannot load f16, but Q3 and Q4 fit. Compute the imatrix from Q2_K, Q3, and Q4, then check the rank correlation of per-channel importance across them. If Spearman stays high as bit-depth rises, the salience ranking is probably stable down to f16 too, and IQ1_M is safe. If it drifts, you have found the exact failure mode without ever holding the full weights.

RULER over vanilla NIAH is the right call. On a YaRN-baked 1M model the number I would watch is where accuracy breaks relative to the baked length, since the extension usually rots before the nominal limit.

Where do you expect IQ1_M to give out first, the retrieval or the reasoning?

·

That's a great idea actually 👍
Q3 and Q4 runners are being built right now anyway as part of the MTP requant wave, so once they exist I can compute imatrices from all three and publish the rank correlations across bit depths, whichever way they land.

On your question, today's hands-on testing already gave me half the answer: reasoning gives out first, and it gives out early. IQ1_M holds together for chat and short answers, but reasoning mode collapses into circular loops even on trivial prompts at short context. That behavior is documented on the card. Retrieval at depth is the untested half: the NIAH ladder for Hy3 is queued right after the MTP work, so whether retrieval outlasts reasoning toward the baked limit is exactly what it will show. Your point about extension rot before the nominal limit matches what I measured on other models too: my 6x and 8x YaRN experiments showed the factor itself taxing quality even while needles still passed. Numbers publish as the rungs finish.

Reasoning breaking before retrieval is the tell.

Circular loops at short context are not a memory failure, they are a decisiveness failure. At IQ1_M the logit distribution flattens, so the model never commits hard enough to escape a branch it already tried. Chat survives that because any fluent continuation passes. Reasoning does not, because it has to remember it ruled a path out.

The number I would log next to RULER is loop rate: fraction of reasoning traces that repeat an n-gram window before terminating. If that climbs with bit depth faster than accuracy falls, you have isolated exactly what 1-bit breaks.

Does the collapse survive greedy decoding, or does temp 0 pull it back out?

·

Your greedy question is the one place I already have data. On the Gemma 12B at 131K, temp 0 made it worse, not better: 12 of 25 samples looped deterministically until they died at the budget, and the same samples looped again on rerun. Vendor sampling (temp 1.0) halved the failures to 6 of 25 but did not eliminate them. Raw prediction files for both conditions are in the repo. On the 299B at IQ1_M it is one step darker: loops happen even with sampling, at short context, on trivial prompts. So the pattern across bit depths so far: at 4-bit you need greedy plus long context to trigger the loop; at 1.7-bit sampling cannot pull it out. That lines up with your flattened-logits read.

Adopting your loop-rate metric as of the next runs: the bridge will store full reasoning traces, and I will publish n-gram repeat rate next to each RULER rung, plus a bit-depth sweep across the Hy3 quant ladder as those rungs finish building. If loop rate climbs faster than accuracy falls, you called it.

Your temp-0-vs-sampling split is the cleanest diagnostic in this whole thread.

It separates two failures that look identical from the outside.

One: the determinism trap. Greedy makes the loop a fixed point, re-entered token for token. Sampling breaks it, which is your 12 to 6.

Two: state collapse. At IQ1_M sampling cannot pull it out, because the model has lost the memory that it already ruled this branch out. A random escape just re-converges.

The tell that separates them is lexical. Exact n-gram repeat means determinism, and temperature or a repetition penalty fixes it. Same dead reasoning reworded means the working memory is gone, and nothing short of more bits helps.

So I would split loop rate into those two buckets rather than log it as one number. The ratio is the real bit-depth signal: exact-repeat share should fall and reworded-repeat share should rise as you drop toward 1.7-bit.

The 6 of 25 that survive sampling at 4-bit are already sitting in your prediction files. Do they repeat the exact tokens, or reword the same dead path?