Inference 비용 낮추기: KV cache, batching, 양자화

token을 생성하려면 decoder-only transformer는 지금까지의 전체 sequence를 받아 모든 layer를 통과시키고, 마지막 위치에서 확률 분포를 읽습니다. 그런 다음 선택된 token을 붙이고 다시 반복합니다. 이 설명은 맞고, 느린 실행이 하는 일이 바로 이것입니다.

하지만 엄청나게 낭비적이기도 합니다. 이유는 9장의 causal mask입니다. 위치 7의 key와 value 벡터는 위치 7의 입력과 그 앞 위치들로부터 계산됩니다. 위치 8이 들어와도 위치 7은 그것을 볼 수 없습니다 — causal하다는 뜻이 바로 그것입니다 — 그래서 위치 7의 key와 value는 이전과 정확히 같은 숫자입니다. 느린 실행은 그래도 매 step마다 그것들을 다시 계산합니다.

그러니 저장하면 됩니다. 그 저장소가 key-value cache, 언어 모델 serving에서 가장 결정적인 최적화입니다:

out = model(prompt_ids, use_cache=True)          # prefill: the whole prompt
past = out.past_key_values                        
nxt = out.logits[:, -1].argmax(-1, keepdim=True)

for _ in range(n - 1):
    out = model(nxt, past_key_values=past, use_cache=True)   
    past = out.past_key_values                                
    nxt = out.logits[:, -1].argmax(-1, keepdim=True)

loop 안에서 모델에 무엇이 들어가는지 보세요: nxt, token 하나입니다. sequence가 아닙니다. 새 token의 query는 모든 cached key에 attention하고, cached key들은 애초에 바뀔 일이 없었습니다. 이것은 근사가 아닙니다 — 위의 동일 출력 확인이 핵심입니다. cache는 품질을 속도와 맞바꾸지 않습니다. 중복 산술을 지워 버립니다.

스케일링을 깔끔하게 보려면 transformer를 걷어 내고 $d = 64$인 단일 attention head 하나를 두 방식으로 generation 한 step만 시간 측정합니다:

오른쪽 열이 원인입니다. 재계산은 매 step마다 전체 $n \times n$ attention matrix를 만듭니다 — 9장의 점근 표기 상자에 있던 $O(n^2)$를 token마다 한 번씩 치르는 셈입니다. cache를 쓰면 대신 $1 \times n$ 행 하나를 만듭니다. 4,096 token에서는 score가 67 MB 대 16 KB입니다.

밀리초 대신 multiply-accumulate를 세면 머신을 논의에서 제거할 수 있습니다. cold start에서 $T$ token을 생성하려면:

step마다 cached 버전은 context에 대해 선형이고 uncached 버전은 제곱입니다. generation 전체로 합치면 $O(T^2)$ 대 $O(T^3)$이고, 비율은 끝없이 커집니다. 첫머리의 아홉 배 차이는 48 token에서 측정한 것입니다 — 저 표의 첫 행보다도 짧습니다.

cache는 메모리에 무엇이 있어야 하는지도 바꿉니다. 8 GB 노트북 GPU에서 fp16으로 256 token을 생성하며 allocator의 peak에서 resident weights를 빼면:

8.3배 더 많은 메모리를 써서 같은 token을 더 느리게 만들어 냅니다. 이것은 5장에서 한 약속이 예상치 못한 방향에서 도착한 것입니다. 그곳에서는 reverse-mode autodiff가 backward pass를 위해 모든 intermediate를 살려 둬야 했고, activation이 학습 메모리를 지배했습니다. inference에는 backward pass가 없고 그것을 위해 보존할 것도 없습니다 — 그래서 대신 메모리를 지배하는 것은 cache이며, 이는 피할 수 없는 비용이 아니라 의도적인 선택입니다.

빠른 실행을 다시 보세요. 첫 token은 나머지 47개와 다르게 행동했습니다.

prefill, 40 prompt tokens : 1.0224 s   ->  25.6 ms per token
decode,  47 steps         : 0.1665 s mean per step

prompt 비용은 token당 25.6 ms였고, 생성된 각 token은 166 ms였습니다. 같은 모델, 같은 하드웨어, 같은 가중치인데 token당 여섯 배 차이입니다 — 그리고 대부분의 사람이 예상하지 않는 방향입니다. prompt가 싼 부분입니다. Generation은 실제 물리가 다른 두 phase로 갈라집니다:

두 절반은 모두 측정할 수 있습니다. Prefill, $P$ token에 대한 pass 한 번:

Decode, $C$ cache에 대해 token 하나:

두 번째 표를 두 번 읽어 보세요. context가 16 token에서 1,024 token으로 — attention해야 할 history가 64배로 — 늘어났는데도 step 비용은 측정 가능한 만큼 변하지 않았습니다. cache에 대한 attention은 실제 작업이지만, 벡터 하나를 만들기 위해 5억 개 가중치를 memory bus로 끌고 오는 고정 비용에 압도됩니다. 그 고정 비용이 다음 섹션의 모든 이유입니다.

이 두 phase가 모든 serving 시스템이 보고하는 두 숫자의 기원입니다. Time to first token은 본질적으로 prefill이며 prompt와 함께 늘어납니다. 그래서 긴 대화는 시작이 느리게 느껴집니다. Tokens per second는 $1/\text{decode step}$이고 대략 일정합니다. 그래서 답변은 그 뒤로 고르게 흘러갑니다. 느리게 시작해 부드럽게 streaming되는 chat은 렌더링 trick이 아닙니다. 바로 이 두 표입니다.

cache는 산술을 메모리와 맞바꾸며, 그것이 원하는 메모리는 작지 않습니다. context의 token마다, 모든 layer는 key-value head마다 key vector 하나와 value vector 하나를 보유합니다:

2는 key와 value 때문이고, 나머지는 architecture입니다. 이 장 전체에서 측정한 모델 — 24 layer, 14 query head, 2 key-value head, head dimension 64 — 에서는 fp16 기준 token당 $2 \times 24 \times 2 \times 64 \times 2 = 12{,}288$ byte입니다.

이 분야의 공식은 두 배씩 틀리는 버릇이 있으니, 믿기 전에 allocator와 대조해 봅니다:

KV cache tensors per layer: (1, 2, 295, 64) float16
measured: 3,624,960 bytes for 295 tokens = 12,288 bytes/token
formula : 2 * 24 * 2 * 64 * 2                = 12,288 bytes/token

정확합니다. 시도한 모든 shape에서 계속 정확합니다:

마지막 세 행은 다시 볼 만합니다. 2,048 token씩 가진 사용자 32명, 1,024 token씩 가진 64명, 512 token씩 가진 128명 — 세 경우 모두 cache는 768 MB입니다. 셋 모두 65,536 token을 보유하기 때문입니다. cache는 resident인 총 token 수에만 의존하고, 그것들이 사용자 사이에 어떻게 분포하는지에는 의존하지 않습니다. 이 사실이 batching 섹션의 토대입니다.

9장은 multi-query attention과 grouped-query attention을 소개하고 이유를 이 장으로 미뤘습니다. 이유는 바로 저 공식, 특히 그 안의 $H_{kv}$입니다.

표준 multi-head attention은 모든 query head에 자기 key와 value head를 줍니다. 여기의 모델에는 14개 query head가 있습니다. full multi-head attention이었다면 cache는 token당 $2 \times 24 \times 14 \times 64 \times 2 = 86{,}016$ byte였을 것입니다 — 12 KB가 아니라 84 KB, 정확히 일곱 배이며, query head와 key-value head의 비율입니다.

Multi-query attention¹은 이것을 극한까지 밀어붙입니다. 모든 query head가 단일 key-value head를 공유합니다. Grouped-query attention²은 승리한 절충안입니다 — 몇 개의 key-value head가 있고, 각 head를 query head 그룹이 공유합니다 — MQA의 품질 손실은 실제였고 GQA의 손실은 그렇지 않았기 때문입니다. 둘 다 산술을 줄여 주지 않습니다. 이들은 저 공식을 정수로 나누기 위해 존재하며, 긴 context가 cache를 binding constraint로 만든 순간 업계 전반으로 퍼졌습니다.

그리고 그것은 빠르게 그렇게 됩니다. 32 layer와 dimension 128의 key-value head 8개를 가진 7B급 모델에서 cache는 fp16 기준 token당 128 KB입니다:

그 모델 자체의 가중치는 fp16에서 13.0 GB이며, 이 장 끝 표의 수치입니다. 그래서 128,000-token context에서는 사용자 한 명의 cache가 모델보다 큽니다. 이 산술을 16장이 돈으로 바꿉니다. 긴 대화가 단지 느린 대화가 아닌 이유도 이것입니다 — 요청이 살아 있는 동안 머신의 고정된 조각을 점유합니다.

Decode는 memory-bound입니다. 가중치를 bus로 끌고 와 token 하나를 만들고, 산술 유닛은 놀고 있습니다. 그러니 같은 step에 더 많은 일을 넣습니다. 여러 요청을 한 번에 실행하면 한 번 읽은 가중치가 모두에게 쓰입니다. 같은 모델에서 각 요청이 64-token cache를 들고 token 하나를 decode하도록 측정했습니다:

오른쪽 두 열을 서로 맞대어 읽어 보세요. 그게 전부입니다. 요청 하나에서 열여섯 개로 가면 throughput은 6.0배가 되고, 개별 요청이 기다리는 시간은 2.67배가 됩니다. batch는 서버를 더 좋게 만들고 모든 사용자를 더 나쁘게 만들었습니다.

이것은 조정해서 없앨 bug가 아닙니다. 바로 그 trade-off 자체이며, 양쪽에 이름이 있습니다. Latency는 답을 기다리는 사람이 경험하는 것입니다. Throughput은 청구서를 나누는 값입니다. 둘 다 개선하는 설정은 없습니다.

멈추는 지점도 보세요. 16에서 32로 가면 throughput은 9% 늘지만 latency는 거의 두 배가 됩니다. step이 memory-bound를 벗어나 compute-bound가 되었고, 그 knee를 지나면 batch가 아무것도 사 주지 않습니다. 모든 deployment에는 그런 knee가 있습니다. 위치는 여러분의 시스템에서 측정해야 하지만, 그 존재는 그렇지 않습니다.

naive한 batching 방식은 $B$개 요청을 모아 함께 실행하고, 모두 끝나면 반환하는 것입니다. 하지만 요청들은 함께 끝나지 않습니다. 어떤 답은 20 token이고 어떤 답은 500 token입니다. 고정 batch는 가장 긴 구성원이 끝날 때까지 실행되고, 이미 끝난 요청은 그때까지 slot을 계속 차지하며 padding에 기여합니다.

현실적인 output 길이의 편향을 가진 64개 요청을 봅시다 — median 18 token, longest 231, 총 1,874 — 그리고 8개 slot의 측정된 per-step 비용으로 두 policy를 simulation합니다:

Throughput은 1.6배 개선됩니다. 평균 latency는 열 배 넘게 좋아집니다. static batching에서는 네 step 만에 끝난 요청도 231-token 이웃이 끝날 때까지 누구에게도 들리지 않기 때문입니다.

Continuous batching³이 해결책이며, 말 그대로 단순합니다. batch는 그룹이 아니라 slot의 집합이고, slot이 비면 바로 다음 step에서 대기 중인 다음 요청을 받습니다. scheduler는 요청 하나가 아니라 token 하나의 granularity로 동작합니다. production의 모든 serving stack은 이제 이렇게 합니다.

두 번째 절반은 cache입니다. 들어오고 나가는 slot은 cache 메모리를 fragment시키고, 각 slot에 가능한 최대 context를 예약하면 예약분 대부분을 낭비합니다. PagedAttention⁴은 운영체제에서 답을 빌려옵니다. cache를 고정 크기 block에 저장하고 sequence마다 block table을 둬서, sequence의 cache가 물리적으로 흩어져 있어도 논리적으로는 연속되게 합니다 — 또한 shared prefix를 가진 두 sequence가 그것을 담은 block을 공유할 수 있게 합니다. vLLM이 그 위에 지어졌고, serving engine이 transformer가 붙은 memory allocator인 이유입니다.

청구서의 다른 절반은 가중치 자체입니다. 5억 개 parameter가 각각 4 byte이면 1.98 GB이고, 2 byte이면 0.99 GB, 1 byte이면 0.49 GB입니다. weight당 bit가 적을수록 disk의 모델도 작아지고, 메모리의 모델도 작아지며, decode가 bandwidth-bound이기 때문에 각 step도 빨라집니다. 옮길 byte가 적기 때문입니다.

가장 단순한 방식은 symmetric absolute-maximum quantization이고, 세 줄에 들어갑니다:

qmax  = 2 ** (bits - 1) - 1
scale = W.abs().max() / qmax                        
Wq    = torch.round(W / scale).clamp(-qmax - 1, qmax)
W_hat = Wq * scale                                  # dequantized

가장 큰 weight가 가장 큰 integer에 대응되도록 scale을 고르고, 나누고, 반올림하고, integer와 scale을 저장합니다. 복원은 다시 곱하면 됩니다. 영리한 것은 하나도 없지만 작동합니다 — 작동하지 않을 때까지는요.

모델의 실제 가중치에서 측정했습니다. projection matrix 168개 전체, parameter 3억 5,780만 개, relative error $\lVert W - \hat{W}\rVert / \lVert W \rVert$:

네 번째 행이 붕괴입니다. 최악의 matrix에서 relative error 0.99라는 것은 복원이 원본의 거의 아무것도 보존하지 못했다는 뜻입니다 — matrix가 대략 맞는 크기의 noise로 바뀐 것입니다. 원인은 단일 matrix에 대한 같은 실험에서 보입니다:

model.layers.12.mlp.down_proj.weight   (896 x 4864)
mean |w| 0.01386   std 0.01822   max |w| 0.43945   max/std 24.1
weights beyond 6 sigma: 692 of 4,358,144   (0.016 %)

6,000개 중 weight 하나가 6 standard deviation 너머에 있고, 가장 큰 것은 24 밖에 있습니다. 전체 matrix에 scale 하나를 쓰면 그 weight 하나가 430만 개 전체의 step size를 정합니다. 8 bit에서는 256 step이 있어서 typical weight도 의미 있는 step에 떨어집니다. 4 bit에서는 16개뿐이고, 가장 바깥쪽은 거의 아무것도 갖지 않는 값에 예약되어 있으며, ordinary weight — 사실상 전부 — 는 두세 개 level로 반올림됩니다.

그 행 이후의 모든 것은 다른 granularity에서 같은 수리입니다. scale의 영토를 줄입니다. output row별로 하면 error가 3.4로 나뉘고, 연속된 128개 weight 그룹별로 하면 다시 나뉩니다. 비용은 bookkeeping입니다 — 128개 그룹마다 16-bit scale 하나면 weight당 4 bit가 아니라 $4 + 16/128 = 4.125$ bit입니다 — 그리고 잃어버린 간격 대부분을 되사 옵니다.

NF4는 반대쪽에서 접근합니다.⁵ level이 등간격일 필요는 없습니다. block 안의 weight는 대략 normal distribution이므로, 16개 level을 normal distribution의 quantile로 고릅니다. weight가 실제로 있는 0 근처에는 촘촘하게, 없는 tail에는 드문드문 둡니다. 같은 4 bit, 같은 block scaling, 더 작은 block — group-128의 4.125에 비해 weight당 4.25 bit — 이고 측정 error는 0.1323에서 0.0952로, 28% 낮아집니다. 일부는 더 세밀한 block 때문이고 나머지는 level을 질량이 있는 곳에 둔 덕분이며, 둘을 분리하려면 세 번째 행이 필요합니다.

2장의 floating-point 상자는 약속으로 끝났습니다. 이 장이 가중치를 8 bit와 4 bit로 quantize하고, 눌러 담기 거부하는 몇몇 outlier feature를 찾을 것이라는 약속입니다. 여기 있습니다. 그리고 이것들이 왜 “숫자를 그냥 반올림”하는 방식이 activation에서는 통할 수 없었는지 설명합니다.

위의 가중치도 얌전하지 않았습니다. activation은 다른 리그에 있습니다. 평범한 84-token prompt를 사용해 각 layer의 residual stream을 캡처하고, 896개 dimension 각각이 도달한 최대 magnitude를 측정합니다:

Dimension 62는 1,579.6에 도달하지만 median dimension은 1.6을 넘지 않습니다. token 하나나 layer 하나의 우연이 아닙니다. 같은 dimension이 layer 4에도 있고 layer 20에도 거의 같은 값으로 남아 있습니다. 이것이 outlier feature⁶이며, 체계적입니다 — 입력의 속성이 아니라 학습된 모델의 속성입니다.

layer 16에서 896개 per-dimension maximum의 histogram을 보면 모양이 분명합니다:

     0 -      1 | ######################################## 254
     1 -      2 | ######################################## 283
     2 -      4 | ######################################## 226
     4 -      8 | ######################################## 93
     8 -     16 | ##################                       18
    16 -     32 | #########                                9
    32 -     64 | #######                                  7
    64 -    128 | #####                                    5
   128 -    256 |                                          0
   256 -    512 |                                          0
   512 -   1024 |                                          0
  1024 -   4096 | #                                        1

900개 dimension이 8 아래에 가지런히 쌓여 있고, 세 octave 동안 아무것도 없다가, 맨 끝에 dimension 하나가 홀로 있습니다. 이제 그 tensor를 INT8로 quantize하고 무슨 일이 일어나는지 세어 봅니다:

256개 level 중 14개입니다. scale은 1,579.6으로 정해졌으므로 모든 step은 12.44 폭입니다. typical activation — median magnitude 0.26, ninety-ninth percentile 2.51 — 은 내려앉을 곳이 없습니다. dimension별로 보면 더 극명합니다:

single tensor-wide scale = 12.4378
  dim 826 (max |h| = 4.77):  1 distinct level out of 256
  dim 336 (max |h| = 1.62):  1 distinct level out of 256
  dim  96 (max |h| = 0.69):  1 distinct level out of 256

after excluding the top 4 dimensions, scale = 0.5749  (22x smaller)
  dim 826: 8 levels    dim 336: 4 levels    dim  96: 3 levels

level 하나. 전체 dimension, 모든 token이 같은 숫자로 quantize되었습니다. 8 bit를 할당했는데 사실상 0 bit가 쓰였고, 그 activation을 읽는 모델은 상수를 건네받습니다.

이 측정이 사람들이 실제로 쓰는 모든 기법의 정당화입니다:

quantization에 관한 거의 모든 글은 이전 섹션에서 멈춥니다. method를 설명하고, compression ratio를 인용하고, 품질이 “대체로 보존된다”고 주장합니다. 4장은 스스로를 속이지 않는 법에 관한 것이었으니, 직접 알아봅시다.

같은 모델의 가중치를 각 scheme으로 제자리에서 quantize한 뒤 세 가지를 측정했습니다. held-out English prose 2,048 token에서의 perplexity — 여기서는 이 강좌의 초안이며, 그래서 repository는 고정된 public-domain 책으로 대체하고 같은 모양의 표를 다른 숫자로 출력합니다 — greedy decoding 아래 known answer가 있는 짧은 factual question 16개 battery, 그리고 동일 context에서 quantized model이 full-precision model과 같은 token을 고르는 비율입니다.

이 표에서 네 가지는 분명히 말할 가치가 있습니다.

제대로 한 INT8은 공짜다. per-row INT8은 reference의 23.08에 대해 22.96을 기록합니다 — 200분의 1 차이이며 noise로 보고 “동일”하다고 읽어야 합니다. noise가 어느 방향을 가리키는지는 안정적이지 않습니다. repository의 public-domain corpus에서는 같은 두 scheme이 22.18에 대해 22.24로 나옵니다. 절반 거리이고 방향도 반대입니다. 생성된 144개 token 중 142개에서 full-precision model과 일치합니다. fp32 reference 대비 메모리의 4분의 1, 실제로 deploy할 fp16 대비 절반, 감지 가능한 비용은 없습니다. INT8을 부주의하게 해도 거의 공짜입니다. matrix마다 scale 하나를 쓰면 perplexity 0.5 point와 battery 답변 0개를 잃을 뿐입니다. 8 bit는 granularity가 거의 중요하지 않을 만큼 관대합니다. 사람들이 INT8에서 INT4로 일반화했다가 다치는 이유가 정확히 이것입니다.

tensor당 scale 하나의 INT4는 모델을 파괴한다. Perplexity 3억 6,500만: 저하가 아니라 전멸입니다. 그다음부터는 granularity가 전부입니다 — per-tensor 365,416,000, per-row 46.18, per-group-of-128 31.08, NF4 24.55. weight당 같은 4 bit인데 최악과 최선 사이가 1,500만 배입니다.

Perplexity는 거친 도구이고 battery는 더 거칠다. NF4와 group-128 INT4 사이의 perplexity gap은 6.5 point이고 battery는 질문 하나 차이입니다 — 4장의 confidence interval에 따르면 16개 중 질문 하나는 아무것도 구분하지 못합니다. interval보다 더 날카로운 시연도 있습니다. 모델의 기본 repetition penalty를 끄고 같은 battery를 실행해 보세요. 그것이 greedy decoding이 실제로 뜻하는 바인데, 그러면 두 행의 순위가 바뀝니다. 16개 중 질문 하나는 작은 효과가 아니라 효과가 없음입니다. 8장의 경고도 적용됩니다. perplexity는 tokenizer를 공유하는 모델 사이에서만 비교 가능하므로, 다른 사람 글의 숫자를 여러분의 것과 비교할 수 없습니다.

agreement 열은 셋 중 가장 날카롭고, 거의 공짜입니다. full-precision model을 greedily 실행한 뒤, quantized model에게 매 위치에서 같은 prefix가 주어졌다면 무엇을 골랐을지 묻습니다. 16개가 아니라 144개의 독립 관측을 얻고, ground truth가 필요 없으며, battery가 계단식으로 나빠지는 곳에서도 부드럽게 degrade됩니다. 또한 다음 섹션에 필요한 양이 정확히 이것입니다.

이것은 1장이 이 장에 대해 한 약속이 제때 도착한 것입니다. 수학은 4-bit model이 가능하다고 말하고, engineering은 그것이 usable한지 결정합니다.

12장이 이것을 예고했고 청구서는 여기로 남겼습니다.

아이디어는 prefill/decode 분리에서 곧장 나옵니다. $\gamma$ token의 제안된 sequence를 verify하는 비용은 $\gamma$ 위치에 대한 forward pass 한 번입니다 — matrix-matrix product이며, 하나에 대한 pass보다 겨우 더 비쌉니다. 그러므로:

output distribution은 변하지 않습니다. greedy decoding에서는 명백합니다 — target이 만들었을 token일 때만 token을 accept하기 때문입니다. sampling에서는 수정된 acceptance rule이 필요하고, Leviathan et al.은 그 결과 distribution이 정확히 target의 것임을 증명합니다.¹⁰ 이것이 이 장의 두 번째 exact optimisation입니다.

따라서 모든 것은 acceptance rate $\alpha$에 달려 있고, 이는 측정 가능합니다 — 위의 agreement 열이며, 그래서 거기서 계산했습니다. 각 quantized model을 full-precision target의 draft로 사용해 144개 생성 위치에서 측정하면:

verification pass당 accept되는 기대 token 수는 draft length $\gamma$에서

이고, 순 speedup은 target 대비 token당 fraction $c$인 draft 자체의 비용으로 그것을 나눕니다:

굵은 항목을 기억해야 합니다. speculative decoding은 generation을 더 느리게 만들 수 있습니다. acceptance가 30%이고 draft 비용이 target의 5분의 1이면, forward pass 다섯 번 값을 치르고 1.4 token을 유지합니다. 마지막 열은 또 다른 함정입니다 — 긴 draft는 acceptance가 높을 때만 도움이 됩니다. $\gamma$-token 추측의 tail에는 거의 도달하지 않기 때문입니다. acceptance 90%에서는 $\gamma = 8$가 3.40x 가치가 있고, 30%에서는 0.79x 가치입니다. 같은 configuration이 traffic에서 측정한 숫자에 따라 이익이거나 손실입니다.

Quantization은 같은 function을 더 적은 bit에 저장해 모델을 줄입니다. Distillation은 작은 모델이 큰 모델을 모방하도록 학습해 줄입니다¹¹ — deep learning보다 거의 10년 앞선 아이디어입니다.¹²

미묘한 부분은 student가 무엇으로부터 배우는가입니다. 정답이 아닙니다. 정답만으로도 직접 학습할 수 있었을 것입니다. teacher가 더하는 것은 전체 distribution입니다. phrase 뒤에 무엇이 오는지 모델에게 묻고 argmax 너머를 봅니다:

"She poured the milk into the"
  ' jug' 0.1355   ' cup' 0.1051   ' bowl' 0.0605   ' large' 0.0380   ' milk' 0.0360

hard label은 jug라고 말하고 그뿐입니다. soft label은 jug라고 말하고, 또한 cup도 거의 그만큼 좋았고, bowl도 그럴듯했으며, large — 형용사, 완전히 다른 문법적 continuation — 도 아직 살아 있다고 말합니다. 원래의 논거가 이것입니다. 이것은 7이지만 1과 꽤 많이 닮았다, 그리고 그 닮음은 hard label이 버리는 정보입니다.

그래서 distillation은 temperature를 씁니다. softmax 전에 logits를 $T$로 나누면 distribution이 평평해지고 runner-up의 relative weight가 올라갑니다. 이 phrase에서는 top token과 세 번째 token의 비율이 $T = 1$에서 2.24였다가 $T = 2$에서 1.50으로 떨어집니다 — 첫 값의 제곱근이며, logits를 2로 나누면 비율에 일어나는 일이 바로 그것입니다. 같은 ordering, near miss에 더 많은 loss의 attention. student의 gradient는 teacher의 verdict만이 아니라 uncertainty도 담습니다.

이 장의 모든 것은 이제 하나의 합입니다:

여기서 $T$는 모든 concurrent request에 걸쳐 resident인 총 token입니다. 적용해 봅시다. 7B와 70B 행은 dimension 128의 key-value head 8개를 가정하고, 13B 행은 40 head의 full multi-head attention을 가정합니다. 그 세대의 모델이 그렇게 만들어졌고 — 차이가 드러납니다.

8 GB

16 GB

24 GB

8 GB 표의 13B 행을 보세요. 가중치는 들어갑니다 — 8 GB 중 6.2 GB — 그래서 흔히 말하는 방식으로는 13B 모델이 “8 GB card에서 돈다”고 합니다. 하지만 context는 337 token입니다. 대화가 아니라 겨우 prompt입니다. “들어가느냐”는 잘못된 질문입니다. 맞는 질문은 “얼마나 많은 context로, 동시에 몇 명에게”입니다.

16 GB int8 두 행도 보세요. 7B는 65,378 token을 얻고 13B는 3,136 token을 얻습니다 — 추가 weight 5.6 GB에서 생긴 20배 차이입니다. 여기의 13B는 multi-head attention이고 cache 비용이 token당 800 KB로, 7B의 128 KB와 다르기 때문입니다. 비슷한 크기의 두 모델 중 하나는 긴 context에 쓸 수 없고, 그 이유는 어떤 model card의 headline에도 나타나지 않습니다.

열세 장 전에는 이것이 weight 두 개와 bias 하나를 가진 perceptron이었습니다. 이제는 설계되고, 학습되고, aligned되고, 어려운 질문에 compute를 쓰도록 배웠으며, token당 측정된 비용으로 served되는 transformer입니다 — 안에 닫힌 상자가 하나도 남아 있지 않습니다.

여기서 끝나며, 의도적으로 끝납니다.

14장은 모델이 다른 곳에 있는 상태에서 시작합니다. 여러분의 process 안도, memory 안도, print할 수 있는 variable 안도 아닙니다. 여러분이 관리하지 않는 머신, API key와 port와 bill 뒤에 있습니다. 여기서 측정한 모든 것은 여전히 일어나고 있습니다 — 첫 token 전에 prefill은 여전히 실행되고, cache는 대화와 함께 여전히 자라며, 여러분이 속한 batch는 여전히 누군가 다른 사람의 것이고 여전히 여러분의 latency를 결정합니다 — 하지만 이제부터는 Server-Sent Events stream, finish_reason, 그리고 Retry-After header가 붙은 HTTP 429를 통해 그것을 관찰합니다. vantage point가 바뀌면 질문도 바뀝니다. 이 gradient는 어떻게 계산되는가가 아니라 왜 invoice가 세 배가 되었는가입니다. 언어도 바뀌며, 14장은 그 규칙을 선언하지 않고 설명합니다 — 여기까지 code는 weights, gradients, logits, tokenizer byte를 들고 있었고, 그다음부터는 connection, retry, cancellation, accumulated state를 듭니다. 건너간다고 해서 뒤의 열세 장이 버려지는 것은 아닙니다. 그것들은 port 반대편에서 실행 중인 것의 설명입니다.

두 가지 생략은 의도적입니다. FlashAttention (Dao et al., arXiv:2205.14135)은 다른 attention이 아닙니다 — $n \times n$ score matrix가 메모리에 쓰이지 않도록 연산을 tiling해서 같은 function을 계산합니다. 그래서 이 장의 두 번째 표에 있는 67 MB는 실제로는 산술이 시사하는 것보다 작습니다. 그리고 kernel 자체는 위임했습니다. Stanford CS336의 lecture 10은 inference system을 여기서 시도하지 않는 깊이로 다루며, llama.cpp repository와 GGUF specification은 CPU 쪽의 primary source입니다.