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

20 KiB
Raw Blame History

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. 路径别名

下文用以下别名缩短路径:

$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

文件行号以当前本地归档为准。二进制动态符号的复核命令为:

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:1llama-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-960encoder :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:15tokenizer_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=falsehas_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 size151936*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 示例存在 CreateParser0.7.6 是 CreateCalbin $PDFTXT:225$SDK/include/calrt/calrt_calbin.h:27;有动态符号 E2/E3/C0
I02 GetAllModels PDF 返回 vectorSDK 返回 pointer $PDFTXT:230,475calrt_calbin.h :37 E2/E3/C0
I03 PDF GetModelInfoSDK GetModelByName $PDFTXT:474calrt_calbin.h :36 E2/E3/C0
I04 PDF infer 返回 voidSDK 返回错误码 $PDFTXT:441calrt_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。每项新能力应进入以下闭环:

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。