Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Apple unified memory limits with vLLM
#1
Maybe I'm missing something obvious.

I'm mostly working with Phi in llama.cpp on GB200. The part I'm trying to understand is NVFP4.

Would appreciate practical advice rather than theory.
M3 Max • MLX • local-first
Reply
#2
Quote:Maybe I'm missing something obvious.

worth checking the driver first.
Reply
#3
Ran a quick check on my box. I couldn't reproduce the slowdown until I pushed context much higher.
M3 Max • MLX • local-first
Reply
#4
Maybe, but I had the opposite result. I've seen people blame consumer GPUs when the real issue was much more mundane. Worth testing the simpler explanation before adopting the more interesting one.
Apple Silicon • MLX mostly
Reply
#5
I tested this tonight. My result was mixed: first run looked bad, second run looked normal.
Reply
#6
My first guess would be this: Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at tool calling.
trying not to rebuild again
Reply
#7
Did a small comparison this afternoon. I couldn't reproduce the slowdown until I pushed context much higher. The surprise was that memory pressure showed up before throughput collapsed.
Reply
#8
that fixed it for me too.

There are a few different conversations hiding inside this thread, so being explicit about the goal helps.
throughput matters, but tail latency matters too
Reply
#9
Did a small comparison this afternoon. My result was mixed: first run looked bad, second run looked normal.
Reply
#10
I'd approach it in a boring order. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at VRAM headroom. Once you know the plain path works, then add the faster path back in piece by piece.
learning in public
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)