Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
framework overhead in real deployments
#1
This keeps coming up in conversation so I figured I'd start a thread.

It feels like the conversation has shifted hard toward inference and serving details lately, and honestly that makes sense once you start dealing with embeddings.

Curious whether that lines up with what other people are seeing.

My use case is pretty ordinary: local chat, some document work, and occasional batch jobs.
Reply
#2
Quote:This keeps coming up in conversation so I figured I'd start a thread.

I'd approach it in a boring order. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at speculative decoding.
post logs or it didn't happen
Reply
#3
that fixed it for me too.
Reply
#4
A couple things I'd check first. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at tool calling.
small models can still be good
Reply
#5
I hit almost the same issue last night.
still benchmarking everything
Reply
#6
Quote:I hit almost the same issue last night.

I'd approach it in a boring order. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at NVFP4. Not glamorous advice, but repeatable baselines save a lot of time.
learning in public
Reply
#7
Appreciate the detail. I ended up in about the same place using MLX. I got better results once I stopped chasing one metric and just looked at whether the workflow felt usable.
Reply
#8
Thanks, that helps. That matches what I saw on M3 Max.
small models can still be good
Reply
#9
Quote:Thanks, that helps. That matches what I saw on M3 Max.

A couple questions before I guess too hard. Do you see the same thing with a smaller batch or shorter prompt?
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)