nano-vLLM KV Block Manager
마지막 수정:
KV cache를 request마다 연속 tensor로 잡으면 길이가 다른 request를 처리하기 어렵다.
nano-vLLM에서는 KV cache를 고정 크기 block으로 나눈다.
physical blocks:
0, 1, 2, 3, 4, ...
request A block table:
[7, 2, 9]
request B block table:
[1]
KV block manager의 최소 책임은 다음이다.
allocate block
append block to request
free request blocks
logical position -> physical block + offset
이 구조가 있어야 나중에 PagedAttention과 kernel metadata로 이어질 수 있다.
확인
- KV cache를 block으로 나누면 어떤 fragmentation 문제가 줄어드는가?
- block table은 logical block과 physical block 중 무엇을 연결하는가?
- request가 끝났을 때 block manager가 해야 할 일은 무엇인가?