上周帮一个朋友排查他们大模型在线服务的线上问题情况很典型晚高峰GPU集群整体负载只有六成但用户普遍反馈回答出来得忽快忽慢有的请求卡了好几秒才开始吐字。翻了一圈根子居然不在模型推理代码而在入口流量这层——他们还沿用着普通Web服务的负载均衡策略把大模型推理请求当成普通短连接HTTP来调度。这件事让我想认真聊聊ADC注意这里说的不是嵌入式电路里那个模数转换采样芯片而是应用交付控制器Application Delivery Controller。在ADC 3.0时代F5这类老牌厂商正在重新证明一件事当AI应用部署的复杂度从模型层蔓延到流量层、安全层、运维层时一个能干的交付控制层比多调几次prompt更救急。这篇文章适合正在把大模型推理服务产品化、平台化的架构师、运维和SRE同学。我会从ADC的演进逻辑讲起再把AI应用部署的复杂性拆开揉碎最后落到F5产品线BIG-IP、NGINX、Distributed Cloud的具体打法和可直接抄作业的配置经验上。内容不吹不黑都是我在实际项目里验证过的思路。1. 从1.0到3.0ADC到底在解决什么问题1.1 前两代ADC从四层转发到应用加速在聊ADC 3.0之前得先把前两代的故事说清楚因为很多人的认知还停留在第一代。第一代ADC本质上就是负载均衡器。那是网站和数据库集群大规模普及的年代企业需要把入口流量分发给多台后端服务器。当时的F5 BIG-IP LTM几乎是金字塔尖的存在四层到七层的包处理、连接调度、会话保持把“几台服务器扛不住”变成“几十台服务器一起扛”。这一代解决的核心矛盾是单机性能瓶颈大家比的并发连接数和吞吐量。第二代ADC加上了大量应用优化能力。SSL卸载、HTTP压缩、缓存、TCP优化、连接复用这些功能让ADC从一个单纯的流量分配器变成了应用加速器。加上WAF、访问控制、DNS负载均衡ADC逐渐演变成了企业南北向流量的统一收口点。这一阶段最重要的变化是应用交付不再只是“把流量转出去”而是开始“理解应用在做什么”。比如一个购物订单请求会被感知到需要会话保持一个接口响应时间异常会被健康检查自动识别并把流量摘除。虽然这些逻辑在今天看来很基础但它为ADC从“网络设备”走向“应用语义层”埋下了伏笔。1.2 ADC 3.0从流量负载均衡到推理语义调度到了大模型应用集中上线的这几年“理解应用在做什么”这件事的难度被突然拔高旧范式的短板就暴露出来了。传统Web请求的处理时长是几十毫秒到几百毫秒请求之间相对独立。负载均衡算法看连接数、看CPU使用率基本就能把流量分得差不多。但大模型推理请求完全不是这个脾气一次生成调用可能持续几秒到几十秒响应是流式返回的而且对后端节点的GPU显存、算力余量、队列深度极其敏感。同一个GPU节点上如果同时跑着多个推理任务算力排队会直接导致响应变慢A100上能够承载的并发推理路数跟一张消费级显卡完全不是一个量级大上下文Agent任务和小模型聊天任务占用的显存相差悬殊。这时候调度一个推理请求不仅要看后端节点“活没活”还要看它“适不适合接这个活”——当前还有多少显存余量并发额度还有多少该请求需要的吞吐量能不能满足多轮对话需要保持到同一节点吗这些判断已经超出了传统L4-L7负载均衡的语义范围。ADC 3.0的核心变化我理解是把交付控制的粒度从“单个请求”下沉到“会话和推理上下文”把决策依据从“节点存活状态”扩展到“模型部署拓扑、节点推理负载、业务级路由策略”。它不再只是一个流量管道而是AI应用入口的智能调度中枢。2. 大模型推理服务的流量特征与传统Web服务完全不同2.1 长连接、流式响应与首Token延迟先讲最容易被低估的一点流式响应改变了交付层的基本假设。传统Web后端返回的是一个完整响应体客户端拿到200以后整体渲染性能指标看的是“请求响应时间”。大模型应用里ChatGPT类客户端普遍使用SSE或流式HTTP服务端每生成一个Token就推一个数据块。用户感知的“快”和“慢”核心指标变成了首Token延迟TTFT而不是整体响应耗时。这个差异给应用交付层带来两个很具体的麻烦。第一代理层如果默认开启缓冲比如开源NGINX的proxy_buffering默认是on那么服务端推过来的Token会先在代理层内存里攒着攒到最后一次性发给客户端。用户看到的效果就是“转圈很久然后全文突然出现”首Token延迟被伤得面目全非。从业务角度讲这等于白付了推理费用却给了最差的体验。第二长连接场景下连接空闲、半开、对端异常退出这些状态需要比普通Web更精细的超时管理。默认60秒的代理读超时对于SSE流式接口可能远远不够。一个长上下文Agent任务可能中间停顿几十秒再继续输出是正常的结果被代理层掐断直接504客户端体验瞬间崩塌。我之前接过一个案子模型服务端明明每秒都在输出Token客户端却几乎同时收到全部内容。排查到最后就是接入层NGINX缓冲没关。像这种细节如果还套传统Web入口的那套配置AI应用性能会莫名差一大截。2.2 多模型、多版本、多地域带来的路由维度爆炸第二个复杂性来自路由维度。以前一个业务模块对应一组后端服务路由规则很清晰按URL路径、按Header、按用户地域最多再按权重切分流量做灰度。现在一个AI平台上往往同时运行着多个模型7B的小模型负责轻量Agent对话70B的大模型负责深度推理微调版本和基座版本并行测试同一个模型还可能有多个副本、分多个地域部署。请求进来以后交付层不能只做负载均衡得做语义路由——根据模型名称、用户等级、任务类型、成本预算决定把这个请求送去哪个模型、哪个地域、哪个版本。比如用户选择了“快速模式”网关应该直接把请求路由到小模型的低延迟副本用户在跑一个需要长上下文的批量分析任务那就应该分配显存更充裕的实例某个模型正在灰度新版本流量要按比例切到预览节点。这套逻辑如果用业务代码写死在服务里每次调整都要发版弹性很差。放在应用交付层做通过配置和策略动态更新就能实现“模型在下层随便伸缩路由策略在上层稳定控制”。也正因为这样NGINX这类可编程的代理组件才会在AI网关场景里被大量采用。2.3 安全暴露面扩大从应用漏洞到提示注入与资源滥用第三个复杂性是安全。AI应用暴露的接口跟传统API有个巨大区别请求体不可预测。传统API的入参有明确的JSON SchemaWAF可以针对SQL注入、XSS、路径穿越这些特征做规则检测。大模型应用呢输入是自然语言攻击者直接在prompt里做文章用提示注入诱导模型忽略系统指令通过恶意构造多轮上下文套取系统提示词甚至试图让模型输出内部数据。这些新型攻击在应用交付层没法百分之百识别但至少要把几道基本防线扎牢API密钥严格校验防止未授权调用请求做规模和频率治理防止有人把推理集群当成免费算力矿场进出流量全程审计留痕线上出事故能回溯到具体会话和请求链路。这些已经是API安全和统一策略治理的范畴了开源负载均衡基本给不了必须靠产品化能力补齐。2.4 可观测与运维层面的复杂GPU指标 vs 业务指标最后是运维侧。传统运维看的是CPU、内存、磁盘、网络这四个“地球人指标”。AI推理集群的核心资源是GPU显存、算力利用率、吞吐量、推理排队长度。但有个反直觉的现象GPU利用率高不一定等于任务处理得快很可能只是大批请求在排队计算资源被无效占住。要让交付层真正智能关键是打通业务指标和资源指标。比如这一路推理实例最近五分钟的p95首Token延迟是多少模型对应队列还在堆积吗显存余量够不够接纳新的推理请求只有把这些信息反馈到调度决策里入口流量才谈得上“智能”两个字。否则最多只是把请求轮流丢给后端谁扛得住谁扛扛不住就告警本质上是碰运气。我把传统Web服务和AI推理服务的差异整理了一张表方便理解对比维度传统Web服务AI推理服务响应模型一次完整响应SSE流式、长连接、持续输出关键性能指标响应时间、吞吐量首Token延迟、Token吞吐、GP排队长度后端资源CPU/内存为主GPU显存、算力调度优先路由维度URL、域名、用户分组模型名、版本、任务类型、成本策略安全重点Web漏洞利用、恶意爬虫提示注入、API滥用、密钥管理健康检查逻辑端口存活、页面探活推理可用性、业务延迟、队列深度3. F5产品体系在AI应用交付中的具体打法3.1 BIG-IP把L4-L7能力变成GPU集群的“入口整流器”聊到F5很多人第一反应就是BIG-IP这套招牌产品线在AI场景里依然是入口侧的基础设施底座。BIG-IP LTM的看家本领是四到七层流量管理GPU推理节点前挂一组BIG-IP可以解决好几个实际问题。连接收敛是第一个价值成千上万的客户端连接被收敛成有限几条到后端的连接避免推理服务本身被连接数拖垮SSL/TLS卸载是第二个价值加解密这种纯CPU密集的事交给ADCGPU只干推理正事会话保持是第三个价值多轮对话场景下同一个用户的请求尽量保持到同一节点避免每轮对话都要重新传上下文。BIG-IP还有个长期累积的差异化优势就是iRules和AS3这套可编程机制。举例来说如果业务要求“白名单用户走高端GPU池普通用户走共享池免费用户限制并发”完全可以用iRules或AS3声明式模板写出一套动态调度策略模型上线、下线、切版本时通过配置变更完成而不需要动业务代码。这种灵活性是传统硬件负载均衡设备当年想都不敢想的也是BIG-IP到今天依然没有退役的原因。3.2 NGINX/NGINX Plus最务实的LLM推理网关如果你问一个真正部署过大模型推理服务的人AI入口最现实的接入层是什么十有八九会提到NGINX。NGINX本身就是F5生态的成员开源生态极其成熟几乎所有主流推理框架的官方文档里都能看到把它作为反向代理或推理网关的推荐配置。为什么NGINX适合做LLM推理网关核心原因是它的模型简单灵活HTTP反向代理加可编程配置加丰富模块生态构成了天然的API入口。在大模型推理集群前面NGINX可以承担几件非常具体的事把/v1/models/{model_name}这类请求按模型名解析到对应的上游服务组实现模型级路由按模型维度做全局限流防止单一租户打爆整个推理集群关闭缓冲透传流式响应保证SSE场景的实时性用API Key或JWT做统一鉴权避免每个推理服务重复实现认证逻辑配合Prometheus导出指标对请求量、延迟、错误率做统一观测。NGINX Plus商业版比开源版多出主动健康检查、会话持久化、细粒度监控、JWT校验这些能力在关键生产环节更省心。很多团队担心开源NGINX不够“AI原生”其实在模型路由、鉴权、限流这个粒度上它已经能覆盖大部分需求关键在于配置体系要设计得足够清晰。3.3 Distributed Cloud多云与边缘场景下的统一策略面AI部署越来越多地跨公有云、私有云和边缘节点展开。单一集群内的交付控制做得再好也管不到全局的流量调度。F5的Distributed Cloud平台做的事情是把策略层从单集群里抽出来放进一个统一的控制面。这对AI应用很有现实价值。比如同一套推理API在多个云厂商和本地机房都部署了节点Distributed Cloud可以按地理位置、实时延迟、单位成本把用户路由到最优的推理节点。边缘节点运行轻量模型或做上下文缓存重模型留在中心机房交付层负责这层“远近配合”的策略编排。同时它还能提供全局的Bot防御、API发现和异常流量清洗能力。就我观察到的情况真正把AI服务产品化的公司早晚会碰到多云和边缘场景。一开始图省事把所有推理任务都堆在单一云区一旦业务起来吨位大了想挪都挪不动。提前把统一策略面搭好后面扩地域、加边缘节点时只是加一个接入点的问题而不是重构入口架构的问题。3.4 可编程生态让策略随业务变化而非发版F5真正难被替代的护城河是沉淀了几十年的可编程生态。BIG-IP有iRules LX、AS3声明式API、Terraform providerNGINX有ConfigMap和OpenAPI驱动的配置管理能力。在AI业务策略变化飞快的节奏下“基础设施即代码”几乎是刚需。举个例子上线一个新模型时不需要登录控制台不停点鼠标直接提交一份AS3声明描述“新模型对应哪个节点池、健康检查逻辑是什么、路由权重怎么分”ADC自动完成配置下发。模型回滚时同样通过声明式改配置秒级生效并且所有变更留痕可审计。我在几个项目里体会最深的是AI应用交付方案的复杂度很多时候不是技术难点本身而是变更频率太高。模型一周出两个新版本数据漂移要切流量压测后要调整限流阈值——这些操作如果都靠人工去控制台配置必然出错。可编程交付不是选配是刚需。4. 实施AI应用交付一组可直接抄作业的配置与避坑经验4.1 一个多模型推理网关的最简可用配置基线下面给一份可以拿去做实验的NGINX配置基线模拟“多模型推理网关”的简化场景。假设有两个模型服务qa-model轻量问答模型和reason-model深度推理模型分别跑在不同后端节点组upstream qa_backend { zone qa_backend 64k; server 10.0.1.11:8080 weight3; max_fails3 fail_timeout30s; server 10.0.1.12:8080 weight3; max_fails3 fail_timeout30s; server 10.0.1.13:8080 weight3; max_fails3 fail_timeout30s; keepalive 32; } upstream reason_backend { zone reason_backend 64k; server 10.0.2.11:8080 max_fails3 fail_timeout30s; server 10.0.2.12:8080 max_fails3 fail_timeout30s; keepalive 16; } limit_req_zone $binary_remote_addr zoneauth_limit:10m rate10r/s; limit_req_zone $arg_model zonemodel_limit:10m rate5r/s; server { listen 8443 ssl; http2 on; ssl_certificate /etc/nginx/ssl/tls.crt; ssl_certificate_key /etc/nginx/ssl/tls.key; location /v1/chat/completions { # 关闭响应缓冲保证流式返回 proxy_buffering off; proxy_cache off; proxy_read_timeout 300s; proxy_send_timeout 300s; proxy_http_version 1.1; proxy_set_header Connection ; # 先做全局限流再做模型级限流 limit_req zoneauth_limit burst20 nodelay; limit_req zonemodel_limit burst10 nodelay; # 按客户端选择的模型名路由 if ($arg_model qa) { proxy_pass http://qa_backend; } if ($arg_model reason) { proxy_pass http://reason_backend; } return 404; } }这里要提醒一句上面的路由为了直观用了两个if但生产环境建议改成map变量来解析模型名再配合proxy_pass因为if块内和其他指令组合时限制很多踩坑概率高。模型路由本质是按请求语义分流不适合在upstream内部做权重混合所以不要图省事把两个模型放在同一个upstream里用权重控制那样流控和健康检查都容易乱。4.2 流式响应与超时参数最容易翻车的两个变量用SSE流式接口时翻车率最高的两个变量一个是proxy_buffering一个是超时时间。很多团队直接把NGINX默认配置放到推理服务前线上一测发现客户端半天看不到回复抓包一看服务端明明在推Token客户端却收不到。原因就是代理层缓冲没关Token全攒在NGINX内存里直到响应结束才一次性发给客户端。这个坑几乎每个做推理网关的团队都会踩一遍。提示SSE场景务必设置proxy_buffering off同时记得关闭或绕过对text/event-stream内容的gzip压缩否则数据会被压缩层堵在缓冲区里一样拖垮实时性。超时参数也需要重新设计。默认proxy_read_timeout是60秒普通接口够用但长上下文推理或复杂Agent任务中间可能几十秒都没有有效字节默认超时一到NGINX直接返回504。我建议推理类服务把读写超时统一放宽到300秒以上同时让客户端配合心跳或ping机制而不是靠代理层硬切。连接复用同样重要。OpenAI兼容接口的客户端通常会创建大量并发连接如果upstream没有配置keepalive每次请求都重新做TCP握手和TLS协商高并发下延迟和CPU占用都会明显上升。我在配置里特意加上了proxy_http_version 1.1和proxy_set_header Connection 再配上keepalive 32这一套在压测里能把连接建立开销降掉一大截。4.3 健康检查千万别按普通Web节奏设计第三个高频问题出在健康检查。传统健康检查的逻辑是每3到5秒请求一次/healthz连续失败N次摘除节点恢复了再加回来。AI推理场景直接照搬会出事。原因有两点一是健康检查请求本身也要占推理服务资源特别是有模型依赖的探活接口检查太频繁等于白耗GPU二是推理节点哪怕进程活着、HTTP接口返回200也可能因为GPU排队严重导致服务质量崩坏这时候节点在传统健康检查眼里依然是“健康”的流量继续往里灌用户持续受损。健康检查必须分层来设计存活层面进程活着端口有响应这是最低要求就绪层面模型文件加载完成推理服务能接受请求质量层面最近五分钟p95首Token延迟是否超过阈值请求队列是否在积压容量层面卡上显存余量是否足够接纳新的推理请求。开源NGINX默认只能做到存活层面加被动健康检查max_fails/fail_timeout如果要按业务指标做主动摘除建议使用NGINX Plus或者BIG-IP这类支持自定义主动健康检查的产品。检查频率在推理场景建议放到15秒以上检查接口设计成轻量模型自检而不是发一个完整推理请求。4.4 从限速限流升级到按用户、模型、成本维度治理最后说安全与治理。推理API的滥用问题比普通API严重得多。攻击者或者投机用户写几行脚本就能把内容生成API当免费算力用。传统限流一般按IP或API Key做个简单的每秒请求数限制但在AI场景这个力度远远不够。原因在于请求成本差异巨大。同样的输入长度打给7B模型的成本可能只有70B模型的一个零头。限流不能只限“每秒多少个请求”还要限“每个用户每天消耗的Token总量”和“高级模型调用次数配额”。NGINX Plus可以通过JWT校验解析出用户身份结合Lua脚本或外部授权服务做细粒度的配额控制。我特别强调把治理能力统一放在应用交付层而不是让每个模型服务自己实现。因为推理服务本身要托管各种模型如果每个模型都重复实现鉴权、配额、审计维护成本会成倍上升。统一收敛到入口相当于所有车进小区都在门岗登记才能实现全局管控。5. 选择ADC的几个判断维度与我的落地体会5.1 性能之外更该关注什么选ADC如果只看并发数、吞吐量这些纸面参数在AI时代很容易选错方向。我更建议关注四个维度对流式协议SSE、gRPC的支持是否原生健康检查能否自定义业务逻辑配置体系是否声明式可管理与Kubernetes和Service Mesh生态的集成深度如何。F5的产品线在这几个维度上是成套的BIG-IP适合对稳定性要求极高的传统机房和大型集群NGINX家族适合云原生环境和推理网关场景Distributed Cloud负责跨云和边缘的统一策略面。选型的时候根据自己业务的部署形态来不必追求一套方案通吃。5.2 与Kubernetes和推理引擎生态的集成深度现在部署AI服务绝大多数都从Kubernetes起步用Helm、Kustomize或云平台自动装推理框架。如果应用交付层跟K8s生态割裂落地会非常痛苦。NGINX Ingress Controller和BIG-IP的Controller模式都能与Service、Pod标签联动做到实例上下线自动感知。很多团队会部署vLLM、Ollama这类推理引擎它们的负载均衡策略通常依赖Kubernetes Service的随机调度比较初级。如果对服务质量要求高建议让Ingress Controller直接对接推理引擎的指标接口按GPU节点实际负载动态调整权重。这个思路不算复杂但对集群稳定性提升明显尤其是在混合跑多种模型副本的情况下。5.3 落地顺序先解决哪个问题不至于什么都想做给正准备把AI推理服务产品化的团队一个路径建议不要一上来就追求大而全的ADC方案按收益大小排序推进。第一步先把流式响应和超时问题解决掉这是用户可感知的体验底线第二步实现基于模型名称的语义路由让多个模型共用一个入口第三步补安全治理统一鉴权、限流、配额防止资源被滥用第四步再考虑跨云和边缘的统一策略调度。每一步都要有可量化收益比如首Token延迟降到多少、支持并发从多少升到多少。做一步验证一步比一次性上一堆概念稳妥得多。5.4 聊聊那个绕不开的疑问AI网关会取代ADC吗最后想聊聊行业里常被问到的问题AI网关以后会不会取代ADC我的判断是二者不是取代关系而是分层关系。AI网关解决的是模型路由、推理引擎适配、Prompt编排、上下文管理这些业务语义问题ADC解决的是流量接入、SSL卸载、连接管理、基础安全防护这些通用基础设施问题。NGINX这类产品经常被用作AI网关的底座本身就说明了二者可以一体化存在。对大多数企业而言先有一个扎实的应用交付层再在其上构建AI网关是最务实的发展路径。模型和框架迭代太快今天火的推理引擎半年后可能就被新的替代品超越但应用交付层解决的是更通用、更稳定的问题建好之后很长时间不需要大改。最后说点个人体会。我见过不少团队把精力全压在模型效果和微调数据上流量入口随便选个默认负载均衡方案等线上出了事故才回头补课。大模型应用的用户体验从来不是模型一个变量决定的交付层决定了用户能不能顺畅、稳定、低成本地用上大模型。ADC 3.0的能力现在已经摆在这里了早一点把入口架构规划好上线后真能少熬几个深更半夜的故障复盘。