一、项目背景

客户的 AI 网关后面挂了几个大模型，流量有明显的昼夜波动，白天闲、晚上集中问。他们一开始把并发上限拍死成一个固定值，结果白天 GPU 利用率才个位数，晚上排队排到几十秒，长文档问答把短问答全堵在后面，P99 延迟经常破秒，用户体验很差。我们进去的时候，他们正纠结要加机器还是调参数，其实两个都不对，核心是并发模型太死。

这个项目我们定的目标是：让并发跟着负载和请求长度动态走，把尾延迟压下来，同时别浪费白天的算力。

二、落地场景

我们在网关层做了一套负载感知的并发调控。实时采集每个模型实例的队列长度、在途请求数和显存占用，动态计算当前该放多少并发。长短请求分开排队，短问答优先走快通道，长文档摘要进慢通道并限制其最大并发占比，避免独吞资源。批内按优先级和到达顺序做公平调度，长请求也不会被饿死。尾延迟超阈值时自动降级非核心功能，比如关掉某些重排序，先保住响应。

容量侧我们让网关的限流信号反向驱动底座弹性扩缩容，流量涨了自动加实例，形成算力流量联动。

三、关键技术挑战与解决思路

负载预判滞后是第一个难题。等队列已经堵了再扩容来不及，我们用过去一段时间的滑动窗口预测接下来几分钟的负载，提前半分钟调并发，实测比纯实时反应稳。

长请求饿死是分级调度的副作用。我们给长请求设了最大等待时间，超过就强制插入执行，同时限制长请求并发占比不超过四成，两头都护住。

批内公平性靠令牌和老化机制。每个请求进来记时间戳，等待过久的自动提优先级，防止某个大批量任务把后来者一直压着。

降级误伤要小心。降级不是一刀切关功能，而是按业务重要性分级，先降可观测里的重计算项，核心生成能力始终保留，避免为了延迟牺牲太多质量。

四、效果数据

文中数据为项目复盘口径，已脱敏。调优后，P99 延迟从约 1.8 秒降到约 0.6 秒，用户体感最明显。平均 GPU 利用率从白天个位数提升到约 45%，晚上高峰也能维持在七成左右，不再大起大落。排队超时率从约 6% 降到约 0.8%。整体吞吐提升约 1.5 倍，同样硬件扛住了原来近一倍的晚高峰流量。

案例片段（已脱敏）：一次晚高峰长文档摘要把短问答堵住，我们看了调度日志，长请求并发占比一度到 70%，触发了限流：[scheduler] long_req_ratio=0.70(>0.40 cap), short_p99=2.1s, action=throttle_long, promote_waiting=12把长请求占比压回四成并提升等待者优先级后，短问答 P99 在四十秒内回到 0.5 秒。

五、可复用经验总结

并发数真不是越大越好，这是个容易踩的坑。我们最早也被提高并发提升吞吐这句话带偏，结果并发一高，显存和调度开销反而把延迟拖爆。后来想明白，得跟着负载和请求长度两条线一起调。

我的判断是，尾延迟治理优先于平均延迟优化，用户记仇的是那几次最慢的体验。先把长请求隔离、设好占比上限，很多问题自然化解。降级也别怕做，关键是分级做、保核心，别为了漂亮数字把主要功能砍了。

附：规模化落地与工程细节

调并发这件事，我们前两周主要在和监控较劲。最初并发上限是固定值，白天浪费、晚上堵，我们试过简单按时间设两套阈值，结果晚高峰到来时间每天浮动，固定时段经常对不上。改成滑动窗口预测后，提前半分钟调，才真正平滑。

降级策略我们也走过弯路，最初一超阈值就关重排序，结果延迟下来了但回答质量掉得厉害，业务方投诉。后来改成分级降级，只降可观测里的重计算项，核心生成能力始终留着，体感和质量才平衡。长请求占比上限四成这个数，是压了几次不同业务混合流量试出来的，文档型和对话型比例差很多。

给同行的建议是，别直接抄我们的参数，按自己流量分布重新标定。尾延迟治理优先于平均延迟，先把长请求隔离，很多问题自然化解，这比堆机器划算。

监控看板我们做了请求长度分布和并发水位两张图，运维每天扫一眼就能预判晚高峰。比起改参数，让负责的人看得懂、愿意看，才是这套调优能持续的关键。我们踩过的坑是参数调好了没人盯，过两周流量一变又堵，所以把监控当产品做，比一次性调优值钱。另外，长短请求分通道后，我们给短问答加了独立配额，哪怕长文档洪峰来了，用户的简单问答也不至于被拖垮，这个隔离比全局限流更精准，体验差异明显。

我们还顺手做了容量弹性联动，网关发现晚高峰并发持续高位，就给底座发信号加实例，平峰再回收，白天不至于空转浪费。这个联动让整体 GPU 成本又降了一截。不过要提醒，弹性扩缩容本身有冷启动开销，我们设了水位滞回，避免在三两个请求波动上频繁加减机器，那比不调还糟。调优这种事，节奏感比参数本身重要，这是我反复验证过的。