Jalapeño 讓 OpenAI 變晶片公司

我拆 OpenAI 和 Broadcom 的 Jalapeño，看看模型公司怎麼一路往自研晶片和 full stack 走，順便給你可直接套用的決策模板。

我看 OpenAI 講算力這件事很久了，老實說，一直有種「話講很滿，落地很卡」的感覺。模型一版接一版，接著就開始喊瓶頸、買 GPU、談供應、講 full stack。聽起來都對，但真正麻煩的是：如果你在 inference 上燒算力燒到失控，永遠靠買現成加速器，最後就像在租別人的天花板。這件事一直卡在我腦袋裡。

所以當 OpenAI 跟 Broadcom 終於把第一顆合作晶片命名成 Jalapeño，我就懂了。這不是單純「我們做出更快的晶片」而已，而是 OpenAI 在講：我想把更多把模型需求變成產品交付的那層 stack 握在自己手上。這跟「我只負責訓練模型，供應鏈自己跟上來」是兩種完全不同的姿態。我看過夠多基礎設施團隊了，這種話一出來，通常不是因為 keynote 需要氣勢，是因為 spreadsheet 已經開始咬人。

而且這顆 chip 名字真的很鬧，但這個動作不鬧。

外部錨點我抓的是 CNBC 記者 David Faber 與 Kif Leswing 的報導，裡面直接點到 OpenAI president Greg Brockman、Broadcom CEO Hock Tan，還有時程、用途與合作方式。來源有講清楚，我就照著拆，不自己亂補數字。

這不是在拼訓練聲量，是在盯 inference 成本

“The chips will be made by Broadcom and used by OpenAI for inference, the compute-intensive process of serving its AI models to users in ChatGPT and other applications.”

白話翻譯一下就是：OpenAI 不是在為了訓練炫技，而是在為了把模型穩穩送到使用者手上而優化。訓練很容易拿來講故事，inference 才是每天都在燒錢、燒延遲、燒穩定性的地方。每一次回應、每一次 agent step、每一次重試，都是算力在流血。這個帳不是一次性的，是持續性的。

我自己也踩過這種坑。團隊前期只盯模型品質，覺得只要效果夠好，後面都能補。結果六個月後，真正痛的不是分數，是 latency、throughput、還有每千次請求的成本。模型是好的，帳單很醜。Jalapeño 這種動作，讀起來就是 OpenAI 終於承認：真正有槓桿的地方，不是在 demo，而是在 serving。

Broadcom 在這裡的角色也很關鍵。它不是來做什麼「AI 概念股合作」的，它本來就吃 custom silicon 這一套。這家公司最擅長的就是做出很像為特定工作負責的晶片與系統，不去假裝自己要通吃所有 workload。你要看它的官方脈絡，從 Broadcom company page 和 products 入口就很清楚，雖然很無聊，但無聊正是重點。

實操寫法很簡單：如果你在做 AI 產品，別只看 model quality。把 inference cost per 1,000 requests、median latency、p95 latency、記憶體壓力、以及有多少流量其實是在用通用算力做重複工作，全都拉進同一張表。重複性越高，越像是 specialization 的候選人。

• 把 training economics 跟 serving economics 分開算。
• 找出產品裡最常重複的 inference path。
• 問自己：通用硬體是不是在做很多不必要的事。

OpenAI 要的是整條鏈，不只是模型權重

“Jalapeño is a major step in OpenAI’s plan to ‘build the full stack behind its models and products,’ according to the press release.”

這句話才是重點。full stack 這詞大家都愛亂用，但放在這裡意思很直白：OpenAI 想管的不只是一個 API，而是晶片、系統設計、部署路徑、產品體驗，最好都能在同一個控制範圍內。這跟幾年前那些大型科技公司開始自研晶片的理由其實很像。當你的軟體變成基礎設施，你就會開始反過來替硬體定規格，而不是等市場給你一個「差不多可以」的答案。

我看過 cloud 團隊走這條路。先租，接著優化，然後某天突然發現 vendor 的 generic 解法在小規模時很好用，到了大規模就開始不夠精準。然後你就會問：我們為什麼還在為這種「差不多」付錢？OpenAI 現在看起來就是走到這一步，只是它的規模大到讓一般人的 infra 痛點都像零錢。

如果要看官方語境，OpenAI 的產品與系統敘事可以從 OpenAI 官網 去對照。硬體這邊則是 Broadcom 的 custom silicon 能力在背書，不是什麼抽象 AI 口號在撐場面。

實操寫法是：把你自己的 AI stack 從 model selection 到 serving path，再到 infra contract 全部畫出來。然後只問一個很刺耳的問題：我是不是一直在接受別人的預設值，因為我根本沒算過？很多時候答案會是「對，全部都是」。那就代表 stack 在漏錢，也在漏控制權。

• 盤點你依賴但不控制的系統。
• 找出 vendor defaults 如何形塑產品行為。
• 分辨瓶頸到底是 code、硬體還是採購。

九個月做出來，代表他們想壓縮的是迭代速度

“OpenAI President Greg Brockman told CNBC’s David Faber on Wednesday that the chips were designed from end to end in nine months with help from the company’s AI models.”

翻譯一下就是：這件事不是 AI 神奇地自己設計晶片，而是 OpenAI 用自己的模型去壓縮了設計流程的一部分。這很務實，也很可怕。因為一旦你把設計週期縮短，驗證就快、修正就快、錯誤不會拖到發霉。在硬體世界，時間不只是時間，時間是錢、是供應鏈、也是產品窗口。

我之前也看過類似的事情，只是縮小版。團隊用自動化去縮短系統設計 review 的繁瑣步驟，目的不是讓工具取代工程師，而是讓工程師少花時間在排版、搬資料、整理簡報上，把腦力留給真正難的決策。Jalapeño 這件事本質上也差不多，只是它把這個 loop 放大到 silicon 層級。

如果你要看更大的對照組，Nvidia 仍然是 AI 加速器的參考點。官方網站是 nvidia.com。我不是在說 OpenAI 要取代 Nvidia，我是在說它想少一點被任何單一供應商卡住的時間。

實操寫法：把你工程流程裡慢到不合理的部分抓出來，分辨它到底是「本質上難」還是「只是手動」。能用模型、腳本、automation 壓縮的，就先壓縮。硬體世界裡是 simulation、design assist；軟體世界裡就是 test generation、config drafting、deployment scaffolding。

算力不夠，才是這筆交易最真實的商業語言

“Brockman told CNBC that OpenAI ‘cannot get compute fast enough,’ and Broadcom CEO Hock Tan backed up that take, saying compute demand from the company’s six customers is ‘simply insatiable.’”

這段幾乎把整件事講穿了。算力不夠，供應不夠，需求永遠比下一批硬體跑得快。你一旦聽到買方跟賣方都這樣講，就不要再把它當成科技新玩具了，這是容量管理問題。

報導裡也提到 OpenAI 已經跟 Amazon Web Services、AMD、Cerebras 有合作，再加上對 Nvidia 的高度依賴。這不是猶豫不決，這是典型的多供應商拼裝。當需求長得比供應快，單一來源根本不夠用，最後你只能把供應鏈湊成一個可運作的組合。

我在平台團隊看過太多次這種演變。先是主力 vendor，接著使用量爆了，然後採購開始介入，最後架構變成多 vendor，不管大家喜不喜歡。等到你開始管理供應商，你其實已經不是在選工具，而是在管理稀缺。

實操寫法：如果你的 AI workload 只押一個算力來源，先做第二條路，別等出事才補。這不是什麼保險套比喻，是因為供應限制真的會改變你的 roadmap。當產品排程要看某一家廠商 allocation，你的 roadmap 就不完全是你的了。

• 找出算力 stack 裡的單點故障。
• 替關鍵 workload 準備備援路徑。
• 把供應延後一季的情境先算進去。

ASIC 會更不靈活，但那正是它值錢的地方

“The chip with Broadcom is an ASIC, which industry experts say is less flexible than Nvidia’s GPU, but is also less expensive and can be designed for specific AI tasks.”

白話就是：你拿掉彈性，換來效率。你不再逼硬體當萬用答案，而是讓它把某一個固定工作做得很漂亮。這種東西平常看起來不性感，但在規模夠大的時候，最值錢的常常就是這種不花俏的選擇。

這也透露出一件事：OpenAI 相信自己的一部分 inference workload 已經夠穩定，值得被專門做成硬體。如果工作負載夠重複，專用晶片確實能壓成本、拉 throughput；如果你的 workload 每週都在變，custom silicon 就是陷阱。所以這不是「要不要自研」的問題，而是「哪一段已經不太會變」的問題。

我看過最常犯的錯，就是太早客製化。最後做出一台很漂亮的機器，但產品已經換方向，機器還在原地等。真正的判斷不是「全部都客製」，而是「把已經停止變動的那段拿去客製」。OpenAI 看起來是在賭 inference 的形狀已經夠穩了。

如果你想看這種硬體類別的官方背景，Broadcom 的 semiconductor 產品頁 是最直接的入口。GPU 端則仍然是 Nvidia 當對照組，因為大家都拿它當通用 AI accelerator 的基準。

實操寫法：在你碰 custom hardware 之前，先回答三個問題。這個 workload 夠重複嗎？性能目標夠穩嗎？通用硬體的成本，現在是不是已經比 specialization 更貴？三題都答是，才有資格往下談。

時程還很長，這代表它現在只是路線圖，不是魔法

“A physical sample of the new chip will be delivered to OpenAI on Wednesday. The companies said they’re aiming for initial deployment of the Jalapeño chips by the end of 2026, ‘expanding in the years ahead.’”

這裡最容易被過度解讀。拿到 sample，不等於量產。2026 年底開始 initial deployment，也不等於算力問題解完了。這只是表示他們有路徑，接下來才是最慢的部分。報導還提到 Hock Tan 預期小型 prototype 會在 2026 年底，2027 年擴大，2028 年上半年才會進入比較完整的 ramp。這是長跑，不是煙火。

白話翻譯就是：這顆 chip 很重要，但 operational 上它還在尷尬期。這很正常。硬體就是這樣，封裝、驗證、整合、部署、失效分析，沒有一個會因為你發新聞稿就自動加速。

我反而喜歡這種誠實。它沒有講成「晶片一出，問題全解」。它講的是「這是多年容量計畫的第一步」。這種講法比較像真的在做 infrastructure，而不是在拍廣告。

實操寫法：如果你也在規劃自訂 infra，請把時間表寫老實一點。sampling、testing、integration、rollout、fallback 全部列出來。你如果講不出這些階段，那你不是在設計系統，你是在做白日夢。

可抄的模板

# 自研 AI 晶片 / custom infra 決策備忘錄模板

## 1) 我們到底在解什麼問題？
- 工作負載：
- 現在卡住的點：
- 為什麼現成硬體已經不夠：

## 2) 什麼情況下專用化真的有幫助？
- 每次請求成本：
- 延遲：
- 吞吐：
- 功耗：
- 產品控制權：

## 3) 哪些地方還必須保留彈性？
- 還在快速變動的模型家族：
- 不能鎖死的 serving path：
- 自研硬體延遲時的 fallback：

## 4) Build vs Buy
- 可選供應商：
- 到 sample 的預估時間：
- 到 production 的預估時間：
- 整合風險：
- 如果 workload 變了，怎麼退出：

## 5) 時程
- 設計開始：
- 第一輪 simulation / prototype：
- sample 交付：
- 限量 rollout：
- production ramp：

## 6) 成功標準
- 成本下降幅度：
- latency 目標：
- 穩定性目標：
- 容量目標：
- 擴大部署的決策門檻：

## 7) 最後只問一句
如果下季需求翻倍，這個硬體方案是在幫忙，還是在把我們困住？

這版我自己會直接拿去開會用。它逼你把那些「策略對齊」的空話收起來，直接面對現實：到底值不值得做、多久能做完、做完之後是不是還有用。

來源致謝：原始報導來自 CNBC，網址是 https://www.cnbc.com/2026/06/24/openai-and-broadcom-reveal-jalapeno-first-ai-chip-in-partnership.html。我這篇的拆解、語氣、判讀框架跟模板是我自己整理的，事實與引言來自原始報導。