出口只跑 30%，为什么全公司的 AI 还在卡？
全公司都在说 AI 工具卡。
你上去看了一眼：
ping 是通的，出口带宽只跑了 30%，设备也没明显告警。
这时候你怎么回复？
如果你的答案还是：
“网络没问题。”
那大概率要翻车。
这其实已经是很多公司网工面试里的新题了。
它考的不是你会不会训练模型，而是你有没有真正的排障体系。
因为 AI 工具慢，不一定慢在"通不通"。
它可能慢在 DNS、代理、SSL 解密、DLP、SASE、上行、会话表、QUIC、MTU，也可能慢在模型排队、API 网关或限流策略。
所以，排 AI 慢，第一句话不能是"我先 ping 一下"。
而应该是：
我先把"慢"拆开。
01
PART
先分清是哪一种慢
用户说"AI 很慢"，这句话太粗了。
你不能直接进设备敲命令。
要先问清楚：
到底是哪一种慢？
简单分一下，至少有四种。
| 现象 | 优先方向 |
|---|---|
| 页面打开慢 | DNS、TCP/TLS、代理、证书、安全网关 |
| 开始回答慢 | 首 token、API 网关、模型排队、代理处理 |
| 回答中途卡 | 丢包重传、代理缓冲、SSE 处理、会话老化 |
| 上传或长文本慢 | 上行、DLP、文件扫描、MTU/MSS、隧道开销 |
完整的归因表在文末，一共 12 种现象。
下面先展开说这四种。
页面打开慢
比如页面打开很慢、登录慢、进入工作台慢。
这类问题更像传统 Web 访问慢，优先看：
•DNS解析；
•TCP建连；
•TLS握手；
•代理链路；
•SASE节点；
•证书检查；
•安全网关拦截。
这时候用户还没真正调用模型。
别一上来就怀疑模型慢。
开始回答慢
页面能打开，问题也能提交。
但点了发送以后，半天没有第一个字出来。
这类问题要看：
•首 token 时间；
•API 网关；
•模型排队；
•代理处理时间；
•SSL 解密；
•DLP 检测；
•限流策略。
这里要注意：
用户看到的是"AI 没反应"。
但真实情况可能是代理在处理，也可能是模型在排队，还可能是 API 被限流。
回答中途卡
AI 已经开始输出，但一会儿吐几个字，一会儿停住。
这类问题最容易被误判。
因为很多 AI 应用不是一次性返回完整页面，而是流式输出。
常见是 SSE：
如果中间代理开启缓冲，或者安全设备要还原响应体再扫描，用户看到的就是：
憋一大段，停一下，再憋一大段。
模型侧可能一直在输出。
但用户侧就是卡。
所以回答中途卡，要重点看：
•丢包重传；
•抖动；
•代理缓冲；
•SSE 流式响应；
•防火墙会话老化；
•DLP / ICAP 内容检查。
这里要区分一下：中途一顿一顿地卡，优先怀疑代理缓冲和内容还原；中途直接断掉，优先怀疑防火墙或代理的空闲超时。
推理模型长思考那段时间链路上没有数据流动，撞上空闲超时会话就被回收，用户看到的是回答断在一半。
比如 nginx 类代理，proxy_buffering 开着的时候，是缓冲区凑够一批才往客户端下发，用户看到的就是一顿一顿。
对流式接口，要么关掉 proxy_buffering，要么让后端返回 X-Accel-Buffering: no。
而真正会憋到最后一次性吐出来的，是做 ICAP 内容还原、必须收完整响应体才能扫描的安全设备——这两种机制表现不一样，定位时要分开看。
普通网页影响不大。
但 AI 流式输出就会直接变成"等一段，吐一段"。
上传慢
短问题正常。
一上传文件、日志、截图、代码、合同、长文本，就开始慢。
这类问题重点看：
•上行链路；
•DLP 检测；
•文件扫描；
•代理队列；
•MTU / MSS；
•VPN、SD-WAN、SASE 隧道开销。
很多网工只盯下行。
但 AI 场景里，上行越来越重要。
用户不是只打开网页，还会上传大量上下文。
短 prompt 正常，长 prompt 慢，别只看出口下行。
02
PART
AI 访问路径要先画出来
排 AI 工具慢，不能只看"终端到公网"。
你要先画路径。
一条企业 AI 访问路径，可能是这样的：
主链路：终端 → 有线/无线 → 分支出口 → VPN / SD-WAN / SASE → 防火墙 → 代理 / SSL 检查 → DLP / CASB → 公网出口 → AI 应用入口 → API 网关 → 模型服务
旁路（在建连之前就已经发生）：终端 → 内网 DNS → 转发器 / 递归 → 公网权威
DNS 要单独拎出来看，它不在数据路径上，但它决定了你后面所有流量往哪走。
这里面每一层都可能慢。
所以面试时你可以这样说：
我不会先判断是不是网络问题，我会先把 AI 访问路径画出来。路径画不清，后面所有排障都是猜。
这句话很加分。
因为它说明你不是靠感觉排障。
你是按路径排障。
03
PART
出口没满，不代表网络没问题
这是新人最容易误判的地方。
一看出口带宽只跑了 30%，就说：
“网络没问题。”
不严谨。
原因至少有三个。
带宽图看到的是平均值
很多监控图是 1 分钟、5 分钟平均。
但真实网络里会有微突发。
可能几十毫秒内，流量已经把上联队列打满并丢包。
但在 Zabbix、MRTG 图上，还是显示 30%。
所以不要只看带宽曲线。
还要看：
•接口的 output drops，也就是队列丢包；
•各个 QoS 队列各自的丢包计数；
•buffer 是否打满。
带宽图看趋势，队列和丢包看体验。
AI 流量不一定吃带宽，但吃状态资源
AI 推理类流量可能不大，但连接持续时间更长。
尤其是 Agent 类任务。
用户只是点了一下"执行任务"。
设备侧看到的可能是：
•多轮模型调用；
•多个域名访问；
•多条长连接；
•多次工具调用；
•多次知识库检索。
这时候压力不一定体现在带宽上，而体现在：
•防火墙会话表；
•NAT 端口资源；
•新建连接速率；
•代理连接数；
•SSL 解密资源；
•安全网关 CPU / 内存。
所以要记住一句话：
出口没满，不等于状态不紧。
限流也会看起来像网络慢
企业用 AI 平台，经常是共用一个 org key 或一组 API token。
限流一般看：
•RPM，每分钟请求数；
•TPM，每分钟 token 数；
•并发数；
•组织级额度。
如果某个 Agent 跑飞了，全公司都可能一起变慢。
现象像出口拥塞。
但网工查半天网络，最后发现是 API 返回 429。
当然，429 不一定都是服务商限流。
也可能是企业自己的 API 网关、WAF 或代理策略在限速。
所以看到 429，不要先怪网络，也不要直接甩给模型。
要看限流发生在哪一层。
04
PART
做对比，比盲查快
AI 工具慢，至少做这几组对比。
总部 vs 分支
总部快，分支慢，优先查：
•分支出口；
•SASE POP；
•SD-WAN 路径；
•VPN 隧道；
•分支 DNS。
这里有个坑，很多人会踩：
DNS 调度和 Anycast，是两回事。
AI 服务大多在 CDN 后面，但"就近接入"有两种完全不同的实现方式，对应的排查动作也完全不同。
一种是 DNS 调度，比如 GSLB、延迟路由这类。不同地点解析出来的 IP 本身就不一样。这时候如果内网 DNS 转发器不带 EDNS Client Subnet，也就是 ECS，权威侧只看得到递归出口的 IP，分支用户就会被调度到总部附近的节点。
排查动作是：对比不同分支解析出来的 IP，确认递归出口在哪里，有没有带 ECS。
另一种是 Anycast。所有人解析到的是同一个 IP，去哪个 POP 完全由你出口的 BGP 路径决定。这时候 ECS 一点用都没有，DNS 查一辈子也查不出问题。
排查动作是：看分支流量是本地直出，还是被回传到总部出口——如果是回传，那它就是从总部的位置去选 POP 的。
怎么区分这两种？
不同地点各 dig 一次。
解析出来的 IP 不一样，偏向 DNS 调度；一样，偏向 Anycast。
但这只是初步判断——混合调度的厂商两地也可能返回同一个 IP，缓存和 TTL 还会干扰，所以要用各自的本地递归多测几次，再确认那个 IP 所在前缀是不是 anycast 宣告，才能下结论。
另外提醒一句：对 Anycast 地址做 ping 和 traceroute，参考意义有限。
公司网络 vs 手机热点
手机热点快，公司网络慢，优先查：
•企业出口；
•代理；
•DNS；
•SASE；
•SSL 检查；
•DLP / CASB。
因为手机热点基本绕开了企业安全链路。但前提是终端没有装 always-on VPN 或 MDM 强制隧道——如果装了，换热点照样被拉回企业出口，这组对比就不成立，要先确认隧道状态。
但注意，不要一上来就全局关闭安全策略。
可以用测试账号、测试终端、测试域名做小范围验证。
专业排障，要有边界。
短 prompt vs 长 prompt
短问题快，长问题慢，优先查：
•上行；
•DLP；
•代理队列；
•MTU / MSS；
•模型处理时间。
短 prompt 正常，长 prompt 慢，说明问题很可能出在请求体变大以后。
不是"通不通"的问题。
浏览器 vs 客户端
浏览器慢，客户端正常，或者反过来，优先查：
•PAC 代理；
•证书链；
•浏览器插件；
•QUIC 和 HTTP/3；
•客户端是否走了不同出口。
有些桌面客户端是 Electron 类应用，它内部其实有两套网络栈：渲染进程走 Chromium，会读系统证书库；主进程用 Node 发出的请求（axios、undici、node-fetch 这些）走的是 Node 编译进去的内置 CA 列表，不读操作系统信任库。
所以公司做 SSL 解密时，企业 CA 装进系统后浏览器正常了，客户端却还在报证书错误。这类情况要给客户端单独注入信任链，Node 侧的关键词是 NODE_EXTRA_CA_CERTS，Python 侧类似的是 REQUESTS_CA_BUNDLE 和 SSL_CERT_FILE，Java 侧是 cacerts。
能说到"同一个客户端里有两套证书信任源"这一层，就比只会说"证书链"更进一步了。
05
PART
QUIC 和 MTU，是新麻烦
现在很多 AI 服务可能走 HTTP/3（底层是 QUIC）。
QUIC 常见是 UDP/443。
这会让传统排障更麻烦。
因为过去很多审计、QoS、DPI、应用识别，都是围绕 TCP/HTTPS 做的。
AI 流量如果走 QUIC，可能出现：
•应用识别成 Unknown；
•QoS 没命中；
•安全策略没按预期生效；
•审计日志看不清；
•放行了但体验差。
有些企业会直接封 UDP/443，让浏览器回落到 TCP。
但如果是静默丢弃，Chrome 这类会做 QUIC / TCP 竞速的浏览器影响有限，通常只多几百毫秒；被拖住的是不做竞速的原生客户端和 SDK，它们可能要等 QUIC 探测超时才切 TCP。
所以要封就用 ICMP port unreachable 明确拒绝，别静默 drop——静默 drop 的结果是你以为更稳，部分客户端体验反而更差。
还有 MTU / MSS。
VPN、SD-WAN、SASE 都会带隧道开销。
如果 MTU 处理不好，就会出现：
•短问题正常；
•大文件上传慢；
•长 prompt 卡住；
•回答到一半断；
•某些分支异常。
这类故障很烦，因为不是完全不通。
而是：
小包通，大包难受。
TCP 可以通过 MSS clamping 缓解。
但 QUIC 跑在 UDP 上，不吃 TCP 的 MSS clamping。
它是从 1200 字节这个保守值起步，靠 DPLPMTUD 主动发探测包往上试——好处是不依赖 ICMP，不怕 ICMP 黑洞；代价是如果实现没做探测，或者探测包在隧道里过不去，它就一直用小包跑。
表现就是上传大文件慢、长 prompt 慢，但你在任何地方都抓不到丢包。
所以同样的 MTU 问题，在 TCP 和 QUIC 上不仅表现不同，排查手段也不同：TCP 看 MSS clamping 有没有生效，QUIC 要看隧道路径上大包能不能过。
能说到这一层，基本就不是背模板了。
06
PART
用命令拆耗时，但别乱测 TTFT
排障最后还是要靠数据。
不要只说：
“我感觉是网络慢。”
可以先用 curl 拆一下访问耗时：
（注意：curl 默认不走 HTTP/3，所以它测的是 TCP 路径。要复现浏览器的 QUIC 体验，得用支持 HTTP/3 的 curl 加 --http3，或者直接用 chrome://net-export 抓 netlog 看浏览器真实走了哪条。）
这条命令能看：
| 指标 | 说明 |
|---|---|
| time_namelookup | DNS 解析耗时 |
| time_connect | TCP 建连耗时 |
| time_appconnect | TLS 握手耗时 |
| time_starttransfer | 首字节时间 |
| time_total | 总耗时 |
|
|
|
最后那个 code 顺带就能看到状态码。文末归因表里说的 429 限流、5xx 异常，不用再单独抓一次包，这条命令跑一下就知道了。
注意：这只是测页面或网关访问链路，不是测首 token。
因为它只是一个 GET 请求，没有触发模型推理，所以 TTFB 再好看，也不代表模型响应快。
真正的首 token 时间，不建议靠 curl 去估。
一是请求体上传的耗时会被算进去，长 prompt 和带附件的场景天然偏大；
二是有些服务端会先返回响应头、甚至先发一个 keepalive 注释行，然后才开始推理，这时候首字节时间反而偏小。
要准确拿首 token，还是要看应用日志、SDK 埋点或者 API 网关的日志。
curl 在这里的定位很明确：把 DNS、TCP、TLS、首字节这几段耗时拆开，判断问题出在建连阶段还是服务端。剩下的交给日志。
这才叫用数据排障。
07
PART
快速归因表
这张表建议收藏。
| 现象 | 优先排查 |
|---|---|
| 页面打开慢 | DNS、代理、证书、安全网关 |
| 开始回答慢 | 首 token、API 网关、模型排队、代理处理 |
| 回答中途卡 | 丢包、重传、代理缓冲、会话老化 |
| 短问题快，长问题慢 | 上行、DLP、MTU/MSS、模型处理 |
| 上传文件慢 | 上行、文件扫描、CASB、代理队列 |
| 总部快，分支慢 | 分支出口、SASE、DNS 调度 / ECS / Anycast 回传 |
| 热点快，公司慢 | 企业出口、代理、SSL 检查、安全策略 |
| 出口没满但都慢 | 微突发、队列丢包、会话表、NAT |
| 浏览器和客户端不一致 | PAC、证书库、QUIC、代理路径 |
| 返回 429 | 服务商、API 网关、WAF 或代理限流 |
| 返回 5xx | 平台侧或服务商侧 |
| 小包正常，大包异常 | MTU/MSS、隧道、分片 |
08
PART
面试时可以这样回答
如果面试官问：
ping 通、出口没满，但 AI 工具还是慢，你怎么排？
你可以这样回答：
我不会直接判断网络没问题。
我会先把"慢"拆开：是页面打开慢、开始回答慢、回答中途卡，还是上传文件慢。
然后画出 AI 访问路径，看它是否经过 DNS、代理、防火墙、SASE、VPN、SSL 检查、DLP、CASB、API 网关和模型服务。
接着做对比：总部和分支、公司网络和手机热点、短 prompt 和长 prompt、浏览器和客户端。
如果偏网络侧，我会从上行、丢包重传和微突发看起，再查会话表、NAT、代理队列和 SSL 解密这些状态资源，最后确认 QUIC 识别、MTU/MSS、DNS 调度方式和安全策略命中。
如果是流式输出卡顿，我会重点看 SSE 是否被代理缓冲，安全设备是否还原响应体，防火墙或代理是否存在空闲超时。
如果网络路径正常，再结合首 token 时间、API 错误码、429 限流、5xx 异常、模型区域和服务商状态，判断是不是模型侧或应用侧问题。
我的原则是：
ping 通只能证明连通。
出口没满不能证明体验正常。
AI 业务排障，要看路径、状态、上行、识别、队列和端到端体验。
09
PART
最后
AI 时代，网工排障会变。
用户要的不是"网络是通的"。
用户要的是 AI 能稳定回答，文件能正常上传，Agent 能顺利执行，总部和分支体验一致。
所以以后再遇到 AI 工具卡，不能只拿 ping 和出口带宽当结论。
你要能回答清楚：
慢到底慢在哪一段？
SPOTO 思博网络是全球 IT 人才在线教育品牌，深耕 ICT 职业教育二十余年。华为授权培训合作伙伴。课程涵盖思科、华为认证及云计算、Linux、PMP、软考、CISP 等方向，已服务全球 152 个国家和地区的 55 万余名学员。
学习改变命运，知识成就未来。如果你想在 IT 路上走得更远，SPOTO 思博愿做你的同行者。想在 IT 领域进阶，欢迎与我们同行。