1. 從“買卡”到“造卡”O(jiān)penAI 為什么會(huì)走上自研芯片這條路1.1 算力賬和成本賬為什么要自己造芯片先說個(gè)大的背景。到 2026 年大模型訓(xùn)練的算力需求早就不是“堆幾張卡”能解決的了。GPT 級(jí)別模型的單次訓(xùn)練成本動(dòng)輒數(shù)億美元其中大頭全在 GPU 采購、服務(wù)器配套和數(shù)據(jù)中心電費(fèi)上。OpenAI 作為全球算力消耗最大的機(jī)構(gòu)之一對(duì)英偉達(dá)的依賴程度已經(jīng)到了“股東都看不下去”的程度——錢被上游賺走產(chǎn)能還被掐著脖子Scale 的節(jié)奏完全由別人的 roadmap 決定。自研芯片在邏輯上就是必然選擇。這里有個(gè)很樸素的賬一顆旗艦 GPU 的毛利接近 70%如果用量級(jí)達(dá)到數(shù)十萬顆中間商賺走的差價(jià)足夠再建一座數(shù)據(jù)中心。自己做 ASIC雖然前期流片費(fèi)用高、周期長但一旦跑通單顆成本可以壓到同等性能 GPU 的六成甚至更低而且供電、散熱、互聯(lián)全都按自己的需求定制不用遷就通用產(chǎn)品的冗余設(shè)計(jì)。另一個(gè)容易被忽略的因素是“推理效率”。OpenAI 目前的收入結(jié)構(gòu)里API 調(diào)用和訂閱制帶來的推理負(fù)載已經(jīng)遠(yuǎn)超預(yù)訓(xùn)練負(fù)載。ChatGPT 的日請(qǐng)求量在千萬級(jí)每一次回答都涉及模型前向推理。通用 GPU 是為“訓(xùn)練優(yōu)先推理兼顧”設(shè)計(jì)的很多晶體管花在了訓(xùn)練才需要的靈活性和可重配置性上。推理場(chǎng)景固定以后這些資源全是浪費(fèi)。自研芯片最核心的優(yōu)化點(diǎn)就是把浪費(fèi)砍掉把每一瓦功耗都花在推理本身。1.2 “Jalape?o”這名字背后藏著的定位Jalape?o 是墨西哥辣椒個(gè)頭不大但后勁足。OpenAI 內(nèi)部給芯片取這個(gè)名字多少有點(diǎn)自嘲加自信的味道——不做“最大的芯片”做“讓你冒汗的芯片”。結(jié)合目前已知的信息OpenAI 找博通合作做定制 ASIC臺(tái)積電代工預(yù)計(jì) 2026 年流片初期部署主要服務(wù)內(nèi)部推理負(fù)載。這確認(rèn)了它是“為規(guī)模推理而生的專用芯片”并非要取代英偉達(dá)全部產(chǎn)品線。這一定位意味著幾個(gè)關(guān)鍵信號(hào)。第一它不會(huì)追求通用性算子層面會(huì)有大量固定化、硬化的設(shè)計(jì)。第二它必須和自家模型深度綁定尤其是 GPT-5 及后續(xù)系列的推理特征。第三它大概率不會(huì)公開零售而是以規(guī)模集群的形式出現(xiàn)在微軟和 OpenAI 自己的數(shù)據(jù)中心里對(duì)外依然以 API 形式提供服務(wù)。我之前和做芯片的朋友聊過這類項(xiàng)目大家一致的判斷是OpenAI 自研芯片的目標(biāo)從來不是“發(fā)布一款產(chǎn)品”而是“建立一種新的算力成本結(jié)構(gòu)”。所以不管這顆芯片的實(shí)際性能能不能在某張標(biāo)桿榜單上超越 H 系列只要它能以一半的 TCO 跑滿 GPT-5 的推理負(fù)載對(duì)公司整體戰(zhàn)略就是巨大的勝利。這也是理解“Jalape?o”所有技術(shù)參數(shù)的前提。1.3 OpenAI 在芯片賽道的“前傳”與籌碼OpenAI 不是突然拍腦袋造芯片的。2023 年就開始接觸包括博通在內(nèi)的多家芯片公司同期還從谷歌 TPU 團(tuán)隊(duì)和英偉達(dá)挖了一批架構(gòu)師。更關(guān)鍵的是OpenAI 手里有幾個(gè)別人沒有的優(yōu)勢(shì)模型定義權(quán)芯片怎么設(shè)計(jì)完全取決于自家模型的 Attention 架構(gòu)、稀疏化策略和精度需求不用猜。真實(shí)負(fù)載數(shù)據(jù)每天幾十億次推理請(qǐng)求模型的熱點(diǎn)算子和訪存分布清清楚楚做硬件設(shè)計(jì)時(shí)可以直接對(duì)著真實(shí) trace 優(yōu)化。軟件?？刂屏penAI 同時(shí)掌控底層框架如 Triton 的深度定制和上層產(chǎn)品ChatGPT、API硬件再難用也能靠軟件堆棧硬啃下來。傳統(tǒng)芯片公司最怕的是“做了芯片沒人適配”O(jiān)penAI 不存在這個(gè)雞生蛋問題。所以這顆“辣椒”不是從零開始的它是在明確路徑、明確負(fù)載、明確算法演進(jìn)方向的條件下對(duì)英偉達(dá)做的一次精準(zhǔn)側(cè)翼進(jìn)攻。能不能真的“辣倒”旗艦我們接下來從工程細(xì)節(jié)看。2. Jalape?o 核心架構(gòu)與技術(shù)畫像2.1 700W 功耗背后的物理含義700W 這個(gè)數(shù)字要放在語境里看。英偉達(dá)的 H100 SXM 版 TDP 是 700WB200 達(dá)到了 1000WB300 有傳聞到 1400W。主動(dòng)散熱設(shè)計(jì)上700W 大致是風(fēng)冷能壓住的極限再往上必須液冷。Jalape?o 選 700W至少透露了三個(gè)信息第一它的目標(biāo)部署形態(tài)是“兼容現(xiàn)有基礎(chǔ)設(shè)施”。700W 意味著設(shè)計(jì)時(shí)考慮了風(fēng)冷和液冷混合部署的可能性甚至可以直接替換部分 H100 的整機(jī)柜插槽不用重新設(shè)計(jì)電源和散熱管道。這對(duì)規(guī)模運(yùn)營來說省下的改造費(fèi)用非常可觀。第二性能墻不是算力而是散熱。一顆 700W 芯片在 CoWoS 封裝下可以容納的晶體管規(guī)模已經(jīng)非?？捎^。以臺(tái)積電 N33nm工藝估算700W 的功耗預(yù)算里計(jì)算 die 部分約占 400-500W剩余給 HBM 和 SerDes 互聯(lián)。這個(gè)預(yù)算足夠放入一個(gè) SM 規(guī)模達(dá)到“旗艦級(jí)”的計(jì)算核心——本質(zhì)上它是一個(gè)有明確面積和功率預(yù)算的定制產(chǎn)品。第三算力密度對(duì)標(biāo)英偉達(dá)下一代風(fēng)冷產(chǎn)品的意圖很明顯。數(shù)據(jù)中心機(jī)柜的功率天花板是固定的單卡 700W 可以在 44U 機(jī)箱里匹配合理的供電密度。如果英偉達(dá)下一步被迫升級(jí)到 1400W 需要全面液冷而 Jalape?o 在風(fēng)冷下就能達(dá)到相近推理性能那在現(xiàn)有數(shù)據(jù)中心的改造速度上OpenAI 就能搶出 6-12 個(gè)月的時(shí)間窗口。這是戰(zhàn)略層面的考量不只是電費(fèi)問題。2.2 推理優(yōu)先為什么是“大顯存、低精度、強(qiáng)互聯(lián)”推理場(chǎng)景和訓(xùn)練最大的區(qū)別在于推理是 latency-critical 的單位時(shí)間內(nèi)要處理盡可能多的請(qǐng)求而不是做復(fù)雜的梯度更新。針對(duì)這一點(diǎn)Jalape?o 的核心配置會(huì)明顯偏向訪存帶寬和容量。顯存容量的重要性怎么強(qiáng)調(diào)都不過分。現(xiàn)在 GPT 級(jí)別的模型權(quán)重動(dòng)輒幾百 GB如果顯存不夠就只能做張量并行或者模型并行把模型切到多張卡上。但多卡并行的代價(jià)是通信開銷模型切得越碎卡間傳輸越頻繁延遲越高吞吐越差。Jalape?o 如果配備 HBM3E 或后續(xù)的 HBM4單卡容量做到 192GB 甚至更大那么許多模型就可以單卡承載推理時(shí)延和集群調(diào)度復(fù)雜度都會(huì)大幅下降。低精度計(jì)算則是另一個(gè)杠桿。推理對(duì)精度的敏感性低于訓(xùn)練FP8 甚至 FP4 就足夠。相同晶體管數(shù)量下低精度算力可以翻倍甚至翻三倍。聽說這代芯片的核心矩陣單元會(huì)在 FP8 上做重點(diǎn)硬化INT8/FP8 吞吐很可能是 FP16 的 2-3 倍。對(duì)于大規(guī)模服務(wù)場(chǎng)景這個(gè)比例意味著單位功耗能服務(wù)的用戶數(shù)直接翻番是“辣”倒英偉達(dá)旗艦的關(guān)鍵武器。2.3 互聯(lián)與集群對(duì)標(biāo) NVLink 的 Scale-up 方案單顆芯片再強(qiáng)撐不起 GPT-5 這種十萬卡級(jí)別的集群集群互聯(lián)把“單點(diǎn)優(yōu)勢(shì)”轉(zhuǎn)化為“整體優(yōu)勢(shì)”才是真正的護(hù)城河。Jalape?o 的互聯(lián)方案必然是最核心的機(jī)密之一。從公開信息推測(cè)它大概率采用 UALink 或自研的私有協(xié)議在超節(jié)點(diǎn)內(nèi)實(shí)現(xiàn)類似 NVLink 的帶寬——目標(biāo)是每張卡 900GB/s 以上才能跟上 HBM 的吞吐需求。為什么互聯(lián)帶寬這么關(guān)鍵因?yàn)橥评碡?fù)載并不是完全友好的。一個(gè)長上下文請(qǐng)求KV Cache 動(dòng)輒幾十 GB如果模型或 KV Cache 分布在多張卡上每層 Transformer 的計(jì)算都要跨卡取數(shù)據(jù)互聯(lián)帶寬低一點(diǎn)整卡算力就被活活餓死。反過來如果互聯(lián)密度夠高就可以把注意力層和大矩陣乘跑在不同的卡上實(shí)現(xiàn)流水線并行推理把端到端時(shí)延壓到極小。對(duì) OpenAI 而言互聯(lián)還有一個(gè)隱形的優(yōu)勢(shì)是“調(diào)度靈活性”。如果他們能從底層控制互聯(lián)拓?fù)渚湍転椴煌愋偷恼?qǐng)求短文本、長文檔、多模態(tài)動(dòng)態(tài)劃分計(jì)算域而不是像今天這樣靠外部集群調(diào)度器硬湊。這種軟硬協(xié)同的優(yōu)化空間是外購 GPU 的用戶永遠(yuǎn)碰不到的。3. 與英偉達(dá)旗艦的正面對(duì)比從 GB200 到 B3003.1 硬件參數(shù)對(duì)比表基于公開信息和合理推演我把 Jalape?o 和英偉達(dá)目前在售的幾款旗艦做了個(gè)參數(shù)對(duì)照。需要說明的是Jalape?o 的正式規(guī)格尚未完全公開表格里一部分是工程層面可信的推測(cè)值但對(duì)比維度本身是有效的。項(xiàng)目Jalape?o推測(cè)H200B200GB200 單卡B300傳聞工藝臺(tái)積電 N3N4PN4PN3TDP約 700W700W1000W約 1400W顯存容量192GB HBM3E 或更高141GB HBM3E192GB HBM3E288GB HBM3E/HBM4顯存帶寬約 8-9TB/s4.8TB/s8TB/s約 13TB/s核心精度優(yōu)化FP8 強(qiáng)化推理FP8 通用FP4/FP8 訓(xùn)練推理FP4 強(qiáng)化訓(xùn)練互聯(lián)帶寬推測(cè) 900GB/s 以上NVLink 900GB/sNVLink 5.0 1.8TB/sNVLink 5.0 1.8TB/s目標(biāo)場(chǎng)景超大規(guī)模推理訓(xùn)練推理訓(xùn)練為主訓(xùn)練旗艦這張表其實(shí)反應(yīng)了一個(gè)很清晰的信號(hào)Jalape?o 在“絕對(duì)算力上限”上可能沒有優(yōu)勢(shì)但在“單位功耗的推理吞吐”和“顯存容量/算力比”這兩個(gè)推理關(guān)鍵指標(biāo)上它是有機(jī)會(huì)和旗艦掰手腕的。它沒有追求全能而是把所有預(yù)算都花在了推理刀刃上。3.2 軟件棧CUDA 護(hù)城河有沒有被繞開任何一個(gè) GPU 想挑戰(zhàn)英偉達(dá)最大的攔路虎從來不是硅片而是 CUDA。十年積攢下來的算子庫、框架適配、分布式通信庫讓“移植到新硬件”幾乎等于把深度學(xué)習(xí)技術(shù)的祖墳刨開重寫一遍。Jalape?o 要想真正落地軟件棧是最難的硬仗。OpenAI 的解法是“繞開底層從上層強(qiáng)攻”。他們不需要吸引所有開發(fā)者只需要自家的模型跑得順。PyTorch 2.x 的 torch.compile 引入了中間表示 Triton IR理論上任何硬件只要實(shí)現(xiàn)一個(gè) Triton 后端就能自動(dòng)適配大量算子。OpenAI 深度綁定了 Triton 的演進(jìn)等于直接把編譯器的控制權(quán)攥在手里再配合內(nèi)部的圖優(yōu)化器把模型計(jì)算圖無縫映射到硬件上。但這不代表沒有坑。即便有 Triton 做中間層高性能算子仍然需要手工調(diào)優(yōu)——比如 Attention 的各種變體PagedAttention、FlashAttention 6比如 MoE 層里 dynamic routing 帶來的訪存不規(guī)律再比如長序列推理時(shí) KV Cache 的反復(fù)讀寫。這些算子的性能直接決定芯片好用不好用。從我接觸過的 ASIC 項(xiàng)目經(jīng)驗(yàn)看第一版本的軟件棧大概率會(huì)很難看算子覆蓋率可能只有 70-80%剩下的要靠模型結(jié)構(gòu)本身的調(diào)整來繞。3.3 部署與 TCO真正的勝負(fù)手在數(shù)據(jù)中心硬件性能再好看最后都要落到“貴不貴”三個(gè)字上。TCO總擁有成本才是決定一顆芯片生死的終極指標(biāo)。這里我算一筆簡(jiǎn)單的賬假設(shè)要支撐 1 萬卡規(guī)模集群來跑 GPT-5 推理對(duì)比 Jalape?o 和 H200。硬件采購H200 單卡均價(jià)按 3 萬美元算Jalape?o 自研按同性能下壓縮 30% 成本計(jì)算1 萬卡差額將近 1 億美元。功耗成本H200 滿載 700W 單卡整機(jī)柜加上散熱和網(wǎng)絡(luò)設(shè)備實(shí)際功耗差不多 2 倍。Jalape?o 按同類負(fù)載下等效功耗低 20% 計(jì)算一年電費(fèi)就能省上千萬美元。維護(hù)成本自研 ASIC 的故障率理論上低于通用 GPU功能更單一RMA 和運(yùn)維成本也低。調(diào)度成本對(duì) OpenAI 來說Jalape?o 的卡上拓?fù)渫耆煽夭辉龠w就英偉達(dá)對(duì) NVSwitch 機(jī)柜的硬性切分集群的碎片化率會(huì)降低空閑資源能多利用 10-15%。這個(gè)賬算下來即使 Jalaape?o 的單卡絕對(duì)性能只是 H200 的 1.5 倍整體 TCO 優(yōu)勢(shì)也可能拉到 2 倍以上。這才是“辣”真正辣的地方——不是因?yàn)橐粔K卡有多快而是因?yàn)槭f塊卡加在一起總成本比對(duì)面低一個(gè)檔次。4. 落地部署會(huì)遇到的現(xiàn)實(shí)問題與應(yīng)對(duì)4.1 新卡上線開發(fā)者會(huì)遇到什么從開發(fā)者的角度說最關(guān)心的就是“我得改多少代碼”。如果你的代碼是純 PyTorch 標(biāo)準(zhǔn)算子那通過 Triton/編譯器后端做適配大概率只改少量環(huán)境變量就能跑起來。但如果你用了 CUDA 特定的庫比如 flash-attn 的 C 擴(kuò)展或者自己寫了 CUDA kernel那麻煩就大了基本等于要重寫。我個(gè)人的建議是如果團(tuán)隊(duì)里有人要為多芯片平臺(tái)做適配快速收斂到三層技術(shù)棧模型層全部用 PyTorch 標(biāo)準(zhǔn)接口別炫技別搞魔改算子。算子層能走 torch.compile 就絕不手寫 CUDA。分布式層優(yōu)先用 PyTorch DDP/FSDP通信庫和硬件解耦。這么準(zhǔn)備的好處是將來無論底層芯片換成 Jalape?o、AMD 還是其他國產(chǎn)加速卡模型代碼都不用大動(dòng)。4.2 算子適配與性能調(diào)優(yōu)就算全部用 PyTorch 標(biāo)準(zhǔn)接口算子適配完之后性能也未必好看。ASIC 和 GPU 在硬件設(shè)計(jì)哲學(xué)上差別很大GPU 是通用并行計(jì)算任何算子都能跑但未必最快ASIC 是固定流水線設(shè)計(jì)了的算子飛快沒設(shè)計(jì)的算子就等著“被軟件層翻譯成底層指令”性能可能慢到懷疑人生。Jalape?o 首批必須重點(diǎn)優(yōu)化的算子里我判斷至少有這幾類Fused Multi-Head Attention含長序列 Flash Attention 變種、Gated MLP / SwiGLU、MoE 的 Top-K Router 與 All-to-All、各類 Normalization 和 Residual 融合。如果你恰好是優(yōu)化這些算子的工程師提前研究 Triton 的底層 dispatch 機(jī)制、把動(dòng)態(tài) shape 從熱路徑里摘出去會(huì)少踩很多坑。還有一點(diǎn)必須提醒第一代專用芯片對(duì)小算子比如 elementwise 操作的開銷模型很不友好。因?yàn)楣潭魉€設(shè)計(jì)里啟動(dòng)一個(gè) Kernel 需要走完整個(gè)硬件隊(duì)列的狀態(tài)機(jī)短任務(wù)會(huì)被啟動(dòng)開銷吞掉。正確做法是把小算子融合到大算子圖里盡量把計(jì)算圖“焊死”成大塊執(zhí)行。這會(huì)和通用框架的默認(rèn)圖優(yōu)化策略有沖突需要自己寫 pass 去調(diào)。4.3 關(guān)于功耗和散熱的幾個(gè)坑700W 的整體功耗不算夸張但它把所有散熱壓力集中在一個(gè)很小的 die 上熱點(diǎn)密度很大。實(shí)際部署中有幾個(gè)容易被忽略的坑機(jī)柜供電規(guī)劃要留余量700W 是 TDP不是實(shí)際穩(wěn)態(tài)功耗。AI 推理的功耗波動(dòng)非常大長上下文請(qǐng)求可能讓卡瞬間沖到接近 TDP供電模塊建議按 1.3 倍冗余設(shè)計(jì)。風(fēng)冷和液冷要分開規(guī)劃雖然 700W 理論上風(fēng)冷可壓但數(shù)據(jù)中心里多個(gè) 700W 卡片并排運(yùn)行時(shí)進(jìn)風(fēng)溫度會(huì)顯著上升風(fēng)冷方案的可靠性會(huì)大幅下降?；旌?SLED 或者后門熱交換器會(huì)是更實(shí)用的選擇。功耗監(jiān)控必須到卡級(jí)通用 GPU 時(shí)代我們可以只盯著整柜功率ASIC 需要細(xì)粒度的每卡遙測(cè)數(shù)據(jù)才能在運(yùn)行中識(shí)別出“功耗異常但沒報(bào)錯(cuò)”的卡提前處理熱漂移。這不是什么高端技術(shù)但沒有就等于瞎跑。5. 常見問題排查與避坑筆記5.1 常見問題速查表結(jié)合 ASIC 部署的常見故障模式和網(wǎng)絡(luò)上的開發(fā)者反饋我整理了一份問題排查速查表大多數(shù)觀點(diǎn)同樣適用于英偉達(dá)之外的其他 AI 芯片平臺(tái)現(xiàn)象可能原因排查手段解決方案模型可運(yùn)行但速度遠(yuǎn)低于預(yù)期算子落到低效路徑或軟件仿真模式在框架里打開算子級(jí) profiling看 Kernel 落在哪個(gè) backend手寫算子映射或修改圖優(yōu)化策略長上下文任務(wù)顯存溢出KV Cache 分配策略不合理檢查顯存分配器是否針對(duì)大塊連續(xù)內(nèi)存優(yōu)化調(diào)整分配器改為預(yù)分配 動(dòng)態(tài)池化多卡并行時(shí)性能不升反降互聯(lián)帶寬/拓?fù)洳黄ヅ溆?AllReduce 測(cè)試延展性調(diào)整通信域劃分避免跨 NUMA 通信芯片溫度快速漂移散熱膏/裝配公差問題檢查遙測(cè)數(shù)據(jù)對(duì)比同批次卡微調(diào)機(jī)柜風(fēng)道或降低頻率墻至穩(wěn)態(tài)安全值推理首次啟動(dòng)特別慢權(quán)重格式轉(zhuǎn)換得不對(duì)檢查模型導(dǎo)出時(shí)精度是否匹配將權(quán)重提前轉(zhuǎn)成目標(biāo)格式避免運(yùn)行時(shí)實(shí)時(shí)流轉(zhuǎn)框架報(bào)錯(cuò)提示算子不存在中間表示下鉆到無硬實(shí)現(xiàn)路徑查看后端注冊(cè)算子列表用 Triton 手工實(shí)現(xiàn)一個(gè) fallback 算子這表遇到具體問題時(shí)再看核心建議是千萬別在生產(chǎn)環(huán)境里臨時(shí)排查硬件平臺(tái)的適配問題一定要在預(yù)發(fā)環(huán)境提前跑完壓力和故障注入測(cè)試。5.2 幾個(gè)獨(dú)家經(jīng)驗(yàn)第一凡是涉及多卡通信的算子一定要把“卡間互聯(lián)拓?fù)洹笨紤]進(jìn)去。很多人習(xí)慣寫分布式訓(xùn)練代碼時(shí)假設(shè)任意兩張卡之間通信成本相同但在 ASIC 集群里同一 chiplet 內(nèi)的通信帶寬和跨 OAM 板卡的通信帶寬可以差 3-4 倍。做負(fù)載均衡時(shí)要按通信關(guān)系就近調(diào)度。第二顯存帶寬再大也架不住低命中率的 Cache Miss。長上下文模型里的 Attention 算子對(duì) HBM 的隨機(jī)訪問壓力非常大不要只看 HBM 帶寬指標(biāo)要多關(guān)注具體工作負(fù)載下的實(shí)際可利用帶寬。如果你的模型是長上下文密集型建議先做一個(gè) bandwith-bound 的基準(zhǔn)測(cè)試用科學(xué)壓測(cè)代替猜測(cè)。第三新卡上跑模型第一件事不是測(cè)吞吐而是開著 profiler 跑一個(gè)標(biāo)準(zhǔn) batch 的模型前向把所有算子的時(shí)間占比拉出來找出 TOP 5 熱點(diǎn)算子。這 5 個(gè)算子通常占掉 80% 以上的時(shí)間榨干它們的性能其他算子隨便弄弄都不影響大局。這個(gè)習(xí)慣是我在優(yōu)化各種國產(chǎn)加速卡時(shí)養(yǎng)成的放到任何新硬件上都適用。6. 對(duì) AI 芯片行業(yè)的影響與我的幾點(diǎn)個(gè)人判斷6.1 超大規(guī)模廠商自研芯片會(huì)成為常態(tài)Jalape?o 哪怕最后量產(chǎn)不及預(yù)期它的示范效應(yīng)也已經(jīng)產(chǎn)生了。OpenAI 讓“模型公司自己做芯片”從“設(shè)想”變成了“既定路線的項(xiàng)目”。之后被影響的連鎖反應(yīng)會(huì)很直接云廠商的芯片團(tuán)隊(duì)獲得更多的資源和話語權(quán)自研 ASIC 在數(shù)據(jù)中心里的占比會(huì)從現(xiàn)在的 10% 上下往 30% 方向走。英偉達(dá)的“全棧護(hù)城河”會(huì)從“市場(chǎng)獨(dú)斷”轉(zhuǎn)變成“性價(jià)比守衛(wèi)戰(zhàn)”。未來幾年它的旗艦產(chǎn)品價(jià)格會(huì)受到明顯壓力純硬件毛利被壓縮是大概率的。臺(tái)積電 CoWoS 封裝的產(chǎn)能可能持續(xù)更緊張因?yàn)槊考易匝行酒级⒅蛔冗M(jìn)封裝廠。短期內(nèi)這反而會(huì)推高 HBM 和先進(jìn)封裝的成本對(duì)行業(yè)整體并非全是好消息。我自己判斷三到五年后的大模型算力市場(chǎng)上會(huì)出現(xiàn)“通用 GPU 推理 ASIC 云廠商自研芯片”三分天下的格局任何一家想靠一款產(chǎn)品壟斷 90% 市場(chǎng)的時(shí)代已經(jīng)過去了。6.2 留給普通開發(fā)者和研究者的應(yīng)對(duì)建議最后說點(diǎn)對(duì)大家實(shí)際有用的。不管你用不用得上 Jalape?o多硬件平臺(tái)的適配能力會(huì)變成一種稀缺技能。現(xiàn)在開始做兩件事不會(huì)有錯(cuò)一是把自己的模型代碼從“能用”改成“可移植”盡量剝離對(duì)特定硬件庫的強(qiáng)依賴二是學(xué)一下 Triton它正在成為 AI 芯片軟件的“通用語言”。手里正在用 OpenAI API 做應(yīng)用的開發(fā)者其實(shí)不用擔(dān)心。OpenAI 早就把 API 層和底層硬件完全解耦了Jalape?o 上線以后你調(diào)用 API 的方式、返回結(jié)果、計(jì)費(fèi)方式都不會(huì)有任何變化。真正被影響的是那些今天自己在租 GPU、自己部署開源模型的團(tuán)隊(duì)——他們需要關(guān)注的是當(dāng)一個(gè)超大規(guī)模玩家把推理成本打下來之后整個(gè)市場(chǎng)的算力價(jià)格會(huì)不會(huì)跟著降。如果會(huì)那無論你用不用自研芯片都是受益者。這顆 Jalape?o 能在多大程度上“辣倒”英偉達(dá)旗艦我認(rèn)為三五年內(nèi)都不是“替代”而是“撬動(dòng)”。它未必是那個(gè)拿到終局冠軍的產(chǎn)品但它是歷史上第一個(gè)讓“模型方做硬件”變成行業(yè)正式議題的樣板事件。就算最終只有這點(diǎn)意義也很了不起了。