本文浅析了谷歌 TPU 与国内 AI 加速器厂商在 Linux 上的内核驱动与内存（HBM）管理机制，以及它们为何普遍不采用 DRM 框架的原因。

目录

1. 背景：AI 加速器的物理内存

AI 加速器芯片普遍具有多层物理存储结构，与 GPU 类似：

存储层级 介质 作用 典型容量
主存 板载 HBM（片外 DRAM） 存放模型参数、激活值、中间结果 数十 GB 级
片上高速缓冲 SRAM / VMEM / CMEM 暂存矩阵单元（MXU）计算数据 MB 级

以谷歌 TPU 为例：TPU v4 每芯片约 32GB HBM，v5e/v5p 容量更大；片内还有向量内存（VMEM）和矩阵乘法单元缓冲区。

因此讨论"HBM 管理"，本质是讨论 片外物理 DRAM 的分配、地址映射与主机-设备数据搬运 由哪一层软件负责。

2. 谷歌 TPU 的驱动与 HBM 管理

2.1 Cloud TPU（数据中心，v2/v3/v4/v5）

  • 内核驱动：私有 gasket + apex 框架，非标准 DRM。
    • Gasket（Google ASIC Software, Kernel Extensions and Tools）：通用内核框架，为 PCIe 挂载的 ASIC 提供字符设备、DMA、中断、BAR 映射等基础设施；曾出现在 drivers/staging/gasket/。
    • Apex：构建在 Gasket 之上的具体 TPU 设备驱动。
  • HBM 管理主要在用户态：由 libtpu（配合 XLA / TensorFlow / JAX runtime）完成。
    • 内核驱动只负责：暴露设备、DMA 映射、命令队列提交。
    • HBM 地址空间划分、buffer 分配、调度：由 XLA 编译器 + runtime 决定，通过 DMA 搬入/搬出 HBM。

2.2 边缘 TPU（Coral / Edge TPU）

  • 使用同一套 Gasket + Apex（gasket.ko + apex.ko）。
  • 用户态通过 libedgetpu 访问。

2.3 与 GPU 内存管理路径的对比

维度 AMD / NVIDIA GPU 谷歌 TPU
内核子系统 DRM / TTM / GEM Gasket（非 DRM）
显存 / HBM 管理 内核 TTM buffer manager 主要在用户态（libtpu / XLA）
内存迁移 DRM / HMM / migrate_vma 由 runtime 显式 DMA

简述：Cloud TPU 的 HBM 通过谷歌私有的 gasket/apex 内核驱动暴露设备并做 DMA，而 HBM 的实际分配与管理主要由用户态的 libtpu/XLA runtime 负责，不走 Linux 标准的 DRM/TTM 显存管理路径。

3. 国内 AI 加速器厂商驱动栈全景

国内厂商绝大多数走 自研私有内核驱动 + 私有用户态 runtime，风格接近 NVIDIA CUDA 闭源栈或谷歌 Gasket 模式。

3.1 华为昇腾（Ascend，NPU / 达芬奇架构）

  • 内核驱动：私有模块，如 davinci、devmm（device memory management）、hdc、dpc；设备节点 /dev/davinciX、/dev/devmm_svm。
  • HBM 管理：设备内存由内核驱动 + 用户态 runtime 管理；支持 SVM（统一虚拟内存），devmm 负责 host/device 地址空间映射（思路类似 HMM，但自研）。
  • 用户态：CANN 栈（ACL / Runtime / GE / AICPU），分配接口如 aclrtMalloc。
  • 是否 DRM：否。

3.2 寒武纪（Cambricon，MLU）

  • 内核驱动：私有 cambricon_drv.ko；设备节点 /dev/cambricon_devX、/dev/cambricon_ipcm。
  • 内存管理：自研设备内存分配器，用户态通过 CNRT / CNDrv（cnrtMalloc）分配，支持 host-device 统一地址。
  • 用户态：Neuware（CNToolkit / CNRT / CNNL / CNCL）。
  • 是否 DRM：否。

3.3 燧原科技 Enflame（GCU，最接近"TPU"定位）

  • 内核驱动：私有 enflame / gcu 内核模块。
  • 用户态：TopsRider 栈（TopsRuntime，对接 TensorFlow / PyTorch / XLA）。
  • 特点：采用 XLA 后端，软件路径与谷歌 TPU 最相似；HBM 管理在用户态 runtime + 内核 DMA。

3.4 百度昆仑芯（Kunlun / XPU）

  • 内核驱动：私有 kunlun / xpu。
  • 用户态：XRE（Kunlun Runtime Environment）、XDNN；接口如 xpu_malloc。
  • 是否 DRM：否。

3.5 壁仞 Biren / 天数智芯 Iluvatar / 沐曦 MetaX / 摩尔线程（GPGPU 类，“类 CUDA”）

  • 壁仞：私有内核驱动 + BIRENSUPA 软件栈（对标 CUDA）。
  • 天数智芯：私有驱动 + 类 CUDA 的 Corex / IXUCA。
  • 沐曦 MetaX：私有内核驱动（metax/maca 模块） + MACA / MXMACA 软件栈，主打 CUDA 兼容与迁移（编译器 mxcc，算子库 mcBLAS/mcDNN/mcFFT 对应 cuBLAS/cuDNN/cuFFT）；拥有曦云 MXC（训练/通用计算）、曦思 MXN（推理）、曦彩 MXG（图形）三条产品线。计算主通道为私有栈（类 NVIDIA nvidia.ko 模式）。
  • 摩尔线程：mtgpu 驱动基于 DRM 框架（需同时做图形 + 计算），显存走 TTM/GEM，用户态 MUSA 对标 CUDA。

3.6 海光 DCU（Hygon）

  • 特殊：源自 AMD 授权，软件栈基于 ROCm 分支（DTK）；内核驱动是 amdgpu/amdkfd 的定制版本，走 DRM + KFD 路径。
  • 与（rocr-runtime / amdgpu SVM）技术栈直接同源。

3.7 汇总对比表

厂商 内核驱动 是否走 DRM 用户态栈 HBM / 显存管理
华为昇腾 私有 davinci/devmm 否 CANN 自研 SVM
寒武纪 cambricon_drv 否 Neuware / CNRT 自研分配器
燧原 enflame / gcu 否 TopsRider (XLA) runtime + DMA
昆仑芯 kunlun / xpu 否 XRE / XDNN 自研
壁仞 私有 否 BIRENSUPA 自研
海光 DCU amdgpu/kfd 定制 是（DRM+KFD） DTK / ROCm TTM + HMM/SVM

核心规律：

  • 纯 AI 加速器（昇腾、寒武纪、燧原、昆仑）→ 私有字符设备驱动 + 私有 runtime，HBM 管理在内核私有模块 + 用户态，不用 DRM/TTM。
  • 图形 GPU 或源自 AMD 的（摩尔线程、海光）→ 走 DRM，其中海光与 amdgpu SVM / rocr-runtime 是同一套 KFD + HMM 内存迁移机制。

4. 为什么自研厂商普遍不用 DRM

本质上是 技术需求 + 工程成本 + 商业策略 的三方权衡。

4.1 DRM 是为"图形显示"设计的，AI 加速器不需要

DRM（Direct Rendering Manager）的抽象体系围绕 GPU 图形渲染建立：

  • KMS（显示模式设置）、framebuffer、CRTC、连接器、EDID、vblank、显示 fence 同步……
  • GEM/TTM 中大量概念（scanout buffer、tiling、显示扫描）对纯计算芯片无意义。

纯 AI NPU/TPU 没有显示输出，用不上 DRM 约 90% 的功能。为了剩余 10% 的 buffer 管理背负整个 DRM 框架，不划算。

4.2 DRM/TTM 太重、太复杂

  • TTM 的内存迁移、驱逐、多域（VRAM/GTT/system）管理，是为"显存有限、要和 CPU 抢内存、支持图形负载"设计的，逻辑极其复杂。
  • AI 芯片内存模型更简单：HBM 是一大块线性地址空间，runtime 自己做 bump / buddy 分配器即可，不需要 TTM 的驱逐搬迁机制。
  • 一个数百行的字符设备驱动（ioctl + mmap + DMA）即可满足需求，远比接入 TTM 简单。

4.3 上游 DRM 有严格的社区规则和维护负担

  • 必须开源用户态栈：DRM maintainer 明确不接受只有闭源用户态的 DRM 驱动。
  • 代码风格、UAPI 稳定性、review 流程严格，周期以年计。
  • 一旦进主线，UAPI 需永久向后兼容，束缚硬件快速迭代。

对追求快速出货、且不愿开源核心 runtime/编译器的厂商，这不可接受，故选择 out-of-tree 私有字符设备驱动。

4.4 商业机密与生态锁定

  • AI 芯片核心竞争力在编译器 + runtime + 内存调度策略；走 DRM 意味着暴露内存管理 UAPI 细节。
  • 私有栈可将 driver / runtime / compiler 打包为闭源 SDK（CANN、Neuware、TopsRider…），形成对标 CUDA 的生态壁垒。

4.5 参考对象是 CUDA，不是 Mesa

  • NVIDIA 计算栈本身不走 DRM（nvidia.ko 是私有字符设备驱动，只有 nouveau 才是 DRM）。
  • 国内厂商照抄这套成熟商业模式：私有内核模块 + /dev/xxx 字符设备 + 闭源 runtime。

5. 走 DRM 路线的例外：海光与摩尔线程

厂商 采用 DRM 的原因
海光 DCU 源自 AMD 授权，直接继承 amdgpu + KFD 代码，改比重写省事
摩尔线程 做真正的图形 GPU，需要显示输出 / 渲染，DRM/KMS 是刚需

这两家要么"被迫继承"，要么"确实需要图形"，才走 DRM 路线。

6. 各路线与各厂商的优劣分析

6.1 两条路线的优劣

路线 A：私有字符设备驱动 + 闭源 runtime

代表：昇腾 / 寒武纪 / 燧原 / 昆仑 / NVIDIA / 谷歌 TPU

优势

  • 迭代快：UAPI 自定，硬件换代不受上游兼容性约束，改内存模型/指令集不用管社区。
  • 实现轻：不背 DRM/TTM 的图形包袱，几百行字符设备（ioctl + mmap + DMA）即可跑通。
  • 护城河：driver + runtime + compiler 打包成闭源 SDK，形成 CUDA 式生态锁定，保护核心 IP。
  • 内存模型简单可控：HBM 当线性空间自己做分配器，调度策略完全自定义。

劣势

  • 生态碎片化：每家一套 API（CANN / Neuware / TopsRider…），互不兼容，用户迁移成本高。
  • 无法进主线：永远是 out-of-tree 模块，随内核升级易 break，需厂商持续适配。
  • 黑盒难调试：闭源，出问题依赖厂商，社区帮不上忙。
  • 重复造轮子：内存管理、DMA、IOMMU 等基础设施每家各写一遍，质量参差。
  • 安全审计难：闭源内核模块是攻击面，云厂商/客户难以信任。
路线 B：DRM + TTM/GEM

代表：摩尔线程 / 海光 / AMD / Intel

优势

  • 复用成熟基础设施：TTM 内存驱逐、GEM buffer 共享、dma-buf、fence 同步、IOMMU 集成全都现成。
  • 能进上游：驱动进 mainline 后随内核长期维护，发行版开箱即用。
  • 图形 + 计算统一：一套栈同时支持渲染和 compute（摩尔线程刚需）。
  • 标准互操作：dma-buf / PRIME 让跨设备零拷贝共享、与显示子系统协作变简单。

劣势

  • 必须开源用户态：社区硬性要求，核心 runtime/compiler 难以闭源，商业机密受限。
  • 框架重、门槛高：TTM 复杂度高，接入和 debug 成本大，对纯 AI 芯片是"过度设计"。
  • UAPI 永久兼容：进主线后接口要长期向后兼容，束缚硬件激进创新。
  • review 周期长：合入以年计，不利于快速出货。

6.2 具体厂商的优劣

厂商 优势 劣势
谷歌 TPU XLA 编译器成熟、软硬协同极致、规模化部署 完全私有、只能在谷歌云用、无对外生态
华为昇腾 国产最完整栈(CANN)、支持 SVM、生态投入大 API 学习曲线陡、闭源、迁移成本高
寒武纪 起步早、Neuware 相对完整 生态小、市占低、闭源黑盒
燧原 走 XLA/OpenXLA，路径通用、易接标准框架 体量小、软件成熟度待验证
昆仑芯 背靠百度内部大规模场景验证 对外生态弱、XPU 编程模型小众
壁仞 / 天数 类 CUDA、迁移门槛相对低 供应链风险、驱动闭源
沐曦 MetaX CUDA 兼容激进、迁移门槛低、训练+推理+图形全产品线 驱动/runtime 闭源、生态追赶中、供应链风险
摩尔线程 唯一 DRM 图形 + 计算通吃、MUSA 对标 CUDA 计算性能与生态仍追赶中、DRM 包袱
海光 DCU 直接复用 ROCm/amdgpu，生态最省力、SVM/HMM 现成 依赖 AMD 授权、架构受制于 AMD 迭代节奏

6.3 小结

纯 AI 芯片选私有栈，是用"生态封闭"换"迭代自由与商业护城河"；选 DRM，是用"必须开源、框架沉重"换"上游维护与标准互操作"。

对国产而言：昇腾 代表自成体系的封闭强栈路线；海光 代表复用 AMD 开源栈的省力路线——后者恰好与本仓库的 amdgpu SVM / rocr-runtime 同源，SVM/HMM 内存迁移几乎零成本继承。

7. 后续有没有可能统一

统一的可能性是有的，但会分层次、分阵营地进行，而不会全球收敛到单一栈。

7.1 内核驱动层：正缓慢向"统一基础设施"靠拢

Linux 社区正在把"计算加速器"从 DRM 里抽象出来：

  • drivers/accel/ 子系统（Accelerator subsystem，2022 年进主线）：专为不做图形的 AI/计算加速器设立，复用部分 DRM 基础设施（GEM、drm_device、dma-buf、fence）但剥离图形/KMS 部分。已有 Habana（Intel Gaudi）、Intel VPU（ivpu）、AMD amdxdna（Ryzen AI NPU）等接入。
  • 这恰好解决了第 4 章的"DRM 太重、图形包袱"痛点：accel 给纯 AI 芯片一个"轻量版 DRM"的上游归宿。

潜在统一点：未来国产厂商若想进主线、被发行版开箱支持，drivers/accel/ 是最现实的路径；但目前国产厂商基本仍在 out-of-tree，动力不足。

7.2 DRM 自身的模块化：drm_gpuvm / drm_gpusvm / drm_pagemap

需要特别指出：“DRM = 图形专用重框架”的印象已经过时。近两年 DRM 正在长出一批跨驱动共享的通用内存/地址空间管理中间层，把过去各家私有的逻辑收敛成公共组件：

  • drm_gpuvm（GPU 虚拟地址空间管理器）：前身为 drm_gpuva_mgr（2023 年进主线）。把“GPU VA 空间 + BO 映射区间（drm_gpuva）”的通用管理逻辑（区间树、split/merge、VM_BIND 语义）抽出。采用者：Nouveau（首个）、Xe、Panthor、PowerVR 等，正成为新驱动的标配。
  • drm_gpusvm（GPU 共享虚拟内存）：2024 年随 Xe 引入，目标就是做跨驱动可复用的 SVM 基础设施。基于 HMM 的 system allocator——CPU 与 GPU 共享同一虚拟地址空间。
  • drm_pagemap：配合 drm_gpusvm，管理 device-private 的 ZONE_DEVICE 内存、用 migrate_vma 做页面迁移，把过去 amdgpu svm_range、Nouveau 等各自实现的 SVM 迁移逻辑收敛成公共层。

这意味着 DRM 正从“图形专用重框架”演化为“模块化、可按需取用的 GPU 基础设施库”：

能力 老做法（各驱动私有） 新的 DRM 公共层
GPU 地址空间 / VM_BIND 各写 VA 管理 drm_gpuvm
SVM / 统一内存迁移 amdgpu svm_range、nouveau 各写 drm_gpusvm + drm_pagemap
BO 内存管理 — TTM（已有）

对两条路线的影响：走 DRM 的厂商（AMD、Intel Xe、海光）能直接复用这套 SVM 基础设施；而走私有栈的纯 AI 厂商（昇腾等）依然在自研 SVM，享受不到这层红利——这反而拉大了两条路线在“统一虚拟内存能力”上的差距。

7.3 用户态编程层：更可能通过"编译器 IR + 框架后端"实现事实统一

内核难统一，但用户态正在被上层"抹平"：

统一层 机制 现状
框架后端 PyTorch 的 PrivateUse1 / torch.compile、OpenXLA/StableHLO 各家写后端即可接入，用户不感知底层
编译器 IR MLIR / OpenXLA / Triton 燧原、部分国产已走 XLA/MLIR
中间接口 SYCL / oneAPI、OpenAI Triton 试图做"跨厂商 CUDA 替代"

趋势：绝大多数厂商都在做 PyTorch 后端 + XLA/MLIR 接入。用户写 PyTorch，不再关心是昇腾还是海光——这就是"事实统一"，但底层驱动/runtime 仍各自私有。

7.4 为什么"完全统一"很难

  • 商业护城河：CUDA 的成功恰恰在于不统一（锁定）。厂商没有动力交出 runtime/编译器控制权。
  • 地缘/供应链：国产阵营（昇腾、海光…）与 NVIDIA/CUDA 阵营被动脱钩，反而会形成两套甚至多套并行标准。
  • 硬件架构差异大：NPU（脉动阵列）、GPGPU（SIMT）、达芬奇（Cube）指令模型差异根本，底层 UAPI 难以真正统一。
  • UAPI 永久兼容成本：进主线后接口冻结，厂商顾虑迭代自由（第 4.3 节提过）。

7.5 最可能的结局：分层收敛，而非单点统一

用户态框架层     →  高度统一（PyTorch / OpenXLA 抹平差异） ★最可能
      ↑
编译器 IR 层     →  部分统一（MLIR / StableHLO 成公约数）
      ↑
Runtime/驱动层   →  阵营内可能统一，全球难统一
      ↑
内核子系统       →  drivers/accel + drm_gpuvm/drm_gpusvm/drm_pagemap
                     提供"可选统一底座"，走 DRM 的厂商可直接复用

7.6 小结

"统一"在上层（PyTorch/OpenXLA 框架后端）和内核层（DRM 公共基础设施）同时推进，底层 runtime 则分阵营并存。一方面 PyTorch/OpenXLA 在上层抹平差异；另一方面内核层 drivers/accel/ 与 drm_gpuvm/drm_gpusvm/drm_pagemap 正把 VM 与 SVM 能力做成跨驱动公共组件。但由于商业锁定、地缘脱钩和架构差异，最现实的未来仍是"上层框架 + 内核基础设施事实统一、厂商 runtime 分阵营并存"——类似今天 CPU 世界有统一的 C/POSIX，但各家微架构各不相同。

对国产阵营而言，海光走 ROCm/DRM 已经天然贴近上游统一底座（能直接受益于 drm_gpusvm/drm_pagemap 等新基础设施），而昇腾等封闭栈既享受不到内核 SVM 公共层，又更依赖"PyTorch 后端"这条上层统一路径。

8. 总结

DRM 是为图形 GPU 设计的重型框架。纯 AI 加速器既不需要显示功能，又想保护闭源 runtime 并快速迭代，因此选择轻量的私有字符设备驱动 + 闭源用户态栈——这条路更简单、更自由、也更符合对标 CUDA 的商业策略。

  • 只有"需要图形输出"或"继承自 AMD/Intel 现有 DRM 代码"的厂商，才会选择 DRM。
  • 谷歌 TPU 用私有 gasket/apex，HBM 管理放在用户态 libtpu/XLA。
  • 国内纯 AI 加速器（昇腾、寒武纪、燧原、昆仑）均为私有驱动 + 私有 runtime。
  • 海光 DCU 是唯一与本仓库 amdgpu SVM / rocr-runtime 技术同源的方案（DRM + KFD + HMM/SVM 内存迁移）。

注：各厂商驱动源码大部分未开源，模块名与实现细节以厂商官方发布为准，本文基于公开资料整理。

# 人工智能
Logo
鲲鹏昇腾开发者社区是面向全社会开放的“联接全球计算开发者，聚合华为+生态”的社区，内容涵盖鲲鹏、昇腾资源，帮助开发者快速获取所需的知识、经验、软件、工具、算力，支撑开发者易学、好用、成功，成为核心开发者。

鲲鹏昇腾开发者社区是面向全社会开放的“联接全球计算开发者，聚合华为+生态”的社区，内容涵盖鲲鹏、昇腾资源，帮助开发者快速获取所需的知识、经验、软件、工具、算力，支撑开发者易学、好用、成功，成为核心开发者。

更多推荐

cover

AI芯片混战：OpenAI用AMD、DeepSeek用昇腾、英伟达5000亿锁HBM——谁在挑战芯片王座？

avatar 鲲鹏昇腾开发者社区
cover

Day0开源发布：CANN解锁Kimi K3昇腾NPU部署实践

avatar 鲲鹏昇腾开发者社区

2026 大语言模型推理应用开发框架盘点推荐：国产昇腾 MindIE LLM 成国产化落地核心选择

推理应用开发的核心载体，内置完整大模型推理 SDK，集成深度定制模型库、推理优化器、运行时调度环境，开发者通过 Python/C++ API 即可快速封装对话、生成、工具调用等推理业务逻辑，原生支持 MoE、MLA、Multi-LoRA、函数调用等当前主流大模型能力。除此之外，本地轻量化推理开发还有 llama.cpp、Ollama、MLX 等工具，主打单机离线、端侧小型模型调试，高并发云端推理应

avatar 鲲鹏昇腾开发者社区