1 DPU 与卸载要回答什么
服务器里的 CPU 除了运行应用，还要处理网络收发、存储访问、地址转换和安全检查。设想 1 台 2U 服务器：有 32 个物理 CPU 核、256 GB 内存、4 块 NVMe SSD，以及 1 张双端口 100 GbE 网卡。当应用读写远端数据时，主机要准备缓冲区、处理协议、提交收发请求，再接收完成通知。即使应用计算没有变复杂，输入输出负担也可能占走更多 CPU 时间。购买更快的网卡，并不保证应用就能得到更多计算资源。
DPU 通常指承担部分基础设施数据处理工作的专用处理器或板卡。常见形态是在网络接口附近集成通用处理核、专用处理单元、独立内存和管理能力，再通过 PCIe 接入服务器。有的产品是一张扩展卡，有的与主板或特定机箱紧密集成。“DPU”不是保证所有功能都存在的统一硬件规格；判断能力时，要查看实际支持的协议、规则规模、固件版本和部署方式。
卸载则是更宽的概念：把原来由主机软件执行的部分工作交给其他硬件。普通网卡就可能支持校验和计算、分段发送或接收合并，并不一定带有可以独立运行基础设施软件的处理环境。反过来，插入 DPU 也不意味着流量已经经过它的处理路径。板卡存在、驱动识别、功能启用、业务命中规则，是需要分别确认的事实。
问题的核心是：到底搬走了什么工作，工作搬到哪里，原来的责任由谁继续承担？例如，主机原先为每个报文查找转发表，卸载后可以由板卡中的表项完成匹配与转发。但策略如何生成、表项何时失效、硬件满了以后怎么办，并不会因为查找动作变快就自动解决。卸载只是改变执行位置，也会改变资源限制与排障入口。
读连接图时，要把网络带宽和主机接口带宽分开。100 Gb/s 按位换算约为 12.5 GB/s，尚未扣除协议开销；PCIe 4.0 x8 的单向理论带宽在扣除线路编码后约为 15.75 GB/s，实际可用载荷还会更低。双端口同时向主机发送数据时，共享链路可能先达到上限。端口标称速率不能直接相加后当作应用吞吐。
服务器形态也有约束。1 张全高扩展卡可能放不进低矮机箱；功耗、散热风道、插槽位置和辅助供电也可能限制部署。卡上的内存通常不是主机 256 GB 内存的一部分，应用不能默认把它当作普通内存使用。入门阶段先建立这张物理地图，比背诵板卡名称更有价值：数据经过哪些器件，哪些链路共享，哪处故障会影响整条路径。
2 数据面卸载与控制面
数据面是反复处理实际数据的路径，例如收到报文后识别头部、匹配规则、修改字段并转发。控制面负责决定规则，例如根据网络配置建立转发表、批准连接或更新访问策略。两者可以运行在不同处理器上，也可以部分共处于主机；区分依据是职责，不是芯片的名称。处理频繁且模式稳定的数据面动作，往往更适合硬件加速。
用 1 条允许虚拟机访问远端存储的连接来观察。管理程序先确定租户身份和目的地址，把允许访问的规则下发给 DPU；DPU 接收后检查资源是否足够，再报告安装结果。随后报文到达时，硬件查表并执行动作。主机可以减少逐包处理，但仍可能负责规则创建、连接异常和未被硬件支持的报文。把“转发已经卸载”理解为“主机完全退出网络”，会漏掉这些路径。
规则还没有装好时，报文可能被送回主机软件处理，也可能按配置丢弃。这里没有通用的最佳默认值。软件回退可以保持某些业务可达，但会突然增加主机负载；直接丢弃能维持某些隔离边界，却会降低可用性。方案必须写出实际行为，并且确认回退路径执行相同的访问策略。否则，性能优化可能意外改变业务权限。
数据如何进入内存也需要分清。DMA 是设备在授权范围内直接读写内存的机制，能够减少 CPU 搬运数据的工作。支持 DMA 的设备依然要建立映射、管理缓冲区并发出完成通知。卸载不等于数据从此不经过主机内存，也不等于每次操作都没有复制。是否绕过某段路径，要看具体模式、驱动和操作系统支持，不能仅凭“零拷贝”名称判断。
存储卸载也有类似边界。某些设备可以处理远端块存储协议的一部分，减少主机封装报文和维护连接的负担；本地 NVMe SSD 的介质延迟、队列拥塞和持久化语义仍然存在。网络上的确认和数据已经安全落盘不是同一个事实。若应用需要持久化保证，必须继续检查存储协议及目标端的确认条件，不能把板卡收到了数据当作写入完成。
交互中先显示规则下发，再显示普通报文命中，最后显示规则缺失后的分支。注意 2 种不同的忙碌：规则变化频繁可能压满控制面，而规则稳定时的大量报文可能压满数据面。它们的监控指标不同。前者应看安装延迟、失败次数与待处理数量；后者应看报文速率、处理单元利用率与丢弃计数。
因此，描述卸载能力时应使用完整句子：“在指定协议、报文长度和规则数量范围内，由设备执行这些动作；其余情况走这条路径。”这比“支持网络卸载”更容易验证。至于硬件流水线如何编排、复杂表结构如何实现，可以留到后续课程；当前只需要能够沿着实际报文找出执行者、状态所在位置和异常出口。
3 隔离、可编程与运维
DPU 的独立处理环境可以让部分基础设施服务与主机应用分开运行。例如主机操作系统重启期间，板卡上的管理服务可能仍然存活；某些网络策略也可能由主机之外的受控环境执行。这能帮助划分责任，但不代表隔离自然成立。设备能访问哪些内存、谁能修改固件、谁能建立管理连接，才是边界能否成立的关键。
IOMMU 可以按配置限制设备的 DMA 访问范围，作用类似为设备访问主机内存设置检查点。它需要处理器平台、固件、操作系统和驱动共同支持并正确启用。把设备分配给虚拟机时，还要检查设备分组与重置能力。不能因为卡上有独立内存，就推断它无法读取主机内存；也不能因为启用了某个隔离开关，就跳过实际的权限验证。
可编程意味着能够改变部分处理行为，例如更新转发规则或加载受支持的处理程序。可编程范围通常有明确限制：不是所有协议字段都能解析，不是所有动作都能组合，表项、计数器和设备内存也有容量上限。规则从 1 万条增长到 10 万条时，是否仍能完整进入硬件，应当以设备规格和实际安装结果为准。规则创建成功与硬件安装成功需要分别观察。
运维上，原来管理 1 套主机系统，现在可能还要管理板卡固件、板卡上的系统镜像、驱动以及控制程序。它们之间有兼容关系。主机驱动升级后能否继续识别旧固件，设备镜像回退后是否还能理解当前配置，都要在发布前确认。版本管理的对象也应包含配置格式；只保存安装包而没有配置快照，未必能恢复原有行为。
管理网络应有明确入口和访问权限。即使数据端口没有连通，也应知道能否通过独立管理口或机箱管理通道查看设备健康状态。设备时间与主机时间还应保持可关联，否则主机日志里的超时与板卡日志里的重置可能看似发生在不同阶段。日志保存空间、轮转策略与故障后导出方式，都应在设备正常时验证。
重启行为尤其容易被忽略。主机重启、驱动重新加载、PCIe 功能重置、板卡重启、整机断电，对设备状态的影响可能不同。某些重置只影响部分队列，另一些会清空规则并中断所有共享端口。运维手册需要说明影响范围与恢复顺序，不能把所有动作都写成“重启网卡”。对共享同一设备的多个工作负载，错误的重置范围会放大故障。
还要观察 DPU 自身的健康状态。设备处理核饱和、板载内存不足、温度超限或供电异常，都可能让主机看起来“CPU 很空，网络却很慢”。主机空闲并不等于系统有余量。完整容量评估需要同时查看主机 CPU、设备资源、PCIe 链路和网络端口。这里只建立责任边界，不深入设备内部调度；先保证每类状态都有人负责采集、解释和处置。
4 动手：对照一次网卡卸载前后 CPU
这个实验使用普通网卡也能完成，目的是观察卸载怎样改变主机负担，不用于证明某张 DPU 的全部收益。准备 2 台 Linux 测试机，连接在受控测试网络上；被测机有 32 个物理核和 25 GbE 接口，另一台能稳定提供足够流量。不要在生产管理接口上切换功能。先确认具有本地控制台或其他可靠入口，并记录接口原始配置，实验结束后逐项恢复。
选择校验和、分段、接收合并等能力之前，先查看实际支持情况。下面以接口 ens5f0 为例，名称需替换为当前机器接口。ethtool -k 显示的 fixed 项通常不能修改；命令返回失败时，不要假定状态已经改变。链路速率、驱动与固件信息也要同时记录，便于判断结果是否来自同一环境。
ethtool ens5f0
ethtool -i ens5f0
ethtool -k ens5f0
lscpu先把输出保存到实验记录，再在对端启动 iperf3 -s。被测机作为客户端，发送测试默认观察被测机的发送路径，加入 -R 则观察它的接收路径。每轮保持方向一致，不要把发送实验和接收实验直接相减。以下地址是文档示例地址，运行时替换为对端测试地址。工具版本也要记下，因为不同版本的线程行为可能影响 CPU 分布。
iperf3 -c 192.0.2.20 -P 4 -t 60 -O 5
mpstat -P ALL 1在独立终端运行 mpstat，观察总 CPU 与各核分布。发送路径主要关注 TSO 和 GSO：它们让较大的数据块在较后阶段分成网络上的报文。接收路径主要关注 GRO，它把可合并的数据交给协议栈。实验只切换这些相关开关，保持校验和等其他配置不变。以下命令需要管理权限，且每次执行后都应重新用 ethtool -k 确认实际状态。
sudo ethtool -K ens5f0 tso off gso off gro off
ethtool -k ens5f0这是关闭相关能力的测试状态。完成测量后，仅对原先开启且允许修改的项重新启用；如果记录显示这 3 项原来都开启，可以使用下面的命令。原来关闭的项应保持关闭。若某项不能切换，就在报告中注明，并缩小结论范围，不要继续把它算进“已关闭”的组合。
sudo ethtool -K ens5f0 tso on gso on gro on
ethtool -k ens5f0
先预热，再让每种状态执行 3 轮，交替安排开与关，使用同样的持续时间、并发数和方向。尽量固定后台任务、CPU 电源策略及网卡队列配置；同时记录吞吐、每核 CPU、TCP 重传和接口丢包。ip -s link show dev ens5f0 可提供接口统计，ethtool -S ens5f0 的设备计数器需查对应驱动说明。累计计数要比较每轮增量，不能直接比较总值。
假设开启后得到 23 Gb/s、消耗约 3.2 个等效 CPU 核，关闭后只有 18 Gb/s、消耗约 5.5 个等效核。这是演示数据，不是性能承诺。由于吞吐不同，不能只说“节省 2.3 个核”；还应把双方发送速率限制到都能稳定达到的水平，再比较相同有效吞吐下的 CPU。跨工具比较时，要注明百分比按单核还是整机归一化。
卸载还可能改变抓包视角：主机抓到的大块数据不一定就是线上帧长，校验和字段也可能尚未由硬件填好。需要线上的报文证据时，应结合对端抓包或交换机镜像。完成这次实验后，你能得出的是“这些开关在这个负载下改变了主机处理成本”。要评价完整 DPU，还需另外检验其转发、策略与存储功能，以及启用后的故障处理行为。
5 卸载收益与锁定取舍
评估收益时，先问当前瓶颈在哪里。如果应用在等待 SSD，且网卡处理只占很少 CPU，把网络处理搬走可能几乎不缩短请求时间。若服务器持续处理大量小报文，逐包开销可能非常显著。同样是 100 Gb/s，小报文每秒数量通常远高于大报文，因此“带宽相同”并不代表处理压力相同。报告应同时给出报文速率和报文长度分布。
CPU 节省也要看能否转化成有用资源。假设总共减少了相当于 4 个核的消耗，但负载分散在 32 个核上，应用是否能立即使用这些空闲时间，要看调度、亲和性和内存访问等条件。不要直接把百分比变化写成“可以少买 4 个核”。更稳妥的证据是：在相同业务目标下，应用能提高多少吞吐，或能在减少多少主机资源后继续满足延迟要求。
成本不仅是板卡价格，还包括功耗、散热、插槽、部署和运维。例如新增板卡平均消耗 60 W，连续运行 24 小时，设备自身每天耗电约 1.44 kWh，尚未计入供电损耗与制冷。若为了腾出插槽而减少 NVMe 扩展能力，存储容量也可能受影响。这些约束会决定卸载是否适合某类机器，而不是只影响采购表中的单价。
滑块把每秒报文数、主机每包成本与希望卸载的比例联系起来，同时设置设备处理上限。提高目标比例后，实际卸载量可能停止增长；主机仍要处理剩余流量和提交完成等工作。这个模型只说明资源关系，不预测某张卡的真实性能。实际收益还受报文特征、内存带宽、规则命中率和 PCIe 路径影响，需要测量才能确定。
锁定风险来自依赖的接口和行为。若策略只用通用配置表达，迁移时可能主要替换适配层；若应用直接依赖专用队列接口、特定程序格式或设备内部状态，迁移就可能涉及应用修改和数据转换。开放接口有助于降低切换成本，却不能保证规则语义、性能或故障行为一致。比较替代设备时，需要重跑实际业务和故障测试。
因此可以把取舍写成可检查的条件：业务需要的有效吞吐、延迟目标、主机资源上限、设备容量余量，以及可接受的恢复时间。再补充软件回退的最低能力和迁移办法。如果收益只在非常窄的负载区间出现，应清楚写明适用范围。入门阶段不必追求复杂成本模型；先避免把“板卡能做”误写成“整机值得这样做”，就已经能排除不少错误方案。
6 常见坑：卸载后排障能力下降
卸载后最常见的误判，是沿用原来的观测位置。过去主机抓包能看到全部转发流量，如今某些报文直接在设备内部完成处理，主机抓不到并不能证明报文没有到达。主机防火墙计数没有增加，也可能只是相关流量没有经过这个软件路径。排查之前，应先确认观测点覆盖哪段路径，再解释其中的数字。
需要给路径上的关键位置设置证据：交换机是否发出、设备端口是否收到、规则是否命中、设备是否转发到主机队列、主机是否完成接收，以及应用是否读取。并非所有设备都提供这些独立计数，缺少的观测点应在方案中标明。计数器名称也不能望文生义；“丢弃”可能包含策略拒绝、缓冲不足或格式错误，必须结合设备文档解释。
先区分链路不通、处理路径异常与业务超时。端口亮灯只说明某种物理连接状态，不证明规则正确；PCIe 设备能枚举，也不证明所有队列都能工作。若应用超时而设备接收计数持续增长，应继续看规则命中与主机交付；若设备端口本身没有收到流量，则应向交换机、线缆和对端查找，避免在主机协议栈里反复调参。
另一个坑是回退造成的资源突变。原先主机只处理少量异常报文，规则失效后突然接收全部流量，CPU 和接收队列可能迅速饱和。此时设备看似“成功回退”，业务仍可能中断。回退必须有容量前提，可以规定降低接入速率、限制并发或迁移负载。把主机软件路径保持可用，只解决了功能存在的问题，没有解决它是否承受得住。
排障动作也会破坏证据。直接重启设备可能清空易失计数器、规则和故障现场；在安全与恢复时限允许时，应先导出版本、链路状态、队列统计和相关日志，再执行重置。若必须立即恢复业务，记录动作时间和影响范围，并接受部分根因证据会丢失的事实。不要为了等待完整转储而无限延长业务中断。
远程访问尤其要考虑共享故障点。若管理连接也经过正在排查的设备，关闭卸载、重置端口或加载固件都可能切断操作通道。因此需要预先验证备用管理入口，而不是故障发生后再寻找。这个要求来自实际连线关系：同一块卡承担业务与管理时，软件上不同的地址未必意味着物理上独立。
恢复判断应回到应用。接口丢包不再增长、链路恢复和 CPU 降低都只是中间证据。还要确认有效吞吐、错误率与延迟恢复，并观察持续时间是否覆盖原来的复现条件。对照时保持报文大小、方向和规则规模相近；只用少量连通性探测通过，无法证明高负载下的路径已经恢复。
7 案例：固件缺陷导致静默丢包
下面是用于教学的构造案例，不对应特定厂商的已公开事故。某机房给 1 批 2U 存储服务器升级 DPU 固件，硬件配置仍是双端口 100 GbE、PCIe 4.0 x16 和本地 NVMe。升级后，少量远端读取出现长尾延迟，偶尔触发应用重试。主机 CPU 没有升高，物理端口没有明显错误，常规连通性检查也通过，值班人员最初怀疑存储介质。
这里的“静默”是指设备没有给出明确对应的错误上报，丢包位置也没有体现在常看的主机计数器中。它不意味着所有协议都检测不到丢失。TCP 仍可能通过重传和超时暴露问题；如果业务使用 UDP，则要依靠应用序号、确认或其他机制发现缺口。发现结果与识别设备内部原因，是不同层次的能力。
排查先保持负载、报文方向和规则规模可比较，将升级机器与未升级机器分组观察。发现问题集中在新固件，能够缩小范围，却还不足以证明固件缺陷：升级过程也可能改变配置或触发硬件状态变化。接着逐项核对配置，并在测试机上复现，以避免在生产环境同时修改多个变量。
对端记录显示数据已经发出，交换机出口统计正常，设备端口接收量也增加；但是主机接收队列完成量出现缺口。通过带序号的受控测试流量和同步时间记录，确认缺口发生在设备收到报文之后、交给主机之前。这里不能简单把不同层的字节计数直接相减，因为封装和合并会改变计数口径；应优先使用可关联的报文序号与同口径计数。
复现进一步发现，问题需要“规则更新与持续接收流量重叠”才出现。测试人员固定流量，仅控制规则更新频率，并在相同配置下交替使用新旧固件。新版本重复出现缺口，回退后消失；设备供应方结合转储确认规则切换路径存在缺陷。到这时，才能将固件缺陷作为已确认结论，而不是仅凭升级时间相近就下判断。
处置分成恢复与修复。先停止扩大升级范围，对受影响机器按支持流程回退，并验证配置能被旧版本读取。无法安全回退的机器可以临时降低负载或关闭相关卸载，但要确认主机容量与隔离策略仍满足要求。备用路径不是无条件安全的开关；若它绕过必要策略，就不能作为正常恢复方式。
修复固件进入机房前，测试应覆盖已知触发条件：持续流量下的规则更新、不同报文长度，以及设备重启后的恢复。发布先从少量机器开始，观察重传、业务延迟和队列交付，而不是只看升级成功率。案例留下的通用经验是：静默故障需要跨位置关联证据；版本对照帮助建立因果关系；恢复有效并不等于根因已经查明。
8 把 DPU 职责写进主机方案
主机方案应从职责开始，而不是从设备型号开始。可以先写：“主机继续运行应用、文件系统和业务协议；DPU 处理指定网络的转发与访问策略；控制程序负责生成、安装和核对规则。”随后列出协议范围、不能卸载的报文、异常报文出口和软件回退条件。这样，即使以后更换板卡，也能判断哪些需求必须保留。
硬件部分要能落到装机检查。记录机箱高度、可用插槽、PCIe 代际与实际协商宽度、端口数量、线缆类型、功耗预算和散热要求。还要确认网卡与 NVMe 是否争用同一组上行资源，以及插槽靠近哪个处理器插座。双路服务器中，不同插槽到 CPU 和内存的路径可能不同；这种位置差异需要实际测试，不能仅凭接口名称判定等价。
软件部分记录主机系统、驱动、设备固件和控制程序的兼容组合，并指定升级顺序。安装完成的验收不止是设备出现在系统列表中，还包括规则确实进入硬件、指定流量命中，以及未支持的流量按预期处理。设备报告成功、主机观察成功和应用行为成功，应能够在验收记录中互相对应。
容量表应同时描述主机与设备。除了目标 Gb/s，还要写报文速率、长度分布、并发连接、规则数量和规则更新频率。对于读写存储的机器，还需记录网络吞吐与 SSD 负载同时上升时的表现。分别测得网络和存储峰值，不能证明 2 者同时运行时都能达到峰值，因为它们可能共享 PCIe、内存或 CPU 资源。
故障责任要能落实到人和动作。主机团队负责哪些日志，网络团队检查哪些端口，设备维护者如何导出状态，谁决定回退，都应明确。发生静默丢包时，避免所有团队只凭自身计数器正常就结束排查。更有效的交接方式是说明已经确认的最远位置、尚未覆盖的路径，以及下个观测点需要提供的证据。
验收至少覆盖正常运行与故障恢复：正常时比较相同业务水平下的主机资源；规则安装失败时确认告警和处理路径；设备重启后确认隔离策略及业务恢复；关闭卸载时确认容量是否足够。恢复时间从业务受到影响开始计时，直到业务指标回到约定范围，不能只计算设备重新上线的耗时。
最后保留退出办法。哪些配置可以导出为通用表达，哪些行为依赖设备专用接口，替代方案需要修改多少应用，都应写入文档。如果暂时无法提供等价替代路径，就明确这项依赖及可接受的中断窗口。技术选择允许有代价，但代价应当被看见、被测试，并与卸载带来的资源收益一起进入决策。
9 从DPU 与卸载走向分布式训练原理（A41）
分布式训练把计算放到多台机器上，机器之间需要交换训练数据和模型相关结果。即使暂时不深入梯度与集合通信的算法，也能理解基础约束：计算完成得再快，如果下一阶段必须等待远端数据，网络路径就会进入整体耗时。DPU 可能减少其中的主机处理成本，但它不能凭空提高所有链路的容量，也不能消除跨机器协调。
设想 4 台训练服务器，每台配置加速器、本地 NVMe 和 100 GbE 网络。数据可能先从存储进入主机内存，再被送到加速器；服务器之间还会交换结果。具体是否能够直接在设备间传输，要看加速器、网卡、驱动和软件共同支持的路径，不能把示意图上的相邻器件理解为已经存在直接连接。实际部署需要确认数据是否仍绕经主机。
粗略估算时，100 Gb/s 对应的 12.5 GB/s 只是换算后的上限。假设某阶段需要经同一发送方向搬运 20 GB 数据，仅按这个上限计算也至少需要约 1.6 秒；协议、争用和调度会使实际耗时增加。这个例子不代表完整训练步骤的通信量，也不代表某种集合通信算法的总耗时，只用于提醒：先确认搬运量和实际有效带宽，才能讨论优化空间。
增加服务器数量还可能放大尾部影响。若某台机器因为 DPU 规则异常而反复重传，其他机器可能在同步阶段等待它。此时集群平均 CPU 很低，也不能证明通信健康。应从单机端口、设备队列一直观察到训练步骤耗时，寻找慢的参与者及其等待原因。局部节省 CPU 与整体训练加速，需要分别提供证据。
进入 A41 时，可以继续追问：哪些数据必须交换，哪些通信能与计算重叠，拓扑和慢节点如何影响训练时间。这里暂不展开通信算法和设备内部实现。带着本课的路径意识即可：指出数据来源、经过的器件、共享的瓶颈与故障出口，再讨论把哪部分处理交给硬件。这能让分布式训练的性能分析落在真实机器上。
放进方案里
本方案采用 2U 主机，配置 32 个物理 CPU 核、256 GB 内存、4 块 NVMe SSD，并为双端口 100 GbE DPU 预留 PCIe 4.0 x16 插槽。实际装机确认协商速率与宽度，核对双端口流量、存储访问是否共享上行资源，同时核对板卡尺寸、供电和散热。端口线速不作为应用吞吐承诺，板载内存不计入主机可用内存。
DPU 承担指定网络的转发与访问策略执行，主机保留应用、业务协议和异常处理职责。控制程序负责规则生成、安装确认与状态核对；文档列明支持的协议、规则容量及未命中处理方式。设备访问主机内存的范围受平台映射与隔离配置约束，管理入口采用受控权限，并保留经过验证的备用访问通道。
验收使用固定方向、报文长度分布和并发条件，对照卸载开关下的有效吞吐、主机等效核消耗、延迟、重传及丢包增量。容量测试同时施加网络与存储负载，另测持续流量下的规则更新。收益以相同业务水平下释放的主机资源为依据，同时计入设备功耗、运维和迁移成本；具体目标值由业务需求与实测基线确定。
规则容量验收须触发硬件表项耗尽，确认安装失败可见、既有规则仍有效，并用允许与拒绝的测试流量核对回退策略。板卡重启后，在规则恢复前持续发送应被拒绝的报文，以对端接收记录和设备计数证明隔离边界未被绕过；出现越权交付即判验收失败。
上线锁定兼容的系统、驱动、固件与控制程序组合，先少量部署，再按业务指标扩大范围。发生异常时，优先关联交换机、设备与主机证据，在恢复时限允许时保存计数和日志。回退必须同时满足容量与隔离要求，规定限流或迁移条件，并验证应用恢复。保留配置快照、受支持的旧版本与退出方案，明确各团队的维护和故障处置责任。
10 小结：下一步分布式训练原理（A41）
DPU 把部分基础设施处理移到主机之外，收益取决于实际搬走的工作与原有瓶颈。数据面、控制面、DMA 权限和异常回退仍需要清晰边界。评估时既看节省多少主机资源，也看新增了哪些设备限制与运维责任。
现在应当能够说明：为什么主机抓不到报文不等于报文没有到达；为什么卸载比例提高后收益可能停止增长；为什么设备故障后的软件回退需要容量验证。下一课 A41 将把这些路径与容量概念放入分布式训练，分析多台机器如何协作，以及通信为什么可能限制计算。