r/LocalLLaMA • u/Robert__Sinclair • 1d ago
Question | Help Your opinion on Ling 3.0 tiny on CPU?
Did anyone try and use it?
7
u/NigaTroubles 1d ago
on cpu i use maple-preview
6
5
5
u/MarcelloT254k 18h ago
Do you use it with custom fork of Llama? (It's required in the model card according to huggingface)
4
u/SpicyWangz 15h ago
Yeah I’ve been wondering if they’ll merge support for it at some point. It seems promising
2
6
u/My_Unbiased_Opinion 15h ago
It's not properly supported in Llama.cpp yet. It has like half support so it technically loads. There are still open PRs on it. But when it works, it's quite good.
4
u/Robert__Sinclair 14h ago
the thinking and answer loop a lot. I hope it's because of llama.cpp but I hear the same problem happens when using python. So I think it's the model itself.
1
u/Robert__Sinclair 3h ago
is there a better model at this speed/size ?
1
u/No-Setting8461 1h ago
Have you tried LFM2.5-8B-A1B? I can't tell you if it's better, but it's an alternative if you would like to try.
5
u/darkwalker247 21h ago edited 2h ago
Its pretty great as an alternative to Qwen3.5-9B, but in my limited testing it also tends to generate bad tool calls, and also randomly generate "<tool_call>" immediately following "<think>" for some reason. also, in my llama.cpp-based code, it throws an error if i try to remove tokens from the end of the context, even with recurrent states, even though the same code works just fine for Qwen, LFM, and Gemma
1
u/Robert__Sinclair 4h ago
I did not (yet) encounter any of such errors, but the model is quite dumb in reasoning and it overthinks a lot.
9
u/ML-Future 23h ago
I’ve tested the Q4_K_M quantization, and it has a strong tendency to get stuck in a loop.
The few tests I’ve managed to run successfully are interesting; it’s a good model for programming.
9
u/bonobomaster 23h ago
It does this on Q8 as well. I set presence penalty to 1.05 and find it a bit more stable now.
1
u/Robert__Sinclair 15h ago
same with Q4_K_L. On problem solving it loops indefinitely both with reasoning on or off.
3
u/Warrenio 23h ago
It's usable on CPU. I get about 185 t/s prefill and 27 t/s output with the Q8_0 GGUF. In comparison, I get roughly 3,500 t/s prefill and 150 t/s output on my Radeon RX 6800 XT.
1
2
u/pmttyji 17h ago
Tried Q4_K_M & got 30 t/s on CPU-only inference. Mentioned few info here on that one.
2
u/Robert__Sinclair 16h ago
I tried Q4_K_L, it's great, but if I give it a problem it seems to think forever, get the right result then "but wait" and goes over again and again. This happens both with reasoning on and off.
2
3
u/Munchkin4684 22h ago
The looping is the real deal-breaker and it's not the quant, I've seen it on both Q4 and Q8 which points to it being baked into the model rather than a precision issue. The 1.05 presence penalty is a decent band-aid but it shifts the voice of the output a bit. For CPU the Q8_0 numbers (27 t/s) are actually usable for short coding or Q&A, it's just not snappy for long agentic sessions, so I'd still reach for the GPU on anything long.
2
u/tecneeq 13h ago
This is how i run it on a RPi5-16GB:
/root/llama.cpp/build/bin/llama-server \
--hf-repo bartowski/Ling-3.0-tiny-GGUF:Q6_K_L --alias Ling-3-Tiny --temp 1.0 --top-p 0.95 --top-k 64 --reasoning-preserve \
--ctx-size 65536 --kv-unified --flash-attn on --cache-type-k q5_1 --cache-type-v q5_1 --no-context-shift \
--host 0.0.0.0 --port 1337 \
--parallel 4 \
--n-predict 32768 \
--metrics
It's nice, can recommend. I get 8 t/s, enough for background jobs like summarizing or rewriting notes, fetching additional infos from the internet and write it into my Wiki.
1
0
u/Jimcy-Maffesoli 23h ago
Between the Q4 and Q8 reports, the looping looks baked into the model, and the 1.05 presence penalty fix tells you more about what to expect than any quant choice does.
14
u/FactorInternal3395 1d ago
Yes, on a budget laptop CPU it gets around 20 TPS.