Jalapeño推理芯片：别只看3.6倍低延迟
同一块推理硬件，吞吐量高，不代表 Agent 一定快。
Agent 真正关心的是：
一个任务连续调用10次模型时，
每一步到底等多久？
OpenAI 今天公布 Jalapeño 首批公开测试结果。它是 OpenAI 第一款自研推理芯片，测试覆盖 GPT‑OSS 120B、DeepSeek R1 670B 和 Kimi K2.5 1T。官方给出的核心结果是：
峰值吞吐下：
1.5—1.9× 更多 AI work / watt
端到端延迟：
1.7—3.6× 更低
高交互工作负载：
2.1—4.1× 更高性能
Jalapeño 标称 700W，但公开测试中的持续功耗保持在 550W 或以下。
最值得注意的是 OpenAI 没把重点只放在 tokens / second，而是强调：
matched user experience
+
performance per watt
+
end-to-end latency
这套测法比“单卡吞吐榜”更适合 Agent。
为什么Agent对延迟比Chat更敏感
普通 Chat：
用户提问
→ 模型回答
Agent：
Planner
→ Search
→ Model
→ Tool
→ Model
→ Reviewer
→ Model
如果有 8 次串行模型调用，每次多 500ms：
500ms × 8 = 4秒
这还没算 Tool。
所以 Agent 的延迟不是 Single Call Latency，而是 Critical Path Latency。
一个最小Critical Path模型
steps = [
{"name": "planner", "ms": 850},
{"name": "reasoner-1", "ms": 1200},
{"name": "tool", "ms": 430},
{"name": "reasoner-2", "ms": 1100},
{"name": "reviewer", "ms": 900},
]
total = sum(step["ms"] for step in steps)
print(total)
输出：
4480ms
如果模型侧整体降低 35%，Agent 总耗时也不会降低 35%，因为 Tool 还在关键路径里。
所以推理芯片 Benchmark 最好最终映射到：
Task Wall Time
Prefill和Decode要分开测
Agent 每个 Turn 都可能带：
System Prompt
Conversation
Memory
RAG
Tool Schema
输入很容易达到：
20K
50K
100K tokens
这时 Prefill 很重要。
而长代码生成、报告生成则更依赖 Decode。
内部 Benchmark 至少分：
profiles:
interactive:
input_tokens: 8000
output_tokens: 800
rag:
input_tokens: 32000
output_tokens: 1200
coding:
input_tokens: 64000
output_tokens: 4000
long_context:
input_tokens: 128000
output_tokens: 2000
每组记录：
TTFT
TBT
E2E
Throughput
Power
Task Success
TTFT和TBT不能混
TTFT：
Time to First Token
影响“用户觉得卡不卡”。
TBT：
Time Between Tokens
影响连续输出速度。
高交互 Agent 经常是：
短调用
→ Tool
→ 短调用
所以 TTFT 会被反复累积。
这类任务更应该关注：
TTFT + E2E
而不是只看 Decode Token/s。
Kimi K2.5 1T这个结果尤其值得拆
OpenAI 给出的 Kimi 测试里：
约1.5×更高峰值性能/瓦
约3.4×更低端到端延迟
这意味着 Energy Efficiency 和 Latency 同时改善。
传统推理服务常见取舍是：
拉高Batch
→吞吐提高
→单用户延迟变差
如果一种架构能在更宽 Operating Range 上保持 Pareto Frontier，它对 Agent 服务的意义会比离线 Batch 更大。
但比较功耗口径必须统一
公开图里比较使用的是各加速器的 published chip power rating：
Jalapeño:
700W
GB200:
1200W
GB300:
1400W
但 Jalapeño 自己的持续实测：
<= 550W
企业内部复测不能把 TDP 和墙上电表实测功耗混在一起。
我会统一成Rack-level Power
真正生产成本：
GPU/ASIC
+
CPU
+
Memory
+
NIC
+
Cooling
+
Power Conversion
所以更实际的是：
Successful Tasks / Rack kWh
而不是简单：
tokens / chip watt
一个真正适合Agent的能效指标
假设：
系统A：
10000 Tasks
20 kWh
成功率80%
系统B：
9000 Tasks
15 kWh
成功率95%
A：
8000 / 20 = 400 success/kWh
B：
8550 / 15 = 570 success/kWh
B 总任务数更少，但“成功工作/电量”更好。
Agent硬件Benchmark必须绑定Task Success
如果更快的推理配置来自更激进量化，但 Tool 选择错误上升，性能数字就没有意义。
记录：
{
"profile": "coding-32k",
"p95_latency_ms": 4200,
"throughput_tps": 310,
"rack_power_w": 6100,
"task_success": 0.91
}
同一个 Operating Point 同时看速度、功耗和成功率。
不要让Batch把真实延迟藏起来
最容易做出漂亮吞吐的方法：
提高Batch Size
但交互式 Agent 应该先固定：
P95 Latency SLO
再比较最大可持续吞吐。
例如：
P95 <= 2s
条件下，谁还能保持更高 Throughput。
这才和真实用户体验一致。
一个简单压测Gate
benchmark_gate:
interactive:
p95_e2e_ms: 2000
min_task_success: 0.98
coding:
p95_e2e_ms: 12000
min_task_success: 0.90
power:
max_rack_watts: 8000
先满足 SLO，再比较吞吐。
我还会记录Model Wait Ratio
模型等待总时间 / Task Wall Time
如果：
80%
换更快推理硬件非常有价值。
如果只有：
25%
剩下都在数据库、浏览器和人工审批，硬件再快也很难改变整体体验。
这也是为什么不能直接拿 Jalapeño 的公开结果推算“产品会快3倍”。
公开 Benchmark 说明的是推理系统，产品最终收益还取决于：
模型等待占比
任务图
Tool延迟
缓存
Batch
Context长度
最后一个值得关注的点：它是按Agent负载设计的
OpenAI 明确说 Jalapeño 从设计之初就针对现代和未来语言模型，尤其是 interactive agents，并把芯片、Memory、Network、Serving Software 和 Rack System 一起优化。
这意味着未来 Agent 性能优化越来越会变成：
Model
+
Compiler
+
Serving
+
Memory
+
Network
+
Silicon
全栈一起做。
Jalapeño 首批数据里，“3.6倍低延迟”当然很抓眼球。
但如果我是做生产 Agent，我更关心：
同样P95下能撑多少Task？
每个成功Task耗多少电？
长Context Prefill到底快多少？
多步Agent总Wall Time下降多少？
只有这些问题回答清楚，芯片 Benchmark 才真正能转成产品价值。
以后看任何 AI 推理硬件，也应该尽量少看单卡峰值，多看：
matched latency
+
task success
+
performance per watt
+
end-to-end agent time
这几个指标更接近 Agent 真正要付的钱和用户真正要等的时间。
更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：
https://www.zyentor.com/