V16 Inference Serving 단권화

1 Autoregressive 2-phase prefill · decode

• prefill = parallel over seq, decode = sequential over time
• 한 request가 두 phase를 직렬 통과 → 스케줄러가 phase별 분기 필요

2 Arithmetic intensity 비대칭

B = batch size. decode AI ≈ batch ↗로만 끌어올림 ↗ V18

3 Sequence 길이 분산 ★

• production trace: input 길이 log-normal · output 길이 geometric · 상호 무관
• long-tail: p50 ≪ p99 (e.g. 200 vs 4K token)
• request 간 이질성이 serving의 핵심 난제

dist hist (실제 트래픽 모양)
 input ▁▂▅█▇▄▂▁▁▁ ... (skew)
 output▂▄█▅▃▂▁▁▁▁ ... (short)
 p50 128    p99 4096

4 Batch 내 이질성 mixed phase

• cu_seqlens = [0, 2000, 2001, 2002] varlen FA 사용 ↗ V07 §4

5 KV cache 성장

Llama-3-70B FP16: L=80, H_kv=8, D=128, T=1 → 320 KB/token·req

6 SLO 이원화

상세 분해는 ↗ §19 p.20

7 Out-of-scope 재확인

• attention kernel 자체 ↗ V07
• 분산 collective 내부 ↗ V15
• quant 알고리즘 ↗ V10
• 일반 scheduler 알고리즘론 (CPU 이론) — 제외

1 Static batching 정의 request-level

t0: B = {A, B, C}   (lock)
 step: forward(pad_to(max_len(B)))
 step: ...
tN: A,B,C 모두 EOS → B = {}
tN+1: new batch {D, E, F}

2 Head-of-Line blocking ★

• batch 내 최장 seq가 종료 지점을 결정
• 짧은 req (output 10 tok) 도 긴 req (output 2000 tok) 끝까지 대기
• p99 latency = longest + queue wait

A (out=10)   ████▫▫▫▫▫▫▫▫▫▫▫▫▫▫▫▫
B (out=2000) ██████████████████████
C (out=50)   █████▫▫▫▫▫▫▫▫▫▫▫▫▫▫▫▫
             ↑ A,C 끝나도 GPU idle

3 Padding waste

varlen kernel이면 waste=0 가능하지만, static batching은 step 단위 동기화가 핵심 문제

4 자원 점유 KV 슬롯

• batch 고정 → KV 슬롯 B개 pre-allocate
• 짧은 req가 끝나도 슬롯 해제 불가 (다음 batch까지 잠김)
• GPU 메모리는 항상 max batch 기준

5 Dynamic batching 중간 단계

• queue wait ↓하지만 HoL blocking 잔존
• LLM 같이 output 길이가 가변이면 효과 제한

6 Static의 처방 공간

7 용어 정리

• step = 한 번의 forward pass
• iteration = decode 1 token (= 1 step)
• batch = 같은 step에 묶인 request 집합

1 Iteration-level scheduling ★ step마다 재편성

• unit of scheduling = iteration, not request
• padding 제거: packed 1D token stream + cu_seqlens
• 짧은 req wait ≈ 0, long req가 short req를 block하지 않음

2 Selective batching

• token-wise op (GEMM, norm, MLP) → packed batch 가능
• sequence-wise op (attention) → per-seq 실행 필요 (varlen FA)
• layer 내부에서 두 모드 전환

3 Core loop 의사코드 ★

# Continuous batching main loop (Orca-style)
def engine_loop():
  while has_requests(waiting | running):
    # 1. schedule a batch for THIS iteration
    batch, budget = scheduler.schedule(
      waiting, running, swapped,
      max_num_batched_tokens,
      max_num_seqs)

    # 2. prepare packed inputs
    input_ids, cu_seqlens, block_tables = \
      prepare_inputs(batch)

    # 3. one forward step (prefill+decode 섞임)
    logits = model.forward(
      input_ids, cu_seqlens, block_tables)

    # 4. sample next tokens per seq
    next_tokens = sampler(logits, batch.params)

    # 5. update each seq & KV cache
    for seq, tok in zip(batch.seqs, next_tokens):
      seq.append(tok)
      if is_finish(seq, tok): finish(seq)
      else: return_to_running(seq)

    # 6. stream partial outputs to clients
    emit_stream_events(batch)

4 효과 정량 개념적

원문: Yu et al. Orca, OSDI'22. 수치는 논문 정성 요약

5 전제 조건

1. varlen attention kernel 지원 (FA varlen ↗ V07 §4)
2. KV cache가 seq 단위로 독립 할당·해제 가능 — PagedAttention 동기
3. sampler/decode logic이 per-seq parameter 지원

1 6-Layer 구성 ★

┌────────────────────────────────────┐
│ API Server (OpenAI-compat, async)  │  Uvicorn/FastAPI
├─────────────▼──────────────────────┤
│ AsyncLLMEngine (event loop)        │  req ingest
├─────────────▼──────────────────────┤
│ LLMEngine                          │  step() driver
│  ├─ Scheduler  (queues, budget)    │  §5
│  ├─ BlockMgr   (KV allocator)      │  §6
│  └─ SequenceGroup pool             │
├─────────────▼──────────────────────┤
│ Executor (MP / Ray)                │  multi-GPU
├─────────────▼──────────────────────┤
│ Worker × N  (1 per GPU)            │
│  └─ ModelRunner                    │
│      ├─ sampler                    │
│      └─ Attention Backend          │  §7
│          (FA2/FA3/FlashInfer/XFM)  │
├─────────────▼──────────────────────┤
│ CUDA kernels + NCCL (TP/PP)        │  ↗ V07/V15
└────────────────────────────────────┘

2 Step 데이터 흐름 1 iteration

1. API → AsyncEngine.add_request()
2. AsyncEngine.step() → LLMEngine.step()
3. Scheduler.schedule()
    → SchedulerOutput{batched_seqs,
                      blocks_to_swap_in,
                      blocks_to_swap_out,
                      blocks_to_copy}
4. Executor.execute_model(SchedOut)
    → broadcast to Workers (TP)
5. Worker.ModelRunner.execute_model()
    a. prepare_inputs (gather tok,
       positions, block_tables)
    b. model.forward()        ← graph?
    c. sampler → next_tokens
    d. return SamplerOutput
6. LLMEngine.process_outputs()
    → update SequenceGroup
    → BlockMgr.free / alloc
7. AsyncEngine yields stream chunks

3 핵심 객체

4 Attention Backend 추상 plug-in

• FlashAttention (FA2/FA3) · FlashInfer · xFormers · TorchSDPA
• Backend 공통 interface: forward(q, kv_cache, block_tables, metadata)
• metadata에 prefill/decode mask, varlen cumsum, causal 플래그 전달
• hardware/dtype/head-dim별 auto-select

5 Executor 모드

6 V1 엔진 재설계

• V1 (2024+): 단일 스케줄러, prefill/decode 통합, async output proc
• Python overhead ↓: C++ core 부분 확장
• structured output · multi-modal 1급 지원

vLLM V1 design doc, 2024-09

1 3-Queue 모델 ★

┌─waiting──┐  new req, prefill 미시작
│ seq, seq │
└──┬───────┘
   │ can_allocate? budget?
   ▼
┌─running──┐  매 step forward
│ seq, seq │
└──┬───────┘
   │ OOM / preempt-swap
   ▼
┌─swapped──┐  KV를 CPU로 off
│ seq, seq │
└──────────┘
 상승 복귀: swap-in 후 running으로

2 Transition 조건

3 Budget 2축 token · seq

• token budget — compute 상한 (one step 시간)
• seq budget — sampler/dispatch overhead 상한
• block budget — KV OOM 방지

4 Preemption 2가지 ★

5 FCFS + priority

• 기본: first-come-first-serve (arrival time)
• priority 지원 시 heap으로 순서 결정
• starvation 방지: aging은 현재 명시적 미지원 (policy 책임)

6 Schedule 의사코드

def schedule():
  budget = Budget(max_tok, max_seq)
  out = []
  # 1. running 먼저 (decode 연속성)
  for s in running:
    if not budget.can_add(s):
      preempt(s); continue
    out.append(s)
  # 2. swapped 복귀
  for s in swapped:
    if can_swap_in(s) and budget.ok():
      swap_in(s); out.append(s)
  # 3. waiting 신규 prefill
  for s in waiting:
    if can_alloc(s) and budget.ok(s):
      alloc(s); out.append(s)
  return out

1 Logical vs Physical ★

seq A logical: [0][1][2][3]
          ↓
block_table_A: [12, 07, 03, 21]  (frame ids)

HBM pool:
 frame 03 ████   ← A.logical[2]
 frame 07 ████   ← A.logical[1]
 frame 12 ████   ← A.logical[0]
 frame 21 ████   ← A.logical[3]

2 Block size B_p

3 Block 크기 바이트 공식

4 Ref count & Copy-on-Write ★

shared prefix (system prompt)
 block_P: refcount = 3  ← A, B, C 공유

A가 prefix 끝에서 분기 (write)
  1. alloc new block_P'
  2. copy block_P → block_P'
  3. A.table[i] = P'; P.refcount-=1
"blocks_to_copy" in SchedulerOutput

• beam search · parallel sampling · prefix cache에서 활용
• CoW는 마지막 block에서만 발생 (완성된 block은 immutable)

5 메모리 프로파일링 기동시

vLLM determine_num_available_blocks()

6 Fragmentation 분석

7 Allocator API 요약

• allocate(seq, num_blocks) · free(seq)
• append_slot(seq) — decode 1 tok당 호출, block 경계 넘으면 new block
• swap_in/out(blocks) — CPU pool 이동
• fork(parent, child) — refcount++, share table

1 Kernel 입력 구조

• kernel 자체의 수식·내부 tiling은 ↗ V07 §16–17
• engine이 kernel에 넘기는 것:
  1. q — 현재 step query (packed)
  2. kv_cache — 전역 pool tensor
  3. block_tables — [B, max_blocks] int32
  4. context_lens — 각 seq의 T
  5. cu_seqlens_q — prefill varlen 경계

2 Gather pattern decode

# per (seq_id, head, tok_idx)
phys = block_tables[seq_id,
                     tok_idx // B_p]
off  = tok_idx % B_p
k = kv_cache[layer, 0,
              phys, off, head, :]
v = kv_cache[layer, 1,
              phys, off, head, :]

vLLM kv_cache shape: [L, 2, n_blocks, B_p, H_kv, D]

3 Prefill vs Decode path 분기

4 v1 vs v2 선택 split-K

• v1: 1 CTA = (seq, head) · 짧은 T 효율
• v2: K축 P partitions · 긴 T에서 SM 포화 ↑
• threshold는 max_context_len과 B에 의존, backend가 결정

자세한 split-K 수식 ↗ V07 §17

5 Prefix cache hit path ★

req 진입:
  1. scheduler: hash(prompt_prefix)
       → hit 노드 N 탐색
  2. N.block_ids 를 seq.block_table에
       prepend (refcount++)
  3. Q kernel은 "cached" span을
       skip — 실제 compute는 새 tok만
  4. 이 단계에서 TTFT ↓ (prefill 단축)

더 상세 → §9 prefix caching p.10

6 KV write path per step

1. model.forward가 현재 step의 new K, V 계산
2. attention backend가 reshape_and_cache kernel 호출
3. block_tables의 "현재 slot"에 write (scatter)
4. attention 자체는 그 다음 kernel 호출에서 paged read

1 동기 왜 쪼개는가

• 긴 prompt (16K~128K) 1-shot prefill → 그 step 전체를 독점 → decode 요청 멈춤
• TTFT는 개선되어도 다른 req의 TPOT가 spike
• 해결: prefill을 C token chunk로 분할, decode 요청과 한 step에 mix

2 Token 예산 통일 공식

3 Step mix 예시

max_batched_tok = 512
req A: decode (1 tok)
req B: decode (1 tok)
req C: prefill 2000 tok (진행중 800/2000)
→ 이번 step tok = [1, 1, 510]
   chunk = 510  (512 − 2)
→ 다음 step: req C chunk 510 ...
최종 step에서 C prefill 완료 → decode 합류

4 Attention 처리 부분 prefill

• chunk N_c token의 Q가 이전 chunk의 KV를 attend
• 현재 chunk 내부 causal + 이전 chunk full attend
• kernel은 prefill varlen + paged cache 동시 — FA2 varlen이 이를 지원

Q: [chunk_k]
K,V: cache[0:chunk_k_start]
     + (chunk_k own K,V)
mask: causal within chunk_k
      full on prior cached

5 효과 정량

overhead 원천: chunk 경계마다 attention kernel re-launch

6 Scheduler와 상호작용

• prefill seq는 여러 step에 걸쳐 running에 머묾
• step마다 num_computed_tokens 갱신
• num_computed_tokens == prompt_len 시 decode 단계로 전환

7 Piggyback & Sarathi

• 메모리 bound decode + FLOP bound prefill = 상보적
• roofline 관점: 두 op AI가 다르므로 동시에 섞으면 효용 ↑ ↗ V18

1 동기

• system prompt · few-shot · agent history — 요청 간 공통 prefix
• prefix를 재연산하지 않고 기존 KV block 재사용
• TTFT ↓, HBM 점유 ↓

2 Hash 체계 ★

tok: [t0..t15][t16..t31][t32..t47]...
hash:   h0      h1        h2
table:  h0→blk_A  h1→blk_B ...

block 경계 토큰 수 불일치 시 hit 불가 — B_p 선택 중요

3 Lookup path

1. 새 req prompt를 B_p-block으로 분할
2. 앞에서부터 chained hash 계산 · table lookup
3. 최장 연속 hit span 결정 (첫 miss에서 break)
4. hit block의 refcount++, req.block_table에 삽입
5. miss span만 prefill 실행

4 Eviction 정책

vLLM 기본: LRU · refcount 0인 block만 free 대상

5 Hit rate 감각

• chat: system prompt 동일 → 60–90% prefix 비율
• agent/tool use: multi-turn history 공유 → 매우 높음
• RAG: context 매번 다름 → 낮음

6 정확성 조건

• prefix hash에 model_id, kv_dtype, lora_id 포함
• multi-tenant 시 tenant namespace 분리

7 RadixAttention과 관계

• vLLM prefix cache: flat hash map
• SGLang RadixAttention: trie 기반 (§14 p.15)
• trie는 중간 분기 공유 가능, hash map은 block-aligned prefix만

1 동기 launch overhead

• decode step = 70B 모델이면 layer × (qkv, attn, o-proj, norm, mlp) = 수백 kernel
• 각 launch ~5–10 μs · 누적 수 ms
• decode 자체는 1 tok · step 내 ms 단위 → launch가 병목
• CUDA Graph로 하나의 캡처된 DAG를 통째 launch

2 Capture 조건

1. 모든 tensor shape·dtype·stride 고정
2. 모든 주소 고정 (포인터 변하면 재캡처)
3. 제어 흐름 데이터에 의존 금지 (static if only)
4. 한 stream 안에서 실행 (cross-stream은 sync node 필요)

3 Graph pool batch size bucketing

capture once per batch size:
  G[1], G[2], G[4], G[8], G[16], G[32]
       ...각각 입력 tensor 고정
실행:
  B_actual = current batch size
  B_padded = next_pow2_or_bucket(B_actual)
  copy inputs into G[B_padded].buffers
  G[B_padded].launch()
  slice outputs[:B_actual]

padding dummy seq가 KV에 쓰지 않도록 mask 필요

4 Dynamic shape 회피

5 적용 범위

• decode only에 주로 적용 (prefill은 shape 변동 大)
• chunked prefill mode는 eager 경로로 fallback하기도
• spec decoding의 verify step도 graph 가능

6 비용

• 각 graph는 자체 workspace · 메모리 ↑
• bucket 개수 × model size = 무시 못함
• capture 시간이 warmup에 추가됨 (수 초~수십 초)

7 관련 설정

• vLLM: enforce_eager=False, cudagraph_capture_sizes
• TRT-LLM: engine build 자체가 static graph
• SGLang: --disable-cuda-graph로 끌 수 있음

1 알고리즘 리마인드

• 수식·rejection sampling 증명 ↗ V08 §12–13
• 여기서는 engine path에 어떻게 꽂히는가만

2 Engine 경로 변화

기본 decode step:
  target.forward(1 tok) → 1 new tok

Spec decode step:
  1. draft.forward(γ tok) → γ drafts
  2. target.forward(γ+1 tok) → γ+1 logits
  3. verify(drafts, target_logits)
     → accepted n ∈ [1, γ+1] tok
  4. seq.append(accepted)
  5. KV cache: accepted n만 commit
     rejected tail은 discard (잘라냄)

3 Worker 구성

4 KV rollback ★

• target이 γ+1 tok의 KV를 미리 cache에 씀
• verify 후 accepted n만 유지, (γ+1−n) tok의 KV는 revoke
• paged 구조상 "마지막 n slot만 유효" 마크 — refcount에 영향 없음
• 다음 step에 draft가 다시 이어감

5 Variant × engine

6 Tree attention path

• draft가 여러 branch → 동시 검증
• target의 attention mask = tree causal mask
• attention backend가 custom mask 지원해야 함 (FA2 packed causal + offset)

7 Scheduler interaction

• token budget에서 spec step은 γ+1 tok/seq로 계산
• accept rate 미달 시 γ 동적 조정 가능 (adaptive γ)

1 양자화 대상 3축

• 알고리즘 (GPTQ/AWQ/SmoothQuant/FP8) 자체 ↗ V10
• 여기는 engine path에 들어가는 기계적 hook만

2 Model loading path

1. config에서 quantization 감지
2. GPTQ/AWQ: kernel-bound Linear → QuantLinear 치환 (group_size, bits 메타 포함)
3. FP8: Linear → Fp8Linear + per-tensor scale
4. weight checkpoint에서 pre-packed quantized tensor 로드

3 Weight-only quant (GPTQ/AWQ)

• backend: Marlin · Machete · ExLlamaV2 · AWQ-cuda
• 선택 조건: batch size, dtype, arch (SM80+ vs SM90)

4 FP8 (H100 native)

• weight · activation 둘 다 FP8 (E4M3 fwd)
• per-tensor 또는 per-block scale
• GEMM은 cuBLAS/CUTLASS FP8 kernel · BF16 accum
• KV cache도 FP8 저장 가능 (per-page scale)

5 KV cache quant path ★

kv_dtype = "fp8_e4m3"
block layout:
  [B_p, H_kv, D]  data
  [per-block scale]  side table

write path:
  k_fp16 → scale_compute → k_fp8
  scale 저장 (per block or per token)

read (attention):
  k_fp8 → scale·k → k_fp16 → QK

정확도 위험: scale 위치 잘못 잡으면 붕괴 ↗ V07 §17 warn

6 Sampler · activation path

• sampler는 보통 FP32 (수치 안정)
• norm, residual, rotary는 FP16/BF16 유지 ↗ V08 §8–9
• 양자화는 GEMM과 KV에만 집중 (edge op는 FP16)

7 Engine별 지원

1 Scope 제한

• collective 알고리즘·NVLink 토폴로지·NCCL 내부 ↗ V15
• 여기는 vLLM engine이 어떻게 TP/PP를 enable하는지만

2 TP 통신 지점 Megatron 방식

3 PP 구성

• layer 집합을 stage로 분할
• inference는 micro-batch 없이 per-request forward
• stage 간 send/recv activation (NCCL P2P)
• PP > 1이면 pipeline bubble 대신 inter-request parallel 활용

4 Worker 간 역할

engine (rank 0 driver)
  Scheduler / BlockMgr  ← 단일
  ┌──────┬──────┐
  │       │       │
Worker0 Worker1 WorkerN    (TP=N)
  ModelRunner × TP
  KV cache per-worker (shard of H_kv or full)
  allreduce 동기식

engine.execute_model:
  broadcast SchedOut to all workers
  각 worker: execute → gather output

5 Executor 선택

6 KV cache under TP

• KV는 head 축으로 shard (H_kv/TP head per worker)
• GQA인 경우 H_kv 작아서 TP가 H_kv 초과 불가
• paged 구조는 per-worker 독립 pool

7 통신·compute overlap

• inference는 학습보다 overlap 기회 적음 (forward only)
• SP (sequence parallel)을 켜면 norm/residual에서 allgather-reduce_scatter 분할
• TP=8 이상에서 allreduce가 병목 → NVLS ↗ V15 §5

8 관련 flag

• --tensor-parallel-size · --pipeline-parallel-size
• --distributed-executor-backend {mp, ray}
• --enable-expert-parallel (MoE EP 별도 축)

1 Radix trie 자료구조 ★

root
 ├─"You are a helpful"─┬─"assistant"  [A,B,C]  rc=3
 │                      └─"expert"     [D]      rc=1
 └─"###"─ ...           ... 

2 연산 API

• match(tokens) → (node, matched_len)
• insert(tokens, block_ids) — split edge if needed
• lock(node) / unlock(node) — refcount +/−
• evict(size) — refcount=0 leaf LRU 제거

3 흐름 per request

req 도착:
  1. radix.match(prompt) → (node, L)
  2. block_tbl = [ node... 조상 블록들 ]
  3. prefill only tokens[L:] (tail)
  4. 생성 중 매 block 완성마다:
       radix.insert(new_block, tokens)
  5. seq 종료:
       unlock 조상 path
       (leaf refcount 0 되면 evict 대상)

4 vLLM prefix cache와 차이

5 Multi-turn 이득

• chat turn 2: prev all tokens가 prefix = trie path 완전 hit
• agent tool loop: 같은 system + tool schema reuse
• hit rate 60–90% 보고 사례

Zheng et al. SGLang, 2024

6 Branching · fork

• parallel sampling n: 한 노드에서 n child leaf
• beam search: branch 시 edge에 token 추가 → 자동 split
• tree-of-thought: 다수 fork 탐색

7 Eviction 정책 세부

1. victim 후보: leaf with refcount=0
2. 각 leaf last_access_time 최소 선택
3. leaf 제거 후 parent가 leaf-되고 refcount=0이면 재귀 제거
4. blocks_to_free 생성 → BlockManager.free

1 SGL 언어 embedded DSL

@function
def multi_turn(s, q):
  s += system("You are...")
  s += user(q)
  s += gen("ans", max_tokens=256)
  if s["ans"].contains("?"):
    s += user("clarify")
    s += gen("clar")

2 Compiled execution

• SGL program은 engine이 직접 해석
• prefix 반복은 RadixAttention이 자동으로 KV 재사용
• parallel fork는 같은 prefix 공유 → 병렬 decode batch 구성

3 Constrained decoding ★

per step:
  state = fsm.current()
  allowed = fsm.allowed_tokens(state)
  logits[~allowed] = -inf
  tok = sample(logits)
  state = fsm.step(state, tok)

4 FSM 종류

engine은 FSM step을 CPU에서 돌리고 GPU logit에 mask 브로드캐스트

5 Token masking 비용

• vocab 100K+ — per-step mask 계산이 병목 가능
• XGrammar: 가능 token set을 bit-packed + precompute
• SGLang은 overlap (next-step mask 미리 계산)

6 Function calling · tool use

1. function schema → JSON CFG
2. model이 tool call → 구조 보장
3. tool 실행 결과를 새 user message로 append
4. RadixAttention이 이전 context 유지 · decode 이어감

7 Other engines의 대응

1 2-Phase: Build → Runtime

[build time]
 Python API (tensorrt_llm)
   → TRT Network Graph (DSL)
   → Plugin insertion (FA, GEMM, …)
   → TRT Engine optimizer
   → serialized .engine file

[runtime]
 C++/Python runtime
   Executor (in-flight batching)
   GptSession / GptManager
   KV Cache Manager (paged)
   samplingConfig per request

2 Plugin 시스템 ★

• TRT 기본 op으론 부족 → custom kernel을 IPlugin으로 wrap
• 핵심 plugin: gpt_attention (FMHA/paged), gemm, rmsnorm, lookup
• plugin은 build 시 선택 · runtime에 고정

3 In-flight batching (IFB)

• vLLM continuous batching과 1:1 대응
• GptSession (batch=1), GptManager (IFB), Executor (최신)

4 KV cache 구성

• Paged KV 지원 (vLLM과 유사)
• kv_cache_reuse flag로 prefix 공유 on
• FP8 KV · INT8 KV 지원 (per-block scale)

5 Engine build 유연성 trade

6 Quant 지원

• W4A16 (AWQ), W8A8 (SmoothQuant), FP8, INT4 weights
• ModelOpt (구 AMMO) 로 양자화 후 TRT-LLM에 전달
• build 시 quant config 고정 → 전용 plugin 선택

7 Triton Inference Server 통합

• TRT-LLM backend plugin (tensorrtllm_backend)
• Triton의 Preprocessor / Postprocessor와 ensemble
• production 배포 기본 패턴

1 5-Engine × 14-Axis 비교 ★ 선택 결정표

출처: 각 프로젝트 공식 문서 · 릴리스 노트 (2024~2025). 기능 유무만 정리, 실측 수치는 제외 (out-of-scope).

1 OpenAI-compatible 스펙

2 요청 파이프라인

HTTP req (JSON)
  → validate (pydantic)
  → apply chat template (jinja)
  → tokenize (prompt_ids)
  → SamplingParams 생성
  → engine.add_request()
  → (async) stream chunks
  → detokenize
  → SSE event write
  → HTTP close

3 Streaming (SSE)

• Server-Sent Events: data: {chunk}\n\n 반복 후 data: [DONE]\n\n
• engine iteration마다 new tok 생성 → per-client chunk 전송
• detokenize는 incremental (BPE 경계 보정: offset_mapping)

4 Chat template

# Jinja2 template (HF tokenizer_config.json)
{% for m in messages %}
<|start|>{{m.role}}\n{{m.content}}<|end|>
{% endfor %}
<|start|>assistant\n

모델마다 다름 · 잘못 적용 시 성능 큰 영향

5 Function calling

1. request에 tools 배열 (JSON schema)
2. schema를 prompt에 주입 (template)
3. constrained decoding (JSON grammar) 으로 구조 보장
4. response parsing → tool_calls 필드

6 Cancellation · abort

• HTTP disconnect 감지 → engine에 abort_request(req_id)
• scheduler가 해당 seq를 running에서 제거, block free
• 이미 dispatch된 step은 완료 후 버려짐 (낭비 최소화는 timing 문제)

7 관측성

1 e2e 공식 ★

2 Prefill 분해

prefill 전체: compute-bound (대부분 구성요소)

3 Decode 분해

decode: memory-bound 지배. batch ↑ or quant ↓로 AI 상승 필요

4 Bottleneck 결정 규칙

• T_TTFT 크다 → prefill GEMM · long context attention (O(N²))
• T_TPOT 크다 → weight load BW · KV read BW
• T_queue 크다 → 용량 부족 · preemption 다발
• variance 크다 → chunked prefill 미적용 · HoL

5 SLO 설계

6 Goodput 지표

• SLO 미달 request는 goodput에서 제외
• C 스윕하여 goodput 최대점 찾기

7 HW 관점 병목

• HBM BW → decode 상한
• SM FLOPs → prefill 상한
• NVLink/PCIe → multi-GPU overhead
• CPU host → Python overhead (V1에서 개선) ↗ V18

1 Fundamental trade ★

tok/s     │    ╱‾‾‾‾‾ saturation (FLOPs)
          │   ╱
          │  ╱  memory-bound linear (BW)
          │ ╱
          └─────────────────▶  B
TPOT      │              ╱
          │           ╱
          │ ──────
          └─────────────────▶  B

2 Memory-bound → compute-bound

• 작은 B: weight/KV 로드가 지배 → step 시간 ≈ const → throughput 선형 ↑
• 큰 B: FLOPs가 지배 → step 시간 선형 ↑ → throughput 포화
• 전환점 B* = HBM BW / (2 · weight_bytes_per_tok)

3 Tunable knobs

4 Chunked prefill ratio

• token budget 중 prefill vs decode 점유 비율 조정
• prefill 비율 ↑ → TTFT ↓, 기존 decode TPOT ↑
• decode 비율 ↑ → TPOT 안정, prefill 대기 ↑

5 Workload별 sweet spot

6 Admission control

• 들어오는 RPS가 capacity 초과 시 queue 폭발 → latency 급증
• 정책: reject · queue + timeout · shed low priority
• goodput 최대점 이상 들어오면 전부 SLO 미달 위험

1 Engine 선택 결정 트리 ★

Q1. 목표가 production low-latency + quant 극한?
  YES → TensorRT-LLM (build 비용 감수)
  NO  ↓
Q2. multi-turn / agent / tree search 중심?
  YES → SGLang (RadixAttention)
  NO  ↓
Q3. Nvidia 외 HW도 필요?
  YES → MLC-LLM (cross-HW) or LMDeploy
  NO  ↓
Q4. 일반 research/throughput, 넓은 모델 커버?
  YES → vLLM (workhorse)
  NO  ↓
Q5. edge/mobile / WebGPU?
  YES → MLC-LLM

2 지표 정의 요약

3 vLLM 경로 요약

API → AsyncEngine → LLMEngine.step()
  → Scheduler.schedule()
      [waiting|running|swapped]
      budget(tok,seq,block)
  → Executor.execute_model()
      broadcast to Workers (TP)
  → Worker.ModelRunner
      prepare_inputs (packed, block_tables)
      model.forward() [CUDAGraph?]
      sampler
  → process_outputs (BlockMgr free/alloc)
  → stream chunks

4 Paged KV 공식 빠른 참조

5 Xref 정리

• attention kernel 수식/내부 → ↗ V07
• LLM 부속 kernel (RoPE/Norm/Sampler/MoE) → ↗ V08
• 양자화 수식·알고리즘 → ↗ V10
• NCCL/5D 병렬 → ↗ V15
• Roofline·stall 분석 → ↗ V18

6 흔한 함정 10선

1. prefix cache 켰는데 tokenizer/quant mismatch로 hit=0
2. CUDA Graph capture가 eager 동작을 박제 → dtype/backend 변경 미반영
3. chunked prefill off 상태에서 long prompt 한 개가 전체 batch 멈춤
4. CoW 미구현/미호출로 prefix 공유 seq의 KV 오염
5. spec decoding을 큰 batch에 적용 — gain 소실
6. FP8 KV scale 위치 오인 → 정확도 붕괴
7. max_model_len ≫ 실제 사용 → KV pool 과소, 동시성 ↓
8. TP size > H_kv 설정 → GQA 모델 load 실패
9. detokenize incremental 버그 → BPE 경계 깨짐
10. admission 없이 RPS 과잉 → queue 폭발, 전부 SLO 미달