73x faster than an Nvidia H200, at a tenth of the power — because the model isn't loaded. It's the chip.

Taalas's first test chip serves Meta's Llama 3.1 8B at roughly 17,000 tokens per second — about 73 times faster than an Nvidia H200, at a tenth of the power. On August 6, AMD agreed to buy the company that built it: its third AI acquisition in nine months, after MK1 in November and memory-optimization startup Mext in June.

We've spent five of our last dozen posts on some version of the same problem: a model our engine can't load, because llama.cpp's graph builder doesn't recognize its architecture yet, or because the quant that fits our size cap isn't the one the model card recommends. That's a software compatibility problem. Taalas's entire pitch is that you can make it disappear — not by fixing the software, but by not having any. If there's no runtime negotiating between a generic chip and an arbitrary model, there's nothing left to be incompatible.

What "casting a model into transistors" actually means

Every engine we've written about here — llama.cpp, MLX, CoreML/ANE, Apple's own Foundation Models path — shares one thing in common: the weights live in memory (DRAM, HBM, unified RAM, whatever the device has) and get streamed into a general-purpose compute array on every forward pass. That streaming is the actual bottleneck in most inference workloads; it's why "memory bandwidth," not raw FLOPs, dominates every serious llama.cpp performance discussion.

Taalas's approach removes that step entirely. Instead of storing a weight as a number the chip reads and multiplies, the weight's value is built into the physical dataflow — the wiring itself is shaped by what the number is. Co-founder and CEO Ljubisa Bajic has described the founding idea as building "the hardware around the model" rather than the model around generic hardware. There's no "load weights" phase at inference time, because the weights were never a separate thing from the silicon to begin with.

The test chip, HC1, is a TSMC 6nm part built specifically to serve Llama 3.1 8B, revealed in February 2026. What makes a company like this economically possible at all — rather than a one-off stunt chip nobody could ever afford to iterate on — is a detail buried in the coverage: only 2 of the transformer's 100-plus layers actually differ in physical layout between one model-chip design and the next, because most of a transformer stack is structurally identical block to block. That lets Taalas reuse over 98% of a prior design and cut tape-out time to roughly two months, instead of the year-plus a from-scratch ASIC normally takes. Their next chip, HC2, is aimed at models around 20 billion parameters — inching toward the weight class of specialists already in privateSLM's own catalog, though nowhere near a phone.

Sources: SiliconANGLE, Aug 6 2026; AMD investor relations press release.

The bill nobody put in the press release

AMD's announcement and most of the coverage it generated read like a highlight reel — understandably, it's a genuinely striking number. The Hacker News discussion underneath it is a useful corrective, and worth citing precisely as commentary rather than vendor fact, since none of these figures come from Taalas or AMD themselves:

• One commenter's back-of-envelope math put an 8B model stored directly in silicon (effectively acting as ROM) at roughly 800mm² of die area, versus roughly 80mm² for the equivalent capacity in DRAM — a rough 10x area cost, which on a leading-edge node is a real manufacturing cost multiplier, not a rounding error.
• A separate comment argued that baking a model into the dataflow only buys "moderate gains" on its own, because memory bandwidth — the same bottleneck GPUs fight — doesn't fully disappear just because the weights are physically local; it changes shape rather than vanishing.
• The obvious structural point: a Taalas chip is permanently one model. GPUs stay useful when you want to run a different model tomorrow; an HC1 does not — you're not swapping weights, you're fabricating new silicon, whatever that ~2-month reuse trick brings the cost down to.
• One estimate for what it would take to serve a trillion-parameter frontier model this way — 50 to 100 chips per instance, meaning "thousands of 100-chip fabs" for real deployment volume — is a sharp reminder that this approach was demonstrated at 8B parameters, not GPT-class scale, and the two are not obviously the same problem.
• Commenters trying Taalas's own public demo (chatjimmy.ai) reported it was fast but gave "complete junk" answers on anything involving new facts or slightly esoteric topics — a reminder that raw tokens/second says nothing about what model is actually running or how current its knowledge is.

Where this lands on the spectrum we keep mapping

This isn't the first time we've measured the price of "runs anything" versus "runs one thing, extremely well." Our July 20 post found that on the same iPhone 17 Pro, Apple's own vertically-integrated Foundation Models path beats llama.cpp's GGUF-compatible path by 2.3x in joules per generated token — not because Apple's silicon is exotic, but because a runtime built for exactly one model, with no compatibility surface to maintain, has less overhead to pay for than one built to load whatever architecture a user happens to download.

Taalas is that same force taken to its literal, physical limit. Apple's 2.3x comes from software specialization — one model, one tuned runtime, still running on general-purpose Neural Engine hardware. Taalas's reported 73x comes from deleting the runtime and the memory bus altogether: there is no "compatible" or "incompatible" architecture, because there's no architecture-agnostic hardware left to be compatible with. It's the same curve our engine-compatibility posts have been tracing for weeks, just extended past the point where "software" is even the right word for what's running.

And that's exactly why it's a demonstration, not a threat, to what privateSLM does. An ASIC is a bet on one model at a volume that can absorb a ~2-month tape-out (best case) and the die-area cost a HN commenter estimated at roughly 10x a DRAM-based chip. privateSLM's own catalog is the opposite bet: a generalist plus more than a dozen domain specialists — coding, math, medical, legal, finance, translation, mental health — because most people using an on-device model don't want the single fastest possible model, they want whichever model fits what they're doing right now. Someone can download Nanbeige4.2-3B this afternoon for a reasoning task and BioMistral 7B tonight for a biomedical question; nobody is fabricating a new chip for that swap, and nobody building consumer hardware at iPhone volumes is going to solder in a chip that's permanently one 8B model either.

What actually changes for on-device users

Nothing ships in our catalog because of this — there's no GGUF here, no download URL, nothing to verify. What changes is the baseline for how big the "compatibility tax" we keep measuring can get before an industry player decides it's worth paying $219M-plus to eliminate it entirely. AMD's answer, for datacenter-scale serving of a fixed model, is apparently yes. For a phone in your pocket that needs to run whichever model you actually asked for, the honest tradeoff hasn't moved: you're still going to pay some real efficiency cost for the freedom to choose, and 73x is now the number that tells you exactly how expensive that freedom can get at the extreme end, not the number that makes it disappear.

Discuss this on the forum → — if you've found a model-specific inference chip that ships anything close to phone-scale, or a GGUF-to-ASIC path we haven't heard of, we want to know.