批处理策略决定SLO
在LLM serving架构中，对SLO影响最直接的是批处理策略的设计。无论配备多高性能的GPU，要同时满足TTFT（Time To First Token）、ITL（Inter-Token Latency）和aggregate throughput三项指标，就必须针对请求到达的波形、输入长度分布、输出长度分布以及KV cache占用模式来设计批处理策略。本文梳理了截至2026年已投入生产的五种方法——continuous batching、chunked prefill、PagedAttention、RadixAttention、sorted batching——的特性、对SLO的影响，以及与prompt cache的组合方式。
Continuous Batching
Continuous batching（又称iteration-level scheduling）是在decode的每个步骤重新决定批次构成的方式。传统的static batching是「同一批次的所有请求全部完成后才接受新请求」，而continuous batching则是「完成的请求立即移出，空出的槽位立即填入新请求」。由此，GPU利用率不易受请求长度差异影响，在输出长度方差较大的对话工作负载中，有效吞吐量可提升2至4倍。
但仅靠continuous batching，prefill与decode在同一step内冲突的问题仍然存在。包含长提示词（8K tokens以上）的请求，其prefill阶段可能耗时数百毫秒以上，在此期间其他请求的decode会被阻塞。这种prefill stall是造成ITL分布长尾的根源。
Chunked Prefill
Chunked prefill将长提示词拆分成小块（典型大小512至2048 tokens），在每次iteration中同时处理「prefill的1个chunk + 其他请求的decode」。这使prefill负载分散到多个step，大幅减少ITL的抖动。对于需要将SLO p99 ITL控制在50ms以内的系统，这是必备功能，vLLM、SGLang、TensorRT-LLM均已标准支持。
chunk大小若过小，kernel launch开销会占主导；若过大，则会阻塞decode。根据KGA的经验，H200上4096至8192 tokens、B200上8192至16384 tokens是合理的起始点。将compute bound的prefill与memory bound的decode混合，可使GPU的compute/memory双侧同时被使用，MFU（Model FLOPS Utilization）比单独处理更高，这是一个额外的收益。
PagedAttention
PagedAttention将KV cache切分成固定大小的页（典型为16个tokens），这是vLLM的核心。它大幅减少内存碎片，在物理内存使用量上可获得2至4倍的有效容量。截至2026年，不仅vLLM，TensorRT-LLM、SGLang、DeepSpeed-Inference的大部分也采用了类似的分页机制。
PagedAttention作为「prefix共享」的基础同样重要，使用相同system prompt的多个请求可共享同一页，物理KV只需保存一份。但vLLM原生的prefix caching是「完全匹配的prefix为单位」，部分匹配或跨租户的优化方面，RadixAttention系列更胜一筹。
RadixAttention
SGLang提出的RadixAttention以radix tree结构管理KV cache，可实现「任意prefix片段」的共享。system prompt、few-shot示例、tool定义、租户公共context等嵌套共享结构，可被自动检测并将物理KV集中存储于一处。
实测基准中，包含共享system prompt的多轮对话（平均轮次8轮，并发会话256个）场景下，RadixAttention比vLLM的prefix caching减少prefill成本40至60%，TTFT中位数改善30至45%。包含大量tool定义的Agent工作负载中，差距可达2至3倍。
另一方面，eviction策略设计较为困难，简单套用LRU时，热租户与冷租户交替出现会导致TTFT骤升。KGA根据情况选用为每个租户赋予优先级的weighted LRU，或为租户固定分配的hard partitioning。
Sorted Batching
Sorted batching是「将输入长度或剩余输出长度相近的请求汇入同一批次」的策略。朴素的continuous batching中，长短混合会带来padding和padding mask的低效；sorted batching可以缓解这一问题。截至2026年，与其说是serving框架的标准内置功能，不如说是上层路由器/调度器实现的功能。
将短响应专用端点（分类、重排序、短摘要）与长响应端点（报告生成、长代码生成）分离，并分别应用sorted batching，是最简洁的设计，实测可实现effective throughput 20至35%的提升。
SLO影响汇总
- TTFT：chunked prefill与prefix caching/RadixAttention是主要决定因素。两者兼备时，p50 TTFT可控制在100ms左右，p99也能控制在500ms以内。
- ITL：continuous batching与chunked prefill有效。不加入chunked prefill，p99 ITL很容易超过200ms。
- Throughput：通过PagedAttention提升内存效率、通过continuous batching充分利用槽位、通过RadixAttention削减prefill浪费，三者组合达到最大化。
- p99尾延迟：通过sorted batching与admission control加以保护。QPS峰值时需要将低优先级请求放入队列的admission policy。
Prompt Cache策略
在生产环境设计prompt cache时，有四个核心维度。
System prompt共享。全租户公共的system prompt在启动时预热并常驻。在RadixAttention中，标准做法是通过启动脚本发送`warmup`请求，将其加载到KV tree。
租户分区。在SaaS型多租户混合场景中，租户A与租户B的context混合有时会引发安全/合规问题。RadixAttention并非密码学隔离，因此在金融、医疗等严格监管领域，需要按租户分离进程（或GPU组），将共享层限定为「非敏感的system prompt」的设计。
TTL与eviction。对于会话时间较长的对话Agent，有效的做法是将多轮对话的中间KV临时缓存，并在会话中断后N分钟进行eviction。根据KGA客户案例，设置TTL为15至30分钟，在内存压力与重新prefill成本之间取得平衡。
跨请求去重。在Agent场景中，同一tool响应被传入多个LLM调用的模式很多，通过对这些tool响应进行指纹去重并只加载一次到KV tree的方式，TTFT可削减30%以上。
配置示例：vLLM + chunked prefill + prefix caching
```python llm = LLM( model="Qwen/Qwen3-72B-Instruct", tensor_parallel_size=8, kv_cache_dtype="fp8", enable_prefix_caching=True, enable_chunked_prefill=True, max_num_batched_tokens=8192, max_num_seqs=256, gpu_memory_utilization=0.92, block_size=16, preemption_mode="recompute", ) ```
`max_num_seqs`设置过大会因内存压力频繁触发swap，实际运维中应根据预期QPS与p99输出长度反推。KGA的经验值是QPS_peak × p99_output_length / expected_decode_rate大致为上限。
总结
批处理策略并非「从五种方法中单选一种」，而是「全部采用后，按SLO调整参数」，这才是2026年的正确答案。守住TTFT选chunked prefill与RadixAttention，守住ITL选chunked prefill与sorted batching，提升throughput选continuous batching与PagedAttention，维护租户隔离选hard partitioning与tenant-aware eviction。以这四个维度设计架构，使用H200 SXM 8卡配置运行70B模型，达到aggregate 2500 tok/s、p99 TTFT 400ms以内的SLO完全可期。