茉莉花
新闻网
2026-08-26 · 星期三近12小时收录 84 条最近更新 20:27

快讯俄中合资石化企业远东工地火灾 至少7人遇难 包括中国公民6人 9人失踪

OpenAI自研辣椒芯片实测超英伟达 每瓦吞吐提升近2倍

转载信息出处与时间记录
内容性质
全文转载(非本站原创报道)
原始出处
爱范儿
原文作者
张子豪
原文发布
本站收录

做芯片很难,第一代产品就做到有竞争力更难。OpenAI 这次交出的答案,至少在大模型推理这件事上,已经足够夸张。

今天,OpenAI 正式公布了其首款定制推理芯片 Jalapeño(墨西哥辣椒)的首批实测性能数据。

1cd19fdc3bf02fa6c5198ae6562af4c6fb5113731d3fab17c032fa1469386c75 article

在基于自己开源模型 GPT-OSS 120B 的公开基准测试 InferenceX 上,Jalapeño 的每千瓦峰值吞吐量和 Token 延迟都比现有的硬件系统表现要好。

要知道,对大多数芯片来说,吞吐和延迟往往是一道只能二选一的难题。而除了针对 OpenAI 的大模型优化明显,芯片在 670B 的 DeepSeek R1 和 1T 的 Kimi K2.5 上表现也更出色,对手都是英伟达 GB200/GB300 等市面上最强的商用 AI 系统。

奥特曼在 X 上毫不客气地评价:「我们造了一颗芯片,快得离谱。」

9544ea497351e5599378aa90788ea17bb314c4d12f0b75a1462f73fbc705a3ee article

知名科技 Newsletter SemiAnalysi 创始人 Dylan Patel 更给了极高的评价,「第一代芯片通常毫无竞争力,但 OpenAI 正在打败英伟达 Blackwell,甚至 Rubin。」

更巧的是,OpenAI 并不是这几天唯一一家谈芯片的公司。

小米刚刚一口气公布三颗自研芯片,苹果昨天发布首颗 2nm M6,接下来一个月,高通、联发科、苹果和华为的新一代旗舰芯片还会继续扎堆登场。

2ac36bd2afefa5bb0c9c0daf434bda3354ae1d2b709862e21616ac4a92916723 article

从数据中心到手机,AI 芯片正在成为所有科技巨头共同争夺的一块地盘。

一份近乎「不讲理」的成绩单

先看 Jalapeño 的数据,OpenAI 这次采用 InferenceX 测试,统一设置为 8K 输入、1K 输出,使用标准单 token 预测,没有开启推测解码。对照系统包括英伟达 GB200 和 GB300。

OpenAI 将 DeepSeek R1 与 Kimi K2.5 标为 MXFP4,在 GPT-OSS 120B、DeepSeek R1 670B 和 Kimi K2.5 1T 三个模型上的结果显示:

  • 峰值吞吐量,每瓦的 AI 工作量是对比系统的 1.5 到 1.9 倍,
  • 端到端延迟降低了 1.7 到 3.6 倍,
  • 对于高交互性工作负载,其性能更是提升了 2.1 到 4.1 倍。

4732f3802c03d912adb7a690373c2d2cb158b2bc722a86e78412995aa12b47bf article

在最极端的对比项里,差距被拉得相当大,GB200 此前最佳的单用户速度(约 535 tok/s)下,Jalapeño 的每千瓦吞吐是前者的 53.7 倍。

acfd7a3230d5502f647736d2a477ad0a106626103701467ae69960821b56deae article

跑 DeepSeek R1 时,Jalapeño 单用户可达 700 tok/s,对标系统只有 169 tok/s。而 Jalapeño 标称功耗仅 700W,实测持续功耗不超过 550W。

对于规模化推理服务来说,芯片最终拼的除了跑得多快,还有花同样的电、占同样的数据中心容量,能服务多少用户。

换成云计算生意里的语言,就是一句很直接的话:「每瓦吞吐,最后都会变成成本和收入。」

d7654347656dc94694deda1fff3d20b988411fa0a772a5d4049d454a13a5f4a5 article

▲跑 DeepSeek R1 时,Jalapeño 单用户生成速度最高约 700 tok/s,GB300 为 169 tok/s。

d4bc47ea37d1b4d412a34e429242fedbc352a775b7010983540a625174948fa6 article

更值得注意的是 OpenAI 这颗辣椒芯片的达成方式:没有多 token 预测(MTP)、没有投机解码、没有 prefill-decode 分离,就这样赢过了软硬件优化的英伟达对手芯片。

SemiAnalysis 长篇技术博客里也验证了测试过程,并确认 Jalapeño 跑出的 GSM8k 精度与英伟达芯片持平。

30140a80aa9666dc91f424d6d68654b0eda9ddc1fef5b472965ddb29a1c8e5fc article

▲文章链接:https://newsletter.semianalysis.com/p/openai-jalapeno-better-than-nvidia

当然,X 上的讨论也没少泼冷水。daily.dev 的开发者社区就指出,那个疯传的「104.3 倍」只是特定等速解码场景下的单一数据点,而且测试模型和对比基线都是 OpenAI 自己挑的。

SemiAnalysis 也承认,Jalapeño 还没跑过多轮长上下文的 AgentX 测试;真正的对手应该是同样用 HBM4 的 Vera Rubin 而非 Blackwell。

即便如此,最终的共识依然是:第一代自研芯片就站上帕累托前沿,这在行业里没有先例。Meta 和微软折腾多年始终难产的 AI ASIC 项目,是最好的反证。

非 OpenAI 模型独家专用,是通用推理引擎

外界一度认为 OpenAI 造芯是给自家模型开小灶,SemiAnalysis 则提到 Jalapeño 是通用推理芯片。测试表现最好的三个模型里,DeepSeek R1 和 Kimi K2.5 根本不在 OpenAI 最初的投产计划内。

团队还提到用 Codex 两个月就把它们优化到了高性能,并且在这颗芯片上成功运行了游戏《Doom》,移植全程只用了 Codex 提示词。

f16a593894df9233ed4e5f5c826877b7ae1640a42a0317df71103d2630351e6f article

硬件上,Jalapeño 采用台积电 N3P 工艺,最新的 B0 步进单计算 die 提供 13.4 PFLOPS 的 MXFP4 算力。同工艺、同尺寸的英伟达 Rubin 计算 die 是 17.5 PFLOPS(NVFP4),但 Jalapeño 的 TDP 只有 700W,Rubin 是 900~1150W。

再看设计逻辑。要理解 Jalapeño,得先知道大模型推理其实是两种完全不同的活:处理 prompt 的 prefill 阶段吃算力,逐字生成回答的 decode 阶段吃显存带宽,而数据在核心间、芯片间搬来搬去的通信开销则在两边拖后腿。

多数系统擅长其中一种,却会在等待数据时把优势浪费掉。

eda158f4569a129902a438015a843f5906ab74e647638fa07840c5bed47bef4f article

Jalapeño 的核心思路,是尽可能让数据待在原地,减少搬运。

芯片的核心和 HBM 都被切成一一对应的切片,每个核心切片对自己那片 HBM 拥有低延迟的本地视图;KV cache 和模型权重被显式地安置在原地,生成过程中不再挪窝。

切片之间需要同步时,可以走一条专用的高带宽集合通信网络,通用通信则交给另一张简化的 NoC。对比 GPU 里层层穿越的复杂内存体系,这套「极简内存层级」省掉了大量的延迟和功耗。

4e8aba085925c5c62025fb6be4cf1a641987dad4149bb5c24c282c74f11e4cb4 article

这套方法论可以总结成两步:硬件负责把理论上限拉到最高,AI 负责找到逼近上限的写法。

结果是它在各种批量、各种形状下都更接近硬件的屋顶线(roofline),尤其是 GPU 最不擅长的小批量、低延迟场景,而这些又恰好是 agentic 工作负载最在意的地方。

系统层面同样贯彻这个思路,OpenAI 没有采用目前热门的优化路线:PD 分离(prefill 和 decode 分池部署),理由是真实流量里输入输出的比例全天都在漂移,固定分池必然一边闲置一边排队,KV cache 跨池搬运还会平添功耗和延迟。

8eeb99842d369a7accc77453335555b26e526aa6b6ffb0c013aea1cc52d0a4d4 article

统一池子里,128 颗芯片组成一个机架(CPU 托盘叫 Katsu、ASIC 托盘叫 Vindaloo、交换托盘叫 Chana,都是一串咖喱菜名),16 个机架再用铜缆加光交换织成 2048 颗芯片的单一 scale-up 域。

整个请求从进来到出去,数据都不需要使用 PD 分离的转移。

真正的秘密武器是:用 AI 造芯片

如果 Jalapeño 的故事只到这里,它仍然只是一颗性能很强的 ASIC 推理芯片。

真正让这件事有点反常识的,是 OpenAI 连「怎么造芯片」这件事本身,也开始交给 AI 加速。

Jalapeño 项目 2024 年年中才启动,2025 年 11 月流片,前后约 16 个月;流片后 9 个月、点亮仅 3 个月就交出了上述成绩。

197008df294f923b34454d2d68a5dd476578c1fc1e95b12bd5fce9c26be20681 article

OpenAI 提到 AI 深度参与了设计:探索实现方案、缩短验证循环、优化算术电路,SIMD 单元面积缩小 8%、矩阵引擎缩小 10% 都有 AI 的功劳。部分 AI 生成的内核实现比人类专家手写版本快 1.5~1.8 倍。

过去几十年,芯片研发一直拥有极高的专业门槛。一套新架构从设计、验证、流片,到建立编译器、内核库和完整的软件生态,通常都需要大量经验丰富的工程师和漫长的迭代周期。

ab3e3b005b88623a6639b981babf72c36d45745a07710a641f0be3a3dc0a4ae8 article

CUDA 最坚固的护城河,也恰恰来自这里。就像英伟达真正难被复制的部分,除了 GPU 本身,还有围绕 GPU 积累了十几年的工具链、Kernel、开发者和工程经验。

但 Jalapeño 这次 AI 造芯片的经验,展示了另一种可能。硬件工程师可以让模型辅助设计和验证;一颗芯片点亮之后,Codex 又可以帮助工程师写 Kernel、适配新模型,甚至把一个完全没有准备过的模型在几个月内优化到高性能。

14bb86953bc77e9474110988846ada74fbc618d9d93e43d4611f9c6199b1149b article

于是会出现一个很有意思的循环:用英伟达 GPU 训练出来的 AI,正在帮助工程师设计下一颗不依赖英伟达的芯片。

SemiAnalysis 对此给出了一个非常激进的判断:CUDA 的护城河,可能正在松动。

当然,只是一颗推理芯片的 Jalapeño 还远远不足以宣判 CUDA 的结局。但它至少证明了一件以前很难想象的事情:AI 已经开始进入生产下一代 AI 基础设施的研发循环。

模型帮助造芯片,更好的芯片又用来运行下一代模型。

当大家都开始造芯

也正是在这个背景下,再看最近密集发生的芯片新闻,会发现它们指向的是同一个方向。

两天,四家公司,芯片从手机、Mac 延伸到数据中心,小米的「自研芯片+OS+大模型」组合,苹果也是全系芯片都在为 Apple Intelligence 准备好,以及做能跑前沿模型的最好本地设备。

6c4478e26ba8ed3b09da725af840091e7655ed2daaf558cdf375e8cdb3daa468 article

高通、联发科两个手机芯片大厂,骁龙 8 Gen 6 与天玑 9600 也双双杀入 2nm;华为的终端与云端路线上,麒麟 9030 和昇腾系列都将迎来更新。

还有 Anthropic,虽然还没发布芯片,但已经确认组建内部定制芯片团队。

8 月被彭博曝出挖来谷歌 TPU 业务前负责人 Amir Salek,这位老将带队交付了 Google 前七代 TPU;6 月又从 OpenAI 芯片团队挖走二号工程师 Clive Chan,此前在特斯拉参与 Dojo 超级计算机。

bd094710a8b82fd0a88b9db88980a1aac416ed236fb83fb088d75d81d0b2f962 article

OpenAI 博客里那句「AI 的进步在整个系统一起变好时复利最快」,放在这些动作上,全部都成立。

b9731ec6664380f934e2289c9035e7998d7a010b8837386641632419d89cc477 article

Jalapeño 的故事,与其说是「OpenAI 造了一颗好芯片」,不如说是在验证一条新路径:当一个团队同时拥有模型、软件栈和最懂负载的场景时,白纸设计反而成了优势——不用背负向后兼容,还可以让 AI 同时担任设计师和程序员。

而这个 8 月和即将到来的 9 月将证明,这条路径也并不是 OpenAI 独享:所有人都在把「芯片—系统—模型」的垂直整合推到前所未有的深度。

当然,OpenAI 这颗芯片目前仍处在量产验证和软件成熟阶段,测试也没有覆盖真实的长下文、多轮 Agent 工作流等,但整个的方向已经没有悬念。

OpenAI 表示 Gen 2 已经在深入开发中,Gen 3 正在成形,今年年底 Jalapeño 将开始进入自有算力基础设施部署,下一个目标是 100MW 规模。

419dcebbadd6a02961cbcfda60a650cd42351f5941e779373e37706da812d59c article

芯片的定义权,正在从少数几家芯片公司手里,流向每一家认真对待 AI 的公司。

更正与撤稿0 条记录

本文暂无更正或撤稿记录。若本文发布更正、澄清或被撤稿,相关说明将按时间顺序列于此处。版权异议或撤稿请求:见 版权与撤稿,或致函 [email protected]