Làm inference rẻ hơn: KV cache, batching và lượng tử hóa

Để sinh một token, một decoder-only transformer nhận toàn bộ chuỗi cho đến lúc đó, chạy nó qua mọi layer, rồi đọc phân phối xác suất ở vị trí cuối. Sau đó nó nối token đã chọn vào và làm lại. Mô tả đó đúng, và đó là điều lần chạy chậm thực hiện.

Nó cũng cực kỳ lãng phí, và lý do là causal mask từ Chương 9. Vector key và value của vị trí 7 được tính từ input của vị trí 7 và các vị trí trước nó. Khi vị trí 8 xuất hiện, vị trí 7 không thể nhìn thấy nó — đó là ý nghĩa của causal — nên key và value của vị trí 7 là chính xác cùng những con số như trước. Lần chạy chậm vẫn tính lại chúng ở mọi bước.

Vậy hãy lưu chúng lại. Kho lưu đó là key-value cache, tối ưu quan trọng nhất trong serving language model:

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)

Hãy nhìn thứ được đưa vào model bên trong vòng lặp: nxt, một token. Không phải cả chuỗi. Query của token mới attends với mọi key đã cache, và các key đã cache vốn sẽ không bao giờ thay đổi. Đây không phải một phép xấp xỉ — kiểm tra output giống hệt ở trên chính là điểm mấu chốt. Cache không đánh đổi chất lượng lấy tốc độ; nó xóa phép tính thừa.

Để thấy scaling một cách sạch sẽ, bỏ transformer ra và đo thời gian một attention head đơn với $d = 64$, một bước generation được tính theo cả hai cách:

Cột bên phải là nguyên nhân. Tính lại sẽ dựng toàn bộ ma trận attention $n \times n$ ở mỗi bước — $O(n^2)$ từ hộp ký hiệu tiệm cận của Chương 9, trả một lần cho mỗi token. Với cache, bạn chỉ dựng một hàng $1 \times n$: ở 4.096 token, 67 MB score so với 16 KB.

Đếm multiply-accumulates thay vì mili giây sẽ loại máy khỏi lập luận. Để sinh $T$ token từ cold start:

Mỗi bước, phiên bản có cache tuyến tính theo context còn phiên bản không cache là bậc hai; cộng trên toàn bộ một generation, $O(T^2)$ so với $O(T^3)$, với tỷ lệ tăng không giới hạn. Chênh lệch chín lần ở phần mở đầu được đo trên 48 token — còn ngắn hơn hàng đầu tiên của bảng đó.

Cache cũng thay đổi thứ phải nằm trong memory. Trên GPU laptop 8 GB sinh 256 token ở fp16, lấy đỉnh của allocator rồi trừ trọng số thường trú:

Tốn memory hơn 8,3 lần, để tạo ra cùng những token đó nhưng chậm hơn. Đây là lời hứa trong Chương 5, đến từ một hướng không ngờ: ở đó, reverse-mode autodiff phải giữ mọi trung gian sống cho backward pass, và activations chi phối memory training. Ở inference không có backward pass và không cần giữ gì cho nó — nên thứ chi phối memory thay vào đó là cache, và nó là một lựa chọn có chủ ý chứ không phải chi phí không thể tránh.

Nhìn lại lần chạy nhanh: token đầu tiên của nó cư xử khác bốn mươi bảy token còn lại.

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

Prompt tốn 25,6 ms mỗi token và mỗi token được sinh tốn 166 ms. Cùng model, cùng phần cứng, cùng trọng số, chênh lệch sáu lần mỗi token — và theo hướng hầu hết mọi người không ngờ. Prompt là phần rẻ. Generation tách thành hai pha với vật lý thật sự khác nhau:

Cả hai nửa đều đo được. Prefill, một pass trên $P$ token:

Decode, một token đối với cache $C$:

Hãy đọc bảng thứ hai hai lần. Đi từ 16 token context lên 1.024 — lịch sử để attend nhiều hơn sáu mươi tư lần — không làm chi phí một bước thay đổi theo cách đo được. Attention đối với cache là công việc thật, nhưng nó bị chi phí cố định của việc kéo nửa tỷ trọng số qua memory bus để tạo ra một vector lấn át. Chi phí cố định đó là lý do cho mọi thứ ở phần tiếp theo.

Hai pha này là nguồn gốc của hai con số mà mọi serving system báo cáo. Time to first token về cơ bản là prefill, và nó tăng theo prompt, đó là lý do một cuộc trò chuyện dài tạo cảm giác chậm lúc bắt đầu. Tokens per second là $1/\text{decode step}$, và nó gần như hằng định, đó là lý do câu trả lời sau đó chảy đều. Một chat bắt đầu chậm rồi stream mượt không phải mẹo render. Nó chính là hai bảng này.

Cache đổi phép tính lấy memory, và memory nó muốn không hề nhỏ. Với mỗi token trong context, mỗi layer giữ một vector key và một vector value cho mỗi key-value head:

Số 2 là cho keys và values; mọi thứ còn lại là kiến trúc. Với model được đo xuyên suốt chương này — 24 layer, 14 query head, 2 key-value head, head dimension 64 — ở fp16, con số đó là $2 \times 24 \times 2 \times 64 \times 2 = 12{,}288$ byte mỗi token.

Các công thức trong lĩnh vực này có thói quen lệch một hệ số hai, nên hãy kiểm tra với allocator thay vì tin nó:

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

Chính xác, và vẫn chính xác trên mọi shape đã thử:

Ba hàng cuối đáng nhìn lại lần nữa. Ba mươi hai user với 2.048 token mỗi người, sáu mươi tư với 1.024, một trăm hai mươi tám với 512 — cache đều là 768 MB trong mọi trường hợp, vì cả ba cùng giữ 65.536 token. Cache chỉ phụ thuộc vào tổng số token đang thường trú, không phụ thuộc vào cách chúng được phân bổ giữa các user. Sự thật đó là nền móng của phần batching.

Chương 9 đã giới thiệu multi-query và grouped-query attention rồi hoãn lý do sang chương này. Lý do là công thức đó, và cụ thể là $H_{kv}$ trong đó.

Standard multi-head attention cho mỗi query head key và value head riêng của nó. Model ở đây có 14 query head; với full multi-head attention, cache của nó sẽ là $2 \times 24 \times 14 \times 64 \times 2 = 86{,}016$ byte mỗi token — 84 KB thay vì 12 KB, nhiều hơn đúng bảy lần, tỷ lệ giữa query head và key-value head.

Multi-query attention¹ đẩy chuyện này đến cực hạn: mọi query head dùng chung một key-value head. Grouped-query attention² là thỏa hiệp đã thắng — một vài key-value head, mỗi head được chia sẻ bởi một nhóm query head — vì mất mát chất lượng của MQA là thật còn của GQA thì không. Cả hai không mua thêm phép tính nào. Chúng tồn tại để chia công thức đó cho một số nguyên, và lan khắp ngành ngay khi context dài khiến cache trở thành ràng buộc chính.

Và nó nhanh chóng trở thành như vậy. Với một model lớp 7B có 32 layer và 8 key-value head dimension 128, cache là 128 KB mỗi token ở fp16:

Trọng số riêng của model đó là 13,0 GB ở fp16, con số trong bảng cuối chương này. Vì vậy ở context 128.000 token, cache của một user lớn hơn cả model. Đây là phép tính mà Chương 16 biến thành tiền, và là lý do một cuộc trò chuyện dài không chỉ chậm — nó chiếm một lát cố định của một máy chừng nào request còn sống.

Decode bị memory-bound: trọng số bị kéo qua bus để tạo ra một token, còn các đơn vị tính toán nhàn rỗi. Vậy hãy nhét thêm việc vào cùng một bước. Chạy nhiều request cùng lúc, và trọng số, đọc một lần, phục vụ tất cả. Đo trên cùng model, mỗi request giữ cache 64 token và decode một token:

Hãy đọc hai cột bên phải cùng nhau, vì chúng là toàn bộ vấn đề. Đi từ một request lên mười sáu nhân throughput lên 6,0 và nhân thời gian chờ của bất kỳ request riêng lẻ nào lên 2,67. Batch làm server tốt hơn và mọi user tệ hơn.

Đó không phải bug để tuning cho mất đi; đó chính là trade-off, và mỗi phía có một cái tên. Latency là thứ một người đang chờ trả lời cảm nhận. Throughput là thứ hóa đơn được chia cho. Không có thiết lập nào cải thiện cả hai.

Cũng hãy để ý nơi nó dừng lại. Từ 16 lên 32, throughput tăng 9 % trong khi latency gần như gấp đôi: bước này đã ngừng bị memory-bound và trở thành compute-bound, và qua điểm gối đó batch không mua thêm gì. Mọi deployment đều có một điểm gối như vậy; vị trí của nó phải được đo trên hệ của bạn, nhưng sự tồn tại của nó thì không.

Cách ngây thơ để batch là gom $B$ request, chạy chúng cùng nhau, và trả về khi tất cả xong. Nhưng chúng không kết thúc cùng lúc: có câu trả lời hai mươi token và có câu trả lời năm trăm. Một batch cố định chạy đến khi phần tử dài nhất hoàn thành, và mọi request đã xong vẫn chiếm slot của nó, đóng góp padding, cho đến lúc đó.

Lấy 64 request với độ lệch độ dài output thực tế — trung vị 18 token, dài nhất 231, tổng cộng 1.874 — và mô phỏng cả hai chính sách ở chi phí mỗi bước đo được cho tám slot:

Throughput cải thiện 1,6x. Latency trung bình cải thiện hơn mười lần, vì dưới static batching, một request hoàn thành trong bốn bước vẫn phải đợi một hàng xóm 231 token trước khi ai đó nghe được gì.

Continuous batching³ là cách sửa, và nó đơn giản đúng như tên gọi: batch không phải một nhóm mà là một tập slot, và một slot vừa rảnh sẽ nhận request tiếp theo trong hàng đợi ngay ở bước kế tiếp. Scheduler làm việc ở độ hạt một token thay vì một request. Mọi serving stack trong production hiện nay đều làm vậy.

Nó có nửa thứ hai, là cache. Các slot đến rồi đi để lại memory cache bị phân mảnh, và đặt trước mỗi slot bằng context tối đa có thể của nó lãng phí phần lớn reservation. PagedAttention⁴ mượn câu trả lời từ hệ điều hành: lưu cache trong các block kích thước cố định với một bảng block cho mỗi sequence, để cache của một sequence có thể nằm rải rác về mặt vật lý trong khi vẫn liên tục về mặt logic — điều này cũng cho phép hai sequence có prefix chung chia sẻ các block đang giữ prefix đó. Đó là nền tảng của vLLM, và là lý do một serving engine là một memory allocator có gắn transformer.

Nửa còn lại của hóa đơn là chính các trọng số. Nửa tỷ tham số ở bốn byte mỗi cái là 1,98 GB; ở hai byte là 0,99 GB; ở một byte là 0,49 GB. Ít bit hơn mỗi trọng số làm model nhỏ hơn trên đĩa, nhỏ hơn trong memory, và — vì decode bị bandwidth-bound — làm mỗi bước nhanh hơn, vì có ít byte hơn để di chuyển.

Sơ đồ đơn giản nhất là lượng tử hóa symmetric absolute-maximum, và nó vừa trong ba dòng:

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

Chọn một scale để trọng số lớn nhất ánh xạ đến số nguyên lớn nhất, chia, làm tròn, lưu các số nguyên và scale. Tái tạo bằng cách nhân ngược lại. Không có gì tinh vi, và nó hoạt động — cho đến khi không.

Đo trên trọng số thật của model: toàn bộ 168 ma trận projection, 357,8 triệu tham số, sai số tương đối $\lVert W - \hat{W}\rVert / \lVert W \rVert$:

Hàng thứ tư là cú sụp. Sai số tương đối 0,99 trên ma trận tệ nhất nghĩa là bản tái tạo hầu như không giữ lại gì của bản gốc — ma trận đã bị thay bằng nhiễu có cỡ độ lớn gần đúng. Nguyên nhân hiện rõ trong cùng thí nghiệm trên một ma trận đơn:

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 %)

Một trọng số trong sáu nghìn nằm ngoài sáu độ lệch chuẩn, và trọng số lớn nhất ở mức 24 độ lệch. Với một scale duy nhất cho cả ma trận, chính một trọng số đó đặt kích thước bước cho toàn bộ 4,3 triệu trọng số. Ở 8 bit có 256 bước và trọng số điển hình vẫn rơi vào một bước có ý nghĩa. Ở 4 bit có 16 bước, bước ngoài cùng dành cho một giá trị hầu như không gì có, và các trọng số bình thường — tức là tất cả — bị làm tròn về hai hoặc ba mức khác nhau.

Mọi thứ sau hàng đó là cùng một cách sửa ở các độ hạt khác nhau: cho scale một lãnh thổ nhỏ hơn. Mỗi hàng output chia sai số cho 3,4; mỗi nhóm 128 trọng số liên tiếp lại chia tiếp. Chi phí là bookkeeping — một scale 16-bit mỗi nhóm 128 là $4 + 16/128 = 4.125$ bit mỗi trọng số thay vì 4 — và nó mua lại phần lớn khoảng cách.

NF4 đi từ phía còn lại.⁵ Các mức không nhất thiết phải cách đều. Trọng số trong một block xấp xỉ phân phối chuẩn, nên chọn mười sáu mức là các quantile của phân phối chuẩn: dày gần zero nơi trọng số thật sự nằm, thưa ở đuôi nơi chúng không nằm. Cùng bốn bit, cùng block scaling, ở block nhỏ hơn — 4,25 bit mỗi trọng số so với 4,125 của group-128 — và sai số đo được giảm từ 0,1323 xuống 0,0952, thấp hơn 28 %. Một phần đến từ block mịn hơn và phần còn lại từ việc đặt các mức nơi khối lượng nằm, và tách hai yếu tố đó sẽ cần hàng thứ ba.

Hộp floating-point của Chương 2 kết thúc bằng một lời hứa: chương này sẽ lượng tử hóa trọng số xuống 8 và 4 bit và tìm thấy một nhúm outlier feature không chịu bị nén. Chúng đây, và chúng giải thích vì sao "cứ làm tròn các số" chưa bao giờ có thể hoạt động trên activations.

Các trọng số ở trên đã cư xử tệ. Activations ở một hạng hoàn toàn khác. Lấy một prompt bình thường dài 84 token, capture residual stream ở mỗi layer, và đo độ lớn lớn nhất mà mỗi trong 896 chiều đạt tới:

Chiều 62 đạt 1.579,6 trong khi chiều trung vị chưa bao giờ vượt 1,6. Nó không phải ngẫu nhiên của một token hay một layer: cùng chiều đó xuất hiện ở layer 4 và vẫn ở layer 20, với giá trị gần như không đổi. Đây là các outlier features,⁶ và chúng có tính hệ thống — một thuộc tính của model đã train, không phải của input.

Histogram của 896 cực đại theo chiều ở layer 16 làm hình dạng không thể nhầm lẫn:

     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

Chín trăm chiều xếp gọn dưới 8, hoàn toàn trống trong ba octave, rồi một chiều đơn độc ở tận cuối. Bây giờ lượng tử hóa tensor đó sang INT8 và đếm chuyện gì xảy ra:

Mười bốn mức trong 256. Scale được đặt bởi 1.579,6, nên mỗi bước rộng 12,44, và activation điển hình — độ lớn trung vị 0,26, percentile 99 là 2,51 — không có chỗ để hạ cánh. Theo từng chiều, nó còn rõ hơn:

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

Một mức. Cả chiều, mọi token, bị lượng tử hóa thành cùng một số. Tám bit đã được cấp phát và gần như không bit nào được dùng, còn model đọc các activations đó được đưa một hằng số.

Phép đo đó là lý do cho mọi kỹ thuật mà người ta thật sự dùng:

Hầu như mọi bài viết về quantization dừng ở phần trước: nó giải thích phương pháp, trích một tỷ lệ nén, và khẳng định chất lượng "phần lớn được giữ nguyên". Chương 4 nói về việc không tự lừa mình, nên hãy tìm hiểu.

Cùng model, trọng số được lượng tử hóa tại chỗ với từng scheme, rồi ba phép đo: perplexity trên 2.048 token văn xuôi tiếng Anh held-out — ở đây là bản nháp của khóa học này, nên repository thay bằng một cuốn sách public-domain cố định và in một bảng cùng hình dạng với số khác — một bộ 16 câu hỏi factual ngắn có đáp án biết trước dưới greedy decoding, và tỷ lệ token mà model lượng tử hóa đồng ý với model full-precision khi được cho context giống hệt.

Có bốn điều trong bảng đó đáng nói thẳng.

INT8 làm đúng thì miễn phí. INT8 theo hàng đạt 22,96 so với 23,08 của tham chiếu — khoảng cách một phần hai trăm, là nhiễu và nên được đọc là "giống hệt". Nhiễu nghiêng về phía nào không ổn định: trên corpus public-domain của repository, hai scheme tương tự ra 22,24 so với 22,18: nửa khoảng cách đó, và nghiêng theo hướng ngược lại. Nó đồng ý với model full-precision trên 142 trong 144 token được sinh. Một phần tư memory so với tham chiếu fp32, một nửa so với fp16 mà bạn thật sự triển khai, và không có chi phí phát hiện được. INT8 làm ẩu cũng gần như miễn phí: một scale mỗi ma trận tốn 0,5 điểm perplexity và không mất câu trả lời nào trong battery. Tám bit đủ khoan dung để độ hạt hầu như không quan trọng, và đó chính là lý do người ta khái quát từ INT8 sang INT4 rồi bị đau.

INT4 với một scale mỗi tensor phá hủy model. Perplexity 365 triệu: không phải xuống cấp, mà bị tiêu diệt. Sau đó độ hạt là toàn bộ trò chơi — per-tensor 365.416.000, per-row 46,18, per-group-of-128 31,08, NF4 24,55. Cùng bốn bit mỗi trọng số, nhưng chênh lệch mười lăm triệu lần giữa tệ nhất và tốt nhất.

Perplexity là một dụng cụ thô và battery còn thô hơn. Giữa NF4 và INT4 group-128, khoảng cách perplexity là 6,5 điểm và battery khác một câu hỏi — và khoảng tin cậy của Chương 4 nói rằng một câu trong mười sáu không phân biệt được gì. Có một minh chứng sắc hơn cả khoảng đó: chạy cùng battery với stock repetition penalty của model tắt đi, đúng nghĩa greedy decoding, và hai hàng đó đổi chỗ. Một câu trong mười sáu không phải hiệu ứng nhỏ, mà là không có hiệu ứng. Cảnh báo của Chương 8 cũng áp dụng: perplexity chỉ so sánh được giữa các model dùng chung tokenizer, nên một con số từ bài viết của người khác không thể so với của bạn.

Cột đồng ý là sắc nhất trong ba cột, và gần như miễn phí: chạy model full-precision greedily, rồi hỏi model lượng tử hóa, ở mỗi vị trí, nó sẽ chọn gì với cùng prefix. Nó có 144 quan sát độc lập thay vì 16, không cần ground truth, và suy giảm mượt nơi battery suy giảm theo bậc. Nó cũng chính xác là đại lượng phần tiếp theo cần.

Đây là lời hứa Chương 1 đã đưa ra về chương này, đến đúng hẹn: toán học nói model 4-bit là có thể, còn kỹ thuật quyết định nó có dùng được hay không.

Chương 12 đã công bố điều này và để hóa đơn ở đây.

Ý tưởng đi thẳng từ tách biệt prefill/decode. Xác minh một chuỗi $\gamma$ token được đề xuất tốn một forward pass trên $\gamma$ vị trí — một phép nhân ma trận-ma trận, hầu như không đắt hơn pass trên một vị trí. Vì vậy:

Phân phối output không đổi. Với greedy decoding điều đó hiển nhiên — một token chỉ được chấp nhận nếu target sẽ sinh nó. Với sampling cần một quy tắc chấp nhận đã sửa đổi, và Leviathan et al. chứng minh phân phối kết quả đúng bằng phân phối của target.¹⁰ Đây là tối ưu chính xác thứ hai trong chương này.

Vì vậy mọi thứ phụ thuộc vào acceptance rate $\alpha$, thứ đo được — nó là cột đồng ý ở trên, đó là lý do nó được tính ở đó. Dùng từng model lượng tử hóa làm draft cho target full-precision, trên 144 vị trí được sinh:

Số token được chấp nhận kỳ vọng mỗi verification pass, với độ dài draft $\gamma$, là

và speedup ròng chia con số đó cho chi phí riêng của draft, một phần $c$ của target mỗi token:

Mục in đậm là điều cần nhớ: speculative decoding có thể làm generation chậm hơn. Ở acceptance 30 % với draft tốn một phần năm target, bạn trả tiền cho năm forward pass và giữ 1,4 token. Cột cuối là cái bẫy còn lại — draft dài hơn chỉ giúp khi acceptance cao, vì đuôi của một dự đoán $\gamma$ token hầu như không bao giờ được chạm tới. Ở acceptance 90 %, $\gamma = 8$ đáng 3,40x và ở 30 % nó đáng 0,79x: cùng một cấu hình, thắng hay thua tùy vào một con số đo trên traffic của bạn.

Quantization thu nhỏ một model bằng cách lưu cùng một hàm trong ít bit hơn. Distillation thu nhỏ nó bằng cách train một model nhỏ hơn bắt chước một model lớn hơn¹¹ — một ý tưởng có trước deep learning gần một thập kỷ.¹²

Phần tinh tế là cái gì student học từ đó. Không phải đáp án đúng: nó đã có thể được train trực tiếp trên đáp án đó. Điều teacher thêm vào là toàn bộ phân phối. Hỏi model thứ gì theo sau một cụm từ và nhìn qua argmax:

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

Hard label nói jug và không gì khác. Soft label nói jug, và cũng nói rằng cup gần như tốt bằng, bowl hợp lý, và large — một tính từ, một tiếp nối ngữ pháp hoàn toàn khác — vẫn còn sống. Đó là lập luận gốc: đây là số 7, nhưng nó trông khá giống số 1, và sự giống nhau là thông tin mà hard label vứt đi.

Đó cũng là lý do distillation dùng temperature. Chia logits cho $T$ trước softmax làm phẳng phân phối và nâng trọng số tương đối của các lựa chọn bám sát: trên cụm từ này, tỷ lệ giữa token top và token thứ ba giảm từ 2,24 ở $T = 1$ xuống 1,50 ở $T = 2$ — căn bậc hai của số đầu, đúng như việc chia logits cho hai làm với một tỷ lệ. Cùng thứ tự, nhưng nhiều attention của loss hơn đặt vào các near miss. Gradient của student mang sự bất định của teacher chứ không chỉ phán quyết của nó.

Mọi thứ trong chương này giờ là một tổng:

trong đó $T$ là tổng token thường trú trên tất cả request đồng thời. Áp dụng nó: các hàng 7B và 70B giả định 8 key-value head dimension 128, hàng 13B dùng full multi-head attention với 40 head, đúng cách các thế hệ model đó được xây — và điều đó lộ ra.

8 GB

16 GB

24 GB

Nhìn hàng 13B trong bảng 8 GB. Trọng số vừa — 6,2 GB trên 8 — nên theo cách nói thông thường, một model 13B "chạy trên card 8 GB". Nó có 337 token context, không phải một cuộc trò chuyện mà chỉ vừa đủ một prompt. "Nó có vừa không" là câu hỏi sai. Câu đúng là "với bao nhiêu context, và cho bao nhiêu user cùng lúc".

Cũng hãy nhìn hai hàng int8 trong bảng 16 GB. 7B có 65.378 token và 13B có 3.136 — chênh lệch hai mươi lần từ 5,6 GB trọng số thêm, vì 13B ở đây có multi-head attention và cache của nó tốn 800 KB mỗi token so với 128 KB của 7B. Hai model kích thước tương tự, một cái không dùng được cho context dài, vì một lý do không xuất hiện trong headline của model card nào.

Mười ba chương trước, đây là một perceptron với hai trọng số và một bias. Giờ nó là một transformer đã được thiết kế, train, aligned, học cách tiêu compute cho câu hỏi khó, và được serve với chi phí đo được trên mỗi token — không còn hộp nào bên trong chưa mở.

Chuyện kết thúc ở đây, và kết thúc có chủ ý.

Chương 14 bắt đầu với model ở một nơi khác. Không trong process của bạn, không trong memory của bạn, không trong một biến bạn có thể print: trên một máy bạn không quản trị, sau một API key, một port và một hóa đơn. Mọi thứ được đo ở đây vẫn đang xảy ra — prefill vẫn chạy trước token đầu tiên, cache vẫn lớn lên theo cuộc trò chuyện, batch bạn đang ở vẫn thuộc về người khác và vẫn quyết định latency của bạn — nhưng từ giờ trở đi bạn quan sát nó qua một stream Server-Sent Events, một finish_reason, và một HTTP 429 với header Retry-After. Các câu hỏi thay đổi theo điểm nhìn: không phải gradient này được tính thế nào mà là vì sao hóa đơn của tôi tăng gấp ba. Ngôn ngữ cũng thay đổi, và Chương 14 giải thích quy tắc đó thay vì tuyên bố nó — đến đây code giữ trọng số, gradients, logits và byte tokenizer; từ đó trở đi nó giữ một kết nối, một retry, một cancellation và state tích lũy. Mười ba chương phía sau bạn không bị vứt bỏ khi băng qua ranh giới. Chúng là mô tả của thứ đang chạy ở phía bên kia port.

Có hai phần lược bỏ có chủ ý. FlashAttention (Dao et al., arXiv:2205.14135) không phải một attention khác — nó tính cùng một hàm bằng cách chia tile phép toán để ma trận score $n \times n$ không bao giờ được ghi ra memory, đó là lý do 67 MB trong bảng thứ hai của chương này trong thực tế nhỏ hơn phép tính gợi ý. Và bản thân các kernels được giao lại: bài giảng 10 của CS336 Stanford bao phủ inference systems ở độ sâu mà chương này không cố làm, còn repository llama.cpp và đặc tả GGUF là nguồn chính cho phía CPU.