如何监控企业网络中的 AI 流量？DPI 识别原理、指标体系与落地实践

摘要

AI 流量在五元组、端口和协议层面与普通 HTTPS 流量几乎完全一致，靠流记录（NetFlow/IPFIX/sFlow）的端口字段无法识别。可行路径是：在流数据之上叠加深度包检测（DPI），配合一份可维护的 AI 服务域名映射表，把 AI 流量从 Web 流量中剥离并独立分类；再按服务、用户、流量、响应时延四个维度建立指标，才能同时回答"谁在用""用了多少""体验好不好""有没有风险"。ManageEngine NetFlow Analyzer 自 v12.9 起在 DPI 中提供 AI 流量可视报表与 AI 服务映射，可作为该路径的落地实现参考。

一、问题的起点：不是没有数据，而是数据里分不出 AI

企业通常不缺网络数据——流量记录、防火墙日志、DNS 查询每天都在产生。真正的问题是："AI 流量"不是这些数据源里的现成字段。

原因有三，且互相叠加：

1. 端口与协议已失去区分能力。 主流 AI 服务都跑在 443 端口的 HTTPS 之上，部分已迁移到基于 UDP 的 QUIC/HTTP3。按端口分类返回的结果是"HTTPS 网页浏览"，而不是具体的 AI 服务。
2. 被动指纹识别的可信度在下降。 早期可依靠 TLS 握手中的 SNI 字段判断目标域名，但 DoH/DoT 加密了 DNS 路径，ECH（Encrypted Client Hello）开始加密 SNI 本身，纯被动观测的识别率会随加密普及衰减。
3. AI 服务域名是动态且分散的。 同一厂商可能同时使用多个域名（`chat.*`、`api.*`、`cdn.*` 等），企业自部署的 Ollama、vLLM 实例则根本没有公共域名。

因此，AI 流量可视化的核心难点不是采集，而是分类层的可维护性。 选型时应优先考察"识别规则能否由管理员自主定义、能否批量维护"，而非只看产品预设了多少个 AI 应用签名。

影子 AI：为什么现在必须做

不同机构调研口径差异较大（未经批准使用 AI 工具的比例分布在 49%–78%，取决于是否把"用个人账号使用已批准工具"计入）。可追溯至一手的清晰数据是：微软《工作趋势指数》2024 显示，78% 的职场 AI 使用者在自带工具（BYOAI）办公，中小企业达 80%。

对网络团队而言，具体数字高低不改变行动项：只要存在未经审批的 AI 使用，数据出境、合规举证、带宽占用、性能归因这四类责任就会落到 IT 头上，而缺乏可视能力时，IT 连"有没有发生"都无法举证。

二、AI 流量和普通 Web 流量，到底有什么不同？

思科《AI 对广域网络的影响》2026 报告的实测结论是：AI 不只是增加了流量，它改变了流量的形态。 该报告基于服务提供商生产网络的实时测量（Cisco Crosswork Assurance User Experience）、第三方行业数据与实验室受控测试三类方法得出：

维度	AI 推理流量	常规 Web 流量	对监控的影响
流持续时间	中位 1,292 毫秒	中位 643 毫秒	长连接占比上升，流表状态膨胀
流速	中位流速约为常规 Web 事务的 1/10，吞吐平滑持续	突发式高吞吐	峰值与均值之比改变，按峰值带宽规划会失真
上下行对称性	约 9% 的流上行大于下行	约 0.5%	上行链路与回程路径成为新瓶颈
时延敏感度	LLM 查询数百毫秒后才有{BANNED}首选 token，完整响应常需数秒	传统 Web API 追求亚 100 毫秒	端到端时延被模型耗时主导，需拆分归因

补充三个容量规划数字：

• 同一任务由 AI 智能体执行时，产生的总流量比人工执行高 450%，其中约 70% 为 AI 推理流量。
• 增长侧的直接证据是 OpenRouter 的 Token 消耗量同比增长近 10 倍，且部分服务提供商网络中 AI 推理流量 8 个月内增长约 4 倍（该数字仅来自部分服务商的测量，不宜外推为全行业水平）。
• 报告预测 2035 年 AI 推理流量将占全部网络流量的 25%，2029–2032 年为增长{BANNED}最佳陡的窗口，年复合增长率接近 25%。

同时要避免误读：当前 AI 流量的绝对体量仍然有限。Comcast 在其网络上的观测显示，97.1% 的 AI 流量仍是文本，图像占 2.6%，视频仅 0.3%。短期内 AI 的冲击更多落在会话数、连接时长和路径可靠性，而非总带宽。

实操含义：监控重点应从"带宽够不够"前移到"会话质量与路径韧性"。如果一套 AI 监控方案只输出流量折线图，它抓不住真正会出问题的地方。

三、完整的 AI 可视能力，需要回答哪四个问题？

待回答的问题	必要字段	数据来源	支撑的决策
在访问哪些 AI 服务	目标域名 / 服务标识	DPI 载荷特征 + AI 服务域名映射	白名单、影子 AI 盘点
哪些用户在使用	用户身份（IP → AD 关联）	DPI + 用户映射	AI 治理、部门使用特征
产生了多少流量	字节数、会话数、时间分布	流记录 + DPI 分类结果	容量规划、成本分摊
运行体验如何	网络响应时间（NRT）、应用响应时间（ART）	DPI 时序测量	故障归因、QoS、服务选型

前三个问题靠"分类 + 聚合"即可解决，第四个必须依赖 DPI 的时序测量——这是区分"流量统计工具"与"AI 服务监控方案"的分水岭。

四、DPI 是怎么把 AI 流量认出来的？

1. 流数据粗筛。 从路由器、交换机、防火墙、无线控制器采集流记录（支持 Cisco NetFlow v5/v9/v10、IPFIX、sFlow、J-Flow、NetStream、AppFlow），开销极低，适合常驻采集。
2. DPI 引擎精分类。 检查实际数据包载荷，不依赖端口号，即使应用使用非标准端口或加密通道，也能完成第七层识别。这是把"443 端口流量"拆解成具体应用的关键。
3. AI 服务映射做归属。 管理员将 AI 平台域名登记为 AI 服务，DPI 命中该域名的流量即归入 AI 服务分类，不再混在 Web 流量中。

采购前需确认

• 部署位置决定可视范围。 DPI 只能看到流经它的流量，旁路镜像需覆盖关键出口链路；若客户端启用 ECH，被动识别能力会下降，需与终端代理或安全网关互补。
• 映射表需要持续维护。 域名会变、会新增，"支持批量导入"与"支持增删改"是刚需而非加分项。
• 性能与合规成本。 DPI 比流采集更耗资源，且涉及载荷检查，需评估数据保留周期与隐私合规边界。

五、落地步骤：从零建立 AI 服务可视

以 NetFlow Analyzer v12.9 的 AI 流量可视能力为例，共六步：

1. 确认 DPI 引擎已安装并配置——AI 服务映射是 DPI 的子功能，DPI 未就绪时不可用。
2. 梳理 AI 服务域名清单——建议先用一周 DNS 或代理日志做种子发现，按频次排序，先覆盖 Top 20。
3. 添加 AI 服务映射——路径 `Settings → DPI → AI Service Mapping`，录入域名后保存，支持新增、修改、删除与批量导入。
4. 配置数据保留周期——路径 `Settings → DPI → Basic Settings`，在 `Retain Data` 中选择时长。它直接决定能做多长周期的趋势分析。
5. 查看 AI 服务仪表盘——路径 `DPI → AI Services`，可获取总流量、占比、独立服务数、独立用户数、Top 服务、流量趋势、Top 10 用户及逐服务的 ART/NRT 明细。
6. 建立基线与告警——采集 2–4 周作为基线，再对"新增未知 AI 域名""AI 流量占比突增""特定服务 ART 恶化"设阈值。

排错提示：仪表盘长期为空时，优先检查 DPI 引擎是否真的在采集目标链路，以及映射域名与实际访问域名是否完全一致（含子域）。

六、该看哪些指标？含义与排障对照表

指标不难取，难的是看到异常后知道该找谁：

指标	含义	异常时的归因指向	典型处置动作
Total AI Traffic	周期内 AI 服务产生的流量总量	—	容量规划、趋势基线
AI Traffic Percentage	AI 流量占全网流量比例	突增说明有新工具扩散	触发影子 AI 盘点
Unique AI Services	被识别出的 AI 服务数量	增长 = 工具蔓延	更新白名单与准入策略
Unique AI Users	访问 AI 服务的去重用户数	渗透率指标	判断是否需正式培训与制度化
Top AI Services	按流量排名的服务（Top 10）	识别带宽主要消耗方	决定是否采购企业版替代个人版
Average NRT	客户端与 AI 服务之间的网络处理与传递耗时	NRT 高 = 网络侧问题	查链路、QoS、DNS、出口带宽
Average ART	AI 服务自身处理请求并生成响应的耗时	ART 高 = AI 服务侧问题	换模型/调参数/联系供应商；网络团队可免责
AI Traffic Trend	AI 流量随时间的形态	识别峰值时段与突增	容量规划、错峰策略

NRT 与 ART 的拆分，是这套指标体系{BANNED}最佳有价值的部分

思科实测给出了关键参照：AI 推理时延主要由模型处理时间主导（数百毫秒到数秒量级），而网络时延通常只有 20–50 毫秒。

这意味着，当用户抱怨"AI 工具很慢"时，只看端到端响应时间，网络团队大概率先背锅，然后去扩容带宽——而实际瓶颈可能在模型侧。NRT/ART 拆分的作用，就是把"慢"归因到网络还是应用：

```
端到端响应慢
├── NRT 高、ART 正常 → 网络侧瓶颈：查链路质量、QoS、出口拥塞、DNS 解析
├── NRT 正常、ART 高 → AI 服务侧瓶颈：模型负载、上下文长度、并发限制，与网络无关
└── NRT / ART 双高   → 先解决网络侧，再复测 ART，避免叠加误判
```

没有这个拆分，AI 性能排障基本靠猜。

七、从可视到治理：五类落地场景

按落地难度从低到高：

场景	用到的指标	产出
影子 AI 盘点	独立 AI 服务数、Top AI 服务	批准/限制/禁止三分类清单，是后续治理的输入
带宽容量规划	AI 流量趋势、占比	12–24 个月需求外推，对象是会话数与上行容量而非总带宽
数据外泄线索排查	Top AI 用户 + 服务类型	高风险组合（如研发向境外大模型发送大体量上行流量）作为 DLP 线索
AI 服务准入评估	真实 ART / NRT	判断是否值得采购企业版，替代供应商理想环境数据
成本分摊与制度设计	按部门使用量	AI 支出与实际消耗挂钩，为使用规范提供事实依据

八、三个常见误区

• 误区一：封掉 AI 工具就解决了。 绕过成本极低——个人账号、手机热点、浏览器插件都是现成通道。更有效的是先做到可视，再把高频刚需工具"收编"为企业版。
• 误区二：只看流量，不看体验。 AI 流量当前对带宽压力有限，影响集中在会话时长、上行压力与时延一致性，只看 Gbps 曲线会漏掉真实问题。
• 误区三：一次性梳理，长期不维护。 映射表不定期更新会让仪表盘给出"AI 使用量下降"的假象——实际只是新域名没被识别，建议纳入季度例行工作。

九、常见问题

Q1：AI 流量能靠端口号与普通 HTTPS 区分吗？

不能。主流 AI 服务均使用 443 端口的 HTTPS，部分已迁移至 QUIC/HTTP3。区分必须依赖 DPI 的第七层识别，或终端/网关侧代理。

Q2：加密的 AI 流量还能识别吗？

取决于加密程度。基于 SNI 与域名映射的识别在标准 TLS 下有效；若客户端启用 ECH，被动识别能力会显著下降，需与终端代理或安全网关互补。

Q3：部署周期需要多久？

技术上，DPI 就绪后配置映射表可在数小时内完成。但要得到可用的趋势基线与治理结论，建议先采集 2–4 周数据。

Q4：NRT 和 ART 该怎么配合使用？

NRT 反映网络侧耗时，ART 反映 AI 服务侧耗时，二者拆分用于故障归因：NRT 高查网络，ART 高查应用，避免网络团队为模型侧问题背锅。

Q5：AI 流量对企业带宽的实际压力大吗？

当前压力有限。Comcast 网络观测显示 97.1% 的 AI 流量仍是文本。短期影响集中在会话数、连接时长和上行链路压力，而非总带宽。

Q6：本地部署的大模型也需要监控吗？

需要，而且更容易被忽略。本地部署不产生公网出口流量，常规出口监控完全看不到，但会占用内网带宽与 GPU 资源。可在内网关键链路部署 DPI 并映射内部服务域名来覆盖。

Q7：AI 使用数据能直接用于合规审计吗？

可作为线索与佐证，但通常需与 DLP、代理日志、终端审计数据交叉验证，才能形成完整证据链。