Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Blackwell deployment chatter
#11
My first guess would be this: On GB200, the easiest win is often to back off the aggressive settings and see whether the problem survives. Once you know the plain path works, then add the faster path back in piece by piece.
Reply
#12
A couple things I'd check first. If you're on MLX, I'd confirm the version first and then reduce variables until the behavior is obvious. Not glamorous advice, but repeatable baselines save a lot of time.
Reply
#13
That matches what I was seeing. I don't think your conclusion is far off.
Reply
#14
I'd approach it in a boring order. Before rebuilding anything, I'd test one clean baseline with Kimi and compare from there.
learning in public
Reply
#15
Did a small comparison this afternoon. My result was mixed: first run looked bad, second run looked normal. The main thing that moved was latency, not quality.

There are a few different conversations hiding inside this thread, so being explicit about the goal helps.
Reply
#16
My first guess would be this: Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at prefill/decode split. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.

If you post your exact settings, people here can probably narrow it down pretty fast.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)