Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
batching changes after update for Llama
#1
Spent some time on this today and wanted to compare notes.

I've gone back and forth between MLX and llama.cpp for Kimi. The interesting difference for me has been prefill/decode split.

What would you pick if you had to live with it for a few months?

My use case is pretty ordinary: local chat, some document work, and occasional batch jobs.
Mostly CUDA, sometimes wrong, usually measured
Reply
#2
Tried to reproduce it just now. I couldn't reproduce the slowdown until I pushed context much higher. The main thing that moved was latency, not quality.
Mostly CUDA, sometimes wrong, usually measured
Reply
#3
Interesting, I hadn't tried that. The pattern around quant drift has been pretty similar for me.
Reply
#4
Quote:Interesting, I hadn't tried that. The pattern around quant drift has been pretty similar for me.

I'd approach it in a boring order. Before rebuilding anything, I'd test one clean baseline with Qwen and compare from there. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.
still benchmarking everything
Reply
#5
A couple questions before I guess too hard. Are you testing this on mini PC or something else?
Reply
#6
A couple things I'd check first. Before rebuilding anything, I'd test one clean baseline with Mixtral and compare from there. Not glamorous advice, but repeatable baselines save a lot of time.
Reply
#7
That matches what I was seeing. That matches what I saw on M3 Max. Worth rechecking your defaults though, because one bad assumption can make the rest of the thread look confusing.
Reply
#8
Quote:That matches what I was seeing. That matches what I saw on M3 Max. Worth rechecking your defaults though, because one bad assumption can make the rest

Need a little more detail here. Is this local-only or are you routing anything externally?
Mostly CUDA, sometimes wrong, usually measured
Reply
#9
My first guess would be this: On Threadripper box, the easiest win is often to back off the aggressive settings and see whether the problem survives. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.
Reply
#10
Quote:My first guess would be this: On Threadripper box, the easiest win is often to back off the aggressive settings and see whether the problem survives.

That matches what I was seeing. I don't think your conclusion is far off. The biggest change for me was simplifying the stack instead of adding one more optimization layer.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)