OpenAI's Jalapeño — a systems analysis of the first inference-chip results.

On August 25, 2026, OpenAI published first performance results for Jalapeño, its custom inference accelerator built with Broadcom (announced June 24, 2026). This is not a product review. It is a graduate-level reading of what the numbers actually claim, why the benchmark is constructed the way it is, and where the argument needs more scrutiny than a press release gives it. We derive the prefill/decode roofline problem the chip is architected around, formalize the throughput–latency Pareto frontier the benchmark reports against, work through all twelve published data points (three models × four metrics) with unit-consistent arithmetic, use Little's Law to explain why the "throughput at matched previous-best latency" comparison is the analytically correct one rather than a marketing trick, and close with a methodological limitations section — the part a press release does not include, and the part a defense committee would ask about first.

1. What Jalapeño is, precisely

Jalapeño is OpenAI's first Intelligence Processor — an ASIC designed jointly with Broadcom, purpose-built for large-language-model inference rather than training. It was announced in June 2026 as the first accelerator in a multi-generation compute platform; the August 25 post is the first disclosure of measured performance rather than architectural intent. Two facts anchor everything that follows, both stated directly by OpenAI:

• Jalapeño's package is rated at 700 W, and its measured sustained power stayed at or below 550 W across the tested workloads — a gap between rated and observed power that matters for how the efficiency numbers should be read (§7).
• The chip went from architectural concept to tapeout in nine months, roughly a third of a typical ASIC development cycle, with OpenAI's own models used in the design loop (§8).

Independent reporting (Tom's Hardware, corroborated by SemiAnalysis's own analyst coverage) describes a package built from a reticle-sized compute die on TSMC's N3P node paired with a separate N3E I/O chiplet, six HBM4 stacks, and two structural dummy dies for mechanical balance during packaging. These architectural specifics are third-party reported, not disclosed in OpenAI's own post — we flag that distinction throughout, because conflating vendor-confirmed numbers with analyst-reconstructed ones is exactly the kind of sourcing error a technical reader should not make.

2. The problem Jalapeño is architected to solve

To evaluate an inference accelerator rigorously, you first need the workload model it targets. Transformer-based LLM inference has two structurally different phases, and this asymmetry is the entire reason inference chip design is a distinct discipline from training chip design.

2.1 Prefill and decode sit on opposite ends of the roofline

The standard tool for reasoning about this is the roofline model (Williams, Waterman & Patterson, 2009): a kernel's achievable performance is bounded by

\[ P_{\text{attained}} = \min\!\big(P_{\text{peak}},\; I \cdot BW_{\text{peak}}\big) \]

where \(P_{\text{peak}}\) is the chip's peak compute throughput (FLOP/s), \(BW_{\text{peak}}\) is peak memory bandwidth (bytes/s), and \(I\) is the kernel's arithmetic intensity — FLOPs performed per byte moved from memory. A kernel is compute-bound when \(I\) is large enough that the compute term dominates, and memory-bound when it is not.

• Prefill (processing the prompt) computes attention and MLP layers over many tokens at once. Because the same weight matrices are reused across a long sequence of tokens in a single batched matrix multiply, arithmetic intensity is high — prefill is compute-bound. This is why prefill throughput scales well with more FLOP/s.
• Decode (generating the response, one token at a time) performs essentially a matrix–vector product against the same weights, plus a read of the entire KV cache accumulated so far, for every single output token. The compute-to-bytes-moved ratio collapses — decode is memory-bandwidth-bound. This is why decode throughput scales with HBM bandwidth, not FLOP/s, and why the per-token latency (see §3) rarely improves just by adding more compute.

A chip optimized purely for prefill (peak FLOP/s) leaves decode-phase bandwidth on the table, and vice versa. A general-purpose GPU built primarily for training — which is almost entirely compute-bound, large-batch matrix multiplication — inherits a compute-heavy design point that is not the correct operating point for decode-dominated serving. This is the design tension Jalapeño's own post names directly: "a system that excels at one phase can lose that advantage while waiting for data or moving model state between different resources."

2.2 Two latencies that are not interchangeable

The benchmark numbers in §6 use two distinct latency metrics, and confusing them is the most common way to misread inference benchmarks:

• TTFT (time to first token) — dominated by prefill; how long before the user sees anything.
• TBT (time between tokens, i.e. inter-token latency during decode) — dominated by decode-phase memory bandwidth per active stream. This is the metric OpenAI's appendix reports directly, in milliseconds, and it inverts cleanly: \( \tau_{\text{user}} = 1 / \text{TBT} \) gives tokens/second experienced by one user. We verified this identity against every published pair — e.g. GPT-OSS's 0.69 ms TBT inverts to 1449 tok/s/user against the reported 1,459, a rounding-level match that confirms the reported "tok/s/user" column is derived exactly from TBT, not an independently measured quantity.

End-to-end latency (also reported per model below) is approximately \(\text{TTFT} + N_{\text{out}} \cdot \text{TBT}\) for an \(N_{\text{out}}\)-token response — meaning it blends both phases and depends on response length, which the benchmark holds fixed via a stated 8k-input/1k-output token profile ("nominal 8k/1k").

3. Benchmark methodology: what "Pareto frontier at matched power" actually means

OpenAI evaluated Jalapeño on InferenceX, a public, open-source inference benchmark maintained by SemiAnalysis (formerly InferenceMAX), which focuses on disaggregated serving with wide expert parallelism — the deployment pattern used in production by every frontier lab, not a synthetic microbenchmark. Three choices in the methodology deserve explicit scrutiny before trusting the headline ratios:

3.1 Normalizing by power, not by chip count

OpenAI states explicitly that it normalizes results by each accelerator's published TDP rating, not by chip count, "because we believe the more useful standard is performance per unit of power." This is the correct engineering framing for a data-center operator, whose binding constraint is almost always power and cooling capacity per rack, not the count of physical packages. But it is not a chip-for-chip comparison, and the packages compared are not power-matched:

Model tested	Comparison system	Comparison TDP	Jalapeño TDP (rated)
GPT-OSS 120B	NVIDIA GB200	1,200 W	700 W
DeepSeek R1 670B (MXFP4)	NVIDIA GB300	1,400 W	700 W
Kimi K2.5 1T (MXFP4)	NVIDIA GB300	1,400 W	700 W

Because the comparison systems draw 1.7–2× the rated power of a single Jalapeño package, every per-kW ratio in this article is smaller than the equivalent per-package ratio would be. We keep the analysis strictly in per-kW terms throughout — matching OpenAI's own units — and flag every place where the underlying package-count asymmetry matters for interpretation (see §6.4 for a worked example).

3.2 What "Pareto frontier" means here, formally

A serving system exposes a family of achievable operating points by varying batch size / concurrency: larger batches raise aggregate throughput but also raise per-user latency, because more concurrent decode streams compete for the same HBM bandwidth each round. A system A is said to be on the Pareto frontier relative to system B if there is no operating point of B that simultaneously matches or beats A on both throughput-per-watt and latency. Formally, letting \((T,L)\) denote a system's (throughput, latency) pair at some batch size:

\[ A \text{ Pareto-dominates } B \iff \nexists\, (T_B, L_B) \text{ s.t. } T_B \ge T_A \text{ and } L_B \le L_A \]

OpenAI's claim — "placing it on the Pareto frontier" across GPT-OSS, DeepSeek R1, and Kimi — means that at every batch size tested for the comparison GPU, Jalapeño has some batch size that matches or beats it on both axes simultaneously. This is a much stronger and more falsifiable claim than a single peak-throughput number, and it is the right way to compare serving systems, precisely because throughput and latency trade off against each other and a single-point comparison can always be gamed by picking the batch size that flatters one side.

3.3 The single-benchmark, single-report caveat

InferenceX is open-source and its harness is publicly inspectable, which is a genuine methodological strength over a closed internal benchmark. But as of this writing, the specific numbers in OpenAI's post are self-reported by the chip vendor, on a benchmark run in coordination with a single third-party analytics firm, with no independent reproduction yet published. That is not an accusation of dishonesty — SemiAnalysis has an established reputation for adversarial, vendor-skeptical benchmarking, which is precisely why OpenAI cites them rather than an internal harness — but it is a standing limitation worth stating plainly before the numbers are treated as settled fact (expanded in §9).

4. Package architecture (third-party reported)

The following section relies on analyst reconstruction (Tom's Hardware, SemiAnalysis, WCCFTech) rather than OpenAI's own disclosure, and should be read with that provenance in mind.

• Compute die: reported as reticle-sized (~840 mm², against a ~858 mm² EUV reticle limit) on TSMC's N3P process — i.e., built at essentially the maximum single-die area a lithography tool can expose in one shot, which is the standard way vendors maximize transistor budget per die before resorting to multi-die compute tiles.
• I/O chiplet: a separate die on the older, cheaper N3E node, disaggregating I/O logic (which does not benefit as much from the newest node) from compute logic (which does) — a now-standard chiplet economics move, also used by AMD's MI-series and NVIDIA's Blackwell packages.
• Memory: six HBM4 stacks are reported, with combined package bandwidth cited around 15.4 TB/s — the figure that matters most for the decode-phase roofline argument in §2.1, since decode throughput is bandwidth-bound.
• Two structural dummy dies: silicon with no logic function, included purely to balance mechanical stress across the package during thermal cycling — a packaging detail, not a compute detail, but one that signals the package is pushing toward the physical limits of what can be reliably assembled at this die size.

5. The twelve published data points, in full

OpenAI's appendix reports four metrics for each of three public models. We reproduce all twelve numbers verbatim below before any derived analysis, so the raw evidence is auditable independent of our interpretation.

Model	Metric	Jalapeño	Comparison (GB200/GB300)	Ratio
GPT-OSS 120B (vs GB200, 1,200 W)	Peak mixed TPS/kW	85,448	44,960	≈1.9×
	End-to-end latency	1.03 s	1.80 s	≈1.7× lower
	Min TBT (tok/s/user)	0.69 ms (1,459)	1.87 ms (535)	≈2.7× lower
	Throughput @ prev. TBT (535 tok/s/user)	22,935 mixed/kW	427 mixed/kW	≈53.7×
DeepSeek R1 670B, MXFP4 (vs GB300, 1,400 W)	Peak mixed TPS/kW	19,641	11,781	≈1.7×
	End-to-end latency	1.65 s	5.99 s	≈3.6× lower
	Min TBT (tok/s/user)	1.43 ms (700)	5.90 ms (169)	≈4.1× lower
	Throughput @ prev. TBT (169 tok/s/user)	12,258 mixed/kW	118 mixed/kW	≈104.3×
Kimi K2.5 1T, MXFP4 (vs GB300, 1,400 W)	Peak mixed TPS/kW	18,195	11,862	≈1.5×
	End-to-end latency	1.56 s	5.31 s	≈3.4× lower
	Min TBT (tok/s/user)	1.44 ms (694)	5.48 ms (182)	≈3.8× lower
	Throughput @ prev. TBT (182 tok/s/user)	6,744 mixed/kW	120 mixed/kW	≈56.1×

6. Analysis, chart by chart

6.1 Peak throughput per kilowatt

The "peak" comparison is the least conservative metric — it lets each system pick its own best batch size independent of the other. It's the right first look because it establishes that Jalapeño is not just faster at one point, it has strictly more headroom across the board, but it is the metric most sensitive to which operating point a vendor chooses to report.

6.2 End-to-end latency

Held at the same nominal 8k-input/1k-output profile, this is a fixed-workload comparison — same prompt length, same response length, both systems doing the same amount of work. The gap here is not a batch-size artifact; it's the clearest single number for "how long does a user actually wait."

6.3 Throughput at the comparison system's own best latency point — the headline claim

This is the metric that produces the 53.7×, 104.3×, and 56.1× figures, and it is the most important chart to understand correctly, because those numbers look implausible until you see what they actually hold fixed. The comparison here is not "Jalapeño's peak vs. the baseline's peak." It is: take the per-user token rate the baseline achieves at its own best (lowest-latency) operating point, then ask how much aggregate throughput-per-kilowatt each system delivers while serving users at that exact same per-token latency. Because the baseline can only reach its lowest latency by running a very small batch (few concurrent users, since more concurrent decode streams compete for the same limited HBM bandwidth on that chip), its throughput-per-kW at that operating point collapses — 427 mixed/kW for GPT-OSS, a small fraction of its own 44,960 peak. Jalapeño, with more decode-phase bandwidth per package-watt, can sustain a much larger batch while still hitting that same low latency, so its throughput-per-kW barely drops from its peak (22,935 out of a 85,448 peak).

6.4 A Little's-Law reading of the 53.7–104.3× numbers

Little's Law, from queueing theory, states that for a stable system, the long-run average number of items in a system equals the arrival rate multiplied by the average time each item spends in the system:

\[ L = \lambda W \]

Applied to decode-phase serving, treat each concurrently-generating request as an "item in the system." Then \(L\) is the batch size (concurrency, i.e. number of simultaneous decode streams), \(\lambda\) is the aggregate token throughput (tokens/s across all streams), and \(W\) is the per-token latency experienced (TBT). Rearranged for our purposes:

\[ \lambda = \frac{L}{W} = L \cdot \frac{1}{\text{TBT}} \]

This says aggregate throughput is just concurrency divided by per-token latency — obvious once stated, but it is the identity that explains why the 53.7×–104.3× numbers are so large. Work the GPT-OSS case through explicitly. At the shared operating point (baseline's own min-TBT, 535.28 tok/s/user):

• Baseline (GB200, 1,200 W): reports 427 mixed/kW → aggregate = \(427 \times 1.2\text{ kW} = 512.4\) tok/s total. At 535.28 tok/s/user per stream, implied concurrency \(L_{\text{base}} = 512.4 / 535.28 \approx 0.96\) — the GB200 can barely sustain one concurrent stream at its own fastest per-token speed.
• Jalapeño (700 W): reports 22,935 mixed/kW → aggregate = \(22{,}935 \times 0.7\text{ kW} = 16{,}054.5\) tok/s total. At the same 535.28 tok/s/user, implied concurrency \(L_{\text{Jal}} = 16{,}054.5 / 535.28 \approx 30\) — Jalapeño sustains roughly 30 concurrent decode streams at the exact latency the baseline can only offer to one user at a time.

That is the real content of "53.7× more throughput per kW" — it is a statement about concurrency headroom at fixed per-user latency, driven by the memory-bandwidth-per-watt advantage argued in §2.1, not a claim that Jalapeño executes the same single-stream computation 53.7× faster in absolute terms (peak-to-peak, the gap is the much smaller 1.9× from Fig. 4). Both statements are true and both are published; conflating them is the single easiest way to misquote this result.

6.5 The advantage narrows as models grow — and OpenAI says the opposite happens internally

Look again at the peak-throughput ratios across the three public models: 1.9× (120B) → 1.7× (670B) → 1.5× (1T). Model size and the ratio move in the same direction — larger, wider mixture-of-experts models with more experts (DeepSeek R1 and Kimi are both MXFP4 MoE models substantially larger than GPT-OSS 120B) show a smaller Jalapeño advantage on this specific metric. That is worth sitting with, because it runs counter to OpenAI's own framing: the post states that "in our internal testing, Jalapeño's advantage widened further on frontier OpenAI models, suggesting that the architecture becomes more valuable as workloads grow larger and more demanding" — but that claim is about internal, unpublished OpenAI models, not the three public models actually benchmarked here. The public data trends one way; the internal claim asserts the opposite trend for a different, unverifiable set of workloads. Both can be true simultaneously if internal frontier models differ structurally (e.g., different sparsity ratios, different KV-cache-to-parameter ratios, or longer context windows) from the three public MoE models tested — but a reader should notice that the one claim we can check does not obviously support the claim we cannot check, and should not average the two into a single "gets better with scale" narrative without that caveat.

7. The AI-designs-chip, chip-designed-for-AI loop

Two claims here are structurally different and should be evaluated separately.

7.1 AI-assisted design (verification/EDA acceleration)

OpenAI states its models "helped optimize the chip's arithmetic circuits" and shortened "design, measurement, and verification loops" during the nine-month tapeout. This is consistent with a broader, independently documented industry trend of LLM-assisted EDA (electronic design automation) — using models to explore RTL implementations, accelerate verification-testbench generation, and search circuit-layout spaces faster than manual iteration. The nine-month figure (vs. a typical 24–36 month cycle) is the load-bearing evidence for this claim, and it is a real, externally observable outcome (the chip exists and was announced on schedule), even though the internal attribution of how much of the speedup came from AI-assisted tooling versus other factors (team experience, reused IP blocks, aggressive risk-taking on a first-generation part) is not independently separable from OpenAI's own account.

7.2 A chip designed as a programming target for AI

The more interesting and more falsifiable claim is architectural: Jalapeño is described as exposing computation through local tensors, explicit communication, and predictable synchronization — a programming model chosen specifically because it gives an AI code-generation system (Codex, paired with OpenAI's GPT-Astra) a tractable search space for the notoriously hard problem of parallel kernel scheduling. The reported evidence: using this toolchain, the team brought three open-weight model families that were not part of the original production plan to high performance within two months, and for selected GPT-OSS attention and mixture-of-experts kernel blocks, AI-generated implementations ran 1.5–1.8× faster than the existing human-expert-written implementations.

This closes an interesting loop worth naming explicitly for a systems-research audience: a hardware architecture co-designed to be legible to an AI code generator, programmed substantially by that same lab's coding models, running inference for that same lab's (and others') language models. Whether this compounds into a durable advantage — each generation's chip easier for the next generation's model to program well — is exactly the kind of multi-generational claim that cannot be evaluated from a single first-results post, but it is the strategic thesis the "multigenerational platform" framing (Gen 2 "deep in development," Gen 3 "taking shape") is staking out.

8. Where this sits in the systems-research literature

None of Jalapeño's individual architectural bets are without academic precedent, which is useful context for judging what is genuinely novel here versus what is a first-party productization of ideas already active in the research literature:

• Prefill/decode disaggregation is now the dominant serving pattern in the literature, precisely because of the roofline asymmetry in §2.1 — recent work on cross-datacenter KV-cache transfer (e.g. Prefill-as-a-Service, arXiv:2604.15039) explores decoupling the two phases across loosely-coupled clusters, the opposite instinct from Jalapeño's "keep the whole workload in one connected network domain" design, which trades flexibility for minimizing data movement.
• Topology-aware data movement for disaggregated GPU inference (arXiv:2607.28633) quantifies exactly the bandwidth cliff Jalapeño's single-domain network design is built to avoid — the same paper's own numbers (900 GB/s NVLink-domain vs. 50 GB/s cross-node InfiniBand vs. 12.5 GB/s cross-datacenter) explain why "keeping the entire workload within one connected system," as Jalapeño's post states, is not a marketing phrase but a direct response to a documented two-orders-of-magnitude bandwidth cliff.
• MXFP4 quantization, used for both DeepSeek R1 and Kimi K2.5 in this benchmark, has its own roofline implication worth noting: 4-bit weights roughly quarter the bytes moved per decode step relative to bf16, which directly increases the effective arithmetic intensity of decode and shifts it — partially — back toward the compute-bound region of Fig. 1. This piece of the article's sister post on Kimi K3 (covered in detail here) is directly relevant background for why quantization-aware serving and quantization-aware chip design are now co-evolving rather than independent decisions.
• KV-cache management under memory pressure — the other major decode-phase bottleneck — is the subject of PagedAttention and its successors, covered at length in this site's dedicated deep dive; Jalapeño's "explicitly placed and kept local" KV-cache handling is a hardware-level answer to the same problem PagedAttention solves at the serving-software level.

9. Tokenomics — translating perf/watt into the price of a token

Every ratio in §5–§6 is a hardware efficiency number. None of it is a price. The step from "more tokens per kilowatt" to "cheaper tokens for the buyer" runs through capex amortization, utilization, margin, and competition — and it is worth doing that translation explicitly rather than leaving "more efficient" as a vague gesture toward "cheaper." The box below does the arithmetic with sourced inputs, states every assumption, and separates what Jalapeño's own numbers imply from the broader industry trend it is one input into.

10. Methodological limitations — read this before citing any number above

A defense-quality reading of this result requires naming what is not established, not just what is claimed:

1. Single-source benchmark, no independent reproduction. All twelve data points in §5 come from one OpenAI-published post, using one benchmark suite, run by (or in direct coordination with) one third-party analytics firm. No competing lab or independent academic group has published a reproduction as of this writing.
2. Power normalization masks package-count economics. As shown in §6.4, per-kW ratios and per-package ratios diverge because the compared systems are not power-matched (700 W vs. 1,200–1,400 W). Both framings are legitimate for different purposes (data-center power budget vs. capital/rack-space budget), but only one is reported.
3. "Measured ≤550 W of 700 W rated" is disclosed but not explained. OpenAI states sustained power stayed at or below the 700 W rating on tested workloads without saying how close to 550 W, on which model, or whether the efficiency numbers in §5 were measured at the 700 W rating or at the lower observed draw — a nontrivial ambiguity, since using rated (denominator) power while workloads draw meaningfully less would inflate every per-kW figure relative to a measured-power normalization.
4. Operating-range selection is not fully specified. The benchmark reports results "across the tested operating range," but the criteria for which batch sizes / concurrency levels were included or excluded from that range are not published in the post itself, leaving room for range selection to favor the vendor's own chip (a well-documented general risk in any self-selected benchmark range, independent of any specific claim about this one).
5. Software-stack maturity asymmetry. NVIDIA's GB200/GB300 inference stack (TensorRT-LLM, vLLM integrations, years of kernel-level tuning by a large ecosystem) is far more mature than a first-generation chip's software stack could plausibly be at launch. Some fraction of the measured gap may reflect NVIDIA-stack tuning debt for these particular three models rather than a pure hardware-architecture delta — a confound that narrows, in the vendor's favor, only with time and independent tuning effort on both sides.
6. The internal-model claim is unverifiable. The assertion that the advantage "widens further on frontier OpenAI models" (§6.5) references workloads no external party can test, run on a benchmark no external party can inspect, evaluated against a baseline no external party can confirm was configured fairly. Treat it as a forward-looking claim, not a result.
7. This is a first-generation part pre-deployment. OpenAI states Jalapeño will begin deploying "within OpenAI's compute infrastructure by the end of the year" — meaning every number in this article describes lab/qualification-stage measurement, not production behavior under real multi-tenant load, thermal variance, and failure-rate conditions at scale.

FAQ

Is "mixed TPS/kW" throughput or tokens-per-second exactly defined?

OpenAI's post uses "mixed" as InferenceX's own metric name, understood to combine prefill- and decode-phase token accounting into one throughput figure, but the exact weighting methodology between the two phases is documented in the InferenceX benchmark itself rather than in OpenAI's post — a reader who wants the precise definition should consult the InferenceX repository/methodology directly rather than infer it from this article.

Why does the "throughput at matched TBT" ratio (53.7–104.3×) so vastly exceed the peak ratio (1.5–1.9×)?

Because they measure different things: peak ratio compares each system at its own best batch size (an apples-to-apples "how fast can each system go" comparison); the matched-TBT ratio compares both systems forced to the baseline's best latency, at which the baseline can only sustain roughly one concurrent stream (derived in §6.4) while Jalapeño sustains dozens. It is a concurrency-headroom claim, not a raw-speed claim.

Does this benchmark tell us anything about training performance?

No — Jalapeño is explicitly an inference-only accelerator, and InferenceX is an inference-serving benchmark. Nothing here bears on training throughput, training-scale interconnect, or training numerics.

Is the "1.5–1.8× faster than human-written kernels" claim about the whole model?

No — explicitly scoped by OpenAI to "selected" attention and MoE blocks, not the full model. Amdahl's Law means the end-to-end effect depends on what fraction of total runtime those blocks occupy, which is not disclosed (§7.2).

Takeaways

• The architecture argument is a textbook roofline story: decode is memory-bandwidth-bound, prefill is compute-bound, and a chip co-designed with HBM4, a single-domain network, and explicit KV-cache placement targets both simultaneously rather than inheriting a training-optimized, compute-heavy design point.
• The benchmark methodology (Pareto-frontier, power-normalized, matched-latency) is more rigorous than a single peak number — but power normalization is not chip-count normalization, and the 700 W vs. 1,200–1,400 W TDP gap changes the story depending on which constraint (power or capital) you actually face.
• The headline 53.7–104.3× figures are a Little's-Law statement about concurrency headroom at fixed per-user latency, not a raw single-stream speed multiplier — the raw peak-to-peak gap is a much more modest 1.5–1.9×, and both numbers are simultaneously true and published.
• The Jalapeño advantage narrows across the three public models as they get larger (1.9× → 1.7× → 1.5×), which sits in tension with — but does not necessarily contradict — OpenAI's separate, unverifiable claim about internal frontier models.
• The AI-generated-kernel result (1.5–1.8×) is explicitly scoped to selected blocks, not the full model — an easy number to over-quote, and one that should always carry that qualifier.
• This is one vendor-published post, one benchmark, no independent reproduction yet. Treat the architectural reasoning as sound and the specific magnitudes as provisional until an outside party runs the numbers.

References & further reading

• OpenAI — Jalapeño's first results — the primary source for every measured number in this article.
• OpenAI — OpenAI and Broadcom unveil LLM-optimized inference chip — the original June 2026 architectural announcement.
• Tom's Hardware — package/die reporting — source for the third-party architectural details in §4.
• SemiAnalysis — OpenAI Jalapeño analysis — independent analyst read from the benchmark's own maintainer.
• InferenceX by SemiAnalysis — the open-source benchmark platform used for all measurements.
• Prefill-as-a-Service: KVCache of Next-Generation Models Could Go Cross-Datacenter — disaggregated-serving literature, contrasting design point.
• Topology-Aware Data Movement for Disaggregated GPU Inference — quantifies the interconnect-bandwidth cliff Jalapeño's single-domain design targets.
• cvam.sight — Kimi K3: Architecture and Infrastructure — MXFP4 quantization and KV-cache background used in this piece.
• cvam.sight — PagedAttention deep dive — the serving-software-level answer to the same KV-cache problem Jalapeño addresses in hardware.
• Stanford HAI — AI Index: State of AI in 10 charts — source for the 280×-in-two-years and ≈50×/year inference price-decline figures in §9.
• Data-center power pricing, PUE & hyperscaler benchmarking — source for the $0.0834/kWh US industrial electricity average and 1.09–1.14 hyperscale PUE range used in §9's energy-cost derivation.
• cvam.sight — Frontier Digest #9 — harness-level RL and the agentic control-plane tax, background for the Jevons-paradox caveat in §9.