没想到：WA7000系列AP改胖后，居然比瘦模式性能还要好？

WA7000‑Wi‑Fi7：FIT 本地转发性能低于 Cloud 胖模式分析
测试条件严格：同样硬件、有线 10G 链路、空口无干扰、射频参数完全一致，关闭漫游测量；FIT 本地转发 iperf3 反向打流 1000‑1300Mbps；Cloud 胖模式 1300‑1800Mbps，多款 WA7xxx 现象复现。
虽然配置了client forwarding‑location ap（本地转发，业务流量不走 AC），但 FIT 与 Cloud 固件内核、报文处理路径仍然存在差异，不是简单 “业务流量不过 AC 就性能完全一致”。
1、核心根源（即使本地转发，FIT 仍然存在额外开销）
1）CAPWAP 控制隧道持续占用 AP 资源
FIT 模式下，无论业务是否本地转发，AP 始终维持 CAPWAP 控制隧道：终端上下线、密钥同步、射频统计、事件上报、VAP 表项同步、K/V 键值同步持续占用 AP CPU / 内存。高频的终端状态上报、统计采集，在 Wi‑Fi7 高吞吐打流场景下，会抢占 AP 报文调度资源，限制最大转发吞吐。
Cloud 模式没有 CAPWAP 控制隧道，不存在这部分持续交互开销，全部算力留给无线报文处理。
2）FIT 固件与 Cloud 固件不是同一套镜像
WA7000 系列 FIT 镜像、Cloud 镜像为两套不同固件：
Cloud 镜像：为独立转发做了优化，桥接 / 报文调度路径更短；
FIT 镜像：需要适配 AC 管控框架，即使本地转发，报文需要经过一层 FIT 适配层做表项同步、事件埋点、统计计数，带来微小但可测量的吞吐损耗；Wi‑Fi7 160MHz 高带宽场景下该差异会被放大。
注意：不是集中转发，本地转发业务报文不封装 CAPWAP 数据隧道，但是控制面的埋点、统计、上报逻辑依然生效。
3）WPA3‑PMF 场景密钥处理差异
测试启用wpa3 personal optional + pmf optional。
Cloud 模式：密钥校验、重放保护全部在 AP 本地完整闭环；
FIT 模式：部分安全状态、PMF 相关状态需要同步至 AC，高吞吐下增加中断与任务调度开销。
4）WX2540X‑LI 对 AP 的持续遥测推送
AC 默认开启 AP 的大量统计、信道测量、终端信息采集。即便关闭漫游，AC 仍然周期性下发测量任务，AP 射频模块会被打断；Cloud 模式没有控制器下发测量任务。
2、为什么有线侧链路完全没问题，无线打流看出差距
你的拓扑：AC 万兆口一边接 AP，一边接 iperf3 服务器。
虽然业务流量不经过 AC，但是FIT AP 自身内部处理路径多一层管控适配层，瓶颈点在AP 内部软件报文处理，不在外部有线带宽。
空口协商速率很高时，软件路径的微小开销直接限制 iperf 的最大可达吞吐。
3、现场可做的验证调优（FIT 模式下尽量缩小和 Cloud 差距）
AC 侧优化
bash
# 关闭非必要的射频测量、终端遥测（测试环境）
wlan global‑configuration
undo radio‑measure enable
undo station‑information report enable
# 关闭不必要的终端统计上报
wlan ap‑profile default
undo statistics‑report enable
关闭后再做 iperf3 对比测试，吞吐会有一定提升。
注意：生产环境不建议长期关闭终端上报，会影响运维、故障排查，仅用于性能对标测试。
AP 侧看资源
FIT 模式打流时登录 AP（Console）查看 AP CPU：
bash
display cpu‑usage
display memory
高吞吐下 FIT 模式 CPU 更容易冲高；Cloud 模式同等打流压力 CPU 占用更低。
4、边界说明
差异主要体现在单终端极限打流（iperf 大带宽）；多用户并发、普通业务浏览，二者差距会被抹平，日常业务感知不明显。
Cloud 胖模式性能上限高，但缺失企业 AC 带来的跨 AP802.11r 快速漫游、批量管理、射频全局调优、终端可视化运维能力。
WX2540X‑LI 属于中端 LI 款 AC，对 Wi‑Fi7 高性能 AP 管控，控制面的交互开销会比高端 AC 更明显。