1. 先把概念对齐：SmartNIC 和 DPU 到底差在哪一步

只要接到“给服务器加一块卡，把网络卸载掉”这类需求，绕不开 SmartNIC 和 DPU 这两个词。它们高频出现在招标文件、架构评审和招聘 JD 里，但十个团队里有六个对它们的边界理解是模糊的：有人把支持 SR-IOV 的普通网卡也叫 SmartNIC，有人把带 ARM 核的卡一律称 DPU。名词混淆的直接后果是选型踩坑——预算按 DPU 报，买回来发现只能做固定功能卸载，想跑个自定义转发逻辑还得回主机 CPU。

我个人的划分标准很简单：能不能脱离主机独立跑一段完整的控制面程序。SmartNIC 的核心语义是“网卡变聪明了”，重点在数据面可编程，转发、过滤、封装这些动作可以在卡上完成；DPU 的语义是“基础设施处理器”，它是一台跑在 PCIe 上的小服务器，有自己的 CPU 核、内存、独立管理口，甚至能独立启动、独立升级、独立被带外管理。前者是网卡的增强版，后者是主机的卸载协处理器。这个区别决定了你在上面能做什么：SmartNIC 上你写的是报文处理流水线，DPU 上你写的是服务。

这篇文章想解决三件事：把技术方向的取舍讲清楚，把卸载边界怎么划讲透，把从裸机验证到云原生接入的实操路径铺出来。适合正在做基础设施选型的架构师、被网络软中断打爆的运维、以及想弄明白这块卡到底值不值得买的研发。不涉及具体厂商产品推荐，只讲方法论和可复现的操作。

1.1 三代形态与一条硬判定线

行业里习惯把这类设备分成三代，这个分法虽然粗，但足够实用。

第一代是固定功能卸载。TCP 分段卸载、校验和计算、VLAN 剥离、大包聚合这些，本质上是把 CPU 上几条固定的指令搬到硬件流水线里做。这一代的门槛在芯片设计，不在软件，使用者基本感知不到“可编程”这回事，开关一开就完事。很多人口中的“智能网卡”其实停在这一代，它解决的问题是 CPU 中断开销，不是业务逻辑下移。

第二代是可编程数据面。典型实现是用 FPGA 或者带可编程解析器的网络处理器，报文解析图、匹配动作表可以由使用者自定义。P4 语言在这个阶段真正落地，你可以定义自己的报文头格式、自己的匹配字段、自己的动作。这一代的价值在于“协议自定义”，比如私有隧道封装、自定义遥测头插入、特定业务的五元组之外的多字段分流。

第三代是带通用计算核的基础设施处理器。多核 ARM 或者类似的通用核，配独立 DDR，对外呈现多个 PCIe 功能，卡上跑一个精简的操作系统或者容器化运行时。它能做的事情一下子打开了：卡上跑 OVS 控制面、跑存储客户端、跑密钥管理、跑遥测采集、跑轻量推理。这时候它不再是网卡的附属，而是一个独立计算节点。

判定一条硬线，我通常问四个问题：

• 卡上有没有可独立编程的通用核，还是只有固定流水线加可编程表项？
• 有没有独立于主机的内存和启动流程，主机宕机时卡还能不能工作？
• 对外暴露的是单一 PF 还是多 PF 加多 VF 加管理口的一套拓扑？
• 控制面能不能在卡上闭环，还是必须依赖主机上的驱动和守护进程？

四个都答“是”，那是 DPU 的形态；只有第二个和第三个答“是”，基本是 SmartNIC 的加强版。选型时先答完这四个问题，再谈性能和价格，能省掉大量返工。

1.2 三个典型画像：谁真的需要它

不是所有团队都需要。我见过不少项目，买回来一块高配卡，最后只用来跑了 SR-IOV，其余能力全闲置，三年生命周期里连固件都没升过两次。真正能吃到红利的，通常是下面三类。

第一类是被软中断打爆的虚拟化或容器平台团队。一台宿主机跑几十个租户网络，OVS 的流表匹配、隧道封装解封装全在主机 CPU 上做，两个物理核常年 100% 软中断，业务抢不到算力。这种场景把 OVS 数据面卸载到卡上，收益是立竿见影的，而且是可量化的——原来被吃掉的那部分 CPU 直接还给了业务。

第二类是存储和网络融合的节点。一台机器既跑业务又跑分布式存储，网络流量和存储流量抢同一块网卡和同一批 CPU。把存储协议栈的客户端卸载到卡上，让卡直接对着本地盘做远端访问，主机侧的 CPU 和内存带宽压力会明显下降。这类场景对卡的 DMA 能力和本地盘直通拓扑要求较高，选型时要重点看卡的 PCIe 上行和下行端口配置。

第三类是安全与可观测性强需求的场景。加密解密、正则匹配、流量镜像、全包捕获，这些动作在主机上做代价极高。卡上有专门的加解密引擎和正则引擎，卸载过去以后主机侧只剩策略下发。做等保、做审计、做流量回溯的团队，这类收益比吞吐提升更实在。

反过来，如果你的业务是单机小流量、几乎不跑虚拟化、网络拓扑简单，那这块卡对你的边际价值非常低。我一般会建议这类团队先用软件方案把 DPDK 或者 XDP 跑通，把瓶颈定位清楚，再决定要不要上硬件。

2. 架构选型的十字路口：三条技术路线的真实取舍

确定了要不要用，下一个问题是选什么架构。这一层的选择一旦定下来，后面两三年的开发方式、运维方式、升级方式都会被锁死，改起来代价极大。我见过最痛的一种情况是：团队按“可编程”预期选了 FPGA 方案，结果发现团队里没人会写硬件逻辑，每次改需求都要找原厂支持，一个季度才能上线一个特性。

2.1 ASIC、FPGA、SoC 三条路的差异对照

这张表里最容易被低估的是“迭代周期”这一行。做基础设施的人对迭代速度的敏感度，往往要等项目进入第二期才会建立起来。第一期需求明确、功能单一，ASIC 方案看起来性价比最高；到了第二期，业务要加一个新协议，ASIC 只能等下一代芯片，FPGA 要重新综合布线，只有 SoC 方案能当天改完当天验证。所以我的经验是：需求可能在一年内发生变化，就不要选纯 ASIC；团队没有硬件工程能力，就不要选 FPGA。

2.2 通用核加加速引擎为什么成了主流方向

纯通用核做报文转发效率并不高，一个 ARM 核跑纯软件转发，小包性能撑不住高带宽；纯加速引擎又不够灵活。所以主流形态一定是“通用核负责控制面和复杂逻辑，加速引擎负责高频重复动作”的异构组合。

典型的加速引擎包括几类：报文解析与匹配动作流水线，负责快速分类和转发决策；加解密引擎，负责批量对称加解密和摘要计算；正则与压缩引擎，负责内容匹配和数据压缩；DMA 引擎，负责在主机内存、卡上内存和本地设备之间搬数据。这些东西用通用核做，性能差一个数量级，功耗还高。

这种架构对开发者的实际影响是：你得接受“一部分代码跑在通用核上、一部分逻辑烧在流水线里”的混合编程模型。控制面用 C、Rust、Go 写，跑在卡上的 Linux 或者实时核里；数据面用 P4 或者类似 DSL 描述，编译成流水线表项。两边的通信靠一层中间层完成，这层中间层的抽象质量，直接决定你的开发效率。

这里有个实操层面的心得：先确认这层中间层能不能做热更新。数据面流水线一旦编译烧录，如果需要重启卡甚至重启主机才能生效，那你在生产环境上基本不敢改。能支持表项级热更新、支持灰度下发、支持回滚的方案，落地阻力会小非常多。

2.3 板载内存与 PCIe 拓扑：先算一遍带宽账

这一节是我最想强调的，因为它是选型阶段最容易漏算、上线后最难补救的一项。

先算网络侧。100GbE 全双工意味着单向 12.5GB/s，收发合计 25GB/s。如果卡有两个 100G 口同时满跑，主机侧需要承载的 PCIe 带宽就是 25GB/s 到 50GB/s 的量级。PCIe Gen4 x16 的理论带宽约 32GB/s，扣掉编码开销实际可用 28GB/s 左右，跑一个 100G 双口就已经非常紧张；Gen5 x16 理论 64GB/s，实际可用 55GB/s 上下，才算有余量。这个账不算清楚，就会出现“网口跑不满”的怪现象，而且很难定位——你查链路是 100G，查 CPU 不忙，查卡上 CPU 也不忙，就是上不去。

再算内存侧。卡上 DDR 的容量和带宽决定了你能不能在卡上做有状态处理。做流表缓存、做连接跟踪、做包缓冲、做加密会话上下文，这些都要占内存。一个粗略的估算方式是：连接跟踪表项按每条 100 字节到 200 字节估，百万级并发就是 100MB 到 200MB；包缓冲按带宽乘以缓冲时延估，25GB/s 乘以 1ms 就是 25MB。加上操作系统和运行时占用，8GB 是起步，16GB 到 32GB 才谈得上从容。很多方案在纸面上写支持千万级并发，实际板载内存只有 4GB，跑起来频繁淘汰表项，性能曲线会在某个并发点断崖式下跌。

PCIe 拓扑还有两个细节值得提前确认：一是卡是不是同时具备上行端口和下行端口。只有上行端口的卡，做不了本地盘直通和本地设备卸载，存储类场景直接排除。二是 ACS 与 P2P 支持情况。主机侧要在卡和 GPU、卡和本地盘之间做点对点 DMA，如果 PCIe 交换结构不支持，数据得绕一圈主机内存，收益会大打折扣。

3. 卸载边界的判断：什么该卸、什么不该卸

确定选型之后，真正的技术活才开始：决定哪些功能下移到卡上。这项工作没有标准答案，但有一条原则可以贯穿始终——卸载的目标是把 CPU 周期从重复劳动里释放出来，而不是把复杂度藏起来。凡是卸载之后可观测性大幅下降、故障定位成本急剧上升的部分，都要慎重。

3.1 用一笔小包账算清卸载收益

卸载收益最容易被感知的场景是小包。算一笔账：以太网最小帧 64 字节，加上 20 字节前导码和帧间隙，链路上实际传输 84 字节，折合 672 比特。100Gbps 线速下，包速率是 100e9 / 672 ≈ 148.8 Mpps。

纯软件转发一个核能扛多少？经过精心优化的轮询模式驱动，单核处理小包大概在 10 Mpps 到 20 Mpps 之间，具体取决于报文处理逻辑的复杂度。按 15 Mpps 算，跑满 100G 小包线速需要 10 个物理核。这十个核的算力成本、内存带宽消耗、以及 NUMA 亲和性带来的调度复杂度，都是真金白银。

同样算大包：1500 字节帧加 20 字节开销，共 12144 比特，100Gbps 下包速率只有 8.2 Mpps，一个核就能扛住。这就是为什么很多团队觉得“我的网络没问题”——他们跑的是大包业务，比如文件传输、视频分发。一旦换成微服务之间的小请求、Redis 短连接、DNS 查询，包速率瞬间涨十倍，问题立刻暴露。

所以卸载决策的第一步是测出你的真实包速率分布，而不是看带宽利用率。带宽 30% 但包速率已经打到 20 Mpps，和带宽 80% 但包速率只有 5 Mpps，是完全不同的两个问题，解法也完全不同。

3.2 四类高价值卸载场景的拆解

网络数据面卸载。这是最成熟的一类。虚拟交换机的流表匹配、隧道封装解封装、NAT、ACL 全部下移到卡的流水线里。主机侧只保留控制面，负责下发流表和管理生命周期。收益是主机 CPU 占用下降，网络转发性能不再受主机调优水平影响。风险点是流表容量——卡上的表项空间是有限的，超了就会回落到软件路径，性能出现台阶式下跌，而且默认情况下你不会收到任何告警。这个坑后面还会展开讲。

存储协议卸载。把远端存储访问的协议栈实现在卡上，业务侧看到的就是一块本地盘。主机省掉了协议处理、队列管理、中断处理一整套开销，延迟抖动也会明显变小，因为不再受主机调度影响。这类卸载对卡的本地盘直通能力要求高，选型时必须确认下行端口和存储介质接口。

安全能力卸载。包括批量加解密、密钥隔离存储、证书链校验、内容检测。密钥放在卡上而不是主机内存里，这一点在合规场景里有额外价值——主机被攻破，密钥不一定泄露。加解密引擎的吞吐通常比通用核高一个数量级，TLS 卸载后握手阶段的 CPU 消耗能降下来一大截。

遥测与可观测性卸载。全包捕获、流级统计、带内遥测头插入。这类能力以前靠主机上的抓包工具，代价是高昂的 CPU 和内存带宽开销，生产环境基本不敢常开。卸载到卡上以后可以常开，出了问题直接查历史数据，定位效率提升非常明显。我个人认为这是被低估最严重的一类场景，很多团队买卡只想着转发性能，最后真正天天用的是这个。

3.3 卸载的隐性成本：三个必须提前想清楚的问题

可观测性断层。流量在卡上转了一圈，主机侧的 tcpdump 什么都抓不到。原有的监控体系、告警规则、排障脚本可能全部失效。这个问题必须在项目立项时就规划对策，比如要求卡侧提供镜像口、提供流级统计导出、提供丢包原因计数。没有这些，一次线上故障就能让整个团队对这套方案失去信心。

故障域扩大。多了一层硬件和固件，就多了一层故障可能。固件 bug、表项耗尽、DMA 异常，这些问题的排查工具链和主机侧完全不是一套。团队里必须有人愿意去啃这部分，否则每次出问题都只能等原厂支持，响应时间完全不可控。

升级路径受限。数据面逻辑一旦固化在硬件或者需要重新编译烧录，版本管理就变得很难。生产环境上要支持灰度、要支持回滚、要保证升级不断流。我见过一个项目，因为升级流程没设计好，每次发版都要停机窗口，最后业务方直接拒绝再升级，卡的功能迭代就此停摆。

4. 编程模型的选型与开发流程

真正开始写代码之前，得先想清楚用哪套模型。四套主流选择各有明确的能力边界，混用是常态，但主次必须分清。

4.1 四种编程模型的定位与边界

选型的判断逻辑其实不复杂。你要做的事情如果只是“按规则分流和丢弃”，eBPF 最省事；如果要“改报文内容、加自定义头”，P4 更合适；如果要“在卡上跑一个完整的服务”，那就得用 SDK 那一套。麻烦的是很多真实需求是混合的：转发规则用 P4，统计用 eBPF，控制面用卡上的容器。这时候要优先保证各层之间的接口清晰，别让业务逻辑横跨三层。

4.2 软硬协同的开发流程该怎么组织

一条我验证过、比较顺的流程是这样的：

1. 主机侧先跑通纯软件版本。用 XDP 或者用户态框架把逻辑实现一遍，功能正确、性能基线拿到。这一步的价值在于，你有了一个可对比的参照物，后面硬件版本出问题时能快速判断是逻辑错了还是卸载错了。
2. 把逻辑拆成可卸载部分和不可卸载部分。匹配动作能表达的部分下移，状态管理、复杂分支、外部依赖留在主机侧。拆分的粒度越细，卸载比例越高，但跨层调用也越频繁，要找平衡点。
3. 数据面用 P4 描述，先跑软件模拟器。主流工具链都带软件后端，能在不碰硬件的情况下验证逻辑和表项下发流程。这一步能挡掉大部分低级错误。
4. 小流量灰度上硬件。用一个 VF 或者一条流做灰度，验证表项下发、报文改写、统计计数是否和软件版本一致。
5. 建立双跑对比机制。同一份流量同时走软件路径和硬件路径，比对输出结果。这是发现硬件行为差异最有效的手段，我强烈建议把它做成常态化流程，而不是一次性验证。

提醒：第三步的软件模拟器验证千万别跳。硬件上一次编译烧录动辄几十分钟，加上环境准备，一轮下来小半天就没了；模拟器上改一行跑一次只要几十秒。把逻辑错误挡在模拟器阶段，整体效率差好几倍。

4.3 虚拟交换机硬件卸载的落地要点

这是最常见、也最容易出问题的一个落地场景。核心是把流表从主机软件层下移到硬件，让首包走慢路径、后续包走快路径。

关键配置项如下，各家语法略有差异，但骨架一致：

# 开启硬件卸载模式（需在初始化虚拟交换机时指定） ovs-vsctl set Open_vSwitch . other_config:hw-offload=true # 确认卸载状态 ovs-vsctl get Open_vSwitch . other_config:hw-offload # 查看已下发到硬件的流表 ovs-appctl dpctl/dump-flows -m type=offloaded # 查看仍在软件层的流表（这些是没卸成功的） ovs-appctl dpctl/dump-flows -m type=ovs # 查看硬件表项统计与命中情况 tc -s filter show dev <representor-name> ingress

几个必查的点：

• representor 端口是否齐全。每个 VF 对应一个 representor，缺一个就意味着那个 VF 的流量无法卸载。上线前用ip link数一遍，和 VF 数量对齐。
• 表项容量与老化策略。硬件流表条目数远小于软件流表，长连接多、短连接频繁的场景很容易打满。打满后新流回落到软件路径，表现为性能忽然变差。必须监控硬件表项使用率，并合理设置老化时间。
• 封装格式支持范围。你的隧道类型、VLAN 层数、报文头组合是否在硬件支持列表里，要逐项确认。不支持的组合会静默回落到软件，日志里往往只有一行不起眼的提示。
• 首包路径。卸载只是把后续包变快，首包还是要走主机慢路径。如果业务是大量短连接，每个连接只有一个包，卸载收益接近于零。这一点在做方案评估时必须算进去。

5. 落地实操：从裸机验证到云原生接入

方案定完，进入动手阶段。我习惯把这一段拆成“确认硬件活着”“确认数据面通”“确认业务能接进来”三层，一层不通就不往上走，避免问题叠加。

5.1 上电前后的准备清单

硬件到位之前，先把这些确认掉，能省掉大量来回：

• 服务器 PCIe 插槽的代际与 lane 数，是否满足卡的带宽需求，是否与其他高带宽设备共享通道。
• 机箱风道与供电。高规格卡功耗不低，被动散热的卡对机箱风道要求很严，装进去温度超标会触发降频，性能表现莫名其妙。
• BIOS 侧开关：Above 4G Decoding、Re-Size BAR、IOMMU、ACS，这几项任何一个没开，后面都可能卡住。
• 固件与驱动版本匹配关系。这一条最容易被忽略，版本不匹配导致的诡异问题，往往要折腾好几天才能定位。
• 管理网络的规划。卡上的管理口需要独立的地址规划，带外管理通道要提前打通，否则出了问题连卡都进不去。

5.2 先证明这块卡是活的

不着急配业务，先把最基础的状态确认一遍：

# 确认设备被 PCIe 枚举到 lspci -nn | grep -i ethernet # 查看链路宽度与速率，确认没有降速 lspci -vv -s <bdf> | grep -E "LnkCap|LnkSta" # 确认网口与固件信息 ip link show ethtool -i <ifname> ethtool <ifname> # 查看硬件卸载相关能力位 ethtool -k <ifname> | grep -E "hw-tc-offload|rx-checksumming|tx-checksumming" # 查看 devlink 层面的设备与固件信息 devlink dev show devlink dev info <dev>

LnkSta那一行尤其要看。卡标称 Gen4 x16，实际协商成 Gen4 x8 的情况非常常见——插槽被共享、金手指接触不良、转接卡质量问题都会导致。带宽直接腰斩，而你在操作系统里看不到任何告警。

5.3 三种接入方式：SR-IOV、vDPA 与 virtio 的取舍

把卡接进虚拟化或容器环境，主流三条路。

SR-IOV 的配置核心是两步，开 VF 数量、配 VF 的 MAC 与 VLAN：

# 创建 8 个 VF echo 8 > /sys/class/net/<pf-name>/device/sriov_numxf # 查看 VF 列表 ip link show <pf-name> # 给 VF 设置 MAC（部分平台支持） ip link set <vf-name> address <mac> # 确认 VF 处于启用状态 cat /sys/class/net/<pf-name>/device/sriov_numvfs

vDPA 的思路是把 virtio 的数据面卸载到硬件，控制面还是标准的 virtio 协议，所以虚拟机看到的是标准设备，迁移时控制面可以正常走，数据面重新映射。这个方案在云平台里接受度越来越高，代价是配置链路比 SR-IOV 长一些，需要管理工具链配合。

注意：开 VF 之后，PF 侧的某些能力会受影响，比如 PF 自己可能无法再作为普通网口使用，或者可用的队列数减少。生产环境变更前，先在测试机上验证 PF 和 VF 并存时的行为，别在业务机上试。

5.4 一个最小可行的 XDP 卸载验证

想快速验证卡的可编程数据面是不是真的能用，XDP 卸载是最短的路径。

# 编写一个最简程序：统计入向包数，全部放行 # 保存为 xdp_count.c，编译为对象文件 clang -O2 -g -target bpf -c xdp_count.c -o xdp_count.o # 挂载到网卡，注意指定 xdp 段 ip link set dev <ifname> xdp obj xdp_count.o sec xdp # 查看挂载状态，输出里应能看到 xdp 标记 ip link show <ifname> # 用 bpftool 确认程序是否真的跑在硬件上 bpftool net show

判定是否真的卸载成功，有三个观察点：bpftool net输出的驱动层信息里能看到 offload 标记；主机侧对应队列的软中断计数基本不动；在网卡侧看包计数增长而主机侧 CPU 无感。三个都符合，才算真的卸载了。只有一个符合，大概率还在软件路径上。

这一段最常见的失败原因是驱动不支持 XDP 卸载，或者卡上没有可用的可编程流水线资源。报错往往很含糊，只提示不支持。这时候回到第 4 章的模型选型，换成 P4 路线反而更快。

6. 性能验证：别被平均吞吐骗了

硬件装好、逻辑跑通，接下来是性能验证。这一段是重灾区，我见过太多报告写着“吞吐提升 3 倍”，实际业务跑起来毫无改善，原因是测试方法和真实负载不匹配。

6.1 压测方法论的三个坑

第一个坑：只测大包。前面算过账，1500 字节的包速率只有 64 字节的十八分之一。大包测试跑出漂亮数字，只能说明带宽够，说明不了 CPU 省了多少。真实的微服务负载是小包为主，必须补测 64、128、256 字节三档。

第二个坑：只测单向。单向流量跑满不代表双向能跑满。全双工场景下，PCIe 上行和下行同时占用，卡上内存的读写带宽也翻倍。很多方案单向 90Gbps，双向一跑就掉到 40Gbps 加 40Gbps。

第三个坑：跑流量和跑业务分开测。打流工具产生的流量模式高度规律，五元组集中、包长固定、连接数少，硬件表项轻松装下。真实业务五元组分散、包长混合、连接数巨大，硬件表项很快打满。所以一定要做一次混合流量测试，把连接数拉到预期峰值的 1.5 倍，观察硬件表项使用率和回落软件路径的比例。

我常用的测试矩阵是这样的：包长四档、方向两档、连接数三档，共 24 组，每组跑 5 分钟取稳态数据。这个矩阵跑完大概半天，能覆盖绝大多数生产场景的问题面。

6.2 观测点与指标体系

只看吞吐和延迟是不够的，必须建立分层观测：

• 物理层：链路速率、误码计数、光模块温度与收发光功率。
• PCIe 层：链路宽度与速率、DMA 事务数、完成超时计数。
• 卡侧：流水线利用率、硬件表项使用率、卡上 CPU 占用、板载内存占用、丢包原因分类计数。
• 主机侧：软中断分布、上下文切换次数、大页内存占用、NUMA 跨节点访问计数。
• 业务侧：P99 延迟、超时率、重传率。

其中“硬件表项使用率”和“丢包原因分类计数”这两项，是最容易被漏掉又最有价值的。前者决定了你离性能断崖有多远，后者能直接把故障定位到具体环节，省掉大量抓包猜谜的时间。

6.3 一份可以直接抄的调优清单

# CPU 频率策略调为性能优先（重启失效，需固化） cpupower frequency-set -g performance # 关闭中断合并，降低小包场景的延迟抖动 ethtool -C <ifname> rx-usecs 0 tx-usecs 0 # 增大环形缓冲区，减少突发丢包 ethtool -G <ifname> rx 4096 tx 4096 # 确认大页配置充足 grep HugePages /proc/meminfo # 绑定数据面线程到固定核，避开系统中断集中的核 taskset -c 8-15 <your-app> # 关闭网卡的流量控制，避免头部阻塞放大 ethtool -A <ifname> rx off tx off

调优的先后顺序比参数本身更重要。我的习惯是先做绑核和 NUMA 亲和，再做中断与队列映射，最后才动缓冲区和合并参数。顺序反了，前面调的参数会被后面的改变推翻，白忙一场。

7. 常见问题与排查速查

这一段是踩坑记录，按现象整理，方便对着查。

7.1 问题速查表

7.2 几个用真金白银换来的教训

教训一：硬件表项容量必须在方案评审阶段就写进非功能需求。我参与过一个项目，功能全部验收通过，压测也过了，上线两周后随着连接数爬升，硬件表项打满，性能断崖式下跌，业务方直接判定方案不可用。根因是当初没人把表项容量当回事，只测了稳态吞吐。补监控、调老化时间、分流策略，前后折腾了一个多月。

教训二：卸载比例要作为一级指标持续监控。“卸载了多少”比“卸载后多快”更重要。比例从 95% 掉到 60%，性能可能只掉 10%，你未必能感知到，但余量已经没了。把这个比例做成看板，比什么都管用。

教训三：一定要保留一条纯软件回退路径。不管硬件方案多成熟，都要能在半小时内切回软件路径。这条路径要定期演练，别等真出事的时候才发现配置早就失效了。我见过最惊险的一次，卡侧固件异常，回退脚本因为一次内核升级失效了，最后是靠手工改配置撑过去的。

教训四：别把卡上跑的东西当成黑盒。卡上是个小型 Linux 环境，有日志、有进程、有资源限制。把它纳入常规运维体系，配好日志采集、配好监控告警、配好资源水位线，能提前发现大部分隐患。很多团队把它当网卡用，出了事才发现连登录方式都没配。

我在实际项目里的体会是，这类设备真正的价值不在于峰值性能，而在于把基础设施的复杂度从主机侧挪走之后，业务团队和平台团队之间的责任边界变清晰了。主机侧的资源争抢少了，性能波动小了，排障时的干扰因素也少了。至于具体选哪条技术路线，还是回到那四个问题：要不要通用核、要不要独立内存、要不要多 PCIe 功能、控制面能不能在卡上闭环。答案确定之后，剩下的架构、编程模型、卸载边界，都是顺着推下来的结果。