Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
eval setup for local models for Kimi
#1
Curious what people here are seeing.

I'm mostly working with Kimi in TensorRT-LLM on 7900 XTX. The part I'm trying to understand is workstation thermals.

Would appreciate practical advice rather than theory.

My use case is pretty ordinary: local chat, some document work, and occasional batch jobs.
throughput matters, but tail latency matters too
Reply
#2
Quote:Curious what people here are seeing.

What worked for me was pretty simple. On B200, the easiest win is often to back off the aggressive settings and see whether the problem survives.
Reply
#3
Quote:
Quote:Curious what people here are seeing.

I think the bottleneck is somewhere else. I wouldn't optimize around that first. On my side the bigger swing came from the runtime and not the model. Worth testing the simpler explanation before adopting the more interesting one.
measure twice, benchmark three times
Reply
#4
Appreciate the detail. I ended up in about the same place using TensorRT-LLM. The biggest change for me was simplifying the stack instead of adding one more optimization layer.
trying not to rebuild again
Reply
#5
Interesting, I hadn't tried that. That matches what I saw on M3 Max. The biggest change for me was simplifying the stack instead of adding one more optimization layer.
Reply
#6
A couple things I'd check first. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at NVFP4. Once you know the plain path works, then add the faster path back in piece by piece.
Reply
#7
Tried to reproduce it just now. The issue went away once I changed one setting and restarted the stack cleanly. I expected the model choice to matter more than it did.
serving stack tinkerer
Reply
#8
Interesting, I hadn't tried that. I ended up in about the same place using TensorRT-LLM. Worth rechecking your defaults though, because one bad assumption can make the rest of the thread look confusing.
measure twice, benchmark three times
Reply
#9
Tried to reproduce it just now. My result was mixed: first run looked bad, second run looked normal. The main thing that moved was latency, not quality.
Reply
#10
Not sure I agree there. The reported numbers can look compelling, but in ordinary usage I didn't see the same benefit. Worth testing the simpler explanation before adopting the more interesting one.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)