周五傍晚六点，公司楼下那家奶茶店又排起了长队。你注意到收银台旁贴着一长串订单小票，从“001 号双拼奶茶”一直贴到“063 号冰美式”。这些等待制作的小票，就是这家店此刻的“积压订单”；老板只要瞄一眼小票挂了多少张，就知道高峰有没有来、后厨忙不忙得过来。 AI 推理服务的世界里，也有一面同样的“小票墙”。用户发来的每一个请求（聊天、翻译、识图）都会先排队，等待 GPU 这个“奶茶师傅”来制作。墙上待处理请求的数量，专业上叫“模型请求队列深度”，它是衡量服务积压程度最直观的温度计。队列越深，用户等得越久，体验越差。 这篇文章我们就从这面小票墙讲起：如何监控队列深度、判断排队延迟是否异常、定位瓶颈到底在排队还是执行、在队列溢出前做好防护，以及什么时候该叫“临时工”——也就是动态扩容。学完这些，你就能像一个老练的店长，一眼看出你的推理服务什么时候在“爆单”。

岗位关联

对 AI 从业者而言，掌握队列深度监控是诊断推理服务性能瓶颈的“第一块仪表盘”，能帮你快速定位延迟劣化根源、设计防护与弹性扩容策略，是模型上线后保质量、保体验的核心技能。

目录
  1. 可视化演示
  2. 队列深度概览
  3. 监控采集手段
  4. 延迟关系分析
  5. 瓶颈定位诊断
  6. 溢出防护机制
  7. 扩容触发策略
  8. 工程落地价值
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示推理服务请求队列深度监控、M/M/1排队论利用率与延迟非线性关系、以及基于队列深度的动态扩容与批处理调度。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+_captions.queue+'

队列深度概览

店长看小票墙，其实在看两件事：一是“今天卖了多少杯”（吞吐），二是“现在还有多少杯没做”（积压）。小票墙上的张数就是后者。它回答一个最简单的问题——此刻有多少用户在等？对小店来说，这决定了出杯速度要不要加快；对推理服务来说，这决定了要不要扩容、要不要限流。

在推理服务中，请求从入口进来后不会立刻被 GPU 处理，而是先进入一个内存队列。队列深度 Q(t) 就是在某个时刻 t，已经到达但还没有开始被处理的请求数量。要真正用好这个指标，关键要分清“到达”和“开始”两个动作：设 A(t) 为截止时刻 t 累计到达的请求数，B(t) 为累计开始被处理的请求数，则任意时刻的队列深度等于两者的差——就像墙上小票数等于贴上的总数减去撕下来开始做的总数。

所以，当监控面板上队列深度持续攀升，你就要像店长一样警觉：这说明“进门的速度”超过了“后厨出锅的速度”，爆单只是时间问题。抓住深度，就抓住了推理服务积压的脉搏。

Q(t)=A(t)−B(t)\displaystyle Q(t) = A(t) - B(t)
这个公式就像“贴上去的小票数减去撕下来开始做的小票数”，剩下的就是还挂着等待制作的订单。
  1. 累计到达请求数 A(t)从服务启动到时刻 t，所有涌入入口的请求总数，对应奶茶店开张以来收到过的全部订单数。
    A(t)=∑到达时刻≤t1\displaystyle A(t) = \sum_{\text{到达时刻} \le t} 1
  2. 累计开始服务数 B(t)从服务启动到时刻 t，GPU 已经开始制作的请求总数，对应后厨已经开始动工的订单数。
    B(t)=∑开始时刻≤t1\displaystyle B(t) = \sum_{\text{开始时刻} \le t} 1
  3. 代入时刻 t 观察若此刻到达 100 个、已开始 62 个，则墙上有 38 个在等，这就是排队积压。
    Q(t)=100−62=38\displaystyle Q(t) = 100 - 62 = 38

监控采集手段

店长不可能一分钟不差地盯着小票墙，他通常每隔一刻钟瞄一眼，或者让收银台在整点时报一次数。观察的方式，决定了老板对忙闲的判断有多准。推理服务也一样，队列深度是“瞬时快照”型指标，怎么采、怎么汇总，直接决定监控数据可不可信。

实践中，监控系统（如 Prometheus）会周期性地来“瞄一眼”：每 15 秒拉取一次当前队列长度，存成一条时间序列。但单次快照很容易漏掉一瞬间的尖峰——比如刚好在两次采样之间爆发了 50 个请求。因此工程上常做“窗口聚合”：把一段时间内的采样值汇总成更有代表性的数字，最常见的是窗口平均深度。

公式里的思想很简单：把窗口内的 N 个采样点加起来求平均，抹平毛刺；同时还要另存窗口内的最大值，防止平均值把风险掩盖掉。一个老练的 SRE 会同时盯“平均排队人数”和“最长那次排队”，两者缺一不可。

店长若只看平均，可能错过某次 40 杯的爆单瞬间——所以成熟的做法是平均值配最大值、再配分位数一起看。这就像既看“平均排队”，也看“最长那次排队”，监控才算真正有了眼睛。

Qˉ=1N∑i=1NQi\displaystyle \bar{Q} = \frac{1}{N}\sum_{i=1}^{N} Q_i
相当于店长把最近 15 次瞄到的小票数加起来除以 15，得到“平均排队人数”；再单独记下最大那一次，以防漏掉爆单瞬间。
  1. 采样序列 Q_i监控系统每隔固定周期采集一次的队列深度快照，一组快照按时间顺序排成一列。
    Q1,Q2,Q3,…,QN\displaystyle Q_1, Q_2, Q_3, \dots, Q_N
  2. 对所有采样值求和把 N 个快照数字累加，得到这一段时间排队深度的总和。
    ∑i=1NQi\displaystyle \sum_{i=1}^{N} Q_i
  3. 除以样本个数求平均总和除以 N，得到代表窗口内“典型排队水平”的均值。
    Qˉ=1N∑i=1NQi\displaystyle \bar{Q} = \frac{1}{N}\sum_{i=1}^{N} Q_i

延迟关系分析

排队的人越多，你等的时间自然越长。但如果店长告诉你“排 5 个人大约 5 分钟，排 10 个人大约 20 分钟”，你一定会觉得不对劲——这说明后厨已经到了极限，队伍一长就彻底转不动了。推理服务也有同样的规律：队列里每多一个请求，新到达的请求就要多等一份“单杯制作时间”。

在系统未饱和前，排队延迟与队列深度近似成正比；可一旦进入饱和区，延迟会以惊人的速度恶化。描述这种关系最经典的结论是 Little 定律：在一个稳定系统中，平均请求数 L 等于请求到达率 λ 乘以平均停留时间 W。它把“队列多深”和“用户等多久”两块仪表盘焊在了一起——深度飙升，等待时间必然飙升。

这就是为什么监控时不能只看深度，还要同步盯到达率：深度只是果，到达率与处理率的赛跑才是因。理解了这一点，你就能解释为什么同样的深度，在凌晨两点和晚高峰七点的含义完全不同。

所以当你看到队列深度从 5 涨到 20，别急着怪模型变慢——先算算到达率是不是翻倍了。排队延迟的账，永远要从“进来多少”和“做得多快”两头算，这才是诊断的第一步。

L=λ×W\displaystyle L = \lambda \times W
这就像“奶茶店等位守恒”：平均店里待着的人 = 每分钟进店人数 × 平均每人停留分钟数。进店越快、停留越久，店里越挤。
  1. 到达率 λ单位时间进入系统的平均请求数，对应每分钟进店点单的顾客数。
    λ=到达请求数时间长度\displaystyle \lambda = \frac{\text{到达请求数}}{\text{时间长度}}
  2. 平均停留时间 W每个请求从进队到完成的平均时长，对应顾客从下单到拿到奶茶的平均分钟数。
    W=T排队+T服务\displaystyle W = T_{\text{排队}} + T_{\text{服务}}
  3. 三者的乘积关系稳定状态下，系统内平均请求数等于到达率与停留时间的乘积，任一项变化都会牵动另外两项。
    L=λ×W\displaystyle L = \lambda \times W

瓶颈定位诊断

顾客在奶茶店等久了，抱怨声难免。会做生意的店长会先搞清楚：是前面点单太慢，还是后厨做太慢？是排队等着收银，还是等着出杯？这两个环节的错，解法完全不同。推理服务同样要把延迟拆开看：一次请求的总时延 = 排队等待时延 + 执行（推理）时延。

如果排队占了八成，说明是“门庭若市、后厨没闲”，属于容量不足；如果执行占了八成，说明是“后厨本身就慢”，光加排队位没用。这就要靠埋点数据说话：分别记录请求进入队列的时刻和开始被 GPU 处理的时刻，两者相减得到排队时长；总时延减去排队时长，就得到执行时长。

排队占比 R_q 就是一个极简的瓶颈诊断指标：它把“等待”和“制作”在总耗时中的分量量化出来。占比越接近 1，说明用户的时间几乎全耗在等上面，问题出在容量与调度；占比越接近 0，说明请求一到就被处理了，耗时长是模型本身慢。

记住这个“等 vs 做”的二分法：当店长发现顾客七成时间都在等出杯，他的下一步不是换更好的锅，而是把队首加快——扩容、限流、提高吞吐。诊断对了，处方才对；诊断错了，优化模型就是在给错误的病吃药。

Rq=TqueueTqueue+Tserve\displaystyle R_q = \frac{T_{\text{queue}}}{T_{\text{queue}} + T_{\text{serve}}}
排队占比相当于“等待时间占整个购物旅程的比例”——七成时间在等，就该多开口子多上人手了。
  1. 排队等待时长 T_queue从请求进入队列到被 GPU 取走开始处理的时间，对应顾客下单后干等的分钟数。
    Tqueue=Tstart−Tarrive\displaystyle T_{\text{queue}} = T_{\text{start}} - T_{\text{arrive}}
  2. 执行服务时长 T_serveGPU 真正跑模型推理的时间，对应后厨制作奶茶的时间。
    Tserve=Tfinish−Tstart\displaystyle T_{\text{serve}} = T_{\text{finish}} - T_{\text{start}}
  3. 排队占比 R_q排队时长占总时延的比例，越接近 1 越说明瓶颈在排队而非算力。
    Rq=TqueueTqueue+Tserve\displaystyle R_q = \frac{T_{\text{queue}}}{T_{\text{queue}} + T_{\text{serve}}}

溢出防护机制

店里座位有限，后厨能力有限。真正火爆的时候，聪明的老板不会让顾客无限排队排到马路对面——他会挂出“今日已满，暂不接单”的牌子。拒绝新客虽然损失一单生意，却保住了已下单顾客的体验，也保住了后厨不被压垮。

推理服务同理，队列不能无限长。无限队列会让延迟无限上涨，把整个服务拖垮，甚至拖垮下游依赖。所以工程上会给队列设一个最大深度 Q_max，并制定溢出时的处理策略。最常用的手段是有界队列加条件接收：只有队列深度小于上限时新请求才被接收，否则直接拒绝，配合客户端退避重试。

更优雅的是背压机制——当队列接近满时，不简单丢弃，而是把压力反向传递给上游，让上游降速或停发。这就像店门口的人不让新顾客进门，还往前走告诉街对面的人“别来了”。拒绝与背压组合使用，系统在过载时才能“软着陆”，而不是硬生生崩溃。

就像老板挂出“暂不接单”时，街角的新顾客会看到提示绕去别家——背压让整个系统过载时“软着陆”。损失一些请求，换取大部分请求的稳定，这笔账在流量洪峰时尤其划算。

Iaccept=1{Q(t)<Qmax⁡}\displaystyle I_{\text{accept}} = \mathbf{1}\{ Q(t) < Q_{\max} \}
这是一个“准入开关”：深度没到顶就放行（1），到了顶就拦住（0），像守门员只看“是/否”。
  1. 队列深度与上限比较当前积压量对比预设最大值，决定是否还有接收空间。
    Q(t)<Qmax⁡\displaystyle Q(t) < Q_{\max}
  2. 指示函数 1{条件}括号里的条件成立取 1，不成立取 0，像一个只看“是/否”的守门员。
    1{⋅}\displaystyle \mathbf{1}\{\cdot\}
  3. 准入判定结果1 表示接收请求入队，0 表示拒绝并返回过载信号，触发上游退避。
    Iaccept=1    或    0\displaystyle I_{\text{accept}} = 1 \;\; \text{或} \;\; 0

扩容触发策略

高峰时段，队伍开始超过二十人。有经验的店长会在队伍刚变长时就打电话叫两个临时工，而不是等顾客骂街了才动手；等午高峰过去，再小心地把临时工劝回去，免得闲得发慌还花钱。推理服务面对流量洪峰也是同样的道理：队列深度是扩容最直接的触发信号。

当深度持续高于阈值时，说明现有 GPU 实例忙不过来，需要动态拉起新实例来分担流量。扩容的底气来自排队论的利用率公式：设到达率为 λ，单个实例平均服务率为 μ，当前实例数为 m，则系统利用率 u = λ / (m × μ)。只有当 u < 1 时队列才会稳定；u 越接近 1，队列越容易堆积。

所以扩容的本质是提高 m，把 u 拉回安全区间。注意新实例要“先预热再放量”，不然冷启动的模型反而会拖慢整体；缩容则要比扩容更保守，防止刚缩完又涨回来，造成反复振荡。

店长的“临时工”不是等到队伍排到门口才叫的，而是深度刚过警戒线就启动。动态扩容同理：用队列深度做扳机，预热缓解抖动，缩容慢半拍求稳，高峰自然有惊无险。

u=λm×μ\displaystyle u = \frac{\lambda}{m \times \mu}
相当于：每分钟进店 12 人、每个师傅每分钟做 3 杯，那 3 个师傅就刚够用，4 个才宽裕、才不用排队。
  1. 到达率 λ 与单实例服务率 μλ 是单位时间进入的请求数，μ 是单个 GPU 实例单位时间能处理的请求数。
    λ,  μ\displaystyle \lambda, \; \mu
  2. 实例数 m当前并行处理请求的服务实例数量，对应店里同时开工的师傅人数。
    m\displaystyle m
  3. 利用率 u总需求与总能力之比，大于等于 1 时队列必涨，小于 1 时队列才可能回落。
    u=λm×μ\displaystyle u = \frac{\lambda}{m \times \mu}

工程落地价值

一家成熟的连锁店，会把“排队不超过 10 分钟”写进店规，并且每周复盘：有多少天做到了？最差的一天排了多久？店长不是为了好看的数字，而是为了顾客下次还来。推理服务同样需要把队列监控沉淀为工程目标。

最核心的是定义服务质量目标（SLO），比如“95% 的请求排队等待时间低于 200ms”。队列深度就是这个 SLO 的晴雨表，也是告警、扩容、限流所有动作的输入信号。落地时，通常把队列深度监控接入告警与容量平台：深度超阈值触发告警并自动扩容；持续超阈值触发限流保护；同时配合延迟分位监控验证 SLO 是否达标。

这样一来，排队这件事就从“被动挨骂”变成了“主动管理”。请求处理效率和交付质量都得到了保障——不是靠运气，而是靠一套从监控到决策再到执行自动运转的闭环。

把“尽量快”变成“承诺多快”，把“凭感觉”变成“看深度”，这就是工程化的魅力。像连锁店靠排队时长树立口碑一样，推理服务靠队列深度监控立住质量底线。

P(Twait<Ttarget)≥SLO\displaystyle P(T_{\text{wait}} < T_{\text{target}}) \ge SLO
意思是：任意一个请求，排队时间低于目标值的概率，必须达到我们承诺的百分比，比如 99% 或 95%。
  1. 单请求排队等待时间 T_wait从请求进队到开始处理之间的时长，对应顾客拿到奶茶前的等待时间。
    Twait\displaystyle T_{\text{wait}}
  2. 目标阈值与达标概率设定一个可接受的目标时长，统计排队时间低于该时长的请求占比。
    P(Twait<Ttarget)\displaystyle P(T_{\text{wait}} < T_{\text{target}})
  3. SLO 达标判定达标概率必须不低于承诺值，否则触发告警与扩容流程。
    P(Twait<Ttarget)≥SLO\displaystyle P(T_{\text{wait}} < T_{\text{target}}) \ge SLO

AI 应用场景

在线 LLM 对话服务的自动扩容

阶段：推理监控与弹性容量管理

解决的问题：传统做法是固定一批 GPU 副本，流量洪峰时请求全部堆进队列，用户等待几十秒，体验暴跌。通过实时监控队列深度并联动扩容，能在队列刚变深时就把容量补上，把积压压回低位。

具体案例：某智能客服产品接入大模型后，工作日早高峰 10 点队列深度从 5 飙到 80，P95 延迟从 1.2 秒恶化到 18 秒。接入队列深度监控与自动扩容后，深度连续 30 秒超过 20 即自动加 2 个副本，P95 稳定在 3 秒以内，高峰期用户几乎无感知。

离线批量推理的背压重试

阶段：批处理任务调度

解决的问题：离线批量任务（如图像审核、文档向量化）一次性全量提交，推理队列被打爆，任务静默丢失且无人知晓。利用有界队列加背压机制，让上游在队列满时暂停提交并退避重试，既不丢任务又不拖垮服务。

具体案例：某内容平台的图像审核每天深夜跑全量新图片，高峰期一次性丢入 50 万条任务，队列溢出导致约 3% 任务丢失。改造为队列深度超过 10000 即暂停提交、指数退避重试后，任务丢包降为 0，整体完成时间反而缩短了 20%。

推荐系统实时推理的瓶颈定位

阶段：线上性能诊断

解决的问题：接口响应时间变慢时，很难立刻判断是“排队等”还是“模型算得慢”。通过在服务端埋点输出排队时长与执行时长，用排队占比 R_q 快速分流排查方向，避免盲目优化模型。

具体案例：某电商首页推荐接口在大促压测中 RT 翻倍，团队先看队列深度与排队占比——R_q 从 10% 升到 70%，立即判定是流量洪峰导致的排队瓶颈，扩容两个推理实例后 10 分钟恢复，省去了先排查模型代码的大量弯路。

Python 演示

python49 行
import random  class QueueMonitor:    """模拟推理服务请求队列，统计队列深度与溢出情况。"""     def __init__(self, arrival_rate, serve_rate, max_depth):        self.arrival_rate = arrival_rate        self.serve_rate = serve_rate        self.max_depth = max_depth        self.queue = []        self.depth_samples = []        self.rejected_count = 0     def run(self, steps):        clock = 0.0        next_arrival = random.expovariate(self.arrival_rate)        next_service = random.expovariate(self.serve_rate)        for _ in range(steps):            if next_arrival < next_service:                clock = next_arrival                if len(self.queue) < self.max_depth:                    self.queue.append(clock)                else:                    self.rejected_count += 1                next_arrival = clock + random.expovariate(self.arrival_rate)            else:                clock = next_service                if self.queue:                    self.queue.pop(0)                next_service = clock + random.expovariate(self.serve_rate)            self.depth_samples.append(len(self.queue))        return self.report()     def report(self):        peak_depth = max(self.depth_samples)        avg_depth = sum(self.depth_samples) / len(self.depth_samples)        utilization = self.arrival_rate / self.serve_rate        return {            "peak_depth": peak_depth,            "avg_depth": round(avg_depth, 2),            "rejected_count": self.rejected_count,            "utilization": round(utilization, 2),        }  if __name__ == "__main__":    print("到达率5.0/秒, 服务率6.0/秒:", QueueMonitor(5.0, 6.0, 10).run(3000))    print("到达率6.5/秒, 服务率6.0/秒:", QueueMonitor(6.5, 6.0, 10).run(3000))
目的：模拟推理请求的到达与服务过程，对比低负载与高负载下队列深度、峰值与拒绝数量的差异，直观验证“到达率超过处理率时队列必然增长”的规律。
  1. next_arrival = random.expovariate(self.arrival_rate)用指数分布模拟下一次请求到达时刻，到达越频繁，期望间隔越短。
  2. if len(self.queue) < self.max_depth:队列深度未达上限才接收请求，这就是有界队列加条件接收的溢出防护。
  3. self.rejected_count += 1队列已满时拒绝请求并计数，用来观察溢出有多严重。
  4. self.depth_samples.append(len(self.queue))每个事件后采样一次深度，形成监控时间序列。
  5. if self.queue: self.queue.pop(0)服务完成时取走队首请求，体现先到先服务的排队规则。
  6. utilization = self.arrival_rate / self.serve_rate利用率大于 1 时队列必然无限增长，这是扩容决策的核心依据。

常见误区

误区监控图上队列深度一直是个位数，看来服务很健康，不用管它。毕竟墙上的小票就几张，后厨肯定忙得过来。

正解队列深度小可能只是采样频率太低，恰好没抓到瞬时尖峰；也可能是服务能力骤降、入口被限流，请求根本没进来。要结合窗口内最大值、分位数与到达率一起看。就像店长两小时才看一眼小票墙，很可能错过中午那一波 40 杯的爆单。

为何常见：平均值看起来安全，容易掩盖瞬时洪峰和“虚假平静”，让人误以为一切正常。

误区队列都排到 50 了，肯定是模型推理太慢，赶紧优化模型、换更大的 GPU。

正解深度高更多时候是“到达率超过处理率”，即流量太大或实例太少，而模型单次推理耗时可能很正常。正确的做法是先用排队占比 R_q 区分排队与服务，别让模型背锅——就像店里排长队，可能不是师傅手慢，而是门口一下子涌进来太多客人。

为何常见：延迟变差时，人脑自动归因到最重的环节——模型，而忽视了容量规划和流量控制这些更常见的原因。

误区无论什么原因排队，多买几张 GPU 卡扩容准没错。算力上去了，队伍自然就短了。

正解若瓶颈在拉取输入、上游依赖慢、锁竞争或冷启动，单纯加 GPU 消化不了流量；而且新实例没有预热，扩容后反而可能加剧抖动。扩容之前要先定位瓶颈到底在排队还是执行，否则就像给已经很快的师傅加人，而真正堵的是点单台。

为何常见：GPU 是最显眼的成本，直觉认为算力够了一切都好，忽略了整个请求链路上的其他环节。

误区队列快满了，赶紧把所有新请求都拒掉，宁可错杀一千，不能放过一个。

正解一刀切拒绝会引发客户端重试风暴，反而放大流量。更好的组合是：背压通知上游降速、拒绝时返回可重试信号并带退避、同时触发扩容，让系统软着陆。就像满座的餐厅不是把客人全赶走，而是告诉后来者“稍后再来”，同时赶紧加桌子。

为何常见：保护直觉容易走极端，忽略了拒绝之后客户端会重试，处理不当反而让系统雪上加霜。

面试题

Q1. 模型请求队列深度直接描述的是？

单选题 · easy

  • A.服务正在处理的请求总数
  • B.排队等待处理的请求数量← 正确答案
  • C.每秒新到达的请求数量
  • D.单次请求处理的耗时

答案：B。队列深度只统计“到达但还没开始处理”的请求，就像奶茶店墙上挂着、还没动工的小票。正在处理的请求属于“服务中”，到达率与耗时则是另外两个独立指标。选 B。

Q2. 当请求到达速率持续大于服务处理速率时，队列深度会？

单选题 · easy

  • A.保持动态平衡
  • B.逐渐减小至零
  • C.不断增长到溢出← 正确答案
  • D.随机上下波动

答案：C。相当于进店速度持续快于出杯速度，小票只增不减，直到挂满整面墙。此时队列深度必然增长并触发溢出防护，不会自己恢复平衡。选 C。

Q3. 关于排队延迟与队列深度的关系，最准确的说法是？

单选题 · mid

  • A.两者间完全无关
  • B.始终呈线性正比增长
  • C.饱和点前平缓后陡增← 正确答案
  • D.只取决于推理耗时

答案：C。未饱和时段队深和延迟近似线性；一旦到达率逼近处理率，队列增速与延迟都会加速恶化，出现“饱和点”拐弯。C 既描述了线性段，也描述了拐点后的恶化，是最完整的答案。

Q4. Little 定律 L = λW 中 λ 表示？

单选题 · mid

  • A.系统平均请求数
  • B.请求平均服务时长
  • C.单位时间到达请求数← 正确答案
  • D.单位时间完成请求数

答案：C。Little 定律中 L 是系统内平均请求数，W 是平均停留时间，λ 是到达率——相当于每分钟进店人数。它把队深、到达率、等待时间三者关联起来。选 C。

Q5. 以下哪个现象最说明瓶颈在排队环节？

单选题 · mid

  • A.队列深度为零但耗时很高
  • B.深度持续增长排队占比高← 正确答案
  • C.执行时间占总时延八成以上
  • D.到达率与处理率基本持平

答案：B。排队占比高（如七成时间在排队）直接说明瓶颈在等待环节；若深度为零耗时还高，说明是执行慢；执行占比高则说明模型算力才是瓶颈。B 最直接地指向排队。

Q6. 背压机制的核心思想是？

单选题 · hard

  • A.直接丢弃所有溢出请求
  • B.将过载压力反向传给上游← 正确答案
  • C.把队列容量设成无限大
  • D.降低所有请求的处理优先级

答案：B。背压不是简单丢弃，而是像满座的店派人去街对面喊“别来了”——把队列将满的信号反馈给上游，让上游主动降速或暂停，从而避免重试风暴。选 B。

Q7. 扩容时“先预热再放量”的主要原因是？

单选题 · easy

  • A.新实例冷启动期性能差← 正确答案
  • B.可以节省 GPU 采购成本
  • C.提升模型的推理准确率
  • D.减少请求的网络传输时间

答案：A。新拉起的实例需要加载模型、填充缓存，冷启动阶段延迟高，直接全量放流会拖慢整体。预热让小流量先激活实例，再逐步放量，就像新师傅先做几杯练手再上高峰。选 A。

Q8. 队列深度监控中，常用的统计口径有？（多选）

多选题 · mid

  • A.瞬时最大值采样← 正确答案
  • B.窗口内平均值统计← 正确答案
  • C.高分位数估计值← 正确答案
  • D.磁盘读写速率指标

答案：ABC。平均值抹平毛刺但掩盖尖峰，最大值捕捉最坏瞬间，分位数刻画长尾，三者互补，对应“平均排队、最长排队、长尾排队”三个视角。磁盘读写速率属于基础设施指标，与队列深度无关。

Q9. 以下哪些措施有助于降低排队延迟？（多选）

多选题 · hard

  • A.动态扩容推理实例← 正确答案
  • B.提高请求到达速率
  • C.限流结合背压机制← 正确答案
  • D.优化单请求执行耗时← 正确答案

答案：ACD。扩容提高总处理能力，限流与背压控制进队量，优化执行耗时让队列排空更快，三者都能降低排队延迟。提高到达速率只会让队伍更长、等待更久，适得其反。

Q10. 关于动态扩容触发策略，正确的做法有？（多选）

多选题 · mid

  • A.深度持续超阈值再扩容← 正确答案
  • B.扩容前先完成预热← 正确答案
  • C.缩容比扩容更谨慎← 正确答案
  • D.容量越早释放越省成本

答案：ABC。深度持续超阈值说明系统确实过载，触发扩容；预热避免冷启动抖动；缩容要滞后防止刚缩完又涨回来造成振荡。D 的“越早释放越好”恰恰是缩容的大忌，容易引发反复扩容的抖动循环。