Files
calculet-npu-research-archive/reports/Calculet-NPU-证据索引与厂商确认清单-20260802.md
T

302 lines
20 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Calculet NPU 证据索引与厂商确认清单
日期:2026-08-02
用途:给总体报告、适配教程、接口矩阵和并发演进设计提供可追溯证据,并将尚不能由本地资料证明的事项转化为厂商问题单。
本索引继续作为所有实施规格的证据底座。实施规格新增的结构、阈值和状态机属于 E4/C2 设计,涉及 compiler/kernel/新 calbin 的部分保持 C3;不得因文档写得更细就提升能力状态。
## 1. 证据等级
| 等级 | 含义 | 可支持的结论 |
| --- | --- | --- |
| E0 | 当前样机实测/进程输出 | 当前环境在该次测试中的真实行为 |
| E1 | 当前镜像、生产二进制、源码和当前模型产物 | 当前产品实现与静态能力 |
| E2 | CalRT 0.7.6 头文件 + 同版动态符号 | API 可编译且动态库有实现入口;不等于产品已验证 |
| E3 | PDF 或 Git 非生产历史分支 | 文档/演进线索;必须与当前版本复核 |
| E4 | 工程推导或建议 | 设计输入;需要实验或厂商确认 |
能力状态仍使用 C0-C4:C0 当前确认,C1 SDK 有但未接入,C2 可工程实现,C3 依赖厂商工具链,C4 不支持或不应开放。E 等级描述证据强弱,C 状态描述能力成熟度,两者不能混用。
## 2. 路径别名
下文用以下别名缩短路径:
```text
$ROOT = outputs/Calculet-NPU-analysis-bundle-20260801/remote-export/extracted
$SRC = $ROOT/llama.cpp-full/llama.cpp
$BASE = $ROOT/baseline
$MODEL = $ROOT/models-complete/models/Qwen3-30B-A3B-dynamic-W8A8-W4AF16-full_layers_merged_2_chips_40960_fa_2026-05-22
$SDK = work/research-sources/calrt-sdk-0.7.6/usr/local
$PDFTXT = tmp/pdfs/runtime-api.txt
```
文件行号以当前本地归档为准。二进制动态符号的复核命令为:
```bash
nm -D --defined-only "$SDK/lib/libcalrt-linux-x86_64.so.0.7.6" | c++filt
```
## 3. 归档完整性
| 归档 | SHA-256 | 说明 |
| --- | --- | --- |
| `calculet-models-complete-20260801.tar.zst` | `ebb143415bc44456599265d07e0b0057497d8708ebafb23f53435d0c189622d8` | 完整模型产物 |
| `llama.cpp-full-no-exclusions-fd9bd632.tar.gz` | `55d28eb0b72eb8e22627028965912b3a274b76314f8d726f67427a42ee0b2d25` | 完整源码和 Git 历史 |
| `calculet-llama-v0.4.8-release.oci.tar` | `1ad4aba68c6a96cf7f592fdcd8e0c801bf022845aaf71cd49b909abd60365bf3` | OCI 镜像 |
远端导出目录还保留分步下载 SHA-256、assembly complete 和 verification complete 文件。后续分析以这些本地只读副本为准,不需要反复连接样机。
## 4. 构建与版本证据
| ID | 结论 | 证据 | 等级/状态 |
| --- | --- | --- | --- |
| B01 | 镜像基于 Ubuntu 22.04 | `$BASE/environment/container-image-inspect.json:27,74,97` | E1/C0 |
| B02 | HostRT 从 `/home/user1/CalCulet/calrt/hostrt` Release/shared 构建、安装后删源 | 同文件 `:200` | E1/C0 |
| B03 | llama.cpp 以 `LLAMA_USE_CALRT=ON` 构建 | 同文件 `:220``$SRC/build/CMakeCache.txt:690` | E1/C0 |
| B04 | `GGML_CALRT=OFF`,不是 GGML 逐算子 backend | `$SRC/build/CMakeCache.txt:371` | E1/C0 |
| B05 | Release`-O3 -DNDEBUG` | `$SRC/build/CMakeCache.txt:59``$SRC/build/src/CMakeFiles/llama.dir/link.txt:1` | E1/C0 |
| B06 | 链接 CalRT 0.7.6 | 上述 `link.txt:1``/usr/local/lib/libcalrt-linux-x86_64.so.0.7.6` | E1/C0 |
| B07 | 当前服务版本/源码是 `fd9bd632` | `$BASE/environment/llama-server-version.txt:1``llama-git-log-500.txt:1` | E1/C0 |
| B08 | `origin/runtime_replace` 在历史中,但不是 HEAD | `llama-git-log-500.txt:1,7-27` | E3/C3 |
由 B02 可知最终镜像不含 HostRT 源码;本地 SDK 头文件和 SO 足以调用公开接口,不足以重建 Runtime。B08 只表明 cal-llm/EngineCore 的厂商方向,不能称为现网。
## 5. 当前执行链证据
| ID | 结论 | 源码位置 | 等级/状态 |
| --- | --- | --- | --- |
| R01 | 创建单个 PCIe VirtualDevice 并检查状态 | `$SRC/src/llama-calrt.cpp:41-44` | E1/C0 |
| R02 | 从固定寄存器读 CalcoreRT commit 并读 CalRT 版本 | 同文件 `:46-58` | E1/C0;任意寄存器仍 C4 |
| R03 | `CreateCalbin`、configure、读取 max_seq、创建 KvManager | 同文件 `:86-96` | E1/C0 |
| R04 | 按每个唯一 sequence 拆 ubatch | 同文件 `:151-166` | E1/C0 |
| R05 | KV Apply 失败无限忙等 | 同文件 `:171-177` | E1/C0 缺陷 |
| R06 | 推理后 KV Apply 失败调用 `abort()` | 同文件 `:201-214` | E1/C0 缺陷 |
| R07 | 子模型使用名称 substring 查找 | 同文件 `:820-851` | E1/C0 缺陷 |
| R08 | token 数 >1 选 prefill,否则 decode,不能混合 | 同文件 `:854-872` | E1/C0 |
| R09 | 每次 infer 创建 Runtime buffer | 同文件 `:878-881` | E1/C0 |
| R10 | 但 buffer 映射到 context 共享 vector | 同文件 `:909-924``:1174-1212` | E1/C0;并发阻断 |
| R11 | 设置 current/past sequence CSR | 同文件 `:891-897` | E1/C0 |
| R12 | prefill 只 slice 实际输入和输出 tile | 同文件 `:931-953` | E1/C0 |
| R13 | output layout 硬编码 D0=16 | 同文件 `:939-949` | E1/C0 缺陷 |
| R14 | `infer()` 后立即 `Wait()`,两者返回码均未检查 | 同文件 `:959-960`encoder `:1037-1038` | E1/C0,同步且错误处理缺陷 |
| R15 | Runtime 分层计时已读取 | 同文件 `:964-981` | E1/C0 |
| R16 | BF16 logits 转 FP32 | 同文件 `:559-617`;临时 vector 路径 `:671-732` | E1/C0 |
| R17 | server slot/scheduler 仍由 llama.cpp 管理 | `$SRC/tools/server/server.cpp:2401-2441` | E1/C0 |
| R18 | 服务实际调用 `calrt_decode` | 同文件 `:4334-4339` | E1/C0 |
| R19 | CalRT 指标读取未受 `USE_CALRT` 保护 | `cal_ctx` 声明 `:2409-2411`,无条件读取 `:4351-4361` | E1/C0 缺陷 |
## 6. KV adapter 证据
| ID | 结论 | 证据 | 等级/状态 |
| --- | --- | --- | --- |
| K01 | batch/full/update context 初始化返回空 | `$SRC/src/llama-kv-cache-calrt-adapter.cpp:5-27` | E1/C0 缺陷 |
| K02 | clear 调用 Runtime KvManager | 同文件 `:34-37` | E1/C0 |
| K03 | seq remove 只支持尾部删除,其他返回 false | 同文件 `:39-60` | E1/C0 限制 |
| K04 | seq copy/keep/add/div 是空实现 | 同文件 `:62-88` | E1/C0 缺陷 |
| K05 | seq min/max 委托 Runtime | 同文件 `:90-96` | E1/C0/C1,尚缺全场景测试 |
| K06 | state write/read 是空实现 | 同文件 `:98-111` | E1/C0 缺陷 |
| K07 | SDK 有 `canAllocate/Allocate/Free/Apply/DoShift/Clear` | `$SDK/include/calrt/calrt_kv.h:94-120` | E2/C1 |
| K08 | SDK 描述 batch layout、BF16/S8 V-cache | 同文件 `:25-64` | E2/C1 + 新 calbin C3 |
## 7. 模型结构、图与芯粒证据
| ID | 结论 | 证据 | 等级/状态 |
| --- | --- | --- | --- |
| M01 | 架构为 Qwen3 MoE48 层、hidden 2048 | `$MODEL/__Tokenizer/config.json:2-4,12,24` | E1/C0 |
| M02 | 32 Q heads、4 KV heads、head dim 128 | 同文件 `:10,21,25` | E1/C0 |
| M03 | 128 experts、每 token 8、expert FFN 768 | 同文件 `:19,22-23` | E1/C0 |
| M04 | vocab 151936、RoPE theta 1e6 | 同文件 `:29,37` | E1/C0 |
| M05 | model config 40960,但 tokenizer config 声明 131072 | `config.json:15``tokenizer_config.json:234` | E1/C0;运行取 calbin 40960 |
| M06 | prefill/decode batch 1、双芯粒、每芯粒 2 CalCore | `$MODEL/*.yaml:491-510,1017-1036` | E1/C0 |
| M07 | Flash Attention/one-token 均启用 | 同 YAML `:524-525,1050-1051` | E1/C0 |
| M08 | prefill dynamic D2Ddecode 非 dynamic D2D | 同 YAML `:526,1052` | E1/C0 |
| M09 | prefill 1496、decode 1398 个顶层 op | 对两个 `*_op_io_buf_ptr.yaml` 用 Ruby YAML `.size` | E1/C0 |
| M10 | profile 行数 prefill 1352/1351decode 1254/1253 | 对四个 `*.profparts` 执行 `wc -l` | E1/C0 |
| M11 | embedding 只在 chip0,其余层级算子两芯粒对应 | 四个 `.profparts` 的逐行/计数比较;chip0 第一行 embedding | E1/C0 |
| M12 | 两芯粒均出现全部 48 层和 128-expert grouped MoE 分片 | `.profparts` 与 op I/O YAML 中 `nbu_moe_dense_group`/shape | E1/C0,判定为 TP |
| M13 | 当前不是 PP 或 EP | M11/M12:两芯粒逐层执行,不是按层或 expert 集合分开 | E1+E4/C0 判断 |
算子计数来自结构化 YAML/line list,不是日志猜测。任何新的 TP/PP/EP 布局都必须通过新的 compiler 产物证明。
## 8. 编译输入与供应链证据
| ID | 结论 | 证据 | 等级/状态 |
| --- | --- | --- | --- |
| C01 | 原始 ONNX 路径被记录但 ONNX 未归档 | `$MODEL/*.yaml:529` 及 prefill `model_path` | E1/C3 |
| C02 | 两个子图使用同一 ONNX hash | 同 YAML `:1056-1058` | E1/C0 元数据 |
| C03 | calcc commit | 同 YAML `:1059-1060` | E1/C3 |
| C04 | TVM commit | 同 YAML `:1061` | E1/C3 |
| C05 | 开启 codegen/op case/C oplib/auto alloc | 同 YAML `:511-517,1037-1043` | E1/C3 |
| C06 | 当前归档没有 calcc、passes、kernel/oplib 源码或 compiler container | 完整文件 inventory + OCI history | E1/C3 |
`has_loaded_onnx=false``has_optimized_graph=false` 是 calcc 环境字段,不能据此断言最终图未经优化;融合算子本身证明图已形成高层融合。
## 9. I/O、内存和容量证据
| ID | 结论 | 证据/计算 | 等级/状态 |
| --- | --- | --- | --- |
| A01 | 模型目录 67 文件,models 树 68 文件 | `find ... -type f \| wc -l`;外层重复 vocab | E1/C0 |
| A02 | `param_blk0.bin` 9,404,557,312 B | `stat` 原文件 | E1/C0 |
| A03 | `param_blk1.bin` 8,782,227,456 B | `stat` 原文件 | E1/C0 |
| A04 | 参数文件合计 16.938 GiB | `(A02+A03)/1024^3` | E4 推算/C0 |
| A05 | DRAM reservation 15,113,064,448 B/芯粒地址计划 | `$MODEL/model_memory_reserved_info.txt:15` | E1/C0 |
| A06 | SRAM reservation 17,662,336 B/芯粒地址计划 | 同文件 `:16` | E1/C0 |
| A07 | 参数 chip0/chip1 映射按 mask 分离 | 同文件 `:19-32``:33-46` | E1/C0 |
| A08 | BF16 KV 总 3.750 GiB、每芯粒 1.875 GiB | `48*4*2*128*40960*2`;每芯粒 2 KV heads | E4 推算/C0 |
| A09 | prefill I/O `[1,40960]` INT32 + `[1,1,151936]` BF16 | prefill `submodel_memory_reserved_info.txt:27-31` | E1/C0 |
| A10 | decode I/O `[1,1]` INT32 + `[1,1,151936]` BF16 | decode 同文件 `:25-29` | E1/C0 |
| A11 | 单次 logits D2H 303872 B | 两个 submodel 文件的 output `size``151936*2` | E1+E4/C0 |
| A12 | decode 地址并集 10.634 GiB | `work/analyze_calculet_artifacts.rb` 输出 `work/calculet-artifact-analysis.tsv` | E4 可复算/C0 |
| A13 | prefill 地址并集 14.091 GiB | 同上 | E4 可复算/C0 |
| A14 | 静态 prefill command chip0 444610/18.979 GiB | 同 TSV,源 `pld_cpu_chip0_runtime_cmds_ping.txt` | E4 可复算/C0 描述 |
| A15 | 静态 prefill command chip1 444608/18.822 GiB | 同 TSV,源 chip1 文件 | E4 可复算/C0 描述 |
| A16 | `device_memory_required: 16777216 MB` 单位不合理 | model memory 文件 `:3` | E1/C3 待确认 |
| A17 | prefill `smodel_type` 被写为 `llm_decode` | prefill submodel 文件 `:2-3` | E1/C3 metadata 缺陷 |
A12/A13 是去重并合并后的 tensor 地址区间覆盖,不是峰值活跃内存;A14/A15 是 40960 上限图的静态 data-moving command 描述,不是短 prompt 的实测流量。两者均不得用于相加估算实际带宽。
## 10. Runtime API 证据
| ID | 结论 | PDF/SDK/符号证据 | 等级/状态 |
| --- | --- | --- | --- |
| I01 | PDF 示例存在 `CreateParser`0.7.6 是 `CreateCalbin` | `$PDFTXT:225``$SDK/include/calrt/calrt_calbin.h:27`;有动态符号 | E2/E3/C0 |
| I02 | `GetAllModels` PDF 返回 vectorSDK 返回 pointer | `$PDFTXT:230,475`calrt_calbin.h `:37` | E2/E3/C0 |
| I03 | PDF `GetModelInfo`SDK `GetModelByName` | `$PDFTXT:474`calrt_calbin.h `:36` | E2/E3/C0 |
| I04 | PDF infer 返回 voidSDK 返回错误码 | `$PDFTXT:441``calrt_infer.h:14-17` | E2/E3/C0 |
| I05 | PDF-only `RelocateTensorAddress/AllocDevMem` | `$PDFTXT:423-425,512`;头文件/动态符号均无同名项 | E2/E3/C4 |
| I06 | C++ infer 与 fixed task 均有 0.7.6 符号 | `calrt_infer.h:14-17` + `nm -D` | E2/C0 infer、C1 fixed |
| I07 | OutputBuf 有 pending/running/done/CCU exception 和 Wait | `$SDK/include/calrt/calrt_buffer.h:115-145` + 符号 | E2/C1 |
| I08 | VirtualDevice 有 SubmitJob、parallel mode、trace | `$SDK/include/calrt/calrt_vdevice.h:45-50` + 符号 | E2/C1 |
| I09 | VirtualDevice 只支持一个物理设备 | 同文件注释 `:3`、成员 `:112` | E2/C4 多板 |
| I10 | per-chip memory 和 reset 能力存在 | 同文件 `:61-96` + 符号 | E2/C4 特权面 |
| I11 | SDK 可读 golden | `$SDK/include/calrt/calrt_calbin.h:65-66` + 符号 | E2/C1 |
| I12 | SDK 有 queue counters、memory、trace | `$SDK/include/calrt/calrt_device.h:228-262` | E2/C1 |
| I13 | C API 提供 blocking/nonblocking/wait | `$SDK/include/calrt/calrt.h:212-242` + C symbols | E2/C1 |
| I14 | version、dtype bit size、full debug 均有符号 | `$SDK/include/calrt/calrt_utils.h:348-352` + `nm -D` | E2version C0debug C1/C4 |
| I15 | 错误码 0-29 覆盖版本、配置、timeout、busy、crash、shape 等 | `$SDK/include/calrt/calrt_errorlist.def:1-30` | E2/C1/C2 错误映射 |
## 11. 性能数据证据与限制
| ID | 结论 | 证据 | 解释 |
| --- | --- | --- | --- |
| P01 | 历史 CSV 有 163 数据行 | `$BASE/remote-tools/test_llama.cpp/client/llama_perf_logs.csv` | E1;原始记录可保留 |
| P02 | 记录中的 model 被硬编码成 `deepseek` | `client_new.py:183` | 标签不可信 |
| P03 | TTFT 被计算成 `predicted_ms + prompt_ms` | `client_new.py:270-272` | 不是客户端 time-to-first-token |
| P04 | 短上下文 decode 约 58-64 token/s,长度增加后下降 | CSV 分桶统计 | 只作为趋势,不作为正式基线 |
| P05 | ~33K 约 12 token/s~40K 约 10-16 token/s | CSV 原始行/分桶 | 需要新 harness 重测 |
正式性能报告必须重采客户端首字节、服务排队、prefill、decode、H2D/infer/D2H、sampling,并固定 prompt/output tokens 和并发。
## 12. 厂商确认清单
### 12.1 编译器与可复现供应链(阻断新模型)
| # | 必须确认/交付 | 验收形式 |
| --- | --- | --- |
| V01 | 固定 digest 的 compiler container | 离线可加载 OCI、SBOM、license |
| V02 | calcc `575c2d...` 和 TVM `7aebd1...` 是否可发布 | 二进制/源码/commit 对应说明 |
| V03 | 当前 Qwen3 完整编译命令和配置 | 一键脚本,无人工隐藏步骤 |
| V04 | hash `316f06...` 的原始 ONNX | 文件 + SHA-256 |
| V05 | ONNX dialect、dynamic shape、opset、external data 要求 | schema 和 checker |
| V06 | 量化工具、校准格式、W8A8/W4AF16 规则 | 可重放配置 + 校准集说明 |
| V07 | pass、codegen、C oplib、kernel 的版本对应关系 | manifest/SBOM |
| V08 | calbin 打包格式、metadata schema、golden 生成方式 | 版本化文档 + parser |
| V09 | compiler/license 能否在我方 CI 使用 | 书面授权和部署方式 |
### 12.2 算子与 kernel(阻断自主优化)
| # | 问题 | 需要的答案 |
| --- | --- | --- |
| V10 | 完整 op/shape/dtype/quant 支持矩阵是什么 | 区分 prefill/decode 和芯片型号 |
| V11 | CPU fallback 是否存在,如何在 profile/trace 识别 | 明确性能和正确性语义 |
| V12 | 自定义 op/kernel SDK 如何使用 | 示例、ABI、调试器、性能计数器 |
| V13 | fusion pass 如何控制和 A/B | 编译 flag 和未融合 golden |
| V14 | FA 的 sequence/batch/head/dtype 边界 | 支持表和 fallback |
| V15 | grouped MoE 的 token bucket、top-k、expert 上限 | kernel 契约和误差 |
| V16 | router/top-k 是否可保持 BF16/FP32 | 混合精度策略 |
| V17 | NPU top-k/sampling 是否已有 kernel/图接口 | 输出格式、随机数和采样参数 |
### 12.3 Batch、并发和 KV(性能主线)
| # | 问题 | 需要的答案 |
| --- | --- | --- |
| V18 | 能否交付 decode batch 4/8/16 calbin | 每档产物、golden、容量和性能 |
| V19 | prefill 支持哪些 batch/动态 shape | shape profile 与实际切片语义 |
| V20 | `EnableParallelMode` 的并发保证 | 最大 in-flight、线程安全、顺序和错误语义 |
| V21 | PING/PONG 是 buffer bank、engine 还是命令槽 | overlap 时序图和示例 |
| V22 | OutputBuf 状态及 counters 的精确定义 | 原子性、单位、何时清零 |
| V23 | job cancel/timeout 是否有安全接口 | DMA/KV/buffer 生命周期 |
| V24 | batch lane/KV slot 如何映射和释放 | inactive lane、mask、回收规则 |
| V25 | S8 V-cache 是只压 V 还是 K/V | 精度、布局、容量公式和对应 calbin |
| V26 | `DoShift` 支持哪些 llama KV 语义 | remove/copy/keep/add/div/state 对应表 |
| V27 | KV failure 后哪些状态可 rollback | 请求级/设备级恢复契约 |
### 12.4 芯粒、内存和拓扑
| # | 问题 | 需要的答案 |
| --- | --- | --- |
| V28 | 每芯粒/整板可用 DRAM、SRAM、带宽和互联拓扑 | 官方规格 + Runtime 可读指标 |
| V29 | 当前双芯粒具体是何种 TP 切分 | 每层矩阵维度、gather/reduce/D2D 说明 |
| V30 | 是否支持单芯粒 calbin和 chip affinity | 小模型示例产物 |
| V31 | 两芯粒能否各 configure 一个独立模型 | 地址、队列、reset、故障隔离契约 |
| V32 | 是否支持 PP/EPcompiler 如何选择 | TP/PP/EP 对照产物和 cost model |
| V33 | `device_memory_required` 的单位为何标为 MB | schema 修复和 Runtime 解析口径 |
| V34 | reservation 是每芯粒还是整板逻辑地址 | chip mask/别名/物理分配说明 |
| V35 | 多 calbin 是否可常驻 | model handle、namespace、quota、unload |
| V36 | 0.7.6 以后何版本支持多物理设备 | roadmap、API、兼容迁移 |
### 12.5 Trace、计数器和性能
| # | 问题 | 需要的答案 |
| --- | --- | --- |
| V37 | trace 输出格式、字段、时钟和开销 | schema + 解析器 + 示例 |
| V38 | 能否读 per-op/per-chip cycle、D2D/DDR/PCIe bytes | counter 列表和复位语义 |
| V39 | `GetModelWorloadByName` 的单位与拼写兼容 | 正式 API 定义 |
| V40 | static command dataSize 与实际动态流量关系 | dynamic D2D 计算说明 |
| V41 | 温度、功耗、频率、throttle 的 API | 采样频率和单位 |
| V42 | golden input/output 在当前产物中是否完整有效 | 实际 runner 通过结果 |
### 12.6 Metadata 和兼容性缺陷
| # | 问题 | 需要的答案 |
| --- | --- | --- |
| V43 | prefill 为何标记 `smodel_type llm_decode` | 修复版本和兼容行为 |
| V44 | PDF 与 0.7.6 API 名称/返回类型差异 | 按版本维护的 API 文档 |
| V45 | PDF-only 地址重定位/分配接口在哪个版本 | 不存在则正式删除文档 |
| V46 | calbin 与 CalRT/driver/firmware/芯片兼容矩阵 | 机器可读规则 + 启动错误码 |
| V47 | metadata schema 是否有版本号和必填字段 | JSON/YAML schema + validator |
| V48 | 地址、size、workload、memory 字段单位 | 每字段定义,修正拼写和歧义 |
### 12.7 Reset、恢复和运维
| # | 问题 | 需要的答案 |
| --- | --- | --- |
| V49 | CCU exception 后 KV/DRAM 是否可信 | 最小恢复域 |
| V50 | ResetCCU/Configuration/Device 的影响范围 | 在途任务、其他芯粒/模型、driver 状态 |
| V51 | reset 前是否必须 drain/Release | 标准状态机和超时 |
| V52 | reset 后是否必须重新 configure/加载参数 | 可运行样例 |
| V53 | 连续故障的推荐 retry/backoff/隔离 | 错误码分类 |
| V54 | ClearDynamicMem/ClearAllDevMem 的使用约束 | 线程安全和数据破坏范围 |
### 12.8 cal-llm / EngineCore
| # | 问题 | 需要的答案 |
| --- | --- | --- |
| V55 | `origin/runtime_replace` 对应哪个正式 SDK/版本 | headers/library/package |
| V56 | EngineCore 是否取代 CalRT 还是上层封装 | 架构与支持周期 |
| V57 | 支持的 batch/KV/cancel/sampling/profile 能力 | API 合同和示例 |
| V58 | 是否兼容当前 calbin | 兼容矩阵和转换工具 |
| V59 | 当前生产迁移路径与回退 | 可运行镜像、A/B 和回滚 |
| V60 | API/ABI 稳定性和发布时间 | 书面版本策略 |
## 13. 厂商交付验收门槛
厂商答复只有同时包含“版本、可执行资产、最小示例、错误路径、golden 和兼容范围”才算关闭。口头声称“支持 batch/多模型/多卡”不能提升为 C0/C1。每项新能力应进入以下闭环:
```text
vendor claim -> versioned artifact -> isolated runner -> numerical golden
-> failure/recovery test -> service integration -> load/soak/perf
```
特别是多板、单芯粒双模型、expert parallel、动态多模型常驻和 NPU sampling,在取得新产物与实际测试前一律保持 C3;0.7.6 多物理设备保持 C4。