LLM 服务上线后，你最先看到的往往是平均延迟：看起来不高，曲线也稳定。但把请求按耗时排序后会发现，总有少量请求特别慢，甚至直接把客户端拖到超时。平均延迟很漂亮，P99 却高得离谱，这个问题就是 LLM 推理服务里的 tail latency（尾部延迟）。
这次我们聊的不是某个模型效果好不好，而是一个更偏工程的问题：LLM 服务为什么会出现尾部延迟，以及一个足够简单、能直接落地的修复思路。修复 tail latency 不需要把推理框架重写一遍，也不需要囤一柜子高端显卡。大多数情况下，你只要把请求排队、动态批处理、超时策略和监控指标一起理清楚，就能把那个刺眼的 P99 压下来。
这篇文章会分成几个部分：先说明 tail latency 的典型根因，再给出一套从客户端到服务端的可操作修复方案，接着用一个最小压力测试环境，说明如何量化验证修复效果。最后会给出常见的排查注意事项。适合正在做 LLM 本地部署、自建推理服务，或者想把在线服务的延迟稳定性做上去的工程师收藏。
1. 核心能力速览
| 能力项 | 说明 |
|---|---|
| 面向问题 | LLM 推理服务的尾延迟偏高、请求超时、批处理排队不均匀 |
| 常见表现 | 平均延迟正常，P99/P999 明显偏离；长文本请求拖垮短请求；流式输出首个 token 很慢 |
| 修复策略 | 限制最大并发序列、动态批处理、前缀缓存、短请求优先队列、流式响应、客户端超时与重试 |
| 推荐实现方式 | 优先调整推理框架参数；复杂场景再叠加请求网关/代理层 |
| 是否强制专用硬件 | 不强制，CPU 与 GPU 均可测试，按服务压力和模型规模评估 |
| 是否影响模型效果 | 不修改模型权重，只改调度和服务策略，通常不影响生成质量 |
| 是否支持批量任务 | 支持；适合离线批处理场景，也适合在线多路并发 |
| 主要验证指标 | P50、P95、P99、TTFT（首个 token 延迟）、ITL（token 间延迟）、请求错误率 |
| 适合读者 | LLM 服务部署、性能调优、API 网关设计、SRE/后端工程师 |
| 使用边界 | 不涉及模型微调；需确认模型许可证与数据合规；生产环境建议做安全过滤 |
下面所有方案都围绕“可观测、可解释、可回滚”三个原则展开。修复 tail latency，不是靠感觉调参数，而是先测量，再定位，最后做最小变更。
2. 为什么 LLM 服务容易出现尾延迟
2.1 什么是 LLM tail latency
tail latency 是指在一批请求中，尾部请求比大多数请求慢很多的现象。分析网络服务时，我们一般看 P50、P95、P99。如果 P50 是 300ms，P99 却是 8 秒，那么系统就存在明显的尾延迟问题。
LLM 服务有两类延迟指标比普通 Web 服务更值得关注：
- TTFT（Time To First Token）：从发出请求到收到第一个 token 的时间。
- ITL（Inter-Token Latency）：相邻两个输出 token 之间的时间间隔。
用户感知最明显的是 TTFT。尾延迟严重时，某些请求可能等了很久才吐出第一个字，体验上就是“卡住没反应”。
2.2 尾部延迟的典型根因
LLM 服务的尾部延迟，往往不是单一原因造成的。更常见的情况是几个因素叠加，让某些请求比其他请求慢一个数量级。
第一，动态批处理中的队列积压。GPU 推理吞吐量高，靠的是把多个请求拼成一个 batch。但 batch 里只要有一个生成长序列的请求，整个 batch 都会占着计算资源不放。batch 越大，排队和等待时间越长。如果不限制最大并发序列数和最大生成长度，慢请求会不断堆积。
第二，请求输入长度差异过大。prefill 阶段需要处理全部输入 token。一个输入 8000 token 的请求，和输入 50 token 的请求混在一起，前者会让所在 batch 的首 token 延迟显著升高。当这个长线程请求和多个短请求共享一个 batch 时，短请求也会被拖慢。
第三，KV Cache 与显存争抢。生成阶段会不断追加 KV Cache。显存不足时，框架可能触发重新调度或降低并发；多个请求同时竞争显存，分配不均匀就会导致部分请求等待。
第四，客户端超时设置不合理。很多客户端只设置一个固定超时时间，比如 60 秒。平均延迟 10 秒，但 P99 是 40 秒时，偶发网络抖动或服务排队就会让请求直接超时。服务端明明还在跑，客户端已经放弃了。结果就是用户看到一堆 timeout，而服务端日志里却显示“请求成功”。
第五，排队策略不公平。默认的先来先服务，看起来很公平，实际上短请求会被长请求堵塞。如果服务是给聊天和给知识库总结共用，一个长总结任务就可能让后面的聊天请求等很久。
尾部延迟难处理，不是因为它有多深奥，而是它跨了多个层面：客户端、网络、网关、推理框架、GPU 显存、模型本身。修复的思路，也应该分层处理。
3. 适用场景与使用边界
3.1 适合什么场景
如果你的服务有下面这些特点，tail latency 优化往往收益很大：
- 在线交互场景：ChatBot、AI 搜索、代码补全。用户对首个 token 延迟特别敏感，超过 2 到 3 秒就会觉得卡。
- 多租户服务：不同用户请求长短混杂，必须做优先级隔离。
- 批量任务和在线任务共用同一套 GPU 资源：离线任务不影响在线体验，需要做资源切分或请求分级。
- 接口已经出现偶发 timeout，但平均延迟不高：优先怀疑 tail latency，而不是盲目扩机器。
3.2 不适合什么场景
- 模型首次加载就很慢，但运行后延迟稳定：这更多是冷启动和模型加载问题。
- 网络链路本身延迟高或丢包严重：先修网络，再优化服务端。
- 模型本身生成质量差、经常输出超长内容：需要做输出长度约束和后处理，而不是只调调度参数。
3.3 使用边界与合规提醒
本文讨论的是对自托管 LLM 推理服务的配置与调度优化，不涉及绕过任何安全机制的内容。如果你使用开源模型，请先确认模型许可证是否允许商用和二次部署；如果处理的是用户数据或敏感业务数据，要确保数据不出内网、传输加密、日志脱敏。生产环境建议增加输入输出内容过滤、限流和审计，避免模型被滥用。
4. 修复 tail latency 的落地策略
4.1 先给请求排队分级，再做调度
最简单的修复思路，是让短请求和实时请求优先，让长任务排队。实现排队分级，不用自己写分布式调度器，你可以在服务入口做一个内存队列，按请求的预计耗时或任务类型分优先级。
伪代码思路如下：
import asyncio from dataclasses import dataclass from enum import IntEnum class Priority(IntEnum): INTERACTIVE = 0 # 在线聊天/搜索，优先 BATCH = 1 # 离线批量，靠后 @dataclass(order=True) class LLMRequest: priority: Priority seq: int prompt: str max_tokens: int created_at: float这个队列模型的关键是：实时请求永远排在批量任务之前。批量任务可以接受等待，在线请求不能。
4.2 限制并发、限制生成长度
绝大多数推理框架都提供并发序列数控制参数。以 vLLM 为例，常用参数包括--max-num-seqs、--max-model-len、--max-parallel-loading-workers等。TGI 也有类似的并发限制配置。Llama.cpp server 可以通过--parallel控制并发槽位。
使用这些框架时，不要把并发数拉满。你要观察一个关系：并发数上升确实能提高吞吐，但也会让长序列请求阻塞短请求。更稳妥的方式是先按“单卡并发 4 到 8 个序列”起步，再结合你的延迟指标逐步上调。
max_tokens 是另一个容易被忽略的参数。推理服务一旦解码到 max_tokens，就会结束生成。如果不做限制，一个“给我写一篇 8000 字文章”的请求会长时间占用 batch 资源，直接抬高尾部延迟。建议对在线请求设置合理的生成长度上限，比如聊天 512 token，总结类 1024 token，代码生成再单独评估。
4.3 开启前缀缓存或 prompt cache
如果你的业务里存在大量相同前缀的请求，比如固定的人物设定、固定的知识库上下文、固定的 few-shot 示例，那么每次都重新计算 prefill 是极大的浪费。
vLLM 支持 Automatic Prefix Caching（APC），可以自动复用相同前缀的 KV Cache。Llama.cpp server 也提供了相关缓存能力。开启前缀缓存后，TTFT 往往会有明显下降，尤其适合“共用系统提示词 + 用户输入变化”的 Agent 场景。
需要留意的是，前缀缓存会占用额外显存。开启后如果显存变紧张，就要调小缓存上限或降低并发。
4.4 流式输出是第一优先级的修复
在线场景下，强烈建议把所有对话类接口都改成 SSE 流式输出。原因很简单：用户感知时间从“拿到完整结果”变为“第一个 token 出现的时间”。即使总生成时间需要 30 秒，只要首 token 在 1 秒内出现，体验就不会差到哪去。
OpenAI 兼容接口通常支持"stream": true。返回格式为 SSE：
data: {"choices": [{"delta": {"content": "你好"}}]} data: {"choices": [{"delta": {"content": "，世界"}}]} data: [DONE]流式输出不仅改善用户体验，也能减少 HTTP 层长时间无响应导致的客户端超时误判。
4.5 客户端超时与重试策略要配套
服务端优化得再好，客户端也不能用一个固定超时打天下。
正确的做法是分阶段设置超时：
- 建连超时：3 到 5 秒。
- 首 token 超时：15 到 30 秒。
- 总请求超时：根据 max_tokens 和模型速度单独估算，不要一拍脑袋写 60 秒。
重试时加上指数退避和随机抖动，避免所有请求在同一时刻重试打垮服务。
import time import random def next_retry_delay(attempt: int, base_delay: float = 1.0, max_delay: float = 8.0) -> float: delay = min(max_delay, base_delay * (2 ** attempt)) jitter = random.uniform(0, delay * 0.3) return delay + jitter4.6 客户端拿到 429/503 时怎么做
当服务端因为队列积压返回 429 或 503，客户端不能无限重试。429 说明服务端过载，应该退避更长；503 可能说明某个实例正在重启，短暂重试是合理的。更优雅的做法是服务端返回Retry-After头，客户端按这个时间等待。
5. 环境准备与前置条件
要验证 tail latency 修复效果，不需要立即上生产。一台带有 NVIDIA GPU 的 Linux 服务器或本地开发机就够了。如果没有 GPU，也可以先在 CPU 上用较小模型观察排队现象，但性能数字会有较大差异。
复现环境建议准备以下内容：
| 检查项 | 说明 |
|---|---|
| 操作系统 | Linux 为佳，Ubuntu 22.04 这类发行版更易处理 GPU 驱动 |
| GPU 驱动与 CUDA | 按推理框架要求安装，不要盲装最新版 |
| Python | 建议使用 conda 或 venv 隔离环境，版本按所选框架要求 |
| 推理框架 | vLLM、TGI、SGLang、Llama.cpp server 任选其一 |
| 开源模型 | 一个支持对话的模型即可，例如 Qwen、Llama、Mistral 等 |
| 压测脚本 | Python + requests/httpx，或熟悉的压测工具 |
| 磁盘空间 | 模型权重 + 日志 + 缓存，建议预留模型体积 2 倍以上 |
创建测试环境的通用命令如下，实际版本请以框架官方文档为准：
# 以 conda 为例 conda create -n llm-tail-test python=3.10 conda activate llm-tail-test # 安装推理框架，不同框架安装方式差异很大 # pip install vllm # 或使用 Docker 镜像这个最小环境不是用来做完整压测的，而是用来观察三类现象：
- 请求并发时，队列长度怎么变化。
- 长输出请求和短输出请求混合时，短请求是否被阻塞。
- 开启流式输出后，TTFT 是否明显改善。
如果你能在一个受控环境里把 tail latency 的根因复现出来，修复后的对比数据也会更有说服力。
6. 启动一个推理服务并复现问题
6.1 以 vLLM 风格服务为例
下面是使用 vLLM 启动一个 OpenAI 兼容服务的参考命令。实际部署时，模型名称、端口和参数都需要按你的环境调整。
python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name test-model \ --host 127.0.0.1 \ --port 8000 \ --max-model-len 8192 \ --max-num-seqs 8这个命令的关键在于--max-num-seqs 8。它限制了同时处理的序列数量，避免大量请求同时涌入导致资源争抢。--max-model-len控制模型支持的上下文长度；设得太大，prefill 耗时和显存占用都会显著上升。
在复杂生产环境，一个长上下文请求可能把max-num-seqs占满。所以不要把并发数设得过大，设成一个你能接受 P99 数值的区间很重要。
6.2 请求体设计
请求 OpenAI 兼容接口时，建议显式传入max_tokens，避免模型无限生成。示例请求体如下：
{ "model": "test-model", "messages": [ {"role": "system", "content": "你是测试助手，回答尽量简洁。"}, {"role": "user", "content": "用一句话介绍什么是 tail latency。"} ], "max_tokens": 128, "temperature": 0.7, "stream": false }6.3 复现短请求被长请求拖慢
启动服务后，用一个脚本同时发送两类请求：
- A 类请求：输入短，输出长度限制 2048 token，模拟总结类任务。
- B 类请求：输入短，输出长度只给 32 token，模拟在线聊天。
观察 B 类请求的耗时是否明显增加。多数情况下，当 A 类任务占满 batch 时，B 类请求会在队列中等待，TTFT 会被拉高。复现出这个现象，后面的修复优化才有的放矢。
7. 功能测试与效果验证
7.1 测试指标
优化前后，至少记录以下指标：
| 指标 | 含义 | 推荐观测方式 |
|---|---|---|
| P50 | 一半请求的耗时低于该值 | 压测脚本统计 |
| P95 | 95% 请求的耗时低于该值 | 压测脚本统计 |
| P99 | 99% 请求的耗时低于该值 | 压测脚本统计 |
| TTFT | 首个 token 出现时间 | 流式响应计时 |
| 请求超时率 | 超过客户端超时的请求占比 | 客户端统计 |
| 错误率 | 4xx/5xx 比例 | 服务端日志 |
压测脚本不宜一上来就上太重负载。先卡在服务并发数附近，比如把并发客户端数设置为max-num-seqs的 1.5 到 3 倍，更容易暴露排队放大效应。
7.2 Python 压测参考脚本
下面是一个只依赖标准库和 requests 的简单压测脚本。通过concurrent.futures控制并发，记录每个请求耗时并输出分位数。
import concurrent.futures import statistics import time import requests API_URL = "http://127.0.0.1:8000/v1/chat/completions" CONCURRENCY = 16 TOTAL_REQUESTS = 64 def send_one_request(idx: int): payload = { "model": "test-model", "messages": [ {"role": "system", "content": "你是测试助手，请简短回答。"}, {"role": "user", "content": "这是第 %d 个请求，请回答：什么是尾部延迟？" % idx} ], "max_tokens": 64, "stream": False } start = time.perf_counter() try: resp = requests.post(API_URL, json=payload, timeout=120) resp.raise_for_status() return time.perf_counter() - start except Exception as exc: print(f"request {idx} failed: {exc}") return None with concurrent.futures.ThreadPoolExecutor(max_workers=CONCURRENCY) as executor: latencies = list(executor.map(send_one_request, range(TOTAL_REQUESTS))) latencies = [x for x in latencies if x is not None] if latencies: latencies.sort() p50 = statistics.median(latencies) p95 = latencies[int(len(latencies) * 0.95) - 1] p99 = latencies[int(len(latencies) * 0.99) - 1] print(f"total={len(latencies)} p50={p50:.2f}s p95={p95:.2f}s p99={p99:.2f}s")这个脚本只模拟了输出长度固定、输入长度固定的简单场景。正式压测时，至少加一组“长输入 + 短输出”和一组“短输入 + 长输出”的混合负载，才能暴露真实 tail latency。
7.3 测试流式输出对 TTFT 的影响
把"stream": true加入 payload，通过逐行读取 SSE 的方式记录首个 token 时间。看 TTFT 是接近总请求耗时的很大比例，还是只占很小比例。
如果 TTFT 很长，重点检查 prefill 阶段和排队等待。如果 TTFT 正常，但 ITL 很长，重点检查解码效率和 KV Cache 是否频繁驱逐。通过分阶段指标，可以避免“头痛医头”。
7.4 判断修复是否成功的标准
完成配置调整后，重新跑同样的压测脚本，观察三个指标：
- P99 相比优化前下降幅度；
- P99 与 P50 的差距是否收窄；
- 超时率是否归零或降到可接受范围。
如果 P50 差不多，但 P99 大幅下降，说明 tail latency 确实被修复了。如果 P50 和 P99 一起下降，说明吞吐或资源使用也得到了改善。实际操作中，只要 P99/P50 的比值从接近 20 倍降到 3 到 5 倍以内，尾部延迟问题就已经大幅缓解。
7.5 常见失败现象与排查方向
| 现象 | 可能原因 | 优先排查点 |
|---|---|---|
| 压测时大量连接超时 | 并发超过服务能力 | 降低并发数，观察 GPU 利用率 |
| 所有请求都很慢，P50 升高 | 负载本身太重 | 增加实例或降低 max_model_len |
| 短请求被长请求拖慢 | 排队策略不公平 | 将长任务和短任务拆分到不同队列或实例 |
| 开启流式后 TTFT 仍较长 | prefill 太长或队列累积 | 开启前缀缓存，减少长上下文输入 |
| 调低并发后 TPOT 仍不稳定 | 显存或 CPU 瓶颈 | 检查 GPU 功耗、显存交换、CPU 负载 |
8. 接口 API 与批量任务优化思路
如果想快速生效，优先调推理框架参数，而不是自己写代理层。但如果业务复杂，需要一套统一入口来管理规则，可以考虑加上一层轻量级网关。
8.1 网关层可以做什么
- 接受客户端请求，统一鉴权、限流、计量。
- 按请求类型设置优先级：聊天请求进高优队列，离线任务进低优队列。
- 对多个后端实例做负载均衡，避免热点实例。
- 把非流式请求转成流式请求，由网关代理转发给客户端。
用 FastAPI 写一个简单的优先级代理并不难，但要注意：如果后端本身已经支持动态批处理，网关注入过多等待逻辑反而会增加开销。网关只做轻量的头部检查和转发即可。
8.2 离线批量任务建议
如果是离线批量总结、批量抽取信息，不追求实时返回，可以考虑：
- 使用低优先级队列，错开白天在线流量高峰。
- 把长任务拆分为文件级或分片级任务，避免单个任务无限运行。
- 每个任务写入独立日志，方便失败重放。
- 批量请求的
max_tokens要单独控制，防止生成失控。
批量任务最容易踩的坑是“失败重试时全部重放”。正确做法是按任务 ID 记录处理状态，只重放失败的任务。
8.3 防止突发流量打垮服务
无论在线还是离线，入口都要做速率限制。一个最简单的思路是使用令牌桶：
import time class TokenBucket: def __init__(self, rate: float, capacity: int): self.rate = rate self.capacity = capacity self.tokens = capacity self.updated_at = time.monotonic() def acquire(self) -> bool: now = time.monotonic() self.tokens = min(self.capacity, self.tokens + (now - self.updated_at) * self.rate) self.updated_at = now if self.tokens >= 1: self.tokens -= 1 return True return False这个代码只是基础版。生产环境最好直接使用网关自带的限流，例如 APISIX、Kong、或者云厂商 API 网关的限流插件，避免自研轮子出错。
9. 资源占用与性能观察方法
9.1 看哪些指标
观察 LLM 推理服务，不能只盯显存占用和 GPU 利用率。
| 指标 | 观察意义 |
|---|---|
| GPU 显存占用 | 判断是否存在 KV Cache 压力 |
| GPU 计算利用率 | 判断算力是否饱和 |
| 请求队列长度 | 判断是否排队严重 |
| 请求平均输入长度 | prefill 压力来源 |
| 生成长度分布 | 长输出请求是否占多数 |
| TTFT/ITL 分布 | 定位用户感知卡顿的阶段 |
9.2 显存占用与 KV Cache
显存占用不是越高越好。如果显存长期接近 100%，说明 KV Cache 可能已经出现驱逐或竞争。调低max-num-seqs通常能缓解显存压力，但也会降低最大吞吐。
量化模型（如 AWQ、GPTQ、GGUF）能降低显存占用，但对 P99 的影响因量化方法和硬件而异，需要实测后才好下结论。不要因为显存紧张就直接所有模型都上 4bit，还要看业务对生成质量是否敏感。
9.3 性能瓶颈定位思路
如果 GPU 利用率已经很高，P99 却还是很高，说明瓶颈在算力或显存带宽，调度策略能做的有限。如果 GPU 利用率只有 30% 到 50%，P99 却很高，那大概率是排队策略、请求间相互阻塞或网络链路有问题，先查队列长度和请求耗时分布，再决定是否需要扩容。
一个需要反复强调的点：压测时不要让压测机本身成为瓶颈。压测机 CPU 不足、requests 连接池太小，也会导致请求时间和服务端不匹配。用专业工具或者至少留出足够 CPU 余量，数据才会准。
10. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 服务端没有报错，客户端却大量 timeout | 客户端总超时时间小于实际生成耗时 | 查看服务端日志，确认请求是否完成 | 取消固定总超时，改为首 token 超时 + 流式读取 |
| 平均延迟低，P99 高 | 少数长请求占用 batch | 按 max_tokens 分组统计耗时 | 限制 max_tokens，拆分长任务队列 |
| TTFT 高 | prefill 耗时长或队列积压 | 分别统计 TTFT 和总耗时 | 开启前缀缓存，降低输入长度，缩短队列 |
| 显存不足或 OOM | max_model_len 过大、KV Cache 压力大 | 观察显存占用变化 | 调小 max_model_len 或 max_num_seqs |
| 并发一高就卡死 | 服务线程池过小或锁竞争严重 | 查看后端进程线程数 | 调整并发模型，必要时增加后端实例 |
| 开启流式后错误增加 | 代理或网关缓冲了整段 SSE | 检查代理层是否开启缓冲 | 关闭代理缓冲，透传 SSE |
| 修复后 P99 下降但 P50 升高 | 请求按优先级排队，高优请求占用了资源 | 对比分组延迟曲线 | 根据业务调节优先级比例，给高优请求预留容量 |
11. 最佳实践与使用建议
11.1 先量化，再修复
不要一上来就加机器，也不要看到 P99 高就直接把所有请求改成流式。先把耗时分布、输入长度、输出长度、并发数四个维度记录下来，找到最异常的群体，再做针对性修改。
11.2 修改一次，只动一个变量
修复 tail latency 过程中，最忌讳同时改并发、模型长度、前缀缓存、网关策略。一次只动一个变量，跑一轮压测，记录 P50、P99、TTFT，再决定下一步。否则出了问题，你根本不知道是哪个配置改坏了。
11.3 保留一套最小可运行配置
把能够稳定运行的参数组合保存为独立的配置文件，作为回滚基线。配置变更前，记录当前版本号和关键参数；变更后出现问题时，能在分钟级恢复。
一个通用的推荐基线是：
- 对在线服务设置合理的
max_tokens上限。 - 按请求类型或预估 token 数设计优先级队列。
- 开启流式输出。
- 结合服务容量设置客户端超时。
- 长任务不要和在线请求混跑。
11.4 明确安全与合规边界
部署在公网或公司内网的 LLM 服务，都要做好访问控制。接口层要加鉴权，避免未授权调用消耗算力；日志中不要明文记录用户敏感信息；模型输出需要内容过滤和审计。涉及外部用户数据时，要谨慎评估模型与数据的合规要求。批量处理人脸、声音、版权内容等场景，必须确认拥有相应授权。
11.5 从简单修复走向系统优化
“一个简单修复”的起点，往往是把默认配置改成适合自己业务形态的配置。等你理解了排队、批处理、KV Cache 和 timeout 的相互作用之后，就可以继续往更复杂的方向走：多实例路由、按模型做容量隔离、GPU 共享调度、弹性伸缩、基于 P99 的自动扩容规则等。
但先把眼前那条 P99 曲线修好，比什么都实际。
最后提醒一句：你的 GPU 型号、模型版本、推理框架版本都会影响参数效果。文中提到的所有参数，最终都要以你实际环境的压测结果为准。先跑一个最小压测，记录优化前后对比，比到处抄配置更可靠，也更容易在团队里说清楚收益。建议先把这篇文章里的方法用在测试环境里验证一轮，再决定要不要应用在生产服务上。
