Live data from Hacker News

Making LLMs Cheaper and Better via Performance-Efficiency Optimized Routing

arxiv.org

21–29 of 29 posts

Re: Making LLMs Cheaper and Better via Performance-Efficiency Optimized Routing

#21
post #17

Essentially, instead of modifying the prompt itself, the system intelligently directs the prompt to the LLM that is best suited to handle it based on its learned performance and efficiency characteristics for similar types of queries. It's externally optimizing people's prompts.

How does it learn in the first place?

Re: Making LLMs Cheaper and Better via Performance-Efficiency Optimized Routing

#22

I’m fascinated by this new paradigm. We’ve more or less perfected Mixture-of-Experts inside a single model, where routing happens between subnetworks. What GPT-5 auto (and this paper) are doing is a step further: “LLM routing” across multiple distinct models. It’s still rough right now, but it feels inevitable that this will get much better over time.

I'd actually bet against this. The "bitter lesson" suggests doing things end-to-end in-model will (eventually, with sufficient data) outcompete building things outside of models.

My understanding is that GPT5 already does this by varying the quantity of CoT done (in addition to the kind of super-model-level routing described in the post), and I strongly suspect it's only going to get more sophisticated

Re: Making LLMs Cheaper and Better via Performance-Efficiency Optimized Routing

#23
post #14

Based on my experience, the GPT-5 router either isn't very smart or is deliberately configured to be very stingy. It basically never uses the reasoning model by itself, even if that means it hallucinates nonsense.

Same experience as you.

Re: Making LLMs Cheaper and Better via Performance-Efficiency Optimized Routing

#24
post #20

I’m fascinated by this new paradigm. We’ve more or less perfected Mixture-of-Experts inside a single model, where routing happens between subnetworks. What GPT-5 auto (and this paper) are doing is a step further: “LLM routing” across multiple distinct models. It’s still rough right now, but it feels inevitable that this will get much better over time.

I wish this could be exploited even further, where a big model could be built with a network of a lot of small, specialized, models And then maybe you could just customize and optimize your own mode for local use. Almost like mixing and matching different modules. It would be nice to have a model that only knows and does what you need it to

A Team-as-a-Service? Would be interesting to be able to create a Python script acting like a team of sales, project management, and engineering working together with telemetry and KPIs dashboard on top. If not to deliver anything useful then as a project management frameworks learning tool.

Re: Making LLMs Cheaper and Better via Performance-Efficiency Optimized Routing

#26
post #22

I’m fascinated by this new paradigm. We’ve more or less perfected Mixture-of-Experts inside a single model, where routing happens between subnetworks. What GPT-5 auto (and this paper) are doing is a step further: “LLM routing” across multiple distinct models. It’s still rough right now, but it feels inevitable that this will get much better over time.

I'd actually bet against this. The "bitter lesson" suggests doing things end-to-end in-model will (eventually, with sufficient data) outcompete building things outside of models. My understanding is that GPT5 already does this by varying the quantity of CoT done (in addition to the kind of super-model-level routing described in the post), and I strongly suspect it's only going to get more sophisticated

The bitter lesson type of strategy would be to implement heterogeneous experts inside an MoE architecture so that the model automatically chooses the number of active parameters by routing to experts with more parameters.

This approach is much more efficient than the paper of this HN submission, because request based routing requires you to recalculate the KV cache from scratch as you switch from model to model.

Re: Making LLMs Cheaper and Better via Performance-Efficiency Optimized Routing

#27

Wow, that was fast. I've thought for a while that ensembling approaches would become the next stage of LLM development after CoT, since it provides yet another effective, independent axis for scaling laws. Great to see that perspective is taking off. The open weight community has an opportunity to take these ideas and run with them better than OpenAI has.

Yet a context hell comes with that

Re: Making LLMs Cheaper and Better via Performance-Efficiency Optimized Routing

#28
why do we always come up with new words for basic ideas. test time compute, test time router, test time sleep, test time slop. its a router lets call it router.

at the end most of those principles are not part of the LLM but part of the API design in front of the LLM. I understand the goal is trying to abstract this fact to sell more magic.

Re: Making LLMs Cheaper and Better via Performance-Efficiency Optimized Routing

#29

I’m fascinated by this new paradigm. We’ve more or less perfected Mixture-of-Experts inside a single model, where routing happens between subnetworks. What GPT-5 auto (and this paper) are doing is a step further: “LLM routing” across multiple distinct models. It’s still rough right now, but it feels inevitable that this will get much better over time.

Matformer seems a better approach to this type of scaling though
Post reply on HN