每秒能处理十个请求，却只来了八个
一个推理服务平均每请求100毫秒，不停工作可每秒完成十个。每秒只来八个，用户为何等远超100毫秒？平均容量忽略到达时刻和耗时波动。三个相近请求可以形成队列，即便之后服务器闲置。未来空闲时间不能用来提前处理尚未到达的请求。
摘要。研究按到达顺序逐个处理请求的单服务器。区分服务、等待和响应，推导M/G/1公式，比较均值相同的三种耗时分布。在到达率与100毫秒平均服务时间均不变时，平均响应可为300、500或750毫秒。事件模拟验证量级并呈现统计波动。这是教学模型，不是EL-AI负载测试，也不是动态批处理GPU预测。
先看具体序列，再看模型
四个请求在0、40、80、500毫秒到达，每个恰需100毫秒。首个立即开始；第二个在100毫秒开始，等待60毫秒；第三个200毫秒开始，等待120毫秒；第四个在500毫秒立即开始。处理时长相同，响应却为100、160、220、100毫秒。模型本身无需变慢，用户感受到的服务就会变慢。
S为服务时间，W为开始前排队等待，T为系统内总时间。第一式是模拟核心：必须既已到达又等前一个完成才能开始。这里不含网络传输、认证及外部预处理；实际存在时应一致地测量和加入。仅说延迟并未说明观察哪个区间。
使队列可解的假设
M/G/1假定到达为速率λ请求/秒的泊松过程，即到达间隔独立且指数分布，并非等间隔。G表示一般服务时间分布，服务独立同分布且独立于到达；1表示单服务器。假定无限队列、无放弃、无优先级、不中断正在服务的请求，并采用FIFO先进先出。
记平均服务m=E[S]、无量纲负载ρ=λm。λ=8、m=0.1秒得ρ=0.8。该模型稳定平稳分布要求ρ<1；公式给有限平均等待还需E[S²]有限。稳定不意味着每请求满足时限，而是长期队列不会无限增长。80%是理想服务器负载，不能直接等同GPU利用率读数。
为什么会出现耗时的平方
到达时可能有一个请求正在服务，另一些排队。需等剩余服务R及前方请求的完整服务。长任务不只更久，也更可能在到达时仍未结束，因此均值不足。长s秒的任务，其剩余时间从s线性降到零，面积s²/2；长耗时因而对时间平均剩余服务产生平方权重。
N_q为等待请求数，不含正在服务者。第三行使用Little关系，连接平均数量、流率和等待。泊松到达观察到时间平均值，即PASTA，把到达时快照与时间平均连接。把第三式代入第二式并合并E[W]，得到Pollaczek–Khinchin公式。λ单位s⁻¹、E[S²]单位s²，结果为秒。
相同均值，三种等待
第一种每次恰好0.1秒，E[S²]=0.01秒²；第二种指数耗时均值0.1秒，二阶矩0.02秒²。第三种独立地以90%概率耗时0.05秒、10%概率0.55秒。均值仍0.9·0.05+0.1·0.55=0.1秒，二阶矩却为0.9·0.05²+0.1·0.55²=0.0325秒²。这些是隔离波动影响的合成情形，不是公司日志。
| 分布 | E[S] (ms) | E[W] (ms) | E[T] (ms) |
|---|---|---|---|
| S = 0.1 s | 100 | 200 | 300 |
| S ~ Exp(mean=0.1 s) | 100 | 400 | 500 |
| P(S=0.05 s)=0.9; P(S=0.55 s)=0.1 | 100 | 650 | 750 |
混合情形等待8·0.0325/[2·(1−0.8)]=0.65秒，再加0.1秒服务。三种服务器平均忙碌比例相同，改变的是长任务给后方造成的等待。可用变异系数平方C_s²=Var(S)/m²，分别为0、1、2.25。由E[S²]=m²(1+C_s²)，平均等待为ρm(1+C_s²)/[2(1−ρ)]。
接近容量时，小变化代价变大
分母1−ρ是剩余余量。指数服务均值100毫秒时，到达从每秒8增至9，平均响应从0.5变1秒：流量只增12.5%，响应翻倍。每秒9.5则为2秒。不存在通用80%魔法阈值；曲线依赖分布、目标和架构。选择容量余量前，应确定可接受响应并验证模型是否适用。
计算提速对响应的影响可非线性。指数情形每秒八到达，平均服务从100降至80毫秒，ρ从0.8降0.64，平均响应从500降至约222毫秒。这只是固定其他假设的参数变化，不是硬件承诺。增加第二服务器会改变模型，不能简单代入m/2；负载均衡及共享队列也有影响。
呈现自身不确定性的模拟
每分布执行八次独立模拟。每次空队列开始，丢弃20,000个预热请求，保留300,000个。到达间隔指数分布均值1/8秒，按前述递推服务。NumPy 2.5.3用SeedSequence(20260929).spawn(24)生成24个独立流，顺序为常数、指数、混合。八次平均等待分别199.0、403.7、658.0毫秒，理论为200、400、650毫秒。
八个独立运行均值估计的标准误约1.0、4.7、6.1毫秒。同一队列连续请求有关联：积压影响许多后续请求，把它们当独立样本会低估不确定性。重复运行揭示此限制，但八次不能证明渐近行为或消除全部预热影响。公式是假设下解析结果，模拟是披露偏差的有限数值检查。
这个模型何时不再适合推理服务
实际推理引擎可同时处理多个请求。批处理使服务依赖队列状态，破坏这里的独立性。输出长度、取消、缓存和共享加速器也引入依赖。到达可能突发而非泊松；有限队列会拒绝请求，因而仅统计接受请求的低延迟可能掩盖服务困难。
应用需到达、开始、结束时间戳、请求类别、结果和调度策略。应检查间隔分布、服务波动与时间相关，再用参数估计样本之外的负载测试比较预测。本文未在EL-AI执行这些工作。均值公式不决定95或99分位：均值方差相同仍可尾部不同。分位目标需测量或进一步分布模型。
可用容量不等于响应时间保证
服务在饱和前变慢，因为必须吸收时间不规则性，而非只处理平均工作量。容量余量用于消除积压，波动决定积压形成的频率与持续时间。在每秒八请求例子中，降低波动即使不改变平均计算也会改变等待。因此设计应分开测服务与队列，并围绕可验证目标选择余量，而非只追求最大利用率。
参考与可复现性
Eytan Modiano, MIT — M/G/1 Queues, Lectures 8–9, course 6.263J, Fall 2002, slides 2–6.
参考给出假设、公式与剩余服务证明。AI服务数值、混合分布及模拟是本文执行的教学例子。代码片段复现解析比较，归档含完整模拟器、逐次结果和图。并非作者基准复现或经过同行评审的原创研究。
mean_service = 0.1 # seconds
arrival_rate = 8.0 # requests per second
rho = arrival_rate * mean_service
for name, second_moment in [('constant', .01), ('exponential', .02), ('mixture', .0325)]:
waiting = arrival_rate * second_moment / (2 * (1-rho))
print(name, 'queue seconds:', waiting, 'total seconds:', waiting+mean_service)
# Analytical M/G/1 values, not a real inference benchmark.
代码、数据与说明 · JSON. 教学计算使用 Python 3.14.0，图使用 Matplotlib 3.11.2。分析由 AI 辅助，不声称经过同行评审或人工审核。原创 ImageGen 封面仅作示意，不记录 EL-AI 人员、场所或实际安装。来源查阅于 2026 年 9 月 29 日。