Ang Batching Strategy ang Nagtatakda ng SLO
Sa LLM serving architecture, ang pinaka-direktang nakakaapekto sa SLO ay ang paraan ng pagtatayo ng batching. Gaano man kataas ang performance ng GPU na naka-install, para sabay na matugunan ang tatlong indicator na TTFT (Time To First Token), ITL (Inter-Token Latency), at aggregate throughput, kailangan mong magdisenyo ng batching strategy na naaayon sa waveform ng pagdating ng request, distribusyon ng haba ng input, distribusyon ng haba ng output, at pattern ng KV cache occupancy. Sa artikulong ito, inaayos namin ang mga katangian ng limang pamamaraan na aktibong ginagamit sa 2026—continuous batching, chunked prefill, PagedAttention, RadixAttention, at sorted batching—at ang kanilang epekto sa SLO, pati na rin ang kombinasyon sa prompt cache.
Continuous Batching
Ang Continuous batching (aka iteration-level scheduling) ay isang paraan na muling nagpapasya ng batch composition sa bawat hakbang ng decode. Habang ang tradisyonal na static batching ay 'hindi nagdadagdag ng bago hanggang makumpleto ang lahat ng request sa parehong batch', ang continuous batching ay 'agad inilalabas ang mga natapos na request at isinasaksak ang mga bagong request sa mga bakanteng slot'. Bilang resulta, ang GPU utilization ay hindi gaanong naapektuhan ng pagkakaiba sa haba ng request, at partikular sa chat workload na may malaking variance sa haba ng output, ang effective throughput ay tumataas ng 2-4x.
Gayunpaman, ang continuous batching lamang ay may natitirang problema kung saan ang prefill at decode ay nagtatagpo sa loob ng parehong step. Ang prefill ng isang request na may mahabang prompt (mahigit 8K tokens) ay tumatagal ng daan-daang ms o higit pa, at sa panahon na iyon, ang decode ng iba pang request ay tumitigil. Ang prefill stall na ito ang lumilikha ng long tail sa distribusyon ng ITL.
Chunked Prefill
Ang Chunked prefill ay isang mekanismo na hinahati ang mahabang prompt sa maliliit na chunk (karaniwang 512-2048 tokens) at sabay na pinoproseso ang '1 chunk ng prefill + decode ng ibang request' sa bawat iteration. Sa ganitong paraan, ang load ng prefill ay kumakalat sa maraming step, at lubos na nababawasan ang jitter ng ITL. Ito ay kinakailangang feature para sa mga system na kailangang panatilihin ang SLO p99 ITL sa loob ng 50ms, at lahat ng vLLM, SGLang, at TensorRT-LLM ay may standard support.
Kung masyadong maliit ang laki ng chunk, ang overhead ng kernel launch ay nangingibabaw, at kung masyadong malaki, nag-stall ang decode. Bilang rule of thumb ng KGA, ang 4096-8192 tokens para sa H200 at 8192-16384 tokens para sa B200 ay ang magandang panimulang punto. Mayroon ding side effect na mas mataas ang MFU kaysa sa pagproseso nang hiwalay kapag pinagsama ang compute bound na prefill at memory bound na decode, dahil sabay na ginagamit ang compute at memory ng GPU.
PagedAttention
AngPagedAttention ay isang paraan ng pamamahala na hinahati ang KV cache sa fixed-size na pahina (karaniwang katumbas ng 16 tokens), at ito ang core ng vLLM. Lubos nitong nababawasan ang memory fragmentation at nakakakuha ng 2-4x na epektibong kapasidad para sa pisikal na paggamit ng memorya. Sa 2026, hindi lamang vLLM kundi ang karamihan ng TensorRT-LLM, SGLang, at DeepSpeed-Inference ay gumagamit ng katulad na paging mechanism.
AngPagedAttention ay mahalaga rin bilang pundasyon ng 'prefix sharing', kung saan ang maraming request na gumagamit ng parehong system prompt ay nagre-refer sa parehong pahina, na pinapanatili lamang ang isang pisikal na KV. Gayunpaman, ang prefix caching ng vLLM mismo ay 'per exact-match prefix unit', at ang partial match o cross-tenant optimization ay mas lamang ang RadixAttention style.
RadixAttention
AngRadixAttention na iminungkahi ng SGLang ay namamahala sa KV cache gamit ang radix tree structure, na nagpapahintulot ng pagbabahagi ng 'anumang prefix fragment'. Awtomatiko nitong nakita ang mga nested na shared structure tulad ng system prompt, few-shot examples, tool definitions, at tenant common context, at kino-consolidate ang pisikal na KV sa isang lugar.
Sa aktwal na benchmark, para sa multi-turn chat na naglalaman ng shared system prompt (average na 8 turn, 256 simultaneous session), ang RadixAttention ay nagbibigay ng 40-60% na pagbawas sa prefill cost at 30-45% na pagpapabuti sa TTFT median kumpara sa prefix caching ng vLLM. Sa agent workload na may mahabang tool definition, may mga kaso na mas mataas ng 2-3x ang pagkakaiba.
Sa kabilang dako, mahirap ang pagdidisenyo ng eviction policy, at kapag pinalitan ang mainit at malamig na tenant na may simpleng LRU, biglang tumaas ang TTFT. Sa KGA, pinipili namin ang weighted LRU na may priority assigned sa bawat tenant, o hard partitioning na nag-aassign ng fixed allocation sa bawat tenant, depende sa sitwasyon.
Sorted Batching
AngSorted batching ay isang strategy na 'ipinagtitipon ang mga request na may magkatulad na haba ng input o natitirang haba ng output sa parehong batch'. Ang naïve na continuous batching ay may inefficiency ng padding at padding mask kapag halo-halo ang maikli at mahaba, ngunit ang sorted batching ay nagpapagaan nito. Sa 2026, ito ay higit na feature na isinasagawa ng upper-layer router/scheduler kaysa sa standard na isinasagawa sa serving framework.
Ang pinakasimpleng disenyo ay ang paghihiwalay ng short-response dedicated endpoint (classification, reranking, short summarization) at long-response endpoint (report generation, long-form code generation), at paglalapat ng sorted batching sa bawat isa, at ang aktwal na pagpapabuti ng effective throughput na 20-35% ay nasukat.
Buod ng Epekto sa SLO
- TTFT: Ang chunked prefill at prefix caching/RadixAttention ang nangingibabaw. Kung naroroon ang dalawang ito, ang p50 TTFT ay humigit-kumulang 100ms, at ang p99 ay nasa loob ng 500ms.
- ITL: Ang continuous batching at chunked prefill ay may epekto. Kung wala ang chunked prefill, madaling lumampas ang p99 ITL sa 200ms.
- Throughput: Na-maximize sa tatlong set ng pag-abot ng memory efficiency gamit ang PagedAttention, pagpupuno ng mga slot gamit ang continuous batching, at pag-alis ng prefill waste gamit ang RadixAttention.
- p99 tail: Pinoprotektahan ng sorted batching at admission control. Sa oras ng QPS spike, kinakailangan ang admission policy na nagpu-queue sa mga low-priority request.
Prompt Cache Strategy
May apat na axis kapag nagdidisenyo ng prompt cache sa production stack.
System prompt sharing. Ang mga system prompt na karaniwang ginagamit ng lahat ng tenant ay pina-pre-warm sa oras ng startup at pinapanatili sa memorya. Sa RadixAttention, ang pamantayan ay ang pagpapadala ng `warmup` request sa startup script para mailagay sa KV tree.
Tenant partitioning. Kapag pinaghalo ang maraming tenant sa SaaS-type, maaaring may problema sa seguridad/compliance kung magkahaluan ang context ng tenant A at B. Dahil ang RadixAttention ay hindi cryptographically isolated, para sa mga mahigpit na domain tulad ng financial at medical, kinakailangan ang disenyo na hinahalang ang tenant sa bawat proseso (o GPU group) at nililimitahan ang shared layer sa 'non-confidential system prompt lamang'.
TTL at eviction. Para sa mga chat agent na may mahabang session, epektibo ang disenyo na pansamantalang kino-cache ang intermediate KV ng multi-turn conversation at ini-evict N minuto pagkatapos ng pagtigil ng conversation. Sa mga kaso ng customer ng KGA, tinatakda ang TTL sa 15-30 minuto at inay-ayos ang balanse ng pressure ng memorya at gastos ng muling prefill.
Cross-request dedup. Sa agent style, maraming kaso ng pagpasa ng parehong tool response sa maraming LLM call, at ang pagsisikap na i-dedup ang tool response na ito gamit ang fingerprint at ilagay lamang ito nang isang beses sa KV tree ay nagpapababa ng TTFT ng 30% o higit pa.
Halimbawa ng Configuration: 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", ) ```
Kapag masyadong malaki ang `max_num_seqs`, madalas na mangyayari ang swap dahil sa pressure ng memorya, kaya sa aktwal na operasyon, kinakalkula mula sa inaasahang QPS at p99 output length. Bilang rule of thumb ng KGA, ang QPS_peak × p99_output_length / expected_decode_rate ay halos ang upper limit.
Buod
Ang batching strategy ay hindi ang 'pagpili ng isang paraan mula sa lima' kundi 'pag-adjust ng mga parameter ayon sa SLO pagkatapos ilagay ang lahat ng ito' ang tamang sagot sa 2026. Kung poprotektahan ang TTFT, ang chunked prefill at RadixAttention; kung poprotektahan ang ITL, ang chunked prefill at sorted batching; kung pataasan ang throughput, ang continuous batching at PagedAttention; kung poprotektahan ang paghihiwalay ng tenant, ang hard partitioning at tenant-aware eviction. Kung magdidisenyo ng arkitektura gamit ang apat na axis na ito, ang SLO ng aggregate 2500 tok/s at p99 TTFT na 400ms o mas mababa ay sapat na maaabot sa configuration ng 70B model na may 8 H200 SXM.