2025 年 5 月，清华大学的一处舞台上，两名嘉宾从牌匾上揭下红绸，高校、模型公司与芯片厂商的代表在他们身后排成长列。新成立的“计图”产学研联盟汇集了 AI 供应链上下游的首批 24 家理事单位，其中包括华为、腾讯、智谱 AI、京东与摩尔线程。[6] 这类典礼常常更像一场机构活动，技术色彩较淡。此时，这张集体照却格外准确地定格了问题。
中国要形成持久的替代性 AI 栈，制造出加速器或发布开放权重模型只是起点。两者之间的软件还要把模型运算转化为硬件任务，管理内存与通信，对外提供可用的服务，并在模型与加速器两端持续变化时维持运行。Jittor（计图）是清华大学计算机图形学研究组开发的深度学习框架；它的启发性在于，团队为掌握这一中间层探索了多条路线。[1][2][5]
两项工作对应的是彼此相关、互有区别的技术命题。2025 年的 Jittor-on-CANN 移植检验编译器与计算图抽象能否在更换加速器时维持上层模型代码稳定。JittorInfer 采用另一条路线：这个 C++ 服务运行时明确吸收了 llama.cpp、ggml 与 torchair 的代码和思路，再接入华为 CANN 图引擎与昇腾专用实现。合在一起看，两者分别检验框架层可移植性与加速器原生服务能力。若把它们归入一条直接延续的代码谱系，第二条路线所展现的大量工程工作便会被抹去。[2][4][5]
最初的技术押注落在模型层之下
Jittor 的设计早于当前这轮大模型竞赛。2020 年的论文将其描述为一个完全采用即时编译的深度学习系统，核心是 元算子（meta-operators）：一小组类似 NumPy 的基础操作，可以组合并编译成针对 CPU 或 GPU 特化的代码。统一计算图执行器负责管理这些操作，同时应用算子融合、跨迭代融合与统一内存管理等技术。[1]
这套设计重新安排了可移植性工作的落点。大量依赖手写后端专用 kernel 的系统，每引入一种新加速器，都会累积出一长串移植任务。以编译器为中心的做法，从原理上可以把更多适配工作移入算子生成、计算图到后端表示的转换，以及数量有限的硬件接口之中。“从原理上”这层限定很重要：新后端依然需要编译器、程序库、内存语义、数值校验，以及针对高开销操作编写并调优的代码。抽象为这些硬件工作标出了明确位置，工作本身依旧存在。
这种编译器优先的设计，也让项目的可移植性命题超出单一加速器。放在中国 AI 技术栈中观察，真正有用的信号超出了“又一个框架”的范畴：这是一次持续多年的尝试，目标是让编译器与计算图层成为跨异构算力的杠杆点。[1]
昇腾移植说明抽象在哪些地方成立
2025 年 1 月，Jittor 团队记录了 Jittor 与华为 CANN 8.0 栈在昇腾 910 系列处理器上的集成。在示例开头，用户可见的迁移动作小得近乎滑稽：把 use_cuda=1 替换为 use_acl=1。团队报告称，现有 Jittor 程序随后便能从 Nvidia 转到昇腾，上层模型代码保持不变。[2]
这行开关下方的工作量很大。发布说明列出了 CANN 接口集成、FlashAttention 实现、模型训练与推理检查，以及算子层数值对比。当时公开列明的 JittorLLMs 大模型支持范围包括 LLaMA 7B、ChatGLM 与 ChatRWKV；图像和多模态示例又将这条路线扩展到 ResNet、ViT、Stable Diffusion 与 CLIP。团队还开放了 Jtorch，用于把大量 PyTorch 风格的模型代码导向 Jittor 后端。[2]
这里需要守住第一条界线。单行开关呈现的是预期的用户体验；PyTorch 工作负载能否原样迁移，仍取决于已经实现并经过测试的算子、shape、dtype、模型架构与分布式模式。即使编译器降低了每个新模型的支持成本，可移植性仍需在每个模型上逐一实现并验证。
JittorInfer 另走一条运行时路线
团队对 DeepSeek 的适配，让专用运行时的必要性变得具体。2025 年 4 月，团队报告已在昇腾上完成对参数量 160 亿的 DeepSeek-V2-Lite、2360 亿的 DeepSeek-V2，以及 6710 亿的 DeepSeek-R1 的支持。相关说明逐项列出了实际工作，没有把它们藏在兼容性标签后面：融合与非融合的混合专家算子、扩展旋转位置编码、多头潜在注意力中的矩阵吸收、INT4 权重量化、张量并行与专家并行，以及连续批处理调整。[3]
8 月发布 JittorInfer v0.1.0 时，它已经是一套独立于原有 Jittor Python/JIT 栈的服务软件。这个采用 MIT 许可证的仓库提供独立 C++ 运行时，README 注明其思路与代码借鉴自 llama.cpp、ggml 和 torchair。公开使用方式依赖华为 CANN 工具包，采用 CANN 图引擎，并提供带 OpenAI 兼容 API 的 llama-server。v0.1.0 发布版本及其 benchmark 材料以 DeepSeek-V2-Lite 和 DeepSeek-V2 为中心。[4][5]
最能说明问题的优化，大多位于矩阵乘法之外。JittorInfer 把一串细粒度操作合并成一张可重复下发的计算图，减少 CPU 反复唤醒 NPU 的次数。它把 token 采样移到加速器上，避免每一步解码都将完整 logits 向量传回 CPU。HTTP 任务队列用定向通知替换广播唤醒；追踪已占用 KV-cache 块时，则以 bitset 替换平衡树。[4]
这套抽象有别于 2020 年的 Jittor，却进一步凸显了同一个供应链问题。规格表上的峰值算力只是起点；调度、数据搬运、缓存状态管理、批处理与对外服务环节持续让加速器空转时，这些算力无法转化为生产能力。JittorInfer 把主机 CPU、NPU、运行时与 HTTP 服务视作一条完整的延迟链路。
Benchmark 提供线索，结论仍待验证
性能数字显示出潜力，评估范围也受到严格限定。Jittor 在 8 月的发布说明中报告了昇腾 910 系列硬件上的测试：DeepSeek-V2-Lite 使用单卡，DeepSeek-V2 使用一台八卡服务器。仓库按并发数 1、2、4、8 比较吞吐量，基线为 vLLM-Ascend v0.7.3；在单卡表格中还加入了 v0.9.1。报告中的增幅在不同负载与并发水平下差异明显。[4][5]
这些结果由项目方发布，尚缺独立评估。v0.1.0 仓库在主表之外披露了一些有用的环境信息：鲲鹏 920 主机、昇腾 910B3 加速器、CANN 8.2 RC1 alpha，以及 -O2 编译。吞吐量脚本采用 15 秒预热，prompt 长度为 5 个 token，解码输出为 110–120 个 token。不过，表格没有标注指标名称或单位。脚本还写死了模型与 benchmark 工具的私有路径，也没有给出条件匹配的 vLLM 命令或配置。因此，表格与脚本之间的对应关系、基线配置细节，以及基线与 JittorInfer 在数值精度和量化设置上是否对等，仍缺少完整说明。[4][5]
现有材料只支持方向性解读：团队已经开放代码，并发布了一组值得复现的对比结果。端到端复现流程仍未给出，这组结果也不能证明 JittorInfer 在任意模型、卡型、序列长度或生产流量下都更快。
这一界线格外重要，因为对比对象仍在变化。vLLM-Ascend、CANN、MindSpore 与模型架构都会继续演进。绑定单一运行时版本的百分比领先缺少持久保证；一套可以长期维护、持续剖析性能并重新调优全栈的方法更为持久。
供应链检验落在覆盖广度上
截至 2026 年 7 月 12 日，JittorInfer 的 README 与版本元数据仍突出展示 v0.1.0 和以 DeepSeek 为中心的 benchmark。默认分支的覆盖范围已经超过这些公开材料：2026 年 6 月 10 日的一次合并，加入了 Qwen3 稠密模型、Qwen3 混合专家模型与 Llama 2 的计算图生成器和配置路径，DeepSeek 也保留在内。这些代码确实说明覆盖面正在扩大；要成为有文档、有 benchmark 的生产支持承诺，还需更多证据。[5]
三项信号可以表明这种扩展正走向基础设施。第一，新模型路线应当进入明确的测试支持矩阵，列出架构、dtype、量化、上下文长度与硬件覆盖。第二，每一张已发布的 benchmark 表都应配有外部人员能够复跑的命令，并包含条件匹配的基线。第三，正式发布版本与用户文档应跟上默认分支，同时在 CANN 和模型升级过程中维持 OpenAI 兼容服务约定不变。
封面照片中的联盟恰好可以协助完成这些不显眼的工作。成员横跨框架研究、模型、硬件、云服务与工业用户。[6] 如果这些参与方贡献需求、测试资源、算子内核、错误报告与部署证据，Jittor 就能把联盟成员的广度转化为软件覆盖面。若联盟只保留仪式活动，运行时也继续局限于少数模型，这种转化便无法发生。
证伪条件很清楚：如果团队的两条昇腾路线无法把新模型代码转化为有文档、经测试的支持和可复现结果，那么 Jittor 这一名称所涵盖的将是一组定向适配，供应链层的定位也无法成立。反过来看，若框架层计算图抽象与独立服务运行时继续降低每次新适配的成本，这个项目就会提供一项具有战略价值的能力：让中国的模型与加速器生态在此汇合，同时正视硬件独立性不会随芯片自动到来。
来源
- Shi-Min Hu、Dun Liang、Guo-Ye Yang、Guo-Wei Yang 与 Wen-Yang Zhou，《Jittor: a novel deep learning framework with meta-operators and unified graph execution》，Science China Information Sciences 63（2020）——介绍框架架构、JIT 编译、元算子、计算图执行、融合与内存设计。
- Jittor / 清华大学计算机图形学研究组，《计图适配华为昇腾 910 系列，迈向国产 AI 生态》（2025 年 1 月 6 日）——介绍 CANN 8.0 集成、迁移开关、模型覆盖、FlashAttention、验证与 Jtorch。
- Jittor / 清华大学计算机图形学研究组，《计图团队完成 DeepSeek 模型在华为昇腾上的高效适配》（2025 年 4 月 17 日）——介绍模型规模、MoE 与 MLA 工作、量化、并行、连续批处理及团队最初报告的结果。
- Jittor / 清华大学计算机图形学研究组，《基于昇腾的大模型推理框架 JittorInfer 重大升级并开源》（2025 年 8 月 8 日）——介绍计算图下发、NPU 端采样、队列与 KV-cache 调整、评估范围及路线图。
- Jittor 官方 JittorInfer 仓库。资料包括 v0.1.0 代码与 README（独立 C++ 架构、依赖项、致谢、服务端路径与 benchmark 表格）、v0.1.0 吞吐量脚本与v0.1.0 环境说明。另见2026 年 6 月 10 日加入 Qwen3、Qwen3-MoE 与 Llama 2 路线的合并记录。
- Jittor / 清华大学计算机图形学研究组，《“计图”产学研联盟在清华大学成立》（2025 年 5 月 30 日）——介绍联盟成员、设立目标，以及本文封面所用真实揭牌照片的来源页面。