InferenceX Data Pipeline

导言

本文对齐 InferenceX 官网、公开 API、官方 InferenceX / InferenceX-app 仓库、AIPerf，以及 Ascend 与 vLLM-Ascend 一手资料，回答“哪些 NVIDIA 基线真实存在、AgentX 能否迁移到 A3/A5、需要多少机器、数据怎样采集和提交”。结论是：AgentX 客户端可以直接压测 Ascend 的 OpenAI-compatible 服务，但模型可运行不等于能够同配置复现；DeepSeek-R1 当前没有原生 vLLM 的 H100/H200/B200 对照数据，A3 也不支持与 NVIDIA FP4 等价的原生浮点格式。应先建立严格对照的离线长表，再推进官方 runner、PR 与自动入库。

结论

1. 指定对比页不能直接作为“vLLM 基线”。 当前 /api/v1/availability 中，DeepSeek-R1 在 H100、H200、B200 上均没有 framework=vllm；现有后端是 Dynamo SGLang、Dynamo TRT-LLM、SGLang 或 TRT-LLM。因此，DeepSeek-R1 B200 vs H100 8K→1K 展示的是硬件组合的现有结果，不能据此得到一个控制后端为 vLLM 的 B200/H100 对照组。
2. Kimi K3 的问题是场景缺口，不是完全无数据。 2026-08-26 读取 benchmarks?model=Kimi-K3 得到 107 条最新结果；其中 H100/H200/B200 共 50 条，全部是 agentic_traces：H200 有 35 条原生 vllm 行，B200 有 15 条 dynamo-vllm 行，H100 为 0。三者均没有固定 8K→1K 的 Kimi K3 数据。
3. availability 不能当作 benchmark 点数。 它只暴露模型、ISL/OSL、精度、硬件、框架、推测方法、是否解耦、场景和日期，不含并发、拓扑、offload 等维度；例如 Kimi K3 在 H200 只有 1 个 availability 覆盖桶，却对应 35 条最新 benchmark 行。API schema 明确列出了这两个接口的不同字段。
4. 自动化覆盖“执行—采集—入库”，不覆盖“自动发现新平台”。 每个数据点来自公开 GitHub Actions；但组合的镜像、命令、并行策略和 runner 都先固化到仓库，配置变化后才重跑。官网说明现在已经不是 nightly 全量跑，而是配置发生变化时重跑。复现说明
5. 正式上站要走官方 PR 和 CI。 本地结果可用公开 API、图表 CSV、GitHub Actions artifact 或数据库快照离线比较；要进入官网数据库，必须让官方 workflow 产生并接管 artifact，随后由 InferenceX-app 执行 ingest-results 或 ingest-agentic-results。
6. AgentX 本身支持 Ascend，但服务端模型支持决定能否完成测试。 AIPerf 只要求可达的 OpenAI-compatible streaming chat endpoint，不绑定 CUDA；真正的约束是模型权重、量化格式、最大上下文、KV cache、并行拓扑和长会话并发。
7. A3 不能与 B200 的“FP4”直接等量替换。 A3 可用 W8A8/W4A8，其中 W4A8 是 INT4 权重、INT8 激活；原生 MXFP4/MXFP8 是 Ascend 950/A5 能力。即使 A5 支持 MXFP4，也不能把它和 NVIDIA NVFP4 只按“4 bit”视为同一精度，必须同时报告格式与精度评测。
8. Kimi K3 目前是明确的困难项。 网站原生 vLLM 的 K3/AgentX 基线只在 H200 上出现，使用 32 GPU；按设备数换算是 2 台 A3 或 4 台 A5，但当前 vLLM-Ascend 的 A3 验证仍处于 WIP，公开实验用了 16 台 A3，且有 KV 容量和算子稳定性问题。这个例子说明“拓扑等价机器数”不能代替“已验证可运行机器数”。

当前数据矩阵

统计口径

本文在 2026-08-26 一次性读取公开 availability API，共得到 6,568 个历史覆盖记录，包含 13 个数据库模型 key、10 个硬件 key、13 个 framework key 和 single_turn / agentic_traces 两类 benchmark。接口只返回已经存在无错误 benchmark 行、且 workflow 有完成结论的覆盖组合；字段定义见 InferenceX-app 查询实现 和 API Reference。

前端会把部分数据库 key 合并展示，例如 kimik2.5、kimik2.6、kimik2.7-code 都归入 Kimi-K2.5，glm5 和 glm5.1 都归入 GLM-5；映射以 models.ts 为准。

当前前端还把模型分为生命周期层级：默认主线包括 DeepSeek-V4-Pro、Kimi-K3、MiniMax-M3、GLM-5.2/5.3 和 Qwen-3.5；DeepSeek-R1 已进入 maintenance；Kimi-K2.5、GLM-5、gpt-oss-120b、MiniMax-M2.5 和 Llama-3.3-70B 等属于 deprecated。生命周期定义见 data-mappings.ts。因此，旧模型有数据不代表官方仍会持续补齐新硬件和新后端。

名称漂移

当前 Comparison 页面文案已经出现 GLM 5.3，但公开 availability 和前端模型常量仍是 glm5.2 / GLM-5.2。自动化脚本应先查询 availability 和模型常量，不应抓取营销页面名称作为 API 参数。这更像发布迁移中的短期不一致，不能自行推断两者等价。

H100、H200、B200 全后端覆盖

下表按前端展示模型合并，只列出当前公开数据中出现过的框架。— 表示该模型与硬件没有任何公开覆盖记录。

模型	H100	H200	B200
DeepSeek-R1-0528	Dynamo SGLang、Dynamo TRT-LLM	Dynamo SGLang、Dynamo TRT-LLM、SGLang、TRT-LLM	Dynamo SGLang、Dynamo TRT-LLM、SGLang、TRT-LLM
DeepSeek-V4-Pro	—	Dynamo SGLang、SGLang、vLLM	Dynamo SGLang、Dynamo vLLM、SGLang、TRT-LLM、vLLM
GLM-5 / GLM-5.1	—	SGLang	Dynamo SGLang、SGLang、TileRT
GLM-5.2	—	Dynamo SGLang	SGLang
gpt-oss-120b	vLLM	TRT-LLM、vLLM	TRT-LLM、vLLM
Kimi-K2.5 / K2.6	—	vLLM	Dynamo TRT-LLM、Dynamo vLLM、vLLM
Kimi-K3	—	vLLM	Dynamo vLLM
Llama-3.3-70B	vLLM	TRT-LLM、vLLM	TRT-LLM、vLLM
MiniMax-M2.5	vLLM	vLLM	Dynamo vLLM、TRT-LLM、vLLM
MiniMax-M3	vLLM	vLLM	Dynamo vLLM、TRT-LLM、vLLM
Qwen-3.5-397B-A17B	SGLang	SGLang	SGLang、TRT-LLM

严格 framework=vllm

这里把 vllm、dynamo-vllm 和 llmd-vllm 视为不同框架 key。F 表示固定序列 single_turn，A 表示 AgentX agentic_traces；“3 seq”表示 1K→1K、1K→8K、8K→1K 均有记录。日期是该格最后一个 availability 日期，反映数据新鲜度，不是软件版本发布时间。

模型	H100	H200	B200
DeepSeek-R1-0528	—	—	—
DeepSeek-V4-Pro	—	F、FP8、1K→1K/8K→1K，2026-07-14	F+A、FP4、1K→1K/8K→1K，2026-08-22
GLM-5 / GLM-5.1	—	—	—
GLM-5.2	—	—	—
gpt-oss-120b	F、FP4、3 seq，2026-05-17	F、FP4、3 seq，2026-05-30	F、FP4、3 seq，2026-05-31
Kimi-K2.5	—	F、INT4、3 seq，2026-05-30	F、FP4/INT4、3 seq，2026-08-07
Kimi-K3	—	A、FP4、2026-08-07	—
Llama-3.3-70B	F、FP8、3 seq，2025-10-29	F、FP8、3 seq，2025-10-29	F、FP4/FP8、3 seq，2025-10-29
MiniMax-M2.5	F、FP8、3 seq，2026-06-04	F、FP8、3 seq，2026-06-05	F、FP4/FP8、3 seq，2026-06-04
MiniMax-M3	F+A、FP8、1K→1K/8K→1K，2026-08-12	F+A、FP8、1K→1K/8K→1K，2026-08-12	F+A、FP4/FP8、1K→1K/8K→1K，2026-08-16
Qwen-3.5-397B-A17B	—	—	—

以下是 H100/H200/B200 中额外出现的 vLLM 家族但非原生 vllm 覆盖：

模型	硬件	framework key	场景与精度	最后日期
DeepSeek-V4-Pro	B200	dynamo-vllm	F、FP4	2026-08-07
Kimi-K2.6	B200	dynamo-vllm	F、FP4	2026-07-31
Kimi-K3	B200	dynamo-vllm	A、FP4	2026-08-19
MiniMax-M2.5	B200	dynamo-vllm	F、FP4/FP8	2026-06-03
MiniMax-M3	B200	dynamo-vllm	F、FP4	2026-08-04

框架标识不一定等于实际入口

Kimi K3 的 B200 配置是一个具体反例：当前 nvidia-master.yaml 注释说明，配置为 launcher 路由保留 framework: dynamo-vllm，但该变体实际直接执行 vllm serve，没有 Dynamo frontend、worker 或 router。因此做严谨横向比较时不能只按 framework 字符串分组，还应核对 recipe、image、run URL 和拓扑。

Ascend 可运行性与机器规模

硬件口径

本文把“A3”按当前 vLLM-Ascend 文档常用的 Atlas 800 A3 运行环境计算，把“A5”按已公开的 Atlas 650E A5 / Ascend 950DT SKU 计算。两者不能只用营销名称代替具体 SKU。

平台	单机软件可见设备与 HBM	相关量化能力	仅按设备数换算
Atlas 800 A3	常见运行环境为 16 个逻辑 NPU × 64 GB；产品口径也会写成 8 × 128 GB，总 HBM 均为 1 TB	W8A8、W4A8；后者是 INT4 weight + INT8 activation，不是浮点 FP4	ceil(网站 GPU 总数 / 16)
Atlas 650E A5 / Ascend 950DT	8 NPU × 96 GB，总 HBM 768 GB	HiF8、MXFP8、MXFP4	ceil(网站 GPU 总数 / 8)

硬件容量来自 Atlas 800I A3 和 Atlas 服务器规格；Ascend 950 的新格式能力见 Huawei Connect 2025 路线说明。路线图中的 144 GB 950DT 与当前公开 96 GB SKU 不是同一容量口径，不能混用。

机器数不是性能等价

下表的 A3/A5 台数首先按网站该行的总加速器数量做拓扑换算，只回答“保留相同设备数量需要几台机器”，不代表 GPU 与 NPU 单卡性能、显存或互联等价。若严格固定 TP，显存不足时不能靠增加卡数解决，因为加卡已经改变 TP/EP/DP 配置；更合理的横评应固定模型、量化精度、场景、并发和延迟 SLO，允许各平台选择最优并行拓扑，并单独披露总设备数。

数据与 Ascend 叠加表

网站设备规模 是 H100/H200/B200 上原生 framework=vllm 行实际出现的 GPU 总数范围，不是理论最小值。A3/A5 两列是对应的单次配置换算；凡需要超过 2 台，均按要求标记为 难（>2 机）。最后一列再加入当前 vLLM-Ascend 的真实软件支持和已公开部署规模。

模型	网站原生 vLLM 数据	网站设备规模	A3 同设备数	A5 同设备数	Ascend 实际状态与判定
DeepSeek-R1-0528	H100/H200/B200 均无	—	—	—	A2/A3 支持 W8A8、最大 128K；A5 未显式列入当前矩阵。缺少 NVIDIA vLLM 对照组，不能直接横评
DeepSeek-V4-Pro	H200 固定；B200 固定 + AgentX	8、64	1、4 难	1、8 难	A3 为实验支持，官方 W4A8-MTP 配方至少 2 台；A5 原生支持 MXFP8/MXFP4，但 1.6T 权重的容量下界已超过单机，至少 2 台并需实测
GLM-5 / 5.1 / 5.2	均无	—	—	—	A3 上 GLM-5.2：W8A8/W4A8C8 1 台，BF16 2 台；64K 低延迟配方为 2 台。A5 当前明确列出 GLM-5.1，但网站无原生 vLLM 对照
gpt-oss-120b	H100/H200/B200 固定三种序列	1–8	1	1	当前 vLLM-Ascend 支持矩阵未列出该模型；规模虽小，仍需先完成模型适配验收
Kimi-K2.5	H200/B200 固定三种序列	4、8、16、64	1、4 难	1–2、8 难	A3 实验支持；固定 8K→1K 的 W4A8 配方可 1 台，高并发 PD 配方因显存建议 4 台，难（>2 机）。A5 未显式列出
Kimi-K3	H200 仅 AgentX	32	2	4 难	主支持矩阵尚未列入。当前 A3 WIP 实验用了 16 台，难（>2 机），仍有 1M KV 容量、原生算子崩溃和性能回退问题；不适合作为首个复现模型
Llama-3.3-70B	H100/H200/B200 固定三种序列	1–8	1	1	vLLM-Ascend 扩展列表覆盖到 Llama 3/3.1/3.2，3.3 未被当前矩阵明确确认；需先做兼容性 smoke test
MiniMax-M2.5	H100/H200/B200 固定三种序列	1–64	1–4 难	1–8 难	A3/A5 均为实验支持；固定小规模可优先试验，但复现 64 卡网站曲线为 难（>2 机）
MiniMax-M3	H100/H200/B200 固定 + AgentX	2–64	1–4 难	1–8 难	A3 为实验支持，PD disaggregation 尚未支持且存在多模态 parser 已知问题；A5 未显式列出。固定序列可 smoke test，完整 AgentX/64 卡曲线为 难（>2 机）
Qwen-3.5-397B-A17B	H100/H200/B200 均无原生 vLLM	—	—	—	A3 W8A8 固定测试可 1 台、BF16 2 台；推荐 PD 为 3 台，难（>2 机）。A5 原生支持，但网站缺少同后端对照

表中网站 GPU 总数来自公开 benchmarks 行的单节点和 prefill/decode 拓扑字段。Ascend 模型状态以 vLLM-Ascend Supported Models 为主，已验证规模分别参考 DeepSeek-V4-Pro、Kimi-K2.5、GLM-5.2 和 Qwen-3.5 配方。

FP4 与量化可比性

vLLM-Ascend 当前明确区分平台能力：量化与 Expert Parallel 文档 中，A2/A3 支持 W8A8、动态 W8A8 和 W4A8，Ascend 950 才支持 MXFP4/MXFP8。因此应这样记录：

• A3 对 B200 FP4：不能声称同精度复现。可做 W4A8 或 W8A8 的“平台最优量化”比较，但必须另列模型质量、显存和吞吐，不能把结果标签简写成通用 FP4。
• A5 对 B200 FP4：可以比较低比特浮点路线，但 MXFP4 与 NVIDIA 结果中的具体 FP4 recipe 仍可能在 block size、scale、累加精度和 kernel 上不同。需要保存完整 quant config，并运行相同 eval。
• 严格横评：优先选择双方都能稳定运行的 BF16/FP8-like 或经质量评测对齐的量化权重；若格式不同，将结论写成“各平台最佳可用配置”，不要写成单纯硬件倍数。

AgentX 在 Ascend 上的判定

AgentX 客户端层面是支持的：AIPerf 不关心服务端是 CUDA 还是 Ascend，只要 vLLM-Ascend 暴露兼容接口。但一个配置能否跑完，要同时通过以下四个门槛：

1. 模型门槛：模型必须在当前 vLLM-Ascend 版本和目标 A3/A5 SKU 上受支持；实验状态不能等同于生产可跑。
2. 上下文门槛：AgentX 的公开 trace 输入常达 100K 以上，尾部可超过 300K；固定 8K→1K 跑通不能证明 AgentX 能跑。必须以目标数据集实际 p95/max token 长度配置 max_model_len。
3. KV 与并发门槛：conc 是存活 session tree 数，子 Agent 会使瞬时请求数更高。应从 conc=1 逐级扩展，并记录 cache hit、失败率和是否 OOM，不能照抄 NVIDIA 的高并发列表。
4. 有效性门槛：本地 trace 与 --unsafe-override 只能 smoke test；正式可比运行必须使用固定公开 corpus、至少 900 秒，并检查 submission_valid。

Kimi K3 是上述门槛同时叠加的反例。公开 Kimi K3 支持 WIP 显示，A3 的 1M 上下文实验在 16 台机器上仍遇到 KV 空间不足；另有 原生算子崩溃 和 性能回退 记录。因此不能根据 H200 的 32 GPU 行简单承诺“2 台 A3 可跑”。

推荐的首轮范围

1. 若目标必须是 DeepSeek-R1：先在 NVIDIA 上补跑同一版本、同一场景、原生 vLLM 的控制组，再测 A3/A5。否则网站指定页面只能作为展示样例，不能作为 vLLM 硬件结论。
2. 若目标是先证明链路：优先用 Kimi-K2.5 的固定 8K→1K 做单机 A3 smoke test；它有 H200/B200 原生 vLLM 数据，且 A3 有公开单机 W4A8 配方。随后再逐步增加并发。
3. 若目标是证明 AgentX：先在受支持模型上跑 corpus 子集和 conc=1，再跑完整 900–1,800 秒测试。MiniMax-M3 的网站对照最完整，但 Ascend 仍是实验支持，风险高于固定序列。
4. 暂不以 Kimi K3 为第一目标：它既缺少固定序列数据，又处于 Ascend 多机 WIP；即使投入超过 2 台机器，也不能保证形成可发布结果。

AgentX 定义与运行入口

测量对象

AgentX 是 AIPerf 中的 inferencex-agentx-mvp 场景，重放长上下文、多轮 agentic-coding 会话树。它保留输入/输出长度、共享前缀、子 Agent 扇出、轮间等待和 KV-cache 复用结构；官网明确说明提示文本经过合成，不重放私有用户内容。AgentX 方法说明

核心锁定条件包括：

• OpenAI-compatible streaming chat endpoint：用于得到 TTFT 和 ITL。
• 固定重放规则：保留轮间延迟，系统全空闲最多压缩到 10 秒。
• first_turn_prefix cache busting：阻止同一 trace 重放造成跨 session 的虚假缓存命中，同时保留 session 内部复用。
• 有效时长：至少 900 秒，默认 1,800 秒。
• 固定公开语料：可比较或提交的运行应使用日期固定的 semianalysis_cc_traces_weka_062126；滚动 alias 会漂移。
• 有效性标志：AIPerf 在结果写入 submission_valid。使用本地任意 Weka 目录或 --unsafe-override 只能做 smoke test，结果会标记为不可提交。

完整约束和当前 MVP 状态见 AIPerf AgentX tutorial。

最小运行命令

aiperf profile \
  --scenario inferencex-agentx-mvp \
  --url http://localhost:8000 \
  --model YOUR_MODEL \
  --endpoint-type chat \
  --public-dataset semianalysis_cc_traces_weka_062126 \
  --concurrency 256

这条命令只要求后端暴露 OpenAI-compatible chat API，因此 AgentX 客户端入口本身并不绑定 CUDA、vLLM 或 SGLang。能否得到可比较结果仍取决于服务端能否承受数据集中的上下文、会话树与并发，并满足 submission_valid 的限制。并发表示“同时存活的 session tree 数”，不是瞬时 HTTP 请求数；子 Agent 扇出时，实际请求并发可以更高。

在 InferenceX 官方仓库中，运行入口分为三层：

1. 配置层：configs/*-master.yaml 的 scenarios.agentic-coding 定义模型、硬件 runner、精度、框架、TP/PP/EP、offload 和 conc-list。配置规范
2. 服务层：benchmarks/ 中的脚本和 recipe 启动具体推理服务；单节点和多节点 workflow 模板把矩阵字段变成环境变量与 artifact 名称。benchmark 目录
3. 调度层：run-sweep.yml 执行 AgentX matrix，聚合结果，并把成功 artifact dispatch 给 InferenceX-app。

数据采集与 schema

自动化边界

数据链路可以概括为：

人工 PR / perf-changelog
  → GitHub Actions 在注册的真实硬件 runner 启动服务
  → benchmark_serving 或 AIPerf 发流并采集请求/服务指标
  → process_result 或 process_agentic_result 聚合
  → GitHub Actions 上传 benchmark、raw trace、log、eval artifact
  → InferenceX-app 校验、标准化、入库并刷新 availability
  → 官网通过 /api/v1/* 读取数据库

因此“工具自动采集”是成立的，但应限定为：组合被人工注册并触发后，测试执行、指标采集、artifact 上传和网站入库自动完成。它不是从未知硬件环境自动发现模型，也不是抓取用户已有日志后自动生成可发布结果。官网说明每个点都链接到对应的公开 GitHub Actions run、recipe、日志与 artifact。Reproducibility

固定序列结果

单节点首先生成 <RESULT_FILENAME>.json，utils/process_result.py 再生成 agg_<RESULT_FILENAME>.json；collector 最终输出 results_bmk/agg_bmk.json，形状是 benchmark row 数组。主要字段包括：

• 配置：hw、model、infmax_model_prefix、framework、precision、spec_decoding、image、disagg、is_multinode、isl、osl、conc。
• 拓扑：单节点的 tp、pp、dcp_size、pcp_size、ep、dp_attention；多节点拆成 prefill_*、decode_* 和对应 GPU 数。
• 指标：tput_per_gpu、input_tput_per_gpu、output_tput_per_gpu，以及 TTFT、TPOT、ITL、E2EL 等延迟分位数。

详细 schema 与 artifact 命名见 Results and Ingestion。

AgentX 结果

AgentX 同时上传聚合与原始 sibling：

bmk_agentic_<RESULT_FILENAME>   → 聚合 JSON
agentic_<RESULT_FILENAME>       → results/** 原始树
server_logs_<RESULT_FILENAME>   → 服务端日志

process_agentic_result.py 至少需要 profile_export.jsonl，并可读取 profile_export_aiperf.json、server_metrics_export.json 与框架日志。聚合 schema 重点包括：

• 场景与计数：scenario_type: agentic-coding、总请求数、成功请求数、request_accounting。
• 缓存与拓扑：KV offload、offload backend、CPU DRAM 分配、router、TP/PP/EP 等。
• 请求指标：QPS，TTFT/E2EL/ITL/TPOT/interactivity 分位数，token 分布，总吞吐和每 GPU 吞吐。
• 服务指标：prefix cache、KV-cache、token totals、告警和数据来源。
• 数据集溯源：从 AIPerf metadata.dataset 复制的 dataset。

入库后，公开 API 把配置字段置于顶层，把可演化的数值指标放入 metrics 对象；AgentX 行使用 benchmark_type=agentic_traces、isl=null、osl=null，并以 conc 表示用户/session-tree 并发。公开 BenchmarkRow schema

提交到网站

官方路径

官网没有公开的“上传结果文件”端点。根据 CONTRIBUTING.md 和 ingestion 实现，正式上站流程是：

1. Fork 仓库并增加或修改硬件 runner、master config、benchmark 脚本/recipe 和必要验证。
2. 所有可能影响性能的改动都在 perf-changelog.yaml 末尾追加记录，不得改写历史条目。
3. 提交 PR，运行 PR validation 和完整 sweep，包括 eval；官方建议使用 full-sweep-fail-fast label。
4. 由对应公司的 CODEOWNER 按最新 checklist 签字，并链接 validation/eval run、vLLM recipe 或 SGLang cookbook PR。
5. 获得核心 maintainer 审批；授权 maintainer 发布 /reuse-sweep-run，复用 PR 上已经成功的昂贵 sweep。
6. 合并后的 main workflow 通过 ingest-results 或 ingest-agentic-results 将 source run artifact 交给 InferenceX-app，完成 schema 迁移、标准化、upsert、availability 刷新和缓存失效。

不能只交本地 JSON

InferenceX-app 的写入身份绑定 GitHub run_id + run_attempt、标准化 config 和配套 artifact。即使本地 JSON 字段看起来一致，也缺少 runner、workflow、changelog、raw sibling、eval 与日志溯源，不能通过现有公开流程直接出现在网站上。这是根据官方 ingestion 主键和 dispatch 链路得出的结论。

最低合作前提

若希望新硬件正式进入网站，需要提前与 InferenceX maintainer 对齐：

• 可供 GitHub Actions 调度的稳定 runner/集群与硬件标签；
• 官方可审计的容器或上游运行时镜像；
• 固定模型权重、精度、tokenizer/chat template 与并行拓扑；
• 与现有 benchmark schema 对齐的服务启动、健康检查、指标采集和清理逻辑；
• 可公开的 workflow 日志、artifact 和 CODEOWNER 审批责任。

离线横向比较

推荐顺序

1. 快速覆盖盘点：先查 /api/v1/availability，确定真实存在的模型、硬件、框架、精度、场景和日期。
2. 获取可比较行：固定 display model 后查 /api/v1/benchmarks?model=...；历史趋势使用 /api/v1/benchmarks/history。固定序列必须精确匹配 ISL、OSL；AgentX 使用 benchmarkType=agentic_traces，不要错误地过滤掉 isl=null / osl=null。
3. 保留溯源：每条横向比较至少保留 id、date、run_url、image、recipe fingerprint、模型/精度/框架、并行拓扑、GPU 总数、并发、offload、MTP 和 metrics。
4. 下载原始证据：需要检查未入库结果、服务日志或 AgentX raw trace 时，从 run_url 对应的 GitHub Actions 下载 results_bmk、agentic_*、server_logs_* 等 artifact。
5. 大规模历史分析：从 InferenceX-app DB Dump Releases 下载周度 PostgreSQL dump，校验 SHA256SUMS 后恢复到本地 PostgreSQL。官网也允许在图表直接导出 raw CSV。数据使用说明

API 示例

# 发现 H100/H200/B200 的原生 vLLM 覆盖
curl --fail --compressed \
  'https://inferencex.semianalysis.com/api/v1/availability' \
| jq '[.[] | select(
    (.hardware == "h100" or .hardware == "h200" or .hardware == "b200")
    and .framework == "vllm"
  )]'

# Kimi K3 当前最新结果；随后必须继续按硬件、框架和场景过滤
curl --fail --compressed \
  'https://inferencex.semianalysis.com/api/v1/benchmarks?model=Kimi-K3' \
| jq '[.[] | select(
    (.hardware == "h100" or .hardware == "h200" or .hardware == "b200")
    and .benchmark_type == "agentic_traces"
  ) | {
    id, date, hardware, framework, precision, conc,
    is_multinode, num_prefill_gpu, num_decode_gpu,
    spec_method, offload_mode,
    tput_per_gpu: .metrics.tput_per_gpu,
    median_ttft: .metrics.median_ttft,
    p95_e2el: .metrics.p95_e2el,
    run_url
  }]'

可比性主键

离线表格不能只按“模型 + GPU”对齐。至少应把以下字段作为联合主键或严格过滤条件：

• 模型权重版本、tokenizer 与 chat template；
• 场景与数据集版本：固定 ISL/OSL，或 AgentX 日期固定 corpus、随机种子与 submission_valid；
• 精度与量化实现；
• framework、image/commit、MTP/spec method；
• 单/多节点、TP/PP/EP/DCP/PCP、prefill/decode worker 数与总 GPU 数；
• disaggregation、router、KV offload/backends；
• concurrency、benchmark duration 和失败率；
• 指标定义与单位，特别是 per-GPU、per-chip 与整个部署总吞吐之间的差别。

建议交付物

第一阶段先维护一份“公开基线 + 本地新硬件”统一长表，所有行保留 source=InferenceX API | local 与 official=true | false。只有联合主键完全一致的行才计算性能比；其余行只作为能力覆盖或成本估算，不进入一对一性能结论。正式上站是第二阶段，不能替代第一阶段的本地可比性验证。

一手来源

• InferenceX Comparison Catalog
• InferenceX Dashboard
• InferenceX Public API Reference
• InferenceX Availability API
• InferenceX About and Reproducibility
• SemiAnalysisAI/InferenceX
• Results and Ingestion
• Configuration Schema
• NVIDIA Master Config
• Contributing
• InferenceX-app Model Mapping
• InferenceX-app DB Dumps
• AIPerf AgentX MVP Tutorial
• AgentX Harness
• Atlas 800I A3
• Atlas A5 / Ascend 950 Server Specifications
• vLLM-Ascend Supported Models
• vLLM-Ascend Quantization
• DeepSeek-V4-Pro on Ascend
• Kimi-K2.5 on Ascend
• GLM-5.2 on Ascend
• Qwen-3.5-397B on Ascend
• Kimi K3 Ascend Support WIP

评论