企业官网建设流程全解析

这次我们来看一个 LLM serving 方向的新思路：Burstiness is all you need for LLM serving。这个标题的提法很直接——它想说的是，LLM 服务流量天然就不是均匀的，而是突发性的；与其试图把流量抹平，不如让调度策略直接感知并利用这种突发性，把它变成提升吞吐和 SLO 达标率的抓手。

如果你负责过在线推理服务、做过大模型 API 网关，或者正在用 vLLM、TGI 这类框架部署开源模型，一定遇到过这样的场景：平时请求量很低，某一瞬间用户全部涌进来，队列瞬间拉长，超时率上升，GPU 显存利用率却不升反降。这就是 burstiness——请求到达率在短时间尺度内剧烈波动。本文会从概念、调度思路、部署验证、接口测试、性能观测、常见坑位这六个层面，把这个主题拆开讲清楚。

文章适合三类读者：正在做生产级 LLM 服务压测和调优的后端工程师；在做推理平台、推理网关的架构师；以及准备在业务里接入自建大模型 API、想搞清楚服务瓶颈在哪里的开发同学。下面先给一个整体速览，再逐步展开验证流程。

1. 核心能力速览

先把这篇内容的关键点列出来，方便快速判断是否和你的场景相关。

这里要强调一点：本文在讲「思路」和「验证方法」时，不会虚构一份已经发布的开源工具。如果标题所指的研究工作还没有对应可跑代码，那就按方法论去理解，并在自己的 serving 环境里完成验证。这样更稳妥，也不会被无效承诺误导。

2. 什么是 Burstiness，为什么它对 LLM serving 这么关键

Burstiness 描述的是请求到达过程在时间上不均匀的程度。数学上经常用到达间隔的变异系数、自相关函数或者多重分形参数来衡量；工程上更直观的观察方式是：把一分钟内的请求按秒切分，你会发现有些秒有几十个请求，有些秒几乎是零。

传统 Web 服务也讲突发流量，但 LLM serving 的 burstiness 影响更大，原因在于请求成本和资源占用高度不均匀。一个普通 HTTP 请求通常毫秒级返回，而一个 LLM 推理请求可能持续几秒到几分钟，期间需要持续占用 GPU 显存和算力。如果同一秒内有大量请求同时到达，服务端不仅要处理排队，还要考虑每请求的 prefill（预填充）阶段和 decode（解码）阶段如何交错。prefill 阶段需要大量并行计算，模型要一次性处理输入 prompt 的所有 token；decode 阶段则是一次生成一个 token，计算密度明显偏低。突发流量一来，prefill 任务集中堆积，GPU 的算力可能在极短时间内被吃满，随后又因为 decode 阶段占满显存而进入低利用率状态。

传统调度器面对这种情况往往表现不好。FCFS（先到先服务）在突发流量下会让短请求排在长请求后面，导致尾延迟失控；基于固定并发数的信号量限流虽然保护了系统，但会直接丢弃流量，用户体验很差。而连续批处理（continuous batching）虽然可以在同一个 batch 里动态增减请求，但它的效率上限取决于调度器能否在正确的时间把正确的请求放进 prefill 和解码槽位。如果没有感知 burstiness，批大小会剧烈波动，GPU 利用率在过饱和和空转之间来回跳跃。

Burstiness is all you need 这类思路的出发点就是：不要假装流量是均匀的，而是把突发性直接建模进调度策略。比如基于到达模式的预测来预先保留 batch 槽位，或者在突发窗口内调整 prefill 和 decode 的比例，把请求按到达间隔分组，让计算密集的 prefill 阶段在流量峰值处合并执行，从而提升 GPU 整体的吞吐，同时控制 SLO 超标比例。

从工程实践看，理解 burstiness 至少有四个直接收益：

• 排障更快：当 P95 延迟突然升高时，不再盲目加机器，而是先看到达率曲线和队列深度是否同步上涨。
• 压测更真实：压测脚本不再使用匀速发请求，而是根据业务特征模拟突发到达，才能暴露真实环境中的问题。
• 容量规划更准：给系统留多少冗余，应该取决于突发峰值的规模和持续时间，而不是平均 QPS。
• 调度策略可验证：在加载不同调度策略时，可以量化对比 SLO 达标率、尾部延迟和吞吐量，而不是靠感觉判断。

3. 适用场景与使用边界

先回答「这个东西适合谁、能解决什么问题」。最典型的是四类场景：

• 企业级 LLM API 网关：多个业务方共用同一个推理集群，每个业务方的用户行为不同，请求到达叠加后会出现明显的高峰期和低谷期，需要感知突发性来做配额和调度。
• Agent 应用后端：Agent 在一次任务里会连续调用模型多次，且调用之间有时间间隔，这会让单个用户维度出现天然的脉冲式请求流。
• 高并发在线服务：比如智能客服、代码补全、实时翻译，用户输入行为受工作时间、热点事件影响，突发性非常显著。
• 多租户共享推理集群：不同租户的负载会互相干扰，如果把 burstiness 纳入调度，可以避免某个租户的高峰把整个集群的延迟拖垮。

同时也要说清楚不适合什么场景：

• 离线批量推理：离线任务通常预先排队、匀速运行，目标是最大化整体吞吐，burstiness 的影响很小。
• 单用户低并发场景：本地调试、个人开发环境里请求量太小，突发性特征不明显，不需要专门优化。
• 对延迟不敏感的异步处理链路：比如日志分析、内容审核的异步队列，只要能扛住增量，突发性不会直接伤害业务。

使用边界和安全提醒：LLM serving 的调度优化不能用来绕过系统的并发限制或资源配额。合理使用方式是，在配额范围内让调度更高效，而不是突破安全边界。生产环境里的突发流量可能来自爬虫、刷接口或其他异常来源，必须和业务限流、认证鉴权配合使用。部署和压测时，也只在自有测试环境里对授权模型和自有数据进行验证，避免把未授权数据灌入公共模型服务。

4. 环境准备与前置条件

在验证 burstiness 调度思路之前，先搭一套可重复运行的 LLM serving 环境。下面是一个通用检查清单，具体版本以实际使用的框架和模型为准。

4.1 硬件要求

• GPU：NVIDIA GPU，建议至少拥有 16G 显存，测试 7B 级别的开源模型比较方便；如果测试更大的模型，显存需求按模型量化精度和上下文长度相应提升。
• 内存：建议 32G 以上。模型权重加载、tokenizer、batch 数据都会占用内存。
• 磁盘：模型仓库加依赖环境，预留 50G 以上比较稳妥。
• 网络：如果使用 Docker 拉取镜像和模型，需要稳定网络。

4.2 软件环境

• 操作系统：Linux 发行版，例如 Ubuntu 22.04。
• NVIDIA 驱动与 CUDA：驱动版本要适配本机 GPU；PyTorch 和 vLLM 对 CUDA 版本都有要求，建议先用nvidia-smi确认驱动支持的 CUDA 版本。
• Python：3.10 或更高版本。
• Python 包管理：建议使用独立的虚拟环境，避免污染系统 Python。
• 推理框架：以 vLLM 为例，它是目前验证连续批处理和调度策略最方便的框架之一。

4.3 端口和防火墙

Serving 服务默认会监听一个端口。启动前先检查端口是否被占用：

ss -lntp | grep 8000

如果端口已被占用，启动参数里显式指定新端口，或者关闭占用进程。生产环境还要在防火墙里放行对应端口，并限制来源 IP。

5. 安装部署与启动方式

这里以 vLLM 为例，演示从零启动一个 LLM 服务。注意：如果是其他框架，命令和参数会有所不同，但验证思路一致。

5.1 创建虚拟环境并安装依赖

python3 -m venv llm-serve-env source llm-serve-env/bin/activate pip install --upgrade pip pip install vllm

如果你的网络环境里 pip 下载较慢，可以换国内镜像源：

pip install vllm -i https://pypi.tuna.tsinghua.edu.cn/simple

5.2 启动 OpenAI 兼容服务

vLLM 支持一条命令启动一个兼容 OpenAI 接口的服务。下面是常见用法，模型路径和参数需要按实际环境替换：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name my-llm \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

参数含义：

• --model：模型权重的本地路径，或者 Hugging Face 上的模型 ID。
• --served-model-name：对外暴露的模型名称，调用 API 时需要保持一致。
• --host：监听地址。本地调试用127.0.0.1，容器或局域网访问用0.0.0.0。
• --port：服务端口。
• --max-model-len：最大上下文长度。
• --gpu-memory-utilization：允许框架使用的显存比例。

启动后如果看到日志输出类似Uvicorn running on http://0.0.0.0:8000，说明服务已经可访问。这时可以用一个简单的请求验证：

curl http://127.0.0.1:8000/v1/models

正常会返回模型列表，说明接口已经通了。

5.3 Docker 方式启动（可选）

如果你希望减少环境依赖，也可以用 Docker：

docker run --gpus all \ -v /path/to/models:/models \ -p 8000:8000 \ vllm/vllm-openai \ --model /models/your-model \ --served-model-name my-llm

Docker 方式的好处是环境隔离更干净，但需要提前拉取镜像和模型文件。具体镜像 tag 请参考 vLLM 官方文档，这里不写死版本号，以免误导。

6. 突发流量模拟与功能验证

服务启动后，下一步是验证它在不同到达模式下的表现。这是整个主题的关键：只有用突发流量压测，你才能看到 burstiness 的影响。

6.1 先做功能连通性验证

在压测之前，先用单请求确认模型可以正常推理：

from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:8000/v1", api_key="EMPTY" ) chat_completion = client.chat.completions.create( model="my-llm", messages=[ {"role": "user", "content": "用一句话介绍什么是突发流量"} ], max_tokens=128, temperature=0.7 ) print(chat_completion.choices[0].message.content)

这段代码能跑通，说明 OpenAI 兼容接口正常。接下来再进入压测和调度观察。

6.2 构建均匀流量基线

均匀流量是基线。使用 Python 脚本，每隔固定秒数发送一个请求：

import time import threading from openai import OpenAI from datetime import datetime client = OpenAI( base_url="http://127.0.0.1:8000/v1", api_key="EMPTY" ) def send_request(idx: int): start = time.time() try: resp = client.chat.completions.create( model="my-llm", messages=[{"role": "user", "content": f"这是第 {idx} 个请求，请写一段关于 LLM serving 的简单说明。"}], max_tokens=200, temperature=0.7 ) end = time.time() print(f"{datetime.now().isoformat()} request={idx} latency={end - start:.2f}s") except Exception as e: print(f"{datetime.now().isoformat()} request={idx} error={e}") for i in range(100): threading.Thread(target=send_request, args=(i,)).start() time.sleep(0.5)

这个脚本模拟每秒 2 个请求的平稳负载。记录下每个请求的响应时间，尤其是 P95 和 P99。这是后续对比的基准。

6.3 构建突发流量场景

突发流量的特征是在短时间内并发大量请求。模拟方式有很多，常见的是脉冲式到达：先静默 5 秒，然后瞬间抛出 50 个请求，再静默 10 秒，再抛出 80 个请求。

import time import threading from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:8000/v1", api_key="EMPTY" ) def burst_send(start_idx: int, count: int): threads = [] for i in range(start_idx, start_idx + count): t = threading.Thread( target=call_once, args=(i,) ) threads.append(t) for t in threads: t.start() for t in threads: t.join() def call_once(idx: int): start = time.time() try: resp = client.chat.completions.create( model="my-llm", messages=[{"role": "user", "content": f"突发请求 {idx}：帮我写一段技术总结。"}], max_tokens=150, temperature=0.7 ) end = time.time() print(f"request={idx} ok latency={end - start:.2f}s") except Exception as e: print(f"request={idx} error={e}") # 静默 3 秒后突发 30 个请求 time.sleep(3) burst_send(0, 30) # 静默 5 秒后突发 60 个请求 time.sleep(5) burst_send(30, 60)

你可以观察几个现象：

• 突发请求的响应时间是否明显高于均匀流量。
• 突发请求是否出现连接超时或 429 限流错误。
• 在突发请求结束后，普通请求的响应时间是否还在持续受到影响，也就是恢复时间有多长。

6.4 判断验证是否成功

判断一套 serving 系统在突发流量下表现是否合格，不能只看平均延迟，要看三件事：

• SLO 达标率：比如定义「200 token 以下请求 P95 延迟低于 3 秒」作为 SLO，统计突发压测中的达标比例。
• 队列阻塞恢复时间：突发请求结束后，服务是否能在几秒内恢复正常延迟。
• 失败率：是否存在因为排队时间过长导致的超时错误。

如果在突发流量下失败率明显上升，且恢复时间过长，就说明当前的调度策略没有很好的 burstiness 应对能力，需要调整 batch 策略、并发上限或调度策略。

6.5 对比实验设计

为了验证「burstiness-aware 调度优于普通调度」，建议做一组对比实验：

• 场景 A：均匀流量压测 5 分钟。
• 场景 B：突发流量压测 5 分钟，其中每 20 秒产生一次脉冲，峰值并发是均值的 5 倍。
• 场景 C：混合流量，80% 时间低负载，20% 时间突发高峰。

分别记录每组的吞吐量、P95 延迟、P99 延迟、错误率。如果后续有可对比的调度版本，只要切换服务端参数或部署版本，重复相同场景即可。这里要注意：压力测试必须控制请求总量和模型 token 上限，避免把测试环境打成不可恢复的状态。

7. 接口 API 与批量任务

LLM serving 的调度优化最终要落到接口和业务上。OpenAI 兼容接口是事实标准，vLLM、TGI、SGLang 都支持，接下来看看 API 能提供哪些信息。

7.1 查看模型列表

curl http://127.0.0.1:8000/v1/models

返回结果中包含模型名称、元数据等信息。确认服务已注册模型后，再开始调用。

7.2 流式响应与指标观测

在线服务推荐使用流式输出，这样客户端可以拿到 TTFT（首 token 时间）。Python 侧的调用方式：

from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:8000/v1", api_key="EMPTY" ) response = client.chat.completions.create( model="my-llm", messages=[{"role": "user", "content": "介绍一下 LLM serving 中的连续批处理"}], max_tokens=256, temperature=0.7, stream=True ) first_token_time = None for chunk in response: if not chunk.choices: continue delta = chunk.choices[0].delta.content if delta and first_token_time is None: first_token_time = time.time() print(f"TTFT: {first_token_time - start_time:.2f}s") if delta: print(delta, end="", flush=True)

在代码里记录请求发出时间、首 token 到达时间、完整响应结束时间，就能近似估算 TTFT 和 TPOT。

7.3 批量提交任务与队列观察

如果你要验证服务在大批量请求下的表现，可以用异步客户端批量发送，而不是一个个串行等待。比如：

import asyncio from openai import AsyncOpenAI async def main(): client = AsyncOpenAI( base_url="http://127.0.0.1:8000/v1", api_key="EMPTY" ) tasks = [] for i in range(50): tasks.append( client.chat.completions.create( model="my-llm", messages=[{"role": "user", "content": f"批量任务 {i} 的内容"}], max_tokens=100 ) ) results = await asyncio.gather(*tasks, return_exceptions=True) for idx, r in enumerate(results): if isinstance(r, Exception): print(f"task {idx} failed: {r}") else: print(f"task {idx} ok: {r.choices[0].message.content[:20]}") asyncio.run(main())

批量提交时，可以观察服务端日志里的排队情况和批大小变化。如果框架暴露了 metrics 接口，可以直接拉取指标。vLLM 默认暴露了 Prometheus 指标端点，路径一般是/metrics。可以通过 Prometheus 采集器抓取；如果没有，也可以直接访问这个地址看原始指标。

curl http://127.0.0.1:8000/metrics | grep -E "vllm:|queue|running"

不同类型的指标名称以实际框架版本为准。重点观察三个量：

• 当前排队的请求数量。
• 当前正在运行的批次数。
• GPU 显存使用率和算力利用率。

7.4 接口压力测试工具选择

除了自己写 Python 脚本，也可以用现成压测工具：

• 简单并发测试：hey或ab，但不推荐直接用于 LLM，因为它们不理解 token 流式特性。
• 更接近真实负载：locust或k6，可以自定义用户行为，模拟思考时间和突发高峰。
• LLM 专项压测工具：部分项目提供 LLM serving 压测功能，使用前确认是否和你的服务端框架兼容。

压测时要在客户端记录请求时间戳和响应时间，方便后续计算分位数指标。最好把压测结果导出为 JSON 或 CSV，再做后续分析。

8. 资源占用与性能观察

突发流量对 GPU 和 CPU 的冲击是动态的，观察资源占用需要多个工具配合。

8.1 显存占用观察

• nvidia-smi可以看到即时显存利用率和 GPU 利用率。
• nvidia-smi dmon可以周期性采样，便于记录变化曲线。
• 显存占用不能只看一个静态值。在 prefill 集中发生的时刻，显存会明显上涨；decode 阶段显存释放较慢，可能导致显存碎片化。

实际占用多少，取决于模型规模、batch 大小、上下文长度和框架的显存管理策略。不要在文章里写死某个数字，要以你自己的压测记录为准。

8.2 帧率和延迟指标

LLM serving 的重要延迟指标：

• TTFT：首 token 延迟，反映 prefill 和排队情况。
• TPOT：每个输出 token 的时间间隔，反映 decode 阶段的稳定程度。
• 端到端延迟：完整响应耗时，是用户感知最明显的指标。
• Normalized Latency：可以进一步按输入 token 数和输出 token 数归一化，用于跨场景对比。

排障时，可以先看 TTFT 是不是过高。如果 TTFT 高，大概率是排队时间长或者 prefill 计算量太大；如果 TTFT 正常但 TPOT 高，问题多半在 decode 阶段的批处理效率不足。

8.3 进程和日志排查

服务崩了不一定是显存不足。排查顺序：

• 看进程还在不在：ps aux | grep vllm。
• 看日志最后几行：journalctl -u your-service -n 100或直接看控制台输出。
• 看 GPU 状态：nvidia-smi -l 1持续输出，观察是否出现 Xid 错误。
• 看系统内存和 swap：free -h。

如果是本地用 nohup 启动的，日志会写在指定文件里；如果是 systemd 管理，用 journalctl。

9. 常见问题与排查方法

这一节把实际部署中容易遇到的问题整理成排查表，方便对照处理。

这里特别提醒：如果你用的是多个请求共享同一个服务的方案，某个超长输出可能长时间占住显存资源，导致其他请求排队。建议在服务端或网关层对max_tokens做统一上限，避免单请求把资源吃光。

10. 最佳实践与使用建议

最后给一套可以落地的工程建议，帮你把 burstiness 思路融入日常的 LLM serving 工作流。

10.1 从最小可运行配置开始

第一次测试不要追求大模型大并发。选一个 7B 级别的开源模型，限制上下文长度在 4096 左右，并发数从 1 慢慢加到 10、20、50。每次都记录延迟指标，而不是一次性把所有配置推到极限。这样出问题时能快速判断是框架问题、模型问题还是流量模型问题。

10.2 保留一套稳定的压测脚本

把均匀流量脚本、突发流量脚本、混合流量脚本放到代码仓库里，做成可复用的压测工具。每次升级 serving 框架、换模型、改调度参数后，都跑同一套脚本，对比指标变化。这是验证 burstiness 优化是否有效的可靠方式。

10.3 监控要分两层

• 系统层：GPU 利用率、显存占用、CPU 内存。
• 服务层：排队请求数、批大小、TTFT、TPOT、P95/P99 延迟、错误码比例。

两层指标必须关联分析。单独看 GPU 利用率看不出问题；单独看 P95 延迟也定位不了瓶颈。推荐把指标统一打到 Prometheus，然后用 Grafana 展示。

10.4 设计限流和熔断机制

生产环境不能依赖调度器硬扛突发流量。建议在入口加两层保护：

• 网关层：基于 IP、Key、用户维度的 QPS 限流，保护后端服务不被打垮。
• 服务层：设置最大并发数和超时时间，超出部分排队或快速失败。

限流的阈值不能拍脑袋。根据压测得到的瓶颈值设置，比如服务稳定运行的并发上限是 20，那就把限流阈值设为 25，留出缓冲。

10.5 数据合规与安全提醒

部署 LLM serving 服务时，务必遵守数据合规要求。压测数据、模型输入输出都可能在日志中留存，不要使用未授权的人脸、声纹、隐私文档或敏感业务数据做测试。如果服务开放给外部调用，必须做认证鉴权，不能裸奔在公网。对模型生成的输出要设置审核机制，避免有害内容直接流出。

11. 总结与下一步

回到标题：Burstiness is all you need for LLM serving。这句话的真正含义不是「只要研究突发性就万事大吉」，而是说，如果把请求到达的突发性理解透彻，你的 LLM 服务在吞吐、延迟和稳定性上都会有明显改善。

最值得优先尝试的事情，是按照本文第 6 节的方法，先用均匀流量和突发流量各压测一轮，记录 P95 延迟、TTFT、TPOT 和错误率。这是投入最小、收益最直接的验证路径。

最容易踩的坑有两个。第一，直接用匀速压测工具测 LLM 服务，得出的结论会和真实负载差别很大；真实用户行为是脉冲式的，而且 prompt 长度各不相同。第二，只看 GPU 利用率不看排队指标，结果就是 GPU 显示很忙，但接口延迟已经高到不可用。

后续可以继续做的事情包括：把 burstiness 指标纳入容量规划模型，结合历史请求曲线做自动扩缩容；在调度层试验基于到达率预测的批处理策略；如果团队自研 serving 框架，还可以把 burstiness 作为调度器的在线输入特征，做更激进的负载感知优化。

这篇文章里的思路和脚本可以直接作为你自建 LLM 服务的第一步验证材料。建议收藏备用，下次压测时照着跑一遍，再结合你自己的业务流量特征调整参数。