← 文章 / 芯片硬件
Tom's Hardware 3小时前 · 2026-09-29 15:27:24 · 2 阅读

OpenAI Jalapeño 推理 ASIC 设计访谈实录

OpenAI 在 2026 年 8 月的 Hot Chips 大会上公布了其 Jalapeño 推理 ASIC。这款芯片在设计过程中大量借助 AI,从而实现了极短的设计周期。发布会后,《Tom's Hardware》有幸与 OpenAI 硬件副总裁 Richard Ho 坐下来聊了聊,解答了我们关于这款芯片如何诞生、未来的规划,以及 AI 将如何应用于芯片研发等一系列最关心的问题。

以下是我们对 Richard Ho 访谈的完整实录,为便于阅读略作编辑。你还可以阅读我们今年早些时候的其他访谈实录,包括 Intel、AMD、Nvidia、Valve 等。作为《Tom's Hardware Premium》AI 芯片设计周的一部分,本篇实录限时免费开放阅读。

Tom's Hardware 资深 CPU 分析师 Jake Roach:你们在 Hot Chips 结束时发布了这个,相当惊艳。我想先从宏观层面聊起。OpenAI 开发自研 ASIC 有很多理由,但有没有某个更具体的因素是主要推动力?是性能、能效,还是别的什么?到底是什么促成了这个决定?

OpenAI 硬件副总裁 Richard Ho:是能效。这是我们追求的主要目标。正如 Sam [Altman] 一直说的,我们将会受限于算力,而算力受限本质上就是数据中心能获得的电力受限。

我们希望在有限的计算资源和功耗条件下尽可能高效地运作,并充分利用这些资源。因为我们真正关心的是能向用户交付多少智能,而更高效的推理设备在此过程中至关重要。这就是我们专注于推理的原因:训练过程虽然涉及大量预训练计算,但对用户而言,真正的成本体现在推理环节,他们感知到的智能也主要来自于此。无论是 ChatGPT、Codex 还是智能体,其响应速度如何,延迟是关键因素。

在我们公布的技术细节中,你可以看到这些考量。我们既提供了一款极佳的低延迟设备,以满足对实时性有严格要求的用户;也能轻松调整参数以获得极高的吞吐量,从而降低推理成本。这正是我们的目标所在,我很高兴团队成功实现了这一目标。

自研的优势

Roach:相比于使用现有的市场产品,你们选择开发自己的 ASIC,是因为对现有产品的效率不满意吗?

Ho:我不这么认为。正确的理解方式是,我们希望利用协同设计的机会。第三方芯片供应商很难做到这一点,因为模型中包含大量研究知识产权,无法广泛共享,无论签多少保密协议,信息终将泄露。

Ho:内部团队能够与我们的研究人员紧密合作,他们对整个技术栈拥有完整视野,并负责权衡:「这个优化应该在软件层做,还是模型层,亦或是硬件层?」凭借对全栈的清晰洞察,我们能够做出明智的权衡,这正是优势所在。

Jalapeño 的一大优势在于我们获得了更高的可见性,从而能够精确洞察达成这些权衡所需的硬件资源。让我们保持智能,将所需反馈注入编译器及整个技术栈,针对特定应用极致优化硬件性能。这正是身处 OpenAI 内部进行全栈协同设计的成果。

Roach:我想澄清几点,因为外界流传着关于针对特定工作负载优化的说法,但这可能被错误地解读为专门针对 OpenAI 工作负载的优化。

Ho:确实是被误读了。我们使用 SemiAnalysis 的 InferenceX 基准测试,核心在于其采用开源模型,且这些模型在架构和尺寸上均有所不同。我们真正希望展示并澄清行业内的一个误解:我们的自研推理芯片并非仅为 OpenAI 模型服务。Hot Chips 上的结果已经证明,它在开源模型上表现优异,几乎适用于任何 LLM。所有基于 Transformer 的 LLM 模型在其上都具有极佳的性能。

我们还希望展示其编程的便捷性。我们在拿到芯片之前甚至没有查看过这些模型,却在大约两个月内使其正常运行并展现出高性能,并能够呈现结果。这证明它是可编程的、通用的,并非为 OpenAI 模型硬编码。

Roach:这让我好奇:Jalapeño 显然面向 OpenAI 的推理工作负载。它是否仅此用途?你们是否考虑外部客户?OpenAI 硬件的计划是什么?

Ho:诚然,谁都可以使用它。但我们在内部对算力的需求极其强劲。为了满足自身不断增长的需求,我们将耗费大量时间。

随着日活跃用户和周活跃用户的增长、新模型的推出、Codex 新能力的加入,以及各种推理相关业务的推进——还有一些尚未对外公布、但我们内部已经有所了解的新消息——我认为,在相当长的一段时间里,光是满足 OpenAI 自身的算力需求,我们就已经忙不过来了。这并不是说这些算力不能用于其他地方,我相信可以,但我们首先要确保的,是 OpenAI 的算力需求得到满足。

工具与时间线内幕

Roach:聊聊时间线吧。从零到首次 RDL 流片只花了大概九个月,真的非常了不起,而且是在 AI 辅助下完成的。这个速度还能更快吗?这算不算 AI 辅助设计流程所能达到的起点?随着路线图的推进,你们能越跑越快吗?

Ho:我是这么看的:我们确立了一个新的基线。以前的基线大概需要 18 个月到两年,而且那往往还是基于已有 IP 或较为成熟的架构设计。而我们这次完全是从零开始,什么都没有,没有一行现成的代码可以参考。

我们证明的是:一支才华横溢的团队,借助 AI 的帮助,可以在这个新基线上完成工作。至于还能不能更快,取决于你要做什么。

在 Jalapeño 项目上,我们在架构和微架构层面做了一些我认为聪明且务实的取舍,就是为了尽快上市,因为当时的算力需求实在太高了。需求方的态度就是:“这颗芯片多快能给我们?”所以确实做了一些务实的妥协。

如果要做一个复杂得多的芯片——而且技术也在进步,比如 3D 堆叠、co-packaged optics 之类——那时间会更长吗?还会是九个月吗?我不敢说九个月,但肯定比不用 AI 模型要快。而如果是在 Jalapeño 基础上做衍生设计,那应该会快得多,我们可以做得非常非常快。

我们的观点是:我们认为正在树立一个新的基准线——从零开始九个月。之后就是常规的工程起伏。但我们认为,芯片设计领域的每个工程团队都应该把这个当作新的基准,因为这是一个有力的证明:当前实际使用的模型——对我们来说主要是 Codex、Sol,以及 Sol 的前身,现在正转向 Astra——它们能力极强。

从 2025 年 11 月我们开始这项工作的初期,到最终完成 GDS II 数据输出(tape out),模型的能力提升巨大。即便从那个时刻到 5 月芯片开始上线、我们着手进行内核(kernel)优化时,我们自己也惊讶于 Codex 变得多么强大,以及它所能达到的水平。

实话实说:在那两个月的冲刺中,我们在基准测试里榨取出的性能确实让我们有些惊讶,因为之前完全没料到模型在核心优化方面的表现会如此出色。

坦白讲,这一点值得所有人借鉴。这是一个可行的证明。这就是应当使用 AI 的方式。我们没有取代工程师;他们只是变得超级高效。由一支小型的、由顶尖工程师组成的团队,配合大量这类 AI 工具,就能做得更快、更好。我认为这是 AI 时代应当如何开展工程工作的良好范式。

Roach: 感谢这一洞察。我知道至少《汤姆硬件指南》的部分读者可能会想:“在 ChatGPT 里输入‘给我做一个 CPU’,然后它就吐出结果。” 但显然,背后付出的努力远不止于此。

在开发过程中,你们是否使用 Cadence 和 Synopsys 的标准 EDA 工具?它们在流程中处于什么位置?

Ho: 我认为这一点至关重要。总的来说,我的团队在很多方面都非常推崇开源。我们实际上将成果回馈到开源社区,且在我们加入之前就已持有这一立场。

但在最终签核阶段,必须使用标准 EDA 流程,我们也确实做到了,因为要确保结果准确可靠。目前并没有真正可行的替代方案。这背后其实是标准流程与 AI 优化的结合,再叠加优秀工程师的调优。

行业界的关注

Roach:显然,你们与整个行业的硬件厂商都有合作。我很好奇,在 Jalapeño 亮相后,你们是否就这种 AI 辅助流程与他们进行了交流?是否收到过什么反馈?

Ho:是的,我们在亮相前就已与他们建立了联系,因为当时我们已经确信成果已经到位,便率先与部分厂商展开了沟通。回顾完成后,双方的交流明显更加频繁了。

我不想在此剧透太多。但可以说的是,业内对此兴趣浓厚。我们也认为,整个行业都能从中受益,而我们要做的正是推动这种赋能。

我们绝不是那种“我有好东西,但要留给自己”的心态。我们希望让全行业的生产力整体提升。因为更强的算力最终也会惠及我们,所以我们要确保所有人都能享受到这一红利。老实说,很快就能看到相关动态。

Roach:我想确认一下,当你提到看到行业兴趣时,指的是设计流程——也就是你们如何构建芯片的方法,而非简单地“把一堆 Jalapeño 发给所有人”。

Ho:对,正是如此。我们为达成那些时间节点做了什么?我们如何获得最终的性能提升?具体方法是什么?用了什么工具?我认为这些经验也值得向行业开放。

想必你也知道,围绕 AI 芯片设计的创业生态相当活跃,这很好。有很多聪明人正在思考并尝试这一领域。我们有自己的见解,并希望在合适的时候向世界阐明:“这是我们的思路。”

其中的关键是 Codex 和 GPT-6 Astra 的问世。这些是基础,我们可以直接指向它们,不会只是幻灯片或空中楼阁。我们会明确指出做了什么、怎么做到的,以及最终成果如何。一切都会非常具体。

Roach: 所以这本来只是个概念验证,结果比预期快了不少?

Ho: 对。说实话,我可以稍微透露一点内情——当时我们工程师就是那种心态:“哦,我们有这些模型,还挺有意思的,要不要试试?”

然后就试了。并没有什么“我们要做这个,打算这么做”的正式规划,纯粹是自下而上地试了一下。试完他们惊了:“天哪,效果也太好了,快过来看看这个。”慢慢地整个团队都意识到:“这东西真的很有用、很好用,我们就这么干。”

过程中也有公司里的研究人员帮忙。遇到“这个方向它不太行”的时候,我们就会去问他们:“有没有办法微调一下或者做点别的优化?”然后他们会给出答复。

这真是芯片团队和研究团队的一次深度协作。我们本来就坐在一起办公,芯片团队在 OpenAI 内部也被归入研究相关的组织。协作一直非常紧密,我们的协同设计(co-design)最初就是这么来的。

而这个成果某种程度上算是意外之喜。我们一开始并没有把它当作明确目标去做,只是后来发现:“哦,这确实很有用。”工程师们都很喜欢,现在我们也有了一套可行的做法。

Roach: 我想把话题拉远一点。现在大家普遍担心的是供应问题——不只是供应,连做事情的空间都紧张。你们这方面情况如何?我猜你们应该早有预料,提前锁定了供应吧。

Ho: 形势确实很严峻,供应非常紧张。我不想说“我早就告诉过你”,但两年前,Sam(Altman)和我跑遍了各家晶圆厂和供应商,一直在请求:“拜托,多建点产能,多建点,我们将来一定会需要的。”而他们的回应是:“放心吧,这种周期我们见得多了。”

但我认为,大家现在都已经看得很清楚了,正如我们之前讨论的那样,芯片设计出现了一个新的基准线。供应链方面也出现了新基准——无论是内存、逻辑晶圆,还是 SSD 及其他组件,都需要满足新的需求。供应链正在响应,但要真正运转起来需要几年时间。

这一点我们已经关注了一段时间,因此我们一直积极行动,确保供应链已经建立并布局到位。我们认为目前的准备情况良好。

选择 Turing 而非 Vera,以及 OpenAI 的终极目标

Roach: 我在 Tom’s Hardware 报道芯片领域,主要关注 CPU。团队里还有一位同事更侧重图形领域。我觉得一个有意思的点是——我之前阅读了 SemiAnalysis 关于此的文章,其中提到与 Jalapeño 机架配套的 Turing 机架。

当时决定选 Turing 而不是 Vera,是基于什么考虑?考虑到多年来 Nvidia 与 OpenAI 之间紧密的合作关系,我原本预期会选 Vera。Turing 有什么优势使其成为更合适的选择?

Ho: 我们在设计时的核心思路是降低风险并快速推进设计。作为独立部件,Vera 在成熟度上稍显滞后。而 Turing 表现强劲,满足了我们所需的性能,部分合作伙伴对它也有一定经验。

我们没必要在这个环节承担巨大风险,所以没有冒险。正如我先前所说,在 Jalapeño 项目中,我们力求做出务实的决策。我们在性能目标和成本上追求激进,但避免不必要的风险。这看起来是一个符合我们设计决策参数的良好方案。

Roach: 我很好奇内部的想法:目前 Jalapeño 的规模——你们有巨大的计算需求,这些资源可能都还不够用。那最终目标会是“希望有一天所有计算都能跑在我们自己的加速器上”吗?这是终极的愿景吗?

Ho: 我认为最终目标是用在性能和成本上最优的设备。如果结果证明我们内部的设备更好——因为我们可以做协同设计、可以搞定其他部分,并从而获得更好的每瓦性能——那就让它成为现实。

但如果不是,如果市场上有来自芯片供应商或其他合作伙伴的替代品,我们当然乐意将其纳入我们的设备池。我们的目标是降低基础设施成本,这是我们的核心目标。无论最高效的方式是什么,我们都会去做。

我们押注认为,得益于协同设计带来的优势,我们能比外部芯片做得更出色,而 Jalapeño 的初步成果似乎印证了这一点。这种优势会持续下去吗?我相信会。但这会成为我们的终极方向吗?不会。我会说,我们的终极方向是尽可能压低基础设施成本。

Roach:我之所以问这个问题,是因为我知道很多人会评论说:“他们还在用 Nvidia,还在用 AMD。”显然,你们目前什么都在用。

Ho:确实如此。但你们都知道,这是一个持续的过程——简直令人难以置信——是不断的评估。随着部署的深入,我们会持续评估,因此各设备的比例可能会发生变化。

只要我们始终牢记那个终极方向,即“什么是最佳设备”,并且不抱着“这是我们自己造的,所以必须用”的心态——我们也并非如此思考问题——我相信这对我们自己和对最终用户都是正确的选择。

Jalapeño 上的推测解码与性能

Roach:再深入了解一下技术细节——我知道时间很紧——推测解码目前在 Jalapeño 上并未实现。你们有计划在 Jalapeño 上实现它吗?

Ho:硬件层面已经实现了。我们没做基准测试的唯一原因是,我们没有时间去训练用于配合 Jalapeño 进行推测解码的草稿模型。我们内部有能做这件事的模型。这就是我们当时做那个基准测试的唯一原因。

补充一下这个背景。在我们拿到芯片之前,我们本没计划做这个基准测试。后来我们发现它能用,而且表现非常出色。当时我们想:“怎么向外界传达这一点呢?”于是就说:“哦,那个基准测试。那就做吧。”

那段时间简直疯了。距离论文截稿——演示截稿——只剩两个月。当时就在想:“我们能做到吗?能跑完多少个模型?”我们索性放手一搏:多 token 预测肯定来不及做了,但看起来我们的单 token 预测结果可能比多 token 预测还好,那就先发布这些结果吧,至少能说明问题。

多 token 预测能带来 3 到 5 倍的性能提升,这已经在我们手里了。我们有这项技术,会把它用到自己的模型里,等投入生产时就能用上。

但为了跑 benchmark 似乎没必要这么做,因为如果你的单 token 预测都已经超过了当前最先进的多 token 预测,那你的多 token 预测只会好得多。这就是我们当时的考虑。

Roach: 也就是说,你们拿到芯片后只有两个月,而且原本根本没打算公布 benchmark 成绩?

Ho: 对。Hot Chips 的组织者其实非常灵活友好。他们问我们:“今年想来做演讲吗?”我们回答:“还不确定,最晚什么时候能给你们答复?”

他们给我们留了最后一个时段。如果 我们不做,议程就会提前结束之类的。最后,在拿到芯片之后很晚的时候,我们才问:“还能给我们这个名额吗?”他们说:“可以,去吧。”于是我们就上了。

Roach: 另一个问题是关于更长的上下文窗口。如果我没记错,在 SemiAnalysis InferenceX benchmark 里,所有测试都是 8K/1K 的配置。我知道你们没公布过这些数据,但我想你们内部应该测试过更长的上下文窗口。

Ho: 对,内部当然测过。就像我们说过的——我记得其中一张幻灯片里提过——在内部模型上,差距还会进一步拉大。是的,上下文越长、模型越大,Jalapeño 相比市面上其他设备的表现似乎就越好。

我还想强调一点,我们做了大量与 Grace Blackwell 的对比,但那是因为那些是我们能找到的最佳已发布数据。显然,等到实际部署时,系统很可能会采用 Vera Rubin,甚至在部署周期的某些阶段使用 Vera Rubin Ultra。

我们内部确实做过测试,但显然不会公开。这些数据必须由 Nvidia 等机构发布,我们自己不会公布这些结果。

产能爬坡与未来

Roach:我理解没错吧——Jalapeno 在整个下半年将缓慢爬坡,而真正的爆发期在 2027 年...

Ho:对,就是 2027 年。如果我们能做到的话,希望在此之前能先导入少量产量,主要是为了确保一切运转正常,并能在生产环境中完成测试。然后 2027 年才会真正迎来产能的大幅提升。

Roach:回到路线图,你们希望确立一个新的基准。显然已经公布了另外两代产品 [...]Gen 2 即将流片(tape-out)。以后的节奏也是如此吗?是不是应该在明年 Hot Chips 大会上,就能了解到关于 Jalapeño 2 的更多消息?

Ho:我想把这一点说清楚。我不认为应该只按照日历时间机械地安排流片。

我们希望在我们构想中的设备在性能(如能效、原始性能或延迟)上实现某种阶梯式提升时,再进行流片。这在很大程度上取决于技术何时成熟可用。

无论是使用哪一代 HBM,采用哪种 SerDes,还是能否将光通信更靠近硅片,我们的项目进度和流片时间都将取决于相关技术的成熟度。

我们的执行速度可以非常快。我们会背靠背地连续执行吗?我觉得不会,因为技术还做不到,我也不希望流片一个只比上一代好 2% 的产品,因为更换整个机群的硬件成本不值得。但我看到的技术进步节奏其实还挺合理的,我们完全有能力在这个节奏内快速完成开发。

最重要的是制造出合适的设备。你必须花足够的时间去打造正确的产品,弄清楚它应该是什么。一旦明确方向,就快速构建,尽快推向市场。

你必须有足够多的时间去了解什么是下一款最好的设备,这并不是跑步机上例行公事般的事情。我认为我们不希望仅仅为了做而做就在那种循环里。我们希望每做一款设备都能带来真正的阶梯式提升。

Roach:演示中我最感兴趣的幻灯片其实是非常早的部分,你列出了目标,不仅是目标,还列出了非目标。我认为这非常有启发性,因为你必须定义你不想做什么。

Ho:没错。我们的小团队希望在这里对计划非常深思熟虑。我们所做的事情,我们希望产生真正的高影响力,而影响力的北极星指标是:为我们的客户以更低的价格实现更多的智能。这就是我们试图做的事。

我们希望非常仔细地思考实现这一点需要付出什么。正如我所说,如果生态系统可以提供,而我们无法做得更好,那么我们就直接使用生态系统。

我们将始终做我们认为能利用我们协同设计优势、利用我们对趋势的认知并智能地加以利用的事情。

[会议结束]

原始来源: Tom's Hardware

评论 (0)