LLM应用延迟与吞吐量监控

可视化演示

延迟拆解：一碗面从下单到上桌的旅程

想象你走进一家面馆，坐下扫码下单。从手指按下“提交订单”那一刻到第一根面条送进嘴里，你的等待其实被分割成了好几段：等菜单传进后厨、等厨师烧水下面、等面条被端上桌。如果每一段都慢半拍，这碗面就要等上十几分钟。LLM应用完全一样——用户问了一句“我的订单到哪儿了”，模型在回复之前，背后也有一条清晰的“上餐流水线”。

在LLM的世界里，这条流水线的“菜品”是一个个Token（可以理解为单词或子词片段）。衡量一次请求的快慢，业界把整条链路拆成两个核心阶段：等待第一个Token的“第一口汤”时间，和后续Token逐个蹦出来的“持续上菜”速度。前者叫TTFT（Time To First Token，首Token延迟），后者用TPS（Tokens Per Second，每秒Token数）表示。此外还有从请求发出到最后一个Token落地的端到端延迟，它是整碗面从下单到吃完的时间总和。

先看TTFT，它等于“用户发出请求”的时刻到“收到第一个Token”的时刻之差，记为：

再看TPS，它衡量第一个Token之后模型的生成速度：

回到面馆：TTFT就像你等第一根面条从厨房窗口递出来的时间，TPS则是面条被一根根连续送到你面前的速度。一家好面馆不仅要“第一口快”，更要“后面不卡壳”——LLM服务也是这样，TTFT和TPS两个指标必须同时看，缺一不可。

吞吐量指标：餐厅同时能喂饱多少人

假设面馆只有一位厨师，每位顾客要等10分钟才能吃上一碗面。如果店里同时坐着五位顾客，最后一位顾客可能足足等了50分钟。但如果厨房有五个灶台，情况就完全不同了。这就引出了“吞吐量”：餐厅在单位时间内到底能接待多少位顾客完成用餐。对应到LLM服务，吞吐量通常指单位时间内系统完成的生成请求数或生成的Token总数，它回答的是“这个服务能扛住多少用户”。

吞吐量受两个关键因素支配：同时处理的请求数（并发数）和每个请求的生成速度（TPS）。厨房里同时开火几口锅，每口锅每分钟出几碗面，两者乘起来就是整家店的总出餐能力。对于一个运行稳定的服务，有效吞吐量可以近似表示为：

需要提醒的是，一味增加灶台并不总是好办法——并发开得太多，每口锅的火力反而会被分摊（GPU显存被瓜分），单个请求变慢，甚至触发显存溢出。吞吐量与单请求延迟之间是一场精细的权衡：并发拉到最大时系统吞吐可能最高，但用户侧的TTFT和TPS已经恶化到不可接受了。监控时要用“有效吞吐”而非“理论吞吐”来做容量基线。

回到面馆的比喻：老板不会为了多接待客人就把灶台加到一百个，因为厨房就那么大。他会算出“最佳并发——既能喂饱最多的客人，又不会让每碗面的质量塌方”，这套思路与LLM服务的容量规划完全同构。

队列分析：等位区里藏着的秘密

任何一家热门餐厅门口都有一个等位区。顾客到得多了，座位满了，新到的人只能排队。队伍的长度直接反映了餐厅的“供不应求”程度：队排得越长，说明顾客来的速度远比厨师出餐的速度快。LLM服务前也有一道“等位区”——请求队列。当并发请求超过服务处理能力时，新请求就会进入队列等待。

队列深度（当前排队的请求数）是判断服务负载状态的关键信号。如果队列持续很深，说明系统已经超负荷运转：即使每个请求本身处理得很快，用户真正感受到的响应时间也会因为排队而变得很长。这就像面条做得再快，前面排着二十个人，你也得干等。相反，队列长期为空，则说明服务资源有富余，可以考虑提高并发或缩容省钱。

排队理论中有一条著名的Little定律，它像交通守恒定律一样，把队列中的三个核心量统一了起来：

监控队列深度，就像看餐厅门口的等位人数。等位人数突然暴涨，要么是顾客（请求）来得太猛，要么是厨师（模型推理）出餐速度掉了。顺着这两个方向分别去查到达速率和服务耗时，就能快速锁定问题来自流量的洪峰还是服务能力的塌陷。队列并不是洪水猛兽——适度的排队是系统吸收突发流量的缓冲垫，真正危险的是队列无限增长导致的服务雪崩。

监控工具：后厨的透明看板

一家连锁餐厅的总部想了解每个分店后厨的真实状况，靠打电话问“你那边慢了没”是不靠谱的。正规做法是装一套数字化看板：每个灶台、每个传菜口都装上传感器，总部随时能看到每道菜从下单到出锅的完整时间线。LLM服务的监控工具扮演的正是这个角色——它让每一次请求的内部环节全部透明化。

在LLM可观测性领域，主流开源工具包括Langfuse和Phoenix（Arize Phoenix）。它们的核心能力一致：把一次完整的LLM请求拆成一个Trace（调用链）和若干Span（环节），每个环节记录耗时、Token数、模型名等元数据。工程师在UI上就能看清“输入处理→模型调用→工具调用→输出返回”每一段的耗时占比，就像看后厨每个工位的实时录像。

接入Langfuse一般分两步：配置Endpoint和API Key，然后安装SDK。在Python侧的初始化通常长这样：

接着用SDK提供的装饰器或上下文管理器包装LLM流式调用，就能自动记录TTFT、TPS、Token用量和延迟分布。Phoenix则更偏底层链路追踪，适合与OpenTelemetry生态配合，把Prompt、响应、嵌入向量一并落库，供后续离线分析。两者都支持把监控数据汇总成可视化面板，用时间序列曲线展示P50/P99延迟、队列深度和吞吐量。

有了这块“透明看板”，后厨的一切效率问题都不再是猜谜。哪个环节慢、哪个模型贵、哪个Prompt经常触发超时，一眼就能定位。Langfuse和Phoenix这类工具让LLM运维从“玄学”变成了“科学”——它们采集的数据，正是当前面所有延迟、吞吐、队列指标的源头。

from langfuse import Langfuselangfuse = Langfuse(    public_key="pk-...",    secret_key="sk-...",    host="http://localhost:3000")

瓶颈定位：找到后厨最慢的环节

假设面馆出餐变慢，是面下锅太慢、汤底没熬好、还是服务员传菜太磨蹭？经理拿着一块秒表蹲在后厨，逐个环节计时，很快就会发现真相。LLM服务的性能调优，做的就是同一件事：用监控数据把“变慢”这个笼统的抱怨，拆解成具体环节的具体数字。

LLM推理的两个阶段速度差异巨大。Prefill阶段（处理用户的提示词Prompt）是一次性并行计算，通常很快；Decode阶段（逐个生成Token）是逐Token串行完成的，往往占据大头。如果监控显示TTFT暴涨，问题大概率在Prefill或排队环节；如果TPS偏低，则往往指向Decode阶段的显存带宽或模型结构瓶颈。就像面馆里，如果“第一口”等很久，可能是下单流程堵了；如果“后面上菜慢”，可能是煮面锅的产能不行。

常见的瓶颈点有三个。第一是显存：模型权重加上KV Cache是否挤爆了GPU，显存不足会触发换页，速度断崖式下跌。第二是推理引擎：vLLM、TGI等引擎的优化程度差异巨大，是否开启PagedAttention、是否启用连续批处理，直接影响吞吐上限。第三是模型参数：模型参数量与量化精度（FP16还是INT8）共同决定单卡吞吐，更大的模型不一定更聪明，但一定更慢。

定位瓶颈时重点看两块监控数据：GPU显存利用率和KV Cache的命中情况。显存长期逼近100%说明硬件是短板；显存还有富余但TPS仍然上不去，说明引擎配置或模型结构才是瓶颈。这两个信号能帮你快速区分是“硬件不够”还是“引擎没调好”。用秒表逐环节计时是件看似枯燥的事，却是调优中最值得的投资——至少你不会在“汤底不够鲜”的问题上白白加十口锅。

优化策略：让厨房真正跑起来

找到了瓶颈，下一步就是改造厨房。聪明的面馆老板不会只买一口更大的锅，他会统筹安排：错峰备料、批量下面、把常点的浇头提前煮好。LLM服务也一样，优化不是单一技巧，而是一套组合拳——针对前面定位到的瓶颈，选择性地施药。

最有效的三招是动态批处理、并发控制和缓存复用。动态批处理（Continuous Batching）把多个请求拼成一个batch喂给模型，摊薄计算开销——就像厨师把四碗面同时下进一口大锅，虽然单碗面没变快，但整体的“出餐总量”大幅提升。vLLM等推理框架默认支持该特性，生产环境应优先开启。

并发控制通常在网关层实现，用信号量限制同时进行的模型调用数量。这听起来和“提高吞吐”矛盾，但实际防止了过载雪崩：当并发超过服务能力时，每个请求都被拖慢，吞吐反而下降。就像餐厅不会让所有客人同时挤进后厨，而是在门口限流，保证每位已入座的客人都能按时吃上饭。缓存复用则分两种：对重复的Prompt前缀做KV Cache复用，能省去重复的Prefill计算；对常见问题做结果缓存，命中后延迟能降到十几毫秒，几乎等于免费上菜。

优化生效后，监控数据会告诉你一切：TTFT下降了吗？TPS上升了吗？队列深度回到安全水位了吗？记住，性能调优不是一锤子买卖，而是“监测→定位→优化→再监测”的循环。每一次微小的优化，都会让下一碗面的上桌时间更短一点；而持续的循环迭代，才能让系统的每一项指标都稳步逼近目标值。厨房的改造永无止境，但方向和依据永远来自那块看板上的数字。

AI 应用场景

Python 演示

import randomimport time  def simulate_token_stream(start_time, ttft, tps, total_tokens=50):    """Simulate a token arrival timeline for one LLM request."""    events = []    first_token_time = start_time + ttft    for i in range(total_tokens):        if i == 0:            t = first_token_time        else:            interval = random.expovariate(tps)            t = events[-1][0] + interval        events.append((t, i + 1))    return events  def compute_metrics(events, request_start):    """Compute TTFT, TPS and total latency from token timeline."""    first_token = events[0][0]    last_token = events[-1][0]    total_tokens = len(events)    ttft = first_token - request_start    generation_time = last_token - first_token    tps = total_tokens / generation_time if generation_time > 0 else 0.0    total_latency = last_token - request_start    return {        "ttft_s": round(ttft, 3),        "tps": round(tps, 3),        "total_tokens": total_tokens,        "total_latency_s": round(total_latency, 3),    }  def simulate_concurrent_load(concurrency, ttft, tps, tokens=50):    """Estimate effective throughput under concurrent requests."""    req_list = []    for _ in range(concurrency):        start = time.time() + random.uniform(0, 0.5)        events = simulate_token_stream(start, ttft, tps, tokens)        req_list.append(compute_metrics(events, start))    total_tokens = sum(m["total_tokens"] for m in req_list)    total_time = max(m["ttft_s"] + m["total_tokens"] / m["tps"] for m in req_list)    throughput = total_tokens / total_time if total_time > 0 else 0.0    return throughput  def main():    random.seed(42)    start = time.time()    events = simulate_token_stream(start, ttft=0.8, tps=15.0)    m = compute_metrics(events, start)    print("=== Single Request Metrics ===")    print("TTFT (s):", m["ttft_s"])    print("TPS (tokens/s):", m["tps"])    print("Total tokens:", m["total_tokens"])    print("Total latency (s):", m["total_latency_s"])     tp = simulate_concurrent_load(10, ttft=0.8, tps=15.0)    print("\n=== Concurrent Throughput (10) ===")    print("Effective throughput (tokens/s):", round(tp, 2))  if __name__ == "__main__":    main()

1. events = simulate_token_stream(start, ttft=0.8, tps=15.0)生成一份带真实时间戳的Token到达时间表，模拟一次流式响应
2. interval = random.expovariate(tps)用指数分布模拟Token生成间隔，均值正好等于1/TPS，符合LLM解码过程的统计特性
3. ttft = first_token - request_start首个Token时间戳减去请求发出时间戳，就是首Token延迟TTFT
4. tps = total_tokens / generation_time总Token数除以纯生成耗时，得到每秒生成Token数
5. total_time = max(m["ttft_s"] + m["total_tokens"] / m["tps"] for m in req_list)一批并发请求中，最后完成的那个请求决定整批耗时，这是有效吞吐的计算基础
6. tp = simulate_concurrent_load(10, ttft=0.8, tps=15.0)模拟10个并发请求，估算系统在给定并发下的总吞吐量
7. random.seed(42)固定随机种子，保证每次运行结果可复现，方便调优前后对比

常见误区

面试题