A purchase-order lever does not need the benchmark to survive contact with production. It needs the internal alternative to be dated and specific. The Broadcom program supplies both: 10 gigawatts of custom accelerators announced in October 2025, racks targeted to start deploying in the second half of 2026, the program running through 2029 [3]. The dev.to analysis is careful to note that those gigawatts are a roadmap and not deployed capacity [4], though a roadmap on this schedule is still enough to price a renewal. From the October 2025 announcement to the end-of-2026 initial deployment OpenAI describes is about fourteen months [19], which sits inside the term of any large GPU commitment being negotiated now.
OpenAI calls the part its first "Intelligence Processor"; the plainer description in the same piece is a custom ASIC for LLM inference, co-developed with Broadcom and turned into boards, racks and production systems with Celestica [1][2]. The narrower job description is the whole argument. A merchant GPU trains and serves; this design targets serving, with attention to memory movement, network delay, and the changing mix of prompt processing and token generation [21].
The mechanism worth reading closely is the pooling decision. Prefill is compute-heavy. Decode waits on memory bandwidth, because the system re-reads weights and the KV cache on every token [10]. Split your fleet into a prefill pool and a decode pool and the ratio is only correct while traffic matches the plan, and prompt length, output length, cache-hit rate, concurrency and speculative-decoding acceptance all move through the day, so a fixed split leaves one pool idle while the other queues [15]. OpenAI runs one flexible accelerator pool instead [14], accepts some local inefficiency to keep every device available for the next request, and avoids shipping a growing KV cache across the network between phases [16]. Cores and HBM are organised into local slices so software can place weights and KV state near the compute that needs them [11], a dedicated collective network carries the known high-bandwidth traffic between slices [12], and support for smaller matrix shapes avoids the padding and utilisation cliffs of large systolic arrays [13]. That is co-design in the literal sense, and it is good work.
It also tells you what the benchmark is a claim about. OpenAI reports strong latency and performance per watt on three large models [7]. For that to transfer to someone else's fleet, that fleet would need OpenAI's model set, OpenAI's prompt and output length distribution, and OpenAI's cache-hit and batching behaviour, because the pooling and slicing choices are tuned to exactly that traffic. The same source lists what is not yet demonstrated: production-scale economics, long-context agent performance, and fleet reliability [8]. On the published benchmark Jalapeno beats NVIDIA, and the dev.to author declines to call it a better chip than the Blackwell platform on that evidence [6].
Scale is the other thing to check before borrowing the numbers. SemiAnalysis, as cited in the piece, describes a reticle-sized compute die, HBM4 at 15.4 TB/s, and a system connecting 2,048 accelerators across 16 racks [17]. That is 128 accelerators per rack [18]. If your serving domain does not need a 2,048-way collective, most of this architecture is answering a question you do not have.
The procurement read is the durable one. Per the dev.to analysis, the chip gives OpenAI a credible way to move repeated, high-volume inference onto hardware it controls, which changes how it buys GPUs, how much pricing power NVIDIA keeps, and how expensive it is to leave CUDA [9]. Over time the same piece expects a profitable slice of inference to move off merchant GPUs, weakening one part of the software moat [20]. That weakens the moat for OpenAI, which owns both the model and the serving stack, though everyone else still pays the porting bill.
