当英伟达还在用 GB300 巩固 AI 训练与推理市场时OpenAI 突然放出一颗名为 Jalapeño 的 3nm 自研芯片并在 DeepSeek R1 负载上打出“每瓦 AI 吞吐量是 GB300 的 1.7 倍”的成绩。这个数据初看很吓人但先别急着喊“英伟达完了”。如果只看芯片名字Jalapeño 像是随手取的辣椒代号如果只看性能数字又很容易把这件事理解成一场跑分游戏。真正值得关注的是它背后的设计取舍为什么 OpenAI 要用 9 个月做一颗推理芯片为什么拿 GB300 对标以及“每瓦 AI 吞吐量”这个指标为什么正在成为 AI 基础设施竞争的新战场。这篇文章不打算复述新闻而是帮你拆清楚三个问题Jalapeño 的首秀到底证明了多少东西每瓦吞吐量 1.7 倍这个数字在工程上意味着什么以及作为普通开发者和 AI Infra 工程师你可以用什么方式验证类似的能效结论而不是被单一跑分带偏。读完你会得到一个明确判断OpenAI 这次首秀的看点不是“性能碾压”而是“AI 硬件竞争开始从堆算力转向抠能效”。1. 这篇文章真正要解决的问题芯片自研在科技巨头里已经不是新鲜事Google 有 TPUAmazon 有 InferentiaMeta 也有自己的芯片计划。但 OpenAI 一直被视为“模型公司”它的核心竞争力长期被认为是算法和算力采购能力而不是硬件设计。当这样一家公司突然拿出 3nm 自研芯片并且用开源模型 DeepSeek R1 做性能首秀时很多人的第一反应是“OpenAI 是不是要取代英伟达”这个判断太早了。替代英伟达需要改变整个 CUDA 生态、互联协议和部署体系不是一颗芯片能短期完成的。Jalapeño 的首秀真正解决的是 AI 推理成本不可控的问题。OpenAI 的 API 服务每天要处理海量推理请求GPU 功耗高、采购贵、供应紧张。如果能在同样的电费下多跑 1.7 倍的 token那么对服务成本的影响是巨大的。所以这篇文章重点解决的痛点有四个为什么每瓦 AI 吞吐量比总吞吐量更重要“DeepSeek R1 每瓦吞吐量是 GB300 的 1.7 倍”这句话中哪些部分是事实哪些部分是营销话术如果你负责 AI 基础设施选型应该如何评估一颗芯片或一个推理服务如果你想在自己的机器上复现类似的能效评测该怎么做无论你是做应用开发的程序员还是关注 AI Infra 的架构师这篇文章都会给你一套判断 AI 硬件价值的思路而不是让你被动接受厂商的战报。2. 基础概念与核心原理要理解这次发布先要分清几个概念GPU、推理芯片、每瓦吞吐量以及为什么选 DeepSeek R1 做基准。2.1 从训练芯片到推理芯片传统意义上的 GPU比如英伟达 H100、GB300最初设计目标是可以同时支持训练和推理。训练需要高精度计算和大规模矩阵运算推理则更看重延迟、吞吐量和功耗。OpenAI 的 Jalapeño 定位很明确面向推理。这意味着它可以牺牲一部分训练灵活性换取更高的能效和更低的生产成本。3nm 工艺是这颗芯片的重要标签。工艺越先进同样面积上能塞进的晶体管越多相同功耗下能跑出的算力也越高。但 3nm 芯片设计周期通常很长Jalapeño 用 9 个月完成说明它的架构更聚焦没有做训练芯片那种“大而全”的功能覆盖而是围绕 Transformer 解码、Attention、KV Cache 这些推理核心操作做优化。2.2 每瓦 AI 吞吐量是什么每瓦 AI 吞吐量的单位通常是 tokens/s/W也就是每秒钟能处理多少个 token再除以功耗。这个指标关心的不是“你有多快”而是“你花一度电能换来多少智能”。理解这一点可以把芯片比作汽车。GB300 是一台大排量 SUV马力大但每百公里油耗也高Jalapeño 更像一台混动小车极限速度未必比 SUV 快但每升油跑的里程更远。自动驾驶出租车公司会关心这两种车怎么选AI 云服务商也会关心。对于普通开发者这个指标直接决定 API 价格。如果 OpenAI 用更低的推理成本提供服务最终用户可能会看到更低的价格或更长的上下文窗口。换句话说1.7 倍每瓦吞吐量带来的不是“AI 更强”而是“AI 更便宜”。2.3 为什么用 DeepSeek R1 做基准DeepSeek R1 是当前开源模型的重要代表而且 R1 在推理任务上有一定特殊要求。它的推理链路常包含思维链需要较长的解码长度对 KV Cache 和显存带宽的压力很大。用这样的模型做基准能检验芯片在长上下文、高并发推理下的真实表现。与此同时DeepSeek R1 还有很多蒸馏版本比如 DeepSeek-R1-Distill-Qwen-1.5B。这类小模型非常适合在本地跑评测因为它们显存占用小、启动快适合用来演示“每瓦吞吐量”的测量方法。后文我们就是基于这类小模型给出一套可复现的本地能效评测思路。3. 发布背景与核心信息从公开信息看OpenAI 在设计 Jalapeño 时的目标非常明确用更快的速度做出一颗面向推理场景的芯片。9 个月完成 3nm 设计这个速度在芯片行业里并不常见说明团队没有选择从头设计复杂架构而是优先满足自己业务的刚性需求。性能首秀选择 DeepSeek R1而不是 GPT 系列也是一个耐人寻味的信号。一方面DeepSeek R1 是开源模型评测结果更容易被外部验证另一方面DeepSeek R1 的推理模式非常考验服务端资源如果芯片能在这种负载下高效运行那么处理其他常见 Transformer 模型时也不会太差。对比对象 GB300 也是很关键的。GB300 是英伟达目前面向大规模 AI 集群的核心产品之一性能强但功耗和价格都很高。OpenAI 把 Jalapeño 和 GB300 放在同一张表里比较说明它想挑战的是推理市场对英伟达的依赖。在生态层面OpenAI 最近还在推进 Codex Harness 等工程工具的建设配合 API 的开放生态我们可以看到一个趋势OpenAI 不只是在做模型而是在搭建从芯片、训练框架到推理服务、开发生态的全栈能力。Jalapeño 是这条链路里最底层的一块拼图。当然这些背景信息并不完整。ChatGPT 之外的很多产品细节、基准测试方法学和部署规模目前公开资料有限。更稳妥的判断是OpenAI 正在用一颗自研推理芯片试探 AI 基础设施的边界同时也给英伟达施加生态压力。4. 性能指标拆解1.7 倍背后的三个关键词“DeepSeek R1 每瓦 AI 吞吐量是 GB300 的 1.7 倍”这句话很容易被理解为“Jalapeño 性能是 GB300 的 1.7 倍”。但真实含义要窄得多。我们用三个关键词来还原它。4.1 是“每瓦”不是“总吞吐”如果只说总吞吐GB300 很可能仍然大幅领先。毕竟 GB300 是一颗功耗极高的超大规模芯片它的绝对算力不是一颗面向推理的小芯片能比的。Jalapeño 领先的是“单位功耗下的吞吐量”也就是能效。这意味着在同样的功耗预算下Jalapeño 能处理的 token 更多但单次推理任务的极致性能未必更高。这带来一个直接后果如果 OpenAI 把 Jalapeño 部署在自己的数据中心它的单位推理成本会显著下降但如果被要求跑一个高难度训练任务Jalapeño 未必比 GB300 有优势。4.2 是“DeepSeek R1 负载”不是“所有模型”芯片性能必须绑定工作负载。Jalapeño 可能在 DeepSeek R1 这种高推理强度负载下表现突出但在短问题、低并发、图像生成或者多模态模型上表现可能完全不同。因此1.7 倍只能说明“在这样的模型、这样的量化等级、这样的推理模式下能效优势是存在的”。如果只看表面很容易误以为 OpenAI 已经造出了一颗全场景无敌的芯片。实际芯片设计里不同模型会导致 Attention、MLP、KV Cache 的瓶颈分布完全不同一颗芯片不可能在每种负载下都最优。4.3 是“GB300 对比”不是“H100 对比”英伟达的产品线也有能效梯度。GB300 面向的是“高算力集群”本身并不是为最低功耗设计。如果拿同样的模型去对比英伟达的 L40S、A100 或者消费级显卡Jalapeño 的能效优势倍数可能会变化。所以1.7 倍是一种“针对性对比”不是“全行业横扫”。为了让这个拆解更直观可以用下面的表来区分可能产生的解读1.7 倍能支持的结论1.7 倍不能支持的结论OpenAI 自研芯片性能碾压英伟达在 DeepSeek R1 推理负载下每瓦吞吐量更高总算力更强、训练速度更快所有 AI 任务都会更快推理型任务能效有优势多模态、训练或其他负载同样最优所有开发者能立刻用上OpenAI 可从中降低 API 推理成本普通用户能直接购买该芯片英伟达会被替代GB300 在特定场景下不再是最优解CUDA 生态和集群优势会被快速瓦解总结一下1.7 倍是 OpenAI 给市场展示的一个“角度”它证明自研推理芯片在特定场景下可行但不等于全面超越。看明白这一点你才不会在技术选型时被厂商战报带偏。5. 开发者如何验证类似的能效结论一个可复现的评测思路作为普通开发者我们没有机会马上拿到 Jalapeño 实测但我们可以用“测量每瓦吞吐量”的思路在自己的 GPU 或 CPU 机器上跑一遍类似评测。下面我们以 DeepSeek-R1-Distill-Qwen-1.5B 的 Q4_K_M 量化模型为例说明整个流程。5.1 准备环境建议使用 Linux 系统并安装 Python、Git、CMake、GCC 等基础工具。如果你要在 NVIDIA GPU 上测功耗还要确保nvidia-smi可用如果你要在 CPU 上测可以使用 Linux 的功耗统计接口但精度不如数据中心电量计。这里我们以 GPU 为例。先用下面的命令安装 llama.cpp或者使用你自己已经编译好的版本# 在 Linux 终端中执行 git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp mkdir build cd build cmake .. -DLLAMA_CUBLASON make -j$(nproc)编译完成后llama-cli和llama-bench会生成在build/bin目录下。如果你的显卡不支持 CUDA 或者没有安装 CUDA 工具链可以选择去掉-DLLAMA_CUBLASON走 CPU 模式。后面所有命令行请以你实际的编译产物路径为准。为什么需要编译llama.cpp 的性能和硬件指令集高度相关。从源码编译能帮你启用本机的加速指令比如 AVX2、AVX512 或 CUDA 加速。如果直接下载预编译包功能上没问题但可能无法发挥最高性能反而让评测结果失真。5.2 下载 DeepSeek R1 蒸馏模型这里我们使用热词里提到的DeepSeek-R1-Distill-Qwen-1.5B模型并选择 Q4_K_M 量化文件。Q4_K_M 是一种常用的 4-bit 量化格式在模型体积和推理质量之间比较平衡适合跑推理评测。你可以在 Hugging Face 上搜索对应模型的 GGUF 版本然后用huggingface-cli下载。下面是一个示例命令实际仓库名和文件名请以下载页面为准pip install -U huggingface_hub huggingface-cli download unsloth/DeepSeek-R1-Distill-Qwen-1.5B-GGUF \ --include *.Q4_K_M.gguf \ --local-dir ./models下载完以后确认文件存在且大小合理。如果你遇到下载超时或网络中断可以先用小文件测试连通性或者换一个镜像源。这里只演示模型获取方式不涉及任何特殊网络配置。5.3 用 llama-bench 记录 token 吞吐量llama-bench是 llama.cpp 自带的基准工具可以输出tokens per second。我们先跑一个短测试cd llama.cpp/build/bin ./llama-bench \ -m ../../../models/DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M.gguf \ -p What is the capital of France? \ -n 128 \ -t 8参数含义-m模型文件路径-p提示词也就是输入文本-n生成多少个 token-tCPU 线程数如果用的是 GPU可以适当调低如果你的版本里没有llama-bench可以用llama-cli代替并在命令中增加-n 128来限制生成长度。输出结果中会包含类似avg token/s的数据。这个数据就是“每秒 token 数”。5.4 记录功耗并计算每瓦吞吐量接下来我们用 Python 脚本在推理期间采样功耗然后计算每瓦吞吐量。先保存下面的脚本到measure_power.pyimport subprocess import time import statistics def get_gpu_power_watt(): output subprocess.check_output( [nvidia-smi, --query-gpupower.draw, --formatcsv,noheader,nounits] ).decode().strip() return float(output) power_samples [] # 这里替换成你的实际 bench 命令 fold_command [ ./llama-bench, -m, ../../../models/DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M.gguf, -p, What is the capital of France?, -n, 256, -t, 8 ] proc subprocess.Popen(fold_command) while proc.poll() is None: try: power_samples.append(get_gpu_power_watt()) except Exception: # nvidia-smi 可能 transiently 失败跳过即可 pass time.sleep(0.5) if power_samples: avg_power statistics.mean(power_samples) print(f平均功耗: {avg_power:.1f} W) else: print(未采集到功耗数据)运行前你需要在measure_power.py里修正fold_command的模型路径。运行方式python3 measure_power.py脚本会在 llama-bench 跑完的同时输出推理期间的平均功耗。然后我们手动计算# 假设你从 llama-bench 得到吞吐量 52.3 tokens/s # 假设平均功耗是 17.2 W tokens_per_sec 52.3 avg_power 17.2 print(f每瓦吞吐量 {tokens_per_sec / avg_power:.2f} tokens/s/W)这里只是演示计算方式不同机器数据差异很大。如果你在同一台机器上用同一个功耗采样工具测量不同芯片就能对比谁在“单位功耗吞吐量”上更高效。要注意的是这种评测方式只能说明“这台机器跑这个模型”的能效不能直接推导出 OpenAI 每瓦 1.7 倍的结论但能帮你建立自己的判断基准。5.5 让评测更公平的三个关键点统一模型和量化等级不要用不同量化格式做对比否则结果没有意义。统一输入输出长度DeepSeek R1 的思维链会让生成长度差异巨大必须固定-n和-p。多次运行取中位数第一次运行可能包含模型加载、缓存预热等开销建议手动跑一遍热身后再正式记录。6. 运行结果与效果验证完成上面的评测后你大概会得到两类结果一类是 llama-bench 输出的 token/s另一类是采样脚本输出的平均功耗。通过两个数字的比值就得到每瓦吞吐量。一个典型的运行输出可能类似这样model size params backend threads n_batch t_prompt t_gen ... DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M 1.75 GiB 1.7 B CPU 8 512 58.23 ms 52.31 ms/tokengen列的单位是ms/token把它换算成 token/s 就是 1000 除以它。例如上面输出的52.31 ms/token表示大约 19.1 token/s这个数字不一定快但只是说明你的本机性能。如果你改成 GPU 后端速度通常会大幅提升。如何判断这次评测是成功的llama-bench 正常退出了没有报模型加载错误。power_samples里有数据不是空数组。计算出的每瓦吞吐量是一个正数通常在 0.5 到 5 之间取决于硬件和模型规模。如果运行失败先从这几个方向排查# 检查模型文件是否完整 ls -lh ../../../models/DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M.gguf # 检查 nvidia-smi 是否能看到 GPU nvidia-smi --query-gpuname,power.draw --formatcsv # 如果 CUDA 编译后找不到 libcuda可以确认环境变量 echo $LD_LIBRARY_PATH模型路径错误、仓库下载不完整、驱动版本过低是三个最常见的失败原因。先用命令行确认模型文件存在再看 llama.cpp 是否输出了 CUDA 相关信息。如果是纯 CPU 模式功耗采样会更难建议用整机功耗减去基础功耗来近似而不是只看 GPU 功耗。7. 常见问题与误区排查围绕 OpenAI 自研芯片和每瓦吞吐量我整理了下面几个高频疑问用表格形式列出方便你收藏后反复查看。问题现象与困惑可能原因排查或解读方式更合理的做法以为 1.7 倍代表全面超越混淆了“每瓦吞吐量”和“总算力”查看指标定义和测试负载同时看总吞吐、延迟和功耗三个维度想在本地复现 OpenAI 的评测没有 Jalapeño 芯片和同款集群环境明确本地评测只是方法演练用开源模型和你自己的 GPU/CPU 跑出相对数据下载模型时找不到同款文件Hugging Face 仓库更新或名称变了到页面搜索 DeepSeek-R1-Distill-Qwen-1.5BGGUF选用相近的 Q4_K_M 版本即可测量功耗波动很大推理任务短、采样频率低、后台有其他进程延长生成 token 数增加到 256 或 512多次运行取中位数并关闭不必要的后台任务以为芯片厂商都应该追求每瓦吞吐量最高不同场景目标完全不同训练任务更重视绝对算力和显存推理服务商优先看能效科研机构可能优先看性能除了表格里的细节还有一个常见误区是“OpenAI 自研芯片会让普通开发者立刻获得更便宜的 API”。从逻辑上看自研芯片确实能降低成本但硬件部署、软件适配和集群建设都需要时间。短期内你可能不会看到 API 价格断崖式下降更可能看到上下文窗口变长、服务吞吐更平稳等间接变化。另一个误区是“既然 OpenAI 做了芯片就可以完全不受英伟达影响”。芯片只是硬件的一半互联、散热、驱动、编译器和运行库同样重要。一颗芯片要嵌入到大型数据中心需要考虑机架设计、网络拓扑、故障隔离等系统工程。这些都不是 9 个月能全部完成的所以保守判断是OpenAI 会先在内部场景使用 Jalapeño再逐步把能力投射到 API 服务中。8. 最佳实践与工程建议这一节写给想参与 AI 基础设施评估和建设的读者。无论是团队选型还是个人学习下面几条建议都能帮助你少踩坑。8.1 把每瓦吞吐量纳入核心指标如果你的业务是长时间跑推理服务那么只看 token/s 是不够的。功耗直接决定了电费和散热成本而电费又是推理服务最大的长期开销之一。建议在 Benchmark 报告里增加每瓦吞吐量这一列并在供应商对比中明确写出工作负载类型。具体做法准备一组标准 prompt固定输出长度在同一型号的服务器上跑多次记录平均功耗和平均吞吐量。这个指标没有行业统一标准但只要对比双方使用同样的条件和测量方式就有决策价值。8.2 使用标准化负载做评测DeepSeek R1、Llama 3.1 这类模型已经是开源社区的通用基准建议选用一到两个代表性模型测“长推理链”和“短对话”两种场景。不要只测单条 Easy Prompt因为在真实场景里长上下文和思维链解码往往是性能瓶颈。在测试里还要固定参数batch size、KV Cache 用量、量化等级、并发数。不同参数下芯片的能效结论很可能完全相反。把这些参数写进测试报告后续回顾和对比才有意义。8.3 谨慎对待芯片新品先算 TCO所谓 TCO即总拥有成本包含采购成本、功耗成本、运维成本、优化软件的时间和人力成本。一颗芯片即使每瓦吞吐量很高如果生态不成熟需要花大量时间做算子适配和工具链改造总成本也未必更低。更稳妥的判断是在引入新硬件前先用你的核心业务模型跑一个 Benchmark把性能、功耗、可用性和工具链成熟度都列出来再决定是否小规模试点。不要因为一个“1.7 倍”就冲进实验室。8.4 关注生态和开源工具链变化OpenAI 在自研芯片之外还在推进 Codex Harness 等开源工程化项目。当一家模型公司开始开放工具链时往往意味着它希望把开发者拉进自己的基础设施体系。对开发者来说这意味着未来可能可以用同一套 API 调用底层不同芯片而不必关心芯片具体型号。如果你在做 Agent 或 AI 应用开发现阶段不需要去学芯片设计但需要学习如何观察 API 的返回速度、延迟和成本。这些指标会直接反映底层基础设施的优化程度。一个更关注能效的平台长期来看会把红利让给应用开发者。9. 长远判断与开发者下一步回到开头的问题Jalapeño 的首秀是改变游戏规则吗我的判断是它没有立刻改变游戏规则但给整个行业安装了一个“能效优先”的思维锚点。以后任何 AI 芯片发布如果只谈峰值算力、不谈每瓦对应模型吞吐量都会被市场追问一句那单位功耗下的真实吞吐是多少对开发者来说接下来可以做的事情很具体用本文第 5 节的评测思路在你自己现有服务器或开发机上跑一个模型算出每瓦吞吐量。这份数据会成为你未来比较新硬件的参照物。追踪 DeepSeek R1 蒸馏模型的迭代特别是 GGUF 量化版本这能帮你快速做本地实验。持续关注 OpenAI 的 API 定价和上下文窗口变化。如果自研芯片的能效红利开始外溢你会最先在价格和响应速度上感知到。学习英伟达 GB300 和 OpenAI 自研芯片的架构差异时不要只看晶体管数量重点关注它们在 Transformer 解码链路里的具体优化比如 KV Cache 容量、显存带宽和互联方式。AI 基础设施的竞争已经不再只是“谁的模型更聪明”还包括“谁的电费更低、谁的吞吐更稳”。OpenAI 用 Jalapeño 这枚辣椒给整个行业提了一个醒真正的算力霸权不只是性能霸权更是能源效率霸权。至于这枚辣椒最终能改变多少市场格局要看它能不能从实验室走进真实机房变成开发者每一个 API 调用里更低的延迟和更稳的响应。 OpenAI自研芯片Jalapeño：每瓦AI吞吐量1.7倍背后的能效博弈
当英伟达还在用 GB300 巩固 AI 训练与推理市场时OpenAI 突然放出一颗名为 Jalapeño 的 3nm 自研芯片并在 DeepSeek R1 负载上打出“每瓦 AI 吞吐量是 GB300 的 1.7 倍”的成绩。这个数据初看很吓人但先别急着喊“英伟达完了”。如果只看芯片名字Jalapeño 像是随手取的辣椒代号如果只看性能数字又很容易把这件事理解成一场跑分游戏。真正值得关注的是它背后的设计取舍为什么 OpenAI 要用 9 个月做一颗推理芯片为什么拿 GB300 对标以及“每瓦 AI 吞吐量”这个指标为什么正在成为 AI 基础设施竞争的新战场。这篇文章不打算复述新闻而是帮你拆清楚三个问题Jalapeño 的首秀到底证明了多少东西每瓦吞吐量 1.7 倍这个数字在工程上意味着什么以及作为普通开发者和 AI Infra 工程师你可以用什么方式验证类似的能效结论而不是被单一跑分带偏。读完你会得到一个明确判断OpenAI 这次首秀的看点不是“性能碾压”而是“AI 硬件竞争开始从堆算力转向抠能效”。1. 这篇文章真正要解决的问题芯片自研在科技巨头里已经不是新鲜事Google 有 TPUAmazon 有 InferentiaMeta 也有自己的芯片计划。但 OpenAI 一直被视为“模型公司”它的核心竞争力长期被认为是算法和算力采购能力而不是硬件设计。当这样一家公司突然拿出 3nm 自研芯片并且用开源模型 DeepSeek R1 做性能首秀时很多人的第一反应是“OpenAI 是不是要取代英伟达”这个判断太早了。替代英伟达需要改变整个 CUDA 生态、互联协议和部署体系不是一颗芯片能短期完成的。Jalapeño 的首秀真正解决的是 AI 推理成本不可控的问题。OpenAI 的 API 服务每天要处理海量推理请求GPU 功耗高、采购贵、供应紧张。如果能在同样的电费下多跑 1.7 倍的 token那么对服务成本的影响是巨大的。所以这篇文章重点解决的痛点有四个为什么每瓦 AI 吞吐量比总吞吐量更重要“DeepSeek R1 每瓦吞吐量是 GB300 的 1.7 倍”这句话中哪些部分是事实哪些部分是营销话术如果你负责 AI 基础设施选型应该如何评估一颗芯片或一个推理服务如果你想在自己的机器上复现类似的能效评测该怎么做无论你是做应用开发的程序员还是关注 AI Infra 的架构师这篇文章都会给你一套判断 AI 硬件价值的思路而不是让你被动接受厂商的战报。2. 基础概念与核心原理要理解这次发布先要分清几个概念GPU、推理芯片、每瓦吞吐量以及为什么选 DeepSeek R1 做基准。2.1 从训练芯片到推理芯片传统意义上的 GPU比如英伟达 H100、GB300最初设计目标是可以同时支持训练和推理。训练需要高精度计算和大规模矩阵运算推理则更看重延迟、吞吐量和功耗。OpenAI 的 Jalapeño 定位很明确面向推理。这意味着它可以牺牲一部分训练灵活性换取更高的能效和更低的生产成本。3nm 工艺是这颗芯片的重要标签。工艺越先进同样面积上能塞进的晶体管越多相同功耗下能跑出的算力也越高。但 3nm 芯片设计周期通常很长Jalapeño 用 9 个月完成说明它的架构更聚焦没有做训练芯片那种“大而全”的功能覆盖而是围绕 Transformer 解码、Attention、KV Cache 这些推理核心操作做优化。2.2 每瓦 AI 吞吐量是什么每瓦 AI 吞吐量的单位通常是 tokens/s/W也就是每秒钟能处理多少个 token再除以功耗。这个指标关心的不是“你有多快”而是“你花一度电能换来多少智能”。理解这一点可以把芯片比作汽车。GB300 是一台大排量 SUV马力大但每百公里油耗也高Jalapeño 更像一台混动小车极限速度未必比 SUV 快但每升油跑的里程更远。自动驾驶出租车公司会关心这两种车怎么选AI 云服务商也会关心。对于普通开发者这个指标直接决定 API 价格。如果 OpenAI 用更低的推理成本提供服务最终用户可能会看到更低的价格或更长的上下文窗口。换句话说1.7 倍每瓦吞吐量带来的不是“AI 更强”而是“AI 更便宜”。2.3 为什么用 DeepSeek R1 做基准DeepSeek R1 是当前开源模型的重要代表而且 R1 在推理任务上有一定特殊要求。它的推理链路常包含思维链需要较长的解码长度对 KV Cache 和显存带宽的压力很大。用这样的模型做基准能检验芯片在长上下文、高并发推理下的真实表现。与此同时DeepSeek R1 还有很多蒸馏版本比如 DeepSeek-R1-Distill-Qwen-1.5B。这类小模型非常适合在本地跑评测因为它们显存占用小、启动快适合用来演示“每瓦吞吐量”的测量方法。后文我们就是基于这类小模型给出一套可复现的本地能效评测思路。3. 发布背景与核心信息从公开信息看OpenAI 在设计 Jalapeño 时的目标非常明确用更快的速度做出一颗面向推理场景的芯片。9 个月完成 3nm 设计这个速度在芯片行业里并不常见说明团队没有选择从头设计复杂架构而是优先满足自己业务的刚性需求。性能首秀选择 DeepSeek R1而不是 GPT 系列也是一个耐人寻味的信号。一方面DeepSeek R1 是开源模型评测结果更容易被外部验证另一方面DeepSeek R1 的推理模式非常考验服务端资源如果芯片能在这种负载下高效运行那么处理其他常见 Transformer 模型时也不会太差。对比对象 GB300 也是很关键的。GB300 是英伟达目前面向大规模 AI 集群的核心产品之一性能强但功耗和价格都很高。OpenAI 把 Jalapeño 和 GB300 放在同一张表里比较说明它想挑战的是推理市场对英伟达的依赖。在生态层面OpenAI 最近还在推进 Codex Harness 等工程工具的建设配合 API 的开放生态我们可以看到一个趋势OpenAI 不只是在做模型而是在搭建从芯片、训练框架到推理服务、开发生态的全栈能力。Jalapeño 是这条链路里最底层的一块拼图。当然这些背景信息并不完整。ChatGPT 之外的很多产品细节、基准测试方法学和部署规模目前公开资料有限。更稳妥的判断是OpenAI 正在用一颗自研推理芯片试探 AI 基础设施的边界同时也给英伟达施加生态压力。4. 性能指标拆解1.7 倍背后的三个关键词“DeepSeek R1 每瓦 AI 吞吐量是 GB300 的 1.7 倍”这句话很容易被理解为“Jalapeño 性能是 GB300 的 1.7 倍”。但真实含义要窄得多。我们用三个关键词来还原它。4.1 是“每瓦”不是“总吞吐”如果只说总吞吐GB300 很可能仍然大幅领先。毕竟 GB300 是一颗功耗极高的超大规模芯片它的绝对算力不是一颗面向推理的小芯片能比的。Jalapeño 领先的是“单位功耗下的吞吐量”也就是能效。这意味着在同样的功耗预算下Jalapeño 能处理的 token 更多但单次推理任务的极致性能未必更高。这带来一个直接后果如果 OpenAI 把 Jalapeño 部署在自己的数据中心它的单位推理成本会显著下降但如果被要求跑一个高难度训练任务Jalapeño 未必比 GB300 有优势。4.2 是“DeepSeek R1 负载”不是“所有模型”芯片性能必须绑定工作负载。Jalapeño 可能在 DeepSeek R1 这种高推理强度负载下表现突出但在短问题、低并发、图像生成或者多模态模型上表现可能完全不同。因此1.7 倍只能说明“在这样的模型、这样的量化等级、这样的推理模式下能效优势是存在的”。如果只看表面很容易误以为 OpenAI 已经造出了一颗全场景无敌的芯片。实际芯片设计里不同模型会导致 Attention、MLP、KV Cache 的瓶颈分布完全不同一颗芯片不可能在每种负载下都最优。4.3 是“GB300 对比”不是“H100 对比”英伟达的产品线也有能效梯度。GB300 面向的是“高算力集群”本身并不是为最低功耗设计。如果拿同样的模型去对比英伟达的 L40S、A100 或者消费级显卡Jalapeño 的能效优势倍数可能会变化。所以1.7 倍是一种“针对性对比”不是“全行业横扫”。为了让这个拆解更直观可以用下面的表来区分可能产生的解读1.7 倍能支持的结论1.7 倍不能支持的结论OpenAI 自研芯片性能碾压英伟达在 DeepSeek R1 推理负载下每瓦吞吐量更高总算力更强、训练速度更快所有 AI 任务都会更快推理型任务能效有优势多模态、训练或其他负载同样最优所有开发者能立刻用上OpenAI 可从中降低 API 推理成本普通用户能直接购买该芯片英伟达会被替代GB300 在特定场景下不再是最优解CUDA 生态和集群优势会被快速瓦解总结一下1.7 倍是 OpenAI 给市场展示的一个“角度”它证明自研推理芯片在特定场景下可行但不等于全面超越。看明白这一点你才不会在技术选型时被厂商战报带偏。5. 开发者如何验证类似的能效结论一个可复现的评测思路作为普通开发者我们没有机会马上拿到 Jalapeño 实测但我们可以用“测量每瓦吞吐量”的思路在自己的 GPU 或 CPU 机器上跑一遍类似评测。下面我们以 DeepSeek-R1-Distill-Qwen-1.5B 的 Q4_K_M 量化模型为例说明整个流程。5.1 准备环境建议使用 Linux 系统并安装 Python、Git、CMake、GCC 等基础工具。如果你要在 NVIDIA GPU 上测功耗还要确保nvidia-smi可用如果你要在 CPU 上测可以使用 Linux 的功耗统计接口但精度不如数据中心电量计。这里我们以 GPU 为例。先用下面的命令安装 llama.cpp或者使用你自己已经编译好的版本# 在 Linux 终端中执行 git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp mkdir build cd build cmake .. -DLLAMA_CUBLASON make -j$(nproc)编译完成后llama-cli和llama-bench会生成在build/bin目录下。如果你的显卡不支持 CUDA 或者没有安装 CUDA 工具链可以选择去掉-DLLAMA_CUBLASON走 CPU 模式。后面所有命令行请以你实际的编译产物路径为准。为什么需要编译llama.cpp 的性能和硬件指令集高度相关。从源码编译能帮你启用本机的加速指令比如 AVX2、AVX512 或 CUDA 加速。如果直接下载预编译包功能上没问题但可能无法发挥最高性能反而让评测结果失真。5.2 下载 DeepSeek R1 蒸馏模型这里我们使用热词里提到的DeepSeek-R1-Distill-Qwen-1.5B模型并选择 Q4_K_M 量化文件。Q4_K_M 是一种常用的 4-bit 量化格式在模型体积和推理质量之间比较平衡适合跑推理评测。你可以在 Hugging Face 上搜索对应模型的 GGUF 版本然后用huggingface-cli下载。下面是一个示例命令实际仓库名和文件名请以下载页面为准pip install -U huggingface_hub huggingface-cli download unsloth/DeepSeek-R1-Distill-Qwen-1.5B-GGUF \ --include *.Q4_K_M.gguf \ --local-dir ./models下载完以后确认文件存在且大小合理。如果你遇到下载超时或网络中断可以先用小文件测试连通性或者换一个镜像源。这里只演示模型获取方式不涉及任何特殊网络配置。5.3 用 llama-bench 记录 token 吞吐量llama-bench是 llama.cpp 自带的基准工具可以输出tokens per second。我们先跑一个短测试cd llama.cpp/build/bin ./llama-bench \ -m ../../../models/DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M.gguf \ -p What is the capital of France? \ -n 128 \ -t 8参数含义-m模型文件路径-p提示词也就是输入文本-n生成多少个 token-tCPU 线程数如果用的是 GPU可以适当调低如果你的版本里没有llama-bench可以用llama-cli代替并在命令中增加-n 128来限制生成长度。输出结果中会包含类似avg token/s的数据。这个数据就是“每秒 token 数”。5.4 记录功耗并计算每瓦吞吐量接下来我们用 Python 脚本在推理期间采样功耗然后计算每瓦吞吐量。先保存下面的脚本到measure_power.pyimport subprocess import time import statistics def get_gpu_power_watt(): output subprocess.check_output( [nvidia-smi, --query-gpupower.draw, --formatcsv,noheader,nounits] ).decode().strip() return float(output) power_samples [] # 这里替换成你的实际 bench 命令 fold_command [ ./llama-bench, -m, ../../../models/DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M.gguf, -p, What is the capital of France?, -n, 256, -t, 8 ] proc subprocess.Popen(fold_command) while proc.poll() is None: try: power_samples.append(get_gpu_power_watt()) except Exception: # nvidia-smi 可能 transiently 失败跳过即可 pass time.sleep(0.5) if power_samples: avg_power statistics.mean(power_samples) print(f平均功耗: {avg_power:.1f} W) else: print(未采集到功耗数据)运行前你需要在measure_power.py里修正fold_command的模型路径。运行方式python3 measure_power.py脚本会在 llama-bench 跑完的同时输出推理期间的平均功耗。然后我们手动计算# 假设你从 llama-bench 得到吞吐量 52.3 tokens/s # 假设平均功耗是 17.2 W tokens_per_sec 52.3 avg_power 17.2 print(f每瓦吞吐量 {tokens_per_sec / avg_power:.2f} tokens/s/W)这里只是演示计算方式不同机器数据差异很大。如果你在同一台机器上用同一个功耗采样工具测量不同芯片就能对比谁在“单位功耗吞吐量”上更高效。要注意的是这种评测方式只能说明“这台机器跑这个模型”的能效不能直接推导出 OpenAI 每瓦 1.7 倍的结论但能帮你建立自己的判断基准。5.5 让评测更公平的三个关键点统一模型和量化等级不要用不同量化格式做对比否则结果没有意义。统一输入输出长度DeepSeek R1 的思维链会让生成长度差异巨大必须固定-n和-p。多次运行取中位数第一次运行可能包含模型加载、缓存预热等开销建议手动跑一遍热身后再正式记录。6. 运行结果与效果验证完成上面的评测后你大概会得到两类结果一类是 llama-bench 输出的 token/s另一类是采样脚本输出的平均功耗。通过两个数字的比值就得到每瓦吞吐量。一个典型的运行输出可能类似这样model size params backend threads n_batch t_prompt t_gen ... DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M 1.75 GiB 1.7 B CPU 8 512 58.23 ms 52.31 ms/tokengen列的单位是ms/token把它换算成 token/s 就是 1000 除以它。例如上面输出的52.31 ms/token表示大约 19.1 token/s这个数字不一定快但只是说明你的本机性能。如果你改成 GPU 后端速度通常会大幅提升。如何判断这次评测是成功的llama-bench 正常退出了没有报模型加载错误。power_samples里有数据不是空数组。计算出的每瓦吞吐量是一个正数通常在 0.5 到 5 之间取决于硬件和模型规模。如果运行失败先从这几个方向排查# 检查模型文件是否完整 ls -lh ../../../models/DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M.gguf # 检查 nvidia-smi 是否能看到 GPU nvidia-smi --query-gpuname,power.draw --formatcsv # 如果 CUDA 编译后找不到 libcuda可以确认环境变量 echo $LD_LIBRARY_PATH模型路径错误、仓库下载不完整、驱动版本过低是三个最常见的失败原因。先用命令行确认模型文件存在再看 llama.cpp 是否输出了 CUDA 相关信息。如果是纯 CPU 模式功耗采样会更难建议用整机功耗减去基础功耗来近似而不是只看 GPU 功耗。7. 常见问题与误区排查围绕 OpenAI 自研芯片和每瓦吞吐量我整理了下面几个高频疑问用表格形式列出方便你收藏后反复查看。问题现象与困惑可能原因排查或解读方式更合理的做法以为 1.7 倍代表全面超越混淆了“每瓦吞吐量”和“总算力”查看指标定义和测试负载同时看总吞吐、延迟和功耗三个维度想在本地复现 OpenAI 的评测没有 Jalapeño 芯片和同款集群环境明确本地评测只是方法演练用开源模型和你自己的 GPU/CPU 跑出相对数据下载模型时找不到同款文件Hugging Face 仓库更新或名称变了到页面搜索 DeepSeek-R1-Distill-Qwen-1.5BGGUF选用相近的 Q4_K_M 版本即可测量功耗波动很大推理任务短、采样频率低、后台有其他进程延长生成 token 数增加到 256 或 512多次运行取中位数并关闭不必要的后台任务以为芯片厂商都应该追求每瓦吞吐量最高不同场景目标完全不同训练任务更重视绝对算力和显存推理服务商优先看能效科研机构可能优先看性能除了表格里的细节还有一个常见误区是“OpenAI 自研芯片会让普通开发者立刻获得更便宜的 API”。从逻辑上看自研芯片确实能降低成本但硬件部署、软件适配和集群建设都需要时间。短期内你可能不会看到 API 价格断崖式下降更可能看到上下文窗口变长、服务吞吐更平稳等间接变化。另一个误区是“既然 OpenAI 做了芯片就可以完全不受英伟达影响”。芯片只是硬件的一半互联、散热、驱动、编译器和运行库同样重要。一颗芯片要嵌入到大型数据中心需要考虑机架设计、网络拓扑、故障隔离等系统工程。这些都不是 9 个月能全部完成的所以保守判断是OpenAI 会先在内部场景使用 Jalapeño再逐步把能力投射到 API 服务中。8. 最佳实践与工程建议这一节写给想参与 AI 基础设施评估和建设的读者。无论是团队选型还是个人学习下面几条建议都能帮助你少踩坑。8.1 把每瓦吞吐量纳入核心指标如果你的业务是长时间跑推理服务那么只看 token/s 是不够的。功耗直接决定了电费和散热成本而电费又是推理服务最大的长期开销之一。建议在 Benchmark 报告里增加每瓦吞吐量这一列并在供应商对比中明确写出工作负载类型。具体做法准备一组标准 prompt固定输出长度在同一型号的服务器上跑多次记录平均功耗和平均吞吐量。这个指标没有行业统一标准但只要对比双方使用同样的条件和测量方式就有决策价值。8.2 使用标准化负载做评测DeepSeek R1、Llama 3.1 这类模型已经是开源社区的通用基准建议选用一到两个代表性模型测“长推理链”和“短对话”两种场景。不要只测单条 Easy Prompt因为在真实场景里长上下文和思维链解码往往是性能瓶颈。在测试里还要固定参数batch size、KV Cache 用量、量化等级、并发数。不同参数下芯片的能效结论很可能完全相反。把这些参数写进测试报告后续回顾和对比才有意义。8.3 谨慎对待芯片新品先算 TCO所谓 TCO即总拥有成本包含采购成本、功耗成本、运维成本、优化软件的时间和人力成本。一颗芯片即使每瓦吞吐量很高如果生态不成熟需要花大量时间做算子适配和工具链改造总成本也未必更低。更稳妥的判断是在引入新硬件前先用你的核心业务模型跑一个 Benchmark把性能、功耗、可用性和工具链成熟度都列出来再决定是否小规模试点。不要因为一个“1.7 倍”就冲进实验室。8.4 关注生态和开源工具链变化OpenAI 在自研芯片之外还在推进 Codex Harness 等开源工程化项目。当一家模型公司开始开放工具链时往往意味着它希望把开发者拉进自己的基础设施体系。对开发者来说这意味着未来可能可以用同一套 API 调用底层不同芯片而不必关心芯片具体型号。如果你在做 Agent 或 AI 应用开发现阶段不需要去学芯片设计但需要学习如何观察 API 的返回速度、延迟和成本。这些指标会直接反映底层基础设施的优化程度。一个更关注能效的平台长期来看会把红利让给应用开发者。9. 长远判断与开发者下一步回到开头的问题Jalapeño 的首秀是改变游戏规则吗我的判断是它没有立刻改变游戏规则但给整个行业安装了一个“能效优先”的思维锚点。以后任何 AI 芯片发布如果只谈峰值算力、不谈每瓦对应模型吞吐量都会被市场追问一句那单位功耗下的真实吞吐是多少对开发者来说接下来可以做的事情很具体用本文第 5 节的评测思路在你自己现有服务器或开发机上跑一个模型算出每瓦吞吐量。这份数据会成为你未来比较新硬件的参照物。追踪 DeepSeek R1 蒸馏模型的迭代特别是 GGUF 量化版本这能帮你快速做本地实验。持续关注 OpenAI 的 API 定价和上下文窗口变化。如果自研芯片的能效红利开始外溢你会最先在价格和响应速度上感知到。学习英伟达 GB300 和 OpenAI 自研芯片的架构差异时不要只看晶体管数量重点关注它们在 Transformer 解码链路里的具体优化比如 KV Cache 容量、显存带宽和互联方式。AI 基础设施的竞争已经不再只是“谁的模型更聪明”还包括“谁的电费更低、谁的吞吐更稳”。OpenAI 用 Jalapeño 这枚辣椒给整个行业提了一个醒真正的算力霸权不只是性能霸权更是能源效率霸权。至于这枚辣椒最终能改变多少市场格局要看它能不能从实验室走进真实机房变成开发者每一个 API 调用里更低的延迟和更稳的响应。