传统深度学习服务常把请求攒成固定 batch,一起 forward,一起返回。 对分类、embedding、rerank 这种一次 forward 就结束的任务,这很自然。 但 LLM 生成是多轮 decode:每个请求 prompt 长度不同、输出长度不同、结束时间不同。 如果还用静态 batch,整批请求会被最长输出拖住,短请求已经完成也不能让新请求进来。

LLM serving 的执行循环可以简化为:接收请求,分词,为 prompt 做 prefill, 然后一次 decode 一个 token。Continuous batching 把调度器插在每个 iteration 前面: 它看 waiting queue、running set、KV Cache 预算、token budget、SLO 约束,再决定本轮 GPU 做什么。

一个最小调度伪代码

while server_is_running:
    new_requests = receive_http_requests()
    waiting_queue.extend(tokenize(new_requests))

    # 释放已结束序列的 KV blocks,把 token 流式返回给客户端
    finished = [seq for seq in running if seq.is_finished()]
    free_kv_blocks(finished)
    running.remove(finished)

    token_budget = max_num_batched_tokens
    seq_budget = max_num_seqs - len(running)

    # 选择一部分 waiting 请求做 prefill,也可能只做 chunked prefill
    batch = choose_prefill_requests(waiting_queue, token_budget, seq_budget)

    # 已经 prefill 完的 running 请求每轮通常 decode 1 个 token
    batch += choose_decode_requests(running, token_budget)

    outputs = model_forward(batch)
    update_kv_cache(outputs)
    stream_tokens(outputs)

Continuous batching 真正难的地方在于 prefill 和 decode 的资源画像不同: prefill 是大矩阵计算,一次处理 prompt 中很多 token;decode 每轮只生成一个 token, 但要反复读写 KV Cache,更容易受显存带宽和 cache 管理影响。 调度器必须决定:先让等待请求尽快拿到首 token,还是保护正在输出的请求保持稳定 TPOT。

RoadMap 要求横向比较三类引擎。不要把它们看成“谁绝对更快”, 而要看各自的抽象:怎样控制批大小,怎样处理等待队列,怎样混排 prefill/decode, 以及有没有围绕 KV Cache、prefix cache、结构化生成做额外优化。

延续 Day32 的 vLLM 服务。今天不追求模型质量,只观察调度: 同一模型、同一 prompt/output 分布下,改变 max-num-seqs、 max-num-batched-tokens 与 chunked prefill,记录 TTFT、TPOT、吞吐和队列日志。

启动三组服务配置

# A. 保守:低并发,更容易看清单请求延迟
vllm serve Qwen/Qwen2.5-7B-Instruct \
  --served-model-name qwen2.5-7b \
  --max-model-len 4096 \
  --gpu-memory-utilization 0.85 \
  --max-num-seqs 16 \
  --max-num-batched-tokens 4096

# B. 吞吐:提高活跃序列上限
vllm serve Qwen/Qwen2.5-7B-Instruct \
  --served-model-name qwen2.5-7b \
  --max-model-len 4096 \
  --gpu-memory-utilization 0.90 \
  --max-num-seqs 64 \
  --max-num-batched-tokens 8192

# C. 长 prompt:尝试 chunked prefill,参数名以当前 vLLM 版本为准
vllm serve Qwen/Qwen2.5-7B-Instruct \
  --served-model-name qwen2.5-7b \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --max-num-seqs 64 \
  --max-num-batched-tokens 8192 \
  --enable-chunked-prefill

压测脚本:混合短/长 prompt

import asyncio
import statistics
import time
from openai import AsyncOpenAI

client = AsyncOpenAI(api_key="EMPTY", base_url="http://localhost:8000/v1")

SHORT = "用三句话解释 continuous batching。"
LONG = "请阅读以下模拟日志并总结调度瓶颈。" + (" waiting=12 running=48 kv=82%; " * 220)

async def one(i, prompt, max_tokens):
    t0 = time.perf_counter()
    first = None
    chunks = 0
    stream = await client.chat.completions.create(
        model="qwen2.5-7b",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.0,
        max_tokens=max_tokens,
        stream=True,
    )
    async for chunk in stream:
        delta = chunk.choices[0].delta.content or ""
        if delta:
            chunks += 1
            if first is None:
                first = time.perf_counter()
    t1 = time.perf_counter()
    return {
        "id": i,
        "ttft_ms": (first - t0) * 1000 if first else None,
        "e2e_ms": (t1 - t0) * 1000,
        "chunks": chunks,
        "tpot_ms": ((t1 - first) * 1000 / max(chunks - 1, 1)) if first else None,
    }

def pct(values, p):
    values = sorted(v for v in values if v is not None)
    return values[int((len(values) - 1) * p)]

async def main(concurrency=32, long_ratio=0.25):
    tasks = []
    for i in range(concurrency):
        is_long = (i / concurrency) < long_ratio
        tasks.append(one(i, LONG if is_long else SHORT, 160))
    res = await asyncio.gather(*tasks)
    print({
        "concurrency": concurrency,
        "p50_ttft_ms": pct([r["ttft_ms"] for r in res], 0.50),
        "p95_ttft_ms": pct([r["ttft_ms"] for r in res], 0.95),
        "p50_tpot_ms": pct([r["tpot_ms"] for r in res], 0.50),
        "p95_e2e_ms": pct([r["e2e_ms"] for r in res], 0.95),
        "avg_chunks": statistics.mean(r["chunks"] for r in res),
    })

asyncio.run(main(concurrency=32, long_ratio=0.25))

记录模板

experiment:
  model: Qwen/Qwen2.5-7B-Instruct
  gpu: "A10 24GB / L40S 48GB / A100 80GB ..."
  engine: vllm
  version: "..."
  workload:
    concurrency: [8, 16, 32, 64]
    long_prompt_ratio: [0.0, 0.25, 0.5]
    max_tokens: 160
  server_args:
    max_num_seqs: 64
    max_num_batched_tokens: 8192
    gpu_memory_utilization: 0.90
    chunked_prefill: true
  metrics:
    p50_ttft_ms:
    p95_ttft_ms:
    p50_tpot_ms:
    p95_e2e_ms:
    output_tokens_per_s:
    kv_cache_usage:
    running_waiting:
    preemption_count:

1. 用自己的话解释 static batching、dynamic batching、continuous batching 的区别。
2. 为什么生成式服务不能只看平均 latency?TTFT 和 TPOT 各自对应用户体感中的哪一段?
3. prefill-first 与 decode-first 策略分别会牺牲什么?
4. 一个长 prompt 请求进入系统时,它会如何影响短 prompt 请求的 TTFT?
5. 如果 vLLM 日志中 waiting 长期很高,你会优先检查哪些参数?
6. 为什么 prefix cache/RadixAttention 会影响调度策略,而不是单纯的 cache 优化?
7. 给定一个线上聊天服务 SLO,你会怎样设置吞吐优先和延迟优先两套调度配置?