尧图网站开发 
如果你正在维护一个 LLM 在线服务大概率见过这种诡异现象接口平均延迟不算高但每隔一段时间就出现一次几十秒的超时P50 明明不到 300 毫秒P99 却直接冲到 20 秒以上。更让人头疼的是负载不高GPU 没有跑满日志里也没报错唯一能看到的规律是总有一两个请求特别“刺眼”——要么 prompt 特别长要么 max_tokens 设得特别大一个人把整个 batch 的节奏都带崩了。这类问题常被笼统地归结为“模型推理太慢”然后团队开始加 GPU、做量化、换推理框架。但很多时候真正的根因不在模型本身而在于请求调度和队列设计。尾部延迟tail latency是一个系统工程问题容量只是其中的一个变量。本文要讲的是一个几乎不依赖硬件的“简单修复”思路在请求入口层做分级、限制长度、快速失败把拖垮 P99 的长尾请求从主队列里隔离出去。整套方案不优雅但足够简单适合绝大多数中小团队直接落地。1. 这篇文章真正要解决的问题先说清楚本文的边界。我们讨论的是“在线 LLM 推理服务”的尾延迟问题比如你封装了一个 OpenAI 兼容的 chat/completions 接口背后跑着 vLLM、TGI 或其他推理框架客户端是 Web 应用或 Agent 程序。这类服务最容易出现的一个典型症状是P50 / P95 很好P99 突然烂掉单看请求量并不大GPU 利用率也不饱和偶尔有一两个请求耗时特别长直接打爆客户端超时一旦客户端超时后自动重试服务端雪上加霜延迟进一步恶化。如果只看表面很容易得出“模型能力不行”“GPU 不够”的结论。但从调度视角看这类问题的本质是短请求和长请求混在同一个队列和同一个 batch 里短请求被长请求的排队时间和解码时间拖累。一个简单的比喻银行柜台同时服务“存 100 块”和“办 2 小时公积金贷款”的客户。如果都排同一条队存钱客户大概率会被贷款客户堵死。LLM 推理里的长 prompt 和超大 max_tokens就是那个办 2 小时贷款的客户。这篇博客适合以下读者正在自建 LLM API 服务的后端开发者负责推理服务稳定性、性能优化的 SRE 或平台工程师使用 vLLM/TGI 但对延迟曲线不满意又不想一开始就上复杂架构的团队。读完你至少能解决三件事知道 LLM 服务尾延迟主要从哪里来掌握一套不依赖推理框架内部实现的入口层修复方案拿到可以直接改的 Python 网关代码和验证方法。2. 先搞清楚 LLM 的延迟到底在哪里要修复尾延迟先得知道一次 LLM 请求的时间花在哪里。和传统 Web 接口不同LLM 的延迟不是单一数字而是由几个阶段叠加而成。阶段含义对应指标通常耗时量级排队延迟请求进入服务后等待被调度的时间Queueing Delay依赖负载可能从毫秒到秒级Prefill 阶段处理输入 prompt生成第一个 tokenTTFTTime To First Token随 prompt 长度线性增长Decode 阶段逐个生成后续 tokenTPOTTime Per Output Token也叫 TBT每个 token 毫秒级总耗时随 max_tokens 线性增长网络传输请求从客户端到服务端、响应回传End-to-End Latency通常较小跨地域时需要注意对在线交互应用来说最难受的往往不是排队的平均时间而是 P99 的“拐点”。一次请求如果排队等了 2 秒prefill 又因为 prompt 太长扫了 3 秒decode 因为 max_tokens 设成 2048 再跑 10 秒叠加起来就是一次灾难性的超时。另一个容易混淆的地方是“并发越高越慢”。LLM 推理框架倾向于把多个请求拼成一个 batch 来提高吞吐这是 GPU 计算特性决定的批量计算比逐个计算更划算。但 batch 的代价是同一 batch 内的所有请求共享同一个调度节奏任何一个慢请求都可能拖住其他请求的 step。这里有一个新手容易误解的点以为 tail latency 主要是“模型本身每次推理快慢不一致”。实际上在动态批处理continuous batching机制下模型单次 forward 的时间相对稳定真正的不稳定来自请求之间的相互作用和队列策略。P99 高往往不是模型抖动而是调度抖动。3. 为什么 batch 越大P99 越难看要理解 tail latency必须理解主流的 LLM 推理框架是怎么“拼车”的。早期的静态 batching 很简单攒够 N 个请求一起 forward等所有请求都生成完再把这批结果一起返回。这种方式吞吐稳定但 tail latency 很惊人因为一旦 batch 里有一个 max_tokens 特别大的请求其他几个早就生成完的请求也只能干等白白被拖累。后来 vLLM、TGI 等框架引入了迭代级调度iteration-level scheduling也就是连续批处理continuous batching。它把“请求”粒度拆成“step”粒度每执行完一个 decode step就检查有没有请求已经结束有就移除位置并允许新请求插入。这大大提高了 GPU 利用率和响应速度但副作用依然存在长序列请求长时间占用 slot。一个 max_tokens2048 的请求哪怕 prompt 很短也要连续占住一个 batch 位置几十甚至上百个 step。它不结束新请求就无法插到相同位置。prefill 与 decode 竞争。新请求的 prefill 阶段计算量很大会把正在进行的 decode 步长显著拉长导致 batch 内所有请求同时变慢。排队策略不公平。如果队列是简单的 FIFO一个长 prompt 请求排在你前面你就得等它 prefill 完。它 prefill 慢会拉高后面所有短请求的 TTFT。现实中一个服务如果同时存在“几百 token 的聊天请求”和“几千 token 的文档总结请求”后者的存在会系统性抬高前者的 P99。短请求不仅是“被延迟”而是“被长请求锁住”。这也是为什么说 tail latency 问题是“结构性”的只要长短请求共享排队和 batchP99 就很难好看。解决思路无非两条要么从调度上隔离长短请求要么从入口控制请求长度分布。本文的方案是后者为主因为它实现成本最低不需要改动推理框架。4. 最容易走错的三个修复方向在给出方案前先列出我见过的大量团队包括我自己早期踩过的坑会走的弯路。4.1 盲目加 GPU很多人看到 P99 高第一反应是“算力不够”于是加卡。加卡能提升整体吞吐但不一定能削平 tail latency。如果瓶颈是某个长请求长时间霸占 batch slot或者队列策略不公平再加多少 GPU短请求照样可能排在长请求后面。加卡只会让平均延迟变好不会修复调度问题。4.2 无上限放开 max_tokens很多后端为了灵活性直接把客户端的max_tokens原样透传给推理框架甚至不传时让框架用默认最大值。这相当于让每一个调用方都能申请“无限制的算力配额”。某个 Agent 程序一旦写错逻辑可能出现长达几千 token 的循环生成一次请求消耗的 GPU 时间等于几百次短请求。4.3 客户端无限重试客户端发现超时后立刻重试是另一种常见的自伤行为。服务端一旦出现某个慢请求客户端重试只会把更多请求压进队列形成“重试风暴”。慢请求还没处理完新的重试请求又把队列堆满最终从 P99 恶化成整体不可用。这三种做法都不是在“修复” tail latency而是在“掩盖”或“放大”问题。真正的修复需要从请求生命周期的最前端下手进入队列之前就完成分类、限流和超时策略。5. 核心方案请求分级 长度上限 快速失败本文推荐的“简单修复”由三个独立但互补的手段组成。它们不依赖推理框架内部实现可以在网关层完成风险低、可回滚、容易理解。5.1 请求分级让短请求先走核心规则很简单请求进入网关时根据 prompt 长度和 max_tokens 大小分成两类短请求高优先级prompt 短、max_tokens 小这些往往是交互式聊天、接口调用、简单问答。长请求低优先级prompt 长或 max_tokens 大这些往往是文档总结、离线分析、Agent 长任务。短请求进入优先队列长请求进入普通队列。只要短请求队列里有任务worker 就优先处理短请求。这个做法的价值在于把“长短请求互相拖累”变成“长短请求自然隔离”。短请求的 P99 会大幅下降长请求的延迟会上升但长请求本身对延迟敏感度低用户本来就会等更久。对业务来说这是一个合理的取舍。需要注意短请求优先并不是“完全饿死长请求”。实际实现中可以给长请求设置一个最大排队超时保证它最终会被处理或者直接拒绝并让客户端稍后重试。5.2 服务端强制长度上限不要信任客户端的 max_tokens 参数。真正的兜底应该在服务端。具体来说需要在网关入口做两层限制输入长度限制对 prompt 的总字符数或预估 token 数设上限超过直接返回 4xx或者要求客户端先做摘要/分块。输出长度限制对 max_tokens 设上限例如默认 256最大不超过 1024。如果客户端传的值大于上限可以截断也可以返回错误。更稳妥的做法是截断并用响应头告知客户端实际生效值。这一步能直接掐掉“一个请求耗尽整机算力”的最坏情况。它看起来简单粗暴但在生产环境中非常有效。5.3 排队超时快速失败第三件套是给排队加超时。很多 tail latency 的极端值来自“请求孤零零地排在队列里等到超时才报错”。与其让客户端傻等不如在服务端设置一个明确的排队超时阈值。超过阈值立即返回 503 或 429并附上“请稍后重试”的说明。这个做法把不确定的等待变成确定的快速失败。对客户端来说收到一个明确错误比无限等待更容易处理对服务端来说排队长度被限制在可控范围不至于出现“几百个请求堆在内存里慢慢腐烂”。三件套合起来的思路是把请求流量在入口处整理成一个“可控、可分类、可拒绝”的形状而不是把所有的随机性都丢给推理框架去消化。6. 代码实现一个最小的 LLM 网关排队器下面用 FastAPI asyncio 实现一个最小可运行的网关。它在最前面加了双优先级队列、长度限制和排队超时后端指向任意一个 OpenAI 兼容接口。6.1 项目结构整个 demo 只有两个文件. ├── gateway_demo.py # FastAPI 网关 └── requirements.txt # 依赖依赖文件内容如下fastapi uvicorn httpx6.2 完整代码# 文件路径gateway_demo.py import asyncio import itertools import os import time import uuid from contextlib import asynccontextmanager from dataclasses import dataclass, field import httpx from fastapi import FastAPI, Request from fastapi.responses import JSONResponse # 后端真实 LLM 推理服务地址例如 vLLM BACKEND_URL os.environ.get(BACKEND_URL, http://127.0.0.1:8000) # 短请求判断阈值 SHORT_PROMPT_CHARS int(os.environ.get(SHORT_PROMPT_CHARS, 2000)) SHORT_MAX_TOKENS int(os.environ.get(SHORT_MAX_TOKENS, 128)) # 排队超时和端到端超时 QUEUE_TIMEOUT float(os.environ.get(QUEUE_TIMEOUT, 5.0)) HTTP_TIMEOUT float(os.environ.get(HTTP_TIMEOUT, 90.0)) # 并发 worker 数量 WORKER_COUNT int(os.environ.get(WORKER_COUNT, 2)) # 输入输出硬限制 MAX_PROMPT_CHARS int(os.environ.get(MAX_PROMPT_CHARS, 100000)) MAX_OUTPUT_TOKENS int(os.environ.get(MAX_OUTPUT_TOKENS, 1024)) dataclass(orderTrue) class LLMRequest: priority: int seq: int field(compareFalse) created_at: float field(compareFalse) request_id: str field(compareFalse) payload: dict field(compareFalse) class LLMGateway: def __init__(self) - None: self.queue: asyncio.PriorityQueue asyncio.PriorityQueue() self.counter itertools.count() self.client httpx.AsyncClient(timeoutHTTP_TIMEOUT) self.workers [ asyncio.create_task(self._worker(i)) for i in range(WORKER_COUNT) ] async def submit(self, priority: int, payload: dict) - dict: loop asyncio.get_running_loop() future: asyncio.Future loop.create_future() req LLMRequest( prioritypriority, seqnext(self.counter), created_attime.monotonic(), request_iduuid.uuid4().hex, payloadpayload, ) await self.queue.put((req.priority, req.seq, req, future)) try: return await asyncio.wait_for(future, timeoutQUEUE_TIMEOUT HTTP_TIMEOUT) except asyncio.TimeoutError: raise TimeoutError(request timeout in gateway) async def _worker(self, worker_id: int) - None: while True: _, _, req, future await self.queue.get() waiting time.monotonic() - req.created_at # 排队时间已经超过阈值不再调用后端直接快速失败 if waiting QUEUE_TIMEOUT: if not future.done(): future.set_exception(TimeoutError(dequeued after timeout)) self.queue.task_done() continue try: resp await self.client.post( f{BACKEND_URL}/v1/chat/completions, jsonreq.payload, ) resp.raise_for_status() if not future.done(): future.set_result(resp.json()) except Exception as exc: if not future.done(): future.set_exception(exc) finally: self.queue.task_done() gateway: LLMGateway | None None asynccontextmanager async def lifespan(app: FastAPI): global gateway gateway LLMGateway() yield if gateway: await gateway.client.aclose() for t in gateway.workers: t.cancel() app FastAPI(titlellm-tail-latency-gateway, lifespanlifespan) def classify(payload: dict) - int: 返回 0 表示短请求放入优先队列返回 1 表示长请求放入普通队列。 messages payload.get(messages, []) prompt_chars sum(len(m.get(content, )) for m in messages) max_tokens int(payload.get(max_tokens, 0) or 0) if prompt_chars SHORT_PROMPT_CHARS and max_tokens SHORT_MAX_TOKENS: return 0 return 1 app.post(/v1/chat/completions) async def chat_completions(request: Request): if gateway is None: return JSONResponse(status_code503, content{error: gateway not ready}) payload await request.json() # 1. 输入长度硬限制 total_chars sum(len(m.get(content, )) for m in payload.get(messages, [])) if total_chars MAX_PROMPT_CHARS: return JSONResponse( status_code413, content{error: prompt too long, please split or summarize} ) # 2. 输出长度硬限制 max_tokens int(payload.get(max_tokens, 0) or 0) if max_tokens MAX_OUTPUT_TOKENS: payload[max_tokens] MAX_OUTPUT_TOKENS # 3. 分类并提交 priority classify(payload) try: result await gateway.submit(priority, payload) return result except TimeoutError: return JSONResponse( status_code503, content{error: queue timeout, please retry later} ) except Exception as exc: return JSONResponse(status_code502, content{error: str(exc)})这段代码的关键逻辑有三点classify负责把请求分成两类。这里的阈值先用SHORT_PROMPT_CHARS和SHORT_MAX_TOKENS两个环境变量控制方便不同业务调整。LLMGateway.submit里用了asyncio.wait_for对每个请求都设置了端到端超时同时 worker 出队后还会再检查一次排队时长超过QUEUE_TIMEOUT就不调用后端直接抛错返回 503。这实现了“快速失败”。入口处对max_tokens做了硬截断防止客户端传一个巨大的值。6.3 运行与接入先用 uvicorn 启动网关BACKEND_URLhttp://127.0.0.1:8000 \ SHORT_PROMPT_CHARS2000 \ SHORT_MAX_TOKENS128 \ QUEUE_TIMEOUT5 \ python -m uvicorn gateway_demo:app --host 0.0.0.0 --port 8080注意BACKEND_URL要指向你真实的推理服务比如 vLLM 启动的 OpenAI 兼容服务。网关启动后客户端只需把请求地址从原来的后端地址改成http://你的网关:8080/v1/chat/completions即可。请求体兼容 OpenAI 格式。7. 在推理框架中的落地配置网关只是入口层真正的推理框架也需要配合调整。以下配置以 vLLM 为例但思路适用于大多数推理框架。7.1 vLLM 启动配置vLLM 的常见启动命令有两种风格取决于版本。较新的版本推荐使用vllm servevllm serve Qwen/Qwen2.5-7B-Instruct \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --trust-remote-code如果你的版本是旧版api_server入口命令类似python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --max-model-len 32768 \ --gpu-memory-utilization 0.9这里需要注意--max-model-len控制的是模型能接受的最大上下文长度但这个值等于“输入长度 输出长度”。如果服务端不额外限制客户端传一个prompt20000、max_tokens20000的请求它仍然可能打满整个上下文窗口。因此网关层的MAX_PROMPT_CHARS和MAX_OUTPUT_TOKENS实际上比框架配置更重要它们是第一道闸门。另一个在 vLLM 中值得开启的功能是前缀缓存prefix caching。它对包含大量公共前缀的请求比如系统提示词固定的 Agent 调用有显著加速效果但不同版本开关参数不同建议查阅你所用版本的官方文档。这里不展开。7.2 Nginx 超时配置如果前面还挂了 Nginx需要合理配置超时时间避免 Nginx 提前切断请求而网关层的超时策略完全失效。upstream llm_gateway { server 127.0.0.1:8080; keepalive 32; } server { listen 443 ssl; server_name llm.example.com; location /v1/chat/completions { proxy_pass http://llm_gateway; proxy_connect_timeout 5s; proxy_send_timeout 300s; proxy_read_timeout 300s; proxy_http_version 1.1; proxy_set_header Connection ; } }这里的核心原则是Nginx 的超时时间必须大于网关到后端的超时时间否则 Nginx 会先于网关切断请求客户端拿到的错误信息也失去意义。建议把proxy_read_timeout设成网关端到端超时的 1.5 倍以上。7.3 客户端约束服务端修复只是兜底客户端也必须配合所有调用方必须显式设置max_tokens不能依赖框架默认值重试次数限制在 2 次以内并采用指数退避对长文本任务先做分块或摘要而不是一次性提交整个文档客户端超时要大于服务端超时否则你永远只能看到“客户端超时”而不是服务端真实错误。8. 效果验证怎么证明它真的有效任何优化都要有验证。下面是一套不需要复杂压测平台的验证方法。8.1 压测前先定指标不要只看平均延迟至少要对比四个数字P50正常情况下的体感延迟P99长尾请求的恶化程度错误率特别是 5xx 和 4xx 比例排队超时比例如果这个指标很高说明后端容量确实不够调度优化已经到极限。8.2 构造混合流量压测真实场景中长短请求是混合出现的。用下面的 Python 脚本模拟一部分请求模拟短问答一部分模拟长文档总结。# 文件路径mix_load.py import json import random import threading import time import urllib.request GATEWAY_URL http://127.0.0.1:8080/v1/chat/completions TOTAL 200 CONCURRENCY 10 SHORT_RATIO 0.8 results [] def send_one(idx: int): is_short random.random() SHORT_RATIO if is_short: prompt 用一句话解释什么是数据库索引 max_tokens 64 else: prompt 请对下面这段技术文档做一份 500 字以内的摘要 数据库索引是... * 200 max_tokens 512 body json.dumps({ model: test, messages: [{role: user, content: prompt}], max_tokens: max_tokens, }).encode(utf-8) req urllib.request.Request(GATEWAY_URL, databody, headers{Content-Type: application/json}) start time.time() try: with urllib.request.urlopen(req, timeout60) as resp: resp.read() status ok except Exception as exc: status type(exc).__name__ cost time.time() - start results.append((idx, status, cost)) threads [] for i in range(TOTAL): t threading.Thread(targetsend_one, args(i,)) threads.append(t) for t in threads[:CONCURRENCY]: t.start() for t in threads[CONCURRENCY:]: t.start() threads[t - CONCURRENCY].join() # 简易信号量控制并发 for t in threads: t.join() costs sorted([r[2] for r in results if r[1] ok]) if costs: n len(costs) print(f成功请求数: {n}) print(fP50: {costs[int(n * 0.50)]:.3f}s) print(fP95: {costs[int(n * 0.95)]:.3f}s) print(fP99: {costs[int(n * 0.99)]:.3f}s if n 100 else 请求数不足无法计算P99) error_rates {} for _, status, _ in results: error_rates[status] error_rates.get(status, 0) 1 print(f错误分布: {error_rates})这个脚本比较粗糙但足以观察出优化前后的差异。建议在同一个后端、同一批 GPU 负载下分别测“没有网关直连后端”和“经过网关”两种模式看 P50、P99 和错误率的变化。8.3 判断标准从设计上看这套方案应该产生以下效果短请求的 P99 显著下降因为不再被长请求抢在前头整体端到端 P99 会被削平但代价是长请求的一部分从“超长耗时”变成“快速失败返回 503”服务端 GPU 利用率可能略微下降因为有些长请求被拦截了但这属于主动放弃低价值请求换取了更稳定的服务质量如果压测中发现短请求 P99 没有改善优先检查是否真的把请求分类对了以及 worker 数量是否充足。这里要特别说明上面的“预期”是从机制上推断的不是某次具体压测的结论。不同模型、不同框架、不同流量分布下数字会有差异但结构性改善的方向是一致的。9. 常见问题与排查思路问题现象可能原因排查方式解决方案P99 高但 P50 不高长短请求混排短请求被长请求拖累看网关日志中短请求的排队等待时间启用短请求优先队列调整后大量 503排队超时设置过短或后端真的处理不过来拆分排队耗时和后端耗时先看后端 P95再决定调大超时还是扩容客户端反馈超时但服务端日志没有对应请求网关前的 Nginx 或负载均衡超时太短检查所有代理层的 timeout 配置将代理超时设为大于网关端到端超时请求被截断后用户不满意服务端强制截断 max_tokens查看实际响应中的 token 数量根据业务场景调整 MAX_OUTPUT_TOKENS或对长任务走单独异步接口加机器后 P99 还是高调度策略仍是 FIFO长请求继续堵住队列观察队列长度和慢请求占比入口分级 快速失败某客户端疯狂重试导致雪崩客户端无限制重试看网关日志中同一请求 id 的重复出现客户端限制重试次数 指数退避排查 tail latency 问题时最重要的顺序是先确认延迟发生在“排队”还是“生成”再决定是调调度还是调容量。如果网关日志里排队时间只有几毫秒大量时间都花在httpx调用后端上那问题在后端推理如果排队时间占了总耗时的一半以上才轮到调度策略优化。10. 最佳实践与工程建议上面这套“简单修复”可以快速止血但如果要在生产环境长期稳定运行还需要补齐以下工程细节。10.1 监控指标至少采集四类指标每个请求的排队耗时、prefill 耗时、decode 耗时、端到端耗时短请求和长请求各自的 P50 / P95 / P99队列当前长度、worker 数量、超时拒绝次数后端推理服务的 GPU 利用率、batch 大小、每 step 耗时。有了这些数据你才能回答“今天 P99 变差了是因为流量异常还是某个长尾请求出现还是后端变慢”。10.2 超时分层设计一套合理的超时配置应该是分层的客户端超时 网关端到端超时网关端到端超时 Nginx 代理超时网关排队超时 后端单请求最大耗时。如果各层超时互不匹配就会出现“客户端等 30 秒Nginx 10 秒就切断网关还被蒙在鼓里”的尴尬局面。10.3 长度限制要写入 API 文档不要只做代码限制还要把规则写进 API 文档。明确告诉调用方请求的最大输入长度是多少max_tokens 的上限是多少超过限制会被拒绝还是截断长任务应该使用哪些异步接口。这样能减少开发团队之间的沟通成本也能让调用方提前对自己请求做裁剪。10.4 留一个绕过通道生产环境要留一个白名单通道给少量确实需要超长上下文的高价值任务使用。比如在网关识别一个内部 header跳过短请求分类直接进入长请求队列。这样你可以在不修改代码的情况下支持极少数特殊场景。10.5 先小流量灰度任何网关改动都建议先小流量灰度。把网关部署在测试环境用录制回放或影子流量验证一段时间确认不会引入错误后再逐步切流量。11. 总结与后续学习方向回到最初的问题LLM 在线服务的 tail latency 为什么难修因为它的根因往往埋在请求调度和队列结构里而不在模型计算本身。加 GPU、优化算法固然有效但成本高、见效慢。相比之下“请求分级 长度上限 快速失败”是一套几乎不依赖硬件的入口层方案它通过改变进入推理框架的流量形状让系统不会因为少数极端请求而整体失控。本文给出的网关代码和验证方法可以直接跑通。你可以把它理解成给 LLM 服务装了一个“交通分流闸门”短请求走快速通道长请求走慢速通道排队过久直接拒绝。它不优雅却足够有效适合大多数中小团队作为第一道防线。如果想继续深入下一步值得研究的方向有三个Prefix Caching对相同系统提示词或文档前缀做 KV Cache 复用能明显减少 prefill 延迟Chunked Prefill 和 PD 分离把 prefill 和 decode 放在不同实例上是更彻底的长短请求隔离方案基于延迟的弹性伸缩根据 P99 和排队长度自动扩缩容而不是只看 GPU 利用率。把这套入口层修复先落地再根据监控数据决定是否需要更进一步是比较稳妥的节奏。希望这篇文章能帮你把 P99 的诡异峰值变成一个可控、可解释、可优化的工程问题。 
如果你正在维护一个 LLM 在线服务大概率见过这种诡异现象接口平均延迟不算高但每隔一段时间就出现一次几十秒的超时P50 明明不到 300 毫秒P99 却直接冲到 20 秒以上。更让人头疼的是负载不高GPU 没有跑满日志里也没报错唯一能看到的规律是总有一两个请求特别“刺眼”——要么 prompt 特别长要么 max_tokens 设得特别大一个人把整个 batch 的节奏都带崩了。这类问题常被笼统地归结为“模型推理太慢”然后团队开始加 GPU、做量化、换推理框架。但很多时候真正的根因不在模型本身而在于请求调度和队列设计。尾部延迟tail latency是一个系统工程问题容量只是其中的一个变量。本文要讲的是一个几乎不依赖硬件的“简单修复”思路在请求入口层做分级、限制长度、快速失败把拖垮 P99 的长尾请求从主队列里隔离出去。整套方案不优雅但足够简单适合绝大多数中小团队直接落地。1. 这篇文章真正要解决的问题先说清楚本文的边界。我们讨论的是“在线 LLM 推理服务”的尾延迟问题比如你封装了一个 OpenAI 兼容的 chat/completions 接口背后跑着 vLLM、TGI 或其他推理框架客户端是 Web 应用或 Agent 程序。这类服务最容易出现的一个典型症状是P50 / P95 很好P99 突然烂掉单看请求量并不大GPU 利用率也不饱和偶尔有一两个请求耗时特别长直接打爆客户端超时一旦客户端超时后自动重试服务端雪上加霜延迟进一步恶化。如果只看表面很容易得出“模型能力不行”“GPU 不够”的结论。但从调度视角看这类问题的本质是短请求和长请求混在同一个队列和同一个 batch 里短请求被长请求的排队时间和解码时间拖累。一个简单的比喻银行柜台同时服务“存 100 块”和“办 2 小时公积金贷款”的客户。如果都排同一条队存钱客户大概率会被贷款客户堵死。LLM 推理里的长 prompt 和超大 max_tokens就是那个办 2 小时贷款的客户。这篇博客适合以下读者正在自建 LLM API 服务的后端开发者负责推理服务稳定性、性能优化的 SRE 或平台工程师使用 vLLM/TGI 但对延迟曲线不满意又不想一开始就上复杂架构的团队。读完你至少能解决三件事知道 LLM 服务尾延迟主要从哪里来掌握一套不依赖推理框架内部实现的入口层修复方案拿到可以直接改的 Python 网关代码和验证方法。2. 先搞清楚 LLM 的延迟到底在哪里要修复尾延迟先得知道一次 LLM 请求的时间花在哪里。和传统 Web 接口不同LLM 的延迟不是单一数字而是由几个阶段叠加而成。阶段含义对应指标通常耗时量级排队延迟请求进入服务后等待被调度的时间Queueing Delay依赖负载可能从毫秒到秒级Prefill 阶段处理输入 prompt生成第一个 tokenTTFTTime To First Token随 prompt 长度线性增长Decode 阶段逐个生成后续 tokenTPOTTime Per Output Token也叫 TBT每个 token 毫秒级总耗时随 max_tokens 线性增长网络传输请求从客户端到服务端、响应回传End-to-End Latency通常较小跨地域时需要注意对在线交互应用来说最难受的往往不是排队的平均时间而是 P99 的“拐点”。一次请求如果排队等了 2 秒prefill 又因为 prompt 太长扫了 3 秒decode 因为 max_tokens 设成 2048 再跑 10 秒叠加起来就是一次灾难性的超时。另一个容易混淆的地方是“并发越高越慢”。LLM 推理框架倾向于把多个请求拼成一个 batch 来提高吞吐这是 GPU 计算特性决定的批量计算比逐个计算更划算。但 batch 的代价是同一 batch 内的所有请求共享同一个调度节奏任何一个慢请求都可能拖住其他请求的 step。这里有一个新手容易误解的点以为 tail latency 主要是“模型本身每次推理快慢不一致”。实际上在动态批处理continuous batching机制下模型单次 forward 的时间相对稳定真正的不稳定来自请求之间的相互作用和队列策略。P99 高往往不是模型抖动而是调度抖动。3. 为什么 batch 越大P99 越难看要理解 tail latency必须理解主流的 LLM 推理框架是怎么“拼车”的。早期的静态 batching 很简单攒够 N 个请求一起 forward等所有请求都生成完再把这批结果一起返回。这种方式吞吐稳定但 tail latency 很惊人因为一旦 batch 里有一个 max_tokens 特别大的请求其他几个早就生成完的请求也只能干等白白被拖累。后来 vLLM、TGI 等框架引入了迭代级调度iteration-level scheduling也就是连续批处理continuous batching。它把“请求”粒度拆成“step”粒度每执行完一个 decode step就检查有没有请求已经结束有就移除位置并允许新请求插入。这大大提高了 GPU 利用率和响应速度但副作用依然存在长序列请求长时间占用 slot。一个 max_tokens2048 的请求哪怕 prompt 很短也要连续占住一个 batch 位置几十甚至上百个 step。它不结束新请求就无法插到相同位置。prefill 与 decode 竞争。新请求的 prefill 阶段计算量很大会把正在进行的 decode 步长显著拉长导致 batch 内所有请求同时变慢。排队策略不公平。如果队列是简单的 FIFO一个长 prompt 请求排在你前面你就得等它 prefill 完。它 prefill 慢会拉高后面所有短请求的 TTFT。现实中一个服务如果同时存在“几百 token 的聊天请求”和“几千 token 的文档总结请求”后者的存在会系统性抬高前者的 P99。短请求不仅是“被延迟”而是“被长请求锁住”。这也是为什么说 tail latency 问题是“结构性”的只要长短请求共享排队和 batchP99 就很难好看。解决思路无非两条要么从调度上隔离长短请求要么从入口控制请求长度分布。本文的方案是后者为主因为它实现成本最低不需要改动推理框架。4. 最容易走错的三个修复方向在给出方案前先列出我见过的大量团队包括我自己早期踩过的坑会走的弯路。4.1 盲目加 GPU很多人看到 P99 高第一反应是“算力不够”于是加卡。加卡能提升整体吞吐但不一定能削平 tail latency。如果瓶颈是某个长请求长时间霸占 batch slot或者队列策略不公平再加多少 GPU短请求照样可能排在长请求后面。加卡只会让平均延迟变好不会修复调度问题。4.2 无上限放开 max_tokens很多后端为了灵活性直接把客户端的max_tokens原样透传给推理框架甚至不传时让框架用默认最大值。这相当于让每一个调用方都能申请“无限制的算力配额”。某个 Agent 程序一旦写错逻辑可能出现长达几千 token 的循环生成一次请求消耗的 GPU 时间等于几百次短请求。4.3 客户端无限重试客户端发现超时后立刻重试是另一种常见的自伤行为。服务端一旦出现某个慢请求客户端重试只会把更多请求压进队列形成“重试风暴”。慢请求还没处理完新的重试请求又把队列堆满最终从 P99 恶化成整体不可用。这三种做法都不是在“修复” tail latency而是在“掩盖”或“放大”问题。真正的修复需要从请求生命周期的最前端下手进入队列之前就完成分类、限流和超时策略。5. 核心方案请求分级 长度上限 快速失败本文推荐的“简单修复”由三个独立但互补的手段组成。它们不依赖推理框架内部实现可以在网关层完成风险低、可回滚、容易理解。5.1 请求分级让短请求先走核心规则很简单请求进入网关时根据 prompt 长度和 max_tokens 大小分成两类短请求高优先级prompt 短、max_tokens 小这些往往是交互式聊天、接口调用、简单问答。长请求低优先级prompt 长或 max_tokens 大这些往往是文档总结、离线分析、Agent 长任务。短请求进入优先队列长请求进入普通队列。只要短请求队列里有任务worker 就优先处理短请求。这个做法的价值在于把“长短请求互相拖累”变成“长短请求自然隔离”。短请求的 P99 会大幅下降长请求的延迟会上升但长请求本身对延迟敏感度低用户本来就会等更久。对业务来说这是一个合理的取舍。需要注意短请求优先并不是“完全饿死长请求”。实际实现中可以给长请求设置一个最大排队超时保证它最终会被处理或者直接拒绝并让客户端稍后重试。5.2 服务端强制长度上限不要信任客户端的 max_tokens 参数。真正的兜底应该在服务端。具体来说需要在网关入口做两层限制输入长度限制对 prompt 的总字符数或预估 token 数设上限超过直接返回 4xx或者要求客户端先做摘要/分块。输出长度限制对 max_tokens 设上限例如默认 256最大不超过 1024。如果客户端传的值大于上限可以截断也可以返回错误。更稳妥的做法是截断并用响应头告知客户端实际生效值。这一步能直接掐掉“一个请求耗尽整机算力”的最坏情况。它看起来简单粗暴但在生产环境中非常有效。5.3 排队超时快速失败第三件套是给排队加超时。很多 tail latency 的极端值来自“请求孤零零地排在队列里等到超时才报错”。与其让客户端傻等不如在服务端设置一个明确的排队超时阈值。超过阈值立即返回 503 或 429并附上“请稍后重试”的说明。这个做法把不确定的等待变成确定的快速失败。对客户端来说收到一个明确错误比无限等待更容易处理对服务端来说排队长度被限制在可控范围不至于出现“几百个请求堆在内存里慢慢腐烂”。三件套合起来的思路是把请求流量在入口处整理成一个“可控、可分类、可拒绝”的形状而不是把所有的随机性都丢给推理框架去消化。6. 代码实现一个最小的 LLM 网关排队器下面用 FastAPI asyncio 实现一个最小可运行的网关。它在最前面加了双优先级队列、长度限制和排队超时后端指向任意一个 OpenAI 兼容接口。6.1 项目结构整个 demo 只有两个文件. ├── gateway_demo.py # FastAPI 网关 └── requirements.txt # 依赖依赖文件内容如下fastapi uvicorn httpx6.2 完整代码# 文件路径gateway_demo.py import asyncio import itertools import os import time import uuid from contextlib import asynccontextmanager from dataclasses import dataclass, field import httpx from fastapi import FastAPI, Request from fastapi.responses import JSONResponse # 后端真实 LLM 推理服务地址例如 vLLM BACKEND_URL os.environ.get(BACKEND_URL, http://127.0.0.1:8000) # 短请求判断阈值 SHORT_PROMPT_CHARS int(os.environ.get(SHORT_PROMPT_CHARS, 2000)) SHORT_MAX_TOKENS int(os.environ.get(SHORT_MAX_TOKENS, 128)) # 排队超时和端到端超时 QUEUE_TIMEOUT float(os.environ.get(QUEUE_TIMEOUT, 5.0)) HTTP_TIMEOUT float(os.environ.get(HTTP_TIMEOUT, 90.0)) # 并发 worker 数量 WORKER_COUNT int(os.environ.get(WORKER_COUNT, 2)) # 输入输出硬限制 MAX_PROMPT_CHARS int(os.environ.get(MAX_PROMPT_CHARS, 100000)) MAX_OUTPUT_TOKENS int(os.environ.get(MAX_OUTPUT_TOKENS, 1024)) dataclass(orderTrue) class LLMRequest: priority: int seq: int field(compareFalse) created_at: float field(compareFalse) request_id: str field(compareFalse) payload: dict field(compareFalse) class LLMGateway: def __init__(self) - None: self.queue: asyncio.PriorityQueue asyncio.PriorityQueue() self.counter itertools.count() self.client httpx.AsyncClient(timeoutHTTP_TIMEOUT) self.workers [ asyncio.create_task(self._worker(i)) for i in range(WORKER_COUNT) ] async def submit(self, priority: int, payload: dict) - dict: loop asyncio.get_running_loop() future: asyncio.Future loop.create_future() req LLMRequest( prioritypriority, seqnext(self.counter), created_attime.monotonic(), request_iduuid.uuid4().hex, payloadpayload, ) await self.queue.put((req.priority, req.seq, req, future)) try: return await asyncio.wait_for(future, timeoutQUEUE_TIMEOUT HTTP_TIMEOUT) except asyncio.TimeoutError: raise TimeoutError(request timeout in gateway) async def _worker(self, worker_id: int) - None: while True: _, _, req, future await self.queue.get() waiting time.monotonic() - req.created_at # 排队时间已经超过阈值不再调用后端直接快速失败 if waiting QUEUE_TIMEOUT: if not future.done(): future.set_exception(TimeoutError(dequeued after timeout)) self.queue.task_done() continue try: resp await self.client.post( f{BACKEND_URL}/v1/chat/completions, jsonreq.payload, ) resp.raise_for_status() if not future.done(): future.set_result(resp.json()) except Exception as exc: if not future.done(): future.set_exception(exc) finally: self.queue.task_done() gateway: LLMGateway | None None asynccontextmanager async def lifespan(app: FastAPI): global gateway gateway LLMGateway() yield if gateway: await gateway.client.aclose() for t in gateway.workers: t.cancel() app FastAPI(titlellm-tail-latency-gateway, lifespanlifespan) def classify(payload: dict) - int: 返回 0 表示短请求放入优先队列返回 1 表示长请求放入普通队列。 messages payload.get(messages, []) prompt_chars sum(len(m.get(content, )) for m in messages) max_tokens int(payload.get(max_tokens, 0) or 0) if prompt_chars SHORT_PROMPT_CHARS and max_tokens SHORT_MAX_TOKENS: return 0 return 1 app.post(/v1/chat/completions) async def chat_completions(request: Request): if gateway is None: return JSONResponse(status_code503, content{error: gateway not ready}) payload await request.json() # 1. 输入长度硬限制 total_chars sum(len(m.get(content, )) for m in payload.get(messages, [])) if total_chars MAX_PROMPT_CHARS: return JSONResponse( status_code413, content{error: prompt too long, please split or summarize} ) # 2. 输出长度硬限制 max_tokens int(payload.get(max_tokens, 0) or 0) if max_tokens MAX_OUTPUT_TOKENS: payload[max_tokens] MAX_OUTPUT_TOKENS # 3. 分类并提交 priority classify(payload) try: result await gateway.submit(priority, payload) return result except TimeoutError: return JSONResponse( status_code503, content{error: queue timeout, please retry later} ) except Exception as exc: return JSONResponse(status_code502, content{error: str(exc)})这段代码的关键逻辑有三点classify负责把请求分成两类。这里的阈值先用SHORT_PROMPT_CHARS和SHORT_MAX_TOKENS两个环境变量控制方便不同业务调整。LLMGateway.submit里用了asyncio.wait_for对每个请求都设置了端到端超时同时 worker 出队后还会再检查一次排队时长超过QUEUE_TIMEOUT就不调用后端直接抛错返回 503。这实现了“快速失败”。入口处对max_tokens做了硬截断防止客户端传一个巨大的值。6.3 运行与接入先用 uvicorn 启动网关BACKEND_URLhttp://127.0.0.1:8000 \ SHORT_PROMPT_CHARS2000 \ SHORT_MAX_TOKENS128 \ QUEUE_TIMEOUT5 \ python -m uvicorn gateway_demo:app --host 0.0.0.0 --port 8080注意BACKEND_URL要指向你真实的推理服务比如 vLLM 启动的 OpenAI 兼容服务。网关启动后客户端只需把请求地址从原来的后端地址改成http://你的网关:8080/v1/chat/completions即可。请求体兼容 OpenAI 格式。7. 在推理框架中的落地配置网关只是入口层真正的推理框架也需要配合调整。以下配置以 vLLM 为例但思路适用于大多数推理框架。7.1 vLLM 启动配置vLLM 的常见启动命令有两种风格取决于版本。较新的版本推荐使用vllm servevllm serve Qwen/Qwen2.5-7B-Instruct \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --trust-remote-code如果你的版本是旧版api_server入口命令类似python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --max-model-len 32768 \ --gpu-memory-utilization 0.9这里需要注意--max-model-len控制的是模型能接受的最大上下文长度但这个值等于“输入长度 输出长度”。如果服务端不额外限制客户端传一个prompt20000、max_tokens20000的请求它仍然可能打满整个上下文窗口。因此网关层的MAX_PROMPT_CHARS和MAX_OUTPUT_TOKENS实际上比框架配置更重要它们是第一道闸门。另一个在 vLLM 中值得开启的功能是前缀缓存prefix caching。它对包含大量公共前缀的请求比如系统提示词固定的 Agent 调用有显著加速效果但不同版本开关参数不同建议查阅你所用版本的官方文档。这里不展开。7.2 Nginx 超时配置如果前面还挂了 Nginx需要合理配置超时时间避免 Nginx 提前切断请求而网关层的超时策略完全失效。upstream llm_gateway { server 127.0.0.1:8080; keepalive 32; } server { listen 443 ssl; server_name llm.example.com; location /v1/chat/completions { proxy_pass http://llm_gateway; proxy_connect_timeout 5s; proxy_send_timeout 300s; proxy_read_timeout 300s; proxy_http_version 1.1; proxy_set_header Connection ; } }这里的核心原则是Nginx 的超时时间必须大于网关到后端的超时时间否则 Nginx 会先于网关切断请求客户端拿到的错误信息也失去意义。建议把proxy_read_timeout设成网关端到端超时的 1.5 倍以上。7.3 客户端约束服务端修复只是兜底客户端也必须配合所有调用方必须显式设置max_tokens不能依赖框架默认值重试次数限制在 2 次以内并采用指数退避对长文本任务先做分块或摘要而不是一次性提交整个文档客户端超时要大于服务端超时否则你永远只能看到“客户端超时”而不是服务端真实错误。8. 效果验证怎么证明它真的有效任何优化都要有验证。下面是一套不需要复杂压测平台的验证方法。8.1 压测前先定指标不要只看平均延迟至少要对比四个数字P50正常情况下的体感延迟P99长尾请求的恶化程度错误率特别是 5xx 和 4xx 比例排队超时比例如果这个指标很高说明后端容量确实不够调度优化已经到极限。8.2 构造混合流量压测真实场景中长短请求是混合出现的。用下面的 Python 脚本模拟一部分请求模拟短问答一部分模拟长文档总结。# 文件路径mix_load.py import json import random import threading import time import urllib.request GATEWAY_URL http://127.0.0.1:8080/v1/chat/completions TOTAL 200 CONCURRENCY 10 SHORT_RATIO 0.8 results [] def send_one(idx: int): is_short random.random() SHORT_RATIO if is_short: prompt 用一句话解释什么是数据库索引 max_tokens 64 else: prompt 请对下面这段技术文档做一份 500 字以内的摘要 数据库索引是... * 200 max_tokens 512 body json.dumps({ model: test, messages: [{role: user, content: prompt}], max_tokens: max_tokens, }).encode(utf-8) req urllib.request.Request(GATEWAY_URL, databody, headers{Content-Type: application/json}) start time.time() try: with urllib.request.urlopen(req, timeout60) as resp: resp.read() status ok except Exception as exc: status type(exc).__name__ cost time.time() - start results.append((idx, status, cost)) threads [] for i in range(TOTAL): t threading.Thread(targetsend_one, args(i,)) threads.append(t) for t in threads[:CONCURRENCY]: t.start() for t in threads[CONCURRENCY:]: t.start() threads[t - CONCURRENCY].join() # 简易信号量控制并发 for t in threads: t.join() costs sorted([r[2] for r in results if r[1] ok]) if costs: n len(costs) print(f成功请求数: {n}) print(fP50: {costs[int(n * 0.50)]:.3f}s) print(fP95: {costs[int(n * 0.95)]:.3f}s) print(fP99: {costs[int(n * 0.99)]:.3f}s if n 100 else 请求数不足无法计算P99) error_rates {} for _, status, _ in results: error_rates[status] error_rates.get(status, 0) 1 print(f错误分布: {error_rates})这个脚本比较粗糙但足以观察出优化前后的差异。建议在同一个后端、同一批 GPU 负载下分别测“没有网关直连后端”和“经过网关”两种模式看 P50、P99 和错误率的变化。8.3 判断标准从设计上看这套方案应该产生以下效果短请求的 P99 显著下降因为不再被长请求抢在前头整体端到端 P99 会被削平但代价是长请求的一部分从“超长耗时”变成“快速失败返回 503”服务端 GPU 利用率可能略微下降因为有些长请求被拦截了但这属于主动放弃低价值请求换取了更稳定的服务质量如果压测中发现短请求 P99 没有改善优先检查是否真的把请求分类对了以及 worker 数量是否充足。这里要特别说明上面的“预期”是从机制上推断的不是某次具体压测的结论。不同模型、不同框架、不同流量分布下数字会有差异但结构性改善的方向是一致的。9. 常见问题与排查思路问题现象可能原因排查方式解决方案P99 高但 P50 不高长短请求混排短请求被长请求拖累看网关日志中短请求的排队等待时间启用短请求优先队列调整后大量 503排队超时设置过短或后端真的处理不过来拆分排队耗时和后端耗时先看后端 P95再决定调大超时还是扩容客户端反馈超时但服务端日志没有对应请求网关前的 Nginx 或负载均衡超时太短检查所有代理层的 timeout 配置将代理超时设为大于网关端到端超时请求被截断后用户不满意服务端强制截断 max_tokens查看实际响应中的 token 数量根据业务场景调整 MAX_OUTPUT_TOKENS或对长任务走单独异步接口加机器后 P99 还是高调度策略仍是 FIFO长请求继续堵住队列观察队列长度和慢请求占比入口分级 快速失败某客户端疯狂重试导致雪崩客户端无限制重试看网关日志中同一请求 id 的重复出现客户端限制重试次数 指数退避排查 tail latency 问题时最重要的顺序是先确认延迟发生在“排队”还是“生成”再决定是调调度还是调容量。如果网关日志里排队时间只有几毫秒大量时间都花在httpx调用后端上那问题在后端推理如果排队时间占了总耗时的一半以上才轮到调度策略优化。10. 最佳实践与工程建议上面这套“简单修复”可以快速止血但如果要在生产环境长期稳定运行还需要补齐以下工程细节。10.1 监控指标至少采集四类指标每个请求的排队耗时、prefill 耗时、decode 耗时、端到端耗时短请求和长请求各自的 P50 / P95 / P99队列当前长度、worker 数量、超时拒绝次数后端推理服务的 GPU 利用率、batch 大小、每 step 耗时。有了这些数据你才能回答“今天 P99 变差了是因为流量异常还是某个长尾请求出现还是后端变慢”。10.2 超时分层设计一套合理的超时配置应该是分层的客户端超时 网关端到端超时网关端到端超时 Nginx 代理超时网关排队超时 后端单请求最大耗时。如果各层超时互不匹配就会出现“客户端等 30 秒Nginx 10 秒就切断网关还被蒙在鼓里”的尴尬局面。10.3 长度限制要写入 API 文档不要只做代码限制还要把规则写进 API 文档。明确告诉调用方请求的最大输入长度是多少max_tokens 的上限是多少超过限制会被拒绝还是截断长任务应该使用哪些异步接口。这样能减少开发团队之间的沟通成本也能让调用方提前对自己请求做裁剪。10.4 留一个绕过通道生产环境要留一个白名单通道给少量确实需要超长上下文的高价值任务使用。比如在网关识别一个内部 header跳过短请求分类直接进入长请求队列。这样你可以在不修改代码的情况下支持极少数特殊场景。10.5 先小流量灰度任何网关改动都建议先小流量灰度。把网关部署在测试环境用录制回放或影子流量验证一段时间确认不会引入错误后再逐步切流量。11. 总结与后续学习方向回到最初的问题LLM 在线服务的 tail latency 为什么难修因为它的根因往往埋在请求调度和队列结构里而不在模型计算本身。加 GPU、优化算法固然有效但成本高、见效慢。相比之下“请求分级 长度上限 快速失败”是一套几乎不依赖硬件的入口层方案它通过改变进入推理框架的流量形状让系统不会因为少数极端请求而整体失控。本文给出的网关代码和验证方法可以直接跑通。你可以把它理解成给 LLM 服务装了一个“交通分流闸门”短请求走快速通道长请求走慢速通道排队过久直接拒绝。它不优雅却足够有效适合大多数中小团队作为第一道防线。如果想继续深入下一步值得研究的方向有三个Prefix Caching对相同系统提示词或文档前缀做 KV Cache 复用能明显减少 prefill 延迟Chunked Prefill 和 PD 分离把 prefill 和 decode 放在不同实例上是更彻底的长短请求隔离方案基于延迟的弹性伸缩根据 P99 和排队长度自动扩缩容而不是只看 GPU 利用率。把这套入口层修复先落地再根据监控数据决定是否需要更进一步是比较稳妥的节奏。希望这篇文章能帮你把 P99 的诡异峰值变成一个可控、可解释、可优化的工程问题。