# Calculet NPU 总体研究报告

日期：2026-08-02  
当前生产源码：`fd9bd632f346085920d523dd307a3e4c11cc0a05`  
CalRT：0.7.6  
镜像：`calculet-llama:v0.4.8-release`  
当前模型：Qwen3-30B-A3B，双芯粒，40960 context

实施说明：本文用于建立全貌。需要直接拆研发任务时，下钻到《异步执行器与生产稳定性实施规格》《性能压测故障注入与验收规范》《新模型适配工程 Runbook》《逐算子优化实验手册》和《Batch、KV 与多模型调度实现规格》；这些文档包含类/方法、数据 schema、实验矩阵、故障注入和验收阈值。

## 1. 结论先行

当前产品不是 GGML 逐算子调度到 NPU 的通用 backend，而是一个“llama.cpp 服务层 + CalRT 预编译整图”的系统：llama.cpp 负责 tokenizer、请求/slot 调度和 CPU sampling；CalRT 加载预编译 calbin，按 prefill/decode 执行完整 Transformer 图。

当前系统的真实能力边界是：

| 维度 | 当前状态 | 结论 |
| --- | --- | --- |
| 物理设备 | 1 个 PCIe VirtualDevice | 0.7.6 头文件明确写“temporary only support one physical device” |
| 板内计算 | 2 个芯粒，MCHIP | 当前模型已经双芯粒运行 |
| 并行方式 | 逐层张量并行 | 两芯粒都执行 48 层；不是 pipeline parallel，也不是 expert parallel |
| 模型 | 1 套完整 Qwen3-30B-A3B | 68 个文件是同一模型的分片、命令、ELF、元数据和 tokenizer，不是 68 个模型 |
| 硬件 batch | 1 | `max_batch_size=1`，无法形成硬件 continuous batching |
| 子模型 | prefill、decode | 两者不能在一次提交中混跑 |
| 上下文 | calbin 40960 | tokenizer 配置中的 131072 不是当前 NPU 可用上限 |
| 调用方式 | `infer()` 后立即 `Wait()` | Runtime 非阻塞和 ping/pong 能力没有转化为并发 |
| 采样 | CPU | 每 token 回传 151936 个 BF16 logits，再转 FP32 采样 |
| 多卡 | 未支持 | 不能把“多芯粒”表述为“多板多卡” |
| 新模型编译 | 当前材料不能独立完成 | 缺 calcc、ONNX pass、kernel/codegen、oplib 和 calbin 打包工具 |

性能优化优先级不是先写更多单算子，而是：

1. 补齐分层指标和正确基准口径。
2. 修复 KV 无限忙等、错误恢复和 manifest 校验。
3. 让 Runtime 的异步、ping/pong 和 buffer 复用真正进入服务路径。
4. 由厂商重新编译 batch 4/8/16 decode calbin，建立 continuous batching。
5. 优化长上下文 Attention/KV 带宽，以及 MoE grouped GEMM/dispatch。
6. 最后再评估 expert parallel、多模型常驻和 NPU 侧 sampling。

## 2. 证据口径与状态定义

本文综合了 Runtime PDF、0.7.6 SDK 头文件、非 strip 动态库符号、生产源码、完整 Git 历史、OCI image history、构建缓存、完整模型产物、首轮实测和历史性能 CSV。

为避免把“接口存在”误写为“产品可用”，全文采用以下状态：

| 状态 | 含义 |
| --- | --- |
| C0 当前已确认 | 当前生产代码、产物或实测直接证明 |
| C1 SDK 存在但未接入 | 0.7.6 头文件和动态符号存在，当前 llama 路径没有使用或未验证 |
| C2 可工程实现 | 基于现有 Runtime/服务能力可以开发，但当前尚不存在 |
| C3 依赖厂商工具链 | 需要重新编译模型、开发 kernel、修改 Runtime 或获得私有工具 |
| C4 当前不支持/不应开放 | 版本或架构明确不支持，或接口只适合受控运维面 |

## 3. 构建与供应链边界

OCI history 完整记录了镜像构建过程：

1. 基础镜像是 Ubuntu 22.04 amd64。
2. 安装 GCC/G++ 11、CMake、Git、ELF、调试工具和 Miniconda。
3. 从 `/home/user1/CalCulet/calrt/hostrt` 以 Release/shared 方式编译、安装 Runtime。
4. 安装完成后执行 `rm -rf calrt/`，因此最终镜像不保留 HostRT 源码。
5. 构建 SystemC、fmt、yaml-cpp 等依赖。
6. 使用以下核心配置编译 llama.cpp：

```text
cmake -B build \
  -DLLAMA_BUILD_COMMON=ON \
  -DLLAMA_USE_CALRT=ON \
  -DLLAMA_CURL=OFF \
  -DCALRT_INSTALL_DIR=/usr/local/
cmake --build build -j
```

构建缓存进一步确认：

- `CMAKE_BUILD_TYPE=Release`，`-O3 -DNDEBUG`。
- `LLAMA_USE_CALRT=ON`。
- `GGML_CALRT=OFF`。
- 最终链接 `/usr/local/lib/libcalrt-linux-x86_64.so.0.7.6` 和 `libelf`。
- 当前 Git HEAD 与 `origin/dev` 都是 `fd9bd632...`。

由此得到三条边界：

- 我们能修改 llama.cpp 服务/适配层并重新构建。
- 我们能调用和封装 CalRT 0.7.6 的公开头文件/动态符号。
- 我们不能仅凭现有材料重建 calcc 图优化、NPU kernel/codegen 或生成一个新 calbin。

模型 YAML 记录的编译器版本是 `calcc 575c2d708e306a60f10bc34f5087477073b58caa`、TVM `7aebd1c21fa67d942a1fd93e39e8a67007f91c0c`；原 ONNX 只留下路径和 SHA-256，文件本身未归档。

## 4. 当前端到端执行链

```mermaid
sequenceDiagram
    participant Client as OpenAI API Client
    participant Server as llama-server
    participant Llama as llama.cpp Scheduler
    participant CalRT as CalRT 0.7.6
    participant NPU as 2-chiplet NPU
    Client->>Server: chat/completions
    Server->>Llama: tokenize + select slot
    Llama->>Llama: split request by sequence
    Llama->>CalRT: select prefill/decode model
    Llama->>CalRT: set current/past sequence CSR
    Llama->>CalRT: MapBuf + SliceTensor
    CalRT->>NPU: H2D + submit whole graph
    NPU-->>CalRT: logits + updated KV
    CalRT-->>Llama: D2H + Wait completion
    Llama->>Llama: BF16 to FP32 + CPU sampling
    Llama-->>Server: next token
    Server-->>Client: stream/non-stream response
```

生产源码中的具体行为：

1. `VirtualDevice::CreateVDevice(PCIE)` 创建设备。
2. 从固定寄存器读取 CalcoreRT commit，并读取 `calrt_version()`。
3. `Calbin::CreateCalbin(path)` 解析模型并 `configure()`。
4. 根据第一个 sequence 的 `n_tokens > 1` 选 prefill，否则选 decode。
5. 子模型通过名称子串查找，而不是严格 manifest。
6. 每次 `calrt_infer()` 都创建 InputBuf/OutputBuf 对象，但映射到长期 vector backing store。
7. 写入 `past_kv_cur_seq_len[0]` 和 `cur_seq_len[0]`。
8. prefill 对 token/position 和末行 logits 做 slice。
9. 对 sequence 数组逐个执行 `infer()`、立即 `Wait()`。
10. 将 BF16 logits 转成 FP32，并交还 llama.cpp CPU sampling。

这里最关键的判断是：`infer()` 本身是非阻塞提交，但当前代码紧接 `Wait()`，所以应用层表现仍是同步串行。

## 5. Qwen3-30B-A3B 结构与计算图

| 参数 | 值 |
| --- | ---: |
| 层数 | 48 |
| hidden size | 2048 |
| Q heads | 32 |
| KV heads | 4 |
| head dim | 128 |
| experts | 128 |
| 每 token 激活 experts | 8 |
| expert intermediate | 768 |
| dense intermediate 配置值 | 6144 |
| vocab | 151936 |
| RoPE theta | 1,000,000 |
| calbin context | 40960 |
| batch | 1 |
| 量化 | W8A8/W4AF16 混合 |
| Flash Attention | 已开启 |

产物中的算子计数：

| 算子 | Prefill | Decode | 说明 |
| --- | ---: | ---: | --- |
| fused RMSNorm | 193 | 193 | 每层 attention/FFN 多处及尾部 |
| quantized fused matmul/add | 193 | 193 | QKV、O、router、lm_head 等 |
| sync CPU/CCU D2D | 146 | 146 | 芯粒/执行单元同步与数据交接 |
| gather tensor | 145 | 145 | 分片结果合并 |
| grouped MoE dense | 144 | 144 | 每层 gate/up/down 三组 |
| KV scatter | 96 | 96 | 每层 K/V |
| fused RoPE | 96 | 96 | 每层 Q/K |
| add/relu/residual | 96 | 96 | attention/FFN residual |
| dynamic D2D | 96 | 0 | prefill 动态跨芯粒移动 |
| SiLU/multiply/reduce | 各 48 | 各 48 | 每层 MoE |
| gate pre/post | 各 48 | 各 48 | top-k、dispatch 与恢复 |
| Flash Attention | 48 | 48 | 每层 attention |
| embedding | 1 | 1 | 只在 chip0 profile 中执行 |
| layout conversion | 2 | 0 | prefill mat/hw pattern 转换 |
| 总节点 | 1496 | 1398 | YAML 顶层 op 数 |

Decode MoE 权重 shape 的第一维是 128，且 chip0/chip1 的 profile 都包含相同的 144 个 `nbu_moe_dense_group`。这说明两边都有 128 experts 的权重分片；当前是矩阵维度张量并行，不是把 experts 分组放到不同芯粒。

## 6. 双芯粒分配与通信

四个 `.profparts` 文件显示：

- decode：chip0 1254 行，chip1 1253 行。
- prefill：chip0 1352 行，chip1 1351 行。
- 唯一稳定的一行差异是 embedding 只在 chip0。
- 两芯粒都执行全部 48 层的 attention、MoE、norm、residual 和 output path。
- Q、K/V、投影矩阵、MoE 权重与 vocab 输出按编译器布局分片，然后 gather/reduce。
- 每颗芯粒承担 2 个 KV heads，合计 4 个。

这属于 tensor parallel：每层都有跨芯粒同步，优势是每层计算并行，代价是每层通信。它不具备 pipeline parallel 的阶段隔离，也没有 expert parallel 的按专家路由。

最大 prefill 静态命令描述：

| 芯粒 | `data_moving` 条目 | 描述字节 | 主要块大小 |
| --- | ---: | ---: | --- |
| chip0 | 444,610 | 18.979 GiB | 245760 x 64 KiB；122880 x 32 KiB；75968 x 1 KiB |
| chip1 | 444,608 | 18.822 GiB | 245760 x 64 KiB；122880 x 32 KiB；75968 x 1 KiB |

注意：prefill 配置为 `dynamic_d2d=true`，且 `libcpu_x86.so` 导出 `Process`。因此这些数字是 40960 上限图的静态命令描述，不是短 prompt 的实测传输量。必须通过 Runtime trace 或 PCIe/D2D counter 测量实际长度相关流量。

## 7. 内存基线

| 项目 | 总量 | 每芯粒/分片 | 口径 |
| --- | ---: | ---: | --- |
| 参数文件 | 16.938 GiB | chip0 8.759 GiB；chip1 8.179 GiB 文件大小 | 两个 `param_blk*.bin` |
| 参数映射到 DRAM | 16.910 GiB | 8.745 / 8.165 GiB | memory reservation 逐段求和 |
| 参数映射到 SRAM 窗口 | 28.762 MiB | 各 14.381 MiB | memory reservation 逐段求和 |
| BF16 KV | 3.750 GiB | 1.875 GiB | 48 x 4 heads x K/V x 128 x 40960 x 2 bytes |
| DRAM reservation | 推断 28.150 GiB/双芯粒 | 14.075 GiB | 同一虚拟地址计划按芯片 mask 应用 |
| SRAM reservation | 推断 33.688 MiB/双芯粒 | 16.844 MiB | 接近每芯粒 18 MiB 物理 SRAM |
| decode tensor 地址并集 | 10.634 GiB | 每芯粒地址计划 | 含常量、KV、I/O 和 workspace；非峰值活跃内存 |
| prefill tensor 地址并集 | 14.091 GiB | 每芯粒地址计划 | 与 DRAM+SRAM reservation 基本闭合 |
| 单 token logits | 303,872 B BF16 | Host D2H | 151936 x 2 bytes |

参数、KV、workspace 的区间存在别名和生命周期复用，不能把各角色的地址覆盖量直接相加。完整映射见《模型产物与内存映射》。

`device_memory_required: 16777216 MB` 明显存在单位/字段问题；按字面是 16,777,216 MiB，不可能成立。它更像 16 GiB 的 KiB 数值被错误标成 MB，需要厂商确认解析口径。

## 8. Runtime 已有能力与当前使用差距

### C0 当前已使用

- PCIe VirtualDevice 创建与状态检查。
- calbin 解析、configure、按名称获取子模型。
- Input/Output buffer、tensor MapBuf、slice。
- CSR 动态序列长度。
- `infer()`、`Wait()`、H2D/D2H/infer 计时。
- KV Apply/Free/RemoveTokensAtEnd/Clear 的部分路径。
- 双芯粒 MCHIP 整图执行。

### C1 SDK 有但生产未利用

- `EnableParallelMode(bool)`。
- `SubmitJob()` 和 `infer_with_fixed_task_type()` 的 ping/pong 控制。
- OutputBuf pending/running/done/CCU exception 状态。
- pending/finished/left job counters。
- trace 和配置 metadata dump。
- golden input/output 读取。
- KV `canAllocate`、显式 Allocate、DoShift、batch layout、S8 V-cache。
- per-chip memory/register 访问。
- C API 的 block/non-block inference 封装。

### C4 当前限制

- VirtualDevice 内部只有一个 `shared_ptr<CalrtDevice>`，不是多物理设备管理器。
- 当前 calbin batch=1、只有 prefill/decode。
- `RelocateTensorAddress()`、`AllocDevMem()` 只出现在 PDF，0.7.6 头文件与动态符号都不存在。
- 任意寄存器、设备地址、reset、ClearAllDevMem 不应暴露到普通推理 API。

## 9. 当前集成的工程问题

### P0 正确性与稳定性

1. KV 申请使用无限 `do/while(!Apply())`，没有超时、退避、取消和资源耗尽错误。
2. KV 更新失败直接 `abort()`；初始化失败使用 `GGML_ABORT`。
3. KV adapter 的 `seq_cp`、`seq_keep`、`seq_add`、`seq_div`、state save/load 基本为空。
4. `seq_rm` 只支持尾部删除，common-prefix 与任意区间删除不成立。
5. 子模型通过名称包含匹配，重复名称时最后一个命中覆盖前一个。
6. CSR setter、`infer()` 和 `OutputBuf::Wait()` 都返回错误码，但当前直接调用没有检查，提交、执行或 D2H 失败可能继续使用无效状态/输出。
7. calbin prefill 的 `smodel_type` 错标为 `llm_decode`。
8. tokenizer 的 `model_max_length=131072` 与模型/calbin 40960 冲突。
9. `server.cpp` 只在成员定义处保护 `cal_ctx`，部分指标读取在 `#ifdef` 外，非 CalRT 构建存在编译风险。

### P0 吞吐

1. `max_batch_size=1`。
2. sequence 逐个循环，`infer()` 后立即 `Wait()`。
3. 所有 slot 共享一套 prefill/decode backing vector，不能直接多 in-flight。
4. prefill/decode 不能混合提交。

### P1 延迟与 CPU 开销

1. 每次调用重建 InputBuf/OutputBuf，并重复查 tensor/CSR。
2. Decode 全 vocab BF16 logits 回传后，先构造完整 FP32 临时 vector 再复制。
3. output untile 硬编码 `D0=16` 和 shape 分支。
4. MapBuf 使用普通 vector，尚未证明是 pinned/registered host memory。
5. 固定寄存器读取版本不具备芯片/固件兼容抽象。

## 10. 性能证据与正确口径

首轮当前版本实测：

- 27 token prefill：184.27 token/s。
- 246 token decode：58.25 token/s。
- 请求端到端：4.41 s。

历史 CSV 有 163 条数据，但有两个口径问题：

- `model=deepseek` 是 `client_new.py` 第 183 行的硬编码字符串，不能证明真实模型。
- CSV 的 `TTFT` 实际是 `predicted_ms + prompt_ms`，是完整生成时长，不是真正首 token 延迟。

仍然可信的趋势是：

| 上下文示例 | Decode TPS | 观察 |
| --- | ---: | --- |
| 短上下文，2026-06/08 | 58-64 | 当前短请求基线 |
| 约 2K | 38-46 | KV 长度增加后明显下降 |
| 约 4K | 28-40 | 4K 附近继续退化 |
| 约 8K-16K | 20-30 为主 | 不同版本混合，不能直接横比 |
| 约 33K | 12 左右 | 长上下文已明显带宽受限 |
| 约 40K | 10-16 | 接近上限时最慢 |

这与 GQA decode 的理论特征一致：每个新 token 需要读取不断增长的 KV，Attention/KV 带宽是长上下文的第一瓶颈。MoE 权重读取则是所有 decode 长度都存在的主成本。

后续必须将指标定义为：

- TTFT：请求进入到第一个可见 token。
- TPOT：首 token 后每个输出 token 的间隔。
- ITL：逐 token inter-token latency 分布。
- E2E：请求进入到结束。
- Goodput：满足 SLO 的完成 token/s，而不是只看设备 TPS。

## 11. 优化路线

### 阶段 0：建立可信基线

- 修复 TTFT 统计和 model 标签。
- 暴露 infer/H2D/D2H/framework、KV 等待、队列等待和 sampling 时间。
- 每次运行记录 llama commit、CalRT/驱动/固件、calcc/TVM、calbin hash。
- 固定 prompt/output/tokenizer/采样参数，保留原始逐 token 时间。

### 阶段 1：稳定性和低风险收益

- KV 申请加入超时、退避、取消和 429/503。
- 严格 model manifest，启动时检查 I/O、dtype、layout、batch、context、chip topology。
- 建立 InputBuf/OutputBuf pool 和 handle cache。
- 复用 BF16->FP32 缓冲，或直接转换到目标 logits 区。
- interrupt/polling、普通/pinned host memory、单/双 buffer 做 A/B。

### 阶段 2：异步流水

- 每个 in-flight 请求独立 backing storage。
- 使用 OutputBuf 状态和 Wait，将 submit 与 completion 分离。
- 使用 ping/pong job，并测试 `EnableParallelMode`。
- 将 CPU sampling 与下一请求/下一阶段 NPU 工作重叠。
- prefill、decode 建立独立队列和优先级。

### 阶段 3：真正批处理

- 由厂商生成 batch 4/8/16 decode calbin。
- 完成 batch KV layout、slot-to-hardware-batch 映射和压实。
- continuous batching 每 step 填充活跃 sequence。
- 验证 fairness、取消、EOS、资源回收和长短请求隔离。

### 阶段 4：算子与图优化

- 长上下文 GQA Flash Attention、KV layout、S8 V-cache。
- router + top-k + dispatch 融合。
- 8 active experts 的 decode 专用 grouped GEMM。
- RMSNorm+QKV、Q/K norm+RoPE、O-proj+residual、FFN+residual 融合。
- NPU top-k 或 sampling，减少 303,872 B/token 的 logits 往返和 CPU 串行。

### 阶段 5：拓扑演进

- 单芯粒小模型/embedding，另一芯粒大模型或 reranker。
- 双芯粒 tensor parallel 大模型。
- expert parallel 的实验性新 calbin。
- 多模型常驻、动态装卸和显式内存预算。
- 多物理板卡需要 Runtime 新版本或进程级设备隔离，0.7.6 不能直接实现。

## 12. 下一轮实验矩阵

### 12.1 基础长度矩阵

- prompt：1、16、128、512、2048、4096、8192、16384、32768、40900。
- output：1、32、128、512。
- 重复：预热 3 次，正式至少 20 次；报告 P50/P95/P99。
- 指标：TTFT、TPOT、E2E、infer、H2D、D2H、framework、sampling、KV wait、CPU、DRAM。

### 12.2 当前 batch=1 下的并发行为

- 客户端并发：1、2、4、8、16。
- 分别测试全短、全长、10% 长+90% 短。
- 只声明队列吞吐和排队延迟，不宣称硬件 batch。
- 验证取消后 KV 是否释放，资源耗尽是否有界返回。

### 12.3 Runtime A/B

- interrupt vs `poll_mode=1`。
- 默认 submit vs `EnableParallelMode(true)`。
- 自动 task vs 固定 ping/pong。
- 普通 vector vs pinned/registered buffer。
- 当前对象创建 vs buffer pool。
- 全 logits vs NPU top-k 原型。

### 12.4 稳定性

- 30 分钟、2 小时、24 小时。
- context 逼近 40960。
- 客户端断开、请求取消、模型服务重启。
- 非法 calbin、超长 prompt、KV 耗尽、CCU exception。
- 设备 reset 后恢复只在独占维护窗口执行。

## 13. 决策建议

1. 近期主线应是“稳定性 + 可观测 + 异步流水”，不要先投入多板抽象。
2. 吞吐目标若高于单请求 58-64 token/s，batch decode calbin 是必要条件。
3. 长上下文性能目标必须单独立项，不能用短上下文 TPS 代表。
4. 新模型适配应先让厂商交付可复现的 compiler container 和一套 dense 模型示例，再做 MoE。
5. `origin/runtime_replace` 的 cal-llm EngineCore 方向值得吸收，但它是厂商演进分支，不是当前生产能力；应先拿到匹配的 `c_api.h`、`libcal_llm.so`、兼容矩阵和测试结果。
6. 对外接口应分为推理面、只读观测面和受控运维面；寄存器/任意内存/reset 不进入普通服务 API。

## 14. 研究后的可执行起点

后续项目研究建议从三个并行工作包进入：

- 工作包 A：在当前 commit 上修复 KV busy wait、非 CalRT 条件编译、buffer pool 和分层 metrics。
- 工作包 B：建立标准性能 harness，重测当前 calbin 的长度/并发/Runtime A/B 矩阵。
- 工作包 C：向厂商索取 compiler toolchain、batch calbin、cal-llm SDK 和接口问题答复，启动一个小型 dense 新模型适配试点。

未经新实验或厂商确认，不应将 C1/C2/C3 能力写入产品规格。