I'm currently trying to write an inference engine that combines the benefits of llama.cpp (one binary deployment, good support for heterogenous non-datacenter compute, wide quantization support) with the benefits of vLLM/SGlang (things like proper paged attention for better VRAM utilization and high concurrency).
Datacenter hardware is expensive and there's shortage of it but llama.cpp is slow/unoptimized for concurrent use, while vLLM/SGLang easily crash on non-common setups (things like, if you do pipeline parallelism for RTX5090+RTX4090, they will randomly crash with RAM caching enabled or select wrong kernels because they usually assume that every rank is the same device type; they also don't support Q5-Q6).
For me what's most interesting is to optimize inference for lack of good datacenter hardware and how to optimize for it best. I've been running an AI server in the office, and so far I've find these techniques most important for concurrent use on cheap hardware: pipeline parallelism (to accomodate for PCie), RAM caching (to quickly restore contexts into VRAM), speculative decoding (including domain-specific ngrams, they already can speed up code generation considerably without the overhead of a draft model), good kernels highly optimized for a specific device, support for Q5-Q6 (almost as good as Q8), FP8 contexts (more context to fit), paged attention (for better VRAM utilization), prefix caching, continuous batching (this is the default everywhere).
So far the main bottlenecks have been llama.cpp's poor VRAM utilization for contexts (you either have fixed-size slots, or use unified KV cache where each request attends to attention from all other requests and then unnecessary portions of attention are masked out), and lack of decode/prefill segregation: when a request starts prefilling a long context, all decoding threads slow down to like 5 tok/sec. On the other hand, vLLM/SGLang feel superbuggy if you don't run them on some officially approved node like 8xH200
Can we expect similar issues such as spectre and meltdown that intel experienced with speculative execution.. but, in the form of prompt injection/poisoning?
No, spectre is based upon speculative execution of code generated by another party. The breach is from the protection stopping that code from doing anything bad. Speculatve execution making things faster by varying amounts is used to turn those differences in timing into a signal.
You could possibly in-pronciple detect what a model with a censorship filter was actually saying, but not really. The signal is weak and needs lots of samples to get anything worth having. You just don't have that level of control to set things up.
Ok, I'll bite: no, considering these are very different domains and you don't get system access by getting the wrong speculative branch for your next text token, you just get a slightly different (but probably still related enough) text.
It's closer to "we can make this highly parallel for not that much cost, but we struggle to use that concurrency. So what if we just guess what the next step is going to be? If we are right we get a big speedup, if we are wrong we just throw that work away". Which I would classify as a notable insight. Doing work that you are 50% certain is useless is not the most obvious thing
This article describes what is usually called a Pareto frontier: the best known achievable trade-offs between two (or more) optimization goals. "Efficient frontier" in common usage seems to be specifically a Pareto frontier for financial risk versus return of an investment portfolio. Even outside of finance, points on a Pareto frontier are called Pareto optimal or Pareto efficient. A Pareto frontier is sometimes shown with more than two dimensions, although usually people will pick just two for simplicity.
Within LLMs, and even inference naturally, there are many other potential parameters that one might optimize: Unsloth typically shows a Pareto frontier for size of a quantized model versus KL divergence. Others trade total concurrent tok/s against single-stream tok/s. KV cache size, context length and context coherency are other trade-offs that are closely related to inference. Total intelligence is usually a defining characteristic of a "frontier model", with cost (per token or task) as a salient trade-off. Cost is one parameter that is implicitly fixed by the "throughput versus latency" analysis: using a GB300 versus Radeon R9700 moves the curve enormously and probably changes the shape of it. Lots of threads here argue over local vs cloud inference regarding cost efficiency, often with privacy and control as competing objectives.
this is a nice and concise writeup. what's striking to me is that these techniques really have not changed in /years/. sure, precision has become slightly lower, spec decoding acceptance has gotten slightly better and the complexity of parallelism is trickier with mixture of experts. but no new concepts in a very long time!
the absolute most impactful improvements for inference comes at architecture design time. I firmly believe everyone who cares about impacting model efficiency should look there
I think we can soon include "recursive depth" strategy that Astra is employing, which (I suspect) is using recursive internal state changes in the transformer as opposed to full forward-pass + sampling which has traditionally been the case with thinking/CoT. Similar method was used here (but different context - encoding tools inside the transformer weights for fast execution): https://www.percepta.ai/blog/can-llms-be-computers
2026 has been the year where spec-dec has matured, it has been adopted by all big OSS engines and i'm sure it's present in quite a lot of inference providers as the default
I feel like P/D dissaggregation will be the next big one for providers, as prefill tends to be compute bound while decode mem bound which I guess each will have a different type of node
Inference techniques either move a deployment along the latency–throughput frontier or push the entire frontier out, creating more efficiency to allocate.
This is a tautology. You can say that with anything. Gastronomy techniques will make a previous recipe better, or create a new recipe better than others, or a mix of both.
The point is to classify them into two kinds. The kind that shifts the frontier is more powerful, since improves capabilities without incurring tradeoffs.
I also wrote this as somewhat of a defense of the techniques that don't move the frontier -- there is a lot of value in being able to pick a point on the curve.
How do you know for sure that you stay on an efficient frontier when you change a parameter?
I think this presentation says more about what knobs you can turn and in what direction the outcome will move (it may be worse than a competitor) than it says about frontiers.
You know what I'm curious about? Whether you have brand guidelines inside the company, a Claude skillset, or the blog post author makes the charts in line with the brand colours and so on.
Nice read. I was wondering what can one do to get into inference engineering as simple theoretical knowledge is not sufficient and switching profiles is tough for someone with years of experience.
"the efficient frontier" is an important landmark of (investment) portfolio theory. It proves/explains/illustrates how you can combine selections from a diffuse cloud of individual investments and still land on a frontier that is better than any of your individual choices. It's the entire basis of "diversify your portfolio".
The efficient frontier of LLM inference is a line, not a frontier.
The author does not deeply mention that quality/intelligence is a third dimension here in addition to throughput and latency, and the frontier is jagged so quality and intelligence require bespoke benchmarks to evaluate tradeoffs for speed and cost.
These are both good points that I attempted to cover, quotes:
> In practice, the efficient frontier is very jagged. Rather than a smooth, continuous line between outcomes, small changes can have big impacts. These cutoff points are often unintuitive and must be discovered empirically through sweeps.
> However, quantization introduces a new set of tradeoffs between quality and serving efficiency. This is a particularly jagged frontier, where a large degree of improvement to serving efficiency is possible with little-to-no reduction in model quality, especially when using microscaling floating-point number formats like MXFP4 and NVFP4.
Would appreciate ideas on how to explain in greater depth
> A model is a “frontier model” if it offers the highest degree of intelligence at a given cost or size.
I would define a "frontier model" as offering the highest degree of intelligence at any cost, or without regard to cost. The frontier today is clearly Fable/Mythos, with the "efficient frontier" at Opus/Sol.
Your partial quote is quite misleading. The article obviously talks about "efficient frontier", not "intelligent frontier".
>In the AI industry, we borrowed the term “efficient frontier” from economists. We use it to talk about managing tradeoffs, most often the tradeoff between cost and capabilities for models. A model is a “frontier model” if it offers the highest degree of intelligence at a given cost or size.
I'm currently trying to write an inference engine that combines the benefits of llama.cpp (one binary deployment, good support for heterogenous non-datacenter compute, wide quantization support) with the benefits of vLLM/SGlang (things like proper paged attention for better VRAM utilization and high concurrency).
Datacenter hardware is expensive and there's shortage of it but llama.cpp is slow/unoptimized for concurrent use, while vLLM/SGLang easily crash on non-common setups (things like, if you do pipeline parallelism for RTX5090+RTX4090, they will randomly crash with RAM caching enabled or select wrong kernels because they usually assume that every rank is the same device type; they also don't support Q5-Q6).
For me what's most interesting is to optimize inference for lack of good datacenter hardware and how to optimize for it best. I've been running an AI server in the office, and so far I've find these techniques most important for concurrent use on cheap hardware: pipeline parallelism (to accomodate for PCie), RAM caching (to quickly restore contexts into VRAM), speculative decoding (including domain-specific ngrams, they already can speed up code generation considerably without the overhead of a draft model), good kernels highly optimized for a specific device, support for Q5-Q6 (almost as good as Q8), FP8 contexts (more context to fit), paged attention (for better VRAM utilization), prefix caching, continuous batching (this is the default everywhere).
So far the main bottlenecks have been llama.cpp's poor VRAM utilization for contexts (you either have fixed-size slots, or use unified KV cache where each request attends to attention from all other requests and then unnecessary portions of attention are masked out), and lack of decode/prefill segregation: when a request starts prefilling a long context, all decoding threads slow down to like 5 tok/sec. On the other hand, vLLM/SGLang feel superbuggy if you don't run them on some officially approved node like 8xH200
Don’t worry, vllm is also buggy on high end hardware
Instead of creating your own engine, would it really be that hard to add paged attention to llama.cpp?
There's actually already a fork that implements the preliminaries:
https://github.com/ggml-org/llama.cpp/discussions/21961
I’m trying to do the same!
You are not alone, I want to do the same :D
> Speculative decoding is the process of guessing which tokens a model might generate, then validating those guesses.
As a computer engineer, it’s always interesting to see optimizations applied at different levels of the stack.
Speculative execution became pretty popular in the 90s, eventually used in basically every x86 design.
Then in the mid-2000s the Speculator[0] paper brought that concept to distributed systems, which we’re still seeing work on[1][2].
Everything old is new again (:
[0]https://www.cs.princeton.edu/courses/archive/fall07/cos518/p...
[1]https://www.usenix.org/system/files/osdi25-shen-weihai.pdf
[2] https://www.microsoft.com/en-us/research/publication/distrib...
> guessing which tokens a model might generate
A transformer that generates tokens based on pre-training? We could call it a GPT for short.
Yo dawg I heard you liked transformers
RIP Optimus Prime.
Can we expect similar issues such as spectre and meltdown that intel experienced with speculative execution.. but, in the form of prompt injection/poisoning?
No, spectre is based upon speculative execution of code generated by another party. The breach is from the protection stopping that code from doing anything bad. Speculatve execution making things faster by varying amounts is used to turn those differences in timing into a signal.
You could possibly in-pronciple detect what a model with a censorship filter was actually saying, but not really. The signal is weak and needs lots of samples to get anything worth having. You just don't have that level of control to set things up.
Ok, I'll bite: no, considering these are very different domains and you don't get system access by getting the wrong speculative branch for your next text token, you just get a slightly different (but probably still related enough) text.
Speculative decoding is lossless because the main model checks whether it agrees with what the drafter outputted
> you don't get system access by getting the wrong speculative branch for your next text token
I think you could if the client supports tool/MCP calls.
> optimizations applied at different levels of the stack
That's because it's just "guess and check" not some deep universal insight.
It's closer to "we can make this highly parallel for not that much cost, but we struggle to use that concurrency. So what if we just guess what the next step is going to be? If we are right we get a big speedup, if we are wrong we just throw that work away". Which I would classify as a notable insight. Doing work that you are 50% certain is useless is not the most obvious thing
Simple optimizations are often the best :)
This article describes what is usually called a Pareto frontier: the best known achievable trade-offs between two (or more) optimization goals. "Efficient frontier" in common usage seems to be specifically a Pareto frontier for financial risk versus return of an investment portfolio. Even outside of finance, points on a Pareto frontier are called Pareto optimal or Pareto efficient. A Pareto frontier is sometimes shown with more than two dimensions, although usually people will pick just two for simplicity.
Within LLMs, and even inference naturally, there are many other potential parameters that one might optimize: Unsloth typically shows a Pareto frontier for size of a quantized model versus KL divergence. Others trade total concurrent tok/s against single-stream tok/s. KV cache size, context length and context coherency are other trade-offs that are closely related to inference. Total intelligence is usually a defining characteristic of a "frontier model", with cost (per token or task) as a salient trade-off. Cost is one parameter that is implicitly fixed by the "throughput versus latency" analysis: using a GB300 versus Radeon R9700 moves the curve enormously and probably changes the shape of it. Lots of threads here argue over local vs cloud inference regarding cost efficiency, often with privacy and control as competing objectives.
this is a nice and concise writeup. what's striking to me is that these techniques really have not changed in /years/. sure, precision has become slightly lower, spec decoding acceptance has gotten slightly better and the complexity of parallelism is trickier with mixture of experts. but no new concepts in a very long time!
the absolute most impactful improvements for inference comes at architecture design time. I firmly believe everyone who cares about impacting model efficiency should look there
I think the biggest net new recent technique is P/D disaggregation. And that spec dec is very different now especially post DSpark/DFlash.
But overall yes the fundamentals of LLM performance optimization have been remarkably stable over the last few years.
perhaps its unfair to say this in hindsight, but it's a fairly straightforward application of little's law that's been around for some time
https://arxiv.org/html/2401.09670v2
It's also the hardest point at which to try to work, because when you change the model architecture you need to completely retrain from scratch.
[flagged]
I think we can soon include "recursive depth" strategy that Astra is employing, which (I suspect) is using recursive internal state changes in the transformer as opposed to full forward-pass + sampling which has traditionally been the case with thinking/CoT. Similar method was used here (but different context - encoding tools inside the transformer weights for fast execution): https://www.percepta.ai/blog/can-llms-be-computers
2026 has been the year where spec-dec has matured, it has been adopted by all big OSS engines and i'm sure it's present in quite a lot of inference providers as the default
I feel like P/D dissaggregation will be the next big one for providers, as prefill tends to be compute bound while decode mem bound which I guess each will have a different type of node
Quantization and speculative decoding unlocked major savings for our smaller models. Still chasing that ideal cost/performance ratio.
The point is to classify them into two kinds. The kind that shifts the frontier is more powerful, since improves capabilities without incurring tradeoffs.
I also wrote this as somewhat of a defense of the techniques that don't move the frontier -- there is a lot of value in being able to pick a point on the curve.
My daily struggle is trying to make a 7B model respond in under 500ms without breaking the bank. This hits home.
How do you know for sure that you stay on an efficient frontier when you change a parameter?
I think this presentation says more about what knobs you can turn and in what direction the outcome will move (it may be worse than a competitor) than it says about frontiers.
[dead]
My RTX 3090 is still laughing at my attempts to run 70B models efficiently.
You know what I'm curious about? Whether you have brand guidelines inside the company, a Claude skillset, or the blog post author makes the charts in line with the brand colours and so on.
I draw my diagrams on notecards and send them to our designer who brings them to life.
The images start out looking like this: https://philipkiely.com/images/blogs/how-to-write-a-book/des...
Makes perfect sense. The classic way!
Nice read. I was wondering what can one do to get into inference engineering as simple theoretical knowledge is not sufficient and switching profiles is tough for someone with years of experience.
"the efficient frontier" is an important landmark of (investment) portfolio theory. It proves/explains/illustrates how you can combine selections from a diffuse cloud of individual investments and still land on a frontier that is better than any of your individual choices. It's the entire basis of "diversify your portfolio".
The efficient frontier of LLM inference is a line, not a frontier.
this is a frontier:
https://upload.wikimedia.org/wikipedia/commons/e/e1/Markowit...
no matter how good is something a smart person writes down, a pleb will come along and try to hang on its coattails.
If you want to steal an idea for this, steal indifference curves, they'd make more sense.
The authors are referring to a Pareto Frontier https://en.wikipedia.org/wiki/Pareto_front
> The efficient frontier of LLM inference is a line, not a frontier.
The efficient frontier of portfolio theory is also a line. Not sure I get your point here.
not sure i get why you don't get it. why have the word frontier if it doesn't mean something different than other words?
Because... it's an accurate description of the concept it's being applied to?
The author does not deeply mention that quality/intelligence is a third dimension here in addition to throughput and latency, and the frontier is jagged so quality and intelligence require bespoke benchmarks to evaluate tradeoffs for speed and cost.
These are both good points that I attempted to cover, quotes:
> In practice, the efficient frontier is very jagged. Rather than a smooth, continuous line between outcomes, small changes can have big impacts. These cutoff points are often unintuitive and must be discovered empirically through sweeps.
> However, quantization introduces a new set of tradeoffs between quality and serving efficiency. This is a particularly jagged frontier, where a large degree of improvement to serving efficiency is possible with little-to-no reduction in model quality, especially when using microscaling floating-point number formats like MXFP4 and NVFP4.
Would appreciate ideas on how to explain in greater depth
good recap on the recent inference techniques!
[flagged]
[flagged]
[flagged]
[dead]
[dead]
[dead]
[dead]
[flagged]
[dead]
> A model is a “frontier model” if it offers the highest degree of intelligence at a given cost or size.
I would define a "frontier model" as offering the highest degree of intelligence at any cost, or without regard to cost. The frontier today is clearly Fable/Mythos, with the "efficient frontier" at Opus/Sol.
Your partial quote is quite misleading. The article obviously talks about "efficient frontier", not "intelligent frontier".
>In the AI industry, we borrowed the term “efficient frontier” from economists. We use it to talk about managing tradeoffs, most often the tradeoff between cost and capabilities for models. A model is a “frontier model” if it offers the highest degree of intelligence at a given cost or size.