吞吐量监控：衡量系统的处理能力

可视化演示

动态演示吞吐量监控的核心机制，通过开始/执行/监控/完成四种模式展示关键概念与交互流程。

吞吐量定义与单位

十字路口的交警首先要回答一个最基础的问题：“这片区域到底能过多少车？”他需要先界定“一辆车”是什么意思——是轿车还是货车？“单位时间”是每分钟还是每小时？同样，吞吐量监控的第一步，就是给“通过能力”一个精确的定义：在单位时间内，系统成功处理的请求数量。这个定义看似简单，却是一切监控的基石——如果连“数什么”都没说清，后面的统计都会失真。

在AI推理服务的语境里，吞吐量的核心指标是QPS（Queries Per Second），即每秒处理的请求数。但经验丰富的运维知道，仅仅看一个QPS数字是不够的：系统在空闲时能跑出漂亮的高峰，在持续压迫下却可能大幅下滑。因此工程上区分两个关键口径——稳态吞吐量（系统在持续压力下能稳定维持的处理速率）和极限吞吐量（系统在资源耗尽前能冲击的最大速率）。这就好比一条城市主干道，畅通时能每分钟通过60辆车，但早晚高峰持续拥堵时实际只能稳定通过40辆——稳态吞吐量才是容量规划真正需要的数字。

回到路口的画面：交警最终在报告上写下的不是“刚才有段路很通畅”，而是“这条路平均每小时稳定通过2200辆车”。有了这个数字，城市规划者才能决定要不要拓宽道路。

采集方案设计

要数车流，交警得先决定站在哪儿数。如果站在路口中央数，能数到每一辆车的到来；如果站在匝道口数，只能数到进入主路的车——两个位置的数字含义完全不同。吞吐量采集方案的核心，就是回答“在哪个环节、用什么方式数请求”的问题。

第一层是网关层采集。在Nginx、API Gateway这类入口处部署全量计数器，统计进入系统的所有HTTP请求。这一层的优势是“一口收口”——所有流量必经此处，数字最完整，且不侵入业务代码。就像在路口安装地磁感应线圈，每过一辆车自动触发一次计数。第二层是应用层埋点。在推理服务内部Pipline的关键路径（如预处理、模型推理、后处理）埋入埋点计数器，统计各阶段处理量。这能回答“请求进来之后，内部到底处理了多少”，好比在路口内的每条车道上都装上探头，看清车流在路口内部是如何分布的。

采集到裸计数器后，还需要解决滑动窗口统计的问题。计数器本身只是“从启动到现在累计数”，但监控需要的是“最近5分钟每秒多少请求”。工程实践上采用滑动窗口：维护一个时间轮，每个时间片（如1秒）一个计数器，窗口滑动时新片加入、旧片丢弃。阿里、腾讯的监控系统均采用类似机制。此外还要做采样与聚合：对海量监控数据，按分钟级粒度聚合成平均值/最大值/P99，减少存储开销。

回到路口画面：交警不再傻站着数一天，而是每5秒瞄一眼滑动窗口，动态播报“最近5秒平均每秒过车X辆”。这种“滚动统计”既灵敏又稳定，正是采集层设计的精髓所在。

QPS与TPS区别

路口交警有时候会被问到一个刁钻问题：“你数的车，是过路口的车次数，还是从A点到B点完成了一整段行程的车辆数？”前者只要车轮碾过路口就算一次，后者要求车辆完整通过整条监控路段才算完成——这就是QPS与TPS（Transactions Per Second）的本质区别。

QPS（Queries Per Second） 以“一次请求”为计量单位。每个HTTP请求就算一次QPS，无论这个请求内部是简单查询还是复杂推理。TPS（Transactions Per Second） 以“一个完整事务”为计量单位——事务可能包含多个请求、多次状态变更。例如一个在线翻译功能，用户点击“翻译”后前端可能连续调用3次后端接口（分词、翻译、校对），对网关来说是3次QPS，但对业务来说这只是一个完整的“翻译事务”，即为1次TPS。

工程上如何选择？核心看统计口径服务于什么目的。如果关注的是基础设施承载压力（网络带宽、连接数、CPU），选QPS——每个请求都会消耗连接和算力资源，好比每辆经过的车都需要占用路面空间；如果关注的是业务价值交付量（用户完成多少次翻译、多少次图像识别），选TPS——只有完整走完流程的用户才算真正“到达目的地”。AI推理场景中，一个典型的对话请求可能包含多轮内部调用，此时TPS更能反映“业务层面系统真正完成了多少有效工作”。

回到路口的画面：如果交警向政府报告“每小时通过2万辆车”（QPS），市长并不能直接知道“有多少市民完成了通勤”（TPS）。对于AI服务，架构师需要同时看两个数字：QPS告诉你系统吃不吃得消，TPS告诉你用户任务是否顺利完成——两者缺一不可。

瓶颈分析与定位

车流不畅时，交警的第一反应不是责怪司机，而是查找堵点：是路口信号灯太短？还是某条车道施工？还是转弯车辆与直行车互相抢道？吞吐量监控的瓶颈分析有同样的逻辑——当QPS上不去时，要找出“拖住整个系统的那个红灯”。

第一步是逐层耗时分析。把一次请求的生命周期拆成网络传输、排队等待、模型推理、结果返回等阶段，分别统计平均耗时和P99耗时。这就像把一段通勤路线拆成“走到地铁站—等车—坐车—出站”四段，用计时器分别记录哪一段花的时间最多。第二步是识别等待与空闲。高吞吐系统的关键在于“让所有部件尽量都忙着”。如果CPU利用率很低但QPS上不去，说明系统在等待外部资源（如磁盘IO、数据库锁、下游接口响应）；如果CPU高但QPS也不高，说明计算本身太重——好比路口明明车不多却堵成一团，原因是每辆车过路口时都要磨蹭半天。

第三步是定位热源与争抢。在GPU推理集群中，最常见的瓶颈点是：GPU利用率是否打满、显存带宽是否争抢、CPU预处理/后处理是否阻塞、锁竞争或队列堆积是否卡住流水线。使用的工具包括火焰图（Flame Graph）分析CPU热点、GPU operator观察利用率、以及链路追踪系统（如OpenTelemetry）串联各阶段耗时。瓶颈根因定位遵循“短板效应”：系统的最大吞吐量由最慢的那个环节决定。

回到路口：交警找到堵点后，就知道该申请加装信号灯（优化调度）、加宽车道（扩容）还是设置专用转弯道（拆分环节）。瓶颈分析的本质，就是把“车走得慢”的模糊感觉，变成“哪一段路最窄”的精准判断。

容量规划与水位

有经验的交警不仅知道现在堵不堵，还会预测下周同时间的车流量，提前布置警力。容量规划的本质就是“未雨绸缪”：根据历史曲线预测未来压力，在系统被打爆之前，提前扩容或限流。这其中的核心概念是水位——系统当前负载占最大容量的百分比。

第一步是收集历史峰值水位。回顾过去31天、90天的吞吐量曲线，找到每个时间段的峰值QPS和P99延迟。比如“过去90天最高QPS出现在工作日下午3点，达到1200”。这个值是容量规划的锚点。第二步是做压测获得极限吞吐。通过全链路压测工具（如Locust、wrk、JMeter）对系统施加递增压力，直到出现错误率上升或延迟超标，记录此时的QPS作为极限吞吐量。注意压测要分阶梯进行：从50%逐渐加到120%的预估峰值，观察每个压力等级下的延迟和错误率变化。

第三步是计算并预留安全冗余。水位线通常不设在100%——因为突发流量和毛刺随时可能出现。行业惯例是将水位控制在极限吞吐量的60%-70%为宜；对关键业务甚至要求更低（约50%），预留足够的弹性应对流量尖峰。容量规划遵循公式：

回到路口城市管理：规划部门根据历史车流数据预测“明年早高峰可能达到每小时8000辆”，而现有道路极限是每小时10000辆——8000/10000=80%，超过70%警戒线，于是申报扩建车道。容量规划就是这种“给未来留余地”的工程智慧。

监控三域模型

一位优秀的交警不会只盯着车辆本身，他还会观察：路况信息牌是否正常显示（系统）、其他路口的疏导信息是否同步（网络）、以及交通事故是否已派出拖车（业务）。吞吐量监控同样需要三维视角——这就是业界广泛采用的监控三域模型：业务域、系统域、网络域。

业务域关注吞吐量的业务含义：QPS、成功率、响应时间、业务方调用量。这些指标直接反映“用户任务完成得怎么样”——相当于交警记录“每小时有多少人顺利到达了目的地”。采集方式包括网关层的访问日志解析、应用层埋点、APM工具的统计。业务域是面向产品方和业务方的语言。

系统域关注承载吞吐量的底层资源：CPU利用率、内存占用、GPU利用率、磁盘IO、线程池队列深度。这些指标揭示“系统的哪个部件在吞吐量上升时首先耗尽”——相当于监控路口的每一条车道是否拥堵、信号灯是否正常工作。当业务域QPS很高但用户仍觉得慢，问题大概率出在系统域。

网络域关注请求链路中的网络开销：网络延迟、连接数、带宽占用、DNS解析时长、上下游调用耗时。当吞吐量指标异常时，网络域用于区分“是应用本身慢”还是“网络传输慢”——好比交警接到报案说路口拥堵，他需要先确认是路口内部堵，还是通向路口的引桥上堵。三个域的指标要联合分析：单看业务域QPS只是知其然，拉通系统域与网络域才能知其所以然。监控三域联合分析，是AI推理服务可观测性的完整拼图。

回到路口的画面：智能交通中心的大屏上同时显示着三块数据——车流量统计（业务域）、红绿灯状态和车道占用（系统域）、周边路网拥堵情况（网络域）。只有三块数据联动起来，调度员才能做出准确的疏导决策。吞吐量监控的成熟形态，就是这样一个三维联动的“交通指挥中心”。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""吞吐量监控统计器：滑动窗口QPS计算与限流判断模拟AI推理服务网关层的吞吐量采集逻辑"""import timeimport randomfrom collections import deque  class ThroughputMonitor:    def __init__(self, window_size=5):        self.window_size = window_size        self.timestamps = deque()        self.total_count = 0     def record(self):        """记录一条请求完成"""        now = time.time()        self.timestamps.append(now)        self.total_count += 1        # 清理滑动窗口外的过期数据        while self.timestamps and now - self.timestamps[0] > self.window_size:            self.timestamps.popleft()     def get_qps(self):        """计算当前滑动窗口内的QPS"""        now = time.time()        while self.timestamps and now - self.timestamps[0] > self.window_size:            self.timestamps.popleft()        return len(self.timestamps) / self.window_size     def is_over_limit(self, limit_qps):        """判断当前QPS是否超过限流阈值"""        return self.get_qps() >= limit_qps  def simulate_traffic(monitor, limit_qps=8, duration=12):    """模拟流量波动并输出统计结果"""    start = time.time()    while time.time() - start < duration:        # 模拟请求到达: 随机间隔0.02~0.2秒        time.sleep(random.uniform(0.02, 0.2))        monitor.record()         qps = monitor.get_qps()        overload = monitor.is_over_limit(limit_qps)        status = "【限流】" if overload else "正常"        print(f"当前QPS={qps:.1f} 累计请求={monitor.total_count} {status}")  if __name__ == "__main__":    m = ThroughputMonitor(window_size=5)    simulate_traffic(m, limit_qps=8, duration=10)

1. self.timestamps = deque()用双端队列存储请求时间戳，新请求从右端加入，过期数据从左端弹出，天然适配滑动窗口的“先进先出”特性。
2. while ... now - self.timestamps[0] > self.window_size每次都清理超过5秒窗口的旧时间戳，保证get_qps计算的是“最近5秒”而非“累计”的速率。
3. len(self.timestamps) / self.window_sizeQPS的计算核心：窗口内剩余时间戳数量除以窗口宽度（5秒），正是正文公式 $\frac{\text{total}}{\Delta t}$ 的代码表达。
4. is_over_limit(limit_qps)封装限流判断逻辑，返回布尔值供上层做扩容/限流决策，对应监控告警的触发条件。
5. simulate_traffic()用随机sleep模拟真实请求到达的泊松分布特性，让演示更接近生产环境的流量波动。

常见误区

面试题