在 AI 基础设施的讨论里OpenAI Jalapeño 与英伟达 Blackwell 的对比近来频繁出现。看到“优于”这类结论第一反应通常是选型要变天但工程上真正要回答的是另一组问题这颗芯片准备跑哪些模型承担训练还是推理软件栈能不能接住运维团队有没有能力排障。由于围绕 Jalapeño 的官方完整参数尚未公布这篇内容不会试图复述一个未经证实的性能数字而是把“Jalapeño 是否优于 Blackwell”这个口号式命题拆成一套可执行的芯片评估、基准测试和落地决策框架。读者可以把它当作一份 AI 算力选型的方法论文档。真正值得关注的是当一款新芯片只有名字、传闻和对比结论时如何通过工程手段判断它到底适不适合自己的业务。1. 先拆解“优于 Blackwell”这句话搞清楚在比什么1.1 这轮讨论的背景定制芯片进入 AI 算力版图OpenAI 是目前对大模型算力需求最旺盛的公司之一。要训练 GPT 级别的大模型训练集群需要上万张加速卡推理侧还需要支撑越来越长的上下文和高并发访问。这种需求规模下只依赖单一 GPU 供应商的风险很明显供应周期、议价能力、架构迭代节奏都不在自己手里。因此自研芯片或定制芯片成为大型 AI 公司都在考虑的方向。Google 的 TPU、Amazon 的 Trainium/Inferentia、Microsoft 的 Maia 都是同类思路的代表。OpenAI 若推出 Jalapeño也属于这条技术路线根据自家模型负载设计专用加速器而不是购买通用 GPU。英伟达 Blackwell 则是通用数据中心的旗舰 GPU 架构。两者的设计出发点不同优势领域自然也不同。看到“优于”这个结论不能直接理解为“新一代技术碾压旧一代技术”。在芯片领域只有把应用场景、模型结构、部署规模和软件栈都限定清楚性能对比才有意义。同一个芯片在训练 1750 亿参数模型、在服务 80 亿参数模型的高并发推理、在端侧场景运行成绩可能完全不同。1.2 “优于”至少要拆成四个子问题把“OpenAI Jalapeño 优于英伟达 Blackwell”翻译成工程语言至少包含四个可验证的子问题。第一峰值算力是否更高。这里要区分 FP16、BF16、FP8、INT8 等不同精度。专业 GPU 在不同精度下的算力差距很大只看某一项会失真。第二有效性能是否更优。峰值算力只决定理论天花板实际模型能利用多少取决于显存带宽、缓存、算子调度和编译器的配合。一个峰值很高但实际利用率只有 10% 的芯片很难说“优于”另一个利用率 60% 的芯片。第三软件生态是否能承接工作负载。性能再高如果 PyTorch 算子缺得厉害Triton 内核不兼容vLLM 推理框架不原生支持开发团队就要花大量时间移植和适配。这不是性能指标但会直接影响上线时间。第四总拥有成本是否更低。功耗、散热、机架空间、运维复杂度、维护周期和故障率都会进入最终成本模型。有的芯片采购价格便宜但为了散热要改造机房结果整体成本更高。后续章节围绕这四个子问题展开。这里的核心判断是一款芯片的“优劣”不是固定的它必须绑定场景和软件栈。1.3 这篇内容能回答的问题和不能回答的问题围绕 OpenAI 自研芯片网络上存在不少关于制程、研发周期和量产进度的讨论这些信息目前缺少完整官方数据支撑不适合作为技术选型依据。这篇内容也不会给出“Jalapeño 跑某某模型每秒多少 token”的结论因为这类数字在没有公开基准和真实硬件前无法验证。能回答的是面对一款新 AI 加速芯片应该用什么指标评估训练和推理各要跑什么基准从单卡到集群要验证哪些点新芯片进入生产环境后典型故障如何排查以及最终如何做选型决策。这套方法既适用于 Jalapeño 和 Blackwell 的对比也适用于判断其他新出现的 AI 芯片是否适合当前业务。注意不要把市场传闻当成工程结论。判断一款芯片能不能用唯一可靠的方式是在自己的模型、自己的数据、自己的部署环境下跑一遍可复现的基准。2. 对比 AI 加速器之前先把硬件指标表对齐2.1 算力指标FLOPs 不是唯一答案算力通常用 FLOPS 表示即每秒浮点运算次数。但要先明确精度FP32、FP16、BF16、FP8 的峰值算力往往不同。现代 AI 加速器为了训练效率和显存带宽普遍会用混合精度因此 BF16/FP16 比 FP32 更能代表实际训练能力。只看峰值 FLOPs 的误区在于它忽略了一个问题模型真正利用了多少峰值算力。业界常用 MFUModel Flops Utilization模型浮点利用率来衡量。MFU 是模型在一次训练中实际产生的浮点运算量除以理论峰值算力与运行时间的乘积。MFU 高说明计算资源被利用得充分MFU 低说明瓶颈可能在显存带宽、数据加载或通信等待而不是算力本身。对比两款芯片时最合理的做法是在同一模型、同一 batch size、同一框架下记录真实的训练吞吐或推理吞吐再反推 MFU。不要直接拿官方标称的 TFLOPS 做加减法。2.2 内存和带宽模型跑不跑得动这里说了算大模型的权重、优化器状态、中间激活值、KV Cache 都需要放进显存。显存容量直接决定单卡能训练多大的模型、推理时能缓存多长的上下文。显存带宽同样关键尤其是自回归推理的 decode 阶段。LLM 推理每次只生成一个 token权重需要从显存反复读取此时计算量不大但带宽压力很大所以 decode 速度往往受限于显存带宽。这就是为什么新芯片如果显存足够但带宽不够跑 decode 时依然可能打不过已有方案。对比时不能只看容量。还要看总显存容量决定模型能否放进单卡或单机。显存带宽决定读取权重和 KV Cache 的速度。是否支持内存复用、缓存压缩、KV Cache 量化等技术。2.3 互连带宽单卡之外集群能不能扩展当模型大到单卡放不下就需要张量并行、流水线并行或数据并行。此时卡间通信会成为新的瓶颈。英伟达体系里有 NVLink 和 NVSwitch跨节点有 InfiniBand 或 RoCE 网络自研芯片则要看它自己的互联方案是否成熟。评估互连时建议关注卡间互连带宽和拓扑是否适合 AllReduce、AllGather 等集合通信模式。跨节点网络协议和驱动生态能否与现有集群调度系统集成。多租户并发时的拥塞控制表现是否在空闲时很快、满载时剧烈退化。训练任务对通信尤其敏感。许多新芯片单卡性能不错但多卡训练时集合通信库不完善扩展效率很差最终出现“加卡不提速”的现象。2.4 能效、散热和机架密度生产环境的隐形约束性能对比表里经常不写功耗但机房会认真算这笔账。两颗芯片如果单卡性能接近TDP热设计功耗更低的芯片可能在同等电力容量下塞进更多卡整体吞吐反而更高。数据中心场景还要考虑散热方案。Blackwell 这类高功耗 GPU 通常需要液冷或强力风冷如果自研芯片功耗更低可以省下机房改造费用。但功耗低的前提是没有牺牲性能和稳定性因此要结合真实负载下的功耗记录来评估。2.5 软件生态性能之外最大的变量就算硬件指标全部领先软件栈不成熟也上不了生产。AI 芯片落地离不开编译器、深度学习框架、推理引擎和分布式通信库的配合。CUDA 生态是英伟达最深的护城河PyTorch、Triton、vLLM、NCCL 等等都围绕它做了大量适配新芯片要“优于” Blackwell必须在算子覆盖率、编译稳定性、调试工具完善度上证明自己。这一部分的评估方法不是看宣传文档而是直接安装官方 SDK写几个常见算子矩阵乘法、LayerNorm、FlashAttention 等跑性能再跑一次 PyTorch 的常见回归用例。软件问题通常在第二周开始暴露所以要留足试用和压测时间。下面给出一个硬件指标速查表便于在拿到两款芯片的参数后逐项核对。指标衡量什么对大模型的影响命中瓶颈时的典型表现峰值算力FP16/BF16/FP8理论最高计算能力决定训练和 prefill 的天花板GPU 利用率很低但耗时还是高显存容量GB能放多少权重、激活和 KV Cache决定单卡规模上限频繁 OOM需要换更小 batch显存带宽GB/s从显存读取数据的速度决定 decode 和长序列性能token 生成慢MFU 却不高卡间互连GB/s多卡通信上限决定多卡扩展效率加卡后吞吐不线性提升TDP 与散热方案单位功耗和散热要求决定机架密度和 TCO高负载下降频、温度告警软件生态成熟度算子、框架、调试工具支持决定迁移和上线成本常见算子缺实现性能回退3. 训练和推理是两张卷子不能混着打分3.1 训练场景真正考验什么训练任务的目标是在合理时间内完成多轮迭代因此核心指标是单位时间的有效计算量通常表现为每次迭代的耗时或者每秒处理的样本数。训练是一个非常稳定的长时任务对显存容量、计算密度、通信带宽和集群稳定性要求极高。训练时显存要同时保存权重、梯度、优化器状态和中间激活。参数规模一上来单卡放不下就必须做并行切分。此时卡间通信频繁AllReduce 的优化程度直接决定扩展效率。此外几十天的训练任务要求硬件故障率低、恢复机制成熟否则一次故障就会造成大量算力浪费。如果新产品主打训练场景至少要验证混合精度训练的收敛速度和稳定性。多卡 AllReduce 通信耗时占 Step 时间的比例。长时间运行是否存在显存泄漏、驱动崩溃或热降频。3.2 推理场景真正考验什么推理与训练不同它关心的是响应时延和吞吐。在线业务中用户发出请求到首次返回第一个 token 的耗时叫 TTFTTime To First Token随后每个 token 的生成间隔叫 TPOTTime Per Output Token。这两个指标决定了产品体验。推理侧还有明显的负载特征多个请求共享模型权重各自维护一份 KV Cache。随着并发请求增加KV Cache 会吃掉大量显存因此 PagedAttention、连续批处理、投机解码这类推理优化技术非常依赖底层芯片在内存管理和 kernel 调度上的支持。如果新芯片没有适配这些优化库推理吞吐会明显吃亏。3.3 用有效吞吐替代峰值性能做决策无论训练还是推理最终决策都要落在有效吞吐上。训练有效吞吐 模型浮点运算量 / 训练总时间等价于每秒处理的样本数。 推理有效吞吐 成功返回的请求数 / 时间窗口同时要满足时延上限。建议两条曲线一起看在 batch size 增大的过程中记录时延和吞吐在并发数增大的过程中记录 TTFT、TPOT 和成功率。峰值算力高但有效吞吐低的芯片在生产环境并不“优”。3.4 假设 Jalapeño 定位不同场景时的验证重点目前没有官方完整参数只能按“如果是训练卡重点验证什么如果是推理卡重点验证什么”来讨论。如果 Jalapeño 被定位成训练加速器需要重点验证多卡通信库、混合精度收敛和长稳如果是推理加速器重点则是显存带宽、KV Cache 友好度和推理框架适配。不同的验证重点会直接改变基准测试的设计方式。维度训练场景推理场景核心目标高吞吐、低等待低时延、高并发主要指标Step 时间、样本吞吐、MFUTTFT、TPOT、并发吞吐内存压力权重梯度优化器激活权重KV Cache并发上下文通信压力AllReduce 等高强度集合通信张量并行下的 AllGather、点对点核心优化ZeRO、梯度检查点、混合精度连续批处理、PagedAttention、量化对比重点扩展效率、稳定性显存带宽、推理引擎适配度4. 用最小基准工程把对比跑成可复现数据4.1 准备一套干净且可复现的环境无论评估哪款芯片都要从干净环境开始。推荐使用容器镜像避免宿主机上的 CUDA 驱动、库文件互相污染。常见的配置是Ubuntu 22.04、Python 3.10、PyTorch 稳定版、官方 CUDA 镜像。先检查驱动和运行环境nvidia-smi python -c import torch; print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))如果测试的是自研芯片就使用芯片厂商提供的 SDK、驱动和容器镜像并记录版本号。这里容易犯的第一个坑是忽略驱动与 CUDA Runtime 的版本匹配。驱动版本过低运行时会出现CUDA driver version is insufficient。对于容器方式可以这样启动基础环境docker run --gpus all --ipchost --ulimit memlock-1 --ulimit stack67108864 \ -v /data:/data -it CUDA 镜像或厂商镜像 bash这里--ipchost和--ulimit是为了避免 PyTorch DataLoader 的多进程共享内存问题。镜像标签以实际使用的驱动版本为准建议每次基准前固定版本号并记录保证结果可复现。4.2 最小训练基准脚本训练基准的模型不用太大但要能体现矩阵运算、attention、反向传播和优化器更新所以用小 Transformer 就足够。下面脚本会固定随机种子运行若干步输出每步平均耗时和训练 Loss。import torch import torch.nn as nn import time torch.manual_seed(0) class ToyLM(nn.Module): def __init__(self, vocab_size1000, d_model512): super().__init__() self.embed nn.Embedding(vocab_size, d_model) self.transformer nn.Transformer( d_modeld_model, nhead8, num_encoder_layers4, num_decoder_layers4, dim_f