Good but ...

#35
by jbourny - opened

After a few days of testing on a Dgx Spark in NVFP4 it is quite good at the architecture level but the number of active parameters means that in the end it is slower to release something because 90% of the time it makes a lot of mistakes at first which forces it to think again about each multiturn to correct what it does.
For example, if he creates a simple HTML page he will put several syntax errors, after creating he will realize for example that he has written twice a meta tag.
Same for CSS strangely at the first pass he will very often create placeholder lines and then return to it.
Even in the reasoning there seems to be a problem, he can make a paragraph of several lines saying for example "I wrote xxxx, but xxxx is not xxxx, wait did I really write xxxx yes but wait xxxx is well written so why xxxx is not written as xxxx" It will lose 10 minutes while xxxx is well written...
I think that with at least 10 or 12b of active parameters it should be able to generate without too many errors.
After I was on a NVFP4 quantization the problem may have come from this but I also had the same problem with Qwen3.6 35b BF16 which had only 3b of active parameters.

This is productive feedback and aligns with other critical feedback.

Yeah, same thing here. I benchmark the inteligence of the models by making typescript unit tests for an api. It made 24 tests, 6 of them failed, and it got confused on some types. The 27b did everything flawlessly.
Granted i only used the q1 of this model.
I also had a problem, i have the latest llama.cpp and after about 35k tokens the model decode goes from 20t/s to 1t/s, i cant figure out the reason why.
I am using mmap to offload the wheights and ngram but i didnt see any increase in the bandwidth use when the decode crashed out.

Sign up or log in to comment