企业官网建设流程全解析

多租户NPU隔离这件事，表面上是“给每个租户分几张卡”，真正难的是“同一张卡上怎么让多个容器互不干扰”。我去年在推进AI算力池化时，一台8卡NPU服务器上几十个租户排队等着用卡，每租户独占整卡，成本高得吓人，很多小模型的推理任务根本用不满。可一旦把多个租户塞到一张卡上，首先就得回答：怎么保证他们不互相偷数据、不互相干扰？单纯靠驱动在软件层做内存分区，我是不敢用在生产环境里的。真正能兜底的是PASID、IOMMU加上硬件强制隔离这条完整链路。这篇文章按照我一步步踩坑的顺序，把多租户NPU隔离从原理到配置再到排障完整过一遍，希望能帮到正在做AI基础设施的同学。

1. 多租户NPU场景与隔离需求拆解

1.1 为什么一定要把NPU切给多个租户

第一个驱动因素就是钱。AI加速器的单卡价格从几万到几十万不等，如果每个租户独占一张卡，很多任务根本用不满算力。比如一个典型的BERT推理服务，单张卡的利用率往往只有30%到50%，剩下的大半资源就这么闲置着。第二个因素来自负载特征：训练任务倾向于长期占满整卡，推理任务则是明显的弹性负载，白天高峰夜晚低谷。两者混部在同一个物理设备上，可以大幅提高设备利用率，摊薄单位算力成本。

我所在的平台早期做法是“一人一卡”，简单粗暴但浪费严重。后来业务方提出要按“CUDA/TOPS”粒度申请资源，而不是按整卡申请，我们才开始认真考虑设备级的多租户共享。这个转变不只是资源管理的改变，更关键的是对隔离能力的要求一下从“可选项”变成了“安全底线”。如果租户A的推理循环里出了内存越界，把租户B的权重读走了，这在合规上就是安全事故，没有任何借口。

1.2 隔离到底要隔离什么

多租户NPU隔离不是单一维度的概念，拆开来看至少有四个维度需要同时满足。

数据隔离是最基本的。模型的权重、梯度和中间激活值、用户输入原始数据，这些字节绝对不能跨租户泄露。传统推理服务里，一个batch的输入会停留在显存/NPU内存里，如果两个租户共用同一块内存区间，代码漏洞就可能让A的输入被B的future请求读取，这在金融、医疗等场景是无法接受的。

执行隔离也很重要。一个租户的kernel如果访问了非法地址，设备端会触发异常或DMA错误，如果不做隔离，这个错误可能直接让整张卡进入异常状态，把其他租户的推理任务全部打断。性能隔离则是在共享资源的前提下，防止某一个租户把算力、内存带宽、PCIe带宽全部打满，把整体延迟拖垮。最后还有安全隔离，这就要从对抗视角理解了：即使NPU的驱动固件被攻击者控制，设备发出的任何一个DMA请求都必须经过IOMMU，无法绕过硬件检查直接读取系统内存。

1.3 只靠软件隔离为什么不够

很多厂商的驱动最初只提供软件层的内存分区。驱动在设备固件侧维护一张“内存映射表”，每个租户被分配一段设备内存区间。但问题在于，这张表是软件维护的——一旦驱动有逻辑漏洞，或者被攻击者利用内核模块漏洞篡改了表项，整个隔离体系就形同虚设。更现实的风险是，驱动代码的复杂度越来越高，现代AI加速器的驱动和固件攻击面巨大，我见过不止一次因为某些驱动的越界写导致数据错乱的事故。

IOVA映射（传统DMA映射）比纯设备内存分区好一点，至少每个DMA请求都要经过设备驱动的映射登记。但它仍然假设“每次操作都被正确映射”——如果驱动自身的逻辑错了，IOVA映射也会跟着错。真正可靠的做法，是把隔离从软件层下沉到硬件层：让设备发出的每个DMA请求都携带“身份标识”，由硬件（IOMMU）拿着这个身份标识去查页表、验证权限。身份对不上，直接拒绝。这条思路就是PASID加IOMMU的出发点，也是“硬件强制隔离”的核心。

2. PASID：让NPU认得出每个租户

2.1 PASID是什么：从PCIe视角理解

PASID全称是Process Address Space ID，进程地址空间标识符。它是PCIe规范定义的一项能力。理解PASID最好的方式，是把PCIe设备发出的DMA请求想象成一份快递包裹，包裹上需要写清楚“发件人是谁”。传统的PCIe设备只有一个身份——BDF（Bus/Device/Function，即设备在PCIe总线上的编号），所以设备能表达的只有“我是这个人”，无法区分“这个人的哪个进程在发请求”。PASID解决了这个问题：在DMA请求的TLP（事务层报文）里额外添加一个字段，标明这个请求属于哪个进程地址空间。PASID通常是20位二进制数，理论上可以支撑一百万以上的上下文。

打个比方，传统的DMA相当于“公司前台统一寄件”，前台就一个人，所有包裹都写前台的名字。PASID相当于给公司每个员工发了专属工号，包裹上写清楚是谁寄的，快递中心才能按工号分发到对应的收件人。对于NPU多租户场景，PASID就是那个工号：每个租户进程拥有自己的PASID，NPU的DMA请求一出门就带着它。

从硬件实现上看，并非所有PCIe设备都支持PASID。设备需要通过PCIe capability结构声明它支持PASID功能，包括支持的最大PASID位数。运行lspci -vvv如果能看到PasID Cap，说明该设备具备此能力。我们实际用过的几款NPU里，有的支持10位PASID（1024个上下文），有的支持完整20位。这个差异直接决定了单卡能支撑的最大租户数。

2.2 PASID在共享虚拟内存中扮演的角色

PASID最核心的应用场景是SVM（Shared Virtual Memory），共享虚拟内存。传统模式下，设备驱动要把用户态内存通过DMA映射成IOVA（I/O虚拟地址），设备访问的是这个IOVA，用户进程访问的是进程虚拟地址，两边隔着一层“翻译”。SVM模式则激进得多：让设备直接使用进程的虚拟地址。进程在CPU侧用0x7f1234560000访问一个tensor，NPU也直接用0x7f1234560000去读取这块数据，不再需要显式的dma_map步骤。

问题随之而来：多个进程都可能有相同的虚拟地址。进程A的0x7f1234560000和进程B的0x7f1234560000，物理上完全可能是两码事。如果没有PASID，设备发一个地址0x7f1234560000的DMA请求，IOMMU根本不知道这个地址该对应哪个进程的页表。有了PASID就不一样了：设备发出的DMA请求携带PASID，IOMMU拿着PASID去索引“PASID表”，从表里取出对应进程的页表基地址，再做地址翻译。每个PASID对应一套独立的地址空间，互不串门。

从驱动开发者的角度看，启用SVM之后，用户态代码申请的内存天然可以被设备访问，程序逻辑简单了很多。但从系统可靠性角度看，SVM也带来了新的挑战：CPU和IOMMU必须共享同一份页表，内核要处理mmu_notifier通知设备侧缓存失效。如果某个进程的内存被munmap或swap出去，设备侧的地址翻译必须同步更新，否则就等于拿着过期的地图找路，极易翻车。

2.3 PASID分配与生命周期管理

PASID的分配策略可以简单分为两类：一类是每个进程地址空间一个PASID，典型的是Linux内核SVA（Shared Virtual Address）框架；另一类是每个设备上下文一个PASID，常见于某些厂商自己的加速器栈。前者适合通用计算负载，后者更适合对设备资源有精细控制的场景。

我实测过的一个场景：某厂商NPU的驱动把每个队列对（Queue Pair）当作一个独立上下文，每个队列对一个PASID。一张卡上最多支持64个队列对，那理论上最多可以同时跑64个租户上下文。但要注意，这里的“理论”还要受到固件资源、内存容量和PCIe带宽的约束。实际部署时，我们给每租户至少预留1个队列对作为控制通道，高峰时最多也就跑了40多个租户，已经接近固件的调度极限了。

PASID的生命周期管理是个容易忽略的坑。创建上下文时分配PASID，上下文销毁时必须释放PASID。听起来简单，但我见过某个早期版本驱动存在PASID泄漏，长时间运行后可用PASID耗尽，新租户无法创建上下文，一台好好的NPU服务器被迫重启。所以生产环境一定得给PASID的分配数量加上监控，一旦逼近上限就要报警。

3. IOMMU：设备DMA的质检员

3.1 IOMMU不只做地址翻译

IOMMU（I/O Memory Management Unit）在系统中的角色，可以理解为设备DMA请求的质检员。任何来自PCIe设备的DMA请求，都要过IOMMU这一关：地址翻译，把设备发出的地址翻译成真正的物理地址；权限检查，确认这个设备、这个PASID是否有权限访问目标内存；中断重映射，防止设备伪造MSI中断干扰其他设备或CPU。

地址翻译是IOMMU最基础的功能。一个设备通过BDF找到它所在的“上下文”，上下文里定义了该设备能使用的地址空间。如果设备发出一个DMA请求，但目标地址不在它的地址空间页表里，或者读权限不匹配，IOMMU就直接拒绝并上报一个DMA页错误。这就是硬件强制隔离的第一道防线：即使设备固件和驱动已经不安全了，设备上的任何代码也无法绕过IOMMU去触碰不属于自己的内存。

中断重映射同样关键。现代设备使用MSI中断来通知CPU，MSI中断本质上是一个内存写操作，写入某个特定地址来触发中断。如果攻击者控制的设备伪造MSI中断，理论上可以向任意CPU注入虚假中断，甚至造成拒绝服务。IOMMU的中断重映射机制可以验证每个中断请求的来源和合法性，把不属于这台设备的中断过滤掉。在多租户虚拟化场景里，这个机制尤其重要，不然租户的设备可以干扰宿主机的其他虚拟机。

3.2 一级翻译与二级翻译：为虚拟机租户打开大门

IOMMU地址翻译有两种基本形式。一级翻译只需要把设备发出的“设备虚拟地址”（IOVA或进程虚拟地址）翻成“系统物理地址”，适用于无虚拟化的直接共享场景。二级翻译（也叫嵌套翻译）则多做一层：先由虚拟机内部完成“客户机虚拟地址到客户机物理地址”的翻译，再由外层IOMMU完成“客户机物理地址到宿主机物理地址”的翻译。

为什么需要两级翻译？因为在使用KVM直通场景时，每个虚拟机是一个租户，虚拟机内部有自己的物理地址空间概念GPA（Guest Physical Address）。两个VM内部都可能有GPA 0x1000，但对应的宿主机物理地址完全不同。没有第二级翻译，IOMMU就不知道GPA 0x1000该落地到宿主机哪块内存。两级翻译正是解决“多个VM各自认为自己拥有物理内存”的办法。

二级翻译的实现原理是在IOMMU页表里同时维护两级结构：一级是VM的客户机页表（由VM内部管理），二级是宿主机维护的嵌套页表（类似于CPU侧EPT/NPT）。当一个NPU要访问VM内进程的虚拟地址时，IOMMU先查一级页表把客户机虚拟地址翻成客户机物理地址，再查二级页表把客户机物理地址翻成宿主机物理地址，最终完成访问。这个流程增加了每次地址翻译的页表遍历成本，但换来了虚拟机场景下的硬件强制隔离，值不值看场景。

3.3 缓存与性能：ATC和TLB消耗

IOMMU的性能优化是整个方案能否落地的重要一环。如果每次DMA都让IOMMU完整遍历页表，延迟会很难看。为此PCIe规范定义了ATS（Address Translation Service），允许设备主动请求IOMMU完成地址翻译并把结果缓存到设备内部的ATC（Address Translation Cache）中，后续DMA请求可以直接命中缓存，减少IOMMU查询压力。

ATC带来了性能提升，却引入了缓存一致性问题：CPU侧如果修改了页表，比如撤销某段内存映射，设备侧的ATC缓存里还留着旧翻译，设备再去访问就会出错。处理办法是内核通过ATS协议向设备发送invalidate命令，要求设备清空对应的ATC缓存项。问题在于，如果程序频繁地对内存进行映射和取消映射操作，invalidate消息就会很多，处理不过来时性能会明显抖动。

我实测的一个例子：部署SVM模式后，发现某个推理服务在批量处理阶段的尾延迟从稳定2毫秒波动到最高15毫秒。排查后发现，数据处理前端频繁分配临时buffer、用完马上释放，导致mmu_notifier不断触发ATC失效。改成内存池复用，让buffer生命周期拉长后，尾延迟恢复了稳定。所以跑SVM场景，内存分配与释放策略一定要留意，尽量复用内存、减少频繁映射变化。

4. 硬件强制隔离：从PASID到IOMMU的完整闭环

4.1 一次DMA请求的完整旅程

把前面所有概念串成一条完整的链路，一次NPU DMA请求在硬件层到底经历了什么？假设租户A的进程在CPU侧申请了一块tensor，虚拟地址是0x7f1234560000，NPU要读取这块数据完成layer计算。

第一步，NPU硬件把当前执行上下文的PASID附加到TLP报文的PASID前缀字段中，形成一个携带身份标识的DMA请求。第二步，这个TLP通过PCIe总线到达根端口，进入IOMMU的处理逻辑。第三步，IOMMU先查看发起者的BDF，找到对应的Context Table项；由于启用了PASID，Context Table项指向一个PASID Table。第四步，IOMMU用PASID值去索引PASID Table，取得租户A对应的页表基地址、权限位等信息。第五步，IOMMU拿着进程虚拟地址0x7f1234560000，遍历租户A的页表，得到物理地址；如果启用了两级翻译，还需要再经过一级客户机物理地址到宿主机物理地址的翻译。第六步，页表命中且权限允许，数据返回设备；页表未命中或权限不足，则产生DMA页错误并中断上报。

这条链路的重点在于“每一个步骤都不可绕过”。NPU发出的DMA请求无论多么恶意，最终都必须经过IOMMU的验证。这就是“硬件强制”四个字的含义——不依赖驱动固件的正确性，而是依赖硬件逻辑的完整性。

4.2 两个租户如何真正互不可见

拿一个具体的对抗场景来验证。租户B是一个恶意用户，他设法搞到了租户A的某个敏感数据在内存中的物理地址PA_A，然后在自己的NPU kernel里直接向这个物理地址发起DMA请求。在没有硬件强制隔离的系统里，驱动如果允许原样透传物理地址，那么B确实有可能直接读取A的数据。

但在PASID+IOMMU方案里，情况完全不一样。IOMMU看这个DMA请求，发现它来自B的BDF和B的PASID，那么地址翻译必须走B的PASID表项。即使B请求的目标地址恰好就是PA_A，但在没有映射关系的PASID页表里，这个地址可能根本不存在，或者被翻译到了别的地方，IOMMU直接拒绝。B连发起一个合法DMA“经过A的地址空间”都做不到，因为设备发出的每个请求都必须先通过IOMMU的地址翻译与权限检查。

我们还做过一次内部验证：特意写了一个测试程序，尝试让设备直接发起裸物理地址访问。预期结果要么是DMA无法完成，要么IOMMU记录一条错误日志。实际跑下来，IOMMU把请求挡得干干净净，dmesg里出现了一串DMA fault记录。这就形成了“互不可见”的实证。

4.3 配合虚拟化实现VM级隔离

如果租户不是容器而是虚拟机，隔离逻辑会再复杂一层。KVM直通NPU设备时，通常使用VFIO将整个物理设备或SR-IOV虚出来的VF设备分配给虚拟机。虚拟机内部的进程运行的是自己的“客户机操作系统”，有自己独立的物理地址空间概念GPA。

体系结构上，每个VM的GPA空间是天然隔离的。IOMMU的第二级翻译再加一层保险：就算VM内部出现了漏洞，某进程在客户机内读到什么GPA都只是“虚拟的”，到了IOMMU这一层还要经过二级翻译才能到达宿主机真实物理内存。两个VM即使内部的GPA完全重叠，翻译后落到宿主机物理地址却分属不同区域。

需要特别注意的是，VFIO直通模式下PASID的SVM能力与虚拟机自带的vIOMMU配合并不简单。不是所有虚拟化平台都支持把客户机内的PASID请求正确透传到宿主机的IOMMU。我们这里初期就遇到过：VM内设备驱动虽然尝试创建PASID上下文，但宿主端IOMMU不认，只能退回传统的IOVA模式。后来更新了宿主内核版本和QEMU版本才解决。虚拟化环境下的排查难度高于裸容器，后面实操部分详细展开。

5. 落地实践：配置、验证与性能调优

5.1 内核与BIOS侧准备

硬件的坑，启动阶段就要填平。第一步是BIOS里打开VT-d（Intel平台），或者开启AMD-Vi/ARM SMMU对应开关。不同厂商的BIOS菜单名不一样，但一般都能搜到“VT-d”“IOMMU”“SMMU”这类关键词。第二步是确保内核命令行带上了IOMMU相关的参数。最常见的是intel_iommu=on，x86平台还要注意iommu=pt这个参数的含义：它让IOMMU在直通设备模式下使用passthrough模式，对直通虚拟机性能友好，但对安全隔离存在一定的绕过风险。我建议隔离敏感的生产环境不做全局pt，而是在具体设备策略上按需配置。

重启后第一件事看内核日志是否出现DMAR相关的初始化信息。如果什么都没看到，大概率是BIOS没开或内核config缺了。再看设备的PASID能力：lspci -vvv -s 03:00.0 | grep -i pasid能匹配到PasID Cap就说明设备硬件支持。最后确认内核模块是否加载了vfio_pci，如果是VM直通方案，这步是必须的。

5.2 配置一个最小可用的多租户SVM场景

我以一个裸容器场景为例，说明最简单的多租户配置流程。前提：宿主机内核开启SVA，NPU驱动支持PASID上下文。

第一步，确保NPU驱动加载成功并正常识别设备。第二步，启动第一个容器，通过设备插件或手动挂载将NPU设备节点传入容器。第三步，在容器内跑一个初始化测试，驱动会为当前进程分配PASID，并在内核日志里记录PASID分配信息。第四步，启动第二个容器重复同样流程。此时两个容器各自拥有独立的PASID和独立地址空间映射。第五步，在两个容器里各自跑一个简单的tensor读写测试，确认均能正常访问自己的内存。

需要说明的是，具体命令和接口会因为NPU厂商不同差异极大。如果你们的设备驱动支持iommu_sva_bind_device接口，核心流程大致如下：驱动在open或context create阶段调SVA接口创建PASID，在DMA下发时把PASID填充到硬件寄存器或描述符中。因为驱动接口差异大，这里就不给固定代码了，先确认你们自己的SDK有没有开启“SVM模式”的开关，很多时候只是环境变量或驱动参数没开。

5.3 验证隔离效果的检查清单

配置完了不等于隔离生效了，如果不在上线前验证一遍，出了问题很被动。我习惯按这个清单验证隔离效果：

• 日志检查：两个租户的dmesg里，各自出现不同PASID的上下文分配记录。
• 地址物理性验证：在容器内用工具把一个缓冲区映射成hugepage，读取pagemap得到物理页帧号，确认两个容器对应缓冲区的物理页完全不同。
• 错误注入验证：在一个容器里发起一个明显非法的DMA访问（比如访问已卸载驱动的某段寄存器），确认IOMMU产生DMA fault日志，而不是静默成功。
• 并发压力验证：两个容器同时跑相同的推理负载，确认各自延迟不被对方明显拖垮。这一步能暴露性能隔离不足的问题。
• 固件更新后回归：设备固件和驱动任何一次升级后，都要重跑一遍上述检查。

5.4 性能调优的关键参数

PASID和IOMMU不是没有代价的。在隔离要求高、性能敏感的推理服务里，我做过几次实际性能标定和调参，这里说几个关键点。

大页配置影响很大。SVM模式下，IOMMU的页表遍历同样遵循TLB特性，2MB大页的TLB覆盖范围远超4KB小页。我们把NPU服务进程的malloc和模型权重加载改为hugepage-aware之后，DMA TLB miss率下降了接近三成，推理延迟的抖动也明显变小。可以用HugeTLB或透明大页，但要注意透明大页在SVM场景下可能带来额外内存回收复杂度，我建议优先考虑显式大页池。

invalidate批处理也很重要。如果程序频繁unmap短生命周期buffer，会产生大量ATC失效操作。优化方向是内存复用：把临时tensor分配从malloc改成从预分配池里拿。生产环境我们会统计每秒mmu_notifier触发的invalidate次数，超过阈值就提示业务侧调整内存策略。

最后要留足IOMMU中断处理能力。DMA page fault和invalidate完成中断都会打到CPU上，如果中断处理不过来，会造成IOMMU队列积压。多队列中断亲和的配置，能摊消掉一部分瓶颈。

6. 常见问题排查与独家避坑经验

6.1 常见问题速查表

6.2 我踩过的四个坑

第一个坑是把iommu=pt当作万能优化参数。当时为了让直通虚拟机性能好一点，我在全局命令行加上了它，结果跑了一段时间后，安全审计发现直通设备在pass-through模式下绕过了重映射检查，相当于DMA裸奔。后来我改成只在确实需要高带宽、低延迟且信任设备固件的内部场景局部开启，多租户生产环境一律严谨模式。这个参数的使用一定要谨慎，不能为了性能牺牲隔离。

第二个坑是设备固件升级后PASID能力发生了变化。某次固件升级后，设备的PASID从14位缩水到8位，虽然仍在设计范围内，但原先支撑上百租户的设计突然只能支撑二百五十六个。我们差点因为没有提前回归测试而在扩容时翻车。从此之后固件升级的回归测试清单里，必然包含PASID能力检查。

第三个坑是忘记处理内存热迁移对SVM的影响。如果宿主机启用了内存热迁移或NUMA balacing，某进程的部分物理页可能会被迁移，CPU侧页表会更新。但设备侧ATC缓存如果不配合invalidate，设备仍按旧翻译访问旧物理页，轻则读到旧数据，重则访问已释放页产生dmA fault。解决方式是确保驱动正确实现了mmu_notifier回调，并在NUMA平衡粒度上避免大范围页面迁移。

第四个坑更隐蔽。我们在一个容器场景里使用了cgroup v2限制内存，但当某个租户的内存使用量超过cgroup限制触发回收时，驱动没有及时处理page fault，DMA直接卡死，整台设备上的所有其他租户都跟着遭殃。故障隔离在这里被击穿了。后来我们在设备固件侧给每个PASID上下文配置了独立的错误处理机制，一个上下文的fault不会拖垮整个设备的其他上下文。

6.3 什么情况下建议别上PASID

PASID不是万能的，也不是每个场景都该硬上。我的判断标准很简单：不是多租户共享同一张卡的场景，没必要上PASID；设备固件和驱动对SVM支持不成熟时，建议观望。

举个例子，如果你们每个租户都是独占整卡，只是共享宿主机，那么传统的DMA重映射和IOVA模式已经完全够用，还能少承担SVM的地址缓存失效和性能调优成本。反过来，如果你们确实要在一个物理NPU上让几十个容器同时跑推理任务，而且有安全合规审计压力，那么PASID+IOMMU这个模式不仅值得上，越早越好。启动早，就能越早积累排障经验，比上线前临时抱佛脚要从容得多。

结尾：一次设备异常后的复盘与长期维护建议

还记得有次线上故障让我印象很深。某个租户的推理进程因为bug触发了大规模DMA页错误，如果没有硬件强制隔离，这个错误很可能波及同卡上的其他租户。但因为PASID上下文把故障范围圈在了单个租户内部，IOMMU拦截并上报，其他租户毫无感知。那一刻我深切体会到，硬件层隔离的投入是值得的。我还想提醒一件常被忽略的事：PASID和IOMMU隔离方案上线只是起点，真正的可靠性来自持续维护。设备固件每次升级、驱动每次迭代、内核每次大版本更新，都可能改变IOMMU行为或PASID分配策略，一定要把隔离验证写进CI/CD流程，每次变更后自动跑一遍故障注入和并发压力测试，让“隔离能力”成为可回归的指标。

如果后续你们要从单机8卡扩展到跨节点的AI集群，可以把这套硬件隔离思路继续延伸，结合网络侧的虚拟化隔离，比如RoCE或InfiniBand的多租户子网隔离，让整条数据通路上的每一个转发点都具备身份认证和访问控制能力。硬件强制隔离的本质，就是让系统不依赖任何单一软件组件的“良心”来保证安全，而是用确定性逻辑把边界焊死。这应是我们做基础设施时的信仰。