Comment by jetrink
1 day ago
> Tokens become cheaper than tool calls
The author observes that a call to GPT-5.6 Luna is only 4-5 orders of magnitude more expensive than grep, and then predicts that at current rates of progress, calling an LLM will soon be cheaper than a grep. I think this is a good time to invoke Stein's Law: "If something cannot go on forever, it will stop." These efficiency improvements won't continue forever. It's more likely that the per-call cost of high-quality, compiled software like grep will be a lower-bound that LLMs asymptotically approach, rather than a line that they blow past with perpetual exponential progress. (Barring a true breakthrough in something like quantum computing or room-temperature superconductors.)
Yeah I bumped on that too. If it's possible to make llms cheaper than current grep, then it is also almost certainly possible to make grep cheaper.
You can burn anything* into an ASIC to make it cheaper per-call.
non-backreferencing grep is not very difficult to implement in an ASIC either. But it's probably not worth it because of how relatively rarely you use it and of the data transfer costs.
LLMs are great candidates for ASIC-burning because they're slow compared even to network speeds and run all the time. The issue is that you don't want to burn a specific model or architecture that then becomes obsolete.
So you've got two possible futures, and both guarantee large price drops: (a) LLMs keep getting better and better and better, so ability/$ keeps rising; or (b) LLMs plateau in ability, in which they will start getting ASIC'd.
Grep (or ripgrep at least) is i/o bottlenecked at this point. It's impossible to process data at faster than i/o speeds, since you have to get the data to the processor somehow. That doesn't change whether that processing is grep on a CPU, or LLM on an ASIC.
29 replies →
It's almost a certainty that LLMs have a "core" that will essentially never become obsolete, possibly even 80% to 90% of their parameters. The rules of English and other languages, core ideas in math and science, all of history, nearly all literature, etc. We don't really understand what's going on inside LLMs enough yet to make good use of this, but one day we will have "core logic" neural networks with stable weights burned into ASIC that are doing the heavy lifting, with more dynamic continually-tuned models manipulating the inputs and outputs into those core models. There are also likely stable expert models on topics that don't change much that we could already do this with.
Inference costs cannot keep falling forever, but they do still have a long way to go.
1 reply →
> LLMs plateau in ability, in which they will start getting ASIC'd.
They don't need to plateu for that to happen. There are companies already building AI on ASIC, and IIRC they were approach 12 months lead time. A 12 months old frontier model (Sonnet 4.5, GPT-5, Kimi K2) for 1% of the price is still a rather good value proposition.
4 replies →
To be clear, I agree with the overall premise of the article!
But I would probably take a long horizon bet that the grep implementation on my machine will remain cheaper than an equivalent ai task, even though I think those ai tasks will become far cheaper over time.
I just think the original comment's model of asymptotic approach is probably more likely to be accurate than the model of the line blowing through this grep-like cost level.
This whole story really reminds me of crypto coins. Like.. going from mining one coin, or lets say token, to millions of fractions like 0.00000000001 bitcoin a week.
7 replies →
postgres in asic however...
Do you mean most of uses of grep are backreferencing? In my 30-yr career I did not use regex backrefs once except for learning them.
1 reply →
grep is deterministic. Llm is probabilistic. Llm can be transferred to a tiny quantum cpu or a lower precision float.
When the author wrote Llm can be as cheap as a tool, I read it as not equivalent. They even said the Llm can be embedded into a tool.
Their point was, the higher level use case — like classification — could become as cheap as grep. Which is quite well possible.
Yeah you may be right!
depends on what you are grepping ... greapping a large file might be more expensive one day than generating n-th token with LLM that works fully in hardware
you could make hardware implementation of grep and store the file itself next to it in some ROM but that's not a very useful grep ... while hardware LLM is exactly as useful as software LLM only orders of magnitude faster
Yeah it's a pretty poorly specified problem. It needs to be some kind of "equivalent task", but it's not clear how to define that.
4-5 orders of magnitude is huge. Assuming an order of base 10, it's 10000x-100000x. So a call to grep may return in 1s on a typical PC. That means a GPT call takes equivalent energy of 10000-100000 PCs to do the same in 1s. That's a difference that can't be equalized with scaling. It would require a revolutionary breakthrough.
I also don't understand where the idea that frontier models are getting better efficiency comes from. The results are certainly improving, but that comes from feedback and multiplexing requests, which cost more.
Recall the articles claim that efficiency is gaining 2.5 orders of magnitude per year.
Something seems off about this.
LLM is spicy memoizing, so it can potentially be faster than a tool call. But people will spend a month tweaking and testing to ensure they have the level of determinism they need, which means it's more expensive, and that they should have used actual memoization in the first place.
If the providers can't find a way to nickel and dime us to death they will no longer provide the service
A classic case of someone projecting out to infinity from just after the first bend of the S curve.
> The author observes that a call to GPT-5.6 Luna is only 4-5 orders of magnitude more expensive than grep, and then predicts that at current rates of progress, calling an LLM will soon be cheaper than a grep.
At some future point where LLM hardware is cheaper than simply running grep, then grep equivalent would benefit from those selfsame hardware improvements and be cheaper to run as well, probably still by the same ratio.
Well, think that statement through a bit:
Grep reads through the entire file looking for patterns.
An LLM scans its neural net (in ways that I don't understand) which is kinda-sorta like having a huge index.
You can improve over Grep if you have an index; and the LLM has an index.
Thus, it's plausible that an LLM can be more efficient at reading its neural net (IE, index) than Grep reading the whole file.
But if the problem is literally grep (search this file you've never seen before), no index can pre-exist.
If you assume the file arrives ahead of time, can be indexed, and that this is worthwhile because we want to support multiple pattern matched retrievals, then sure it makes sense to consider indexed query schemes and upper/lower bounds. Each query could be faster as an inference if it doesn't have to re-scan the whole file.
But I don't think anybody, in good faith, can pretend that any LLM can digest a file faster than grep can. Particularly, if you admit the vector processing dedicated to doing the convolution kernel(s), you should also admit similar hardware could run a vectorized grep.
The LLM doesn't have an index of every single file I might want to grep, though. In practice it has an index of very few of them, and perhaps even none of them.
It might never beat out grep, but it could beat some more expensive to call tools, similar to how heuristics will often be faster than exact answers. Rust Analyzer can be slow at times, I could see an AI tool taking over a subset of its work.
It's probably better to optimize rust-analyzer first (and now, this became easier). I mean, see rust-glance: it's not feature complete but it points out to different tradeoffs in this space
Right. And some hardware improvements will speed up both grep and Luna, which won't close the gap.
not necessarily, one may be easier to parallelize while the other suffers some serial computation bottleneck.
Grep is trivially parallelizable if you care to do it though.
https://iepathos.github.io/ripgrep/performance/#work-stealin...
2 replies →
A few years is hardly forever and the state of the world here indicates a lot of low hanging fruit still exists.
An LLM can certainly be cheaper than grep, because it’s an approximation, while a grep is deterministic and must examine every byte in what can be a relatively complex state machine for a regex based grep. There are other scales to consider like the scale of your local hardware vs the highly multitenant and high end hardware of the hyper scale inference providers.
There are already high volume models for coding inference where the reasoning time is crazy low and cheap per token where it can build reasonably simple software so blindingly fast it isn’t implausible the bottleneck is the latency in tools and networks. I find them hard to use at times because I don’t have time to think through the next turn by the time it’s done.
Regardless I wouldn’t be surprised to see a world where tokens are so cheap it’s not worth metering them but charging licensing feels with meter tiers at the far horizons to prevent abuse, charge outliers. Subscription models already set this stage well.
The other side to consider is bountiful capacity will also drive tokens to near zero price. The data center build out is barely underway and as it materializes, as hardware efficiencies improve, as techniques and model science and technology improves, harnesses, methodologies , etc improve, the economics flip from load shedding to trying to keep the data centers utilized. The economics lead to the world where tokens are not a unit of measurement for cost for anyone other than the inference providers to manage their utilization.
> An LLM can certainly be cheaper than grep, because it’s an approximation, while a grep is deterministic and must examine every byte
You mean a grep over terabytes of data vs a LLM with gigabytes of parameters?
If you have so much data, you can use an index to search. It's unlikely that LLMs are going to be cheaper than properly indexed search DBs (which is what we should be comparing them with)
There is no reason to assume that quantum computers would benefit LLMs in particular. Perhaps we could implement LLMs as analog circuits to save energy.
> calling an LLM will soon be cheaper than a grep
From a computational standpoint this is obviously nonsense, but from an attentional one I'm not so sure. It may already be more attentionally expensive to use grep in some cases, such the moment you need to remember a non standard arg. And if this applies for performing a simple http operations, then it certainly applies going up the complexity chain.
What if the tool is more advanced, like an optimizing compiler: `g++ -O3 -march=native -x c++ - <<EOF ... EOF`
If the compiler invocation is sufficiently slow, the llm could consider outputting a binary directly?
For all we know matrix multiplications are a faster way to generate optimized machine code than branchy sequential compiler code with tons of heuristics and passes.
> For all we know matrix multiplications are a faster way to generate
“are” or “could be”?
> Barring a true breakthrough in something like quantum computing or room-temperature superconductors
Won't that also help grep and then move the asymptote down more?
The cost for my employer to employ me is only 4-5 orders of magnitude over that of the snack in the vending machine…
room-temperature superconductors, sure, but I fail to see how quantum computing will disrupt – in the medium term (25 years or so) – classical computing in any meaningful way
Is running LLMs (or some other ML workload) on/with quantum computers expected to bring efficiency gains?
But grep is just a tool in a pipeline between a question in your brain and an answer you are searching for.
what if an LLM finds the answer early?
grep might continue to read everything, doing the wrong thing correctly.
"Did you know that disco record sales were up 400% for the year ending 1976, if these trends continue...AY!"
AY-3-8913?
I think it's an interesting thought experiment: could an LLM call be a "cheaper" grep?
Especially for deterministic activities it just feels impossible to imagine general LLM tech handling the problem better, despite everything being said.
But hey, tech is filled with "smashing the generalist hammer works better than the specialized tooling". Would be odd though!
One thing that's easy to miss about performance is that it depends on framing.
An example I like to give: optimizing a data processing program's runtime by 5x is obviously 5x speedup for everyone. But if, for some reason[0], this means it crashes and restarts more often, it stops looking like this to end users. If every restart means it needs to start from scratch, and it restarts 10 times on average now where it didn't restart before, the 5x speedup suddenly looks like 2x slowdown to end user.
In this sense, LLMs are already much more efficient than most CLI tools, by a combination of:
- User not having to remember the exact invocation, or even the name of the CLI tools
- LLM being able to run the CLI tools and chain them on its own
- LLM being able to self-correct in case it got things wrong, or when actual output show that user's idea was right, but the instructions were wrong
Prompting "okay, list those processes sorted by runtime and match them against these output files" is both faster to type than the actual commands, it also end-to-end completes much faster than doing it by hand.
--
[0] - And I don't mean a bug. Say it's some batch processing run on a cluster with aggressive resource usage management; 5x speedup means it runs much hotter than before, which may put it on the top of "kill list" for when the cluster managing code needs to free up some resources.