SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

延迟和吞吐量

一个问你「单件活要多久」,一个问你「一小时能干几件活」。把延迟优化等同于吞吐优化,可能花了钱却让用户等得更久。

寓言

快厨和流水席

老马的餐厅有两个厨房。左边是「快厨」,只做一道菜。客人下单,厨师起锅、翻炒、装盘、出餐,从下单到上桌最快三分钟。右边是「流水席」,一做就是一整桌,八个菜同时上。但要等——配菜、切料、摆盘、统筹火候,第一道菜上桌至少要二十分钟。

餐厅刚开业时主打快厨,客人点单三分钟吃到,口碑好,翻台率高。后来接了几个公司团餐的订单,一次性要出几十份,快厨扛不住了——虽然每份只要三分钟,但只有一个灶头,后面的单子得排队,出到第四十份已经等了一个多小时。

老马于是扩建了流水席厨房。八个灶头同时开工,一次出十几份。公司团餐的问题解决了,但新问题出现了:散客点单也被导进了流水席厨房。客人点了份蛋炒饭,等了二十五分钟还没上桌。服务员跑后厨催,厨师说正在炒大锅菜,单份的得等这锅完了才能插进去。

老马坐下来复盘。快厨的单份时间是三分钟——这叫延迟低,但单位时间能出的份数少——这叫吞吐量低。流水席的第一份出餐时间是二十分钟——延迟高,但一个小时能出一百多份——吞吐量高。两套厨房各有所长,问题出在把散客的蛋炒饭送进了流水席的队列。

老马在收银系统上做了分流:散客点单自动进快厨队列,团餐和批量订单进流水席队列。两套厨房各自独立,不再混用。散客继续三分钟吃上饭,团餐客户也能按时拿到整桌菜。

后来有个同行问老马:你不是说流水席吞吐量大吗,为什么单份反而更慢?老马说:吞吐量大是靠批量起步的,单份走批量通道,启动成本就把优势吃掉了。你让一辆跑车拉一车砖,它还没拖拉机快。

老马在厨房墙上贴了一条规则:看速度,问快厨。看总量,问流水席。别拿流水席的数字去解释一道菜的等待时间。

新来的厨师学徒第一天上班,老马先带他到两面墙前面。左墙贴着快厨的规则:一份三分钟,灶头不空等。右墙贴着流水席的规则:一锅十几份,统筹不让灶。老马说:选对厨房,比闷头炒菜重要。

延迟 (Latency)

单个请求从发出到收到完整响应所经历的时间。它是单次操作的速度指标,直接影响用户的等待体验。单位通常是毫秒或秒。

吞吐量 (Throughput)

系统在单位时间内能处理的请求总数。它是整体产能的指标,反映系统的并发处理能力。单位通常是每秒请求数或每分钟 Token 数。

故事对应

  • 快厨三分钟出餐:低延迟,单次操作速度快。
  • 流水席一小时出一百份:高吞吐量,单位时间总产出大。
  • 散客蛋炒饭进了流水席队列:用高吞吐架构处理低延迟需求,启动批量开销吃掉了速度优势。
  • 两套厨房分别排队:延迟优化和吞吐优化通常需要不同的架构策略,不能混用。
  • 跑车拉砖不如拖拉机:每个架构有其适配场景,高吞吐不等于低延迟。

落到项目里

给 AI 模型服务分别设延迟和吞吐的观测面板,别混在一个指标里。交互式场景(聊天、代码补全)盯 P50 和 P95 延迟,数值毫秒级变动直接影响用户感知。批量场景(文档处理、数据标注、离线推理)盯吞吐量,优化方向是批大小、并发数和 GPU 利用率。一个常见的采购失误:用吞吐量数据美化实时产品的响应速度——供应商说「每秒处理五百个请求」,每个请求的 P95 延迟可能已经超过了两秒。