Operational notes Partnerships

Intel and SambaNova: what you are really buying with an inference accelerator

6 min read

Black and white close-up of the fins of an aluminium heat sink, side-lit against a dark background
An accelerator is judged here too: how much heat it produces, and whether your facility can carry it away.

For a few days now a “strategic deal” between Intel and SambaNova Systems has been circulating, dated around 24 July 2026. We went looking for the document. On that day neither company published anything: Intel’s newsroom holds exactly two pages on SambaNova, from 24 February and 8 April. The only document from those days is the quarterly report Intel filed with the SEC on 23 July. The agreement exists, but it is not from July — and it is not what the label suggests.

Who SambaNova is

Founded in 2017 in San Jose, California, by Rodrigo Liang and Stanford academics Kunle Olukotun and Christopher Ré, SambaNova designs chips and racks to run models where the customer is: in its own cloud, at service providers, or on-premises. It has been raising capital for seven years, and on 8 July 2026 it closed a first tranche of $1 billion at an $11 billion valuation.

What was signed, and when

On 24 February Intel’s headline reads: “Intel and SambaNova planning multi-year collaboration for Xeon-based AI inference”. A “planned” collaboration, three areas: SambaNova’s cloud on Xeon infrastructure, the integration of its systems with Intel CPUs, accelerators and networking, and joint go-to-market. The same day SambaNova unveils the SN50 chip and announces a raise of more than $350 million, with Intel Capital among the participants.

On 8 April the verb changes. “Under its signed agreement”, both write, presenting a heterogeneous inference blueprint: GPUs for the prefill phase, SambaNova RDUs for decode, Intel Xeon 6 as host CPU and “action CPU” for orchestration, tool calls and code execution. Availability is “expected” in the second half of 2026. In the 23 July report SambaNova appears among the products — rack infrastructure demonstrated with Foxconn — not among the foundry activities, where Intel lists Fortinet instead.

So: it is not a manufacturing contract, SambaNova has not been announced as an Intel Foundry customer, and it is not an acquisition. Several outlets have written that the deal followed acquisition talks that came to nothing; the press releases carry no trace of them. And Intel Capital is not new — it led the $150 million Series B back in 2019. Reuters reported $35 million invested in February, taking the stake from 6.8% to 8.2%, and in May the closing of the US antitrust review: figures neither company has published. Value, duration, volumes, exclusivity, intellectual property and any purchase commitments are all undisclosed. One governance detail: on SambaNova’s own website Lip-Bu Tan, Intel’s chief executive, is listed as chairman.

Why an inference accelerator is not a GPU

It comes down to two phases. In prefill the model reads the prompt and builds the key-value cache: everything runs in parallel and the bottleneck is compute. In decode it generates one token at a time and re-reads the weights from memory for every token: the bottleneck is bandwidth, not teraflops. A GPU was born for the first problem. A dataflow accelerator — SambaNova calls it an RDU, reconfigurable dataflow unit — maps the model graph onto the shortest path between compute units, avoiding repeated trips to off-chip memory. Hence the three-tier memory, which keeps several models resident and swaps them without reloading.

The practical consequences matter more than the figures. SambaNova states an average of 20 kW for its rack and compatibility with air-cooled halls: if that number holds in your facility, it installs without moving to liquid cooling. On another page of the same site, for the managed offering, it states 10 kW. These are vendor figures for different configurations: they give an order of magnitude, they do not size a switchboard. The same applies to “five times faster” than a reference GPU.

Then there is the constraint you only see later. On non-GPU hardware a model runs if the vendor’s compiler supports it. SambaNova’s public cloud catalogue currently lists four production models — MiniMax-M2.7, DeepSeek-V3.1, Llama 3.3 70B, gpt-oss-120b — and two in preview. On a general-purpose GPU, in practice, everything that ships will run.

What buyers are betting on

On 8 July, from Paris, SambaNova announced that JPMorganChase has selected it as an inference infrastructure partner, deploying SN40 and SN50 systems on-premises. Read it literally: the headline says “deploying”, while the quote from CIO Infrastructure Platforms Darrin Alves says the bank is “looking forward to testing its speed and security”. JPMorganChase has issued no release of its own: the source is SambaNova.

Anyone signing an order is betting on four things, and they belong in the contract. The software stack: the value of the hardware depends on a proprietary compiler and on the models the vendor chooses to support. Spares and updates: custom silicon means a single manufacturer, no second-hand market, no second source. A change of strategy or ownership: a shareholder that has already weighed buying the company it holds a stake in is a material fact for an installation meant to last five years. Reversibility: a general-purpose GPU costs more per token but runs almost anything and can be resold; a dedicated accelerator is worth exactly as much as its ecosystem.

Europe and Italy

The sovereign AI providers listed by SambaNova are Argyll in the United Kingdom, Infercom and OVHcloud in the Union, SouthernCrossAI in Australia. No Italian one. Anyone here who wants compute capacity depends on Californian design, Asian manufacturing and foreign integrators — and on a national capacity where announced and available are not the same thing. On the opposite front, the march of open models towards ordinary hardware — DeepSeek V4 Flash on a machine costing a few thousand euros — cuts every month into the set of cases that genuinely need a dedicated accelerator. Between the two roads the difference is not cost per token: it is the cost of changing your mind, the same question as with licences — if the rules change, what happens to what you have already installed?

The operational lesson

  1. Ask for the text, not the headline: “planned collaboration” in February and “signed agreement” in April are two different things, written by the same companies six weeks apart.
  2. Put the model catalogue in the contract: which models run today, what commitment covers future ones, and what happens if yours is no longer compiled.
  3. Write down end of support and exit: spares, firmware and compiler updates, source code escrow, termination on a change of control.
  4. Measure on your own workload: tokens per second, kilowatts and cost per million tokens are verified on your models, not on the vendor’s datasheet.

The hardware choice matters, but it is not what makes an installation governable. What makes it governable is an environment under the customer’s control: dedicated, closed models, detached from the open web, in an architecture that stays verifiable — on-premises in the customer’s environment, or on a dedicated cloud reserved for the single customer, with a dedicated VPN, data centres in Italy and premises staffed by us.

Do you need to assess an offer of dedicated AI hardware, or decide between an accelerator and a general-purpose GPU for models kept in house? Let’s talk it through in thirty minutes.

Sources