AI加速器性能评测指南：从芯片指标到可复现压测实践

最近关于 OpenAI 自研芯片的讨论热度上升得很快。热搜词里既有“OpenAI 用 9 个月造出 3nm 自研芯片”这种听起来很夸张的说法也有“OpenAI 自研加速器 Jalapeño 性能超越英伟达 Blackwell”这种直接下结论的标题。如果只看表面很多人会觉得格局已定但真正在做推理服务、选型 GPU、核算成本的开发者更关心的是另一个问题这种“超越”到底是怎么算出来的对我们的项目有没有实际意义先说结论再展开任何跨芯片、跨架构、跨软件栈的“性能超越”都必须在特定条件里讨论。“Jalapeño 超越 Blackwell”可能只在某个推理场景、某个量化位宽、某组模型输入输出长度下成立甚至只是某家厂商内部测试结果被传播放大后的版本。真正可靠的做法是先把性能拆成可测量的单元首 Token 延迟、生成吞吐量、显存占用、功耗、单位成本然后在自己能复现的环境里跑一遍。这篇文章不负责替谁站台而是把“如何看懂加速器性能”与“如何用开源工具做一次可复现压测”讲清楚。这里先说明一个前提本文说“加速器”指的是 AI 训练与推理的硬件加速单元包括 GPU、AI 加速卡、ASIC 等与任何网络连接工具无关。下面进入正题。1. 为什么“超越 Blackwell”这种结论需要打问号“超越”这个词看着简单但在硬件领域特别容易被误读。英伟达 Blackwell 是一整套平台而不仅仅是一颗芯片。它包含 GPU 核心架构、显存子系统、NVLink 互联、CUDA 软件栈、TensorRT 推理引擎以及围绕 PyTorch、vLLM、DeepSpeed 等框架做的大量适配。当你听说某个新加速器“超越 Blackwell”时首先要问它超越的是 Blackwell 平台的哪个部分是在 FP16 矩阵乘法上超越还是在 INT8 推理上超越是在单卡生成吞吐量上超越还是在千卡集群训练效率上超越两者技术难度和实现路径完全不一样。从公共信息看OpenAI 确实有推动自研芯片的迹象行业里也流传“Jalapeño”这个代号。但截至我写这篇文章时还没有看到一份经过广泛技术社区验证的官方规格表和第三方可复现基准。很多讨论更像是基于传闻的反推既然 OpenAI 是当前大模型生态的核心玩家那么它造出的芯片一定“性能炸裂”再叠加“9 个月造出 3nm 自研芯片”的说法“超越 Blackwell”就成为顺理成章的标题。这里真正容易踩坑的地方在于自研 ASIC 与通用 GPU 的取舍完全不同。ASIC 通常是对某类固定运算做极致优化比如固定的矩阵乘法形状、固定的注意力计算模式、固定的量化位宽。它在特定场景下确实可能比通用 GPU 更快但这种快往往以牺牲灵活性为代价。如果未来模型结构变化比如注意力机制被新机制替代或者训练与推理的比例大幅调整ASIC 的优化空间就会受到限制。更稳妥的判断是除非你亲眼看到同一份数据集、同一套模型、同一个评估脚本下的对比结果否则“性能超越 Blackw ell”这类声明一律先当作营销语言处理。这是做技术选型的基本素养。2. AI 加速器真实性能的三个层次芯片、软件栈与生态要判断一个加速器是否值得关注不能只看“芯片”这层。真正的性能来自三层叠加。第一层是芯片本身的算力与存储带宽。芯片的浮点运算峰值、低精度算力、显存容量、显存带宽、片间互联带宽决定了它的理论上限。训练和推理对这几项的侧重不同训练对算力与互联更敏感推理对显存带宽和延迟更敏感。一个典型现象是某些加速卡算力标称很高但一旦跑真实模型会发现瓶颈在显存带宽导致实际吞吐远低于理论值。第二层是软件栈。这是英伟达最坚固的护城河之一。CUDA、cuBLAS、cuDNN、TensorRT、Triton 等工具链经过十多年累积对模型算子做了深度优化。反过来一个新加速器即使算力很强如果编译器工具链不成熟PyTorch 算子适配不全推理引擎无法直接调用那么真实性能会大打折扣。行业里反复出现“纸面算力高实际跑模型打六折甚至更低”的情况根源就在软件栈。第三层是生态。开发者拿到一个新加速器第一件事是问PyTorch 能不能直接跑HuggingFace Transformers 认不认vLLM 支不支持Docker 镜像有没有现成的监控工具能不能监控它的利用率如果这些问题都答不上来性能数据再漂亮也落不了地。这也是为什么即使出现性能更强的 ASIC很多团队仍然会继续使用英伟达因为切换成本不只在硬件还在整个工程链路。知道这三层之后就能理解“Jalapeño 超越 Blackwell”这句话的分量了。即便 Jalapeño 在某个推理基准里超过了 Blackwell只要它的软件栈成熟度和生态覆盖度还差一截这个“超越”就很难转化为真实业务的收益。反过来如果 OpenAI 能把软件栈也补上那才是对现有格局的真正冲击。3. 评测性能先搞懂这些指标TTFT、TPOT、吞吐量与显存在做任何压测之前必须先把指标口径统一。否则同一个模型两个人测出来的数据能差出好几倍不是谁造假而是一个测的是端到端延迟另一个统计的是排除排队后的纯计算时间。下面这几个指标是做推理服务评估时必须搞懂的。首 Token 延迟也叫 TTFTTime To First Token。从客户端发起请求到模型返回第一个 Token 的耗时。它决定用户从“点击按钮”到“看到第一个字符”的等待时间。对对话类应用这个指标直接影响体感。TTFT 可能被多种因素放大包括请求排队、显存换入换出、小算子调度开销等。单 Token 生成间隔也叫 TPOTTime Per Output Token。生成每个 Token 的平均耗时。它决定模型输出的速度。TPOT 越低用户感觉“打字速度”越快。它主要受显存带宽和模型规模影响。吞吐量Throughput。单位时间能处理的 Token 数量常用 tokens/s 表示。压测时通常会指定并发请求数。吞吐量高不代表体验好因为高吞吐可能建立在高并发排队基础上单请求延迟会变长。显存占用与并发数。一条请求会占据一定显存包括 KV Cache 和模型权重。显存越大能承载的并发请求越多单位成本越低。这也是为什么大显存卡在推理场景特别受欢迎。单位成本。把硬件成本、电费、运维成本除以总 Token 数得到每百万 Token 的成本。对做业务的人来说这个指标比峰值算力更现实。功耗。功耗既影响电费也影响机房散热规划。数据中心对单机功耗有严格上限功耗过高会导致无法按设计密度部署。评测时建议至少记录以上六个指标而不是只看一个峰值数字。缺少上下文的速度值没有太大意义。4. 自己的压测自己跑用 Python 和 API 测量推理速度既然不能轻易相信传闻最靠谱的方式是自己动手测。这一节先从最轻量的方式开始我们使用 Python 脚本通过 OpenAI 兼容接口测量一个模型接口的 TTFT 和生成吞吐量。这种方式不需要自己准备 GPU只需要一个可访问的模型 API 地址和 API Key。它适合用来验证“某个模型在当前网络和负载下到底快不快”。4.1 环境准备建议使用 Python 3.10 及以上版本并安装 openai 库。可以用 pip 安装pip install openai如果你本地已经装有虚拟环境管理工具建议先创建并激活虚拟环境避免依赖冲突。4.2 写一个最小压力测试脚本下面这个脚本会向兼容 OpenAI 协议的接口发送一个聊天补全请求使用流式输出并记录两个关键时间点首 Token 到达时间与完整响应结束时间。代码里的 API Key 和 base_url 需要换成实际可用的值。# openai_api_benchmark.py import asyncio import time from openai import AsyncOpenAI client AsyncOpenAI( api_keysk-xxxxxxxxxxxxxxxxxxxx, base_urlhttps://api.openai.com/v1, ) async def run_once(prompt: str, max_tokens: int 512): start time.perf_counter() first_token_time None stream await client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], max_tokensmax_tokens, streamTrue, ) collected async for chunk in stream: if chunk.choices[0].delta.content: if first_token_time is None: first_token_time time.perf_counter() collected chunk.choices[0].delta.content end time.perf_counter() total end - start ttft (first_token_time - start) if first_token_time else 0 generate_time total - ttft tokens len(collected) tps tokens / generate_time if generate_time 0 else 0 return { total_seconds: round(total, 3), ttft_seconds: round(ttft, 3), generate_seconds: round(generate_time, 3), output_tokens: tokens, tokens_per_second: round(tps, 2), } if __name__ __main__: prompt 写一段200字左右的文章介绍AI推理性能测试的基本指标。 result asyncio.run(run_once(prompt)) print(result)关键逻辑说明first_token_time在流式响应的第一个非空内容块出现时记录它就是 TTFT。generate_seconds表示第一个 Token 之后到响应结束的耗时。tokens_per_second是生成阶段的实际速度不包含首 Token 等待。这样能避免“网络慢导致整体指标被拉低”的干扰。运行脚本后会输出一个包含六个字段的字典。如果输出的ttft_seconds很低但tokens_per_second也很低说明瓶颈可能在生成阶段比如模型本身较大或服务端负载较高。4.3 用 nvidia-smi 观察 GPU 状态如果你自己有一台带英伟达 GPU 的服务器可以在压测的同时用 nvidia-smi 观察 GPU 的实时状态。下面命令会每秒刷新一次关键信息nvidia-smi \ --query-gpuname,utilization.gpu,memory.used,power.draw,temperature.gpu \ --formatcsv,noheader,nounits \ --loop1输出类似以下内容NVIDIA H800 PCIe, 100, 78019, 254, 64 NVIDIA H800 PCIe, 100, 78080, 253, 63每一行依次表示GPU 型号、显存占用百分比、显存已用大小MiB、当前功耗、温度。利用这些数据能判断压测过程中 GPU 是否被真正跑满。如果 GPU 利用率只有 30%而 API 响应已经很慢说明瓶颈更可能在模型输入输出长度、CPU 数据处理或网络层而不是 GPU 算力本身。5. 本地部署 vLLM用 OpenAI 兼容接口做一次完整压测API 测试的优点是简单缺点是没法控制模型版本和推理引擎而且受网络影响较大。想要更可信的数据最好是本地部署开源推理服务压测自己控制的模型。这里以 vLLM 为例因为它是目前社区使用最广泛的推理引擎之一并且自带 OpenAI 兼容接口。5.1 部署开源推理服务假设你有一张显存足够的英伟达 GPU先安装 vLLMpip install vllm然后启动一个 Qwen2.5-7B-Instruct 模型的推理服务。如果网络能正常拉取模型权重命令如下python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --dtype bfloat16参数说明--model指定 HuggingFace 模型 ID。--gpu-memory-utilization控制最多使用多少比例的显存用于 KV Cache 分配。设为 0.9 可以降低显存不足风险。--max-model-len控制模型上下文长度直接影响 KV Cache 占用。--dtype指定模型精度格式常见选项是 bfloat16 或 float16。服务启动后默认监听http://localhost:8000并提供一个 OpenAI 兼容的/v1/chat/completions接口。5.2 替换 API 地址进行测量复用第 4 节的 Python 脚本只需要把base_url改成 vLLM 的地址client AsyncOpenAI( api_keysk-no-key-needed, base_urlhttp://localhost:8000/v1, )再把模型名称改成Qwen/Qwen2.5-7B-Instruct或你实际部署的模型 ID。然后运行同样的压测脚本就能得到本地真实推理数据。这种方式能排除网络波动测出“同一张卡、同一个模型、同一个推断引擎”下的真实性能。建议至少测几次取平均值不要用单次结果下结论。5.3 结果解读如果本地测出的tokens_per_second明显低于模型参考值优先检查以下几点并发请求数单请求无法打满 GPU提高并发才能真正压出吞吐量。输入输出长度超过一定长度后显存带宽会成为瓶颈。GPU 利用率如果nvidia-smi显示利用率长期低于 80%说明没有加载足够请求。模型量化位宽bfloat16、INT8、INT4 的吞吐量差异很大。要注意vLLM 的具体启动参数在不同版本之间存在差异。如果你的 vLLM 版本较新部分参数可能改名或废弃。本文重点演示通用思路实际操作时以对应版本文档为准。6. 性能之外成本、功耗与切换成本是更大的变量假设“Jalapeño 超越 Blackwell”不是传闻而是事实接下来真正的博弈会发生在性能之外。大模型落地选择硬件时很少只看单卡快不快。线上推理服务通常要考虑三件事第一单位 Token 成本。一个加速器如果速度很快但价格昂贵折算到每百万 Token 的成本反而不一定划算。当前大模型 API 定价竞争激烈OpenAI 如果推出自研芯片最有价值的突破大概率在成本端而不是单纯的速度数字。第二功耗和散热。数据中心不是有电就能无限扩容。功率上限决定了机柜能塞进多少卡。如果新加速器性能提升 30% 但功耗提升 80%那它反而可能拖累集群密度。第三切换成本。推理服务从英伟达 GPU 迁移到新加速器不只是把代码换新还要更换推理引擎适配、算子编译、监控告警、镜像构建、训练后验证等一整套流程。这个成本对很多团队来说远比几倍的性能提升要高。这也是为什么很多公司即使看到“更快的卡”也不会马上切换而是先在一个非核心场景做小规模试点。从业务角度一个更理性的观察方式是如果 OpenAI 自研芯片真能让 API 价格降低一个数量级同时保持兼容性和稳定性那它对开发者生态的影响会远超“某张卡在某项测试里更快”这件事。7. 常见问题与排查指南问题现象可能原因排查方式解决方案压测时 GPU 利用率低性能上不去请求并发数不足模型没有打满批处理查看服务端日志观察单请求延迟分布提高并发请求数开启动态批处理TTFT 突然变大请求排队或者显存剩余空间不足导致 KV Cache 频繁换入换出检查服务端日志中的排队时间查看显存占用曲线限制最大并发数或增加显存预留比例吞吐量高但用户主观感觉慢平均吞吐量被长文本请求拉高短请求实际延迟高分输入长度统计 TTFT 和 TPOT按内容长度做动态路由长文本走独立通道换新加速卡后速度反而下降软件栈未适配算子未完成编译优化检查推理引擎是否支持新芯片查看算子编译日志优先等待推理引擎适配或回滚到已支持版本显存不足导致进程 OOM并发请求过多KV Cache 占用超过显存查看 vLLM 日志中的 OOM 记录观察显存峰值降低--max-model-len或降低并发上限nvidia-smi 显示功耗低但响应慢瓶颈不在 GPU 算力而在显存带宽或 CPU 数据处理对比不同模型长度下的耗时变化优化模型输入输出长度或使用更高带宽显存的硬件如果压测失败第一步永远是看日志和监控数据不要直接换卡。日志能告诉你请求是否进入推理阶段监控数据能告诉你瓶颈在 GPU、显存、网络还是 CPU。8. 团队与个人开发者应该怎么应对这轮芯片竞赛面对“某公司自研芯片性能超越某巨头”的新闻最容易被带偏的动作是立刻评估迁移。实际上这个阶段更需要的是理性隔离信息噪音。对于中小团队在英伟达生态上继续投入仍然是更稳妥的选择。CUDA 生态、PyTorch 适配、vLLM 支持、云厂商镜像模板这些都不是新硬件一天两天能替代的。优先把自己业务的性能基线与成本基线建立起来远比追逐新硬件更有价值。换句话说你至少要知道当前方案每百万 Token 的真实成本是多少才有资格讨论“新方案是否更划算”。对于有自建 Infra 能力的团队可以采用双轨验证策略。先圈定 2 到 3 个不敏感场景用兼容 OpenAI 接口的推理引擎跑通负载测试记录 TTFT、TPOT、吞吐量和功耗。如果新硬件的软件栈已经支持主流推理引擎并且这些指标在成本和稳定性上确实有明显优势再考虑扩大试点。这个流程并不复杂但它能把“感觉上更快”变成“可量化的收益”。对于个人开发者不必急着追随最新硬件。你首先需要的是一套属于自己的测量脚本这比任何硬件更值钱。无论以后用哪家 API 或哪块卡你都能用它快速回答一个问题当前方案是不是最优如果你想保持竞争力建议优先掌握 vLLM、LangChain 和 OpenAI 兼容 API 接口这些开发生态里的通用工具它们不绑定单一硬件品牌。9. 结语回到业务需求回归可验证的基准“OpenAI Jalapeño 加速器性能超越英伟达 Blackwell”这个标题真正值得思考的不是谁快谁慢而是我们如何判断“快”。只要没有经过独立可复现的基准测试任何“超越”都只能算作一个待验证的假设。对工程师来说与其追逐热点不如把第 4、5 节里的脚本跑一遍让数据替你说话。这篇文章最想传达的一点是在 AI 加速器竞争越来越激烈的今天真正可靠的判断工具不是新闻标题而是一套属于自己的、能随时复现的性能评估流程。哪一天真的出现了性能、成本和生态同时占优的加速器你能比其他人更快地识别出它而不是被一时的信息噪音带着走。