Lab tổng hợp · 13 khối

Lab tổng hợp Inference Engineering · theo dõi một yêu cầu từ cổng tiếp nhận đến lúc dừng bằng NumPy

Chạy bằng NumPy một đường ống phục vụ LLM thu nhỏ để theo dõi bằng số thật một yêu cầu từ cổng tiếp nhận, lập lịch, prefill, KV cache, decode, lấy mẫu đến các số đo TTFT, TPOT và throughput.

LESSON ID inference-end-to-end-lab GROUP Bài Lab tổng hợp

1Định nghĩa

Bài Lab tổng hợp này cho bạn chạy thử, bằng NumPy ngay trong trình duyệt, toàn bộ đường đi của một yêu cầu trong hệ thống phục vụ mô hình ngôn ngữ lớn (LLM, large language model): yêu cầu chạm cổng tiếp nhận, được cắt thành token (mảnh văn bản nhỏ mà mô hình xử lý), được xếp lịch, rồi được tính để sinh từng token trả lời cho đến khi dừng. Mỗi khối trong lab mang đúng tên một khối trên sơ đồ kiến trúc ở Tab 01, nên bạn nhìn thấy dữ liệu đi qua từng khối thay vì chỉ đọc mô tả rời rạc.

Cơ chế chạy như sau: năm yêu cầu A đến E đi vào một engine mô phỏng; bộ lập lịch theo vòng lặp cho yêu cầu vào chạy khi có chỗ trống, prefill xử lý cả prompt một lần và ghi key, value của từng token vào KV cache phân trang, rồi ở mỗi bước decode nhận một token mới và lấy mẫu token kế tiếp. Thời gian (TTFT là thời gian tới token đầu tiên, TPOT là thời gian trung bình giữa hai token liền sau, throughput là số token sinh ra mỗi giây) được đọc trên một đồng hồ mô phỏng theo công thức giả định, còn token, byte, số block và sai số là kết quả tính thật. Vì vậy lab kiểm chứng tính đúng của cơ chế, không đo tốc độ của GPU (chip tính toán chạy mô hình) thật.

Ví dụ đời thường: Lab giống một quầy gọi món giờ cao điểm. Nhân viên ở cửa nhận hoặc từ chối khách khi quầy đã đầy (cổng), ghi món thành mã số (tokenizer), bếp trưởng quyết định món nào lên bếp ở mỗi lượt (bộ lập lịch), đầu bếp sơ chế cả đơn rồi nấu từng món một (prefill rồi decode), kệ giữ phần nguyên liệu đã sơ chế để món sau khỏi sơ chế lại (KV cache) và bảng điện tử ghi thời gian chờ của từng bàn (telemetry). Phép so sánh dừng lại ở chỗ thời gian trong lab là con số giả định, không phải thời gian của một nhà bếp thật.

2Luồng

Sơ đồ luồng (13 bước)

1 · Gateway & admission
Nhận A, B, E, C và từ chối D bằng mã 429 vì hệ thống đã có 3 yêu cầu, bằng giới hạn 2 chạy cộng 1 chờ.
2 · Input preparation
BPE 10 phép gộp, từ vựng 22 token; C thành 9 token ID và E bị chặn mã 400 vì 8 cộng 30 vượt 24.
3 · Iteration scheduler
12 bước; A chạy một mình lúc 0.50 ms, prompt của C chia thành hai đoạn 5 và 4 và C chờ chỗ chạy 14.55 ms mô phỏng.
4 · Prefill
9 token của C ghi K và V có shape 2, 9, 4; hàng cuối có 22 logits và token đầu xuất hiện lúc 23.00 ms, TTFT 22.00 ms mô phỏng.
5 · Transformer × N layers
Trọng số attention của token cuối có 9 phần tử và tổng bằng 1; logits là 22 điểm số khác; kết quả qua cache khớp tính lại trong 1e-9.
6 · KV state manager
Cao điểm 7 trên 12 block, A giữ 0, 1, 5 và B giữ 2, 3, 4, 6; C dùng lại block 3, 4, 6 của B; cuối còn đủ 12 block trống.
7 · Decode
C có 1 token từ prefill và 3 bước decode; dùng cache chỉ tính 41 vị trí, tính lại cả lịch sử cần 197 vị trí.
8 · Logits → sampling → stop check
Softmax với temperature 0.8 cho d 0.260 và eos 0.152; lọc top-k và top-p giữ 5 token, rút ra o; C dừng vì eos sau 4 token.
9 · KV / weight precision
8 ma trận trọng số xuống INT8: 3264 byte còn 1192 byte, sai số khôi phục 0.0056 trong nửa scale 0.0061.
10 · HBM memory budget
128 byte KV mỗi token trong lab; cấu hình mẫu 32 lớp, 4096 token, 8 KV head, head 128, FP16 cần 0.50 GiB mỗi chuỗi.
11 · Telemetry & capacity feedback
TTFT của C = 0.65 chuẩn bị + 14.55 chờ chỗ chạy + 6.80 prefill = 22.00 ms; thành phần lớn nhất là chờ chỗ chạy.
12 · Benchmark & SLO methodology
Token giống hệt giữa ba chính sách lập lịch; TTFT trung bình và khoảng đứng lớn nhất (ms mô phỏng): không chia prompt 10.00 và 6.00, chia đoạn 12.67 và 3.60, static 12.48 và 1.20.
13 · Quality gates & rollout
Bản INT8 khớp 40 trên 40 quyết định top-1 của bản gốc; quyết định sát nhất chênh 0.0304 ở bản gốc và 0.0326 ở bản INT8.

Mã Mermaid

flowchart TD
  step1["1 · Gateway #amp; admission"]
  step2["2 · Input preparation"]
  step3["3 · Iteration scheduler"]
  step4["4 · Prefill"]
  step5["5 · Transformer × N layers"]
  step6["6 · KV state manager"]
  step7["7 · Decode"]
  step8["8 · Logits → sampling → stop check"]
  step9["9 · KV / weight precision"]
  step10["10 · HBM memory budget"]
  step11["11 · Telemetry #amp; capacity feedback"]
  step12["12 · Benchmark #amp; SLO methodology"]
  step13["13 · Quality gates #amp; rollout"]
  step1 --> step2
  step2 --> step3
  step3 --> step4
  step4 --> step5
  step5 --> step6
  step6 --> step7
  step7 --> step8
  step8 --> step9
  step9 --> step10
  step10 --> step11
  step11 --> step12
  step12 --> step13

Cách đọc: một yêu cầu đi từ khối 1 đến khối 8 theo đúng thứ tự thời gian của nó (cổng, chuẩn bị đầu vào, xếp lịch, prefill, tính một lớp, ghi cache, decode, lấy mẫu và dừng). Các khối 9 đến 13 là khối đi kèm: nén trọng số, ngân sách bộ nhớ, số đo, so sánh chính sách và cổng chất lượng; chúng dùng lại dữ liệu của engine chứ không phải bước tiếp theo của một yêu cầu. Mọi số lấy nguyên văn từ inference-end-to-end.py (seed 7), trừ số ms là kết quả trên đồng hồ mô phỏng.

3Giải pháp

Một yêu cầu gửi tới LLM không đi thẳng vào mô hình. Văn bản người dùng gửi (gọi là prompt) phải qua cổng tiếp nhận, được đổi thành token (mỗi token có một số thứ tự gọi là token ID), được xếp lịch cùng các yêu cầu khác rồi mới được tính. Mỗi khối có thể làm yêu cầu chậm đi hoặc bị từ chối, nên đọc từng bài riêng rất khó thấy chúng nối nhau ra sao. Lab gom 13 khối vào một đường ống để bạn theo dõi một yêu cầu cụ thể, tên là C, và thấy vì sao nó mất 22.00 ms mô phỏng mới nhận được token đầu tiên.

Đầu vào là một trace (danh sách các yêu cầu cùng thời điểm đến) gồm năm yêu cầu, đến vào những thời điểm khác nhau trên đồng hồ mô phỏng: A (xin chao model, được sinh tối đa 10 token, mỗi bước chọn token có điểm cao nhất, gọi là greedy), B (model hoc token, chọn token ngẫu nhiên có kiểm soát), E (xin chao ban nhưng xin sinh tới 30 token), C (ban hoc model, yêu cầu được theo dõi) và D (xin chao token). Engine có 2 chỗ chạy cùng lúc và 1 chỗ chờ; mỗi bước xử lý tối đa 6 token; KV cache gồm 12 block, mỗi block chứa 4 token; một chuỗi dài tối đa 24 token. Mô hình là một lớp decoder với 2 head attention (mỗi head là một nhóm tính attention độc lập, có K và V riêng), kích thước ẩn 8 và bảng từ vựng 22 token. Trọng số ngẫu nhiên với seed 7 nên chạy lại ra cùng số, nhưng chưa huấn luyện nên văn bản sinh ra không có nghĩa.

Đi theo từng khối. Ở khối 1, cổng chỉ cho tối đa 3 yêu cầu có mặt trong hệ thống; D đến khi đã có 3 yêu cầu nên nhận mã từ chối 429. Ở khối 2, văn bản đổi thành token: E qua được cổng nhưng bị chặn mã 400 vì prompt 8 token cộng 30 token xin sinh là 38, vượt giới hạn 24. Ở khối 3, bộ lập lịch quyết định mỗi bước chạy việc gì: A chạy một mình lúc 0.50 ms vì B còn đang chuẩn bị đầu vào, và prompt 9 token của C được chia thành hai đoạn 5 và 4 để không chiếm trọn một bước. Khối 4 là prefill, tức xử lý cả prompt một lần và ghi key (K) cùng value (V) của từng token vào cache; hàng cuối của kết quả là 22 điểm số (logits), mỗi điểm cho một token ứng viên.

Khối 5 nhắc một điều rất dễ nhầm: trọng số attention và xác suất từ vựng là hai phân phối khác nhau. Với token cuối của prompt C, mỗi head chia trọng số cho 9 vị trí đã có, tổng bằng 1, để cho biết lấy thông tin từ đâu. Chỉ sau khi qua phần còn lại của lớp và lớp LM head mới có 22 logits trên token ứng viên, và phải đến khối 8 logits mới được đổi thành xác suất. Khối 6 cho thấy KV cache không nằm trong một mảng liền: mỗi chuỗi có một bảng block nối block logic với block vật lý, ví dụ lúc cao điểm A giữ các block 0, 1, 5 còn B giữ 2, 3, 4, 6; khi B xong, block 3, 4 và 6 được C dùng lại. Khối 7 là vòng decode: mỗi bước chỉ đưa vào một token mới và đọc lại K, V cũ từ cache, nên cả lab chỉ phải tính 41 vị trí thay vì 197 vị trí nếu mỗi bước tính lại toàn bộ lịch sử. Đây là số vị trí phải tính, chưa phải thời gian tiết kiệm được.

Khối 8 biến logits của C thành xác suất bằng softmax (phép đổi một dãy điểm số thành dãy không âm có tổng bằng 1) sau khi chia cho temperature 0.8 (temperature nhỏ hơn 1 làm phân phối nhọn hơn): token d có xác suất cao nhất, 0.260, còn eos có 0.152. Bộ lọc top-k = 5 (chỉ giữ 5 token điểm cao nhất) và top-p = 0.9 (giữ nhóm nhỏ nhất có tổng xác suất đủ 0.9) còn lại 5 token, được chuẩn hóa lại để tổng bằng 1, rồi rút ra token o. Sau mỗi token, engine kiểm tra điều kiện dừng: C dừng vì gặp eos (token báo kết thúc) sau 4 token. Khối 9 nén 8 ma trận trọng số xuống số nguyên 8 bit (INT8) với một hệ số tỉ lệ (scale) cho từng cột; dung lượng tính trên định dạng giảm từ 3264 byte (nếu lưu bằng số thực 32 bit, FP32) còn 1192 byte, sai số khôi phục trọng số lớn nhất 0.0056, nằm trong nửa scale là 0.0061. Khối 10 lập ngân sách cho HBM (bộ nhớ băng thông cao gắn trên GPU): mỗi token cần 128 byte K và V trong lab; với cấu hình mẫu 32 lớp, 4096 token, 8 KV head, mỗi head 128 chiều, số thực 16 bit (FP16), một chuỗi cần 0.50 GiB.

Khối 11 đến 13 đọc kết quả. TTFT (time to first token, thời gian từ lúc yêu cầu đến tới token đầu tiên) của C là 22.00 ms mô phỏng, gồm 0.65 ms chuẩn bị đầu vào, 14.55 ms chờ chỗ chạy và 6.80 ms prefill. Thành phần lớn nhất là chờ chỗ chạy, nên muốn giảm TTFT của C thì phải nhìn vào hàng đợi chứ không phải vào prefill. TPOT (time per output token) là khoảng cách trung bình giữa các token sau token đầu; throughput là số token sinh ra trên mỗi giây. Khối 12 chạy cùng một trace với ba chính sách lập lịch và thấy token sinh ra giống hệt nhau, chỉ thời gian khác: không chia prompt cho TTFT trung bình 10.00 ms nhưng có lúc một yêu cầu đang decode phải đứng 6.00 ms, còn chia đoạn cho 12.67 ms và khoảng đứng chỉ 3.60 ms. Khối 13 so token được chọn của bản gốc với bản INT8 trên cùng ngữ cảnh và thấy khớp cả 40 quyết định.

Giới hạn của kết luận: mọi số ms đến từ đồng hồ mô phỏng với chi phí giả định, nên chúng không cho biết GPU thật nhanh bao nhiêu; chỉ số token, byte, block và sai số là kết quả tính thật. Ba yêu cầu được phục vụ chưa đủ để nói về p95 hay p99 (giá trị mà 95% hoặc 99% yêu cầu không vượt quá). Con số 40 trên 40 của cổng chất lượng chỉ cho thấy bản INT8 chọn cùng token trong 40 trường hợp của một mô hình ngẫu nhiên, không nói gì về chất lượng ngôn ngữ. Router, xác thực, hủy yêu cầu, prefix cache, preemption, mô hình nhiều lớp và nhiều GPU không được mô phỏng.

4Profiling

Kiểm tra tính đúng trước khi nói tới tốc độ
Trước khi đọc bất kỳ con số thời gian nào, hãy xem hai phép kiểm tra số học. Một: logits tính qua KV cache khớp logits tính lại cả chuỗi từ đầu ở mọi bước prefill và decode của cả ba yêu cầu, với sai lệch lớn nhất không vượt 1e-9 (phần dư chỉ là sai số làm tròn). Hai: K và V gom từ các block rời rạc khớp K và V tính lại từ đầu, cũng trong ngưỡng 1e-9. Ngoài ra, ba chính sách lập lịch phải cho cùng token cho mọi yêu cầu chạy ở cả ba chính sách. Ba điều này chứng minh cache, block và lập lịch không làm đổi nội dung; chúng không chứng minh lab chạy nhanh hơn.
Đọc TTFT, TPOT và throughput trên đồng hồ mô phỏng
Workload là cùng một trace năm yêu cầu, ba yêu cầu được phục vụ, cùng seed và cùng công thức chi phí; baseline là chính sách static (đợi đủ nhóm rồi chạy hết nhóm). Với mỗi yêu cầu, hãy đọc TTFT = thời điểm token đầu trừ thời điểm đến, TPOT = (thời điểm token cuối trừ thời điểm token đầu) chia số khoảng cách, và phân rã TTFT thành chuẩn bị đầu vào, chờ chỗ chạy, prefill để biết nút thắt. Khi so ba chính sách, đọc cả cột khoảng đứng lớn nhất giữa hai token liền kề, vì TPOT trung bình có thể che một lần đứng lâu. Sai khác giữa các chính sách là hệ quả của công thức chi phí giả định trên 3 yêu cầu; đổi trace hoặc hằng số COST có thể đổi thứ hạng, nên đừng viết chúng thành tốc độ của hệ thống thật.
Đo áp lực bộ nhớ KV
Đọc cột KV theo từng bước ở khối 11 và dòng cao điểm ở khối 6: lúc dùng nhiều nhất là 7 trên 12 block, tức 28 chỗ token để lưu 24 token, còn cấp một mảng liền 24 token cho mỗi chỗ chạy sẽ cần 48 chỗ. Phần thừa 4 chỗ là phần cuối của block chưa đầy. Trên GPU thật, hãy đo bộ nhớ đỉnh với đúng workload; công thức ở khối 10 chỉ cho phần KV, chưa gồm trọng số và vùng làm việc.
Phân biệt sai số số học với thay đổi quyết định
Sai số logits giữa bản gốc và bản INT8 lớn nhất ở C là 0.0385, nhưng điều ảnh hưởng đến đầu ra là liệu hai token đứng đầu có đảo thứ tự không. Quyết định sát nhất của lab (prompt B, bước 6) có chênh lệch 0.0304 ở bản gốc và 0.0326 ở bản INT8, nên token được chọn giữ nguyên dù sai số logits lớn nhất của B là 0.1317. Hãy luôn báo cả sai số lẫn tỉ lệ quyết định đổi, và nhớ rằng 40 quyết định của mô hình ngẫu nhiên không thay cho bộ đánh giá nhiệm vụ thật.

Mẹo đo lường: ghim số liệu trên workload thật, ghi cả p50/p95/p99 thay vì chỉ trung bình, và luôn ghi lại điều kiện chạy (batch, cache, đồng thời, phần cứng) trước và sau khi tối ưu. Số đo thiếu điều kiện chạy thì không so sánh được.

5Ví dụ

Vì sao C chờ tới 14.55 ms mà không vào chạy sớm hơn?

Hãy dự đoán trước: C đến lúc 1.00 ms và chuẩn bị xong lúc 1.65 ms, vậy điều gì giữ nó lại? Mở khối 3 và đọc từng bước. Hai chỗ chạy đang do A và B giữ. B kết thúc ở bước 7 (lúc 16.20 ms) vì gặp eos sau 4 token, nên C mới có chỗ ở bước 8. Quan sát này suy ra từ số liệu: 16.20 ms trừ 1.65 ms bằng 14.55 ms. Tự kiểm tra: nếu một trong hai yêu cầu đang chạy xong sớm hơn thì C chờ ít hơn hay nhiều hơn? Đối chiếu: ít hơn hoặc bằng, vì C lấy chỗ trống đầu tiên; phần chờ chỗ chạy trong TTFT phụ thuộc vào lúc có chỗ trống đầu tiên, tức vào độ dài các yêu cầu đứng trước, chứ không phụ thuộc vào độ dài prompt của C.

Một token, hai phân phối khác nhau

Mở khối 5 và khối 8 cho cùng yêu cầu C. Ở khối 5, token cuối của prompt (vị trí 8) nhìn lại 9 vị trí và head 0 chia trọng số [0.109, 0.141, 0.080, 0.146, 0.128, 0.100, 0.072, 0.102, 0.121], tổng bằng 1: nó nhìn nhiều nhất vị trí 3. Ở khối 8, cùng token đó cho ra 22 logits; softmax với temperature 0.8 đổi chúng thành xác suất trên 22 token, trong đó d có 0.260 và eos có 0.152. Hai dãy có cùng tính chất tổng bằng 1 nhưng trả lời hai câu hỏi khác nhau: dãy đầu là lấy thông tin từ vị trí nào, dãy sau là chọn token nào. Tự kiểm tra: dãy nào có 9 phần tử và dãy nào có 22? Đối chiếu: attention có 9 phần tử vì prompt có 9 vị trí; xác suất có 22 phần tử vì từ vựng có 22 token.

Đổi QUANT_BITS từ 8 thành 4 và đọc lại cổng chất lượng

Dự đoán: nén xuống 4 bit làm sai số lớn hơn nhiều; liệu token được chọn có bắt đầu đổi không? Sửa dòng QUANT_BITS = 4 ở đầu file rồi bấm Chạy. Kết quả đã chạy với cấu hình này: sai số khôi phục trọng số lớn nhất 0.1000 (so với 0.0056 ở 8 bit), sai số logits của C là 1.2911, và cổng chất lượng khớp 33 trên 40 quyết định, tức 82.5%, thấp hơn ngưỡng giả định 95% nên báo KHÔNG ĐẠT. Dung lượng định dạng chỉ giảm thêm từ 1192 xuống 784 byte. Kết luận: giảm bit đổi bộ nhớ lấy sai số, và cổng chất lượng là chỗ phát hiện cái giá đó; ngưỡng 95% và 40 quyết định chỉ là giả định để minh họa.

6Thuật ngữ

TTFT (time to first token): Thời gian từ lúc yêu cầu đến tới lúc token đầu tiên được sinh. Trong lab, TTFT của C = chuẩn bị đầu vào + chờ chỗ chạy + prefill, tính trên đồng hồ mô phỏng.
TPOT (time per output token): Khoảng cách trung bình giữa hai token liền nhau sau token đầu tiên, bằng (thời điểm token cuối trừ thời điểm token đầu) chia số khoảng cách.
Đồng hồ mô phỏng: Bộ đếm thời gian do công thức chi phí giả định (COST) tạo ra thay cho GPU thật. Các số ms của lab chỉ có ý nghĩa so sánh trong chính lab, không phải tốc độ phần cứng.
Bảng block (block table): Bảng tra của một chuỗi, nối block logic 0, 1, 2... với block vật lý trong bể KV; hai chuỗi có thể xen kẽ block vật lý và block được trả sẽ cấp lại cho chuỗi khác.
Cổng chất lượng (quality gate): Phép kiểm tra tự động quyết định có chấp nhận một thay đổi hay không; trong lab là tỉ lệ quyết định top-1 phải giữ nguyên giữa bản gốc và bản INT8 so với ngưỡng giả định 95%.

Glossary (6)

Token ID: Số thứ tự của một token trong bảng từ vựng; mô hình dùng số này để tra vector nhúng, bản thân số chưa mang ý nghĩa.
Trọng số attention: Phân phối softmax trên các vị trí đã thấy, cho biết một token lấy thông tin từ vị trí nào; khác với xác suất chọn token kế tiếp.
Logits: Điểm số chưa chuẩn hóa của mọi token trong từ vựng ở một vị trí; softmax đổi chúng thành xác suất.
Continuous batching: Cách lập lịch nhận yêu cầu mới vào ở ranh giới từng bước ngay khi có chỗ trống, thay vì đợi cả nhóm cũ xong.
Chunked prefill: Chia một prompt dài thành các đoạn và xử lý dần qua nhiều bước để các yêu cầu đang decode không phải đứng chờ quá lâu.
Lượng tử hóa đối xứng theo kênh: Lưu mỗi cột trọng số bằng số nguyên cùng một hệ số tỉ lệ riêng của cột đó, scale = max|w| chia cho mức lớn nhất của số nguyên.

7Bài liên quan

Cổng tiếp nhận và kiểm soát yêu cầu Chuyển văn bản thành đơn vị mà mô hình hiểu Lập lịch tính toán theo từng bước sinh token Xử lý prompt trước khi bắt đầu sinh câu trả lời Mô hình transformer biến token thành dự đoán như thế nào Bộ nhớ đệm key và value của attention Sinh câu trả lời theo vòng lặp token Chọn token từ điểm số và xuất văn bản Dùng ít bit hơn để lưu và tính các giá trị của mô hình Lập ngân sách bộ nhớ trên accelerator Theo dõi và tìm nguyên nhân request chậm Thiết kế phép đo để so giải pháp công bằng Kiểm tra tính đúng và chất lượng sau tối ưu

8Nguồn

Efficient Memory Management for Large Language Model Serving with PagedAttention (Kwon và cộng sự, 2023) Orca: A Distributed Serving System for Transformer-Based Generative Models (OSDI 2022) Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve (2024)

9Bài lab

Theo dõi một yêu cầu qua 13 khối của đường ống phục vụ LLM bằng NumPy

Thực hành NumPy · đường ống phục vụ LLM thu nhỏ (13 khối)

Đọc phần hướng dẫn rồi bấm Chạy. Mỗi khối [n · Tên] khớp một khối trên sơ đồ kiến trúc ở Tab 01; hãy đọc dòng Quan sát, đối chiếu các con số, rồi mới đọc Kết luận.

Bạn sẽ học được gì?

Sau bài lab, bạn giải thích được bằng số cụ thể chín điều: (1) vì sao cổng từ chối một số yêu cầu ngay từ đầu; (2) văn bản trở thành token ID như thế nào và vì sao có yêu cầu bị chặn vì quá ngân sách; (3) bộ lập lịch chọn việc cho mỗi bước ra sao; (4) prefill khác decode ở đâu; (5) trọng số attention khác xác suất từ vựng thế nào; (6) KV cache phân trang dùng bảng block ra sao; (7) logits trở thành xác suất, rồi token, rồi quyết định dừng như thế nào; (8) TTFT, TPOT và throughput gồm những phần nào; (9) nén trọng số xuống INT8 đổi bộ nhớ lấy sai số ra sao và cách kiểm tra.

Bạn không cần biết trước về LLM. Mỗi thuật ngữ được giải thích ở chỗ nó xuất hiện đầu tiên; bạn chỉ cần đọc được Python và biết một mảng NumPy có shape, ví dụ (2, 9, 4) là 2 nhóm, mỗi nhóm 9 hàng, mỗi hàng 4 số.

Đầu vào và cấu hình thu nhỏ của bài lab

Đầu vào là năm yêu cầu (request: một lời gọi gửi văn bản tới mô hình để nhận trả lời). A "xin chao model" đến 0.00 ms, tối đa 10 token sinh ra, greedy. B "model hoc token" đến 0.00 ms, tối đa 7 token, lấy mẫu T = 0.8, top-k = 4, top-p = 0.9. E "xin chao ban" đến 0.50 ms nhưng xin tới 30 token. C "ban hoc model" đến 1.00 ms, tối đa 8 token, lấy mẫu T = 0.8, top-k = 5, top-p = 0.9; đây là yêu cầu được theo dõi qua mọi khối. D "xin chao token" đến 1.50 ms, greedy. Thời điểm đến tính trên đồng hồ mô phỏng; mỗi yêu cầu có seed riêng nên lấy mẫu lặp lại được.

Cấu hình thu nhỏ: 2 chỗ chạy cùng lúc và 1 chỗ chờ (SLOTS = 2, QUEUE_LIMIT = 1); mỗi bước tối đa 6 token (TOKEN_BUDGET = 6); KV cache có 12 block, mỗi block 4 token; một chuỗi tối đa 24 token. Mô hình có một lớp, 2 head attention (MHA, multi-head attention: mỗi head có K và V riêng) với mỗi head 4 chiều, d_model = 8 (chiều của vector ẩn), RoPE (mã hóa vị trí bằng phép xoay) và SwiGLU (mạng feed-forward có cổng) là hai chi tiết của lớp mà bạn chỉ cần biết là có mặt, bảng từ vựng 22 token (gồm token bắt đầu bos và token kết thúc eos), trọng số ngẫu nhiên seed 7. Token của lab do một bộ BPE (byte pair encoding: gộp dần cặp ký tự hay gặp) 10 phép gộp học từ 5 câu mẫu. Đồng hồ mô phỏng dùng các hằng số COST giả định (đơn vị micro-giây) ở đầu file.

Bảng ánh xạ giữa sơ đồ Tab 01 và 13 khối của lab

Khối 1 Gateway & admission = hàm admit; khối 2 Input preparation = train_bpe và encode; khối 3 Iteration scheduler = vòng lặp chính của run_engine (nhận yêu cầu, chọn việc mỗi bước, chia prompt theo TOKEN_BUDGET); khối 4 Prefill và khối 7 Decode = hai nhánh task của run_engine; khối 5 Transformer × N layers = hàm forward (attention, RoPE, SwiGLU, LM head); khối 6 KV state manager = lớp KVPool.

Khối 8 Logits → sampling → stop check = hàm sample và điều kiện dừng trong emit; khối 9 KV / weight precision = quantize_weights; khối 10 HBM memory budget = phép tính byte trên KVPool và công thức mẫu; khối 11 Telemetry & capacity feedback, khối 12 Benchmark & SLO methodology = metrics và summary; khối 13 Quality gates & rollout = greedy_teacher_forced. Tên khối trong output khớp tên khối hoặc năng lực trên sơ đồ.

Cách thực hiện và đọc từng khối output

1. Trước khi bấm Chạy, hãy dự đoán: trong năm yêu cầu, yêu cầu nào bị từ chối và vì sao? C sẽ phải chờ lâu hay không? Viết dự đoán ra giấy.

2. Bấm Chạy. Ở khối 1 và 2, đối chiếu dự đoán: D nhận 429 vì lúc xét đã có 3 yêu cầu trong hệ thống; E qua cổng nhưng bị chặn 400 vì 8 + 30 = 38 lớn hơn 24. Ở khối 3, đọc từng dòng bước: p là prefill một đoạn prompt, d là decode một token; tìm bước mà một yêu cầu đang decode dùng chung bước với prefill của yêu cầu khác.

3. Ở khối 4 đến 7, theo dõi C: shape (2, 9, 4) của K nghĩa là 2 head, 9 token, 4 số mỗi vị trí; so hai dãy số của khối 5 và khối 4 (trọng số attention có 9 phần tử và tổng bằng 1; logits có 22 phần tử và tổng không bằng 1); đọc bảng block của khối 6 và tìm block được dùng lại; so 41 với 197 ở khối 7 nhưng nhớ rằng đó là số vị trí, chưa phải thời gian.

4. Ở khối 8 đến 10, đọc xác suất trước và sau khi lọc của C, thấy token được rút và lý do dừng của từng yêu cầu; sau đó đọc dung lượng trước và sau INT8 và so sai số khôi phục với nửa scale.

5. Ở khối 11 đến 13, cộng ba thành phần của TTFT để kiểm tra đúng bằng tổng, tìm thành phần lớn nhất, rồi đọc bảng ba chính sách lập lịch và dòng quyết định sát nhất của cổng chất lượng. Cuối cùng, đối chiếu dự đoán ban đầu với kết quả và sửa các hằng số ở đầu file (xem bài tập) để thấy output thay đổi.

Kết quả này chứng tỏ điều gì và giới hạn ở đâu?

Các phép kiểm tra trong lab xác nhận, cho trace năm yêu cầu này: cache và bảng block cho cùng logits với tính lại toàn bộ (sai lệch không vượt 1e-9); số yêu cầu offered bằng served cộng rejected; mọi xác suất và mọi hàng attention có tổng bằng 1; mọi block được trả đủ khi các chuỗi kết thúc; đổi chính sách lập lịch không đổi token sinh ra.

Lab không chứng minh: tốc độ trên GPU thật (mọi số ms là đồng hồ mô phỏng giả định); chất lượng ngôn ngữ (trọng số ngẫu nhiên, văn bản vô nghĩa); p95 hay p99 (chỉ có ba yêu cầu được phục vụ); chất lượng của INT8 trên tác vụ thật (cổng chất lượng chỉ có 40 quyết định); và hành vi của router, xác thực, hủy yêu cầu, prefix cache, preemption hay nhiều GPU, vì các phần đó không được mô phỏng.

Kết quả mong đợiOutput gồm phần mở đầu, 13 khối đánh số 1 đến 13 và dòng TỔNG KẾT. Mốc kiểm tra nhanh: D bị từ chối 429 ở cổng và E bị từ chối 400 ở bước chuẩn bị đầu vào, còn A, B, C được phục vụ; prompt của C có 9 token, chia thành các đoạn [5, 4]; TTFT của C = 22.00 ms mô phỏng = 0.65 + 14.55 + 6.80; cao điểm KV dùng 7 trên 12 block; dùng cache phải tính 41 vị trí so với 197 nếu tính lại; C dừng vì eos sau 4 token; bản INT8 khớp 40 trên 40 quyết định; cuối cùng là dòng PASS.

Tải inference-end-to-end.py ↓

inference-end-to-end.pyPYTHON

"""Lab tổng hợp Inference Engineering: một đường ống phục vụ LLM thu nhỏ, chạy bằng NumPy thuần.

Năm yêu cầu A..E đi vào một "engine" mô phỏng. Mỗi yêu cầu có thể đi qua:
cổng tiếp nhận -> chuẩn bị đầu vào (BPE) -> bộ lập lịch theo vòng lặp (continuous
batching) -> prefill -> KV cache phân trang -> decode -> lấy mẫu -> dừng -> số đo.

Tên các khối [1]..[13] trùng với nhãn khối/hotspot trên sơ đồ kiến trúc của Tab 01.

Những gì là THẬT trong file này: mọi phép tính tensor (attention, RoPE, SwiGLU, logits),
mọi giá trị token được chọn, mọi số đếm byte/block, mọi sai số so sánh.
Những gì là GIẢ ĐỊNH: đồng hồ mô phỏng (xem COST_*), vì NumPy trong trình duyệt không có GPU.
Các số mili-giây in ra là đo trên đồng hồ mô phỏng đó, KHÔNG phải tốc độ của GPU thật.
Trọng số ngẫu nhiên có seed cố định, chưa huấn luyện: văn bản sinh ra không có nghĩa.
"""
import numpy as np

# ── Cấu hình thu nhỏ (mọi số đều nhỏ để in thẳng ra màn hình) ────────────────
SEED = 7                      # seed của trọng số mô hình
D_MODEL, N_HEADS, D_HEAD = 8, 2, 4          # MHA: mỗi head có K/V riêng
FFN_HIDDEN = 16
MAX_CONTEXT = 24              # tổng token tối đa của một chuỗi (prompt + sinh ra)
BLOCK_SIZE = 4                # số token trong một block KV
POOL_BLOCKS = 12              # số block vật lý trong "HBM" giả lập
SLOTS = 2                     # số chuỗi được chạy cùng lúc
QUEUE_LIMIT = 1               # số yêu cầu được xếp hàng chờ thêm ngoài SLOTS
TOKEN_BUDGET = 6              # số token tối đa xử lý trong một bước (chunked prefill)
BOS, EOS = 0, 1               # token đặc biệt: bắt đầu / kết thúc

# Đồng hồ MÔ PHỎNG (đơn vị micro-giây, số nguyên để không có sai số làm tròn). GIẢ ĐỊNH, không đo.
COST_GATEWAY = 200            # cổng: xác thực + kiểm tra hạn mức
COST_TOKENIZE_PER_TOKEN = 50  # CPU chuẩn bị đầu vào
COST_DECODE_FIXED = 1000      # đọc trọng số một lần cho cả bước decode (bị giới hạn băng thông)
COST_DECODE_PER_SEQ = 100
COST_PREFILL_FIXED = 500
COST_PREFILL_PER_TOKEN = 400  # prefill tính nhiều token cùng lúc (bị giới hạn tính toán)
TTFT_SLO = 8000               # ngưỡng TTFT GIẢ ĐỊNH để minh họa cảnh báo (8 ms mô phỏng)
QUANT_BITS = 8                # độ rộng bit của trọng số lượng tử hóa (thử đổi thành 4 ở bài tập)
QUALITY_GATE = 0.95           # ngưỡng GIẢ ĐỊNH: tỉ lệ quyết định top-1 phải giữ nguyên

CORPUS = ["xin chao model", "xin chao ban", "model hoc token", "ban hoc model", "xin chao token"]
N_MERGES = 10

# Mỗi yêu cầu: thời điểm đến (µs mô phỏng), văn bản, giới hạn sinh, cấu hình lấy mẫu, seed riêng.
REQUESTS = [
    dict(id="A", arrival=0, text="xin chao model", max_new=10, temperature=0.0, top_k=0, top_p=1.0, seed=1),
    dict(id="B", arrival=0, text="model hoc token", max_new=7, temperature=0.8, top_k=4, top_p=0.9, seed=2),
    dict(id="E", arrival=500, text="xin chao ban", max_new=30, temperature=0.0, top_k=0, top_p=1.0, seed=3),
    dict(id="C", arrival=1000, text="ban hoc model", max_new=8, temperature=0.8, top_k=5, top_p=0.9, seed=4),
    dict(id="D", arrival=1500, text="xin chao token", max_new=5, temperature=0.0, top_k=0, top_p=1.0, seed=5),
]
FOLLOW = "C"                  # yêu cầu được theo dõi chi tiết qua mọi khối

def ms(us):
    return f"{us / 1000:.2f} ms"

def vec(a, nd=3):
    return "[" + ", ".join(f"{x:.{nd}f}" for x in np.asarray(a, dtype=float).ravel()) + "]"

def say(code, title, lines):
    print(f"[{code}] {title}")
    for line in lines:
        print("   " + line)
    print()

# ── [2] Input preparation: BPE nhỏ học từ CORPUS ─────────────────────────────
def train_bpe(corpus, n_merges):
    words = [list(w) + ["</w>"] for text in corpus for w in text.split()]
    merges = []
    for _ in range(n_merges):
        counts = {}
        for w in words:
            for pair in zip(w, w[1:]):
                counts[pair] = counts.get(pair, 0) + 1
        if not counts:
            break
        pair = max(counts, key=lambda p: (counts[p], p))
        merges.append(pair)
        merged = "".join(pair)
        new_words = []
        for w in words:
            out, i = [], 0
            while i < len(w):
                if i + 1 < len(w) and (w[i], w[i + 1]) == pair:
                    out.append(merged)
                    i += 2
                else:
                    out.append(w[i])
                    i += 1
            new_words.append(out)
        words = new_words
    symbols = sorted({s for w in words for s in w} | {c for t in corpus for c in t.replace(" ", "")} | {"</w>"})
    return merges, symbols

MERGES, SYMBOLS = train_bpe(CORPUS, N_MERGES)
ID_TO_TOKEN = ["<bos>", "<eos>"] + SYMBOLS
TOKEN_TO_ID = {t: i for i, t in enumerate(ID_TO_TOKEN)}
VOCAB = len(ID_TO_TOKEN)

def bpe_word(word):
    tokens = list(word) + ["</w>"]
    for left, right in MERGES:
        i = 0
        while i < len(tokens) - 1:
            if (tokens[i], tokens[i + 1]) == (left, right):
                tokens[i:i + 2] = [left + right]
            else:
                i += 1
    return tokens

def encode(text):
    """Chat template tối giản: <bos> + các từ đã tách bằng BPE. Trả về (tokens, ids)."""
    tokens = ["<bos>"]
    for word in text.split():
        tokens += bpe_word(word)
    return tokens, [TOKEN_TO_ID[t] for t in tokens]

def detokenize(ids):
    pieces = [ID_TO_TOKEN[i] for i in ids if i not in (BOS, EOS)]
    return "".join(pieces).replace("</w>", " ").strip()

# ── Mô hình: một lớp decoder MHA + RoPE + SwiGLU (trọng số ngẫu nhiên, chưa học) ─
def make_weights():
    rng = np.random.default_rng(SEED)
    return {
        "E": rng.normal(0, 0.5, (VOCAB, D_MODEL)),
        "Wq": rng.normal(0, 0.4, (D_MODEL, N_HEADS * D_HEAD)),
        "Wk": rng.normal(0, 0.4, (D_MODEL, N_HEADS * D_HEAD)),
        "Wv": rng.normal(0, 0.4, (D_MODEL, N_HEADS * D_HEAD)),
        "Wo": rng.normal(0, 0.4, (N_HEADS * D_HEAD, D_MODEL)),
        "Wg": rng.normal(0, 0.4, (D_MODEL, FFN_HIDDEN)),
        "Wz": rng.normal(0, 0.4, (D_MODEL, FFN_HIDDEN)),
        "Wf": rng.normal(0, 0.3, (FFN_HIDDEN, D_MODEL)),
        "U": rng.normal(0, 0.6, (D_MODEL, VOCAB)),
    }

LINEAR = ["Wq", "Wk", "Wv", "Wo", "Wg", "Wz", "Wf", "U"]

def rmsnorm(x):
    return x / np.sqrt(np.mean(x * x, axis=-1, keepdims=True) + 1e-6)

def rope(x, positions):
    """Xoay RoPE theo VỊ TRÍ TUYỆT ĐỐI; x: [heads, T, d_head]. Chỉ áp cho Q và K."""
    half = D_HEAD // 2
    freqs = 10000.0 ** (-2.0 * np.arange(half) / D_HEAD)
    ang = np.asarray(positions, dtype=float)[:, None] * freqs[None, :]
    cos, sin = np.cos(ang)[None], np.sin(ang)[None]
    x1, x2 = x[..., :half], x[..., half:]
    return np.concatenate([x1 * cos - x2 * sin, x1 * sin + x2 * cos], axis=-1)

def heads(x):
    return x.reshape(len(x), N_HEADS, D_HEAD).transpose(1, 0, 2)

def forward(W, ids, start, K_past=None, V_past=None):
    """Xử lý len(ids) token bắt đầu từ vị trí `start`; K_past/V_past có shape [heads, start, d_head].

Trả về (logits [T, VOCAB], K_mới đã xoay RoPE, V_mới, trọng số attention [heads, T, số_key]).
    """
    ids = np.asarray(ids, dtype=int)
    T = len(ids)
    positions = np.arange(start, start + T)
    X = W["E"][ids]
    N = rmsnorm(X)
    Q, Kn, Vn = heads(N @ W["Wq"]), heads(N @ W["Wk"]), heads(N @ W["Wv"])
    Qr, Kr = rope(Q, positions), rope(Kn, positions)
    if K_past is None or K_past.shape[1] == 0:
        assert start == 0
        K, V = Kr, Vn
    else:
        assert K_past.shape[1] == start
        K, V = np.concatenate([K_past, Kr], axis=1), np.concatenate([V_past, Vn], axis=1)
    scores = np.einsum("htd,hkd->htk", Qr, K) / np.sqrt(D_HEAD)
    allow = np.arange(K.shape[1])[None, :] <= positions[:, None]       # mặt nạ nhân quả
    scores = np.where(allow[None], scores, -np.inf)
    prob = np.exp(scores - scores.max(axis=-1, keepdims=True))
    prob /= prob.sum(axis=-1, keepdims=True)                           # attention: softmax TRÊN VỊ TRÍ
    ctx = np.einsum("htk,hkd->htd", prob, V).transpose(1, 0, 2).reshape(T, N_HEADS * D_HEAD)
    H = X + ctx @ W["Wo"]
    M = rmsnorm(H)
    gate = M @ W["Wg"]
    F = H + ((gate / (1.0 + np.exp(-gate))) * (M @ W["Wz"])) @ W["Wf"]
    return rmsnorm(F) @ W["U"], Kr, Vn, prob

# ── [6] KV state manager: bể block vật lý + bảng block cho từng chuỗi ─────────
class KVPool:
    def __init__(self):
        self.K = np.zeros((POOL_BLOCKS, N_HEADS, BLOCK_SIZE, D_HEAD))
        self.V = np.zeros((POOL_BLOCKS, N_HEADS, BLOCK_SIZE, D_HEAD))
        self.free = list(range(POOL_BLOCKS))      # cấp phát block có chỉ số nhỏ nhất trước (để dễ đọc)
        self.released = []                        # (request, các block vừa trả lại)
        self.owners = {}                          # block vật lý -> các yêu cầu đã dùng nó theo thứ tự
        self.active = {}                          # request đang giữ block
        self.peak = dict(used=0, tables={}, tokens=0)

def used(self):
        return POOL_BLOCKS - len(self.free)

def write(self, seq, k_new, v_new):
        for i in range(k_new.shape[1]):
            pos = seq["cached"] + i
            if pos // BLOCK_SIZE == len(seq["blocks"]):
                assert self.free, "Hết block KV: lab này không mô phỏng preemption"
                seq["blocks"].append(self.free.pop(0))
                self.owners.setdefault(seq["blocks"][-1], []).append(seq["id"])
                self.active[seq["id"]] = seq
            block, slot = seq["blocks"][pos // BLOCK_SIZE], pos % BLOCK_SIZE
            self.K[block, :, slot] = k_new[:, i]
            self.V[block, :, slot] = v_new[:, i]
        seq["cached"] += k_new.shape[1]
        if self.used() > self.peak["used"]:         # ghi lại khoảnh khắc dùng nhiều block nhất
            self.peak = dict(used=self.used(), tables={k: list(v["blocks"]) for k, v in self.active.items()},
                             tokens=sum(v["cached"] for v in self.active.values()))

def gather(self, seq):
        if seq["cached"] == 0:
            empty = np.zeros((N_HEADS, 0, D_HEAD))
            return empty, empty
        K = np.concatenate([self.K[b] for b in seq["blocks"]], axis=1)[:, :seq["cached"]]
        V = np.concatenate([self.V[b] for b in seq["blocks"]], axis=1)[:, :seq["cached"]]
        return K, V

def release(self, seq):
        self.released.append((seq["id"], list(seq["blocks"])))
        self.free = sorted(self.free + seq["blocks"])
        self.active.pop(seq["id"], None)
        seq["blocks"] = []

# ── [8] Logits -> sampling -> stop check ────────────────────────────────────
def softmax(z):
    e = np.exp(z - z.max())
    return e / e.sum()

def sample(logits, req, rng):
    """Chọn một token. Trả về (token, thông tin để in: xác suất trước/sau lọc)."""
    z = np.array(logits, dtype=float)
    z[BOS] = -np.inf                                     # ràng buộc: không bao giờ sinh <bos>
    if req["temperature"] == 0:
        token = int(np.argmax(z))
        return token, dict(probs=softmax(z), filtered=np.eye(VOCAB)[token], token=token, mode="greedy")
    probs = softmax(z / req["temperature"])
    filtered = probs.copy()
    if req["top_k"]:
        filtered[np.argsort(filtered)[:-req["top_k"]]] = 0
    order = np.argsort(filtered)[::-1]
    norm = filtered / filtered.sum()
    filtered[order[np.cumsum(norm[order]) - norm[order] >= req["top_p"]]] = 0
    filtered /= filtered.sum()
    token = int(rng.choice(VOCAB, p=filtered))
    return token, dict(probs=probs, filtered=filtered, token=token, mode="sampling")

# ── Engine mô phỏng: gateway -> tokenizer -> scheduler -> prefill/decode ──────
def run_engine(policy, W, budget_cap=TOKEN_BUDGET):
    """policy: "continuous" (nhận ngay khi có chỗ) hoặc "static" (đợi đủ nhóm). budget_cap=None: không chia đoạn prompt."""
    pool = KVPool()
    pending = sorted((dict(r) for r in REQUESTS), key=lambda r: r["arrival"])
    waiting, running, done, rejected = [], [], [], []
    steps, gateway_log = [], []
    trace = dict(last_prefill=None, first_decode=None, first_sample=None, parity=0.0, gather=0.0,
                 positions_cached=0, positions_naive=0)
    now = 0

def admit(req):
        in_system = len(waiting) + len(running)
        if in_system >= SLOTS + QUEUE_LIMIT:
            gateway_log.append((req["id"], "gateway", "429", f"đang có {in_system} yêu cầu trong hệ thống, đã chạm giới hạn {SLOTS}+{QUEUE_LIMIT}"))
            rejected.append((req, "429"))
            return
        gateway_log.append((req["id"], "gateway", "OK", f"đang có {in_system} yêu cầu trong hệ thống, còn dưới giới hạn {SLOTS}+{QUEUE_LIMIT}"))
        tokens, ids = encode(req["text"])
        req.update(tokens=tokens, ids=ids, prompt_len=len(ids))
        if len(ids) + req["max_new"] > MAX_CONTEXT:
            gateway_log.append((req["id"], "input", "400", f"prompt {len(ids)} token + max_new {req['max_new']} = {len(ids) + req['max_new']} > MAX_CONTEXT {MAX_CONTEXT}"))
            rejected.append((req, "400"))
            return
        gateway_log.append((req["id"], "input", "OK", f"prompt {len(ids)} token + max_new {req['max_new']} <= MAX_CONTEXT {MAX_CONTEXT}"))
        req.update(ready=req["arrival"] + COST_GATEWAY + COST_TOKENIZE_PER_TOKEN * len(ids),
                   cached=0, blocks=[], prefill_left=len(ids), pending_token=None, start=None,
                   out=[], token_times=[], reason=None, history=[], rng=np.random.default_rng(req["seed"]))
        waiting.append(req)

def finish(req, t):
        req["finish"] = t
        K, V = pool.gather(req)
        Kf, Vf = forward(W, req["history"], 0)[1:3]
        trace["gather"] = max(trace["gather"], float(np.max(np.abs(K - Kf))), float(np.max(np.abs(V - Vf))))
        pool.release(req)
        running.remove(req)
        done.append(req)

def emit(req, logits_row, t):
        token, info = sample(logits_row, req, req["rng"])
        if trace["first_sample"] is None and req["id"] == FOLLOW:
            trace["first_sample"] = dict(info, logits=np.array(logits_row), request=req["id"])
        req["out"].append(token)
        req["token_times"].append(t)
        if token == EOS:
            req["reason"] = "eos"
        elif len(req["out"]) >= req["max_new"]:
            req["reason"] = "max_new_tokens"
        if req["reason"]:
            finish(req, t)
        else:
            req["pending_token"] = token

while pending or waiting or running:
        while pending and pending[0]["arrival"] <= now:
            admit(pending.pop(0))
        ready = [w for w in waiting if w["ready"] <= now]
        if policy == "continuous":
            room = SLOTS - len(running)              # nhận thêm ngay khi có chỗ trống
        else:                                        # static: chỉ lập nhóm mới khi nhóm cũ đã xong
            full_group = len(ready) >= SLOTS or (not pending and len(ready) == len(waiting))
            room = SLOTS if (not running and full_group) else 0
        for req in ready[:room]:
            waiting.remove(req)
            running.append(req)
        if not running:
            upcoming = [t for t in [r["arrival"] for r in pending] + [w["ready"] for w in waiting] if t > now]
            now = min(upcoming)
            continue
        decode = [r for r in running if r["prefill_left"] == 0]
        tasks = [("decode", r, 1) for r in decode]
        budget = None if budget_cap is None else budget_cap - len(decode)
        for r in running:
            if r["prefill_left"]:
                n = r["prefill_left"] if budget is None else min(r["prefill_left"], budget)
                if n > 0:
                    tasks.append(("prefill", r, n))
                    budget = None if budget is None else budget - n
        prefill_tokens = sum(n for p, _, n in tasks if p == "prefill")
        duration = 0
        if prefill_tokens:
            duration += COST_PREFILL_FIXED + COST_PREFILL_PER_TOKEN * prefill_tokens
        if decode:
            duration += COST_DECODE_FIXED + COST_DECODE_PER_SEQ * len(decode)
        assert duration > 0
        end = now + duration
        step = dict(start=now, end=end, waiting=len(waiting), running=len(running), tasks=[(r["id"], p, n) for p, r, n in tasks],
                    decode=len(decode), prefill=prefill_tokens)
        for phase, r, n in tasks:
            if phase == "decode":
                tok = r["pending_token"]
                r["history"].append(tok)
                K, V = pool.gather(r)
                logits, kn, vn, prob = forward(W, [tok], r["cached"], K, V)
                if trace["first_decode"] is None and r["id"] == FOLLOW:
                    trace["first_decode"] = dict(request=r["id"], token=tok, position=r["cached"], prob=prob, logits=logits[0])
                pool.write(r, kn, vn)
                full = forward(W, r["history"], 0)[0][-1]
                trace["parity"] = max(trace["parity"], float(np.max(np.abs(full - logits[0]))))
                trace["positions_cached"] += 1
                trace["positions_naive"] += len(r["history"])
                emit(r, logits[0], end)
            else:
                if r["start"] is None:
                    r["start"] = now
                lo = r["prompt_len"] - r["prefill_left"]
                chunk = r["ids"][lo:lo + n]
                r["history"] += chunk
                K, V = pool.gather(r)
                logits, kn, vn, prob = forward(W, chunk, lo, K, V)
                pool.write(r, kn, vn)
                r["prefill_left"] -= n
                trace["positions_cached"] += n
                trace["positions_naive"] += n
                if r["prefill_left"] == 0:
                    full = forward(W, r["history"], 0)[0][-1]
                    trace["parity"] = max(trace["parity"], float(np.max(np.abs(full - logits[-1]))))
                    if r["id"] == FOLLOW:
                        trace["last_prefill"] = dict(token=chunk[-1], position=lo + n - 1, prob=prob[:, -1, :])
                    emit(r, logits[-1], end)
        step["kv_used"] = pool.used()
        steps.append(step)
        now = end
    assert len(pool.free) == POOL_BLOCKS, "mọi block phải được trả lại sau khi các chuỗi kết thúc"
    return dict(done=sorted(done, key=lambda r: r["id"]), rejected=rejected, steps=steps, gateway=gateway_log,
                trace=trace, pool=pool, end=now)

def metrics(req):
    first, last, n = req["token_times"][0], req["token_times"][-1], len(req["out"])
    return dict(
        prep=req["ready"] - req["arrival"],
        queue=req["start"] - req["ready"],
        prefill=first - req["start"],
        ttft=first - req["arrival"],
        tpot=(last - first) / (n - 1) if n > 1 else None,
        e2e=last - req["arrival"],
        gap=max(b - a for a, b in zip(req["token_times"], req["token_times"][1:])) if n > 1 else 0,
        n=n,
    )

def summary(result):
    ms_ = {r["id"]: metrics(r) for r in result["done"]}
    tokens = sum(m["n"] for m in ms_.values())
    span = max(r["finish"] for r in result["done"]) - min(r["arrival"] for r in result["done"])
    tpots = [m["tpot"] for m in ms_.values() if m["tpot"] is not None]
    return dict(per=ms_, tokens=tokens, span=span, throughput=tokens / (span / 1e6),
                mean_ttft=sum(m["ttft"] for m in ms_.values()) / len(ms_), max_ttft=max(m["ttft"] for m in ms_.values()),
                mean_tpot=sum(tpots) / len(tpots), worst_gap=max(m["gap"] for m in ms_.values()))

# ── [9] Quantization: số nguyên đối xứng theo kênh đầu ra ────────────────────
def quantize_weights(W, bits=QUANT_BITS):
    levels = 2 ** (bits - 1) - 1                                       # 127 với INT8
    Wq, info = dict(W), {}
    for name in LINEAR:
        w = W[name]
        scale = np.max(np.abs(w), axis=0, keepdims=True) / levels      # một scale cho mỗi cột (kênh đầu ra)
        ints = np.clip(np.rint(w / scale), -levels, levels).astype(np.int8)
        restored = ints.astype(float) * scale
        assert np.max(np.abs(restored - w) - scale / 2) <= 1e-12, "sai số khôi phục phải <= nửa scale"
        Wq[name] = restored
        info[name] = dict(elements=w.size, scales=scale.size, max_err=float(np.max(np.abs(restored - w))),
                          half_scale=float(np.max(scale) / 2))
    return Wq, info

def greedy_teacher_forced(W, Wq, ids, steps):
    """Mô hình gốc chạy greedy; ở mỗi bước đưa CÙNG ngữ cảnh cho bản lượng tử hóa và so quyết định top-1."""
    results = []
    logits, k, v, _ = forward(W, ids, 0)
    logits_q, kq, vq, _ = forward(Wq, ids, 0)
    for step in range(steps):
        row, row_q = logits[-1].copy(), logits_q[-1].copy()
        row[BOS] = row_q[BOS] = -np.inf
        first, second = np.argsort(row)[::-1][:2]
        results.append(dict(token=int(first), token_q=int(np.argmax(row_q)), margin=float(row[first] - row[second]),
                            margin_q=float(row_q[first] - row_q[second]), step=step,
                            err=float(np.max(np.abs(logits[-1][1:] - logits_q[-1][1:])))))
        pos = len(ids) + step
        logits, kn, vn, _ = forward(W, [int(first)], pos, k, v)
        logits_q, knq, vnq, _ = forward(Wq, [int(first)], pos, kq, vq)
        k, v = np.concatenate([k, kn], axis=1), np.concatenate([v, vn], axis=1)
        kq, vq = np.concatenate([kq, knq], axis=1), np.concatenate([vq, vnq], axis=1)
    return results

# ══════════════════════════════════════════════════════════════════════════════
# CHẠY LAB
# ══════════════════════════════════════════════════════════════════════════════
W = make_weights()
main = run_engine("continuous", W)
RUNS = [("static (đợi đủ nhóm)", run_engine("static", W, None)),
        ("continuous, không chia prompt", run_engine("continuous", W, None)),
        (f"continuous + chunked ({TOKEN_BUDGET} token/bước)", main)]
S = summary(main)
by_id = {r["id"]: r for r in main["done"]}
f, fm, tr, pool = by_id[FOLLOW], S["per"][FOLLOW], main["trace"], main["pool"]
steps = main["steps"]

print("=== LAB TỔNG HỢP: MỘT YÊU CẦU ĐI QUA TOÀN BỘ ĐƯỜNG ỐNG PHỤC VỤ LLM ===")
print("MỤC TIÊU: theo dõi bằng số thật một yêu cầu từ lúc đến cổng tới lúc dừng, rồi đọc TTFT, TPOT và throughput.")
print(f"ĐẦU VÀO: 5 yêu cầu đến cùng một engine (thời điểm đến tính trên đồng hồ mô phỏng). Bạn theo dõi yêu cầu {FOLLOW} qua mọi khối.")
for r in REQUESTS:
    mode = "greedy" if r["temperature"] == 0 else f"lấy mẫu T={r['temperature']} top_k={r['top_k']} top_p={r['top_p']}"
    mark = "  <- yêu cầu theo dõi" if r["id"] == FOLLOW else ""
    print(f"  {r['id']}: đến {ms(r['arrival'])}, \"{r['text']}\", max_new={r['max_new']}, {mode}, seed {r['seed']}{mark}")
print(f"CẤU HÌNH: {SLOTS} chỗ chạy + {QUEUE_LIMIT} chỗ chờ; mỗi bước tối đa {TOKEN_BUDGET} token; block KV {BLOCK_SIZE} token x {POOL_BLOCKS} block; context tối đa {MAX_CONTEXT}.")
print(f"MÔ HÌNH: 1 lớp decoder (MHA {N_HEADS} head, RoPE, SwiGLU), d_model={D_MODEL}, từ vựng {VOCAB} token, trọng số ngẫu nhiên seed {SEED}.")
print("ĐỒNG HỒ: mô phỏng theo công thức giả định (xem COST_* ở đầu file). Mọi 'ms' dưới đây là ms MÔ PHỎNG, không phải đo trên GPU.")
print("CÁCH ĐỌC: mỗi khối [n · Tên] mang tên khối trên sơ đồ Tab 01. Đọc Quan sát, nhìn số, rồi tự nói lại Kết luận.")
print("LƯU Ý: engine chạy MỘT lần; các khối in lại những gì engine đã ghi nhận. Router, xác thực và hủy yêu cầu không được mô phỏng.")
print("")

# [1] Gateway & admission
cap = SLOTS + QUEUE_LIMIT
lines = [f"Quan sát: cổng xét từng yêu cầu theo thứ tự đến; hệ thống chứa tối đa {cap} yêu cầu (đang chạy + đang chờ)."]
for rid, stage, code, why in main["gateway"]:
    if stage == "gateway":
        arrival = next(r["arrival"] for r in REQUESTS if r["id"] == rid)
        lines.append(f"{rid} (đến {ms(arrival)}): {'nhận' if code == 'OK' else 'TỪ CHỐI ' + code} - {why}")
n_429 = sum(1 for _, c in main["rejected"] if c == "429")
n_400 = sum(1 for _, c in main["rejected"] if c == "400")
n_served = len(main["done"])
lines.append(f"Số đếm: offered={len(REQUESTS)}; từ chối 429 ở cổng={n_429}; từ chối 400 ở bước chuẩn bị đầu vào={n_400}; được phục vụ={n_served}.")
lines.append(f"Đối chiếu: offered = served + rejected -> {len(REQUESTS)} = {n_served} + {n_429 + n_400} -> {len(REQUESTS) == n_served + n_429 + n_400}.")
lines.append("Kết luận: từ chối sớm giữ hàng đợi hữu hạn, nên yêu cầu tới khi hệ thống đầy nhận 429 thay vì chờ lâu rồi vẫn trễ hạn." if n_429
             else "Kết luận: với giới hạn hiện tại hàng đợi chưa đầy nên không có yêu cầu nào bị 429; thử giảm QUEUE_LIMIT để thấy từ chối.")
lines.append("Giới hạn: cổng chỉ xét ở ranh giới giữa hai bước, nên yêu cầu đến giữa bước được xét sau khi bước đó kết thúc (giờ đến vẫn giữ nguyên).")
say("1 · Gateway & admission", "Cổng tiếp nhận và kiểm soát hàng đợi", lines)

# [2] Input preparation
bad = [(rid, why) for rid, stage, code, why in main["gateway"] if stage == "input" and code == "400"]
say("2 · Input preparation", "Chat template, BPE và ngân sách token", [
    f"BPE học {len(MERGES)} phép gộp từ {len(CORPUS)} câu mẫu; từ vựng cuối có {VOCAB} token (cộng <bos>, <eos>).",
    f"Các phép gộp đầu: {[''.join(m) for m in MERGES[:5]]} ... ('</w>' đánh dấu hết một từ).",
    f"Yêu cầu {FOLLOW}: \"{f['text']}\" -> {f['tokens']}",
    f"Token IDs: {f['ids']}  (ID chỉ là số thứ tự trong bảng từ vựng; ý nghĩa nằm ở vector nhúng mà mô hình tra ra từ ID).",
    f"Ngân sách: prompt {f['prompt_len']} token + max_new {f['max_new']} = {f['prompt_len'] + f['max_new']} <= MAX_CONTEXT {MAX_CONTEXT}.",
    "Độ dài prompt: " + ", ".join(f"{r['id']}={r['prompt_len']}" for r in main["done"]) + " token (kể cả <bos>).",
    *[f"Bị chặn: {rid} - {why}." for rid, why in bad],
    f"Chi phí chuẩn bị (giả định): cổng {ms(COST_GATEWAY)} + {COST_TOKENIZE_PER_TOKEN / 1000:.2f} ms mỗi token -> {FOLLOW} sẵn sàng sau {ms(fm['prep'])}.",
    "Kết luận: cùng văn bản phải cho cùng token IDs trên mọi bản sao; tokenizer hay template sai làm đổi hành vi của mô hình.",
])

# [3] Iteration scheduler
sched = ["Mỗi dòng: bước (bắt đầu -> kết thúc), số yêu cầu chờ/chạy, rồi [yêu cầu:pha:số token] với p = prefill (đoạn prompt), d = decode (1 token mới)."]
for i, st in enumerate(steps):
    work = " ".join(f"{rid}:{p[0]}:{n}" for rid, p, n in st["tasks"])
    sched.append(f"bước {i + 1:>2}: {ms(st['start'])} -> {ms(st['end'])} | chờ={st['waiting']} chạy={st['running']} | {work}")
lone = steps[0]["tasks"][0][0]
late = [r for r in main["done"] if r["id"] != lone and r["arrival"] <= steps[0]["start"]]
sched.append(f"Quan sát: bước 1 bắt đầu lúc {ms(steps[0]['start'])} chỉ với {lone}; "
             + ", ".join(f"{r['id']} đã đến nhưng còn chuẩn bị đầu vào, sẵn sàng lúc {ms(r['ready'])}" for r in late) + ". Bộ lập lịch không đợi.")
mixed = [i + 1 for i, st in enumerate(steps) if st["decode"] and st["prefill"]]
sched.append(f"Bước {mixed} vừa decode cho yêu cầu đang chạy vừa prefill cho yêu cầu mới: chúng dùng chung một bước và (theo công thức chi phí giả định) hai pha chạy nối tiếp nên decode phải đợi prefill xong." if mixed
             else "Không có bước nào trộn decode và prefill.")
chunks = [n for st in steps for rid, p, n in st["tasks"] if p == "prefill" and rid == FOLLOW]
sched.append(f"Chunked prefill: prompt {FOLLOW} dài {f['prompt_len']} token được xử lý theo các đoạn {chunks} (ngân sách {TOKEN_BUDGET} token mỗi bước).")
sched.append(f"{FOLLOW}: sẵn sàng lúc {ms(f['ready'])}, nhưng bước đầu của nó bắt đầu lúc {ms(f['start'])} -> chờ chỗ chạy {ms(fm['queue'])}.")
sched.append("Kết luận: continuous batching đưa yêu cầu mới vào ở ranh giới từng bước ngay khi có chỗ trống, không đợi cả nhóm cũ xong.")
say("3 · Iteration scheduler", "Lập lịch theo vòng lặp (continuous batching + chunked prefill)", sched)

# [4] Prefill
fs = tr["first_sample"]
row = fs["logits"]
top3 = np.argsort(row)[::-1][:3]
say("4 · Prefill", "Xử lý prompt, ghi KV và tạo logits đầu tiên", [
    f"Prompt {FOLLOW} có {f['prompt_len']} token -> các đoạn {chunks} chạy qua mô hình; mỗi token ghi K và V vào cache.",
    f"Sau prefill, cache của {FOLLOW} có K shape {(N_HEADS, f['prompt_len'], D_HEAD)} = (số head, số token, chiều mỗi head); V cùng shape.",
    f"Chỉ hàng CUỐI của logits dùng để chọn token đầu tiên: {vec(row, 2)}",
    f"Cách đọc: {len(row)} cột = {len(row)} token trong từ vựng; ba điểm cao nhất ở ID {top3.tolist()} = {[ID_TO_TOKEN[i] for i in top3]} (điểm {vec(row[top3], 2)}).",
    f"Token đầu tiên của {FOLLOW} xuất hiện lúc {ms(f['token_times'][0])} -> TTFT = {ms(f['token_times'][0])} - {ms(f['arrival'])} = {ms(fm['ttft'])}.",
    "Kết luận: prefill kết thúc bằng token đầu tiên, nên nó cùng với thời gian chờ quyết định TTFT. Logits là điểm số, chưa phải xác suất.",
])

# [5] Transformer x N layers
lp = tr["last_prefill"]
a0, a1 = lp["prob"][0], lp["prob"][1]
say("5 · Transformer × N layers", "Attention weights và logits là hai phân phối khác nhau", [
    f"Lấy hàng cuối của prefill: token '{ID_TO_TOKEN[lp['token']]}' (ID {lp['token']}) ở vị trí {lp['position']} nhìn lại {len(a0)} vị trí nguồn 0..{lp['position']}.",
    f"Attention weights head 0: {vec(a0)} tổng = {a0.sum():.6f}",
    f"Attention weights head 1: {vec(a1)} tổng = {a1.sum():.6f}",
    f"Cách đọc: mỗi head có K/V riêng (MHA) nên cho phân phối khác nhau; head 0 nhìn nhiều nhất vị trí {int(np.argmax(a0))}, head 1 nhìn nhiều nhất vị trí {int(np.argmax(a1))}.",
    "Mỗi hàng là softmax trên các VỊ TRÍ nguồn, cộng lại bằng 1; vị trí tương lai bị mặt nạ nhân quả chặn (xác suất 0).",
    f"Hai head được ghép, qua W_O, cộng residual, SwiGLU, rồi LM head cho {VOCAB} điểm số trên TOKEN ứng viên (chính là hàng logits ở khối [4]).",
    "Phân biệt: attention weights nói 'lấy thông tin từ vị trí nào'; logits nói 'token nào đi sau'. Xác suất trên từ vựng chỉ xuất hiện ở khối [8].",
    f"Kiểm tra số học: logits qua KV cache khớp tính lại cả chuỗi ở MỌI bước (prefill + decode, cả 3 yêu cầu), sai lệch lớn nhất <= 1e-9: {tr['parity'] <= 1e-9} (phần dư chỉ là sai số làm tròn float64).",
])

# [6] KV state manager
pk = pool.peak
slots_used = pk["used"] * BLOCK_SIZE
contiguous = SLOTS * MAX_CONTEXT
reused = [f"block {b}: {' → '.join(o)}" for b, o in sorted(pool.owners.items()) if len(o) > 1]
say("6 · KV state manager", "Block vật lý, bảng block và việc trả block", [
    f"Mỗi block chứa {BLOCK_SIZE} token. Khoảnh khắc dùng nhiều block nhất, bảng block (logic -> vật lý) của từng chuỗi là: "
    + "; ".join(f"{rid}→{blk}" for rid, blk in pk["tables"].items()) + ".",
    "Cách đọc: block logic 0, 1, 2... của một chuỗi nằm ở block vật lý không nhất thiết liền nhau và có thể xen kẽ giữa các chuỗi; bảng block là bảng tra.",
    f"Khi đó dùng {pk['used']}/{POOL_BLOCKS} block = {slots_used} chỗ token, đang lưu {pk['tokens']} token -> thừa {slots_used - pk['tokens']} chỗ ở block cuối của từng chuỗi.",
    f"So sánh: cấp một mảng liền {MAX_CONTEXT} token cho mỗi chỗ chạy cần {contiguous} chỗ token; phân trang chỉ cần {slots_used} chỗ.",
    "Trả block theo thứ tự kết thúc: " + "; ".join(f"{rid} trả {blk}" for rid, blk in pool.released) + ".",
    ("Block được dùng lại: " + "; ".join(reused) + ".") if reused else "Không có block nào được dùng lại trong trace này.",
    f"Sau khi mọi yêu cầu kết thúc còn {len(pool.free)}/{POOL_BLOCKS} block trống (không rò rỉ).",
    f"Kiểm tra số học: K/V gom từ các block rời khớp K/V tính lại từ đầu cho từng chuỗi, sai lệch lớn nhất <= 1e-9: {tr['gather'] <= 1e-9}.",
    "Giới hạn: không mô phỏng prefix cache, đếm tham chiếu hay preemption khi hết block.",
])

# [7] Decode
fd = tr["first_decode"]
d0 = fd["prob"][0, 0]
n_dec = sum(1 for st in steps for rid, p, n in st["tasks"] if p == "decode" and rid == FOLLOW)
say("7 · Decode", "Vòng lặp tự hồi quy với KV cache", [
    f"{FOLLOW} sinh {len(f['out'])} token: 1 token từ prefill + {n_dec} bước decode; mỗi bước chỉ đưa vào 1 token mới.",
    f"Bước decode đầu của {FOLLOW}: đưa token '{ID_TO_TOKEN[fd['token']]}' (vị trí {fd['position']}), attention head 0 có {len(d0)} trọng số: {fd['position']} vị trí đọc từ cache + 1 vị trí là chính nó.",
    f"Các trọng số đó: {vec(d0)} tổng = {d0.sum():.6f}; K/V của {fd['position']} vị trí cũ không phải tính lại.",
    f"Cache của {FOLLOW} dài {f['prompt_len'] + len(f['out']) - 1} vị trí khi kết thúc (token cuối được chọn nhưng chưa bao giờ được đưa vào mô hình).",
    f"Đếm vị trí đã đưa qua mô hình (cả 3 yêu cầu): dùng cache = {tr['positions_cached']}; nếu mỗi bước tính lại cả lịch sử = {tr['positions_naive']}.",
    "Đây là số vị trí phải tính, đếm thật khi chạy; thời gian tiết kiệm thật trên GPU còn phụ thuộc phần cứng và CHƯA được đo ở đây.",
    "Kết luận: mỗi bước decode tính ít token nhưng vẫn phải đọc lại trọng số và toàn bộ KV, nên thường bị giới hạn bởi băng thông bộ nhớ, không phải bởi phép nhân.",
])

# [8] Logits -> sampling -> stop check
kept = np.flatnonzero(fs["filtered"] > 0)
top = np.argsort(fs["probs"])[::-1][:5]
stream = ", ".join(f"{ms(t)} '{ID_TO_TOKEN[tok]}'" for t, tok in zip(f["token_times"], f["out"]))
say("8 · Logits → sampling → stop check", "Từ logits tới một token, rồi dừng hay tiếp", [
    f"{FOLLOW}: temperature {f['temperature']}, top_k {f['top_k']}, top_p {f['top_p']}, seed {f['seed']}; áp cho hàng logits ở khối [4].",
    f"Logits chia temperature rồi softmax -> XÁC SUẤT trên {VOCAB} token, tổng = {fs['probs'].sum():.6f}. Năm token cao nhất: "
    + ", ".join(f"{ID_TO_TOKEN[i]}={fs['probs'][i]:.3f}" for i in top),
    f"Lọc top-k/top-p giữ {len(kept)} token, tái chuẩn hóa tổng về 1: " + ", ".join(f"{ID_TO_TOKEN[i]}={fs['filtered'][i]:.3f}" for i in kept),
    f"Rút ngẫu nhiên (seed {f['seed']}) được ID {fs['token']} = '{ID_TO_TOKEN[fs['token']]}'. Chọn token chưa phải xử lý token: nó vào cache ở bước decode kế tiếp.",
    "Kiểm tra dừng sau mỗi token: gặp <eos> hoặc đủ max_new_tokens. Kết quả:",
    *[f"  {r['id']}: dừng vì {r['reason']} sau {len(r['out'])}/{r['max_new']} token -> {detokenize(r['out'])!r}" for r in main["done"]],
    f"Streaming của {FOLLOW} (thời điểm mô phỏng, token): {stream}",
    "Quan sát: token đầu đến đúng lúc TTFT, các token sau cách nhau theo TPOT; engine không đợi câu hoàn chỉnh mới gửi.",
    "Cảnh báo: văn bản vô nghĩa (hoặc lặp một chữ) vì trọng số ngẫu nhiên chưa huấn luyện; chỉ cơ chế chọn token và dừng là thật.",
])

# [9] KV / weight precision
Wq8, qinfo = quantize_weights(W)
n_el = sum(i["elements"] for i in qinfo.values())
n_sc = sum(i["scales"] for i in qinfo.values())
fp32_bytes, int_bytes = 4 * n_el, n_el * QUANT_BITS / 8 + 4 * n_sc
lg_fp = forward(W, f["ids"], 0)[0]
lg_q = forward(Wq8, f["ids"], 0)[0]
logit_err = float(np.max(np.abs(lg_fp[:, 1:] - lg_q[:, 1:])))
say("9 · KV / weight precision", f"Lượng tử hóa trọng số INT{QUANT_BITS} đối xứng theo kênh đầu ra", [
    f"Lượng tử hóa {len(LINEAR)} ma trận tuyến tính ({n_el} phần tử): scale = max|w| / {2 ** (QUANT_BITS - 1) - 1} cho từng cột, w_int = round(w / scale).",
    f"Dung lượng định dạng: FP32 = {fp32_bytes} byte -> INT{QUANT_BITS} + scale FP32 = {int_bytes:.0f} byte (nhỏ hơn {fp32_bytes / int_bytes:.2f} lần; phép tính trên định dạng, không phải đo).",
    f"Sai số khôi phục trọng số lớn nhất = {max(i['max_err'] for i in qinfo.values()):.4f}; chặn lý thuyết (nửa scale lớn nhất) = {max(i['half_scale'] for i in qinfo.values()):.4f}.",
    f"Sai số logits khi chạy prompt {FOLLOW} (so bản gốc với bản lượng tử hóa, bỏ <bos>) lớn nhất = {logit_err:.4f}.",
    "Kết luận: sai số số học nhỏ chỉ nói các con số gần nhau; có đổi quyết định chọn token hay không phải kiểm ở khối [13].",
    "Giới hạn: lab giả lập 'lưu số nguyên, giải nén ra số thực để nhân'; kernel số nguyên thật tạo thêm sai số và khác tốc độ. KV cache lượng tử hóa không được chạy.",
])

# [10] HBM memory budget
bytes_per_token = 2 * N_HEADS * D_HEAD * pool.K.itemsize
pool_bytes = pool.K.nbytes + pool.V.nbytes
weight_bytes = sum(w.nbytes for w in W.values())
layers, ctx, kvh, hd, bpe = 32, 4096, 8, 128, 2
real_seq = 2 * layers * ctx * kvh * hd * bpe
GiB = 1024 ** 3
assumed_hbm, assumed_weights = 80 * GiB, 16 * GiB
say("10 · HBM memory budget", "Trọng số + KV + vùng làm việc", [
    f"Trong lab: trọng số float64 = {weight_bytes} byte; bể KV = {POOL_BLOCKS} block x {BLOCK_SIZE} token x {bytes_per_token} byte/token = {pool_bytes} byte.",
    f"Một token cần K và V: 2 x {N_HEADS} head x {D_HEAD} chiều x {pool.K.itemsize} byte (float64 của NumPy) = {bytes_per_token} byte cho 1 lớp.",
    f"Khoảnh khắc cao điểm dùng {pk['used']} block = {pk['used'] * BLOCK_SIZE * bytes_per_token} byte KV ({100 * pk['used'] / POOL_BLOCKS:.0f}% bể).",
    "Công thức: byte KV = 2 x số lớp x số token x số KV head x chiều head x byte mỗi phần tử.",
    f"Ví dụ GIẢ ĐỊNH (tính tay, không đo; cùng cấu hình bài HBM): {layers} lớp, {ctx} token, {kvh} KV head, head {hd}, FP16 -> {real_seq} byte = {real_seq / GiB:.2f} GiB cho một chuỗi.",
    f"Giả sử GPU {assumed_hbm // GiB} GiB, trọng số FP16 {assumed_weights // GiB} GiB: còn {(assumed_hbm - assumed_weights) // GiB} GiB cho KV = tối đa {(assumed_hbm - assumed_weights) // real_seq} chuỗi {ctx} token (chưa trừ vùng làm việc).",
    f"Nếu trọng số nén còn một nửa ({assumed_weights // 2 // GiB} GiB, giả định): còn {(assumed_hbm - assumed_weights // 2) // GiB} GiB -> {(assumed_hbm - assumed_weights // 2) // real_seq} chuỗi.",
    "Kết luận: KV tăng tuyến tính theo số token và số chuỗi; vì vậy bộ nhớ KV, không chỉ trọng số, quyết định số yêu cầu chạy đồng thời.",
])

# [11] Telemetry & capacity feedback
tele = ["Mỗi bước: thời lượng, số yêu cầu chờ/chạy, token decode/prefill, block KV đang dùng (đo sau khi các chuỗi vừa xong đã trả block)."]
for i, st in enumerate(steps):
    tele.append(f"bước {i + 1:>2}: {st['end'] - st['start']:>5} µs | chờ={st['waiting']} chạy={st['running']} decode={st['decode']} prefill={st['prefill']} "
                f"| KV {st['kv_used']}/{POOL_BLOCKS} ({100 * st['kv_used'] / POOL_BLOCKS:.0f}%)")
tele.append("Phân rã TTFT (µs mô phỏng): chuẩn bị đầu vào + chờ chỗ chạy + prefill = TTFT")
for rid, m in sorted(S["per"].items()):
    biggest = max([("chuẩn bị đầu vào", m["prep"]), ("chờ chỗ chạy", m["queue"]), ("prefill", m["prefill"])], key=lambda x: x[1])
    assert m["prep"] + m["queue"] + m["prefill"] == m["ttft"]
    verdict = "VƯỢT" if m["ttft"] > TTFT_SLO else "đạt"
    tele.append(f"  {rid}: {m['prep']:>5} + {m['queue']:>5} + {m['prefill']:>5} = {m['ttft']:>5} | lớn nhất: {biggest[0]} | {verdict} ngưỡng giả định {ms(TTFT_SLO)}")
tele.append("Kết luận: đừng chỉ nhìn tổng TTFT; xem phần nào lớn nhất để biết nút thắt là hàng đợi hay prefill trước khi sửa.")
tele.append("Giới hạn: chỉ có 3 yêu cầu được phục vụ nên không có p95/p99 đáng tin; hệ thống thật cần hàng nghìn mẫu.")
say("11 · Telemetry & capacity feedback", "Số đo trên đồng hồ mô phỏng", tele)

# [12] Benchmark & SLO methodology
bench = ["Định nghĩa: TTFT = thời điểm token đầu - thời điểm đến; TPOT = khoảng cách trung bình giữa các token sau token đầu; throughput = tổng token / thời gian chạy.",
         "Từng yêu cầu (continuous + chunked): TTFT | TPOT | E2E | số token"]
for rid, m in sorted(S["per"].items()):
    tp = ms(m["tpot"]) if m["tpot"] is not None else "n/a"
    bench.append(f"  {rid}: {ms(m['ttft'])} | {tp} | {ms(m['e2e'])} | {m['n']}")
same = all(r["out"] == by_id[r["id"]]["out"] for _, res in RUNS for r in res["done"] if r["id"] in by_id)
bench.append(f"Đúng trước, nhanh sau: đổi chính sách lập lịch có đổi token sinh ra không? Mọi yêu cầu chạy ở cả 3 chính sách đều cho cùng token: {same}.")
bench.append("Baseline: cùng trace, cùng seed, cùng công thức chi phí; chỉ đổi chính sách lập lịch (static = đợi đủ nhóm, chạy hết nhóm rồi mới nhận nhóm sau).")
bench.append("Mỗi dòng: thời gian chạy | throughput | TTFT trung bình / lớn nhất | TPOT trung bình | khoảng cách lớn nhất giữa hai token liền kề của một yêu cầu")
for name, res in RUNS:
    X = summary(res)
    bench.append(f"  {name:<38}: {ms(X['span'])} | {X['throughput']:.1f} token/s mô phỏng | {ms(X['mean_ttft'])} / {ms(X['max_ttft'])} | {ms(X['mean_tpot'])} | {ms(X['worst_gap'])}")
nochunk, chunked = summary(RUNS[1][1]), summary(RUNS[2][1])
if nochunk["mean_ttft"] < chunked["mean_ttft"] and nochunk["worst_gap"] > chunked["worst_gap"]:
    bench.append(f"Cách đọc: không chia prompt thì TTFT trung bình thấp hơn ({ms(nochunk['mean_ttft'])} so với {ms(chunked['mean_ttft'])}) nhưng một yêu cầu đang decode bị đứng "
                 f"tới {ms(nochunk['worst_gap'])} (so với {ms(chunked['worst_gap'])}). Chia đoạn đổi một phần TTFT lấy khoảng đứng ngắn hơn.")
else:
    bench.append("Cách đọc: với cấu hình hiện tại, chia đoạn prompt không còn cho đúng đánh đổi 'TTFT thấp hơn nhưng khoảng đứng dài hơn'; hãy so hai cột TTFT và cột cuối.")
bench.append("Kết luận: các chênh lệch này là hệ quả của mô hình chi phí giả định trên 3 yêu cầu, KHÔNG phải tốc độ GPU thật; đổi trace hoặc COST_* có thể đổi thứ hạng.")
bench.append("Benchmark thật cần: khởi động nóng, lặp lại nhiều lần, báo p50/p95/p99, cùng phần cứng và cùng mẫu tải. Một lần chạy không đủ.")
say("12 · Benchmark & SLO methodology", "TTFT, TPOT và throughput", bench)

# [13] Quality gates & rollout
gate_rows, flips, decisions, tight = [], 0, 0, None
for r in sorted(REQUESTS, key=lambda r: r["id"]):
    res = greedy_teacher_forced(W, Wq8, encode(r["text"])[1], 8)
    agree = sum(x["token"] == x["token_q"] for x in res)
    flips += len(res) - agree
    decisions += len(res)
    low = min(res, key=lambda x: x["margin"])
    if tight is None or low["margin"] < tight[1]["margin"]:
        tight = (r["id"], low)
    gate_rows.append(f"  {r['id']}: khớp {agree}/{len(res)} quyết định top-1; sai số logits lớn nhất {max(x['err'] for x in res):.4f}")
agreement = (decisions - flips) / decisions
say("13 · Quality gates & rollout", f"Cổng chất lượng: bản gốc và bản INT{QUANT_BITS} có chọn cùng token không?", [
    "Cách làm: với mỗi prompt, mô hình gốc chạy greedy 8 bước; ở mỗi bước đưa CÙNG ngữ cảnh cho bản lượng tử hóa và so token top-1 (teacher forcing).",
    *gate_rows,
    f"Tổng: {decisions - flips}/{decisions} quyết định giống nhau = {100 * agreement:.1f}%; ngưỡng cổng giả định {100 * QUALITY_GATE:.0f}% -> {'ĐẠT' if agreement >= QUALITY_GATE else 'KHÔNG ĐẠT'}.",
    f"Quyết định sát nhất: prompt {tight[0]}, bước {tight[1]['step'] + 1}: bản gốc hơn token nhì {tight[1]['margin']:.4f} điểm; bản lượng tử hóa hơn {tight[1]['margin_q']:.4f} điểm "
    f"-> {'giữ nguyên' if tight[1]['margin_q'] > 0 else 'ĐÃ ĐỔI'} token được chọn.",
    "Cách đọc: token top-1 chỉ đổi khi sai số làm hai điểm số đảo thứ tự; sai số logits lớn nhất (các dòng trên) chỉ là chặn trên, không tự nó báo token đổi.",
    f"Kết luận: cổng này là kiểm tra hồi quy trên mô hình đồ chơi, {decisions} quyết định. Nó KHÔNG đo chất lượng ngôn ngữ; bản thật cần bộ đánh giá theo nhiệm vụ.",
])

# ── Kiểm tra bất biến (không thay thế việc đọc kết quả ở trên) ───────────────
assert len(REQUESTS) == n_served + n_429 + n_400
assert tr["parity"] <= 1e-9 and tr["gather"] <= 1e-9
assert len(pool.free) == POOL_BLOCKS and sorted(pool.free) == list(range(POOL_BLOCKS))
assert abs(fs["probs"].sum() - 1.0) < 1e-9 and abs(fs["filtered"].sum() - 1.0) < 1e-9
assert abs(a0.sum() - 1.0) < 1e-9 and abs(a1.sum() - 1.0) < 1e-9 and abs(d0.sum() - 1.0) < 1e-9
assert np.all(fs["filtered"][fs["probs"] == 0] == 0)
assert same, "đổi chính sách lập lịch không được đổi token đã sinh"
assert tr["positions_cached"] < tr["positions_naive"]
assert S["tokens"] == sum(len(r["out"]) for r in main["done"])
print("TỔNG KẾT: Bạn vừa quan sát được gì?")
print(f"1. Yêu cầu {FOLLOW} đi qua 13 khối; TTFT {ms(fm['ttft'])} = chuẩn bị {ms(fm['prep'])} + chờ chỗ chạy {ms(fm['queue'])} + prefill {ms(fm['prefill'])}.")
print("2. Đổi cách lập lịch hay lưu KV theo block không đổi token sinh ra (đã so token và logits); chúng chỉ đổi thời gian và bộ nhớ.")
print("3. Attention weights (trên vị trí) và xác suất từ vựng (trên token) là hai phân phối khác nhau, mỗi phân phối tổng bằng 1.")
print("4. Số ms là mô phỏng theo giả định; số byte, số vị trí, token và sai số là kết quả tính thật trong lab này.")
print("PASS: đường ống phục vụ LLM thu nhỏ chạy đúng (cache khớp tính lại, block được trả đủ, lập lịch không đổi nội dung).")

Python outputSẵn sàng.

Bài tập 1 · Vì sao D bị từ chối ở cổng còn E bị chặn ở bước chuẩn bị đầu vào?

Dựa vào khối 1 và khối 2: D và E đều bị từ chối, nhưng mã khác nhau (429 và 400) và ở hai khối khác nhau. Hãy nêu điều kiện cụ thể khiến mỗi yêu cầu bị từ chối, rồi cho biết nếu sửa QUEUE_LIMIT thành 2 thì yêu cầu nào hết bị từ chối.

Đối chiếu sau khi tự trả lời

D đến lúc đã có 3 yêu cầu trong hệ thống (A, B, C) bằng giới hạn SLOTS + QUEUE_LIMIT = 2 + 1, nên cổng trả 429 trước khi tốn công tokenize. E đến khi mới có 2 yêu cầu nên qua cổng; sau khi tách token, prompt có 8 token cộng 30 token xin sinh là 38, lớn hơn MAX_CONTEXT = 24, nên bị chặn 400 ở khâu chuẩn bị đầu vào. Khi QUEUE_LIMIT = 2 giới hạn thành 4, D được nhận (có 3 yêu cầu trong hệ thống khi nó được xét) còn E vẫn bị 400 vì lỗi ngân sách token không liên quan đến hàng đợi.

Bài tập 2 · Tách TTFT của C và thử SLOTS = 3

Từ khối 11, cộng ba thành phần của TTFT cho C và chỉ ra thành phần lớn nhất. Dự đoán rồi kiểm tra: nếu sửa SLOTS thành 3 thì TTFT của C giảm hay tăng, và D còn bị từ chối không?

Đối chiếu sau khi tự trả lời

Mặc định: 0.65 ms chuẩn bị đầu vào + 14.55 ms chờ chỗ chạy + 6.80 ms prefill = 22.00 ms; chờ chỗ chạy là lớn nhất. Với SLOTS = 3, giới hạn hệ thống thành 3 + 1 = 4 nên D không bị 429 nữa; C chỉ chờ 8.95 ms nhưng prefill kéo dài 9.00 ms vì dùng chung các bước với nhiều chuỗi hơn, nên TTFT là 18.60 ms (giảm so với 22.00 ms). Thêm chỗ chạy giảm thời gian chờ nhưng làm mỗi bước nặng hơn; vì vậy TTFT của B, C, D đều vượt ngưỡng giả định 8.00 ms trong lần chạy này.

Bài tập 3 · Dãy số nào là trọng số attention, dãy nào là xác suất từ vựng?

Với C, khối 5 in hai dãy trọng số của hai head và khối 8 in xác suất trước và sau khi lọc. Hãy nói mỗi dãy có bao nhiêu phần tử, tổng bằng bao nhiêu, và mỗi dãy dùng để làm gì. Vì sao không thể đọc 0.306 ở khối 7 là xác suất token kế tiếp?

Đối chiếu sau khi tự trả lời

Trọng số attention của một head có số phần tử bằng số vị trí đã thấy (9 ở khối 5, 10 ở khối 7 sau khi thêm token mới), tổng bằng 1, và dùng để pha trộn các vector V: nó trả lời lấy thông tin từ vị trí nào. Xác suất từ vựng có 22 phần tử (một cho mỗi token), tổng bằng 1 sau softmax, và dùng để chọn token kế tiếp. Giá trị 0.306 ở khối 7 là trọng số của vị trí 1 trong attention của head 0, không gắn với một token ứng viên nào nên không thể là xác suất token kế tiếp.

Bài tập 4 · Đổi TOKEN_BUDGET từ 6 lên 20

Dự đoán: prompt của C còn bị chia thành mấy đoạn? TTFT trung bình, khoảng đứng lớn nhất giữa hai token và token sinh ra sẽ đổi thế nào? Sửa dòng TOKEN_BUDGET rồi chạy lại để kiểm tra.

Đối chiếu sau khi tự trả lời

Prompt 9 token nằm gọn trong ngân sách 20 nên C chỉ có một đoạn [9]. Bảng khối 12 cho dòng continuous + chunked (20 token/bước) trùng dòng không chia prompt: TTFT trung bình 10.00 ms (thay vì 12.67 ms), TTFT lớn nhất 17.20 ms, nhưng khoảng đứng lớn nhất giữa hai token của một yêu cầu là 6.00 ms (thay vì 3.60 ms). Token sinh ra không đổi. Chia nhỏ prompt đổi một phần TTFT lấy khoảng đứng ngắn hơn cho các yêu cầu đang decode; đây vẫn là hệ quả của công thức chi phí giả định.

Bài tập 5 · Đổi QUANT_BITS thành 4

Sửa QUANT_BITS = 4 và chạy lại. Hãy ghi: dung lượng định dạng, sai số khôi phục trọng số lớn nhất, tỉ lệ quyết định top-1 giữ nguyên ở khối 13 và kết luận của cổng chất lượng. Điều đó cho phép khẳng định gì về chất lượng ngôn ngữ?

Đối chiếu sau khi tự trả lời

Dung lượng định dạng giảm còn 784 byte (nhỏ hơn 4.16 lần so với FP32), sai số khôi phục trọng số lớn nhất tăng lên 0.1000 (chặn nửa scale là 0.1102). Cổng chất lượng khớp A 8/8, B 7/8, C 7/8, D 5/8, E 6/8, tổng 33/40 = 82.5%, thấp hơn ngưỡng giả định 95% nên báo KHÔNG ĐẠT. Điều đó cho thấy 4 bit làm đổi quyết định chọn token của mô hình ngẫu nhiên này, nhưng không cho phép khẳng định gì về chất lượng ngôn ngữ của mô hình thật, vì lab không có mô hình đã huấn luyện và không có bộ đánh giá tác vụ.

Bài tập 6 · Kích thước block ảnh hưởng thế nào đến phần thừa của KV cache?

Sửa BLOCK_SIZE = 8 và POOL_BLOCKS = 6 (giữ nguyên tổng 48 chỗ token) rồi chạy lại. Đọc khối 6: lúc cao điểm dùng bao nhiêu block, bao nhiêu chỗ token, đang lưu bao nhiêu token và thừa bao nhiêu? So với cấu hình mặc định, block lớn có lợi và có hại gì?

Đối chiếu sau khi tự trả lời

Lúc cao điểm lab dùng 4 trên 6 block, tức 32 chỗ token để lưu 19 token, thừa 13 chỗ; với block 4 token mặc định là 28 chỗ, lưu 24 token, thừa 4 chỗ. Block lớn thì bảng block ngắn hơn và mỗi lần cấp phát phục vụ nhiều token hơn, nhưng block cuối của mỗi chuỗi dễ còn nhiều chỗ trống hơn nên lãng phí bộ nhớ nhiều hơn. Số liệu này chỉ đúng với trace nhỏ của lab; chọn kích thước block cho hệ thống thật cần đo trên workload thật.