Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
tool calling reliability
#1
Spent some time on this today and wanted to compare notes.

Two paths both seem viable, but they break down differently once batch size becomes important.

Trying to avoid rebuilding the whole thing twice.

This is mostly for local work rather than public serving.
trying not to rebuild again
Reply
#2
A couple questions before I guess too hard. Is this local-only or are you routing anything externally?
still benchmarking everything
Reply
#3
I tested this tonight. On 4090 with Ollama, I saw basically the same behavior.
Reply
#4
What worked for me was pretty simple. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at router policy. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.
LoRA tinkerer • dataset janitor
Reply
#5
My first guess would be this: Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at INT4. Not glamorous advice, but repeatable baselines save a lot of time.
Reply
#6
My first guess would be this: 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.
Reply
#7
Quote:My first guess would be this: Before rebuilding anything, I'd test one clean baseline with Qwen and compare from there. A lot of these threads end up

same here on my side.
measure twice, benchmark three times
Reply
#8
Tried to reproduce it just now. On mini PC with vLLM, I saw basically the same behavior. The main thing that moved was latency, not quality.
Reply
#9
Tried to reproduce it just now. The issue went away once I changed one setting and restarted the stack cleanly.
Reply
#10
A couple things I'd check first. On 4090, the easiest win is often to back off the aggressive settings and see whether the problem survives.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)