从 Qwen 在线服务的 SLA 与算力成本出发，系统化优化 Ascend Kernel
Ascend Kernel Forge 是一个面向推理框架端到端性能的 Agentic Kernel 优化控制面。
它从真实 Qwen 请求、Prefill/Decode 阶段、框架 callsite 和 shape 分布中发现机会，
再证明候选能否改善 xLLM、vLLM-Ascend、SGLang 的真实服务指标。
Qwen-first · CANN ≥ 9.0.0 · 3 Framework Arms · 10 Kernel Routes · 1 Evidence Chain
Kernel 决定局部执行效率，推理框架决定这份效率能否转化为 TTFT、TPOT、SLA 内 Goodput、HBM 容量和尾延迟的改善。AKF 的主线不是“写一个更快的算子”，而是从服务问题定位到可编辑 Kernel，再把局部收益穿过真实 binding、dispatch、graph、scheduler 和 serving 路径，最终形成有支持边界和回滚条件的发布结论。
在 LLM 推理中，同一个 Kernel 会被每层、每个 token 或每个 decode step 反复调用。只要它在真实流量中的加权占比足够高，局部的数据搬运、计算映射、尾块或下发成本就会累积成服务延迟、设备时间和并发容量问题。反过来，一个看起来很慢但调用占比很低的 Kernel，即使 microbenchmark 大幅加速，也可能几乎不改变端到端结果。
| 服务目标 | Kernel 层可能消耗价值的位置 | 必须在框架端证明的结果 |
|---|---|---|
| 缩短 Prefill 首 token 时间 | Cube/Vector 利用不足、MTE 搬运、融合边界、Host 下发 | TTFT 与 Prefill weighted latency 改善，精度和图模式无回归 |
| 降低 Decode 每 token 延迟 | 高频小 shape、tail、core/block 不均衡、launch/graph gap | TPOT、E2E p99 与连续 decode replay 改善 |
| 提高固定 SLA 下的吞吐 | Kernel 时间、scheduler/batching、通信或 Host gap 共同限制 | Goodput @ SLA、error rate 与稳定性满足阈值 |
| 扩大单卡/多卡承载能力 | 临时张量、workspace、KV 与 graph 内存相互挤占 | Peak HBM、KV capacity、max concurrency 不退化或改善 |
| 降低优化交付风险 | binary 未加载、dispatch 未命中、隐藏 fallback、支持域过宽 | 真实 hit proof、fresh-process 复验、fallback 与 rollback 边界完整 |
因此，AKF 把四个模糊问题变成机器可验证的问题：
- 数学语义真的没有改变吗？
- 正确的 binary 真的在真实 callsite 命中了吗？
- 局部收益真的进入模型和在线服务了吗？
- 结论的模型、SoC、CANN、shape、dtype、graph 和框架边界真的可复现吗？
| 普通单 Kernel 优化 | Ascend Kernel Forge |
|---|---|
| 从一个算子或固定 shape 出发 | 从 Qwen 服务 KPI、真实请求分布和 framework callsite 反推机会 |
| 默认问题一定在 Kernel | 先区分 Kernel、HBM/MTE、Host、Graph、Scheduler 与 Communication |
| 以 microbenchmark speedup 为主要成功标准 | 以 profiler-off 的 model replay 与 serving A/B 为最终成功标准 |
| 关注指令或 tiling 的局部变化 | 同时约束 ABI、binding、dispatch、stream、graph、fallback 与 HBM |
| 一份实现被视为适用于多个框架 | 候选源码可以复用，三套框架的运行事实不能复用 |
| 输出一个最优数字 | 输出 exact build identity、原始证据、支持包络、verdict 与 rollback |
同一份 Kernel 源码可以复用，端到端收益事实不能复用。
AKF 先冻结 Short Prefill、Long Prefill、Decode 与 Mixed Serving 的 tokens、并发、callsite、provider、shape、调用次数和权重，再判断研发预算是否真的应投入 Kernel。若热点在真实流量中的占比为 h，候选的板端局部加速为 s，其理想端到端加速上界为：
E2E speedup upper bound = 1 / ((1 - h) + h / s)
这个上界不是收益承诺。AKF 还会检查流量覆盖、A/A 噪声、集成成本、可编辑路径与支持域，并把问题分配到正确的任务类型，或直接终止：
kernel：active bound 确实在 Kernel 数据流或计算映射；integration：瓶颈来自 binding、dispatch、provider 或 fallback；configuration：瓶颈来自 runtime、graph 或资源策略；pipeline：瓶颈来自 scheduler、batching、communication 或 Host gap；no-go（终止结论，不是 Task 类型）：Amdahl 上界不足、范围不可安全限定或验证成本超过预算。
这一步的业务价值是尽早终止“局部能快、服务无感”的方向，把 Agent 搜索预算集中到可以改变端到端指标的机会。
GPU 项目可以提供搜索范式，但不能直接给出昇腾结论。AKF 在目标板上识别 active bound，再用一个最小、可证伪的假设修改数据流：
| Active bound | 主要观察 | 候选优化动作 | 必须回到板端验证 |
|---|---|---|---|
| Compute | Cube/Vector activity、instruction mix | Cube/Vector 分工、tile/block 映射、融合与流水 | Kernel latency、activity、utilization |
| Transfer | MTE traffic、UB/L1/L2/HBM、stall/overlap | tiling、数据复用、双缓冲、MTE 与计算重叠 | traffic、overlap、latency |
| Balance | core/block skew、alignment、tail cost | 核间均衡、尾块专化、对齐访问 | row p95、CV、tail cost |
| Launch/Graph | host gap、tiling host cost、recompile、replay miss | 下发减负、AOT、graph 兼容、stream 语义 | host gap、recompile、replay hit |
每轮只允许一条主假设，并依次经过 correctness → isfinite → hit proof → profiler-off board A/B。Profiler 只负责选择下一轮假设，不能提供发布数字；microbenchmark 通过也不等于 release。
候选可在多种路线中探索，但路线名不代表性能结论：
- 快速搜索：Triton、TileLang、CATLASS DSL；
- 更直接的性能控制：AscendC、CATLASS C++；
- 专家路径：PyPTO、PTO-ISA。
每条路线都保留独立的 SoC、CANN、toolchain、binary 与证据身份，不能混池比较或互相代证。
局部收益要依次穿过四层，任何一层都可能把 microbenchmark 收益吃掉：
Operator A/B：正确性、真实 dispatch、无隐藏 fallback 与稳定板端计时；Model Replay：精度 smoke、加权模型延迟、graph replay/recompile 与 peak HBM；Online Serving：TTFT、TPOT、Goodput @ SLA、E2E p99、error、KV capacity 与 max concurrency；Fresh Process：同一身份在新进程独立加载、重放并完成 cleanup。
常见的价值损耗包括 dispatch/graph tax、model integration tax、scheduler/batching tax 和 HBM/capacity trade-off。若候选局部有效但端到端收益不足，正确结论是 inventory，不是对外宣称优化成功。
最终交付是一份可审计的 Kernel Release Record，而不是一个 speedup 数字：
- 身份：Model、SoC、CANN exact build、backend、compiler、binding、deployment 与 binary digest；
- 三框架事实：每个 arm 独立保存 build、binding、loaded path、hit proof、model replay、serving A/B 与 verdict；
- 支持包络：明确已验证的 op、shape、dtype、layout、eager/graph 与 framework，其他范围安全 fallback；
- 发布安全：owner、license、rollback、cleanup 与 fresh-process reproduction；
- 机械结论：
promotable、inventory、rejected、blocked、incomplete或incomparable。
上图展示的是中性的发布合同：没有预选 PASS，也不代表示例 Campaign 已获得真实板端结论。
| Arm | 必须冻结的 runtime | 必须独立证明的事实 |
|---|---|---|
xllm |
xLLM binary、xllm_ops ABI、torch/torch_npu、CANN/ops、model 与 launch policy | C++ callsite、private OPP/overlay、loaded binary、graph、model/serving A/B |
vllm_ascend |
vLLM core 与 vLLM-Ascend plugin 双重身份、runtime 与 scheduler policy | custom op/PrivateUse1/Triton provider、compile/graph、engine 与 online serving |
sglang_ascend |
SGLang 与实际启用的 NPU kernel package、runtime 与 cache policy | torch.ops.npu/provider、NPUGraph、offline/server/online serving |
Suite 只在三类 lane 内比较：
per_framework_native_ab：同一 framework arm 内 native baseline 与 candidate 的 A/B；matched_policy：三框架使用相同请求、顺序、权重、SLA 和容量策略；framework_native_best：相同优化预算下比较各框架最佳合法系统方案，不把结果归因给单个 Kernel。
只有三个 required arms 在同一语义域分别通过，才能声明 portability。
AKF 不绑定单一 DSL，也不把不同 lowering/build 链路的证据混在一起。
| 路线族 | Backend identity |
|---|---|
| Native / Template | ascendc_direct、catlass_cpp |
| Python / DSL / IR | triton_ascend、tilelang_ascend_ascendc、tilelang_ascend_pto_headers、tilelang_ascend_npuir、catlass_dsl |
| PTO / Expert | pypto_tensor_ptoas、pypto_pro_cce、pto_isa_direct |
每个可执行组合都必须精确命中 (backend, SoC, CANN, op, shape, dtype, graph) capability tuple。未知组合失败关闭。CANN 正式版最低为 9.0.0，新 Campaign 默认精确锁定 9.1.0；pypto_pro_cce 仅允许声明支持的 950PR/950DT，A3 Campaign 必须拒绝。
完整路线边界见 Kernel Backend 目录。
要求 Python 3.11+。
python -m pip install -e .
python -m akf validate-suite suites/qwen3-8b-a3-bf16/suite.json
python -m akf validate-campaign suites/qwen3-8b-a3-bf16/arms/xllm.json
python -m unittest discover -s tests -v仓库提供 Qwen3-8B Dense + Ascend A3 + BF16 + TP1 的三框架 Suite。示例故意保持安全的 draft 状态，因此验证结果应是：结构合法、三个 arm 可识别，但在真实设备、框架 revision、模型 digest、capture、CANN build 和阈值冻结前不得创建 Run。
部署到真实环境后，只有 validator 返回 valid=true, ready=true 才允许执行：
python -m akf init-run path/to/ready-campaign.json --runs-root runs
python -m akf judge runs/<run-id> runs/<run-id>/attempts/<candidate-id>/gatesCLI 输出机器可读 JSON。失败使用非零退出码，并且不能留下部分 canonical artifact。
- AKF 是优化控制面，不是新的推理框架或 Kernel DSL；
- Agent 生成候选，但不能修改 baseline、oracle、workload、threshold、Gate、Decision 或 ledger；
- microbenchmark 不能直接产生端到端或跨框架结论；
- profiler-on 数据只用于诊断，发布指标来自 profiler-off 复验；
- 候选只能通过私有 OPP、隔离 overlay 或框架绑定部署，不能修改共享 CANN/OPP；
- simulator、CPU-SIM、cost model 和 GPU 参数可以帮助排序，不能证明昇腾板端性能；
promotable表示机器门禁满足，不等于自动合入或发布。
| 对象 | 作用 | 可信所有者 |
|---|---|---|
OptimizationSuite |
定义跨框架目标、required arms、比较 lane 与公共 workload | Supervisor |
Campaign |
冻结单个 framework arm 的环境、能力、基线与策略 | Supervisor |
Run |
保存 Campaign、Workload、Capture 的不可覆写快照 | Supervisor |
Task |
限定任务类型、ABI、支持域、预算和允许写路径 | Supervisor |
Candidate |
描述单一假设、数据流变化、源码与失败边界 | Supervisor 规范化 Agent 输出 |
Build |
绑定源码、后端、SoC、CANN、工具链与二进制摘要 | Trusted Builder |
Gate |
保存环境、算子、模型、服务、复验与发布证据 | Trusted Evaluator |
Decision |
校验父链并机械输出 verdict | Deterministic Judge |
ascend-kernel-forge/
├─ REQUIREMENTS.md 唯一规范性要求入口
├─ AGENTS.md 候选 Agent 操作合同
├─ assets/brand/ Logo
├─ assets/visuals/ README 与架构主视觉
├─ docs/ 架构、契约、后端、框架与治理
├─ schemas/ Draft 2020-12 机器契约
├─ src/akf/ 确定性控制面核心与 CLI
├─ suites/ 跨框架 OptimizationSuite 与各 framework arm Campaign
├─ adapters/ Framework 与工具适配边界
├─ knowledge/ 带适用包络的验证知识
└─ tests/ 身份、权限、判定与反投机测试
- 项目要求
- 实施路线与验收标准
- 系统架构
- 机器契约与证据模型
- 三框架 Adapter SPI
- Kernel Backend 目录
- Qwen3-8B Suite
- 安全、合规与发布治理
- Adapter 注册边界
- 知识生命周期
精确字段与关系仍保留在 docs/visuals/*.excalidraw 中，作为可编辑工程视图；README 使用 GPT Image 2 主视觉表达项目价值，并以 Markdown 文本作为权威技术说明。