English | 中文版

8. 下一步：路线图与展望

当前状态

ascend-rs 已经远超 alpha 阶段——就第 2–7、9、10、11 章已展示的内容而言。本路线图只列出尚未展示的部分;前面各章已经演示到位的条目都视为已交付,不再重复。

• 宿主机 API:alpha 完成。ACL、内存、stream、event、HCCL、DVPP、profiling、BLAS 都有安全 Rust 封装。
• ascend_compile crate:独立编译库,同时提供 Rust API、C ABI、CLI 与 Python 绑定——所有前端到 NPU 二进制的唯一路径。
• 设备端运行时:1565 个 Rust NPU 内核(489 个 compiletest + 16 个可部署),在昇腾 910B3 上 413 个 NPU 正确性测试通过,覆盖 MultiKernelBench 全部 17 个类别。
• PyPTO / PTO-MLIR 路径:已集成。发射器(mlir_to_pto) → ptoas 0.26 → AscendC → bisheng。DeepSeek-R1-Distill-Qwen-1.5B 的端到端 decode 在 910B2 上经此路径达到 114–187 tok/s(第 10 章)。
• PTO 安全卫士:已交付(第 11 章)。pto_to_rust 捕获 ptoas 本身以 rc=0 接受的 PlanMemoryPass 放置 bug。
• 与手调 AscendC 的性能对等:已在 softmax、激活函数、vec_add 以及 DeepSeek 四种 decode matmul 上达成(第 9、10 章)。

短期目标

真正尚未入库的短清单:

• Tiling 与双缓冲:基于队列(TQue)的流水线 API,用于重叠 DMA 与计算。PTO 路径已通过 PlanMemoryPass 隐式流水化;此目标是 ascend_std 缓冲 API 的对应版本。
• 迭代器组合子:设备端 Rust slice 上的 map、filter、fold、zip、enumerate——当前可用但下降效率不高。
• 调试信息生成:为 NPU 二进制发射 DWARF 节,让 ccec 级诊断能回链到 Rust 源。
• Qwen-7B / DeepSeek-V2-Lite 模型升级:1.5B-distill 做头条太单薄;7B 与 16B-MoE 才是可发表的故事(追踪于 project_deepseek_model_upgrade_plan)。

中期目标:生态集成

ascend_compile 的设计目标是成为每一个 AscendC C++ 生成器的唯一、经过验证的后端。PyPTO 已经接入;剩下这几条前端是中期工作:

• TileLang → ascend_compile:TileLang 当前通过裸 subprocess.run 调用 bisheng,没有任何校验。用 ascend_compile.compile_kernel() 替换 LibraryGenerator.compile_lib(),TileLang 就能获得 ascend-rs 自身 kernel 所用的同一套校验 pass(entry-point、DMA/sync barrier、buffer 与容量)。
• Triton → 昇腾:Triton 的昇腾后端可用 ascend_compile 处理最后一步 AscendC C++ → NPU 二进制,不必重复实现 ascend_compile 已有的目标 flag 与校验逻辑。
• PyTorch → 昇腾:torch.compile 的昇腾后端可通过 C ABI 链到 libascend_compile.so——不需要 Python 到 Rust 的依赖,用的是 TileLang 用的同一个 so。
• PTO 安全卫士 → 上游 ptoas:第 11 章列出的六条不变量目前是外部校验。把前四条(aliasing、capacity、op-constraint、matmul-bounds)折叠进 ptoas 自己的 VerifyAfterPlanMemoryPass,就能把它们升级为一等编译器保证,而不再是可选外挂。

长期愿景

昇腾目标规范 —— davinci-huawei-none:面向 Rust 编译器的 Tier-3 目标提案已经备好。三元组名沿用 nvptx64-nvidia-cuda / amdgcn-amd-amdhsa 传统,定义了 DaVinci 的 ABI、调用约定与指针大小。目标规范位于 upstream-tier3/compiler/rustc_target/src/spec/targets/davinci_huawei_none.rs,用 aarch64-unknown-none 作为 LLVM 占位(因为尚未有 DaVinci LLVM 后端),注册 cfg(target_arch = "davinci")。接入计划:(1) 在 Zulip #t-compiler/help 发帖获取三元组命名的早期反馈;(2) 若 MLIR codegen 后端需要 compiler 团队共识,提交 MCP;(3) 向 rust-lang/rust 提 draft PR。Tier-3 门槛最低——无 RFC、无 CI、单审批人即可通过。

减轻 no_core 负担:独自维护一套 core 重实现是重工程。方向是探索用 -Zbuild-std=core 搭配 MLIR 后端直接编译标准库源码,而不是手写重实现。

统一的昇腾编译栈:第 7 章展示了 ascend_compile 今天作为 IR 中枢的角色。长期图景要把前端、共享的 stage-2 plan 与安全卫士这三者的闭环补完——这样任何到达 NPU 二进制的路径,都会经过同一条已验证流水线和同一套编译期保证:

graph TD
    A1["Rust kernels<br/>（已交付）"] ==> F
    A5["PyPTO / PTO-MLIR<br/>mlir_to_pto → ptoas<br/>（已交付·第 7、10 章）"] ==> F
    A2["TileLang<br/>（规划中）"] -.-> F
    A3["Triton<br/>（规划中）"] -.-> F
    A4["torch.compile<br/>（规划中）"] -.-> F
    A6["未来 DSL"] -.-> F
    F["AscendC C++<br/>共用 IR"] ==> O["pto_to_rust 安全卫士<br/>（已交付·第 11 章）<br/>aliasing · capacity · op-constraint<br/>matmul-bounds · dead-tile · linear-use"]
    F ==> G["ascend_compile<br/>validate → target flags → bisheng"]
    O -.->|"定位到原始 .acl.pto"| A5
    O -.->|"上游候选<br/>VerifyAfterPlanMemoryPass"| U["ptoas（未来）"]
    G ==> H["NPU 二进制 · .o / .so"]
    H ==> D["DeepSeek 端到端<br/>910B2 上 114–187 tok/s<br/>（已交付·第 10 章）"]
    classDef shipped fill:#d4f5d4,stroke:#2b8a3e,stroke-width:2px
    classDef planned fill:#f5f5f5,stroke:#adb5bd,stroke-dasharray:3 3
    class A1,A5,F,G,O,H,D shipped
    class A2,A3,A4,A6,U planned

粗边表示已在代码树里跑起来的路径,虚边表示规划中的集成。此图把唯一的不对称点标了出来:当前卫士是外部观察 ptoas。从卫士指向 ptoas(未来) 的虚箭头代表上游整合——一旦卫士的前四项检查落到 PlanMemoryPass 内部,这一部分就会坍缩为一个节点。

社区参与

ascend-rs 当前仍在私有仓库,等待组织层面关于开源的决定。开源后,可以着手的贡献点有:

1. 为 ascend_std 增加新的向量 intrinsic:沿用既有模式——extern "C" stub + mlir_to_cpp handler。
2. 补充 compiletest:ascend_std 每增加一个特性,都应有对应的编译测试。
3. 扩充宿主机 API 封装:CANN 尚有大量未封装的 API,每个都可独立贡献。
4. 写更复杂的 Rust 内核:帮助发现代码生成后端的空白,并在 NPU 硬件上验证新 intrinsic。
5. 把 ascend_compile 接入你的工具:如果你做 TileLang、Triton 或其他针对昇腾的内核编译器,试着把编译步骤替换为 ascend_compile 并反馈问题。
6. 扩展 PTO 安全卫士:pto_to_rust 只有约 600 行。新增检查(例如循环感知的 liveness,把 [linear-use] 从 warning 提升为 error;为 910C / 310P3 增加 per-SoC 的 DeviceSpec 条目)都是自成一体的 PR。