在线 LLM 服务里,请求经常共享大段前缀: 同一套 system prompt、同一组工具定义、同一段 few-shot 示例、同一篇 RAG 文档。 如果每条请求都重新 prefill 这些相同 token,就会浪费 GPU 计算和 TTFT。

RadixAttention 不是新的注意力数学公式,而是一套 KV Cache 组织和调度机制。 它把已处理过的 token 序列压进 radix tree:公共前缀共享同一个路径, 分叉处拆成不同子节点。新请求进来时先找最长已缓存 prefix, 命中的部分直接拿 KV Cache,未命中的 suffix 再进入 prefill。

SGLang 提供 OpenAI-compatible API,默认常用端口是 30000。今天用小模型先跑通观察链路; 如果有足够显存,可以换成 7B/8B Instruct 模型。

安装与启动

python -m venv .venv-sglang
source .venv-sglang/bin/activate

pip install -U pip
pip install -U "sglang[all]" openai

export MODEL=qwen/qwen2.5-0.5b-instruct

python3 -m sglang.launch_server \
  --model-path ${MODEL} \
  --host 0.0.0.0 \
  --port 30000 \
  --enable-cache-report \
  --log-requests

OpenAI API 烟测

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen/qwen2.5-0.5b-instruct",
    "messages": [
      {"role": "system", "content": "你是一个简洁的 AI Infra 助教。"},
      {"role": "user", "content": "用一句话解释 RadixAttention。"}
    ],
    "temperature": 0,
    "max_tokens": 96
  }'

实验设计很简单:保持 system prompt 完全相同,只改变 user question。 第一个请求会把共享前缀放进缓存;后续请求应该能复用这段 prefix。 我们用 --enable-cache-report 和 return_cached_tokens_details 观察 cached tokens。

from openai import OpenAI
import time

MODEL = "qwen/qwen2.5-0.5b-instruct"
client = OpenAI(base_url="http://localhost:30000/v1", api_key="EMPTY")

SYSTEM_PROMPT = """你是一个 AI Infra 助教。
回答必须使用中文。
回答结构固定为:概念、为什么重要、排查建议。
不要输出无关寒暄。"""

questions = [
    "解释 KV Cache 为什么会成为推理显存大头。",
    "解释 PagedAttention 解决了什么问题。",
    "解释 continuous batching 为什么能提高吞吐。",
    "比较 vLLM 和 SGLang 的缓存思路。",
]

def cached_tokens(resp):
    details = getattr(resp.usage, "prompt_tokens_details", None)
    return getattr(details, "cached_tokens", None) if details else None

for i, q in enumerate(questions, 1):
    t0 = time.perf_counter()
    resp = client.chat.completions.create(
        model=MODEL,
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": q},
        ],
        temperature=0,
        max_tokens=128,
        extra_body={"return_cached_tokens_details": True},
    )
    dt = time.perf_counter() - t0
    usage = resp.usage
    print({
        "i": i,
        "latency_s": round(dt, 3),
        "prompt_tokens": usage.prompt_tokens,
        "cached_tokens": cached_tokens(resp),
        "completion_tokens": usage.completion_tokens,
    })
    print(resp.choices[0].message.content[:120], "\n")

反例:一个字符也可能破坏命中

SYSTEM_PROMPT_A = "你是一个 AI Infra 助教。回答必须使用中文。"
SYSTEM_PROMPT_B = "你是一个AI Infra助教。回答必须使用中文。"

# 对人类看起来差不多,但 tokenizer 看到的是不同 token 序列。
# prefix cache 按 token id 精确匹配,不要依赖“语义相似”。

Prefix cache 不是单纯的“查一下字典”。 调度器要在等待队列里识别哪些请求已经命中缓存、命中多长、哪些 KV 正在被活跃请求引用, 然后把有限的 GPU token budget 分给 prefill 和 decode。

Day34 的压测目标不是最大吞吐,而是证明 prefix cache 真的生效。 用相同请求集跑两组:默认 RadixAttention 与 --disable-radix-cache baseline。 对比 cached tokens、TTFT、总耗时和 prompt throughput。

使用 bench_serving 随机负载

python3 -m sglang.bench_serving \
  --backend sglang-oai-chat \
  --host http://localhost:30000 \
  --dataset-name random \
  --num-prompts 100 \
  --random-input 512 \
  --random-output 128 \
  --request-rate 10 \
  --max-concurrency 32

更适合 Day34 的自定义负载

workload:
  shared_prefix:
    - long_system_prompt
    - tool_schema
    - few_shot_examples
  variable_suffix:
    - user_question_001
    - user_question_002
    - user_question_003

compare:
  A: default radix cache
  B: --disable-radix-cache

metrics:
  - cached_tokens
  - p50_ttft_ms
  - p95_ttft_ms
  - output_tokens_per_s
  - prompt_throughput
  - gpu_memory_used

1. 用自己的话解释 RadixAttention 为什么要用 radix tree 保存 KV Cache。
2. Prefix cache 为什么必须做 token 级精确匹配?哪些模板变化会破坏命中?
3. 对比 PagedAttention 和 RadixAttention:它们分别解决 KV Cache 的什么问题?
4. 如果 cached tokens 很少,你会从 prompt 模板、chat template、请求顺序哪些方向排查?
5. 设计一个“同文档多问”的压测负载,说明你会记录哪些指标。
6. 为什么缓存命中能降低 TTFT,但不一定明显降低长输出阶段的 TPOT?