Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's kind of insane how having this tech at this speed 5 years ago would have probably still been seen as insanely useful and revolutionary. If LLMs were more capable but dramatically slower, I wonder how it would impact how we use it? Dramatically more thought being put into prompts, much more preparation probably
 help



The future of inference is likely in ASICs, so we'll get the inverse, a bit less capable than frontier but super fast models. Like this 14k tok/s beast https://chatjimmy.ai/ from Taalas (who got acquired by AMD recently).

GPT-6-astra runs at like ~40 tok/s, I have a hard time imagining what could be accomplished with that type of model at 10k+ tok/s when in the hands of the public. Will certainly make cybersecurity a challenge for older systems.


This is incredible! Are there other big players in this space (freezing models to silicon)?

take a look at Cerebras, who are doing wafer-scale compute

I imagine Astra is/will soon will be on Cerebras?

Nope, OpenAI partnered with Broadcom to produce their own chips and the performance/watt looks good

Is it definitely out of the question?

https://openai.com/index/cerebras-partnership/


Like how crypto used ASICS but then didn't because the scaling of consumer hardware made it obsolete?

To the extent that cryptocurrency moved off ASICs, it was because of interest shifting to different cryptocurrencies that were specifically designed to be harder to mine on an ASIC than Bitcoin's compute-heavy, memory-light hashing.

I'm not sure there's any reason to expect a similar shift from LLMs. The hardware used for training doesn't dictate what hardware needs to be used for inference, and nobody's going to design an LLM architecture with an overt intention to make it better suited to GPUs and hard to target with ASICs.


Yet it doesn't seem that ASICs will have any particular advantage over consumer hardware since AI is very memory heavy, which is (right now) expensive no matter how you package it. And the compute is just simple matrix multiplication, which is almost entirely what GPUs were meant to do anyway.

ASIC vs GPU doesn't make a ton of difference when both are relying on commodity DRAM; in that sense, LLMs are more like the anti-ASIC cryptocurrencies. But the actually interesting ASICs are the ones that ditch the commodity discrete DRAM chips. They lose out on the memory density and thus struggle to scale up to the largest models, but for what does fit onto a Cerebras wafer or a Taalas chip, the speed is phenomenal. They have a real shot at securing the "smart enough, and really fast" segment of the market.

And it seems more plausible to me that an ASIC architecture rather than GPUs would be able to best make use of something like wafer-bonded custom memory to approach the density of discrete DRAM while retaining the extremely high bandwidth that comes with arbitrarily wide interfaces and minimal PHYs.


Go back and correct your idea that consumer hardware made asics obsolete. Then we can figure out if asic or asic like devices for inference will have no advantage.

Except Taalas is much faster than GPUs, orders of magnitude so. They aren’t going to get 100x faster at inference any time soon!

There's a new SOTA model every few months, are you supposed to buy a new chip every new release?

Yeah! Nobody needs chatjimmy.ai. Nobody needs their results to come back instantly instead of at 10 tokens per second. Nobody needs a CPU faster than a megahertz.

This is factually wrong no? Bitcoin is asic only. The others all changed for other reasons unrelated to your thought.

My thought was that ASICs turned out not to be worth it for crypto mining because consumer hardware evolved fast enough to do it, while also being cheaper and having some resale value, while ASICs are useless besides mining and have no resale value.

So I'm extrapolating this same idea to LLM inference.


For the problems ASICs exist they vastly outperform general hardware. Typically both in absolute speed and efficiency.

But it's only possible to make custom ASICs when you have a specific problem to solve. For newer crypto systems they can vary enough parameters that building a flexible enough ASIC to recoup the investment before the algorithm changes and makes your hardware useless.

For problems where the problem to solve remain in the problem space the ASIC can solve there is no point to use a thing else.


You’re extrapolating on something that is false. Consumer hardware never caught up to asic.

Am I missing some joke here?

x86 has a built in instruction for doing AES. That's just moving the ASIC into the CPU core, not eliminating it.

Is there any cryptocurrency that uses AES?

I hate the word crypto, very ambiguous. In my professional life it almost always refers to cryptography.

At 1t/s it's still faster than humans for a lot of tasks, basically doing overnight what could take humans half a week. Plus you can always parallelize.

This is what people forget when they see slow performance: at 1 t/s it's still roughly the equivalent of having another person work for you at no extra cost besides the initial purchase/sign-on-bonus.

Frontier models are amazing, but what will really be useful for us is having models and hardware so efficient that you can run useful LLMs locally. One of my favourite LLMs to this day is still my jail-broken gemma4 12b because it's small enough to run on my computer, but also 100% local and free as in liberty.


How are you running it, if I may ask?

How am I running a jailbroken gemma 4? It's fairly easy to convince to disregard its previous policies with a slightly tweaked, generic SYSTEM prompt.

> At 1t/s it's still faster than humans for a lot of tasks

Which tasks? I think you're underestimating how token hungry current proposed workflows are.


Anything you do right now? A typical 10 minute prompt "simply" becomes about 7 hours long. (40t/s vs 1t/s).

I don't really do anything at my job that could be done in a single prompt, and certainly not something that would take me 7 hours. A 7 hour task would take multiple iterations with how LLMs are right now.

You said it would do overnight what would take a human half a week, so I'm curious what tasks you are doing where AI is 3x faster than you even at 1t/s


you could give it an entire spec, let it rip through everything that it is assigned and let another model correct the failures. Or similarly there's uses as well as an asynchronous adversarial review agent which basically ends up being an extra pair of "hands" to help out where performance isn't critical.

Your prompts are probably very underspecified then. Frontier models one shot the majority of my prompts. UI is kind of the exception, there I do have to ask for a lot of tweaks.

Maybe. Do you have an example of a prompt you've done recently?

I don't think it's valuable at all to try and craft a specific prompt to "one-shot" a task, I'm way faster just doing small asks and guiding it. At 1t/s, how would you even know your prompt was insufficient? It would take you 7 hours to see it.


Stuff along the lines of implement controller service and tests for the following endpoints:

- list of many endpoints with the JSON they receive and return and description of what they need to achieve

Stuff you could probably do in a single work day if you lock in and enter flow state, but in a typical job takes like half a week. And the vast majority of times the AI one shots it with no bugs, where I would have copy paste errors or dumb stuff I'd need to fix before it's shippable.


Like I said, in my experience I would rather do this with a bunch of tiny prompts than try to craft something that oneshots it. Chances are it will do several things I don't want, no matter how clear I think I'm being.

why need frontier model for this?

Why not? It makes less mistakes and with subscriptions it's very cheap

Doesn't matter which task. Compare it with about 40-50t/s an LLM oneshots with, and it, and whatever task now takes X time, takes X * 40-50 with this.

I would agree, but I want to add that I have real issues with combination of opencode plus slow inference (4-5tok/s).

I get weird interruptions. I can only guess its related to some kind of timeouts in the harness or something.

Its not a problem of the model of course, but it seems impractical atm.

I wonder if anyone else had this kind of thing happening.


For OSs harnesses this seems like a good thing to point a paid model at fixing if you don't want to dig in yourself?

I might do that myself in the end checked the bug reports and PRs first though, there are a few related, nothing merged yet

I ran opencode task again last night since it's slow and this morning i got a "SSE read timed out"

logs show tokens still streaming in steadily (every 3-4s, 46,818 tokens in) right up to the moment opencode disconnected

opencode cut a response that was actively generating (not a stalled one)


I think pi handles it better

I just tried pi, absolute junk compared to hermes

I dont get it, so for slow inference its:

hermes > pi > opencode ??

or is hermes better in general? habent tried it hermes/pi yet


My parents learned to program on punch cards. They told me it was a day of preparing the program, an hour of running it, just to get a syntax error.

Write the program, punch the cards, send the cards to another building to be loaded, program runs, printout comes out in another building, somehow this takes 2-3 days

Coding is the new punch card slots now. My children will listen in awe about how typing and testing used to take hours or even (gasp!) days.

That's because 5 years ago it was still brand new for a computer to be able to speak English. 5 years later, we have accepted that LLMs can speak English and we expect them to do useful things.

running my own locally. I just set the tasks to start when systems go idle over x. Read and copy only to external drive projects, codes, ect for review. I review the reports the changes and apply them myself or correct them. Is it slower than say throwing it into fable yes. But I don't have to be monitoring it 24/7



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: