如果一家 AI 公司突然宣布自研芯片你的第一反应是什么很多人会本能地想到“挑战英伟达”。但这次 OpenAI 的 Jalapeño 首秀真正值得关注的不是又一款 AI 芯片而是它放到台面上的考核指标——每瓦 AI 吞吐量。根据公开信息Jalapeño 基于 3nm 工艺研发周期大约 9 个月在 DeepSeek R1 推理任务上每瓦吞吐量达到了 GB300 方案的 1.7 倍。这个数字的冲击力不在晶体管数量也不在峰值算力而在于它直接回答了 AI 推理经济性最核心的问题一度电能换回多少 token。对普通开发者来说这听起来像数据中心层面的军备竞赛和日常工作关系不大。但实际上它会连锁影响你调用 API 时的单价、可用的上下文长度以及你在自有服务器上做模型服务时的硬件选型。当算力供应商开始按每瓦效率竞争AI 应用的边际成本会被重新定义。这篇文章会从三个角度展开先拆解“每瓦 AI 吞吐量”这个指标的真实含义再分析 1.7 倍性能差异对成本和架构的影响最后用一套可以本地跑通的示例教你在自己的服务器上测量推理吞吐量。这样再看到厂商发布会上的性能曲线你就能把宣传语言变成自己能够验证的数据。1. 这篇文章真正要解决的问题跑大模型推理的人最近普遍有一个体感算力好像更便宜了但账单没有降下来。无论是直接调用商用 API还是租 GPU 自建推理服务token 生成成本始终是项目从 Demo 走向生产时绕不过的坎。每生成几千个 token背后都是显卡功耗、显存占用和数据中心散热成本。很多技术团队在模型选型时只看参数量和精度很少意识到真正决定长期成本的是“每瓦吞吐量”。自研推理芯片并不是一个新概念Google 的 TPU、AWS 的 Trainium 都已经走了好几年。但 OpenAI 的 Jalapeño 之所以值得专门拿出来分析是因为它补齐了一个关键拼图最强的模型厂商开始自己定义推理芯片。这意味着以后你在 API 上看到的模型价格很可能由这类定制芯片决定而不再是通用 GPU 一家独大。推理效率的竞争正在从模型层向上蔓延到硅片层。所以这篇文章的核心目标是解决三个问题第一如何用一个技术指标看懂 AI 芯片发布会上的“性能首秀”而不是被峰值算力带偏第二DeepSeek R1 每瓦吞吐量是 GB300 的 1.7 倍这个数据对开发者意味着什么第三在没有 Jalapeño 真机的情况下如何用开源工具在自己的服务器上复现一套吞吐量测试方法积累判断芯片能力的第一手经验。这三点才是普通技术团队能从这轮芯片竞赛中真正拿走的东西。2. 核心背景OpenAI 为什么需要自研推理芯片先理清一个容易误解的地方OpenAI 做芯片的主要动力不是“看不起英伟达”而是模型推理成本太贵。训练模型可以一次性投入但推理是持续发生的成本。GPT 级别产品的每一次对话、每一轮 Agent 调用都要花钱买算力。当用户规模上来之后推理成本会成为利润表的头号压力源。自研芯片即使不能全面超越通用 GPU只要在自家模型工作负载上做得足够好就能改善商业模式甚至反向压低 API 价格。从公开信息看Jalapeño 是一款面向推理场景的 3nm 芯片研发周期约 9 个月。这里需要特别说明9 个月这个周期并不是传统大芯片项目的常规节奏。如果信息属实说明它更可能采用了“专用化”设计思路牺牲通用能力换取自家负载上的高能效。它不是一个试图替代训练卡的宏大平台而是服务于高频、低延迟、长输出的推理任务。换句话说Jalapeño 的目标不是全面胜利而是在 OpenAI 最疼的环节上做到极致。另一个关键点是 OpenAI 选择将性能首秀放在 DeepSeek R1 上。DeepSeek R1 是目前开源社区讨论度很高的推理模型特点是思维链长、输出 token 多。长上下文和长输出会让 GPU 的内存墙问题更突出功耗也会快速上升。用 R1 作为测试负载一是测试结果对开发者有实际参考价值二是能放大芯片在“长生成场景”下的能效优势。如果换成一个短输出任务1.7 倍的优势很可能不会这么明显。所以Jalapeño 的出现不是孤立的硬件事件而是模型厂商试图从芯片层面掌握“每 token 成本”控制权的信号。它不是一次简单的硬件发布会更像是在宣告未来的模型能力竞争一部分会发生在晶圆上。理解了这个背景再去看每瓦吞吐量就不会被一个孤立的数字迷惑。3. 核心指标拆解每瓦 AI 吞吐量到底是什么先建立几个容易混淆的概念。第一个是吞吐量Throughput。在推理场景中常用 tokens/s 表示模型每秒生成多少个 token。吞吐量越高同等时间内能完成的请求越多推理服务的并发能力越强。但它没有考虑功耗一台 1000W 的机器跑出 100 tokens/s和一台 300W 的机器跑出 50 tokens/s指标完全不同。第二个是延迟Latency。延迟指的是从请求发出到响应返回的时长。对于聊天应用延迟决定用户等待时间对于 Agent 应用延迟还会影响工具调用链条的节奏。吞吐量和延迟经常相互制约高吞吐不一定意味着低延迟。第三个是本文的主角每瓦 AI 吞吐量。它把吞吐量除以功耗得到每瓦特每秒能生成的 token 数通常写作 tokens/s/W。这个指标把性能和经济性绑定在一起比单纯的 TFLOPS 或 GPU 型号更能反映数据中心的真实成本。如果说算力规格是“发动机排量”那么每瓦吞吐量就是“百公里油耗”。在电力和散热成本占大头的推理机房油耗往往比排量更致命。上面提到的 GB300在本文语境中代表英伟达面向下一代 AI 服务器市场的加速方案。它延续了高性能通用 GPU 的路线在模型训练和通用推理上覆盖很广。Jalapeño 与它对比不是要证明自己绝对性能更强而是在特定模型推理负载下用更低的功耗实现了可比的吞吐量。这两类芯片的设计哲学本来就不同一个是普适计算平台一个是专用加速器。对比每瓦效率是为了理解“专用化到底能换回多少经济性”。“DeepSeek R1 每瓦 AI 吞吐量是 GB300 的 1.7 倍”这句话正确理解方式是运行 DeepSeek R1 这个模型时Jalapeño 每一个单位功耗能产出的 token 数是 GB300 方案的 1.7 倍。它不是说生成速度快了 1.7 倍更不是说所有模型都有相同增幅。如果换成了实时语音识别或文生图模型这个排名很可能完全不同。所以任何拿单一模型评测结果代表整个芯片能力的说法都需要谨慎看待。4. 1.7 倍每瓦性能意味着什么成本与体验的双重变化单独看 1.7 倍可能不够震撼把它换算成功耗和成本差距就会被放大。假设某推理集群需要稳定输出 1000 tokens/s。如果 A 方案的每瓦吞吐量是 x tokens/s/W需要对应功耗为 1000/x W。B 方案达到 1.7 倍也就是 1.7x tokens/s/W那么相同输出速率下功耗只需要 1000/1.7x ≈ 588/x W。也就是说功耗大约下降了 41%。放在电力成本占大头的推理机房这个数字足以改变毛利率也会直接影响服务商对流量高峰的应对策略。而对开发者来说更直接的影响可能出现在 API 定价上。推理芯片的每瓦效率越高模型服务商在单位请求上的电力成本越低就有空间把价格压得更低或者在同样的价格下开放更长的上下文窗口。尤其是 R1 这种长思维链模型输出 token 数量大用户每轮请求的耗电成本本身就高芯片效率提升带来的降价空间会更明显。过去我们常说“模型决定智能上限”现在芯片效率开始悄悄决定“模型能否以合理价格被使用”。但也要注意1.7 倍是在特定负载下的数字不是万能结论。实际部署还会受内存带宽、显存容量、并发调度、模型量化方式等因素影响。比如同样运行 DeepSeek R1如果选择不同的量化精度芯片能否发挥优势可能完全不同。因此面对这类数据正确反应不是“无脑买”而是把它当作一个基准参考再结合自己的任务负载做验证。这也是第六节要讲实践的原因每个团队都应该具备自测吞吐量的能力不能只依赖厂商发布会。5. 环境准备如何搭建一个可复现的吞吐量测试环境在没有 Jalapeño 真机的情况下我们仍然可以搭一套吞吐量测试环境验证 DeepSeek R1 量化模型在本地硬件上的实际表现。这套环境不追求复现 1.7 倍而是让你掌握评估方法。未来无论面对哪款新芯片都能够用自己的数据说话而不是停留在对方给的宣传图里。首先准备硬件。推荐使用支持 CUDA 的 NVIDIA GPU显存至少 4GB 以上以便运行 1.5B 参数的量化模型。如果没有 GPU也可以用 CPU 跑但速度会慢很多结果只能作为功能连通性验证。要注意功耗和散热长时间跑推理前先确认硬件的供电和散热条件避免设备降频影响测量数据。如果是在服务器上测试还要确认功率上限和机柜散热不然跑出来的数字可能被温度折损得很厉害。软件方面推荐使用 llama.cpp。它是目前社区生态很成熟的 C/C 推理框架支持 GGUF 格式的量化模型对显存和内存占用控制得比较好。还需要一个 Python 3.10 环境用来写测量脚本。如果在服务器上执行建议先确认网络、权限和依赖管理方式不要在未授权的生产环境随意编译运行代码。很多团队成员直接拿生产节点跑压力测试结果导致在线服务抖动这是完全可以避免的。模型方面社区常见的 GGUF 量化文件例如 deepseek-r1-distill-qwen-1.5b-q4_k_m.gguf是很好的测试样本。1.5B 参数量在开发机上就能跑起来Q4_K_M 是质量和体积之间比较均衡的量化档位。下载时注意模型文件的来源要可靠最好从官方仓库或可信镜像获取。如果模型文件来自不明渠道至少先校验哈希值再放到服务器上加载避免代码执行链被污染。6. 完整示例用 llama.cpp DeepSeek R1 量化模型跑推理下面用三个示例演示从编译到测量的完整流程。所有命令都以当前主流 llama.cpp 仓库结构为例具体参数细节以官方 README 为准。这套流程的核心思路是先让模型跑通再记录关键指标最后把结果转成结构化数据。不要跳过编译这一步直接下载二进制否则遇到 GPU 后端版本不匹配时排错成本会更高。6.1 示例一编译 llama.cpp如果你的机器带有 NVIDIA GPU并且 CUDA 环境已经就绪可以用下面的命令开启 CUDA 加速。如果只有 CPU也可以去掉 CUDA 相关参数。编译参数在不同版本里可能叫LLAMA_CUBLAS也可能叫LLAMA_CUDA需要以你克隆下来的仓库 README 为准。git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp cmake -B build -DLLAMA_CUBLASON cmake --build build --config Release -j 4这里-DLLAMA_CUBLASON是让编译过程启用 GPU 后端。编译完成后build/bin/llama-cli就是命令行推理工具。如果编译过程中报错不要急着换参数先运行nvcc --version确认 CUDA 工具链可用。很多时候编译失败不是代码问题而是环境变量没有指向正确版本的 CUDA。6.2 示例二命令行测试单并发吞吐下载好 GGUF 模型后放入models/目录然后执行下面的命令。-n 128表示最多生成 128 个 token-t 4表示使用 4 个线程。如果你的 GPU 足够强-t可以适当调大但不要超过物理核心数。./build/bin/llama-cli -m models/deepseek-r1-distill-qwen-1.5b-q4_k_m.gguf \ -p 请用一句话解释什么是每瓦 AI 吞吐量。 \ -n 128 -t 4程序会先在终端打印 prompt 的评估阶段信息然后逐字输出生成内容最后打印eval time和tokens/s等统计数据。注意输出内容可能包含思考链标记这是 R1 系列模型的正常行为不代表生成出错。如果你想做更贴近业务的测试可以把-p后面的 prompt 换成真实业务问题但要注意 prompt 长度会影响prompt eval time和总耗时。6.3 示例三Python 脚本统计 token 生成速率为了让结果更可读可以用 Python 调用上面的命令并解析输出中的关键数据。新建文件bench_tokens.py内容如下import subprocess import re import time MODEL models/deepseek-r1-distill-qwen-1.5b-q4_k_m.gguf PROMPT 请用一句话解释什么是每瓦 AI 吞吐量。 def run_benchmark(): start time.time() result subprocess.run( [./build/bin/llama-cli, -m, MODEL, -p, PROMPT, -n, 128, -t, 4], capture_outputTrue, textTrue, encodingutf-8, errorsreplace, ) elapsed time.time() - start combined result.stdout result.stderr print(combined) match re.search(reval time\s*\s*[\d.]\s*m/s\s*\(\s*([\d.])\s*tokens/s\), combined) if match: tokens_per_second float(match.group(1)) print(f吞吐量: {tokens_per_second:.2f} tokens/s) print(f端到端耗时: {elapsed:.2f}s) else: print(未匹配到吞吐量字段请检查 llama.cpp 输出格式。) if __name__ __main__: run_benchmark()脚本先记录下来整个调用的耗时再把stdout和stderr合并从输出中提取tokens/s。不同版本的 llama.cpp 输出格式可能不同如果你的版本没有正则匹配到可以先把combined打印出来人工确认新的格式。这个脚本还有一个好处它把所有信息合并到了一个输出流里方便后续接入日志系统。如果你更习惯用 API 方式做压力测试也可以在合法授权的前提下用类似 OpenAI 兼容接口的方式测量端到端吞吐。下面是一个简化的示例import time from openai import OpenAI # 请替换为你在合法环境中申请的 key且不要把 key 写入公开仓库。 client OpenAI(base_urlhttps://api.openai.com/v1, api_keyYOUR_API_KEY) prompt 解释一下什么是每瓦 AI 吞吐量。 start time.time() response client.chat.completions.create( modelgpt-4o-mini, # 以实际可用模型为准 messages[{role: user, content: prompt}], max_tokens128, temperature0, ) latency time.time() - start completion_tokens response.usage.completion_tokens print(f端到端延迟: {latency:.2f}s) print(f输出 token 数: {completion_tokens}) print(f平均生成速率: {completion_tokens / latency:.2f} token/s)这个示例的重点不是让你拿本地小模型和云端大模型对比而是展示“端到端吞吐”和“芯片本身吞吐”的差异。网络传输、排队等待都会增加延迟跑线上压力测试时必须区分清楚。否则你测量出来的数字包含了太多网络噪声无法真正反映芯片或者模型服务本身的效率。7. 运行结果与效果验证运行上面的命令后llama-cli会在最后打印类似下面的统计信息。不同版本、不同硬件上的数字会不同但字段结构大致类似。llama_print_timings: load time 123.45 ms llama_print_timings: sample time 8.90 ms / 128 runs ( 0.07 ms per token) llama_print_timings: prompt eval time 456.78 ms / 32 tokens ( 14.27 ms per token) llama_print_timings: eval time 5678.90 ms / 128 tokens ( 44.36 ms per token) llama_print_timings: total time 6123.45 ms重点看两个指标prompt eval time代表输入 token 的处理速度eval time代表生成阶段的平均耗时。后者越低说明模型生成越流畅。tokens/s字段就是生成阶段吞吐量。如果使用 Python 脚本会直接解析出这个字段并打印。要判断测试是否成功先看两件事模型是否正常加载以及是否完成 128 个 token 的生成。逻辑上只要程序没有报错退出统计结果就有参考价值。如果eval time显示为 0 或者低得离谱优先怀疑模型没有加载成功或者编译时没有启用 GPU 后端。如果 CPU 跑 1.5B 模型速度可能只有几 tokens/s这并不意味着代码有问题而是硬件差异导致。如果在服务器上测试还可以使用nvidia-smi确认 GPU 利用率和功耗再结合时间统计得到更完整的每瓦数据。值得注意的是nvidia-smi给出的功耗是瞬时值最好用监控工具记录一段时间内的平均功耗。这样才能在对比不同硬件或不同框架时获得比较稳健的每瓦吞吐量而不是一次偶发快照。8. 常见问题与排查思路问题现象可能原因排查方式解决方案编译报错找不到 CUDACUDA 工具链缺失或路径不正确执行nvcc --version确认 CUDA 是否安装安装对应 CUDA 版本重新执行 cmake模型加载失败GGUF 文件损坏或下载不完整对比模型文件哈希检查下载大小重新下载使用官方源生成速度非常低编译时未开启 GPU 后端检查 cmake 参数和启动日志中的 backend 信息重新编译并启用 GPU 后端启动后显存不足模型量化档位与显存不匹配查看nvidia-smi显存占用换更小的量化格式或更小参数量模型输出中大量思考标签R1 模型本身会生成思考链检查 prompt 和采样参数保留或按应用需求过滤不影响吞吐测量Python 脚本匹配不到 tokens/sllama.cpp 输出格式有变化先打印 combined 输出更新正则表达式匹配实际格式表格里的问题都是实际使用量测试时容易遇到的。如果你在编译步骤卡住建议先把 cmake 错误日志完整看一遍不要只看最后几行。多数时候错误信息已经告诉了你缺什么依赖。如果是模型文件的问题优先重新下载而不是手动修改二进制文件损坏后的行为往往不可预期排查起来反而更浪费时间。9. 最佳实践与工程建议跑通一套吞吐量测量流程只是第一步。在实际项目中真正能优化成本的地方往往在模型之外。首先重视模型量化。Q4_K_M 这类 4-bit 量化在多数任务上能保持不错效果同时显著降低显存占用和内存带宽压力。量化档位选择要结合业务效果评测不能只凭速度挑最低精度否则模型输出质量下降带来的返工成本会超过算力节省。建议每个团队建立一套小型评测集专门用来评估不同量化档位下的效果变化。其次使用批处理和 KV Cache。LLM 推理服务通常不会只跑单请求。连续批处理continuous batching可以让多个请求共享 GPU 资源明显提高整体吞吐。KV Cache 的大小和淘汰策略也会直接影响长对话场景的显存占用建议在服务框架中配置可观测的缓存命中率。很多人在本地测试时只跑单并发上线后却发现吞吐远低于预期原因就是没有把批处理纳入设计。第三监控要落到功耗层面。仅仅看 tokens/s 是不够的因为不同配置下的功耗差异很大。如果硬件支持可以记录 GPU 功耗、温度和利用率计算“每瓦吞吐量”。这样当你收到某个新芯片的“1.7 倍”数据时才能明白对方是在什么功耗曲线上得到的结果。如果你记录的是整机功耗还需要把 CPU、内存、风扇等额外功耗考虑进去否则会高估芯片本身的效率。第四注意环境和数据安全。在服务器上编译代码、下载模型、调用 API 之前先确认网络权限和资源配额。不要把 API key 写进代码仓库更不要运行未经审查的脚本。涉及生产环境时遵循最小权限原则先在测试环境验证完整流程。安全边界的意义不只是防止外部攻击还在于避免内部误操作导致线上服务不可用。最后不要迷信单一指标。每瓦 AI 吞吐量是重要参考但它无法覆盖所有场景。如果你主要做低延迟实时交互延迟可能比功耗更重要如果你做离线批量生成吞吐量可能是唯一指标。明确自己的业务约束再选择评估标准才能让“性能首秀”真正服务于你的技术决策。10. 下一步关注什么Jalapeño 的首次公开性能展示让“每瓦 AI 吞吐量”这个词从芯片厂商的销售手册走进普通技术讨论。它提醒所有做大模型应用的人推理效率不只是模型结构问题也不只是软件优化问题而是从硅片到服务的整条链路问题。接下来值得继续关注的方向有三个Jalapeño 是否会在 OpenAI API 中逐步落地API 价格和上下文长度会不会因此变化DeepSeek R1 这类长输出模型在专用芯片上的优化思路会如何反向影响开源推理框架的设计英伟达下一代平台面对每瓦效率竞争会不会调整产品路线。对普通开发者来说不必追着芯片新闻跑。更实际的做法是回到自己的服务器上用文中这套方法跑一遍吞吐量测试记录下模型版本、量化档位、硬件功耗和生成速度。当你在不同硬件或不同框架之间迁移服务时这份基准数据会成为最有说服力的决策依据。它能帮你回答“换硬件真的划算吗”“换框架会不会提高吞吐”这类具体问题。下次再看到某款芯片宣称“性能首秀”时先不要急着看峰值算力。问一句它在 DeepSeek R1 这类主流模型上的每瓦吞吐量是多少答案会告诉你它到底是为讲故事设计的还是为降本设计的。这才是芯片竞争里最值得盯着的那条线。