LLM Serving 전체 문항

301회. 프롬프트용 pass 1회에 출력 토큰 300개분을 더합니다.

prefill을 출력과 별개의 비용으로 세면 이 답이 나옵니다. 하지만 prefill은 KV Cache만 만들고 끝나는 것이 아니라 마지막 토큰 위치의 출력, 즉 첫 번째 생성 토큰까지 함께 내놓습니다. 첫 토큰이 이미 나왔으므로 decode 스텝은 299번만 더 돌면 됩니다.

2,348회. 프롬프트든 출력이든 토큰 하나에 pass 하나가 대응합니다.

생성이 토큰 단위라는 사실을 입력에까지 확장한 오해입니다. 프롬프트 토큰들은 이미 전부 주어져 있어 순서대로 처리할 이유가 없고, Transformer는 2,048개를 한 번의 pass에서 병렬로 밀어 넣습니다. 순차 처리가 강제되는 쪽은 아직 존재하지 않는 토큰을 만들어내야 하는 출력뿐입니다.

프롬프트가 길수록 pass도 늘어나므로 출력 토큰 수만으로는 정해지지 않습니다.

프롬프트가 길면 느려지는 것은 맞지만, 늘어나는 것은 pass 횟수가 아니라 prefill 한 번의 무게입니다. 프롬프트가 한 스텝의 토큰 예산 안에 들어가는 한 prefill은 pass 1회이고, 대신 그 1회가 처리하는 행렬이 커집니다. 그래서 프롬프트 길이는 pass 횟수가 아니라 TTFT에 반영됩니다.

약 16ms, 초당 약 62토큰.

파라미터당 4바이트, 즉 fp32로 계산했을 때 나오는 값입니다. bf16은 지수부 8비트와 가수부 7비트에 부호 1비트를 더해 총 16비트, 파라미터당 2바이트입니다. 정밀도를 절반으로 줄이는 것이 곧 읽을 데이터를 절반으로 줄이는 것이라는 점이 memory-bound 단계에서 결정적입니다.

약 4ms, 초당 약 250토큰.

파라미터 수 8B를 그대로 8GB로 읽으면 이 값이 나옵니다. 파라미터 개수와 바이트 수는 정밀도를 곱해야 이어지고, bf16에서는 개수의 2배가 바이트 수입니다. 이 환산을 건너뛰면 필요한 GPU 메모리도 절반으로 잘못 잡게 됩니다.

A100의 bf16 연산 성능(약 312 TFLOPS)까지 알아야 계산됩니다.

배치 1의 decode에서는 연산 성능이 상한을 정하지 않으므로 이 값은 식에 등장하지 않습니다. 스텝당 실제로 하는 일은 토큰 1개를 위해 가중치 전체를 HBM에서 한 번 훑는 것이고, 연산 유닛은 그 데이터를 기다리며 대부분 놉니다. 연산 성능이 상한을 정하는 쪽은 수천 토큰을 한꺼번에 미는 prefill입니다.

KV Cache 공간이 모자라 기존 요청 일부가 선점되었다가 다시 스케줄되었습니다.

선점은 실제로 ITL을 크게 튀게 하는 원인이지만 여기서는 조건이 맞지 않습니다. KV cache usage가 51.2%로 절반 남짓이고 Waiting도 0이라 메모리 압박의 흔적이 없습니다. 선점이 일어났다면 Waiting에 밀려난 요청이 잡히고 별도의 preemption 경고가 함께 찍혔을 것입니다.

긴 프롬프트 때문에 attention이 훑을 KV Cache가 커져 decode 스텝이 느려졌습니다.

새 요청의 KV Cache가 커지면 그 요청이 낀 스텝의 어텐션 시간이 늘어나는 것은 맞습니다. 하지만 그 부담은 요청이 살아 있는 동안 계속 남으므로 지연도 그 뒤로 유지되어야 하는데, 다음 구간에서 ITL 꼬리가 61ms로 되돌아왔습니다. 한 구간에만 나타나고 사라졌다는 사실이 지속적 부담이 아니라 일회성 사건을 가리킵니다.

배치가 32개에서 33개로 늘면서 스텝당 가중치 읽기가 그만큼 나뉘어 느려졌습니다.

방향이 반대입니다. decode는 배치를 키워도 가중치를 여전히 한 번만 읽으므로 스텝 시간이 요청 수에 비례해 늘지 않고, 그래서 배칭이 거의 공짜 점심이 됩니다. 실제로 Running이 33으로 유지된 다음 구간에서 ITL이 원래대로 돌아온 것이 배치 증가가 원인이 아님을 보여줍니다.

4비트 가중치의 정확도 손실 탓에 출력이 길어져 스텝 수가 늘어난 것입니다.

정확도 저하는 실제로 일어날 수 있지만 그것이 TTFT를 나쁘게 만들지는 못합니다. TTFT는 첫 토큰이 나오기까지의 시간이라 출력 길이와 무관하게 결정됩니다. 품질 문제와 속도 문제는 원인도 측정 지점도 다릅니다.

4비트 커널의 최적화가 덜 된 문제이며 배치 크기나 단계와는 무관합니다.

커널 구현이 원인이라면 배치 1에서도 이득이 없었어야 하는데 그쪽에서는 2배 가까이 빨라졌습니다. 같은 커널이 조건에 따라 이득과 손해를 오간다는 것은 병목이 옮겨갔다는 뜻입니다. 무엇이 병목인지 묻지 않고 구현 탓으로 돌리면 배치 크기라는 진짜 변수를 놓치게 됩니다.

가중치가 작아진 만큼 KV Cache 예산이 늘어나서, 배치당 메모리 접근량이 함께 늘어난 것입니다.

가중치가 줄면 KV Cache에 쓸 공간이 늘어나는 것은 맞지만, 여유 공간이 생겼다고 요청 하나의 KV Cache가 저절로 커지지는 않습니다. KV Cache 크기는 시퀀스 길이와 모델 구조가 정하고, 여기서는 동시 요청 수를 고정한 채 비교했습니다. 게다가 이 설명으로는 TTFT가 나빠진 이유를 댈 수 없습니다.

KV Cache 읽기가 배치와 무관한 상수이기 때문이며, 배치에 비례해 늘어난 가중치 읽기가 4.8TB/s를 먼저 포화시킵니다.

상수와 변수를 맞바꾼 설명입니다. 가중치는 배치에 묶인 요청들이 전부 같은 것을 쓰므로 스텝당 한 번만 읽히고, KV Cache는 요청마다 내용이 달라 읽을 양이 배치에 비례해 늘어납니다. 스텝 시간이 그나마 14% 오른 것도 커진 KV Cache 쪽 몫이지 가중치 쪽이 아닙니다.

배치가 KV Cache를 한 벌로 공유해 읽을 양이 늘지 않기 때문이며, 배치가 아니라 컨텍스트 상한 16,384가 먼저 걸립니다.

가중치는 배치가 공유하지만 KV Cache는 공유되지 않습니다. 요청마다 지금까지 본 토큰이 다르니 K와 V도 달라지고, prefix caching까지 꺼져 있어 요청 수만큼의 캐시를 따로 들고 있어야 합니다. 컨텍스트 상한은 요청 하나가 얼마나 길어질 수 있는지를 정할 뿐, 평균 8,000토큰 트래픽에서 동시 요청 수를 묶는 것은 58GB 풀입니다.

배치 64에서도 연산 유닛이 데이터를 기다리며 놀고 있기 때문이며, 연산 강도가 206에 닿는 배치에서 연산이 먼저 막습니다.

연산에 여유가 남았다는 관찰은 맞지만 한계를 잘못 짚었습니다. bf16 decode의 연산 강도는 배치 크기와 같은 값이라 206 근처에서 연산이 포화하는 것은 사실이나, 배치 206을 띄우려면 KV Cache만 430GB가 넘게 필요해 141GB 카드로는 닿을 수 없습니다. 이 서버에서 먼저 걸리는 쪽은 언제나 메모리입니다.

모델 가중치가 훨씬 커서 애초에 남는 메모리가 적기 때문입니다.

가중치는 모델을 올리는 순간 정해지는 고정분이라 동시 요청 수를 따라 늘지 않습니다. 더 작은 모델로 바꾸면 여유 공간은 커지지만, 요청이 늘수록 메모리가 차오르는 성질 자체는 그대로 남습니다. 요청 수에 따라 변하는 몫이 무엇인지가 질문의 핵심입니다.

decode가 계산 집약적이라 GPU 연산 코어가 먼저 포화되기 때문입니다.

방향이 반대입니다. decode는 토큰 하나당 연산량이 적은 대신 가중치와 캐시를 메모리에서 읽어와야 해서 대역폭에 먼저 묶입니다. 연산 코어가 남기 때문에 오히려 배치를 키워 처리량을 올리려 하고, 그때 걸리는 벽이 연산이 아니라 메모리입니다.

요청마다 입력 길이가 달라 배치 패딩으로 버려지는 공간이 크기 때문입니다.

길이가 제각각인 요청을 한 배치로 묶을 때 생기는 낭비는 실재하는 문제입니다. 다만 그 낭비를 완전히 없애도 진행 중인 요청들의 캐시가 동시에 상주해야 한다는 사실은 남습니다. 상한을 만드는 것은 버려지는 몫이 아니라 상주하는 몫입니다.

70B 쪽이 약 2배 큽니다. 레이어가 80개로 두 배입니다.

레이어 수만 보면 그렇게 보이지만 KV 크기는 레이어 수와 KV head 수를 함께 곱해서 정해집니다. 70B는 레이어가 2배인 대신 KV head가 40개에서 8개로 5분의 1이라, 두 항을 곱하면 오히려 2.5분의 1이 됩니다.

70B 쪽이 약 5.3배 큽니다. 파라미터 수 비에 비례합니다.

파라미터 수는 가중치가 차지하는 고정분을 정할 뿐 토큰당 KV 크기와 직접 연결되지 않습니다. KV 크기를 정하는 값은 레이어 수, KV head 수, head_dim, dtype 네 가지뿐입니다. FFN 폭을 넓혀 파라미터를 늘린 모델은 KV가 전혀 늘지 않습니다.

두 모델이 거의 같습니다. head_dim이 128로 동일합니다.

head_dim이 두 모델 모두 128인 것은 맞습니다. 5120을 40으로 나눠도, 8192를 64로 나눠도 128입니다. 다만 head_dim은 곱해지는 네 항 중 하나일 뿐이고, 레이어 수와 KV head 수가 두 모델에서 다르므로 결과도 갈립니다.

두 서비스 모두 8개 안팎입니다. 로그가 상한을 8.00x로 못박았습니다.

그 줄은 모든 요청이 max_model_len인 32,768 토큰을 꽉 채웠다고 가정했을 때의 값입니다. vLLM은 KV 풀의 블록 수를 그런 요청 하나가 쓰는 블록 수로 나눠 이 숫자를 계산합니다. 실제 요청이 그보다 짧으면 동시 처리 수는 8을 훨씬 넘어갑니다.

두 서비스 모두 870개 안팎입니다. 새로 자라는 것은 출력 300 토큰뿐입니다.

생성 중에 새로 자라는 양이 300 토큰으로 같은 것은 맞습니다. 하지만 prefill이 만들어낸 프롬프트 몫의 K, V가 사라지는 것이 아니라 응답이 끝날 때까지 그대로 상주합니다. 점유량을 정하는 것은 늘어난 양이 아니라 상주하는 총량입니다.

A는 약 57개, B는 약 5개입니다. 풀의 절반은 prefill 작업 공간으로 남겨둡니다.

KV 풀은 전부 KV 저장에 쓰입니다. prefill이 쓰는 중간 활성값은 풀이 아니라 시작할 때 따로 떼어둔 활성값 몫에서 나가므로, 풀을 절반만 세어야 할 이유가 없습니다. 262,144 토큰은 그대로 요청들에 나눠 줄 수 있는 양입니다.

컨텍스트가 길어질수록 스텝마다 읽는 가중치 양도 함께 늘어나서, 총 읽기가 두 항 모두에서 커진 결과입니다.

가중치 16 GiB는 컨텍스트 길이와 무관하게 매 스텝 전부 읽는다고 표에 명시되어 있습니다. 총 읽기에서 KV 몫을 빼면 세 줄 모두 16 GiB로 같습니다. 컨텍스트를 따라 변한 항은 KV 읽기 하나뿐입니다.

캐시가 제구실을 했다면 지연이 고정이어야 하므로, 앞선 토큰의 K, V를 다시 계산하고 있다는 신호입니다.

캐시가 정상이어도 attention은 스텝마다 지금까지 쌓인 K, V를 전부 훑어야 하므로 지연이 고정될 수 없습니다. 게다가 K, V를 다시 계산한다면 늘어나는 것은 연산량이지 캐시에서 읽어오는 바이트가 아닌데, 표에서 커진 항은 KV 읽기입니다.

컨텍스트가 32배 커지는 동안 지연은 2배 미만이므로, 캐시를 훑는 몫은 컨텍스트에 로그로 자랍니다.

지연이 1.9배에 그친 것은 맞지만 이유가 다릅니다. 컨텍스트와 무관한 가중치 16 GiB가 총 읽기의 바닥을 깔고 있어 전체 증가율이 눌린 것입니다. 캐시를 훑는 몫만 떼어 보면 0.49 GiB에서 15.63 GiB로 32배, 즉 컨텍스트에 정비례합니다.

블록 14개를 쓰고 마지막 블록에 13칸이 빕니다.

221을 16으로 나눈 나머지 13은 마지막 블록에 들어찬 칸 수이지 빈칸 수가 아닙니다. 빈칸은 16에서 그 값을 뺀 3칸입니다. 채워진 칸과 빈칸을 뒤집어 세는 실수가 자주 나옵니다.

블록 15개를 쓰고 마지막 블록에 7칸이 빕니다.

프롬프트와 출력이 각각 자기 블록에서 시작한다고 보면 12개와 3개로 나뉘어 15개가 되고, 출력 쪽 마지막 블록에 7칸이 빕니다. 실제로는 논리 블록이 시퀀스 전체에 걸쳐 왼쪽부터 순서대로 채워지므로, 프롬프트의 마지막 토큰과 첫 출력 토큰이 같은 블록 안에 나란히 들어갑니다.

요청의 max_tokens 값에 따라 정해져 221토큰만으로는 알 수 없습니다.

max_tokens만큼 미리 잡아두는 것은 연속 할당 방식의 동작입니다. 블록은 앞 블록이 다 찬 뒤에야 하나씩 새로 붙으므로, 점유량은 실제로 만들어진 토큰 수만으로 정해집니다.

어텐션 커널이 블록 단위로 KV를 읽어 계산이 빨라진 만큼 요청을 더 받게 된 것입니다.

PagedAttention 커널은 블록 테이블을 따라가며 흩어진 블록을 모아 읽으므로, 연속 배열을 그대로 훑는 커널보다 어텐션 자체는 오히려 조금 느립니다. 동시에 올라가는 요청 수를 늘린 것은 커널 속도가 아니라 점유 방식의 변화입니다.

KV를 16토큰 단위로 묶어 저장하면서 형식이 조밀해져 실제 바이트 수가 줄어듭니다.

블록으로 나누는 것은 저장 위치를 쪼개는 일이지 값을 압축하는 일이 아닙니다. 같은 토큰의 K와 V는 블록에 담기든 연속 배열에 담기든 바이트 수가 같습니다. 저장 바이트를 실제로 줄이는 것은 KV 양자화 같은 별개의 기법입니다.

요청이 끝나기 전에도 앞쪽 블록을 반납해 KV를 돌려 쓰게 된 것입니다.

앞쪽 블록은 뒤에 생성되는 토큰의 어텐션이 계속 읽어야 하므로, 윈도우 밖을 보지 않는 sliding window 레이어가 아니라면 생성 도중에 내놓을 수 없습니다. 생성 중에 KV를 내려놓는 것은 선점될 때 재계산을 택하는 별개의 동작이고, 낭비가 사라진 이유가 아닙니다.

여전히 거절됩니다. 어텐션 계산에 연속된 KV가 필요하다는 조건은 그대로입니다.

그 조건을 깨는 것이 PagedAttention 커널입니다. 블록 테이블을 따라가며 흩어진 블록을 읽어 어텐션을 계산하므로 KV가 물리적으로 이어져 있지 않아도 됩니다. 대신 블록 테이블을 참조하고 블록마다 접근을 나누는 만큼 어텐션 커널 자체는 조금 느려집니다.

빈 조각을 앞으로 밀어 모으는 압축이 먼저 돌고 나서야 수용됩니다.

압축은 KV Cache에 현실적인 선택이 아닙니다. 옮겨야 할 데이터가 기가바이트 단위인데 그 이동이 매 스텝 지연에 그대로 얹히기 때문입니다. 블록 단위 관리는 조각을 모으는 대신 조각난 채로 쓸 수 있게 만들어 압축이 필요한 상황 자체를 없앱니다.

수용됩니다. 흩어진 900칸을 이어 붙여 512칸짜리 연속 구간으로 되돌릴 수 있습니다.

블록 단위 관리는 조각을 이어 붙이지 않습니다. 애초에 연속 구간을 만들 필요를 없애는 것이 요점이고, 흩어진 블록은 흩어진 채로 블록 테이블에 등록됩니다. 이어 붙여야 한다는 발상은 여전히 연속 할당의 사고에 머물러 있습니다.

블록마다 크기가 달라져 어중간한 빈틈이 쌓이는 외부 단편화가 되살아납니다.

블록 크기를 32로 올려도 풀 안의 모든 블록은 여전히 서로 같은 크기입니다. 크기가 제각각일 때만 어느 요청에도 맞지 않는 빈틈이 생기므로, 큰 블록만 있는 풀에서도 빈 블록은 어떤 요청에든 들어갑니다. 커진 블록이 만드는 낭비는 블록 안쪽에 갇히는 내부 단편화입니다.

공통 시스템 프롬프트의 KV가 요청마다 따로 저장되어 접두어 공유 자체가 동작하지 않습니다.

블록 크기를 키워도 여러 요청의 블록 테이블이 같은 물리 블록을 가리키는 구조는 그대로라 공유는 계속 동작합니다. 달라지는 것은 공유가 성립하는 입도이고, 32의 배수까지만 맞아떨어져 재사용 구간이 짧아질 뿐입니다.

물리 블록 풀 전체 크기가 절반으로 줄어 담을 수 있는 총 토큰 수가 줄어듭니다.

풀 전체 크기는 GPU 메모리에서 모델 가중치와 활성화가 쓸 몫을 뺀 나머지로 정해지고, 블록 크기는 그 공간을 몇 조각으로 자를지만 정합니다. 블록 개수가 절반이 되는 대신 블록 하나가 두 배 커지므로 담을 수 있는 총 토큰 수는 거의 그대로입니다.

쌍 P에서 7개, 쌍 Q에서 6개가 복사되어 모두 13개가 됩니다.

공통 구간이 차지한 블록 수를 그대로 센 값입니다. 100토큰은 블록 7개, 96토큰은 블록 6개를 씁니다. 갈라짐이 공유를 통째로 끝낸다는 전제가 틀렸습니다. 앞쪽 블록들은 이미 확정된 토큰의 K와 V만 담고 있어 양쪽 요청이 읽기만 하므로, 값이 달라질 일이 없어 한 벌로 계속 공유됩니다. 복사가 필요한 자리는 두 요청이 서로 다른 값을 써 넣으려는 블록뿐입니다.

쌍 P와 쌍 Q 양쪽에서 각각 1개씩, 모두 2개가 복사됩니다.

갈라지는 순간 자체를 복사의 방아쇠로 본 답입니다. 복사를 부르는 것은 갈라짐이 아니라 이미 공유 중인 블록 안으로 쓰기가 들어오는 일입니다. 96은 16의 배수라 쌍 Q는 마지막 공유 블록까지 꽉 차 있고, 97번째 토큰은 그 블록이 아니라 아직 매핑이 없는 다음 논리 블록으로 갑니다. 꽉 찬 블록은 이후 아무도 덧쓰지 않으니 복사할 이유가 없습니다.

쌍 P에서 2개가 복사되고, 쌍 Q에서는 한 개도 복사되지 않습니다.

갈라지는 두 요청이 각자 한 벌씩 복사한다고 본 값입니다. 먼저 쓴 요청이 새 블록을 받아가면서 원래 블록을 놓아주기 때문에 그 블록의 참조 카운트는 1로 내려가고, 뒤에 쓰는 요청은 더 이상 공유 상태가 아닌 그 블록에 그대로 덧씁니다. 그래서 두 요청이 동시에 갈라져도 실제 복사는 한 번에 그칩니다.

X의 첫 청크에 4,096토큰을 주고, A부터 E는 다음 스텝으로 밀립니다.

waiting 큐를 먼저 보는 순서였다면 긴 요청이 들어올 때마다 진행 중인 요청의 토큰이 멈춥니다. V1은 running 큐를 먼저 훑기 때문에 그 일이 생기지 않습니다.

A부터 E에 1토큰씩 주고, 남은 4,091토큰은 놀린 채 X를 다음 스텝으로 미룹니다.

예산에 통째로 안 들어가면 대기시키는 것은 chunked prefill이 없을 때의 동작입니다. 프롬프트가 12,000토큰인데 예산이 4,096이면 X는 영원히 시작하지 못합니다. 잘라서라도 넣는 것이 V1 스케줄러의 기본 동작입니다.

A부터 E에 1토큰씩 주고, 그와 별개로 X의 첫 청크에 4,096토큰을 씁니다.

예산은 그 스텝의 forward pass에 밀어 넣는 토큰 전부에 걸리는 상한입니다. decode 토큰도 같은 배치에 실리므로 예산에서 함께 차감됩니다. decode가 몇 개 안 되면 차이가 작지만, 동시 요청이 수백 개면 이 몫이 예산에서 무시 못 할 자리를 차지합니다.

긴 prefill이 그 스텝을 독점해 진행 중인 요청의 decode가 아예 빠집니다.

chunked prefill이 없던 시절의 동작입니다. V1 스케줄러는 running 큐의 decode부터 예산에 채우므로 decode가 스텝에서 통째로 밀려나는 일은 없습니다. 빠지는 것이 아니라 함께 실린 채로 스텝이 길어집니다.

KV 블록이 모자라 선점이 일어나고, 선점된 요청이 재계산되는 동안 토큰이 멈춥니다.

선점이라면 엔진 로그에 Preemptions 항목이 나타나는데 여기에는 그 흔적이 없습니다. 선점은 특정 요청의 진행분을 0으로 되돌리는 사건이라 231ms보다 훨씬 큰 공백을 만듭니다.

매 스텝 배치를 새로 구성하는 스케줄링 비용이 스텝 사이에 끼어들어 간격이 벌어집니다.

스케줄 결정은 요청 수만큼의 항목을 담은 딕셔너리를 만드는 정도의 일이라 밀리초 단위 지연을 만들지 않습니다. 매 스텝 배치를 다시 짜는 것은 continuous batching의 비용이 아니라 이득의 원천입니다.

max_num_seqs를 256에서 64로 낮춥니다.

동시 요청이 16개인 부하에서 상한을 64로 내려도 배치 구성은 그대로입니다. 상한이 실제 배치를 제약하지 않으니 꼬리도 처리량도 움직이지 않고, 배치가 컸다 해도 decode 몫이 줄면 prefill 청크가 커질 자리만 넓어집니다.

max_num_batched_tokens를 8,192에서 32,768로 올립니다.

prefill을 더 빨리 끝내면 끊김도 빨리 끝난다는 직관인데 방향이 반대입니다. 청크가 커지면 그 스텝 하나가 더 길어져 꼬리는 더 높아집니다. 이 방향은 TTFT와 처리량을 우선할 때 고르는 쪽입니다.

max_num_seqs를 256에서 1,024로 올립니다.

배치를 키우면 GPU를 더 쓴다는 생각이지만, ITL 꼬리의 원인인 prefill 청크 크기와는 무관합니다. 블록 풀이 늘지 않는 한 실제 배치 크기도 따라 오르지 않습니다.

행렬 곱 연산량은 어떻게 잘라도 같으므로, 이 하락은 측정 잡음으로 봐야 합니다.

선형 계층의 곱셈 연산량이 자르는 방식과 무관하다는 것까지는 맞습니다. 하지만 달라지는 것이 연산량 말고도 있습니다. attention이 읽어야 하는 KV의 양과 커널의 효율이 함께 움직이고, 14%는 잡음으로 넘길 크기가 아닙니다.

청크를 처리할 때마다 KV Cache 블록을 새로 할당하는 비용이 붙어 쌓입니다.

블록 할당은 요청이 필요로 하는 블록 수만큼 일어나고, 그 총량은 프롬프트 길이가 정합니다. 청크를 몇 개로 자르든 결국 같은 수의 블록을 할당하므로 이 비용은 거의 변하지 않습니다.

예산이 작아진 만큼 running decode가 가져가는 몫의 비중이 커져 prefill 자리가 줄었습니다.

방향은 맞지만 크기가 안 맞습니다. Running이 16개면 decode 몫은 예산의 0.2%(8,192일 때)에서 1.6%(1,024일 때)로 오를 뿐이라 prefill에 남는 자리는 1.4%p 남짓 줄어듭니다. 관측된 14% 하락을 이 몫으로 설명할 수 없습니다.

선점된 요청의 KV가 CPU 메모리로 스왑됐다 돌아오느라 PCIe 전송이 병목이 됐습니다.

V1의 선점은 스왑이 아니라 재계산입니다. 블록을 풀에 반납하고 그 요청을 waiting 큐 맨 앞에 되돌려 놓을 뿐이라, KV가 CPU로 오가는 경로 자체가 없습니다. 손해는 전송이 아니라 버린 계산을 다시 하는 데서 옵니다.

prefix cache hit rate가 5%대에 머물러 재계산이 늘어난 것입니다.

히트율은 변경 전 5.1%, 변경 후 5.3%로 사실상 그대로입니다. 두 측정에서 달라지지 않은 값은 달라진 결과의 원인이 될 수 없습니다. 히트율이 오르면 요청당 점유가 줄어 도움이 되기는 하지만, 지금 Running을 297에 묶고 있는 것은 100%에 붙은 KV 풀입니다.

배치가 커지면서 decode의 attention 비용이 요청 수의 제곱으로 늘어 스텝이 느려졌습니다.

요청들의 attention은 서로 독립이라 비용은 요청 수에 비례해 늘 뿐 제곱이 되지 않습니다. 게다가 decode는 memory-bound라 배치를 키우면 요청당 비용이 오히려 줄어듭니다. 배치를 키우는 것 자체는 처리량에 유리하고, 문제는 블록 없이 키운 데 있습니다.

1,050스텝분입니다. R4를 제외한 세 슬롯이 350스텝 내내 비어 있던 셈입니다.

세 슬롯도 각자 자기 출력 길이만큼은 토큰을 만들었습니다. R1은 40스텝, R2는 90스텝, R3은 120스텝을 실제로 일했으므로 그 250스텝분은 낭비가 아닙니다. 이 값은 세 슬롯이 처음부터 아무 일도 하지 않았다고 볼 때 나오는 수치입니다.

310스텝분입니다. R1이 끝난 뒤부터 배치 종료까지 빈자리가 남아 있던 스텝 수입니다.

빈자리가 하나라도 있던 스텝의 개수는 310이 맞지만, 묻는 것은 슬롯 단위의 낭비량입니다. 41번째 스텝에는 빈 슬롯이 하나뿐이지만 121번째 스텝부터는 셋이 비어 있으므로, 스텝 수만 세면 여러 슬롯이 동시에 노는 구간이 한 번으로 접힙니다.

1,400스텝분입니다. 배치가 끝날 때까지 네 슬롯이 묶여 있던 시간 전체입니다.

1,400은 이 배치가 붙들고 있던 슬롯 예산의 총량이고, 그 안에는 실제로 토큰을 만든 600스텝분이 함께 들어 있습니다. 점유한 시간 전부를 낭비로 세면 배치가 한 일까지 낭비로 계산하는 셈이 됩니다.

공통 지시문 400토큰이 히트합니다. 같은 토큰열의 KV는 어디에 놓여도 같습니다.

토큰 하나의 KV는 자기 자신과 앞선 토큰들 전부에 의존합니다. 앞에 문서 청크 A가 온 지시문과 문서 청크 B가 온 지시문은 토큰 id만 같을 뿐 KV 값이 다릅니다. 이걸 재사용하면 결과가 조용히 틀어집니다.

공통 지시문 중 16토큰 블록 경계에 맞아떨어지는 구간만 히트합니다.

블록 경계는 이미 시작된 히트 구간이 어디서 끊기는지를 정하는 규칙입니다. 프롬프트 중간에서 매칭을 새로 시작하게 해주는 장치가 아닙니다. 조회는 항상 맨 앞 블록부터 순서대로 진행됩니다.

두 요청에 같은 cache_salt를 주면 공통 지시문 400토큰이 히트합니다.

cache_salt는 캐시를 나누는 장치이지 붙이는 장치가 아닙니다. 같은 salt는 재사용 자격을 열어줄 뿐이고, 토큰열이 다르면 키는 여전히 다릅니다. salt를 맞춰도 이 두 요청은 서로의 블록을 볼 수 없습니다.

60토큰입니다.

시스템 프롬프트 1,530토큰이 통째로 히트한다고 본 값입니다. 1,530은 16으로 나누어떨어지지 않아 마지막 10토큰이 블록을 채우지 못합니다. 채워지지 않은 블록은 해시가 매겨지지 않아 캐시 대상이 아닙니다.

76토큰입니다.

미완성 블록 하나를 16토큰으로 통째로 세고 질문 60토큰을 더한 값입니다. 실제로 재계산되는 것은 블록의 크기가 아니라 히트 경계 뒤에 남은 토큰 수입니다. 여기서는 시스템 프롬프트의 잔여분이 16이 아니라 10토큰입니다.

1,590토큰입니다.

프롬프트 뒷부분이 다르면 해시 사슬 전체가 달라진다고 본 값인데, 사슬은 앞에서 뒤로 흐릅니다. 뒤쪽 블록이 앞쪽 블록의 키에 영향을 주는 경로는 없습니다. 앞이 같으면 앞부분 블록의 키는 그대로 같습니다.

캐시 히트가 아예 나지 않습니다. 블록마다 독립적인 키를 갖게 되어 접두사를 대조할 수단이 사라집니다.

해시 방식은 접두사를 공유하지 못한다는 흔한 오해입니다. 부모 해시를 빼면 매칭이 사라지는 것이 아니라 너무 헐거워집니다. 문제는 히트가 안 나는 쪽이 아니라 나면 안 될 곳에서 나는 쪽입니다.

해시 충돌 확률이 올라가지만 SHA-256을 쓰므로 실질적인 문제는 없습니다.

충돌은 서로 다른 입력이 우연히 같은 해시값을 갖는 사건입니다. 여기서는 입력 자체가 완전히 같아지므로 해시 함수를 아무리 강한 것으로 바꿔도 같은 값이 나옵니다. 해시 품질이 아니라 무엇을 해시에 넣느냐의 문제입니다.

접두사 매칭은 그대로지만 블록마다 부모를 거슬러 대조해야 해서 조회 비용이 제곱이 됩니다.

부모 포인터를 따로 두고 매번 거슬러 올라가는 설계도 가능하지만, 그것은 vLLM이 고른 길이 아닙니다. 부모 해시를 키 안에 접어 넣었기 때문에 맵 조회 한 번이 그 블록까지의 접두사 전체를 보증합니다. 이 문항의 가정은 조회 비용이 아니라 판정의 정확성을 무너뜨립니다.

요청이 몰리면 radix tree가 가득 차 evict가 잦아져 매치할 노드가 남지 않기 때문입니다.

트리가 좁아지면 히트가 줄어드는 것은 맞지만, 로그의 KV 사용률은 두 구간이 0.31에서 0.35로 비슷해 캐시가 포화되지 않았습니다. 이 시나리오에서 설명해야 하는 것은 캐시 인지 정렬을 켜둔 값이 왜 무력해졌는가입니다. 정렬이 계속 돌고 있다면 같은 접두사끼리 묶어 evict 압력 자체를 줄여줍니다.

lpm은 radix cache가 켜져 있어야 동작하는데 부하가 높으면 자동으로 꺼지기 때문입니다.

전제의 앞 절은 맞습니다. radix cache를 끄면 캐시 인지 정책은 FCFS로 강등됩니다. 하지만 radix cache는 기본으로 켜져 있고 부하에 따라 스스로 꺼지지 않습니다. 부하에 반응하는 것은 캐시가 아니라 정렬 쪽입니다.

큐가 길어지면 정렬이 도착 순서를 심하게 흐트러뜨려, 공정성 보호가 정렬을 막기 때문입니다.

정렬이 도착 순서를 흐트러뜨려 접두사가 겹치지 않는 요청을 뒤로 미는 것은 실제 부작용입니다. 다만 런타임에 정책을 되돌리는 스위치는 공정성 지표가 아니라 대기 큐 길이입니다. 공정성은 이 정책을 쓸지 말지 판단할 때 볼 사항이지 엔진이 감시하는 값이 아닙니다.

시스템 프롬프트 쪽입니다. 가장 먼저 만들어져 목록에 오래 머문 블록입니다.

기준은 만들어진 시각이 아니라 마지막으로 쓰인 시각입니다. 게다가 반납 순서를 뒤에서 앞으로 잡아둔 덕분에 앞쪽 블록이 목록의 뒤로 밀려 오히려 늦게 재활용됩니다. 공유될 가능성이 큰 블록을 오래 남기려고 일부러 그 방향으로 설계했습니다.

반납하는 순간 120개 블록의 내용이 함께 지워집니다. 빈 블록은 캐시가 아닙니다.

반납된 블록은 빈 목록에 들어가지만 안에 든 KV와 어떤 토큰들의 것인지 알려주는 꼬리표는 그대로 남습니다. 다음 요청이 같은 접두사로 시작하면 계산을 건너뛰고 그 블록을 다시 가리키기만 하면 됩니다. prefix caching이 캐시 전용 메모리를 따로 떼지 않고도 성립하는 이유입니다.

정해진 순서가 없습니다. 빈 목록에서 아무 블록이나 하나 꺼내 씁니다.

임의로 꺼내면 어떤 블록이 살아남을지 통제할 수 없어, 모두가 쓰는 시스템 프롬프트가 한 번 쓰이고 사라지는 일이 생깁니다. vLLM은 빈 목록을 이중 연결 리스트로 관리해 머리에서 꺼내고, 히트가 난 블록은 목록 중간에서 즉시 빼냅니다.

radix tree는 노드를 임의 지점에서 쪼갤 수 있어 페이지 크기에 매이지 않습니다. SGLang은 2,010토큰까지 가고 vLLM만 2,000토큰에서 끊깁니다.

노드 분할이 자유로운 것은 페이지 크기가 1일 때의 이야기입니다. 16으로 띄우면 SGLang은 매칭을 시작하기도 전에 키를 페이지 경계까지 잘라내고 매치 길이도 페이지 크기의 배수로 내려 보고합니다. 2,010은 이 정렬이 없을 때, 즉 기본값 1로 띄웠을 때 나오는 값입니다.

두 엔진 모두 경계에 걸친 페이지를 통째로 버리고 그 앞까지 물러납니다. 완전한 페이지 124개에 해당하는 1,984토큰에서 함께 끊깁니다.

버려지는 것은 페이지를 채우지 못한 나머지 10토큰뿐입니다. 125번째 페이지는 2,000토큰째에서 이미 가득 찼으므로 정상적으로 해시가 매겨지고 그대로 히트합니다. 1,984는 가득 찬 마지막 페이지까지 함께 버렸다고 본 값이고, 어느 엔진도 그렇게 동작하지 않습니다.

SGLang은 페이지 크기가 1을 넘으면 radix tree를 접고 블록 해시맵으로 갈아탑니다. 자료구조가 같아져 2,000토큰에서 함께 끊깁니다.

끊기는 지점은 맞지만 이유가 사실이 아닙니다. 페이지 크기는 트리에 넣고 빼는 키의 정렬 단위를 바꿀 뿐이고, SGLang은 어떤 값에서도 radix tree를 그대로 씁니다. 자료구조는 여전히 트리와 해시맵으로 다른데 결과만 같아진다는 것이 이 상황의 요점입니다.

됩니다. 저장 형식이 4비트이므로 커널도 4비트 경로를 그대로 씁니다.

저장 형식과 연산 형식은 별개입니다. W4A16 커널은 행렬곱 직전에 가중치를 16비트로 복원하므로, 텐서코어에 들어가는 두 피연산자는 모두 16비트입니다.

됩니다. H100은 FP8 텐서코어를 갖추고 있어 4비트 가중치를 FP8로 승격해 받습니다.

FP8 경로도 두 피연산자가 모두 FP8일 때 열립니다. 가중치를 FP8로 올려도 활성값이 16비트로 남으면 조건을 채우지 못하고, W4A16 커널은 애초에 가중치를 16비트로 복원합니다. 참고로 Hopper 텐서코어에는 INT4 경로 자체가 없습니다. Turing과 Ampere, Ada에는 있지만 Hopper에서 빠졌습니다.

안 됩니다. AWQ가 중요 채널을 16비트로 남겨두어 커널이 혼합 정밀도로 돌기 때문입니다.

AWQ는 중요 채널을 16비트로 남기는 대신 그 채널의 가중치를 미리 키우고 활성값을 줄이는 스케일링으로 같은 보호 효과를 냅니다. 혼합 정밀도가 하드웨어에서 비효율적이라 그 길을 고른 것이고, 커널이 받는 가중치는 균일한 4비트입니다. 경로가 막히는 이유는 혼합 정밀도가 아니라 활성값이 16비트라는 데 있습니다.

어텐션도 배치와 함께 compute-bound로 바뀌어 복원 경로가 어텐션까지 늦췄습니다.

어텐션은 요청마다 자기 몫의 KV Cache를 따로 읽어야 해서 배치가 커져도 memory-bound로 남습니다. 게다가 W4A16이 양자화한 대상은 가중치이고 어텐션은 KV를 읽는 연산이라, 가중치 복원 경로와 어텐션은 서로 다른 자리에 있습니다.

4비트에 붙는 그룹 스케일 오버헤드 때문에 실제 압축률이 4배에 못 미쳤습니다.

그룹 스케일 때문에 실효 압축이 4배가 아니라 3.5배 남짓인 것은 맞지만, 그 손실은 배치와 무관하게 항상 같은 크기입니다. concurrency 1에서 두 배가 나왔다는 것 자체가 읽기 이점이 살아 있었다는 증거이므로, 배치에 따라 달라지는 다른 요인을 찾아야 합니다.

KV 예산이 모자라 요청이 선점되고 재계산이 반복됐습니다.

가중치가 가장 작은 W4A16이 세 방식 중 KV 예산이 가장 큽니다. 선점이 원인이었다면 가중치가 가장 무거운 bf16 쪽이 먼저 무너졌어야 합니다.

사전 양자화 체크포인트인데 --quantization fp8을 주지 않아 양자화가 적용되지 않았습니다.

체크포인트 설정에 양자화 방식이 적혀 있어 vLLM이 별도 플래그 없이 인식합니다. 로그의 감지 줄과 가중치 메모리가 절반으로 줄어든 사실이 양자화가 실제로 적용됐다는 증거입니다.

prefill이 아직 memory-bound 구간이라 연산 정밀도가 처리량에 닿지 않습니다.

prefill은 수천 토큰을 한 번에 미는 단계라 배치 1에서도 compute-bound입니다. FP8 연산이 실제로 돌았다면 prefill 처리량에서 가장 먼저 차이가 났어야 합니다. 이 장비에서는 배치를 더 키워도 FP8 연산 경로가 열리지 않으므로 격차 자체가 생기지 않습니다.

--kv-cache-dtype fp8을 함께 주지 않아 어텐션이 여전히 16비트로 돌고 있습니다.

KV Cache 양자화는 가중치 양자화와 별개 자원이고, 켜더라도 1차 효과는 KV 예산이지 가중치 행렬곱의 처리량이 아닙니다. 로그에서 KV 예산이 이미 크게 늘어난 것은 가중치가 줄어 남은 메모리가 KV로 갔기 때문입니다.

예산만 늘었을 뿐 스텝마다 읽는 KV 바이트는 그대로입니다. 블록당 토큰 수가 16개로 고정이기 때문입니다.

PagedAttention 블록의 크기를 정하는 것은 토큰 수가 아니라 토큰당 바이트입니다. 같은 16토큰 블록이 절반 크기가 되므로 스텝당 읽는 KV 바이트도 실제로 절반이 됩니다. 그대로인 것은 읽는 양이 아니라 그 절감이 지연에 드러날 조건입니다.

스케일 calibration을 하지 않아 기본값 1.0이 쓰였고 그래서 속도 이득이 상쇄됐습니다.

스케일은 품질에 걸리는 값입니다. 기본 스케일 1.0은 분포가 큰 모델에서 outlier가 잘려 정확도를 떨어뜨릴 수 있지만, 속도를 되돌려놓지는 않습니다.

KV 예산이 늘어난 만큼 배치가 자동으로 커져서 요청당 지연이 상쇄됐습니다.

늘어난 것은 태울 수 있는 요청 수의 상한이지 실제로 태워진 요청 수가 아닙니다. 같은 부하에서 전후를 잰 수치라 배치는 그대로이고, 예산 상한 자체는 지연에 직접 관여하지 않습니다.

활성 파라미터가 4B뿐이라 실질 크기가 작고, 작은 모델일수록 4비트를 못 견딥니다.

모델이 작을수록 양자화에 민감한 경향은 있지만 여기서 기준이 되는 것은 활성 파라미터 수가 아닙니다. 문제는 양자화가 실제로 적용되는 단위, 즉 개별 expert 행렬의 크기에 있습니다.

top-k 라우터의 로짓이 4비트로 뭉개져 expert 선택이 흔들리기 때문입니다.

라우터는 파라미터 비중이 극히 작아 보통 높은 정밀도로 남겨두는 부분이라 4비트로 내릴 대상이 아닙니다. 손실이 생기는 곳은 라우터가 아니라 expert의 FFN 행렬입니다.

MoE는 QAT 추가 학습에서 수렴이 느려 같은 스텝 수로 4비트를 회복하지 못합니다.

학습 예산을 늘려 해결되는 문제였다면 4비트가 통째로 빠지는 대신 더 오래 학습한 버전이 나왔을 것입니다. 4비트가 제외되고 8비트가 권장된 것은 학습 난이도가 아니라 형식 자체의 한계를 가리킵니다.

GPTQ는 활성값 통계로 중요 채널을 골라 스케일로 보호하고, AWQ는 Hessian으로 나머지 가중치를 갱신합니다.

두 방식의 역할이 뒤바뀐 서술입니다. 활성값 통계로 중요 채널을 골라 스케일링으로 보호하는 쪽이 AWQ이고, Hessian으로 아직 양자화하지 않은 가중치를 갱신하는 쪽이 GPTQ입니다. AWQ에는 오차를 되돌리는 재구성 과정 자체가 없어서 Hessian을 계산할 일이 없습니다.

GPTQ는 가중치 크기 상위 1%를, AWQ는 활성값 크기 상위 1%를 각각 16비트로 남겨둡니다.

AWQ 논문이 실험으로 확인한 사실이지만 채택한 방법은 아닙니다. 큰 활성값과 만나는 1% 채널을 16비트로 남기면 품질이 크게 회복되는데, 혼합 정밀도는 시스템 구현을 어렵게 만들어서 그 채널의 가중치를 미리 키우고 활성값을 같은 배수로 줄이는 스케일링으로 대체했습니다. GPTQ에는 가중치 크기로 채널을 고르는 단계 자체가 없습니다.

GPTQ는 calibration 데이터 없이 반올림 경계만 조정하고, AWQ는 양자화를 시뮬레이션하는 추가 학습으로 스케일을 배웁니다.

GPTQ는 calibration 데이터를 흘려 각 레이어의 입력 통계를 모으는 데서 출발합니다. 그 통계가 없으면 갱신량을 정할 Hessian이 나오지 않습니다. AWQ도 학습을 하지 않습니다. 활성값 통계를 미리 모아 스케일을 정할 뿐이고, 학습 과정에 양자화를 끼워 넣는 것은 PTQ가 아니라 QAT입니다.

이 플래그는 가중치만 8비트로 두는 옵션이라 활성값이 16비트로 남습니다. 피연산자가 어긋나 FP8 행렬곱 경로가 열리지 않았습니다.

온라인 양자화는 활성값까지 8비트로 내리는 W8A8입니다. 활성값 스케일을 매 스텝 동적으로 잡을 뿐 16비트로 남겨두지 않으므로, FP8 텐서코어가 있는 H100에서는 FP8 행렬곱이 실제로 돌아갑니다. 가중치만 8비트로 남고 연산이 16비트가 되는 것은 FP8 텐서코어가 없는 Ampere에서 폴백할 때의 이야기입니다.

온라인 양자화는 가중치 스케일까지 매 스텝 다시 계산합니다. 그 비용이 FP8 행렬곱으로 번 시간을 대부분 되돌려놓았습니다.

가중치는 서버가 뜰 때 한 번 양자화되고 스케일도 그때 정해져 그대로 고정됩니다. 매 스텝 다시 계산되는 것은 활성값 스케일뿐입니다. 30B 가중치를 스텝마다 다시 훑는다면 1.08배가 아니라 bf16보다 크게 느려졌을 것입니다.

온라인 양자화의 FP8 커널은 prefill 구간에만 적용됩니다. 출력 토큰을 뽑는 decode가 16비트로 돌아 처리량이 거의 그대로입니다.

8비트로 내린 Linear 레이어는 prefill과 decode를 가리지 않고 같은 커널로 돌아갑니다. 단계에 따라 연산 정밀도가 갈리는 경로는 vLLM에 없습니다. decode가 16비트로 돌았다면 TPOT이 bf16과 같아야 하는데 로그에서는 21.5ms에서 19.9ms로 줄었습니다.

draft가 과하게 뽑아온 토큰의 확률을 낮춰 품질 저하를 무시할 만한 수준으로 억제합니다.

억제가 아니라 복원입니다. 깎아낸 확률이 거절 시 재샘플링 분포로 정확히 돌아가기 때문에 오차가 조금 남는 것이 아니라 0입니다. 근사와 정확의 차이를 정도의 차이로 읽으면 이 기법을 품질과 속도의 교환으로 오해하게 됩니다.

수락률이 충분히 높을 때에만 target 단독 출력과 같은 분포를 얻을 수 있습니다.

수락률은 속도에만 관여합니다. 수락률이 0.9든 0.1이든 최종 분포는 똑같이 target과 일치하고, 낮은 수락률이 깎는 것은 iteration당 확정 토큰 수뿐입니다. 수락률이 아주 낮으면 draft 비용만 얹혀 느려지지만 그때도 출력의 품질은 변하지 않습니다.

같은 프롬프트에 대해 speculative decoding을 끈 서버와 항상 같은 문장이 나옵니다.

분포가 같다는 것과 문장이 같다는 것은 다릅니다. temperature가 0보다 크면 sampling의 무작위성 때문에 문장은 당연히 달라지고, 이것은 speculative decoding과 무관하게 원래 그렇습니다. greedy에서도 부동소수점 연산 순서 차이로 아주 드물게 갈릴 수 있어서 vLLM 문서는 하드웨어 수치 정밀도 한계 안에서의 무손실이라고 적어둡니다.

100%입니다. 두 확률의 비가 0.5 나누기 0.2로 1을 넘으므로 그대로 통과시킵니다.

무조건 수락하는 것은 p가 q 이상일 때입니다. 여기서는 draft가 target보다 이 토큰을 2.5배 자주 뽑아오므로 그대로 통과시키면 draft의 취향이 출력에 그대로 남습니다. 비율을 q/p로 뒤집어 계산하면 2.5가 나와 1로 잘리는데, 분자와 분모를 바꿔 쓴 경우입니다.

20%입니다. target이 그 토큰에 준 확률이 곧 통과 비율입니다.

p 자체를 통과율로 쓰면 최종 빈도가 0.5 × 0.2 = 0.1이 되어 target이 원한 0.2의 절반으로 떨어집니다. 깎는 방향은 맞지만 과하게 깎는 것입니다. 통과율은 target의 확률이 아니라 target과 draft 확률의 비입니다.

60%입니다. 두 확률의 비를 1에서 뺀 값이 통과 비율입니다.

1 - p/q = 0.6은 수락이 아니라 거절 확률입니다. 이 값을 통과율로 쓰면 최종 빈도가 0.5 × 0.6 = 0.3이 되어 target의 0.2보다 오히려 높아집니다. draft가 과하게 뽑아오는 토큰을 더 통과시키는 셈이라 규칙의 목적과 정반대입니다.

약 1.5토큰입니다. draft 3개 중 평균적으로 수락되는 개수입니다.

수락 확률과 draft 수를 곱한 값인데 두 가지가 빠졌습니다. 하나는 거절이 나도 target이 그 자리에서 토큰 하나를 다시 뽑아 주므로 최소 1토큰은 확정된다는 점이고, 다른 하나는 앞에서 거절이 나면 뒤쪽 draft가 버려지므로 수락된 개수가 3번의 시도 합이 아니라 앞에서부터 이어진 연속 성공 횟수라는 점입니다.

2토큰입니다. 수락 확률 0.5에서 이 기법이 낼 수 있는 천장값입니다.

1 나누기 (1 빼기 0.5)로 얻는 2는 draft 토큰 수를 무한히 늘렸을 때의 극한입니다. draft 수가 유한하면 그 값에서 수락 확률의 거듭제곱 항이 빠지므로 천장보다 작아지고, 3개일 때는 약 1.875로 천장의 94% 지점입니다. 천장이 2라는 사실 자체가 draft를 길게 잡는 이득에 한계가 있다는 뜻입니다.

약 2.5토큰입니다. 평균 수락 개수에 target이 뽑는 1개를 더한 값입니다.

1을 더하는 구조는 맞지만 평균 수락 개수가 1.5가 아닙니다. 앞에서 거절이 나면 뒤는 통째로 버려지므로 수락은 앞에서부터 연속으로만 쌓입니다. 실제 평균 수락 개수는 0.5 + 0.25 + 0.125로 약 0.875이고 여기에 1을 더하면 약 1.9가 됩니다.

피크 시간대에 유입되는 프롬프트의 도메인과 temperature가 달라져 draft의 예측이 어긋나고, 버려지는 draft 연산이 늘어난 것입니다.

수락률이 세 부하 모두 0.74로 같으므로 draft의 적중은 변하지 않았습니다. 문제는 draft가 얼마나 맞히느냐가 아니라 맞힌 것을 검증할 여유 연산이 남아 있느냐입니다. 같은 수락률에서 결과가 뒤집혔다는 사실 자체가 원인이 draft 쪽이 아니라는 증거입니다.

KV Cache가 부족해져 요청 선점과 재계산이 발생했고 그 비용이 지연으로 나타난 것입니다.

높은 부하에서 선점이 늘어날 수는 있지만 그것은 speculative decoding을 껐을 때도 똑같이 일어납니다. 여기서 설명해야 하는 것은 같은 부하에서 켠 쪽만 더 느려진 차이입니다. draft 토큰이 KV 블록을 조금 더 쓰는 것만으로 1.6배의 역전이 만들어지지는 않습니다.

draft 모델이 GPU 메모리를 점유해 target이 쓸 수 있는 배치 크기가 줄어든 것입니다.

draft 가중치가 KV Cache 예산을 조금 깎는 것은 맞지만, 지문의 세 부하 모두 KV 사용률이 60% 미만이고 선점이 0건이라 배치 크기를 제약하지 않았습니다. 여기서 뒤집힌 것은 담을 수 있는 요청 수가 아니라 검증에 쓸 연산 여유입니다. EAGLE 계열처럼 decoder layer 하나 남짓인 모듈은 점유량 자체도 작습니다.

프롬프트가 길수록 draft가 참고할 문맥이 많아져 수락률이 오르고 그만큼 이득이 커집니다.

수락률이 워크로드를 타는 것은 맞지만 그것으로는 배치를 키웠을 때의 차이를 설명하지 못합니다. 수락률이 아무리 높아도 GPU가 연산으로 포화되면 버려지는 draft 계산이 순손실이 되어 이득은 사라집니다. B가 버티는 이유는 포화 지점이 뒤로 밀린 것이지 draft가 더 잘 맞혀서가 아닙니다.

긴 프롬프트는 prefill이 오래 걸려 전체 지연에서 decode 비중이 작아지고 손해가 가려집니다.

prefill이 길면 TTFT가 커지는 것은 맞지만 speculative decoding이 손대는 구간은 decode입니다. 손해가 가려진 것뿐이라면 decode 구간만 따로 재는 순간 드러나야 하는데, 실제로는 그 구간 자체가 여전히 빨라집니다. 평균에 묻힌 것이 아니라 이득이 실재하는 상황입니다.

긴 컨텍스트에서는 KV Cache 때문에 배치에 실제로 담기는 요청 수가 줄어 사실상 낮은 부하가 됩니다.

지문에서 실행 배치가 64로 유지되고 선점이 0건임을 확인했으므로 배치가 덜 찬 상태가 아닙니다. 이 설명은 큰 배치에서 이득이 남았다는 관찰이 아니라 큰 배치가 애초에 만들어지지 않았다는 주장이라 관찰과 어긋납니다. 배치를 실제로 채운 상태에서도 이득이 남는 이유는 병목의 종류가 바뀌었기 때문입니다.

사내 0.6B 모델을 draft로 붙입니다. 별도 draft 모델은 target의 hidden state를 이어받아 다음 토큰을 그리므로 문자열 매칭보다 수락률이 구조적으로 높습니다.

vocabulary가 같으니 붙이는 것 자체는 가능하지만 근거로 든 사실이 틀렸습니다. target의 hidden state를 입력으로 받는 것은 EAGLE 계열의 speculator이고, 별도 draft 모델은 target과 무관하게 자기 가중치로만 예측합니다. 그래서 vLLM 실측에서도 낮은 부하 기준 draft 모델 방식은 최대 1.5배에 그쳐 요약 데이터셋에서 최대 2.8배를 낸 n-gram에 밀렸습니다.

EAGLE-3을 켭니다. speculator는 target 가중치에서 hidden state를 받아 그 자리에서 만들어지므로, 체크포인트 없이 method만 지정하면 켜집니다.

hidden state를 이어받는다는 설명은 맞지만 그것이 체크포인트를 면제해주지는 않습니다. EAGLE의 speculator는 따로 학습된 모듈이라 `--speculative-config`의 `model`에 그 체크포인트를 지정해야 켜집니다. 지문의 target은 파인튜닝 모델이라 공개 speculator가 없고 학습 일정도 없으므로 이번에는 고를 수 없습니다.

MTP를 켭니다. `"method": "mtp"`는 모델에 내장된 예측 모듈을 쓰는 설정이라 어떤 모델에서든 추가 준비 없이 동작합니다.

MTP는 모델 제작자가 함께 학습해 배포한 모듈이 있어야 성립합니다. DeepSeek처럼 체크포인트에 내장했거나 Gemma 4처럼 별도로 배포한 경우에만 쓸 수 있는데, 지문의 베이스 모델 제작자는 그 모듈을 배포하지 않았습니다. 준비물이 없다는 말은 쓸 수 있는 모델에서 따로 챙길 것이 없다는 뜻이지 아무 모델에나 켤 수 있다는 뜻이 아닙니다.

prefill을 청크로 잘라 넣는 스케줄링이 함께 꺼져 첫 토큰 지연이 커집니다.

chunked prefill은 스케줄러가 토큰 예산을 어떻게 채울지에 대한 결정이고, 이 플래그는 정해진 배치를 실행할 때 커널을 그래프로 재생할지만 정합니다. 서로 다른 층에 있는 인자라 한쪽을 끈다고 다른 쪽이 따라 꺼지지 않습니다.

KV Cache 풀이 그래프가 쓰던 몫만큼 줄어 동시 처리 가능한 요청 수가 떨어집니다.

방향이 반대입니다. 그래프를 캡처하지 않으면 시작 시 그 몫을 예산에서 미리 뺄 필요가 없어 KV 풀은 오히려 커집니다. 메모리가 정말 빠듯할 때 이 플래그가 최후 수단이 되는 이유가 그것입니다.

PagedAttention 대신 연속 할당 방식 attention이 쓰여 KV 메모리 단편화가 생깁니다.

PagedAttention은 KV를 블록 단위로 할당하고 참조하는 설계라 실행 모드와 무관하게 항상 동작합니다. eager로 돌아도 블록 할당과 공유는 그대로입니다.

0.15로 잡습니다.

이 값이면 11.87 GiB만 요구해 시작은 하지만 상한은 아닙니다. 남은 23.74 GiB를 절반만 쓰는 셈이라 쓸 수 있었던 KV 풀을 그만큼 버립니다. 상한을 묻는 문항이므로 뜨는 값 중 가장 큰 것을 골라야 합니다.

0.45로 잡습니다.

한 GPU에 둘을 올릴 때 절반씩 나눠 주는 관행에서 나온 값이지만, 여기서는 첫 인스턴스가 이미 0.7을 쓰고 있어 대칭이 깨졌습니다. 0.45는 35.62 GiB를 요구해 남은 23.74 GiB를 넘으므로 같은 에러가 다시 납니다.

0.62로 잡습니다.

부족분을 상한으로 착각한 값입니다. 요구량 72.82와 여유 23.74의 차이 49.08 GiB가 전체의 0.62인데, 그것은 기본값에서 내려야 할 폭이지 상한 자체가 아닙니다. 0.92에서 0.62를 빼면 상한 0.30 근처가 나옵니다.

세 줄이 모두 두 배가 됩니다. KV 풀도 요청 하나가 감당하는 몫도 함께 늘어납니다.

KV 풀 크기는 예산에서 가중치와 활성값 피크, 그래프 몫을 뺀 나머지로 정해지고 그 계산에 max_model_len은 들어가지 않습니다. 앞의 두 줄은 애초에 이 인자를 보지 않습니다.

첫 줄은 그대로이고 둘째 줄과 셋째 줄이 각각 두 배가 됩니다.

둘째 줄은 최대 동시성에 max_model_len을 곱해 토큰으로 되돌린 값입니다. 기준 길이가 절반이 되면 동시성이 두 배가 되고 곱하는 길이가 절반이 되어 둘이 정확히 상쇄되므로, 담을 수 있는 토큰 총량은 그대로입니다.

앞의 두 줄은 그대로이고 셋째 줄만 3.25x로 절반이 됩니다.

방향이 반대입니다. 최대 동시성은 풀의 블록 수를 요청 하나가 쓰는 블록 수로 나눈 값이라 기준 길이는 분모에 있습니다. 분모가 절반이 되면 몫은 두 배가 됩니다. 절반이 되려면 max_model_len을 두 배로 올려야 합니다.

KV head 4개가 8로 나누어떨어지지 않아 시작할 때 divisibility 에러가 납니다.

시작 시 나누어떨어지는지 검사하는 대상은 attention head 수입니다. 64는 8로 나누어떨어지므로 이 검사는 통과하고, KV head는 검사 대상이 아니라 복제로 처리됩니다.

GPU당 KV head가 절반이 되어 토큰당 KV 크기가 줄고 풀 용량이 두 배가 됩니다.

TP를 올릴 때 흔히 기대하는 그림이지만 KV head 수가 TP보다 적어지는 순간부터 성립하지 않습니다. 장당 1개에서 더 내려갈 자리가 없어 토큰당 KV 크기는 고정되고, 늘어나는 것은 가중치가 더 쪼개져 생긴 여유뿐입니다.

KV Cache는 TP로 분할되지 않으므로 GPU마다 전체 KV를 그대로 들고 있습니다.

KV Cache는 KV head 단위로 함께 분할됩니다. head 수가 넉넉한 모델이라면 TP를 올린 만큼 GPU당 KV가 정확히 줄어들고, 문제가 되는 것은 나눌 head가 모자란 경우뿐입니다.

컴파일이 API 서버 프로세스에서 일어나 토큰화와 CPU를 다투고, 진행 중인 응답의 스트리밍이 끊깁니다.

컴파일은 API 서버가 아니라 EngineCore 쪽 스레드 풀에서 돕니다. V1이 API 서버로 밀어낸 CPU 작업은 토큰화와 스트리밍이고, 스키마를 상태 기계로 바꾸는 일은 스케줄러가 문법을 필요로 하는 쪽에서 시작됩니다. 다른 요청의 스트리밍은 영향을 받지 않습니다.

컴파일된 문법이 GPU 메모리에 쌓여 KV 풀을 잠식하고 동시성이 점점 떨어집니다.

문법 상태 기계와 그 캐시는 CPU 쪽에 있습니다. 캐시에는 크기 상한이 있어 넘치면 오래된 항목이 밀려날 뿐이고, KV 풀은 시작할 때 확정된 크기를 그대로 유지합니다.

스케줄러 루프가 컴파일이 끝날 때까지 멈춰 배치 전체의 첫 토큰이 함께 밀립니다.

스케줄러 루프를 붙잡는 구조였다면 무거운 스키마 하나가 서버 전체를 세울 수 있어 프로덕션에 쓸 수 없습니다. 컴파일을 루프 밖으로 빼고 해당 요청만 대기시키는 것이 이 설계의 요점입니다.

메모리 용량 하나로 갈립니다. 70GiB를 넘으면 큰 값, 못 넘으면 작은 값을 씁니다.

이 규칙이면 79.15 GiB인 node-a도 큰 값을 받아야 하는데 2048과 256으로 떴습니다. node-b와의 용량 차이는 0.5 GiB뿐이라 임계선으로 둘을 가를 수도 없습니다. 용량은 두 조건 중 하나일 뿐입니다.

NVIDIA Hopper 이상 세대면 큰 값을 쓰고, 그보다 앞선 세대면 작은 값을 씁니다.

node-d는 Hopper도 NVIDIA도 아닌데 8192와 1024를 받았습니다. 분기는 아키텍처 세대나 compute capability를 조회하지 않고, 보고된 메모리 용량과 장치 이름 문자열 두 가지만 봅니다.

장치 이름만 봅니다. 이름에 a100이 들어가면 작은 값, 아니면 큰 값을 씁니다.

node-c의 이름에는 a100이 없는데도 2048과 256을 받았습니다. 이름은 큰 값으로 가기 위한 두 조건 중 하나이고, 44.99 GiB인 node-c는 그 앞의 용량 조건에서 먼저 걸립니다.

대역폭 천장입니다. 스텝마다 읽는 가중치와 KV가 늘어 토큰 간격이 길어졌습니다.

간격이 길어지기는 했지만 폭이 맞지 않습니다. Mean ITL은 29.7ms에서 33.0ms로 11% 올랐을 뿐이고, Mean TPOT도 33.1ms로 SLO 60ms에는 한참 못 미칩니다. 대역폭이 병목이면 악화가 TTFT가 아니라 토큰 간격에 먼저 크게 나타나야 합니다.

배치 상한입니다. max_num_seqs 256에 걸려 더 이상 요청을 못 태우고 있습니다.

Running이 62에서 멈췄는데 이는 상한 256의 4분의 1도 되지 않습니다. 배치 상한이 원인이라면 Running이 256에서 평평해져야 하고 Preemptions도 생기지 않습니다. 지금 배치 크기를 정하는 것은 인자가 아니라 KV 풀입니다.

연산 천장입니다. GPU 연산이 포화해 처리량이 더 오르지 않습니다.

연산이 포화하면 스텝 자체가 길어져 ITL과 TPOT이 크게 나빠지고, KV 공간과는 무관하므로 Preemptions는 0으로 남습니다. 여기서는 반대로 간격은 거의 그대로인 채 대기열과 선점만 늘었습니다.

`max_num_batched_tokens`를 8192 이상으로 올려 prefill 처리량을 키웁니다.

TTFT가 나쁜 것은 맞지만 원인이 prefill 속도가 아니라 큐 대기입니다. 자리가 없어 못 들어간 요청은 prefill을 아무리 빨리 돌려도 순서가 오지 않습니다. 오히려 스텝당 prefill 조각이 커져 진행 중인 요청의 토큰 간격만 나빠지고 KV 공간은 한 바이트도 늘지 않습니다.

`max_num_seqs`를 256에서 512로 올려 더 많은 요청을 동시에 태웁니다.

배치 상한에는 애초에 걸려 있지 않았습니다. Running이 62에서 멈춘 것은 KV가 없어서이지 256이라는 숫자 때문이 아닙니다. 상한만 키우면 스케줄러가 공간이 없는데도 요청을 더 올리려 해 선점 횟수가 늘어납니다.

`max_model_len`을 4608로 낮춰 요청당 KV 사용량을 줄입니다.

max_model_len은 요청 하나가 쓸 수 있는 길이의 상한을 막는 인자이고 풀 크기를 바꾸지 않습니다. 이 워크로드는 이미 4096과 512를 합쳐 4608을 쓰고 있으므로 상한을 4608로 내려도 실제 사용량은 한 토큰도 줄지 않습니다. 상한 근처까지 쓰는 긴 요청이 섞여 있을 때만 효과가 있습니다.

P99 TTFT가 1.9초로 높아, 첫 응답이 늦은 것을 사용자가 끊김으로 느낀 것입니다.

TTFT는 요청을 보낸 뒤 첫 토큰이 도착할 때까지의 시간이라 생성이 시작된 다음의 멈칫과는 다른 구간입니다. 첫 반응이 느린 것과 나오다가 멈추는 것은 사용자도 구분해서 말하는 별개의 증상입니다.

Peak output token throughput이 평균보다 12% 높아, 서버가 주기적으로 스로틀링됐습니다.

peak는 벤치 구간 중 가장 좋았던 순간의 값이라 평균보다 높은 것이 정상이고, 오히려 두 값이 같으면 측정이 이상한 것입니다. 이 지표는 서버 전체의 토큰 총량이라 개별 요청의 간격에 대해 아무것도 말해주지 않습니다.

Median TPOT과 Mean TPOT이 거의 같아 분포가 정상이므로, 원인은 서버가 아니라 클라이언트입니다.

두 값이 가깝다는 것은 요청들끼리 비교했을 때 평균이 고르다는 뜻일 뿐입니다. 한 요청 안에서 간격이 어떻게 흔들렸는지는 요청 단위로 평균을 낸 뒤라 이 지표가 아예 볼 수 없고, 그것을 보려고 따로 두는 지표가 ITL입니다.

약 4개입니다.

어텐션 head 32개로 계산하면 나오는 값입니다. GQA에서 KV Cache는 Query head가 아니라 KV head 수만큼만 저장하므로 32가 아니라 4를 곱해야 합니다. 이 모델은 Query head 8개가 KV head 하나를 공유하고, 그 여덟 배가 여기서 갈립니다.

약 16개입니다.

컨텍스트 8,192를 입력과 출력 양쪽에 각각 잡아 요청당 16,384토큰으로 본 결과입니다. 지문의 8,192는 요청 하나가 쓰는 컨텍스트 전체이고, 블록 단위 할당은 외부 단편화를 없애고 내부 낭비를 블록 하나 미만으로 묶으므로 여기서 절반이 사라질 자리도 없습니다.

약 64개입니다.

K와 V 중 한쪽만 세어 식 맨 앞의 2를 빠뜨리면 나오는 값입니다. 어텐션은 이전 토큰들의 Key와 Value를 둘 다 보관해야 하므로 토큰당 크기는 두 배가 됩니다. 참고로 KV를 FP8로 저장했다면 토큰당 48KiB로 줄어 실제로 이 숫자가 됩니다.

DP 복제본마다 KV 풀 크기가 달라 카드별 배치가 벌어진 것입니다. `--data-parallel-size`를 낮춰야 합니다.

DP 랭크들은 같은 크기의 KV 풀을 잡고, 스케줄러도 대기 요청 수를 보고 랭크를 고르므로 배치가 이렇게 갈리지 않습니다. 무엇보다 노는 카드가 계속 바뀐다는 것은 요청 배분이 아니라 스텝 단위로 달라지는 무언가를 가리킵니다.

all-to-all 통신이 병목이라 카드들이 서로를 기다리는 것입니다. `--tensor-parallel-size`를 8로 올려 통신을 없앱니다.

EP 크기는 TP 크기와 DP 크기의 곱이라 TP를 8로 바꿔도 8장 노드에서는 EP가 그대로 8이고 all-to-all도 그대로 남습니다. 거기에 TP의 all-reduce가 스텝마다 더해지니 통신은 줄기는커녕 늡니다.

expert마다 가중치 크기가 달라 카드별 읽기 시간이 벌어진 것입니다. EP를 끄고 TP만 쓰는 편이 낫습니다.

한 모델 안의 expert는 모두 같은 모양이라 랭크가 들고 있는 가중치의 바이트 수는 같습니다. 불균형은 가중치 크기가 아니라 그 expert로 흘러가는 토큰 수에서 생깁니다. TP는 expert 하나하나를 잘게 쪼개므로 연산 효율이 EP보다 떨어집니다.

상한은 초당 약 31토큰입니다. TP는 가중치를 나눠 들 뿐 대역폭을 합쳐주지는 않으므로 요구를 받을 수 없습니다.

카드 한 장의 2,039GB/s를 전체 가중치 65.6GB로 나눈 값입니다. TP=4에서는 카드마다 가중치를 4분의 1씩 나눠 들고 동시에 읽으므로 대역폭도 4장을 합산해서 칩니다. 게다가 이 서버는 동시성 1에서 이미 초당 68.5토큰을 내고 있어, 상한이 31토큰이라면 측정치가 상한의 두 배라는 모순이 됩니다.

상한은 초당 약 249토큰이라 여유가 있고, `max_num_seqs`를 낮춰 배치를 줄이면 요구를 받을 수 있습니다.

파라미터 수 32.8로 그대로 나눠 BF16의 2byte를 빠뜨린 값입니다. 8,156 ÷ 32.8 = 249는 FP8로 양자화했을 때의 상한이고 지금은 스텝마다 65.6GB를 읽습니다. 배치를 줄이면 스텝당 KV 읽기가 줄어 TPOT이 동시성 1의 14.60ms까지 돌아가지만, 그 값이 곧 초당 68.5토큰이라 130토큰에는 닿지 못합니다.

상한은 초당 약 497토큰이라 여유가 있고, `max_num_batched_tokens`를 낮추면 요구를 받을 수 있습니다.

합산 대역폭 8,156GB/s를 카드당 몫 16.4GB로 나눠 4를 두 번 적용한 값입니다. 카드당 대역폭에는 카드당 가중치를, 합산 대역폭에는 전체 가중치를 맞춰야 하고 어느 쪽으로 세어도 답은 124토큰입니다. `max_num_batched_tokens` 하향은 스텝에 섞이는 prefill 조각을 줄여 간격을 고르게 하는 손잡이라 가중치 읽기가 정하는 상한은 건드리지 못합니다.