logo
How to…?

Everyone is building an inference chip. Should you use one?


10 mins.
Inference Chip in AI Stack

Table of Content

About the author

Divesh Sood Avatar

Head of Product Marketing

Inference Chip in AI Stack

Table of Content

In two weeks this summer, OpenAI unveiled Jalapeño, its first inference chip, and Reuters reported that DeepSeek is designing one too. Reuters puts Anthropic among the handful of labs doing the same. The big cloud providers already have theirs: Google Ironwood, AWS Trainium, Microsoft Maia. And a dozen startups are selling silicon built for one job, running models: Groq, Cerebras, SambaNova, d-Matrix, Etched.

Why the rush? Inference is now the bigger bill. Deloitte puts inference at about half of AI compute in 2025 and two-thirds in 2026. Menlo Ventures reported 74% of builders say most of their workloads are inference, up from 48% a year earlier. When the recurring cost moves, the hardware follows it.

So the pitch lands in your inbox every week: a specialist chip that serves tokens faster and cheaper than the graphics processing unit (GPU) you are on. The benchmark behind it is usually real. It just may not hold for your workload. That is the catch with specialized silicon.

The right choice is the one that fits what you are actually running, not the one that wins the benchmark. So start with your use case and work back to the silicon.

Serving a model is a different job from training one

Training and inference stress a chip in opposite ways. That is the whole reason inference chips exist.

Answering a prompt happens in two phases. Prefill reads your prompt. It is compute-bound: lots of dense math done in parallel. Then decode writes the answer one token at a time, and it is memory-bound. Every new token reads the whole model and the running context out of memory before it can appear. For most chat and agent workloads, decode is where the time and the cost sit.

That split rewires the spec sheet. For serving, memory capacity and memory bandwidth matter more than the peak training floating-point operations per second (FLOPS) at the top of the page. It is why every 2026 inference part leads with low-precision number formats. FP8 roughly halves what a model weighs. FP4 and INT4 cut it again, so more of the model moves per second. The split is already showing up in production. In July, inference provider Parasail put d-Matrix Corsair accelerators alongside NVIDIA GPUs, running prefill on the GPU and decode on the cheaper specialist silicon.

Memory capacity matters for a blunt reason too. A frontier model may not fit on one chip. Llama 3.1 405B needs about 810GB at 16-bit precision, and the largest single accelerators today hold 288GB. When a model does not fit, you chain chips together and pay for the network between them. That is the memory wall every inference-chip company is really fighting.

The 2026 landscape: a chip for every job

Step back from the logos and the field sorts into four buckets.

Memory-rich GPUs carry the whole model on one card and run anything. The AMD Instinct MI350X and NVIDIA B300 both hold 288GB; the H200 holds 141GB. These are the general-purpose default.

Wafer-scale and dataflow chips trade generality for raw speed on a served model. Cerebras runs a model out of 44GB of on-chip memory. Groq’s language processing unit (LPU) is built the same way: all static memory (SRAM) on the chip, none off it, tuned for fast single-stream decode. SambaNova sits between the two with a three-tier memory design.

Cloud-provider silicon is the big clouds’ own answer: Google’s Ironwood tensor processing unit (TPU) with 192GB, AWS Trainium, Microsoft Maia. You rent it inside their cloud rather than racking it in yours.

Purpose-built ASICs, or application-specific integrated circuits, go furthest. d-Matrix keeps compute and memory on the same chip and skips scarce high-bandwidth memory (HBM) entirely. Etched went further and hard-wired the transformer into the silicon: fast on the models it was built for, useless on anything else.

CategoryExamplesMemoryBest-fit workloadPortability / lock-in
Memory-rich GPUsAMD MI350X, NVIDIA B300, H200141-288 GB HBM3EAny model, general servingHigh. PyTorch/ROCm/CUDA, day-zero models
Wafer-scale & dataflowCerebras WSE-3, Groq LPU, SambaNova44 GB SRAM to multi-tierFast single-stream decodeMedium. Own software kit (SDK), usually a cloud endpoint
Cloud-provider siliconGoogle TPU Ironwood, AWS Trainium, MS Maiaup to 192 GB HBM3EHigh-volume serving in that cloudLow. One cloud, its own toolchain
Purpose-built ASICsd-Matrix Corsair, Etched SohuIn-memory / 144 GB HBM3EOne stable, high-volume modelLow. Etched runs transformers only

Two things are true here at once. The engineering is good, and the independent numbers are closing on the leading GPUs. On the audited MLPerf v5.1 round, the specialist gap to the best GPUs is measured in tens of percent, not multiples. Even so, a GPU still runs any model the day it ships. That is why NVIDIA still holds around 80% of the accelerator market, and closer to 60 to 75% in inference specifically.

Score a serving chip on five things, not one

AxisThe questionWhy it decides your bill
FitDoes the model plus its context fit in memory?If it spills, you chain chips and pay for the network between them
FeedIs there enough memory bandwidth to keep it busy?Bandwidth, not FLOPS, sets your per-token speed on decode
CostCost per million tokens at your batch size?The benchmark’s batch is not the batch you will run
LatencyTime to first token and speed one user feels?The aggregate hides what a person actually experiences
PortabilityCan you move off it?The model you serve next quarter may not run on it

No chip wins all five for every workload. A wafer-scale part may top Latency for one user and lose on Cost at scale. An ASIC may win Cost on a stable model and score near zero on Portability.

That is the point of a scorecard. It stops you buying on the one number the seller chose.

A peak number is measured at a batch size you will never run

The gap between a spec sheet and production comes down to one thing: batching.

A chip hits its peak tokens per second by packing many requests together. That keeps every circuit busy. Your one user gets a slice of it. Here is the same NVIDIA B200, in NVIDIA’s own InferenceMAX numbers, reported two ways.

ModelAggregate, per GPU (the headline)Per user (what a person feels)
gpt-oss60,000 tok/s1,000 tok/s
gpt-oss, speculative decode30,000 tok/s100 tok/s
Llama 3.3 70Bover 10,000 tok/s50 tok/s

Same silicon. The headline is measured where the chip is fullest. You will run where your p99 latency, the slowest 1% of requests, stays inside your service level agreement (SLA). That point is far lower. Push a GPU’s batch size up and throughput can rise 14x while latency gets 4x worse. Run at batch size one to keep a single user fast, and you leave most of the GPU idle. You do not get to pick both ends of that slider.

The other thing the spec sheet will not tell you: software moves your cost more than the chip does. NVIDIA cut a model’s token cost about 5x in a month through serving-stack optimization alone, on hardware that did not change. SemiAnalysis’s InferenceMAX shows the same swing from the latency target you hold the chip to. Four things move your cost per token. Only one of them is the chip.

MoveCost per tokenThe trade-off
Bigger batchesfallsevery user’s answer slows down
Tighter latency targetrisesyou serve fewer requests at once
Better serving softwarefalls sharplythe work is in the tuning
A faster chipfalls a littlethe smallest lever of the four

The chip sets the floor. The software running the queue sets the ceiling. Most teams shop hard for the chip and never touch the software.

The model you serve next year is not the one you serve today

The field is moving fast, and prices with it. The cost to serve a fixed level of quality has fallen roughly 10x a year. To hold a GPT-4 level of performance, Epoch clocks it at up to 40x. A frontier open model lands every few weeks. The one you pick today will look dated within a year.

On a GPU from AMD or NVIDIA, a new model runs from day zero: PyTorch, vLLM and SGLang ship recipes the week it drops. On a chip with its own toolchain, you wait for support. Etched’s design runs transformers and nothing else.

That is the real cost of a specialist chip, and it never shows up on the spec sheet.

When a dedicated ASIC winsWhen a GPU wins
One stable model, served at huge volumeA model roadmap that changes every few weeks
A fixed latency target you tune onceNew architectures you need to adopt day-zero
Cost per token and power are the whole gamePortability and a standard toolchain matter
You can absorb the software and lock-in costYou want to run your model anywhere

If you serve one stable model at massive scale, an ASIC’s cost-per-token and power savings can dominate. That is why analysts expect the largest clouds to move most internal inference to custom silicon by the end of the decade. But it is a bet that your workload holds still, and most workloads move. Teams that keep their options open treat portability as a feature they will use. Tenstorrent has built a whole open-source stack around exactly that pitch.

On a GPU, switching models is a base-image change. On the wrong ASIC, it means buying new hardware.

How to actually choose

Do not start with the chip. Start with the workload.

Write down the model and how big its context gets. Write down your traffic shape and your latency SLA. Now the five axes have values instead of adjectives. Does the model fit? Does your SLA leave room to batch? Is your model roadmap fixed for the next year? The answers tell you whether you are shopping for a memory-rich GPU, a low-latency specialist, or a stable-model ASIC.

Then run your own model on the shortlist. A benchmark deck is measured on someone else’s workload at someone else’s batch size. Yours is the only one that counts.

If you would rather not run the chips yourself

There is a middle path between renting a raw GPU and buying a rack of new silicon: let someone else operate the serving layer. That is what Neysa Velocis offers in India. Managed inference as a service, on dedicated single-tenant endpoints, running on leading AMD and NVIDIA GPUs. Neysa runs the endpoint. You put your model on either vendor and compare cost and speed on your own traffic before you commit.

You do not need to own the chip. You need the right one for the job, run well. Score the five axes, run your model, and leave the headline number for last.

FAQs

Do I need a special chip to run inference?
No. A memory-rich GPU runs any model well and stays the safe default. Dedicated inference chips earn their place when you serve one stable model at high volume and can absorb the software and lock-in cost.

What is the difference between an inference chip and a training GPU?
A training GPU is built for flexibility and raw throughput across forward and backward passes. An inference chip strips out what serving does not need and optimizes for memory, low-precision math and latency. Serving is memory-bound; training is compute-bound.

Is an ASIC better than a GPU for inference?
On a fixed, high-volume workload, a purpose-built ASIC can win on cost per token and power. A GPU wins on flexibility: it runs any model from day zero, which matters when models change every few weeks. See the five axes above.

What is the cheapest chip per token?
It depends on the model, the precision and your latency target, and it changes weekly. Independent trackers like SemiAnalysis InferenceMAX and Artificial Analysis publish live cost-per-token spreads. Cite a specific workload, never a blanket winner.

What is a TPU, and is it an ASIC?
A TPU is Google’s inference and training ASIC. All TPUs are ASICs; not all ASICs are TPUs. You rent TPUs inside Google Cloud rather than racking them yourself.

Can I serve a model without buying any hardware?
Yes. Managed inference services run the serving layer for you on dedicated endpoints and bill you for what you use. For most teams that is the step before committing capital to silicon.


  • How to Implement AI in Business: Building the Case for Smarter Infrastructure

    How to…?

    13 mins.

    How to Implement AI in Business: Building the Case for Smarter Infrastructure

    The article explores the implementation of AI in business, emphasizing the need for a focused roadmap that aligns AI investments with measurable performance outcomes. Key sectors like HealthTech and BFSI illustrate how specific infrastructure investments can directly enhance efficiency and deliver financial returns, transitioning AI from a theoretical concept to a crucial business tool.


  • AI Adoption Roadmap: Finding Your Ikigai in Portability

    How to…?

    12 mins.

    AI Adoption Roadmap: Finding Your Ikigai in Portability

    The content discusses the significance of portability in AI adoption, emphasizing its role in ensuring flexibility, sustainability, and alignment with organizational goals. It outlines various stages of AI implementation where portability aids in managing costs, compliance, and scalability effectively.


  • Enterprise AI: From Experiments to Organization-Wide Systems

    How to…?

    10 mins.

    Enterprise AI: From Experiments to Organization-Wide Systems

    Enterprise AI rarely arrives in a single moment. It settles in gradually. Then, almost without notice, it becomes part of how the organization thinks, decides, and operates. How do you get your enterprise to do this effectively?

SHARE