Inference phân tán

Chương 8 đã bàn về việc batching (gộp lô), lập lịch request, bộ đệm và giải mã đầu cơ (speculative decoding) giúp cải thiện hiệu quả inference như thế nào với một tập tài nguyên tính toán nhất định. Các phương pháp đó áp dụng cho cả một thẻ duy nhất lẫn các instance thực thi phối hợp trên nhiều thẻ. Chương này đi xa hơn và đặt câu hỏi: phép tính và trạng thái nên nằm ở đâu — giai đoạn và toán tử nào được xử lý bởi tài nguyên tính toán nào, trọng số và KV được phân bố như thế nào, và dữ liệu truyền giữa các vị trí thực thi ra sao, công việc được phân bổ thế nào, và lỗi được xử lý thế nào.

Chương này dùng P cho giai đoạn prefill và D cho giai đoạn decode. Tách rời PD (PD separation) giao hai giai đoạn này cho các tài nguyên khác nhau. Tách rời AF (AF separation) giao khối attention và mạng feedforward (bao gồm cả mạng expert) của mỗi tầng cho các tài nguyên khác nhau.

Xoay quanh việc đặt phép tính và trạng thái ở đâu, chương này xem xét bốn mẫu tổ chức cơ bản. Thêm replica đầy đủ cho phép các nhóm tài nguyên khác nhau xử lý request một cách độc lập; tách prefill khỏi decode cho phép mỗi giai đoạn có cấu hình tính toán riêng; tách attention khỏi tính toán expert cho phép các tài nguyên tính toán khác nhau khai thác khả năng tính toán và lưu trữ riêng của chúng; chia sẻ KV cho phép một request sử dụng trạng thái do các vị trí thực thi khác để lại. Các mẫu tổ chức này có thể xuất hiện trong một instance inference duy nhất, hoặc có thể kết nối nhiều cụm dịch vụ được lập lịch độc lập.

Bài toán thiết kế của chương này: một máy chủ giữ bốn thẻ A100 80GB SXM, một máy chủ khác giữ bốn thẻ H20 SXM5 96GB — tám thẻ này nên xử lý 3,5 request đến mỗi giây như thế nào? Mỗi request có đầu vào 8192 token và đầu ra 1025 token, và thuộc lớp request có quy trình suy luận: model trước tiên sinh ra một chuỗi suy nghĩ dài (chain of thought), rồi mới đưa ra câu trả lời. Model là Qwen3-8B, và cả trọng số lẫn KV đều dùng định dạng BF16 với 2 byte mỗi phần tử. Mỗi thẻ có thể chứa toàn bộ model, nên một thẻ là một đơn vị thực thi (worker). Không có NVLink giữa hai máy chủ, nên chúng chỉ có thể giao tiếp qua NIC RDMA. Các mục tiếp theo lần lượt quyết định: phép tính nên được chia như thế nào, bàn giao bối cảnh xảy ra ở đâu, khi nào thì giữ lại bộ đệm là đáng giá, và backlog (công việc tồn đọng) sau khi khởi động mất bao lâu để giải quyết hết. Mục 9.7 sẽ kết hợp các kết quả này để xác định phương án triển khai cho cụm tài nguyên này. Ngoài ra, để làm điểm so sánh, Mục 9.2 cũng phân tích một cụm đồng nhất gồm tám thẻ A100.

Một ví dụ xuyên suốt khác trải qua Mục 9.3 và 9.4 dùng Qwen3-235B-A22B để nghiên cứu trọng số expert nên nằm ở đâu. Cùng 512 lần dispatch expert đó, tùy thuộc kết quả dispatch, có thể cần đọc trọng số của nhiều expert hoặc lặp lại việc sử dụng trọng số của một số ít expert nóng. Điều này quyết định tính toán expert nên chạy trên CPU hay GPU, rồi xem xét vì sao cần các bản sao expert (expert replica) một khi các điểm nóng tập trung vào một thẻ duy nhất. Cả hai ví dụ đều dùng cùng một phương pháp phân tích: trước tiên xác định công việc và trạng thái mà mỗi request cần, sau đó ước tính tốc độ mỗi loại bộ xử lý có thể hoàn thành công việc đó và tốc độ hệ thống lưu trữ có thể cung cấp dữ liệu cần thiết.

9.1 Các cách phân bố phép tính và trạng thái

9.1.1 Tài nguyên tính toán, instance inference và replica dịch vụ

Trước tiên cần phân biệt tổ chức phần cứng với tổ chức dịch vụ. Các bộ tăng tốc như GPU và NPU, cùng với CPU, cung cấp khả năng tính toán và tài nguyên lưu trữ đi kèm; các tiến trình chạy logic model và giao tiếp trên các thiết bị này, và mỗi tiến trình trong một nhóm giao tiếp có một rank. Một instance inference có thể được thực thi phối hợp bởi nhiều tiến trình như vậy. Một replica dịch vụ hoàn chỉnh sở hữu trọng số và khả năng thực thi cần thiết để hoàn tất inference cho toàn bộ model, và có thể xử lý request độc lập với các replica khác.

Các hình 9-1 đến 9-4 mô tả bốn mẫu tổ chức. Hai mẫu đầu đều thực thi toàn bộ model; điểm khác biệt là một nhóm phối hợp tám thẻ cùng xử lý cùng một lô request, trong khi nhiều replica đầy đủ thì mỗi replica nhận request của riêng mình. Hai mẫu sau còn thay đổi sự phân công lao động sâu hơn: PD phân chia theo giai đoạn sinh, còn AF phân chia theo toán tử trong một tầng. Mỗi mẫu tổ chức có bộ lập lịch riêng quản lý phép tính mà nó phụ trách.

Replica đầy đủ chia công việc theo request; trong Hình 9-3, cùng một request lần lượt đi qua hai cụm dịch vụ. Theo mũi tên từ P đến D, thứ được bàn giao là context KV do quá trình xử lý đầu vào để lại; hai cụm đều vẫn thực thi toàn bộ model cho giai đoạn tương ứng của mình.

Hình 9-4 dời ranh giới vào bên trong tầng model: các activation do phía attention tạo ra được bàn giao cho phía feedforward, và kết quả được trả về. So với bàn giao một giai đoạn, đường dữ liệu này phải được đi qua lặp đi lặp lại ở mỗi tầng, trong mỗi bước sinh.

Khi so sánh các phương án triển khai này, trước tiên dùng cấu hình chạy và tốc độ xử lý thu được ở Chương 8, sau đó thay đổi sự phân công lao động giữa các tài nguyên tính toán. Chế độ P và D được xử lý bởi cùng một tập tài nguyên thực thi được gọi là co-location (cùng vị trí). Xét một instance co-location đã được tinh chỉnh. Một request có độ dài đầu vào $L$ và tổng độ dài đầu ra $G$; prefill tính logits cho token đầu vào cuối cùng và lấy mẫu token đầu ra đầu tiên từ đó. Theo quy ước sinh được áp dụng trong chương này, số lần gọi decode tiếp theo là $G-1$: token cuối cùng được trả về chưa được đưa trở lại vào model, nên số lượng đầu ra nhiều hơn số lần gọi decode tiếp theo là một.

Với một phân bố request cho trước, gọi $d_r$ là thời gian phục vụ trung bình một request tiêu thụ trên tài nguyên $r$, với $n_r$ đơn vị làm việc độc lập của loại tài nguyên đó. Tốc độ đến và thời gian chiếm dụng tài nguyên phải thỏa mãn

$$\lambda d_r < n_r,$$

trong đó $\lambda$ là tốc độ đến của request. Nếu nhiều phép toán dùng cùng một tài nguyên, trước tiên phải cộng các thời gian chiếm dụng; nếu các phép toán dùng các tài nguyên độc lập lẫn nhau, phải liệt kê một ràng buộc riêng cho từng loại tài nguyên. Mức chiếm dụng tài nguyên được đo bằng “số tài nguyên × số giây bị chiếm”; tài nguyên trong chương này là GPU, và tích này được gọi là GPU-giây (GPU-seconds). Ví dụ, nếu mỗi giây có bốn request đến và mỗi request chiếm 0,5 GPU-giây, cần hai GPU làm việc liên tục. Với đúng hai thẻ, các đợt request tăng thêm đến sẽ liên tục bị tồn đọng, vì cả hai thẻ đều bận với dòng request ổn định tiếp theo; chỉ thêm GPU mới có thể hấp thụ được đợt bùng nổ.

Giả sử mỗi request chiếm $d_P$ và $d_D$ giây tương ứng cho prefill và decode trên một loại replica nhất định, và hai giai đoạn thực thi tuần tự trên replica đó; khi đó cận trên của tốc độ request cho $N$ replica co-location giống hệt nhau là

$$\mu_{\mathrm{co}}=\frac{N}{d_P+d_D}.$$

Mục 9.2.3 sẽ suy ra thời gian phục vụ từng giai đoạn của hai loại thẻ được giới thiệu ở đầu chương này từ các con số đỉnh trên bảng thông số. Một A100 cần khoảng 0,86 giây để xử lý một prefill 8192 token, và 1024 lần gọi decode của một request cùng chiếm khoảng 1,76 GPU-giây; một H20 cần khoảng 1,81 giây cho prefill, và decode của nó chỉ chiếm khoảng 0,88 GPU-giây. Vì mỗi replica đầy đủ phải xử lý cả hai giai đoạn, một A100 chiếm 2,62 GPU-giây mỗi request, và một H20 chiếm 2,68 GPU-giây. Tám thẻ cùng hoàn tất khoảng 3,02 request mỗi giây, thấp hơn tốc độ đến 3,5 request mỗi giây, tồn đọng khoảng 0,5 request mỗi giây. Câu hỏi vì thế trở nên cụ thể: với cùng tám thẻ, việc chia lại công việc có thể lấp đầy khoảng trống 0,5 request/s này không?

Một replica cũng có thể được xây dựng từ nhiều thẻ phối hợp. Ví dụ, một triển khai TP2×EP4 của Qwen3-235B-A22B (TP chia đôi các ma trận expert, EP chia các expert thành bốn nhóm) dùng tám thẻ để xử lý cùng một lô request: cứ hai thẻ dùng chung một ma trận expert, và bốn nhóm EP mỗi nhóm giữ các expert khác nhau. Attention và KV được nhân bản một lần cho mỗi nhóm EP, nên context 8192 token của một request chiếm 5,875 GiB trên toàn instance — gấp bốn lần một bản KV logic. Tám thẻ này cùng tạo thành một instance inference; thêm một replica có khả năng xử lý request độc lập sẽ cần thiết lập một bộ trọng số và trạng thái hoàn toàn riêng biệt.

9.1.2 Phân chia phép tính và chia sẻ trạng thái

Thêm replica đầy đủ thay đổi cách phân bổ các request; tách rời PD thay đổi nơi prefill và decode thực thi; tách rời AF thay đổi nơi attention và FFN/expert thực thi; chia sẻ KV thay đổi phạm vi mà context state được lưu và đọc. Mỗi phương án triển khai thay đổi một bộ phận khác nhau của hệ thống, và có thể được đưa vào từng phần một hoặc kết hợp lại.

Phương án triển khai	Lợi ích mong muốn	Ràng buộc mới chính được đưa vào
Thêm replica đầy đủ	Xử lý nhiều request độc lập hơn, dàn trải xếp hàng chờ	Nhân bản model, cache phân tán, khởi động, và duy trì các instance chạy
Tách rời PD	Cấu hình năng lực riêng cho hai giai đoạn	Bàn giao KV, chiếm bộ nhớ đồng thời ở cả hai đầu, hai hàng đợi
Tách rời AF	Để các toán tử dùng tài nguyên tính toán và lưu trữ phù hợp với chúng	Khứ hồi activation từng tầng, đồng bộ hóa, cân bằng tải giữa các giai đoạn pipeline
Chia sẻ KV	Tái sử dụng context giữa các instance, giảm prefill lặp lại	Định danh cache, thao tác đọc, thông báo sẵn sàng, vô hiệu hóa, và giải phóng không gian

Việc chọn phương án triển khai bắt đầu từ việc phân tích nhu cầu tài nguyên của khối lượng công việc hiện tại. Nếu hai giai đoạn có nhu cầu tài nguyên tương tự nhau, replica đầy đủ có thể đã cân bằng phục vụ đầy đủ, và tách rời có thể chỉ thêm chi phí bàn giao. Nếu nhiều request dùng chung các tiền tố dài, cache xuyên instance có thể đáng giá hơn việc chia nhỏ phép tính thêm nữa. Tính riêng mức chiếm dụng tài nguyên và thời gian bàn giao giúp phán đoán xem tình huống hiện tại cần thêm replica, tách giai đoạn, hay chia sẻ trạng thái.

9.1.3 Đường thực thi và thời gian lưu trú trạng thái của một request đơn lẻ

Sau khi chốt sự phân công lao động, hãy đi theo dòng thời gian của một request để xem nó đi qua những giai đoạn nào và để lại trạng thái gì. Hình 9-5 đặt các giai đoạn tính toán và thời gian lưu trú trạng thái của một request nhiều lượt trên cùng một dòng thời gian. Với đầu vào hình ảnh, giai đoạn mã hóa E chuyển ảnh thành các đặc trưng model dùng, và EC giữ các kết quả mã hóa này để tái sử dụng. P xử lý các kết quả được mã hóa này cùng với văn bản, D sinh đầu ra từng bước; sau khi một tool trả kết quả, một vòng P mới xử lý thông tin mới được thêm vào. Trọng số thường được giữ lại giữa các request, activation chủ yếu truyền giữa các toán tử liền kề, và KV tăng trưởng theo các vị trí đã được xử lý. Trong lúc chờ tool, phép tính có thể tạm dừng, nhưng context state vẫn có thể chiếm bộ nhớ.

Lấy Qwen3-8B của chương này làm ví dụ: context KV 8192 token định dạng BF16 chiếm 1,125 GiB. Trong 10 giây thực thi tool, GPU có thể xử lý các request khác, nhưng context KV này vẫn chiếm 1,125 GiB bộ nhớ, cho tích dung lượng nhân thời gian là 11,25 GiB·s; mười phiên chờ như vậy đồng thời chiếm 11,25 GiB. Trạng thái vẫn phải được giữ lại một khi phép tính dừng — đây chính là bài toán mà chia sẻ cache và các chính sách trục xuất (eviction) phải giải quyết.

Nếu request này rồi trả về 1025 token, P tạo ra token đầu ra đầu tiên, và 1024 lần gọi decode tiếp theo xử lý 1024 token đã sinh đầu tiên. Tại thời điểm này, KV liền mạch bao phủ $8192+1024=9216$ token, với token cuối cùng được trả về chưa được ghi vào KV. Lượt tiếp theo tiếp tục sau 9216 token này, trước tiên xử lý token đuôi chưa được ghi này cùng với đầu vào mới; quá trình sinh tiếp tục tính toán từ điểm này.

9.2 Tách rời Prefill–Decode và tỷ lệ tài nguyên

9.2.1 Vì sao cần tách prefill và decode

Prefill có thể xử lý nhiều token mới trong một lần gọi, và phép toán ma trận lớn liên quan có xu hướng tái sử dụng trọng số triệt để hơn. Trong giai đoạn decode, mỗi request thường chỉ xử lý một token mới mỗi bước, đòi hỏi đọc lặp lại trọng số và context state. Khi hai giai đoạn trộn lẫn nhau, một prefill dài có thể làm trì hoãn token đầu ra tiếp theo của các request đang chạy; ngược lại nếu quá ưu ái decode, thời gian chờ đợi của các request mới bị kéo dài.

Mục 8.2 đã dùng chunked prefill (chia khối prefill) để rút ngắn thời gian một đầu vào dài có thể chặn decode. Mục này giữ nguyên model và request, và tiếp tục thay đổi vị trí thực thi. Tách rời PD đặt hai giai đoạn vào các cụm dịch vụ khác nhau, cho chúng hàng đợi, batching và tỷ lệ tài nguyên độc lập. DistServe và Splitwise là các hệ thống inference nghiên cứu triển khai P/D tách rời. Trong một cụm đồng nhất gồm tám thẻ A100, việc tách rời loại bỏ nhiễu lập lịch giữa hai giai đoạn thông qua các hàng đợi độc lập. Trong một cụm không đồng nhất gồm A100 và H20, mỗi loại thẻ còn có thể chỉ xử lý giai đoạn mà nó giỏi.

Sự phân công lao động này giống như một người đọc xong tài liệu rồi đưa cho người khác tiếp tục: người tiếp nhận cần bản ghi công việc hiện có để tiếp tục. Với model của chương này, bản ghi cần bàn giao đó chính là context KV. P và D mỗi bên xử lý một giai đoạn khác nhau của cùng một request, và mỗi giai đoạn phải thực thi lượt truyền thẳng (forward pass) hoàn chỉnh. P của Qwen3-8B xử lý 8192 token đầu vào, và D sau đó thực hiện 1024 lần gọi; mỗi lượt đi qua attention và mạng feedforward. Do đó cả hai cụm đều cần toàn bộ trọng số model, và KV được bàn giao từ P sang D. Lợi ích của batching độc lập trước tiên phải lớn hơn phần bàn giao mới được thêm vào này.

Một ứng dụng yêu cầu một lần inference model hoàn chỉnh thông qua một lần gọi duy nhất, trong khi dịch vụ bên trong có thể sắp xếp các tài nguyên khác nhau theo giai đoạn. Các phụ thuộc dữ liệu của model quyết định ranh giới giữa các giai đoạn nằm ở đâu, KV xác định trạng thái phải được bàn giao giữa hai giai đoạn, và tỷ trọng tải xác định mỗi cụm cần bao nhiêu tài nguyên. Tận dụng thông tin này, một dịch vụ có thể, dưới một giao diện gọi thống nhất, chọn kích thước lô và tài nguyên tính toán riêng cho việc xử lý đầu vào và cho quá trình sinh từng bước.

9.2.2 Truyền KV và chiếm bộ nhớ ở cả hai đầu

Một khi P xử lý xong đầu vào, D cần context KV để tiếp tục quá trình sinh. GQA cho phép nhiều query head dùng chung một bộ key và value, lưu trữ toàn bộ key và value cho mỗi token context. Gọi $n$ là số tầng, $L$ là độ dài context, $h_{kv}$ là số KV head, $d_h$ là số chiều mỗi head, và $b$ là số byte mỗi phần tử; khi đó kích thước trạng thái logic là

$$V_{KV}=2nLh_{kv}d_hb.$$

Hệ số 2 tương ứng với K và V. Cấu hình cố định của Qwen3-8B là 36 tầng, 8 KV head, 128 chiều mỗi head. Trạng thái BF16 chiếm 144 KiB KV mỗi token; 8192 token chiếm

$$V_{KV}=8192\times144\ \mathrm{KiB}=1.125\ \mathrm{GiB}.$$

Ví dụ 9.1: Bàn giao KV giữa prefill và decode mất bao lâu? Máy chủ A100 và máy chủ H20 được kết nối qua NIC RDMA 200 Gbit/s, với băng thông payload một chiều lấy là 25 GB/s, dùng bàn giao trực tiếp toàn trạng thái. Thời gian truyền payload thuần là

$$T_{\mathrm{payload}}=\frac{1.125\times2^{30}}{25\times10^9} \approx48.3\ \mathrm{ms}.$$

Cộng thêm một bước khởi động và đồng bộ 5 μs, tổng thời gian vẫn khoảng 48,3 ms: với lượng dữ liệu KV hoàn chỉnh này, chi phí cố định chỉ chiếm khoảng một phần vạn, nên nâng băng thông payload mới là điều giúp rút ngắn thời gian chờ đợi nhất. Ngược lại, với lượng dữ liệu nhỏ trong mỗi lần truyền của bàn giao từng tầng trong AF, chi phí cố định chiếm tỷ trọng lớn hơn nhiều.

Các kích thước trạng thái trên đến từ phương pháp lưu trữ của GQA. MLA (Mục 2.3.2) không lưu các key và value đã khai triển, mà lưu biến tiềm ẩn (latent variable) trước phép chiếu lên (up-projection): mỗi token ở mỗi tầng chỉ có một vector tiềm ẩn $d_c$ chiều và một nhánh vị trí $d_r$ chiều, cho kích thước trạng thái là

$$V_{KV,\mathrm{MLA}}=nL(d_c+d_r)b.$$

Cấu hình cố định của DeepSeek-V3 là 61 tầng, $d_c=512$, $d_r=64$; dưới BF16 mỗi token chiếm $61\times576\times2=70{,}272$ byte, khoảng 68,6 KiB, và cùng context 8192 token chiếm 549 MiB. Dùng liên kết 25 GB/s từ Ví dụ 9.1, truyền payload thuần mất khoảng 23,0 ms; ở 50 GB/s giảm còn 11,5 ms; trên cùng liên kết đó, trạng thái GQA cần 24,2 ms.

Trạng thái bàn giao	Mỗi token	8192 token	25 GB/s	50 GB/s
Qwen3-8B, GQA BF16	144 KiB	1.125 GiB	48.3 ms	24.2 ms
DeepSeek-V3, MLA gọn BF16	68.6 KiB	549 MiB	23.0 ms	11.5 ms

Trạng thái của MLA nhỏ hơn vì cache nằm ở phía bên kia của phép biến đổi tuyến tính: GQA lưu $K$, $V$ đã khai triển cho mỗi KV head, còn MLA chỉ lưu biến tiềm ẩn trước phép chiếu lên; nhờ tính kết hợp (associativity), phép chiếu lên có thể được dời sang phía query hiện tại để thực thi. Nếu 128 head của DeepSeek-V3 cũng được lưu dưới dạng khai triển, mỗi token sẽ chiếm $61\times128\times(192+128)\times2$ byte, khoảng 4,77 MiB — gấp 71 lần biểu diễn gọn; so với GQA của Qwen3-8B vốn chỉ có 8 KV head, MLA gọn vẫn chỉ bằng 0,48 lần. Trong phần còn lại của chương, ở bất kỳ công thức nào có byte KV, kết quả cho cả hai trạng thái sẽ được trình bày song song.

Với bàn giao đệm kép toàn trạng thái, nguồn giữ toàn bộ trạng thái và đích cấp phát một bộ đệm nhận hoàn chỉnh cho đến khi truyền xong. Các hình 9-6 đến 9-8 lần lượt mô tả thời điểm bắt đầu bàn giao, hoàn tất truyền, và giải phóng nguồn. Một khi payload được ghi đầy đủ vào đích, P phát một dấu hiệu hoàn tất (completion marker); D chỉ đọc trạng thái sau khi thấy dấu hiệu này (Hình 9-7); P chỉ giải phóng bộ đệm nguồn sau khi quyền thực thi được chuyển giao cho D (Hình 9-8). Với truyền chia khối, một khi đích xác nhận đã nhận một khối nhất định, nguồn có thể giải phóng sớm khối đó, rút ngắn khoảng thời gian cả hai đầu giữ trạng thái trùng lặp; đích dựa vào các dấu hiệu hoàn tất để xác định những khối liền mạch nào đã dùng được. Nếu đi qua bộ nhớ host, trạng thái lần lượt chiếm bộ đệm nguồn, bộ nhớ host và bộ đệm đích, và việc sao chép từ bộ nhớ host sang GPU trở thành một cạnh phụ thuộc mới.

Khi các request đến liên tục, băng thông liên kết giới hạn cả số lần bàn giao trạng thái hoàn tất được mỗi giây lẫn thời gian mỗi lần bàn giao mất bao lâu. Tám lần bàn giao như vậy mỗi giây cần khoảng 9,7 GB/s băng thông truyền; mười sáu lần mỗi giây cần khoảng 19,3 GB/s. Một cổng 100 GbE (Ethernet 100 Gbit/s), với 12,5 GB/s mỗi chiều, có thể đáp ứng nhu cầu trung bình của trường hợp đầu, nhưng mỗi request vẫn phải chờ lần truyền của nó hoàn tất; trường hợp sau khác biệt: dù năng lực tính toán của cả hai cụm đều nhàn rỗi, hàng đợi mạng vẫn sẽ tăng mãi. Trong kịch bản thứ nhất, mỗi trạng thái mất khoảng 96,6 ms để truyền xong; trong kịch bản thứ hai, mỗi giây tích lũy khoảng 6,8 GB dữ liệu chưa truyền. Thời gian truyền quyết định thời gian chờ tối thiểu cho một request đơn lẻ, còn hiệu giữa tốc độ dữ liệu đến và tốc độ truyền quyết định hàng đợi tăng nhanh đến đâu. Chuyển sang trạng thái MLA gọn 549 MiB, tám và mười sáu lần bàn giao mỗi giây chỉ cần khoảng 4,6 và 9,2 GB/s, và cùng cổng 100 GbE có thể đáp ứng nhu cầu trung bình của cả hai, với mỗi trạng thái truyền xong trong khoảng 46,1 ms. Hàng đợi có tăng hay không được quyết định chung bởi số byte trạng thái và băng thông liên kết; thay đổi biểu diễn context của model có thể lật ngược kết luận trên chính cùng một liên kết.

9.2.3 Thông lượng từng giai đoạn và tỷ lệ instance

Trước khi so sánh tốc độ xử lý từng giai đoạn, trước tiên tính xem một request đơn lẻ cần bao nhiêu công việc ở mỗi giai đoạn. Giả sử một request có $L_{new}$ token mà P phải xử lý mới, và $G-1$ lần gọi decode. Nếu thông lượng hiệu dụng của một loại thẻ nhất định là $r_P$ token mới/s và $r_D$ lần gọi decode/s, nhu cầu tài nguyên mỗi request của worker đó là

$$d_P=\frac{L_{new}}{r_P},\qquad d_D=\frac{G-1}{r_D}.$$

Ở đây các thời gian chiếm dụng tài nguyên có thể cộng trực tiếp; token đầu vào/s và token đầu ra/s trước tiên phải được chuyển thành nhu cầu của một request đơn lẻ. Khi nhiều request trong một lô dùng chung một lần gọi decode, bước decode đã hoàn tất được ghi có cho tất cả các request, nhưng thời gian chiếm dụng tài nguyên chỉ được tính một lần cho lần thực thi lô duy nhất đó.

$r_P$ và $r_D$ của hai loại thẻ có thể được suy ra từ bảng thông số. Mô hình Roofline ở Chương 4 cho cận dưới của thời gian từng giai đoạn: giá trị lớn hơn giữa thời gian tính toán và thời gian truy cập bộ nhớ. Bảng dưới đây liệt kê các con số đỉnh của hai thẻ. Thông lượng tính toán của H20 chưa bằng một nửa A100, trong khi băng thông bộ nhớ của nó gấp khoảng đôi A100 — chính vì vậy H20 hợp với decode nhưng không hợp với prefill.

Thẻ	Tính toán dense BF16	Băng thông bộ nhớ	Dung lượng bộ nhớ
A100 80GB SXM	312 TFLOP/s	2039 GB/s	80 GB
H20 SXM5 96GB	148 TFLOP/s	4096 GB/s	96 GB

Các kernel thực tế không đạt tới đỉnh. Mục 8.6.3 đã hiệu chuẩn hai con số hiệu quả bằng các bản ghi từng vòng trên RTX PRO 6000: hiệu quả băng thông của decode tăng từ 33% ở batch size 1 lên 65% ở batch size 64, nội suy thành khoảng 49% ở batch size 32 dựa trên các phép đo ở cả hai phía; hiệu quả tính toán của prefill giữ ổn định ở mức 58%–62%. Chương này lấy cả hai là 50% đỉnh: con số decode khớp với giá trị nội suy ở batch size 32, còn con số prefill chạy thấp hơn khoảng mười phần trăm so với phép đo. Với lựa chọn này, tính toán và băng thông hiệu dụng của A100 là 156 TFLOP/s và 1020 GB/s, còn của H20 là 74 TFLOP/s và 2048 GB/s.

Lấy 50% nghĩa là đặt cả MFU lẫn MBU từ Mục 1.2.2 thành 0,5, nghĩa là một nửa khả năng phần cứng không bao giờ trở thành tính toán model. Theo tiêu chí ở Mục 1.3.4, nửa này có hai nguồn: một là công việc không được tính trong mô hình bậc nhất của chương này, chẳng hạn các hàng đệm zero do việc lát tile (tiling) kernel hoặc giao tiếp không được chồng lấp với tính toán; nguồn kia là chi phí phía host có thể loại bỏ, chẳng hạn nộp kernel từng cái một, hoặc dựng lại các nhóm giao tiếp và đồ thị thực thi trước khi chuyển đổi. Mục 9.4.3 và 9.6.2 mỗi mục cho một ví dụ.

Thay hai bộ thông lượng hiệu dụng này vào request được giới thiệu ở đầu chương: prefill xử lý 8192 token đầu vào, cần 133,6 TFLOP phép toán ma trận nhưng chỉ đọc khoảng 15 GB trọng số một lần, nên nó bị giới hạn bởi tính toán (compute-bound). A100 cần 0,856 giây, xử lý khoảng 9570 token mới mỗi giây; H20 cần 1,81 giây, khoảng 4540 mỗi giây. Một bước decode sinh một token cho mỗi request trong lô 32 request. Lấy context trung bình trong lúc sinh là $8192+512=8704$ token, bước này đọc khoảng 15,1 GB trọng số và 41,1 GB KV, trong khi phép toán ma trận chỉ là 0,65 TFLOP — bị giới hạn bởi băng thông (bandwidth-bound). A100 cần 55,1 ms mỗi bước, hoàn tất khoảng 580 lần gọi decode mỗi giây; H20 chỉ cần 27,4 ms mỗi bước, khoảng 1166 mỗi giây. Thế mạnh của hai loại thẻ đảo ngược chính xác: prefill của A100 nhanh hơn gấp đôi H20, còn decode của H20 nhanh gấp đôi A100. Ở batch size 32, khi một request sinh xong, KV chiếm tổng cộng 43,5 GB, cộng khoảng 15,1 GB trọng số thành khoảng 59,9 GB — đều nằm gọn trong dung lượng của mỗi loại thẻ.

Xét trường hợp đồng nhất trước: tám thẻ A100 thực thi cùng một model. Co-location, mỗi thẻ chiếm $0.856+1.764=2.62$ GPU-giây mỗi request, cho 3,05 request/s đối với cả tám thẻ. Sau khi tách rời, hai cụm chỉ có thể chia theo nguyên thẻ: ba thẻ làm P cung cấp 3,50 request/s, năm thẻ làm D cung cấp 2,83 request/s, cho cận trên 2,83 request/s — thấp hơn co-location 7%. Mỗi request tiêu thụ cùng số GPU-giây trước và sau khi tách rời, nên tách rời trên cụm đồng nhất không thể nâng thông lượng; việc phân hoạch theo số nguyên cũng ngăn không cho năng lực của hai cụm bằng nhau chính xác, và năng lực dư thừa chỉ đơn giản nằm im.

Thứ tách rời trên cụm đồng nhất mua được thay vào đó là độ trễ ổn định hơn. Dưới co-location không chunking, một prefill 8192 token chiếm độc quyền một A100 trong khoảng 0,86 giây, trong thời gian đó mọi request đang chạy trên thẻ đó đều ngừng sinh — tương đương bỏ lỡ khoảng 16 bước decode, mỗi bước 55 ms. Nếu tám thẻ này nhận 2,5 request mỗi giây, mỗi thẻ trung bình phải chèn một prefill như vậy mỗi 3,2 giây. Sau khi tách rời, các thẻ D giữ ổn định ở 55 ms mỗi bước; các thẻ P xử lý đầu vào độc quyền, và thời gian đến token đầu tiên (time-to-first-token) là prefill 0,86 giây cộng bàn giao KV.

Chunked prefill từ Mục 8.2 cung cấp một đường khác bên cạnh tách rời. Trên A100, một bước decode cần 55,1 ms cho truy cập bộ nhớ nhưng chỉ 4,2 ms cho phép toán ma trận, phần thời gian còn lại là tính toán nhàn rỗi. Ở 156 TFLOP/s, khoảng nhàn rỗi này đủ để xử lý khoảng 490 token prefill. Tách một đầu vào 8192 token thành 17 khối và chở chúng kèm qua 17 bước decode cho thời gian đến token đầu tiên khoảng 0,94 giây, tương đương với tách rời, trong khi khoảng cách giữa các token đầu ra của các request đang chạy không đổi. Nếu phép tính chở kèm được ẩn hoàn toàn trong thời gian truy cập bộ nhớ, cận trên của tám thẻ A100 co-location tăng lên 4,50 request/s, vượt xa 2,83 của tách rời. Bao nhiêu thực sự có thể được ẩn phụ thuộc vào việc chunking và decode chạy cùng nhau có thể đồng thời bão hòa cả tính toán lẫn băng thông hay không, điều này cần phán đoán từ thời gian bước hỗn hợp đo được. Vì vậy trên một cụm đồng nhất, chunked prefill thường được áp dụng trước tiên; giá trị của tách rời nằm ở chỗ cho phép hai giai đoạn chọn chiến lược song song hóa và batch size một cách độc lập, và cách ly triệt để hàng đợi của nhau.

Ví dụ 9.2: Tỷ lệ giai đoạn quyết định cận trên thông lượng trong một cụm không đồng nhất như thế nào? Dùng 8192 token đầu vào và 1025 token đầu ra. Thông lượng từng giai đoạn của bốn A100 và bốn H20 được suy ra bằng phương pháp trên, như trong bảng dưới đây; khi thành phần request thay đổi sau này, cùng phương pháp sẽ suy lại các con số cho khối lượng công việc mới.

Thẻ	Thông lượng P, token mới/s	Thông lượng D, lần gọi/s	GPU-giây P mỗi request	GPU-giây D mỗi request
A100 80GB SXM	9566	580	0.856	1.764
H20 SXM5 96GB	4538	1166	1.805	0.878

Co-location, một A100 chiếm 2,62 GPU-giây mỗi request, một H20 chiếm 2,68 GPU-giây, và tám thẻ cùng cho 3,02 request/s. Gán bốn thẻ A100 cho P và bốn thẻ H20 cho D, cụm P cung cấp $4/0.856\approx4.67$ request/s, cụm D cung cấp $4/0.878\approx4.55$ request/s. Mỗi request cần một lần bàn giao 1,125 GiB. Với một NIC 200 Gbit/s giữa hai máy chủ, băng thông 25 GB/s có thể bàn giao khoảng 20,7 trạng thái mỗi giây, cho cận trên thông lượng tổng thể là

$$\mu_{PD}=\min\left(\mu_P,\mu_D,\frac{B_{net}}{V_{KV}}\right)\approx4.55\ \text{requests/s}.$$

Ở đây $\mu_P$ và $\mu_D$ là các cận trên tốc độ request của cụm P và cụm D, và $B_{net}$ là băng thông của liên kết bàn giao giữa hai cụm.

Sau khi tách rời, cả hai loại thẻ đều tránh được giai đoạn chậm hơn của chúng, và cận trên tốc độ request tăng từ 3,02 lên 4,55 request/s — gấp 1,51 lần co-location, và cao hơn tốc độ đến 3,5 request mỗi giây. Model vẫn xử lý cùng 8192 token đầu vào và 1024 lần gọi decode; khác biệt là ai thực thi chúng. Đảo vai trò, H20 làm P và A100 làm D, cụm P tụt xuống chỉ còn 2,22 request/s, cho cận trên thông lượng chưa bằng một nửa sự phân công lao động đúng.

Việc chở kèm chunked so sánh trước đó trên cụm đồng nhất có hiệu quả hạn chế trên H20: tính toán nhàn rỗi của một bước decode H20 chỉ đủ xử lý khoảng 85 token prefill. Dưới chở kèm lý tưởng, cận trên của bốn A100 cộng bốn H20 co-location là 4,17 request/s, vẫn thấp hơn 4,55 của tách rời. Lợi ích của cụm không đồng nhất đến từ chính sự khác biệt của phần cứng; chunking không thể thay thế điều đó.

Một điều kiện khác có thể thay đổi là bản thân trạng thái bàn giao. Chuyển trạng thái bàn giao sang MLA gọn nâng số hạng liên kết của $\mu_{PD}$ từ 20,7 lên 43,4 request/s, và ở liên kết 50 GB/s từ 41,4 lên 86,9 request/s; cận trên vẫn do cụm D thiết lập ở 4,55 request/s, và tỷ lệ bốn A100 cho P với bốn H20 cho D không đổi. Điều kiện liên kết trở thành ràng buộc chặn là $B_{net}<\mu V_{KV}$: ở 4,55 request/s, trạng thái GQA cần liên kết tối thiểu khoảng 5,5 GB/s, còn trạng thái MLA gọn chỉ cần khoảng 2,6 GB/s. Trên giá trị này, nâng băng thông thêm không làm thay đổi cận trên thông lượng; dưới giá trị đó, trong Hình 9-10 mọi ô nằm trên $B_{net}/V_{KV}$ bị liên kết làm phẳng về cùng một giá trị.

Những gì đường gọn tiết kiệm là byte, chứ không phải toàn bộ công việc. Theo tính kết hợp ở Mục 2.3.2, phép chiếu lên đã dời sang phía query: DeepSeek-V3 phải thực hiện thêm, mỗi tầng mỗi token query, một phép biến đổi query $128\times128\times512$ và một phép khôi phục value cùng kích thước, tổng cộng 33,5 MFLOP; qua 61 tầng là 2,05 GFLOP — bằng với phép tính khai triển mỗi token của phép chiếu lên KV (kv_b_proj) trong Bảng 2-3. Phép tính phụ này tăng tuyến tính theo số request trong lô: một lần gọi decode phục vụ $B$ request thêm $2.05B$ GFLOP. Ở 74 TFLOP/s hiệu dụng của H20, mỗi request thêm 27,7 μs mỗi bước, tổng cộng 28,3 ms qua 1024 bước. Nếu phép tính phụ này không thể được ẩn trong thời gian truy cập bộ nhớ, GPU-giây mỗi request của cụm D tăng từ 0,878 lên khoảng 0,907, và thông lượng cụm D giảm từ 4,55 xuống khoảng 4,41 request/s — vẫn trên tốc độ đến 3,5; thẻ D thứ năm chỉ cần đến khi phép tính phụ mỗi request mỗi bước vượt khoảng 258 μs. Điều đường gọn thay đổi là nút thắt của instance D nằm ở đâu: việc đọc mỗi token giảm từ 4,77 MiB của trạng thái khai triển xuống 68,6 KiB, trong khi số hạng tính toán tăng theo batch size, nên instance D chuyển từ bị giới hạn bởi đọc sang bị giới hạn bởi tính toán ở một batch size nhỏ hơn. $r_D$ của Ví dụ 9.2 được suy ra ở batch size 32; chuyển sang MLA gọn đòi hỏi suy lại nó ở batch size giao điểm mới.

Hình 9-10 cũng cho thấy tốc độ thông lượng thay đổi ra sao khi tỷ lệ rời khỏi mức tối ưu. Chuyển một A100 từ P sang D làm P tụt từ 4,67 xuống 3,50 request/s và nâng D từ 4,55 lên 5,12 request/s, kết quả bị chặn ở 3,50 bởi P. Chuyển một H20 từ D sang P nâng P lên 5,22 request/s nhưng làm D tụt xuống 3,42 request/s — lần nữa chậm hơn tổng thể. Tỷ lệ tối ưu đưa năng lực của hai cụm đến gần bằng nhau. Một khi tỷ lệ rời khỏi điểm đó, một cụm có năng lực dư thừa không thể bù đắp cho sự thiếu hụt của cụm kia.

9.2.4 Ranh giới lợi ích dưới các request và tải khác nhau

Ví dụ 9.2 cố định thành phần request; giờ chúng ta chỉ thay đổi một điều kiện: trúng tiền tố (prefix hit). P đã cache sẵn 6144 token đầu và chỉ cần xử lý 2048 token còn lại. Với token mới giảm còn một phần tư, thời gian prefill của A100 giảm từ 0,856 s xuống 0,238 s, và năng lực P của một A100 tăng từ 1,17 lên 4,20 request/s; nếu P vẫn nhận bốn A100, chúng cùng có thể xử lý 16,8 request/s, trong khi D vẫn chỉ xử lý được 4,55 request/s.

Chuyển hai A100 sang D, để lại hai thẻ cung cấp 8,41 request/s năng lực P; khi đó D được cung cấp bởi hai A100 và bốn H20, cho $2/1.764+4/0.878\approx5.69$ request/s. Trần thông lượng tổng thể tăng lên 5,69 request/s. Chuyển thêm một A100 nữa khiến P chỉ còn 4,20 request/s — chậm hơn thay vào đó. Giả sử D chưa cache tiền tố này, nên cả hai tỷ lệ vẫn phải bàn giao toàn bộ 1,125 GiB; phép tính của P giảm hơn bảy mươi phần trăm, nhưng kích thước KV chuyển cho D không đổi.

Giờ khôi phục đầu vào ban đầu và rút ngắn đầu ra xuống còn 129 token — một cuộc trò chuyện thông thường không có vết suy luận. Số lần gọi D giảm từ 1024 xuống 128, năng lực D của một H20 tăng lên khoảng 9,46 request/s, và D gần như không còn là nút thắt. Tỷ lệ tối ưu trở thành bốn A100 cộng ba H20 làm P, một H20 làm D, với cụm P cung cấp $4\times1.168+3\times0.554\approx6.33$ request/s. Co-location ở điểm này đã đạt 5,84 request/s, nên tách rời chỉ cải thiện thêm 8,5%.

Hình 9-11 vẽ ba sự điều chỉnh trên cùng một tập tài nguyên tính toán. Mỗi ô vuông là cùng một thẻ như trước; chỉ có giai đoạn nó xử lý thay đổi. Sau khi trúng tiền tố, khối lượng công việc của P co lại, giải phóng hai A100; một khi đầu ra ngắn lại, khối lượng công việc của D co lại, và ba H20 chuyển sang làm P.

Số thẻ P phù hợp nhất cho ba request này lần lượt là bốn, hai và bảy. Một cú trúng tiền tố giảm công việc mới của P và đẩy tài nguyên về phía D; một đầu ra ngắn hơn giảm công việc lặp lại của D và đẩy tài nguyên về phía P. Đầu ra của request inference càng dài, phần của D càng lớn, và các thẻ mạnh băng thông, yếu tính toán như H20 càng trở nên đáng giá. Điều này cho phép tách lập lịch thành hai thang thời gian: vào hàng đợi nào khi một request đến, và điều chỉnh kích thước cụm khi phân bố tải tiếp tục dịch chuyển. Việc gán hàng đợi quyết định thời gian chờ trước mắt; kích thước cụm quyết định liệu backlog có thể tiêu giảm trong dài hạn hay không.

9.3 Tách rời Attention–FFN và thực thi không đồng nhất

9.3.1 Ranh giới thực thi giữa Attention, FFN và Expert

AF chỉ sự phân công lao động giữa attention và mạng feedforward. Khác với PD vốn tách hai giai đoạn sinh tại một thời điểm, AF tách phép tính bên trong một tầng model: attention tạo ra hidden state, mạng feedforward hoặc các expert được chọn xử lý hidden state đó, và kết quả được gửi trả cho các toán tử tiếp theo dùng. Tầng tiếp theo thường phải chờ kết quả này, nên chi phí khởi động và đồng bộ của các lần truyền dữ liệu nhỏ được lặp lại nhiều lần.

MoE đặc biệt phù hợp với sự phân công lao động này: tổng trọng số expert lớn, nhưng mỗi token chỉ chọn một tập con trong đó. Nếu phần lớn expert nằm trong bộ nhớ host, các trọng số được chọn có thể được chuyển lên GPU, hoặc CPU có thể dùng trọng số cục bộ của chính nó để tính toán và chuyển sang một activation nhỏ hơn. Đường trước đổi băng thông liên kết lấy phép tính GPU; đường sau đổi phép tính CPU lấy ít lưu lượng liên kết hơn. Chọn cái nào phụ thuộc vào có bao nhiêu token trong lô này được dispatch tới cùng một expert: vector đặc trưng của mỗi token chiếm một hàng của ma trận đầu vào của expert đó, và các hàng này dùng chung cùng một tập trọng số expert.

9.3.2 Hợp tác CPU/GPU

Hai đường trong mục trước cho cùng một đầu ra; chúng khác nhau ở thứ qua liên kết: Hình 9-12 gửi trọng số, Hình 9-13 gửi đầu vào và đầu ra. Mục 8.4.3 dùng đường thứ nhất, dàn trọng số trong bộ nhớ host và chuyển chúng lên GPU khi cần. KTransformers là một hệ thống thực tế đi theo đường thứ hai: GPU xử lý attention và một số expert thường trú, CPU xử lý các expert được gán cho nó; sau khi nộp phần việc của CPU, GPU tiếp tục thực thi các nhánh có thể chạy song song, và cuối cùng đồng bộ và gộp kết quả. Expert điểm nóng, expert dùng chung và giai đoạn prefill mỗi loại có thể dùng một sự phân chia tài nguyên tính toán khác nhau. Khi các nhánh hội tụ, tầng tiếp theo phải chờ cả hai phía hoàn tất trước khi có thể bắt đầu.

Chi phí của cả hai đường phụ thuộc vào kích thước một bộ trọng số expert. Với Qwen3-235B-A22B, một expert chứa ba ma trận, với số tham số là $3\times4096\times1536=18874368$. Trọng số BF16 là 36 MiB.

Ví dụ 9.3: Việc tái sử dụng trọng số expert thay đổi lựa chọn thực thi CPU/GPU như thế nào? Dùng máy thí nghiệm trong bài báo KTransformers: hai CPU Intel Xeon Platinum 8452Y, mỗi cái 36 lõi và 1 TB DDR5, kết nối qua PCIe 4.0 đến một A100 40GB PCIe. Bài báo đo được, dùng công cụ kiểm tra bộ nhớ MLC của Intel, băng thông bộ nhớ 220 GB/s trong một socket CPU duy nhất. Chạy tầng MoE trên một CPU duy nhất, kernel của PyTorch dựa trên AVX-512 (một tập lệnh vector 512 bit) đạt tối đa 1,8 TFLOP/s; kernel của KTransformers dựa trên các lệnh ma trận AMX (Advanced Matrix Extensions) đạt tối đa 21,3 TFLOP/s. Với GPU, chúng ta lấy 50% đỉnh 312 TFLOP/s và 1555 GB/s của A100 40GB PCIe, tức 156 TFLOP/s và 778 GB/s. Băng thông lý thuyết của PCIe 4.0 x16 là 32 GB/s; việc bàn giao được tính ở 25 GB/s, với 5 μs khởi động mỗi lần phát động, và độ rộng activation BF16 là 4096. Tám expert thực thi tuần tự, với tổng thời gian là tổng thời gian của mỗi expert, và trọng số được đọc một lần mỗi lô. Khi mỗi expert chỉ nhận vector đặc trưng của một token, CPU đọc trọng số trực tiếp từ bộ nhớ host cục bộ, tránh việc di chuyển 36 MiB qua liên kết chậm hơn; khi số hàng đầu vào mỗi expert tăng lên, chi phí di chuyển trọng số một lần được trả dần trên nhiều hàng tính toán hơn, trong khi CPU sớm chạm trần tính toán của nó.

Trước tiên xét tám expert điểm nóng mỗi cái xử lý một token: trọng số tổng cộng 288 MiB. Đọc phần này qua bộ nhớ host 220 GB/s mất khoảng 1,37 ms, và với bàn giao activation, đường CPU mất khoảng 1,46 ms; đường chuyển lên GPU, chỉ riêng truyền trọng số, mất khoảng 12,1 ms, và cộng khởi động và tính toán GPU, khoảng 12,5 ms. Ở mức tái sử dụng thấp, tránh một lần truyền trọng số lớn đáng giá hơn việc nâng thông lượng ma trận.

Nếu tám expert này mỗi cái xử lý 128 token, trọng số vẫn là 288 MiB, nhưng phép tính tăng gấp 128 lần. Với kernel AVX-512, đường CPU tăng lên khoảng 22,2 ms, còn đường GPU khoảng 12,5 ms — giờ tính toán trên GPU nhanh hơn. Hình 9-14 vẽ diễn tiến trung gian: khi đầu vào mỗi expert tăng từ 71 lên 72 token, GPU bắt đầu đánh bại CPU. Chuyển sang kernel AMX, ở 128 token đường CPU chỉ cần khoảng 2,57 ms, khoảng một phần năm đường di chuyển trọng số, và điểm giao nhau bị đẩy lùi về 689 token mỗi expert. Chạy cùng các request trên cùng một máy, tập lệnh CPU dùng thế nào quyết định một expert nên nằm ở phía nào. Mỗi token thêm mà một expert xử lý làm tăng thời gian tính toán trên CPU nhiều hơn trên GPU, trong khi chi phí di chuyển trọng số cố định, nên sau điểm giao nhau GPU thắng thế.

Hãy viết các con số trên dưới dạng tổng quát. Gọi số tham số của expert là $P_e$, số byte trọng số là $W_e$, độ rộng đầu vào là $h$, và số byte mỗi phần tử là $b$. Nếu cùng một expert nhận $m$ token trong lô này, phép toán ma trận của nó là $F_e(m)=2mP_e$ FLOP, và trọng số phải được đọc ít nhất một lần. Gọi tính toán CPU hiệu dụng và băng thông DRAM là $C_C,B_D$, tính toán GPU và băng thông HBM là $C_G,B_H$, và băng thông bàn giao là $B_L$. Giả sử trọng số và activation đã ở định dạng cần thiết để thực thi, rằng bàn giao và phép tính expert xảy ra tuần tự, và thời gian toán tử lấy giá trị lớn hơn giữa thời gian tính toán và thời gian đọc trọng số, thời gian cho một expert đơn lẻ dưới hai phương thức thực thi lần lượt là

$$T_C(m)=2\alpha+\frac{2mhb}{B_L} +\max\left(\frac{2mP_e}{C_C},\frac{W_e}{B_D}\right),$$ $$T_G(m)=\alpha+\frac{W_e}{B_L} +\max\left(\frac{2mP_e}{C_G},\frac{W_e}{B_H}\right).$$

Phương trình thứ nhất cộng truyền đầu vào, phép tính expert trên CPU, và truyền đầu ra; phương trình thứ hai trước tiên chuyển một bản trọng số, rồi thực thi phép tính GPU. $\alpha$ trong các phương trình này là chi phí cố định mỗi lần bàn giao. Activation đầu vào đến CPU trước, và activation đầu ra quay về sau khi tính toán; hai lần khởi động và hai payload khứ hồi trong phương trình tương ứng chính xác với hai cạnh phụ thuộc này.

Những thay đổi phần cứng có thể được ước tính bằng cùng một bộ phương trình. Dưới kiến trúc NUMA, một luồng đọc bộ nhớ trên CPU khác phải đi qua liên kết giữa các bộ xử lý. Bài báo đo được băng thông xuyên socket của máy này chỉ còn 125 GB/s. Thời gian của đường CPU lấy giá trị dài hơn giữa đọc trọng số và phép toán ma trận; Hình 9-15 vẽ hai số hạng này cạnh nhau ở 128 token mỗi expert. Với kernel AVX-512, phép tính dài hơn việc đọc rất nhiều, nên bộ nhớ nằm ở socket nào gần như không quan trọng; chuyển sang kernel AMX, phép tính co lại chỉ còn dài hơn một chút so với đọc cùng socket, và một khi việc đọc vượt qua các socket, đọc trở thành số hạng dài hơn. Việc tính toán tại chỗ có đáng giá hay không được quyết định bởi nút thắt đang chiếm ưu thế: khi bị giới hạn bởi đọc, nâng băng thông bộ nhớ host giúp ích; khi bị giới hạn bởi tính toán, nâng thông lượng ma trận giúp ích. Định dạng lượng tử hóa thay đổi cả hai số hạng cùng lúc: ít byte trọng số hơn, và thông lượng hiệu dụng của kernel ma trận thay đổi theo.

9.3.3 Ảnh hưởng của dung lượng, độ đồng thời và mức tái sử dụng expert đến năng lực dịch vụ

Việc trọng số có vừa hay không và việc request có hoàn tất kịp thời hay không là hai câu hỏi khác nhau. 128 expert BF16 mỗi tầng của Qwen3-235B-A22B cùng chiếm 4,5 GiB. Nếu 32 expert mỗi tầng được cố định thường trú trên GPU, một tầng là 1,125 GiB, và qua 94 tầng tổng cộng khoảng 106 GiB. Dù dành toàn bộ 80 GB (khoảng 74,5 GiB) bộ nhớ của một A100 80GB cho expert cũng không thể chứa tập expert thường trú này; nó vẫn cần được chia nhỏ trên nhiều thẻ, hoặc giảm số expert thường trú mỗi tầng. Cắt số expert thường trú mỗi tầng xuống 16 đưa các trọng số này về khoảng 53 GiB, nhưng cũng bàn giao thêm việc thực thi nhiều expert sang phía bộ nhớ host. Do đó lựa chọn dung lượng trực tiếp thay đổi đường thực thi của một request.

Một token chọn tám expert không có nghĩa một lô cũng chỉ chạm vào tám expert. Mục 6.3.2 đã tính ra lô dispatch này: 64 token mỗi cái chọn tám expert cho tổng cộng 512 lần dispatch; khi dàn đều trên 128 expert, mỗi expert xử lý bốn hàng, còn khi tập trung vào tám expert, mỗi expert xử lý 64 hàng — trong cả hai trường hợp phép toán hiệu dụng của các ma trận expert là $512\times2\times18874368$, khoảng 19,3 GFLOP; nhưng nếu mỗi bộ trọng số expert trong lô chỉ được đọc một lần, lượng đọc trọng số là 4,5 GiB so với 288 MiB, khác nhau 16 lần. Trên bộ nhớ host 220 GB/s của Ví dụ 9.3, riêng việc đọc trọng số mất khoảng 22,0 ms so với 1,37 ms: cùng một lượng tính toán, nhưng thời gian đọc khác nhau một bậc độ lớn.

Tổng số expert quyết định cần sắp xếp bao nhiêu trọng số, số lượng dispatch quyết định phép toán ma trận hiệu dụng của lô này, và tập expert được chạm đến trong lô quyết định cần truy cập những trọng số nào. Hình 9-14 đã cho thấy số hàng đầu vào quyết định phía nào, CPU hay GPU, nhanh hơn. Còn một đại lượng nữa cần được thêm vào: một lô request sẽ thực sự chạm đến bao nhiêu expert. Biết con số này cho phép mở rộng kết quả expert đơn lẻ lên toàn lô.

Ngoài hai trường hợp hoàn toàn dàn đều và hoàn toàn tập trung, ta cũng có thể phân tích trung bình định tuyến ngẫu nhiên chạm đến bao nhiêu expert. Theo suy dẫn ở Mục 6.3.2, khi mỗi token độc lập và đồng đều chọn $K$ expert phân biệt trong số $E$ expert, số expert hoạt động kỳ vọng trên $M$ token trong một lô là

$$\mathbb{E}[U]=E\left[1-\left(1-\frac{K}{E}\right)^M\right].$$

Thay $E=128,K=8,M=64$ cho giá trị kỳ vọng khoảng 126 expert, với lượng đọc trọng số lý tưởng khoảng 4,43 GiB, gần với trường hợp phủ đều ở trên. Khi batch size tiếp tục tăng, số expert phân biệt được chạm đến chạm trần 128 và ngừng tăng, trong khi số lượng dispatch tiếp tục tăng tuyến tính, nên các token mới thêm ngày càng tái sử dụng các trọng số đã được nạp.

Phân tích này cũng cho thấy một máy chủ trang bị bộ nhớ host lớn và ít GPU hợp với các khối lượng công việc nơi mỗi expert nhận ít hàng đầu vào. Cấu hình RTX-5090 đơn card đã công bố của DeepSeek V4-Flash yêu cầu tối thiểu 200 GB bộ nhớ host, và cấu hình của Kimi K2 với lượng tử hóa nhóm Q4_K_M (chủ yếu 4-bit, với một số tensor ở độ rộng bit cao hơn) yêu cầu khoảng 600 GB bộ nhớ host. Bộ nhớ host giải quyết bài toán vừa vặn tổng trọng số; khi batch size của request tăng, nút thắt vẫn có thể dịch chuyển từ đọc trọng số sang phép toán ma trận CPU. Điểm giao nhau trong Hình 9-14 tương ứng chính xác với sự dịch chuyển này: tăng độ đồng thời vừa trả dần chi phí đọc trọng số vừa dần dần làm cạn năng lực tính toán CPU.

9.3.4 AF xuyên máy, tách expert và pipelining micro-batch

Hai mục trước vẫn chia việc giữa CPU và GPU trong cùng một máy chủ. Trong MoE, các expert định tuyến (routed expert) cũng có thể được chuyển sang một cụm tài nguyên expert độc lập, với worker giữ attention và KV gửi activation đi và nhận kết quả expert về. Đây gọi là tách expert (Expert Disaggregation), còn thường được gọi là tách EP; cuốn sách này dùng “tách expert” để chỉ ranh giới triển khai, và dùng EP để chỉ bậc song song expert (expert-parallelism degree). Tách expert là một dạng phân công lao động giữa attention và tính toán expert được bàn trong mục này; một hệ thống cụ thể còn phải xác định thêm bên nào giữ các expert dùng chung, bộ định tuyến, và các phép chiếu trước/sau.

Lấy hai máy chủ HGX H100 từ Chương 7 làm ví dụ, và xem một tầng MoE thực thi thế nào dưới tách expert (Hình 9-16). Bốn thẻ A0–A3 của máy chủ A thực thi attention và giữ KV cho các request của chúng; bốn thẻ B0–B3 của máy chủ B mỗi thẻ giữ một phần tư các expert định tuyến. Trong một tầng, bốn bước xảy ra tuần tự. Đầu tiên, các thẻ A hoàn tất attention, và bộ định tuyến chọn 8 expert cho mỗi token. Bước thứ hai là dispatch được mô tả ở Mục 6.2.6: các thẻ A nhóm hidden state của mỗi token theo thẻ giữ các expert được chọn của nó và gửi đến thẻ B tương ứng. Cả bốn thẻ A phải gửi các khối dữ liệu kích thước không đều đến cả bốn thẻ B, tạo thành một all-to-all. Thứ ba, sau khi các thẻ B nhận đầu vào từ mỗi nguồn, chúng sắp xếp lại các hàng đầu vào theo expert và thực thi phép nhân ma trận expert. Bước thứ tư là combine: các đầu ra expert đi ngược lại cùng đường đến thẻ A sở hữu token; thẻ A thu thập đủ 8 đầu ra cho một token và tính tổng có trọng số theo trọng số định tuyến, để có thể tiến tới attention của tầng tiếp theo.

Hình này chỉ ra hai điểm chờ đợi. Một thẻ B thường chờ đến khi đầu vào từ mọi nguồn đã đến rồi mới bắt đầu tính toán, và một thẻ A chờ đến khi mọi đầu ra expert cho một token đã quay về rồi mới có thể cộng chúng. Nếu một thẻ B nhận nhiều hơn và tính chậm hơn, nó làm trì hoãn cả phép tính và việc trả kết quả của chính nó, và mọi thẻ A chờ kết quả của nó. Độ lệch (skew) được bàn ở Mục 9.4 hoạt động chính xác qua hai điểm chờ đợi này để ảnh hưởng đến thời gian hoàn tất của cả tầng.

EP lớn (Large EP) chỉ một nhóm song song expert trải qua nhiều thẻ. EP lớn cho phép mỗi thẻ chỉ giữ vài expert và gộp đầu vào từ nhiều worker attention, để các expert nhận được một lô ma trận đủ lớn. EP lớn không nhất thiết phải dùng một cụm expert độc lập: cùng một thẻ cũng có thể đồng thời thực thi attention và các expert mà nó giữ; cũng không nhất thiết một cụm expert độc lập chỉ chứa một nhóm EP lớn. Báo cáo inference đã công bố của DeepSeek-V3/R1 đưa ra prefill EP32 và decode EP144 (các bậc song song expert lần lượt là 32 và 144), và áp dụng expert dự phòng (redundant expert — các bản sao thêm được đặt cho các expert tải cao) và nhiều loại cân bằng tải; điều này cho thấy EP lớn có công dụng thực tế thật sự, nhưng quy mô này tự nó không chứng minh rằng attention và expert đã được tách lên hai bộ thiết bị riêng.

Mở rộng EP không tự động mở rộng batch size của mỗi expert. Nếu một lô có $n$ token, mỗi token chọn $k$ expert, và tổng cộng có $E$ expert logic, dưới định tuyến đồng đều mỗi expert trung bình chỉ nhận $nk/E$ hàng. Ví dụ, với $n=1024,k=8,E=256$, đó là 32 hàng; dàn cùng 256 expert đó từ 32 thẻ ra 128 thẻ vẫn để mức trung bình ở 32 — chỉ là số expert mỗi thẻ giảm đi. Gộp nhiều đầu vào hơn có thể tăng batch size của mỗi expert, nhưng cũng mở rộng phạm vi giao tiếp và đồng bộ: hai điểm chờ đợi trong Hình 9-16 phải bao phủ mọi thẻ trong nhóm EP. Ít expert mỗi thẻ hơn cũng làm tăng độ lệch xuyên thẻ; Mục 9.4.1 dùng cùng $n,k,E$ để tính độ lệch này tăng thế nào theo EP.

Một cụm expert có thể độc lập thêm replica, chọn các tỷ lệ tính toán/bộ nhớ khác nhau, và gộp tác vụ từ nhiều worker attention. Cái giá phải trả là đầu vào expert mà lẽ ra có thể thực thi cục bộ giờ phải được gửi xuyên cụm, và mạng trở thành một tài nguyên được cả hai cụm chia sẻ. Chỉ khi nhiều nhóm EP độc lập mỗi nhóm giữ một bộ expert đầy đủ thì chúng mới có thể đóng vai trò replica dịch vụ nhận tác vụ một cách độc lập; chỉ thêm các thẻ giữ một phần expert không cho phép mọi request tự do vòng qua một expert đang bận. Hàng đợi, bộ nhớ GPU, phiên bản model và chính sách tiếp nhận của một cụm expert dùng chung phải được quản lý như một tổng thể.

Một khi AF được mở rộng từ một máy chủ sang xuyên máy chủ, thời gian khởi động mỗi lần truyền, băng thông liên kết, và độ lệch thời gian tại đó mỗi nút bắt đầu thực thi đều có tác động lớn hơn. MegaScale-Infer là một hệ thống inference phân tán tách phép tính attention và expert. Hệ thống này xen kẽ các micro-batch giữa các nút attention và các nút expert, tạo thành một pipeline luân phiên: trong khi micro-batch này thực thi attention, micro-batch khác thực thi phép tính expert. Trong trường hợp lý tưởng, nếu hai giai đoạn cần $t_A,t_F$ mỗi micro-batch và ta bỏ qua việc bàn giao, xử lý $q$ micro-batch độc lập qua pipeline hai giai đoạn mất $t_A+t_F+(q-1)\max(t_A,t_F)$. Micro-batch đầu tiên tốn $t_A+t_F$, và sau đó cứ mỗi chu kỳ phục vụ của giai đoạn chậm hơn lại hoàn tất thêm một micro-batch. Xuyên các tầng, activation được trả về kết nối cuối tầng này với đầu tầng kế.

Các thí nghiệm của MegaScale-Infer cung cấp bằng chứng thực tế cho kiểu triển khai này. Bài báo năm 2025 của nó dùng Mixtral-8×22B, DBRX và một Scaled-MoE 317B, với trọng số, activation và KV đều ở BF16, và các request sản xuất có chiều dài đầu vào/đầu ra trung vị 571/159 token. Ràng buộc đánh giá là TPOT không quá 150 ms; trên một cụm đồng nhất tám nút với tám GPU Ampere 80 GB mỗi nút, thông lượng decode mỗi GPU của Scaled-MoE đạt 1,90 lần thông lượng của khung inference TensorRT-LLM của NVIDIA. Kết quả này là tác động tổng hợp của việc đặt tách rời, các lựa chọn song song hóa, pipelining và thư viện giao tiếp, và không nên được coi là một gia tốc chung chung từ việc “chỉ bật tách EP”. Bài báo còn chủ động cấu hình các replica dự phòng theo độ phổ biến của expert và tối thiểu hóa chi phí của nút bận nhất, cho thấy ngay cả một cụm expert độc lập vẫn phải đối phó với độ lệch.

Hãy tính pipeline này bằng một ví dụ cụ thể: giả sử các giai đoạn attention và expert cần lần lượt 2 ms và 3 ms mỗi micro-batch. Thực thi tuần tự bốn micro-batch mất tổng cộng 20 ms, với chỉ một nút làm việc tại mỗi thời điểm; pipeline hai giai đoạn lý tưởng chỉ cần $2+3+3\times3=14$ ms, tiết kiệm 6 ms (Hình 9-17). Nếu việc tách thành các micro-batch nhỏ hơn làm kéo dài thời gian phục vụ thực tế mỗi giai đoạn, hoặc nếu giao tiếp khứ hồi không thể chồng lấp với tính toán vượt quá 6 ms, lợi ích này biến mất. Vì vậy, tổng thời gian phụ thêm từ giao tiếp giảm đi và hiệu quả tính toán giảm đi phải nhỏ hơn 6 ms để thực thi pipelined vẫn nhanh hơn.

Ví dụ 9.4: Bàn giao từng tầng giữa attention và mạng feedforward thêm bao nhiêu chi phí giao tiếp? Trong một ví dụ triển khai Qwen3-8B, với 36 tầng mạng feedforward dense đặt ở phía bên kia, mỗi tầng gửi một vector hidden state BF16 hoàn chỉnh và nhận về một kết quả cùng kích thước. Lượng dữ liệu một chiều mỗi lần truyền là $4096\times2=8192$ byte; một bước decode tổng cộng 72 lần truyền, 576 KiB. Dùng cùng NIC 25 GB/s như Ví dụ 9.1, thời gian payload thuần khoảng 23,6 μs, và 72 lần phát động với 5 μs mỗi lần tổng cộng 360 μs, cho một bàn giao tuần tự khoảng 0,384 ms.

Thời gian này ngắn hơn một lần bàn giao PD trong Ví dụ 9.1, nhưng hai bên tương ứng với các phạm vi công việc khác nhau: PD bàn giao một lần mỗi request, còn AF phải bàn giao ở mỗi bước decode. Nếu prefill 8192 token đầu vào cũng được bàn giao như một lô AF dense trọn vẹn, payload activation là 4,5 GiB, cần khoảng 193 ms truyền thuần, cộng khởi động. Lần di chuyển một lần của PD tăng theo độ dài context, còn khứ hồi từng tầng của AF lặp đi lặp lại theo các bước sinh; cái trước chịu ảnh hưởng trước của các truyền KV lớn, cái sau dễ bị tổn thương hơn bởi chi phí khởi động của các truyền nhỏ và các phụ thuộc giữa các toán tử.

Bàn giao từng tầng của AF không thay đổi theo biểu diễn KV: nó mang một hidden state 4096 chiều, độc lập với số KV head hoặc độ rộng tiềm ẩn, nên một bước decode vẫn là 72 lần truyền, 576 KiB. Cái thay đổi là phía PD. Đặt thời gian tuần tự của một bàn giao PD bằng thời gian của một bước AF,

$$\frac{V_{KV}}{B}+\alpha=\frac{V_{AF}}{B}+72\alpha \quad\Longrightarrow\quad \alpha^*=\frac{V_{KV}-V_{AF}}{71B},$$

trong đó $V_{AF}$ là tổng payload của một lần bàn giao bước AF (576 KiB), và $B$ là băng thông liên kết. Dưới thời gian khởi động $\alpha^*$, một lần bàn giao bước AF nhanh hơn một bàn giao PD; trên mức đó, chi phí tích lũy của 72 lần phát động đã vượt quá việc truyền toàn bộ trạng thái trong một lần. Với trạng thái GQA, $\alpha^*\approx680$ μs ở 25 GB/s, 340 μs ở 50 GB/s; với trạng thái MLA gọn, các giá trị này lần lượt là 324 và 162 μs. Trạng thái càng nhỏ và liên kết càng nhanh, ngân sách còn lại cho mỗi lần phát động càng ít. Khởi động 5 μs thấp hơn rất xa cả bốn ngưỡng này ($\alpha^*$ trong từng trường hợp), nên xét riêng một bước bàn giao, AF luôn nhanh hơn. So sánh trên toàn bộ request, kết luận đảo ngược: bàn giao AF tích lũy qua 1024 bước khoảng 393 ms, gấp 8,1 lần 48,3 ms của một bàn giao PD GQA, và gấp 17 lần 23,0 ms của một bàn giao PD MLA gọn. PD chỉ bàn giao một lần, và MLA giảm một nửa chi phí của lần đó; AF bàn giao mỗi bước, và độ rộng hidden state không đổi, nên nó không tiết kiệm được byte nào cả. Đầu ra càng dài, khoảng cách càng lớn.

Mục tiếp theo xem xét truyền activation trong MoE: mỗi đầu vào có thể đi đến nhiều vị trí thực thi, và để hoàn tất vẫn phải chờ tất cả các expert nó chọn trả kết quả về trước khi gộp.

9.4 Vị trí đặt expert, nhân bản và cân bằng tải

9.4.1 Độ lệch tính toán và giao tiếp trong EP quy mô lớn

Trong mục trước, tái sử dụng tập trung đã giảm lượng đọc trọng số. Nhưng nếu các expert điểm nóng này đều nằm trên cùng một thẻ, các thẻ khác không thể san sẻ tải. Mục này tiếp tục theo dõi cùng 512 lần dispatch đó, xét thời điểm mỗi thẻ hoàn tất phép tính của nó. Ngay cả khi tổng phép tính trên toàn hệ thống không đổi, thẻ bận nhất vẫn có thể làm trì hoãn việc hoàn tất của cả tầng. Với thẻ $r$, gọi $F_r$ là phép toán ma trận, $W_r$ là số byte trọng số nó phải đọc, và $C_r$, $B_r$ lần lượt là thông lượng tính toán và băng thông hiệu dụng của nó. Thời gian thẻ đó hoàn tất cả phép tính lẫn đọc trọng số ít nhất là $\max(F_r/C_r,W_r/B_r)$; khi gộp kết quả trên các thẻ, ta phải chờ thẻ chậm nhất hoàn tất.

Đặt 512 lần dispatch của mục trước lên tám thẻ hé lộ một mặt khác của định tuyến tập trung. Nếu mỗi thẻ xử lý đúng 64 tác vụ, mỗi thẻ xử lý khoảng 2,42 GFLOP; nếu cả tám expert điểm nóng nằm trên một thẻ duy nhất, thẻ đó xử lý tổng cộng gần 19,3 GFLOP. Coi tám thẻ là một máy chủ HGX H100 từ Chương 7, mỗi H100 SXM ở 50% đỉnh dense BF16 989,4 TFLOP/s cho 494,7 TFLOP/s. Chỉ nhìn vào tính toán, thời gian phục vụ của thẻ bận nhất tăng từ khoảng 4,9 μs lên 39,1 μs — gấp tám lần ban đầu.

Trong Hình 9-19, độ dài của mỗi thanh ngang biểu thị thời gian mỗi thẻ cần để hoàn tất phép tính của nó. Chỉ sau khi mọi kết quả được gộp, tầng tiếp theo mới có thể tiến hành, nên chính thanh dài nhất — chứ không phải trung bình của tám thanh — quyết định thời gian hoàn tất.

Định tuyến tập trung giảm lượng trọng số cần đọc từ 4,5 GiB xuống 288 MiB, nhưng nó có thể làm phép tính của thẻ bận nhất tăng gấp tám lần. Lợi ích trước phục vụ thực thi bị giới hạn bởi đọc; tác hại sau gây hại cho thực thi bị giới hạn bởi tính toán. Do đó một chiến lược cân bằng trước tiên phải xác định nút thắt nằm ở đâu trước khi quyết định theo đuổi tái sử dụng hay dàn trải công việc.

Ngay cả khi tổng khối lượng công việc không đổi, EP quy mô lớn khuếch đại sự chờ đợi này. Theo $n=1024,k=8,E=256$ của Mục 9.3.4 (DeepSeek-V3 cũng dùng 256 expert định tuyến mỗi tầng với 8 expert được chọn mỗi token): một lô 8192 lần dispatch trung bình 32 hàng mỗi expert. Giả sử một expert nóng, nhận 128 hàng — gấp 4 lần trung bình — trong khi 8064 hàng còn lại dàn đều trên 255 expert kia, mỗi cái khoảng 31,6 hàng. Phân bố 256 expert theo chỉ số đều khắp các thẻ của nhóm EP, thẻ giữ expert điểm nóng xử lý 128 hàng của chính nó cộng các hàng của bất kỳ expert nào khác trên cùng thẻ. Ở EP8, với 32 expert mỗi thẻ, thẻ điểm nóng nhận khoảng 1108 hàng, chỉ cao hơn trung bình mỗi thẻ 1024 khoảng 8%; ở EP32, với 8 expert mỗi thẻ, thẻ điểm nóng nhận khoảng 349 hàng, cao hơn trung bình 256 khoảng 36%; ở EP256, với chỉ còn một expert này mỗi thẻ, thẻ điểm nóng có 128 hàng, gấp 4 lần trung bình 32. Cùng một expert điểm nóng bị pha loãng bởi các expert sống chung ở EP nhỏ nhưng độc chiếm cả một thẻ ở EP lớn — sự mất cân bằng giữa các expert chuyển thẳng thành sự mất cân bằng giữa các thẻ (Hình 9-21).

Số hàng của một thẻ đồng thời quyết định ba thứ: số byte nó phải nhận trong lúc dispatch, số byte nó phải gửi trong lúc combine, và — khi phép tính expert bị giới hạn bởi tính toán — thời gian ma trận của nó. Ở 8 KiB mỗi hàng và 50 GB/s mỗi NIC thẻ, thẻ điểm nóng EP256 phải nhận 1 MiB, khoảng 21 μs, trong khi một thẻ trung bình chỉ nhận 256 KiB, khoảng 5,2 μs. Nếu lô nhỏ và phép tính expert bị giới hạn bởi đọc trọng số, thời gian ma trận của một thẻ phụ thuộc chủ yếu vào số bộ trọng số expert nó phải đọc, ít liên quan đến số hàng — nhưng số byte trao đổi trong cả hai lần truyền vẫn tỷ lệ với số hàng. Đi từ EP8 đến EP256, số hàng trung bình mỗi thẻ co lại còn 1/32, song số hàng của thẻ bận nhất chỉ giảm từ 1108 xuống 128 — khoảng 1/8,7 ban đầu. Vì cả tầng được định thời bởi thẻ bận nhất của nó, một thẻ trung bình ở EP256 dành ba phần tư giai đoạn này nhàn rỗi, chờ đợi.

Ngay cả khi không có điểm nóng, tăng EP vẫn khuếch đại độ lệch. Giả sử mỗi token độc lập và đồng đều chọn ngẫu nhiên 8 expert; số hàng của mỗi expert vẫn dao động ngẫu nhiên quanh 32. Càng nhiều expert trên một thẻ, các dao động này càng triệt tiêu lẫn nhau; càng nhiều thẻ, cơ hội một thẻ nào đó trong một lô nhất định hóa ra đặc biệt bận càng lớn. Mô phỏng 1000 lô với một seed ngẫu nhiên cố định, thẻ bận nhất của EP8 trung bình chỉ cao hơn trung bình mỗi thẻ 4%, trong khi thẻ bận nhất của EP256 trung bình cao hơn 52% (Hình 9-22). Cả hai hiệu ứng cùng một nguyên nhân: EP càng lớn, số expert mỗi thẻ có thể triệt tiêu lẫn nhau càng ít, nhưng số thẻ phải chờ đợi càng nhiều. Triển khai decode đã công bố của DeepSeek dùng EP144, với chỉ 2 expert định tuyến mỗi thẻ — gần đầu phải của đường cong này; để bù lại, nó thêm 32 expert dự phòng và điều chỉnh số replica theo tải, kỹ thuật được bàn ở Mục 9.4.2.

Khối lượng giao tiếp cũng phụ thuộc vào thẻ nào mà một token bắt nguồn. Trong bố cục TP2×EP4 từ Mục 9.1, mỗi nhóm EP xử lý cùng một lô request, và các thành viên của mỗi nhóm EP vốn đã giữ các đầu vào hidden state giống hệt nhau, nên dispatch xuyên nhóm EP có thể bằng không, với kết quả được gộp qua phép rút gọn tổng từng phần (partial-sum reduction). Một bố cục khác cho mỗi thẻ giữ các token đầu vào khác nhau, đòi hỏi activation phải được dispatch đến các expert ở xa — Hình 9-16 mô tả trường hợp này. Khi các đầu vào đã được nhân bản, giao tiếp tập trung vào việc gộp kết quả; khi các đầu vào thuộc các thẻ khác nhau, thực thi thêm một vòng dispatch từ xa. Khối lượng giao tiếp được quyết định chung bởi token bắt nguồn ở đâu, expert được đặt ở đâu, và kết quả phải về đâu.

Độ lệch trong EP quy mô lớn phải được xem xét ở ít nhất ba cấp. Tần suất lựa chọn của các expert logic quyết định số hàng hiệu dụng của mỗi expert; việc đặt expert và chọn replica biến các số hàng này thành tải mỗi thẻ; nguồn gốc, đích đến và đường mạng của các token rồi biến tải mỗi thẻ thành lưu lượng theo mỗi hướng. Độ phổ biến expert không đồng đều không nhất thiết gây ra các thẻ không đồng đều, và thậm chí phép tính ngang thẻ không nhất thiết nghĩa là các liên kết dùng chung đồng đều. Việc tái sử dụng trong lô của Mục 6.3.2 đã giải thích việc đọc trọng số; mục này tiếp tục tính đến phép tính mỗi thẻ, giao tiếp và thời gian hoàn tất.

Gọi $a_{ij}$ là số lần dispatch token-expert từ nguồn $i$ đến nhóm expert $j$, với payload mỗi đầu vào và mỗi đầu ra lần lượt là $d_D,d_C$ byte. Dưới một phương án truyền trên mỗi lần dispatch, không khử trùng lặp và không rút gọn trước,

$$V^D_{ij}=a_{ij}d_D,\qquad V^C_{ji}=a_{ij}d_C,\qquad m_j=\sum_i a_{ij},\qquad s_{\mathrm{expert}}=\frac{\max_j m_j}{nk/R}.$$

Ở đây $R$ là số nhóm expert nhận, và $\sum_jm_j=nk$. $s_{\mathrm{expert}}=1$ nghĩa là khối lượng công việc hiệu dụng cân bằng giữa các nhóm; nó xấp xỉ độ lệch tính toán chỉ khi các expert cùng loại và cùng độ chính xác và phần đệm được bỏ qua. Với giai đoạn giao tiếp $X\in\{D,C\}$, kiểm kê ma trận theo người gửi, người nhận và tập cắt vật lý cho

$$T_X\ge\max\left( \max_i\frac{\sum_jV^X_{ij}}{B^{\mathrm{send}}_i}, \max_j\frac{\sum_iV^X_{ij}}{B^{\mathrm{recv}}_j}, \max_{\mathcal C}\frac{V^X_{\mathcal C}}{B_{\mathcal C}} \right).$$

Ở đây $V^X_{\mathcal C}$ và $B_{\mathcal C}$ lần lượt là payload đi qua tập cắt vật lý $\mathcal C$ và băng thông của liên kết đó. Đây là cận dưới của việc truyền payload, không tính khởi động, xếp hàng chờ và dữ liệu đến muộn; các lưu lượng đồng thời dùng chung cùng một hướng vật lý phải được cộng lại, chứ không phải mỗi dòng chia cho một ngân sách băng thông đầy đủ rồi giả định hoàn tất đồng thời. Độ lệch băng thông ở đây chỉ nhu cầu hoặc mức chiếm dụng không đồng đều trên các thẻ và liên kết, chứ không phải sự thay đổi băng thông định mức của phần cứng.

Ví dụ 9.5: Cùng tổng khối lượng giao tiếp — vì sao một điểm nóng làm chậm cả hai cuộc trao đổi? Theo 1024 token, 8 expert mỗi token và vector 8 KiB của Mục 7.2.3, đặt trên hai máy chủ HGX H100 của Hình 9-16: bốn nguồn là bốn thẻ trên máy chủ A chạy attention, và bốn nhóm expert mỗi nhóm chạy trên một thẻ của máy chủ B, với mọi dispatch đi xuyên máy chủ. Mỗi thẻ gửi và nhận qua NIC ConnectX-7 400 Gbit/s riêng, 50 GB/s mỗi chiều; khung chuyển mạch giữa hai máy chủ mang $4\times50=200$ GB/s mỗi chiều. Bốn nguồn mỗi cái gửi 2048 mục, cho tổng dispatch 64 MiB, và combine cũng là 64 MiB. Trong trường hợp cân bằng mỗi nhóm nhận 2048 mục, tức 16 MiB; trong phân bố điểm nóng $[5120,1024,1024,1024]$, nhóm 0 nhận 40 MiB và ba nhóm còn lại mỗi nhóm nhận 8 MiB. Cả hai phân bố có cùng tổng khối lượng giao tiếp và tổng phép tính hiệu dụng, vậy mà độ lệch expert chuyển từ 1 lên 2,5.

Mỗi phép tính expert đi theo ví dụ MoE Qwen3 với $6\times4096\times1536$ FLOP, với thông lượng hiệu dụng mỗi H100 lấy là 494,7 TFLOP/s. Tạm bỏ qua đọc trọng số, đệm, khởi động và xếp hàng chờ, ta được bảng dưới đây. Cột cuối chỉ áp dụng cho thực thi với một hàng rào toàn lô giữa ba giai đoạn, là tổng của ba cận dưới; với chồng lấp, đường tới hạn phải được tính riêng.

Phân bố và đường	cận dưới dispatch	cận dưới tính toán thẻ bận nhất	cận dưới combine	cận dưới tổng có hàng rào chia giai đoạn
Bốn nhóm cân bằng, xuyên máy chủ	0.336 ms	0.156 ms	0.336 ms	0.827 ms
Nhóm điểm nóng, xuyên máy chủ	0.839 ms	0.391 ms	0.839 ms	2.068 ms
Bốn nhóm cân bằng, chỉ một liên kết 400 Gbit/s giữa các cụm	1.342 ms	0.156 ms	1.342 ms	2.841 ms
Nhóm điểm nóng, dispatch chuyển sang FP8	0.419 ms	0.391 ms	0.839 ms	1.649 ms
Nhóm điểm nóng, cả hai cụm trên cùng một HGX (NVLink)	0.093 ms	0.391 ms	0.093 ms	0.577 ms

Xuyên máy chủ, hai cuộc trao đổi chiếm 80% cận dưới tổng có hàng rào chia giai đoạn, với phép tính của thẻ bận nhất chỉ đóng góp 20%: một H100 mất khoảng 76 ns để tính một tác vụ expert, trong khi NIC mất khoảng 164 ns để truyền một activation 8 KiB. Điểm nóng đồng thời kéo dài việc nhận, tính và trả, kéo dài cả ba giai đoạn lên 2,5 lần thời lượng ban đầu của chúng. Dàn trải điểm nóng, nếu giữa hai cụm chỉ còn một liên kết 400 Gbit/s, vẫn cần tối thiểu 1,342 ms mỗi chiều — cho thấy thêm thẻ expert không thể thay thế băng thông xuyên cụm. Chỉ chuyển dispatch sang FP8 cũng không làm ngắn lại theo tỷ lệ combine BF16 hay phép tính expert; bảng giả định lượng tử hóa không đổi thời gian tính toán và bỏ qua siêu dữ liệu tỷ lệ, để quan sát từng hiệu ứng một cách riêng biệt. Đặt cả hai cụm trong cùng một HGX, NVLink 450 GB/s mỗi chiều nén cả hai cuộc trao đổi xuống còn 0,093 ms, khiến phép tính 0,391 ms của thẻ điểm nóng trở thành giai đoạn dài nhất; ở đây, giảm phép tính của thẻ điểm nóng hiệu quả hơn nâng băng thông thêm nữa — chính là điều mà các replica expert trong mục sau giải quyết.

9.4.2 Replica expert, vị trí đặt và điều chỉnh động

Công việc tập trung vào một vài thẻ trong Hình 9-20 chỉ ra một cải tiến: đặt các bản sao của expert điểm nóng lên các thẻ nhàn rỗi, để các thẻ đó cũng có thể xử lý các tác vụ điểm nóng. Nhân bản expert cho phép một expert logic có nhiều bản sao vật lý, và bộ lập lịch có thể phân phối các tác vụ giữa các bản sao này. Chừng nào trọng số của các replica khớp nhau, các trọng số định tuyến được áp dụng đúng, và các kết quả được gộp đúng, việc nhân bản không cần thay đổi quy tắc rằng mỗi token chọn top-$k$ expert có điểm cao nhất; sửa đổi quy tắc chọn expert làm thay đổi hành vi model và phải được đánh giá riêng. Bộ cân bằng tải song song expert (EPLB) của vLLM và SGLang điều chỉnh vị trí replica và việc gán tác vụ của mỗi expert logic dựa trên số liệu định tuyến.

Replica expert tiêu thụ bộ nhớ GPU, và chúng còn chiếm chỗ của KV cache và các bộ đệm. Thêm một expert 36 MiB mỗi thẻ mỗi tầng, qua 94 tầng, cần tổng cộng 3384 MiB, khoảng 3,30 GiB; chỉ thêm replica cho tám tầng tắc nghẽn nhất cần vỏn vẹn 288 MiB. Hai con số này khác nhau gần một hệ số 12. CRAFT là một hệ thống phục vụ nghiên cứu replica expert và việc cấp phát bộ nhớ, giải quyết chính xác bài toán phân bổ bộ nhớ giữa các tầng: chi không gian vào những tầng nơi nó rút ngắn thời gian chờ đợi nhiều nhất, thay vì máy móc cho mọi tầng cùng một số replica.

Ví dụ 9.6: Một replica expert điểm nóng cần bao nhiêu lô để thu hồi chi phí nhân bản của nó? Tám thẻ tạo thành một máy chủ HGX H100; một lô 128 token đều chọn cùng tám expert điểm nóng trên thẻ 0, tổng cộng 1024 lần dispatch. Nhân bản bảy trong số các expert này, mỗi cái một bản, lên các thẻ 1 đến 7, tổng cộng 252 MiB; mỗi thẻ nhận trong số bảy thẻ được thêm 36 MiB, vừa khít trong 64 MiB không gian trống thêm. Ở 50% đỉnh, mỗi H100 có thông lượng hiệu dụng 494,7 TFLOP/s và băng thông bộ nhớ 1675 GB/s. Thẻ 0, được lập lịch theo tile, phải đọc và ghi khoảng 921 MB mỗi lô, bị giới hạn bởi băng thông bộ nhớ; sau khi nhân bản, thẻ 0 chỉ xử lý 576 lần dispatch, và thời gian mỗi lô của nó rút ngắn từ khoảng 0,550 ms xuống 0,309 ms, tiết kiệm khoảng 0,240 ms. Cả bảy bản sao được gửi tuần tự từ thẻ 0 qua NVLink (450 GB/s mỗi chiều), mỗi cái thêm 5 μs khởi động, mất khoảng 0,622 ms để nhân bản. Dùng thời gian thực thi không làm tròn, số lô tối thiểu mà tại đó tiết kiệm tích lũy vượt quá thời gian nhân bản thỏa mãn

$$N\Delta t>T_{copy},\qquad N_{min}=\left\lfloor\frac{T_{copy}}{\Delta t}\right\rfloor+1=3.$$

Trong cùng một máy chủ, replica tự trả tiền vào lô thứ 3: một điểm nóng kéo dài 16 lô đem về ròng khoảng 3,2 ms tiết kiệm, và một điểm nóng kéo dài 64 lô đem về ròng khoảng 14,8 ms. Nếu bản gốc của expert điểm nóng nằm trên một máy chủ khác, việc nhân bản phải vượt qua một NIC ConnectX-7 400 Gbit/s (50 GB/s mỗi chiều), kéo dài thời gian chuẩn bị lên khoảng 5,32 ms và cần 23 lô để hòa vốn: một điểm nóng chỉ kéo dài 16 lô thực ra lỗ ròng khoảng 1,5 ms, còn một điểm nóng kéo dài 64 lô đem về ròng khoảng 10,1 ms tiết kiệm. Hình 9-24 vẽ khoản đầu tư một lần này cùng lợi nhuận mỗi lô trên cùng một biểu đồ. Nếu thẻ nhận chỉ có 32 MiB không gian, không đủ chứa dù chỉ một expert 36 MiB, thì bất kể điểm nóng kéo dài bao lâu, vị trí đặt phải được thay đổi hoặc dung lượng phải được giải phóng trước.

Các phép đo của CRAFT còn cho thấy lợi ích nhân bản phụ thuộc vào tầng. Nghiên cứu này, dựa trên SGLang v0.4.8, chạy DeepSeek-R1 và Kimi K2 BF16 trên một cụm A100 80GB gồm tám nút AWS p4de.24xlarge, so sánh việc phân bổ replica expert có ngân sách bộ nhớ từng tầng với các chiến lược nhân bản hiện có. Bài báo báo cáo thông lượng đầu cuối trung bình 1,14 lần đường cơ sở, tốt nhất lên tới 1,2 lần. Điều này gợi ý ngân sách replica nên được ưu tiên cho các tầng lợi ích cao, nhưng nó không có nghĩa việc nhân bản điểm nóng tùy ý nào cũng đạt được lợi ích này; các điều kiện thí nghiệm của nó — đầu vào chia khối ở 4096 token, đầu ra cố định ở 256 token — và các điểm uốn dung lượng được định nghĩa theo goodput (thông lượng hữu ích) không thể trực tiếp thay thế cho các số liệu p99 trực tuyến.

Một chiến lược nhân bản phải dự đoán một điểm nóng sẽ kéo dài bao lâu. Với nhân bản xuyên máy chủ, mỗi lần nhân bản lại tốn 5,32 ms, nên di chuyển replica thường xuyên để đuổi theo các điểm nóng sẽ trì hoãn việc thu hồi chi phí nhân bản. Nhân bản trong cùng một máy chủ chỉ mất 0,622 ms, gần như không phải ràng buộc về thời gian; cái giới hạn số replica là mỗi thẻ có thể giải phóng bao nhiêu bộ nhớ. Năng lực ưu tiên nên dành cho các tầng tắc nghẽn dai dẳng, để thời gian chờ đợi tiết kiệm tích lũy vượt chi phí chuẩn bị.

Một chiến lược cân bằng cũng phải chọn các điểm kiểm soát của nó dọc theo toàn bộ đường. Về phía nguồn, nó phải cân bằng số token với thời điểm sẵn sàng của attention; về phía expert, nó phải cân bằng số hàng hiệu dụng, thời gian GEMM thực tế và khối lượng nhận; về phía mạng, nó phải kiểm tra đường egress dùng chung, lưu lượng xuyên rack và hướng trả về. Đây chính là lý do các báo cáo công khai của DeepSeek xử lý riêng việc cân bằng tải prefill, decode và EP. Trong decode context dài, ngay cả với cùng số request mỗi thẻ, khối lượng đọc KV của attention vẫn có thể khác nhau, cuối cùng tạo ra các thời điểm bắt đầu dispatch khác nhau.

Trong các cụm expert độc lập, việc xếp hàng chờ xuyên nguồn cũng phải được kiểm soát. Nhiều worker attention có thể đồng thời chọn cùng một expert điểm nóng, và ngay cả khi lô nhỏ của mỗi worker trông cân bằng, lưu lượng kết hợp có thể vượt năng lực phục vụ của expert đó. Nếu một cụm tiếp nhận $\lambda$ lô mỗi giây, và mỗi lô trung bình sinh $\mathbb E[F_j]$ FLOP trên thẻ expert $j$, hoạt động ổn định cần ít nhất $\lambda\mathbb E[F_j]<C_j$; mỗi liên kết $\ell$ cũng phải thỏa mãn $\lambda\mathbb E[V_\ell]<B_\ell$. Việc thỏa mãn các điều kiện này ở mức trung bình chỉ là điều kiện cần — đầu vào dạng bùng nổ và đuôi nặng vẫn có thể tạo ra các hàng đợi dài. Một cụm dùng chung đôi khi gộp các lô và làm mượt các dao động giữa các nguồn, nhưng đôi khi khuếch đại các điểm nóng tương quan; không thể giả định tách rời sẽ loại bỏ độ lệch.

Replica điểm nóng nên được đặt ở nơi có đồng thời dư địa tính toán và dư địa băng thông liên kết. Thông điệp dispatch của mục này là vector hidden state của một token — 8 KiB ở BF16, 4 KiB ở FP8 — lớn hơn nhiều so với điểm giao nhau khoảng 0,93 KB suy ra ở Mục 7.2.4 cho một NIC 50 GB/s, nên thẻ điểm nóng cạn băng thông trước, chứ không phải tỷ lệ phát hành request của NIC. Chỉ khi gửi các thông điệp điều khiển dưới 1 KB mỗi cái thì mới cần dành dư địa cho khả năng phát hành khoảng 54 triệu request-mỗi-giây của NIC. Việc chọn replica động phải tính đến các hàng đợi và đường đi, và phải giữ bản đồ định tuyến của lô hiện tại cho đến khi combine hoàn tất; trước khi di chuyển hoặc thu hồi một replica cũ, các tác vụ đang bay phải được xả hết. Đặt hạn ngạch tiếp nhận cho các điểm nóng và giới hạn khối lượng đang bay từ một nguồn duy nhất có thể ngăn nó làm cạn bộ đệm của toàn cụm; khi tăng năng lực cụm, hạn ngạch tiếp nhận và backpressure phải được điều chỉnh theo. Bỏ token tràn, thay đổi top-k, hoặc thay thế expert logic làm thay đổi hành vi model và không thể được coi là cân bằng tài nguyên trong suốt.

9.4.3 Chồng lấp dispatch đầu vào, tính toán và gộp kết quả

Việc hạch toán trong hai mục trước không phân biệt prefill với decode, vậy mà dispatch tập trung ảnh hưởng khác nhau đến hai giai đoạn này. Bài báo Demystifying the Mixture of Experts Serving Tax giải thích sự khác biệt này bằng các microbenchmark theo giai đoạn: phép tính không đều của prefill để thẻ chậm nhất kìm hãm toàn bộ lô, trong khi các expert tập trung của decode thực ra có thể giảm chi phí truy cập bộ nhớ bằng cách thu nhỏ các trọng số hoạt động và phần đệm. Điều này khớp với phân tích tái sử dụng ở Mục 6.3.2. Các thí nghiệm Mixtral/Qwen2 MoE của bài báo dùng tám A100, DeepSeek-V3 dùng tám B200, và các microbenchmark giao tiếp riêng dùng 8/16 H200; các kết quả này không thể được gộp thành một gia tốc đầu cuối xuyên cụm duy nhất. Bằng chứng của bài báo cho thấy định tuyến, hình dạng ma trận thực tế, giao tiếp và truy cập bộ nhớ phải được đo cùng nhau.

Tác động của hình dạng ma trận thực tế chủ yếu đến từ phần đệm. Grouped GEMM đặt phép nhân ma trận của nhiều expert vào một lần phát động kernel duy nhất, và kernel đệm số hàng của mỗi ma trận lên kích thước tile. Ví dụ, tám expert cục bộ nhận $[32,16,8,4,2,1,1,0]$ token, tổng cộng 64 lần dispatch token-tới-expert, tương ứng với 64 hàng hợp lệ trong ma trận đầu vào. Nếu mỗi expert không rỗng được đệm lên 32 hàng, cần 224 hàng; nếu cả tám expert được đệm lên giá trị tối đa, cần 256 hàng. Các hàng thực sự được thực thi lần lượt gấp 3,5 lần và 4 lần số hàng hợp lệ. Điều này giải thích vì sao thời gian ma trận vẫn có thể khác nhau ngay cả với cùng số tác vụ hiệu dụng: phần cứng thực thi ma trận đã đệm, trong khi phép tính expert mà model thực sự cần chỉ tương ứng với 64 hàng hợp lệ đó — các hàng zero đệm không có token thực nào tương ứng.

Đệm chỉ ảnh hưởng đến số hạng tính toán; tổng thời lượng qua ba giai đoạn còn phụ thuộc vào việc chúng có thể chồng lấp hay không. Lấy phân bố cân bằng xuyên máy chủ của Mục 9.4.1 làm ví dụ: các cận dưới của dispatch, phép tính expert và combine lần lượt là 0,336, 0,156 và 0,336 ms, hoàn toàn tuần tự tổng cộng 0,827 ms. Nếu chia đều thành hai micro-batch, thời gian mỗi giai đoạn giảm một nửa, và pipeline ba giai đoạn lý tưởng bằng tổng ba giai đoạn của một micro-batch cộng thêm một lần giai đoạn dài nhất — tức 0,581 ms, tiết kiệm 0,246 ms. Ở đây giai đoạn dài nhất là giao tiếp, nên NIC quyết định nhịp của pipeline. Nếu DMA của NIC tranh chấp với GEMM đang chạy đồng thời để truy cập HBM, làm dispatch và combine của mỗi micro-batch chậm lại khoảng 49% mỗi cái, cùng một pipeline quay về 0,827 ms: giao tiếp có chồng lấp, vậy mà lô không nhanh hơn. Ngược lại, phép tính expert sẽ phải chậm đi gấp 3,1 lần thời lượng ban đầu mới triệt tiêu cùng một khoản lợi.

Đệm và tranh chấp chính xác là hai nguồn chính khiến MFU tụt dưới đỉnh: đệm khiến đơn vị ma trận tính các hàng zero không có token tương ứng, và tranh chấp khiến giao tiếp và tính toán kéo nhau xuống. Cả hai đều phát sinh ở cấp triển khai — đỉnh phần cứng vẫn không đổi; chọn kích thước tile khớp tốt hơn với số hàng thực tế, và so le DMA với truy cập HBM của GEMM, có thể thu hồi một phần khoản lỗ này.

Theo dòng thời gian trong Hình 9-26, trong khi micro-batch đầu tiên đang trong giai đoạn combine, micro-batch thứ hai đã bắt đầu tính toán. Việc dispatch của lô đầu làm đầy pipeline, và combine của lô cuối kết thúc pipeline — hai đoạn này là thời gian tuần tự nằm ngoài phần lõi pipeline.

Pipeline trên giả định hai micro-batch có kích thước đều. Trong tách expert thực tế, đường của một token đơn lẻ vẫn là “dispatch → tính toán của các expert được chọn → combine”, với hai giai đoạn giao tiếp kẹp quanh phép tính expert. Độ lệch mức sẵn sàng dữ liệu của dispatch đến từ thời gian hoàn tất của attention và hàng đợi gửi; độ lệch từ phép tính expert, đổi lại, trở thành độ lệch sẵn sàng gửi của combine. Ngay cả khi số byte của hai cuộc trao đổi đối xứng hoàn hảo, giai đoạn trả về vẫn có thể bị kéo dài bởi dữ liệu đến muộn.

Với token $t$, gọi tập expert được chọn là $\mathcal E(t)$, và gọi $L_{t,e}$ là chiều dài đường tích lũy — xếp hàng chờ, dispatch, tính toán và trả về — từ khi bắt đầu tầng hiện tại đến expert $e$. Thời gian hoàn tất gộp của nó thỏa mãn

$$T_t=\max_{e\in\mathcal E(t)}L_{t,e}+T_{\mathrm{merge},t}.$$

Mọi đường ở đây đều gồm xếp hàng chờ trên các tài nguyên dùng chung, nên các thời gian từng giai đoạn đo riêng lẻ không thể đơn giản thay vào và giả định độc lập. Nếu hai nhánh của một token trả về lần lượt ở 0,5 ms và 1,4 ms, nó không thể gộp trước 1,4 ms; chỉ rút ngắn nhánh nhanh xuống 0,3 ms không làm thay đổi thời gian hoàn tất của nó. Khi tiến theo từng token hoặc từng khối, các token không chọn một expert chậm có thể tiến hành sớm hơn; một hàng rào toàn lô khiến chúng chờ cùng nhau. Liệu runtime có thực sự hỗ trợ tiến trình hạt mịn, và liệu các ma trận tiếp theo có vẫn cần ghép lô hay không, quyết định sự chờ đợi lan truyền xa đến đâu.

Điều này cũng giải thích vì sao $\max(t_A,t_F)$ không phải lúc nào cũng dự đoán được chu kỳ pipeline của một cụm expert. Công thức đó đòi hỏi thời lượng mỗi giai đoạn ổn định, các tài nguyên độc lập, và công việc được cung cấp liên tục; chu kỳ thực tế còn bị ràng buộc bởi expert bận nhất, các liên kết khứ hồi, các bộ đệm trả về và các phụ thuộc xuyên tầng. Nếu cùng một cụm expert phục vụ nhiều tầng hoặc nhiều model, mức tiêu thụ tài nguyên của chúng phải được kiểm kê cùng nhau. Ngay cả micro-batch đầu tiên cũng phải chịu toàn bộ độ trễ khứ hồi — nâng thông lượng ở trạng thái ổn định không rút ngắn thời gian phản hồi của một token đơn lẻ.

Hai vòng giao tiếp — dispatch và combine — được triển khai bởi các thư viện giao tiếp. NCCL cung cấp các nguyên thủy collective và point-to-point đa dụng, trong khi các thư viện giao tiếp EP chuyên dụng gộp định tuyến, đóng gói, truyền và gộp vào một triển khai duy nhất. DeepEP cung cấp dispatch/combine MoE với hỗ trợ truyền độ chính xác thấp; giao diện công khai của V2 dùng ElasticBuffer, với một backend NCCL Gin bên dưới (NCCL với giao tiếp mạng do GPU khởi tạo), và loại bỏ đường giao tiếp EP độ trễ thấp của V1 vốn bỏ qua SM và gửi/nhận trực tiếp qua RDMA. Điều này cho thấy ngay cả một tên thư viện khớp nhau cũng không thể so sánh nếu không chỉ rõ phiên bản. Khi so sánh các triển khai, hãy cố định phiên bản, hình dạng dữ liệu, độ chính xác và tô-pô, ghi lại riêng số byte gửi/nhận, số hàng GEMM expert, phần đệm, các sự kiện sẵn sàng và hoàn tất từng giai đoạn, rồi kiểm kê p50/p99 trên toàn bộ tầng và toàn bộ request. Băng thông giao tiếp đo trong cô lập chỉ giải thích một phần điều này.

Khi tái lập các phép tính của mục này, trước tiên giữ tổng số lần dispatch cố định và chỉ biến thiên phân bố expert; sau đó cố định phân bố và biến thiên egress dùng chung cùng độ chính xác dispatch; cuối cùng, trong nhật ký vết (trace log), biến thiên thời gian sẵn sàng của một nguồn hoặc một expert. Ba việc đầu có thể được tái lập trực tiếp với các phép tính kèm theo; việc cuối đòi hỏi quan sát, trong dòng thời gian thực thi, sự chờ đợi lan truyền thế nào. Chỉ bằng cách này mới phân biệt được độ lệch lưu lượng, độ lệch tính toán và sự chờ đợi do đến muộn thuần túy, thay vì quy mọi giao tiếp chậm cho băng thông mạng không đủ.

9.5 Phân bố KV, chia sẻ và định tuyến request

9.5.1 Định danh cache, phạm vi chia sẻ và trạng thái khả dụng

Hai mục trước giảm độ trễ của request hiện tại bằng cách thay đổi vị trí thực thi và việc gán tác vụ. Một cách tiết kiệm phép tính khác là để các request tiếp theo dùng trực tiếp KV do một lần tính toán trước để lại. Mục 8.3 đã giải thích các cơ chế paging, khớp tiền tố, chia sẻ và trục xuất. Mục này xem xét, khi trạng thái được phân bố trên các vị trí thực thi khác nhau, cách xác nhận một trùng khớp, tìm dữ liệu và hoàn tất việc truyền. Giá trị của prefix caching đến từ việc tránh thực thi lặp lại, nhưng “văn bản giống hệt” là không đủ để xác định duy nhất mọi trạng thái tái sử dụng được. Phiên bản model và adapter, chuỗi token, các chỉ số vị trí, định dạng trạng thái và bất kỳ cấu hình mã hóa cần thiết nào đều có thể tham gia tính định danh cache. Ví dụ, cùng các token đi kèm các adapter khác nhau chiếu ra các K, V khác nhau; cùng một hậu tố đứng sau các văn bản trước khác nhau sẽ nhìn thấy một context khác dưới attention. Khóa cache cần xác định được, dọc theo chuỗi tiền tố, toàn bộ phép tính đã tạo ra trạng thái này. Trạng thái cửa sổ trượt hoặc trạng thái hồi quy (recurrent) cũng phải mang theo các chỉ số vị trí token và dấu thời gian cập nhật tương ứng để có thể tiếp tục từ cùng một trạng thái.

Một khi xác nhận hai trạng thái có thể thay thế cho nhau, ta vẫn cần xác định trạng thái được lưu ở đâu và các instance khác đọc nó thế nào. Cộng các dung lượng lại không tự động tạo thành một cache dùng chung. Khi hai instance mỗi cái có 4 GiB cache bộ nhớ host riêng, cùng một tiền tố 1,125 GiB được lưu riêng ở mỗi bên, chiếm tổng cộng 2,25 GiB, và không instance nào dùng được bản sao của instance kia. Nếu cả hai được kết nối với cùng một backend lưu trữ dùng chung (một dịch vụ lưu trữ nhận và phục vụ các đối tượng cache), một đối tượng có thể phục vụ cả hai bên, nhưng mỗi bên vẫn có thể phải kéo nó về cục bộ trước khi sinh. Cache phân tầng HiCache của SGLang, đường cache đa cấp của vLLM, và hệ thống quản lý KV cache LMCache đưa ra các tổ chức khác nhau; việc kéo về có đi qua CPU hay không quyết định thời gian đường đi được bàn ở mục sau.

Một khi trạng thái được tạo ra, nó phải được lưu và công bố trước khi các instance khác có thể truy vấn, kéo về và sử dụng. Các sự kiện cache mà bộ định tuyến dùng thường chỉ mang siêu dữ liệu như vị trí lưu trữ và định danh cache, chứ không phải toàn bộ KV. Khi bản sao trên GPU bị trục xuất, bản sao trên CPU có thể vẫn còn. Thư mục (directory) giữ ánh xạ từ định danh cache đến vị trí; đối tượng (object) giữ các byte KV thực tế. Việc khôi phục phải xác nhận riêng cả ánh xạ thư mục lẫn dữ liệu đối tượng. Các sự kiện bị bỏ lỡ hoặc đến muộn, hoặc không gian cache bị giải phóng, đều có thể khiến một vị trí đã ghi trước đó không còn hợp lệ.

9.5.2 Lưu trữ đa cấp

Mục 8.3.4 đã so sánh việc giữ lại, hoán đổi ra ngoài và tính lại trên một thẻ duy nhất. Mở rộng lên toàn bộ một máy chủ, cùng một KV có thể được lưu ở bốn vị trí: HBM, bộ nhớ host, SSD cục bộ và một cụm lưu trữ từ xa — dung lượng tăng dần và khoảng cách tới GPU cũng lớn dần khi đi xuống danh sách này. Lấy một DGX A100 làm ví dụ: 8 thẻ A100 80GB, 2 TB bộ nhớ host, 8 SSD NVMe U.2 3,84 TB, 8 NIC 200 Gbit/s, tính theo phần chia mỗi GPU. SSD được chọn là Solidigm D7-P5520 3,84 TB, với băng thông đọc và ghi tuần tự đỉnh lần lượt là 7,1 GB/s và 4,2 GB/s. Đối tượng lưu vẫn là tiền tố 8192 token của Qwen3-8B, tổng cộng 1,125 GiB.

Tầng	Dung lượng mỗi GPU	Đường đến GPU	Kéo tiền tố 8K
HBM	≤ 63.6 GB	đã nằm trên GPU	0
Bộ nhớ host	256 GiB	PCIe 4.0 x16, 25 GB/s	48.3 ms
SSD cục bộ	3.84 TB	Đọc tuần tự SSD, 7.1 GB/s	170 ms
Cụm lưu trữ từ xa	tăng theo số nút	NIC 25 GB/s, rồi PCIe	96.6 ms
Tham chiếu: tính lại trên A100	—	ở 50% đỉnh	856 ms

Hàng HBM là cận trên sau khi trừ 16,4 GB trọng số BF16 khỏi 80 GB, trước khi khấu trừ các activation và không gian làm việc. Thời gian kéo về của cả bốn tầng đều thấp hơn rất xa thời gian tính lại 856 ms, nên với một lần kéo đơn lẻ, lưu trạng thái ở bất kỳ tầng nào cũng nhanh hơn tính lại. Các ràng buộc thực sự đến từ ba yếu tố khác: cache có sống sót đến lần dùng tiếp theo hay không, việc đọc có thể chồng lấp với tính toán hay không, và chi phí ghi vào mỗi tầng là bao nhiêu.

Dung lượng quyết định cache có thể giữ trạng thái bao lâu. Một A100 liên tục chạy prefill trên các request 8K không trúng cache tạo ra một KV 1,125 GiB mỗi 0,856 s, tốc độ sản xuất $r\approx1.41$ GB/s. Nếu mọi KV mới tạo ra được ghi vào một tầng nhất định và bị trục xuất theo thứ tự ghi, một tầng dung lượng $C$ có thể chứa gần đúng KV sản xuất trong khoảng $C/r$ giây gần nhất: khoảng 45 s cho HBM, khoảng 195 s cho bộ nhớ host, khoảng 2722 s (45 phút) cho SSD. Ngược lại, gọi $T$ là khoảng cách giữa hai lần dùng cùng một tiền tố; để các request đến lại trong khoảng $T$ trúng cache, dung lượng của tầng này phải thỏa mãn tối thiểu

$$C\ge rT.$$

Một nghiên cứu của Alibaba Cloud dựa trên nhật ký request trực tuyến (trace) báo cáo khoảng cách tái sử dụng cho hai loại khối lượng công việc: với khối lượng trò chuyện (conversational) hướng tới từng người dùng, 80% việc tái sử dụng xảy ra trong 10 phút; với khối lượng API doanh nghiệp, 80% xảy ra trong 10 giây. Ở khoảng cách 10 giây, chỉ cần 14,1 GB, HBM có thể chứa; ở khoảng cách 10 phút, cần 846 GB, vượt quá 275 GB bộ nhớ host mỗi thẻ, nên phải nhờ SSD bù vào khoảng trống.

$C\ge rT$ cũng giải thích khi nào SSD không cần thiết. Cùng nghiên cứu đó phát hiện trên khối lượng trò chuyện của nó, dung lượng cache mà Llama3-70B cần khoảng 4 lần HBM khả dụng; với một máy chủ 8 thẻ A100 trang bị 1 TB bộ nhớ host, mỗi thẻ được 128 GB, đã đủ, không cần thêm SSD hoặc tầng từ xa. Khác biệt nằm ở $r$: nghiên cứu đó tính $r$ từ tốc độ request thực tế mỗi instance, và các request cũng ngắn hơn — các request một lượt trung bình 973 token, các request nhiều lượt trung bình 5953 token; ở đây chúng ta thay vào đó giả định GPU liên tục chạy prefill trên các request 8K. Tỷ lệ trúng tiền tố càng cao và KV mỗi token càng nhỏ (ví dụ với MLA), $r$ càng thấp. $T$ phụ thuộc vào ai khởi xướng vòng tiếp theo: khoảng cách trò chuyện của con người tính bằng phút, khoảng cách gọi chương trình tính bằng giây.

Dung lượng càng lớn, tỷ lệ trúng cache cải thiện càng chậm. Dung lượng chỉ có thể giữ trạng thái sẽ được tái sử dụng trong tương lai, và một số trạng thái sẽ không bao giờ được dùng lại. Mooncake công bố một trace mẫu một giờ của dịch vụ trực tuyến Kimi, với mỗi khối chứa 512 token. Dưới trục xuất LRU (trục xuất khối được truy cập lâu nhất trước), khi cache tăng từ 1000 khối lên 50.000 khối, tỷ lệ trúng tăng từ 30% lên 50%; ngay cả với dung lượng vô hạn, nó cũng chỉ đạt 51%. Quy đổi sang Qwen3-8B, 50.000 khối khoảng 3,77 TB, tương đương một SSD 3,84 TB. Trong trace này, hơn một nửa số khối không bao giờ được tái sử dụng, trong khi các khối khác được truy cập hàng chục nghìn lần; trace của Alibaba Cloud cho thấy sự tập trung tương tự, với 10% số khối đóng góp 77% việc tái sử dụng.

Kéo về một lần, hay đọc từ xa ở mỗi bước. KV dùng chung có ba kiểu sử dụng điển hình: chạy lại prefill cục bộ, kéo về một lần từ vị trí từ xa và giữ lại cục bộ, hoặc đọc từ vị trí từ xa ở mỗi bước decode. Cả ba đều dùng cùng một context, nhưng với tần suất truyền hoàn toàn khác nhau.

Tiếp tục với tiền tố 1,125 GiB và NIC 200 Gbit/s (25 GB/s) của chương này, một lần kéo payload mất khoảng 48,3 ms. Nếu 100 lần gọi decode mỗi lần kéo lại tiền tố không đổi này từ vị trí từ xa, liên kết bị chiếm tổng cộng khoảng 4,83 s. Nếu 100 lần đọc này phải hoàn tất trong một giây, riêng context này cần khoảng 121 GB/s, gấp 4,8 lần năng lực liên kết đã cho. Ngay cả việc lập lịch các lần đọc song song với tính toán cũng không thể khiến một liên kết 25 GB/s truyền các byte này trong một giây. Chuyển sang tiền tố MLA gọn 549 MiB, một lần kéo mất khoảng 23,0 ms, và 100 lần kéo tích lũy khoảng 2,30 s; hoàn tất trong một giây vẫn cần khoảng 57,6 GB/s, gấp 2,3 lần năng lực liên kết — giảm một nửa kích thước trạng thái chỉ giảm một nửa bội số, và việc đọc từ vị trí từ xa ở mỗi bước vẫn bất khả thi.

Kéo về một lần và giữ lại cục bộ giảm tần suất truyền từ “mỗi bước một lần” xuống “mỗi lần tái sử dụng một lần”, với cái giá là chiếm HBM cục bộ. Giả sử một trạng thái chiếm $V$ byte và được giữ lại cục bộ trong $\tau$ giây; tích của dung lượng và thời gian bị chiếm là $V\tau$, đơn vị là byte-giây. Giữ trạng thái trong cùng 10 giây, một đối tượng lớn hơn chiếm nhiều hơn; với các đối tượng cùng kích thước, giữ càng lâu tích này càng lớn. Trong phiên từ Mục 9.1.3, trong 10 giây thực thi tool, trạng thái GQA chiếm 11,25 GiB·s, còn trạng thái MLA gọn chiếm 5,36 GiB·s — cùng một dung lượng cục bộ có thể giữ gấp đôi số phiên chờ đợi. Do đó các phiên không hoạt động có thể được dỡ sang vị trí từ xa, kéo về khi phiên tiếp tục, và giữ cục bộ trong lúc decode liên tục. Bằng cách này, truyền dữ liệu chủ yếu xảy ra ở lúc phiên tiếp tục và tạm dừng.

Giả sử một trạng thái sẽ được tái sử dụng $k$ lần trong tương lai, tạm bỏ qua thời gian xếp hàng chờ và việc chiếm chỗ này đẩy đi các nội dung cache khác. Điều kiện mà theo đó lưu lại rồi kéo về nhanh hơn tính lại là

$$T_{write}+kT_{read}<kT_{recompute}.$$

Lấy tiền tố 8192 token của Qwen3-8B làm ví dụ: tính lại nó một lần trên A100 mất khoảng 0,856 giây (thời gian prefill từ Mục 9.2.3); lưu và kéo về mỗi cái mất khoảng 48,3 ms qua NIC 25 GB/s. Với một lần tái sử dụng, lưu cộng kéo về tổng cộng khoảng 96,6 ms, chưa bằng một phần tám việc tính lại — chừng nào trạng thái này sẽ được dùng lại dù chỉ một lần nữa, việc lưu là đáng giá. Kết luận thay đổi khi liên kết chậm lại: ở các băng thông giữa khoảng 1,41 và 2,82 GB/s, cần ít nhất hai lần tái sử dụng để bù đắp chi phí lưu, và càng gần 1,41 GB/s thì càng cần nhiều lần tái sử dụng; dưới khoảng 1,41 GB/s, ngay cả một lần kéo cũng chậm hơn tính lại, và càng tái sử dụng nhiều lỗ càng lớn. Một liên kết 10 GbE chỉ cung cấp 1,25 GB/s mỗi chiều, nên một lần kéo mất khoảng 966 ms; trong trường hợp này nên dùng tính lại, hoặc đưa việc kéo ra khỏi đường tới hạn và hoàn tất trước. Kích thước trạng thái chỉ đi vào $T_{write}$ và $T_{read}$; $T_{recompute}$ được quyết định bởi chi phí prefill của model. Chuyển sang trạng thái MLA gọn, việc ghi và kéo về một lần qua cùng NIC chỉ mất khoảng 46,1 ms, làm bên trái bất đẳng thức co lại khi số byte KV giảm.

Băng thông tới hạn 1,41 GB/s này chính là tốc độ sản xuất KV $r$ ở trên: kéo về $V$ byte mất $V/B$, tính lại mất $V/r$; chừng nào băng thông liên kết $B$ vượt quá tốc độ GPU sản xuất KV này, kéo về nhanh hơn tính lại. Băng thông đọc và ghi của SSD cục bộ đều vượt $r$: ghi mất khoảng 288 ms, đọc khoảng 170 ms, và một lần tái sử dụng tổng cộng khoảng 458 ms, vẫn ít hơn 856 ms của việc tính lại.

Chồng lấp đọc với tính toán. Sau một cú trúng cache, request chỉ cần tính 256 token mới, ở 50% đỉnh A100 (theo quy ước Mục 9.2.3) mất khoảng 30,9 ms. Khi KV lịch sử nằm trong bộ nhớ host, nếu toàn bộ khối được đọc vào trước khi tính toán bắt đầu, tổng là 48,3 + 30,9 = 79,2 ms, với việc đọc lâu hơn tính toán. CachedAttention áp dụng nạp trước từng tầng (layer-by-layer preloading): vì một Transformer tính theo từng tầng, và tầng $i$ chỉ dùng KV của tầng $i$, GPU có thể tính tầng $i$ trong khi PCIe đồng thời đọc các tầng tiếp theo. KV lịch sử mỗi tầng của Qwen3-8B là 32 MiB, mất 1,34 ms để đọc, trong khi tính một tầng cho token mới chỉ mất 0,857 ms. Vì phép tính của mỗi tầng phải chờ lần đọc của nó, tổng thời gian khoảng 49,2 ms, vẫn bị đọc chi phối. Để rút ngắn thêm, một số tầng phải được đọc vào trước khi request này bắt đầu thực thi: dùng thời gian thực thi của lô trước, 14 tầng đầu (448 MiB) được đọc vào một bộ đệm dành riêng trong HBM, và việc đọc 22 tầng còn lại có thể được chồng lấp hoàn toàn với tính toán, giảm tổng thời gian xuống còn 30,9 ms của riêng tính toán. Bộ đệm phải chứa đúng số byte dư thừa theo đó việc đọc vượt quá tính toán:

$$S_{buf}=B\,(T_{read}-T_{new}),$$

trong đó $B$ là băng thông liên kết, $T_{read}$ là thời gian đọc toàn bộ KV lịch sử, và $T_{new}$ là thời gian tính các token mới. Thay 25 GB/s, 48,3 ms và 30,9 ms cho khoảng 437 MB, hơi nhiều hơn 13 tầng, làm tròn lên thành trọn 14 tầng. Khi $T_{new}\ge T_{read}$, không cần bộ đệm: với khoảng 400 token mới, tính toán đã có thể chồng lấp việc đọc từ bộ nhớ host; đường tuần tự của cụm lưu trữ từ xa cần khoảng 800, và SSD cục bộ cần khoảng 1400. Trong các phép đo của CachedAttention trên LLaMA-13B, với 1K token lịch sử và 100 token mới, nạp trước từng tầng giảm 35% thời gian prefill, và thêm một bộ đệm 15 tầng giảm 61%.

Dùng thời gian xếp hàng chờ để prefetch từ SSD. Đọc một tầng từ SSD cục bộ mất 4,73 ms, gấp 5,5 lần thời gian tính một tầng, nên nạp trước từng tầng chỉ có thể chồng lấp một phần nhỏ. Khi một request bắt đầu thực thi, nếu trạng thái của nó vẫn còn trên SSD, ngay cả với việc đọc từng tầng, riêng bước này mất khoảng 171 ms, trong khi tính toán tự nó chỉ mất 30,9 ms. Thời gian xếp hàng chờ có thể được khai thác: trong khi một request còn trong hàng đợi, bộ lập lịch đã biết nó cần tiền tố nào và có thể đọc tiền tố này từ SSD vào bộ nhớ host trước. Chừng nào thời gian xếp hàng chờ không ngắn hơn 170 ms, lần đọc này nằm ngoài đường tới hạn, và việc đọc từng tầng từ bộ nhớ host diễn ra như mô tả ở trên một khi thực thi bắt đầu. Đây cũng là quan hệ $T_{first}=\max(Q,R)+C$ từ Mục 9.5.4: prefetch chồng lấp thời gian trạng thái sẵn sàng $R$ với thời gian xếp hàng chờ $Q$.

Bộ nhớ host giữ được bao nhiêu phiên quyết định bộ lập lịch có thể prefetch cho bao nhiêu request ở đầu hàng đợi: 256 GiB có thể chứa khoảng 227 tiền tố 8K, nên việc prefetch chỉ cần phủ 227 request ở đầu hàng đợi. Khi bộ nhớ host không đủ và cần hoán đổi ra ngoài, các quyết định cũng được đưa ra dựa trên hàng đợi: trạng thái mà các request sắp dùng không thể bị hoán đổi ra; trong số phần còn lại, trạng thái có lần dùng tiếp theo xa nhất bị hoán đổi ra trước. LRU và FIFO chỉ dựa vào truy cập quá khứ và không thể khai thác các request sắp tới trong hàng đợi. CachedAttention phát lại các cuộc trò chuyện nhiều lượt từ ShareGPT (một tập dữ liệu các cuộc trò chuyện ChatGPT do người dùng chia sẻ) trên 4 A100, 128 GB bộ nhớ host và 10 TB SSD: với prefetch và trục xuất dựa trên hàng đợi, tỷ lệ trúng tổng thể là 86%, với hơn 99,6% số cú trúng đến từ bộ nhớ host; LRU và FIFO chỉ đạt tỷ lệ trúng lần lượt 58% và 48%, với chưa tới 1% số cú trúng đến từ bộ nhớ host — gần như mọi cú trúng đều phải đọc từ SSD.

Độ bền ghi của SSD có hạn. Việc ghi cũng phải tránh đường tới hạn. KV được sản xuất từng tầng trong lúc prefill có thể được ghi lại đồng thời với tính toán; decode chỉ thêm KV của một token mỗi bước. Ghi ở $r\approx1.41$ GB/s chỉ chiếm 5,6% băng thông PCIe, và chỉ 34% băng thông ghi tuần tự của SSD. Ràng buộc thực sự của SSD là độ bền ghi: D7-P5520 được định mức một lần ghi đầy ổ mỗi ngày trong năm năm (1 DWPD), nên ổ 3,84 TB chỉ có thể duy trì trung bình khoảng 44,4 MB/s. Nếu toàn bộ KV mới được ghi vào SSD, lượng ghi sẽ gấp 31,7 lần hạn ngạch này, làm cạn kiệt độ bền ghi năm năm trong chưa đầy hai tháng. Về dài hạn, chỉ khoảng 3,2% KV mới có thể được ghi vào SSD. Như với hai trace đã nêu ở trên, việc tái sử dụng tập trung vào một số ít khối — trong trace của Mooncake, hơn một nửa số khối không bao giờ được tái sử dụng — nên việc ghi vào SSD cần kiểm soát tiếp nhận (admission control) trước, ví dụ chỉ ghi các tiền tố đã từng được tái sử dụng, hoặc các phiên nhiều lượt chưa kết thúc. Ghi trong hạn ngạch này, SSD có thể chứa khoảng lượng KV sản xuất trong ngày gần nhất.

Quan hệ giữa dung lượng và tỷ lệ trúng này cũng có thể được quan sát bằng thí nghiệm. Trong một tập thí nghiệm với hai engine dùng chung một thẻ, qua 12 cơ hội tái sử dụng tiền tố, một cụm CPU dùng chung 4 GiB đạt 5 cú trúng hoàn chỉnh, còn một cụm 8 GiB đạt 12 cú trúng hoàn chỉnh. 4 GiB thêm đã giữ lại bảy tiền tố hoàn chỉnh mà lẽ ra đã bị trục xuất; nếu trạng thái mà một request tiếp theo cần đã nằm cục bộ, nó không cần được kéo về lần nữa. Vì vậy lợi ích của dung lượng dùng chung phải được cân đo theo “giữ được bao lâu, tránh được bao nhiêu lần tính lại, và phát sinh thêm bao nhiêu lần truyền”.

9.5.3 Tính bền vững, checkpoint và tính lại một phần

Mục trước giả định trạng thái đã lưu có thể được kéo về đầy đủ. Sau khi một instance khởi động lại, các bản ghi thư mục, dữ liệu trên đĩa và các tiền tố có thể tái sử dụng liên tục có thể không nhất quán, và quá trình khôi phục cần xác nhận lại kết quả tính toán nào đã thực sự được lưu. Tính bền vững (persistence) giữ trạng thái khả dụng sau khi một instance khởi động lại hoặc một tác vụ tạm dừng. Lưu đầy đủ giảm việc tính lại khi khôi phục, checkpoint định kỳ giảm việc ghi nhưng tăng công việc khôi phục, và tính lại một phần dùng tiền tố được giữ lại để lấp phần còn thiếu. Một checkpoint phải lưu mọi trạng thái cần để tiếp tục tính toán: GQA đầy đủ lưu context K, V; trạng thái của DeepSeek V4 còn liên quan đến các kết quả nén, các cửa sổ, và các khối nén dở dang. Khôi phục tiếp tục tính toán từ bản cập nhật hoàn chỉnh cuối cùng được ghi trong checkpoint.

Trạng thái đã duy trì được lưu theo trang và đọc lại theo trang khi khôi phục. Trước tiên xét các trang GQA đầy đủ. Với Qwen3-8B, mỗi trang logic chứa 16 token là 2,25 MiB. Nếu các mảnh (shard) K, V của mỗi tầng được di chuyển riêng, kết quả là nhiều đoạn liền kề nhỏ; nếu được gom theo trang, số lần truyền và phép biến đổi bố cục cần thiết khác nhau. Một trang logic tách theo K, V qua 36 tầng có 72 đoạn liền kề 32 KiB; gom theo trang, nó là một đối tượng 2,25 MiB duy nhất. Cái trước bị giới hạn nhiều hơn bởi các ràng buộc thao tác-mỗi-giây, cái sau dành nhiều thời gian hơn để truyền các payload liền kề.

Một request sau khởi động lại đọc 64 trang, bao phủ 1024 token, nhưng tiền tố liền mạch tái sử dụng được chỉ là 1008 token, tức 63 trang. Trang đọc thừa tốn 2,25 MiB mà không tiết kiệm được lần tính lại tương ứng nào. Với request này, lượng đọc là 144 MiB, nhưng lượng tái sử dụng hiệu dụng khoảng 142 MiB; một cách diễn đạt giàu thông tin hơn là “64 trang được đọc, 63 trang được dùng”. Ràng buộc ở đây xảy ra sau khi đọc: chỉ những trang khớp thành công và có thể được nối liên tục vào context hiện có mới có thể thay thế phép tính. Đọc đĩa nhanh hơn rút ngắn thời gian đọc nhưng không thay đổi trang cuối cùng mà request này phải xử lý.

Khi một trang bị thiếu, ta phải so sánh việc tiếp tục chờ đợi với việc tính lại. Tính lại toàn bộ tiền tố 8192 token trên một A100 mất khoảng 0,856 giây (thời gian prefill từ Mục 9.2.3); nếu một request đã chờ 1 giây để kéo về một đối tượng không khả dụng, riêng thời gian chờ đó đã vượt quá thời gian cho một lần tính lại hoàn chỉnh. Trong một thí nghiệm trang cụt (truncated page) thực tế, một request chờ vô điều kiện không bao giờ hoàn tất trong cửa sổ quan sát 60 giây; một khi được phép bỏ cuộc chờ, request đó thu được kết quả của nó qua việc tính lại. Sau khi hoàn tất request hiện tại, trang hỏng vẫn cần được cách ly hoặc sửa chữa, nếu không request kế tiếp sẽ gặp cùng sự chờ đợi.

9.5.4 Độ dính cache và định tuyến request

Một khi xác nhận cache tái sử dụng được, ta vẫn cần quyết định gửi request đến máy nào. Máy giữ cache có thể đang bận, trong khi một máy khác, dù phải kéo về hoặc tính lại, có thể hoàn tất sớm hơn. Vậy điều quan trọng cho việc định tuyến là thời gian hoàn tất của request. Gọi $Q$ là thời điểm sớm nhất GPU có thể thực thi, $R$ là thời điểm trạng thái trở nên sẵn sàng tính từ lúc request đến, và $C$ là phần công việc còn lại một khi trạng thái khả dụng. Trong một mô hình mà việc thực thi chỉ bắt đầu sau khi toàn bộ trạng thái đã đến, và việc kéo về có thể chồng lấp với việc GPU chờ, thời gian đến token đầu tiên là

$$T_{first}=\max(Q,R)+C.$$

Nếu việc kéo về chỉ có thể bắt đầu sau khi GPU xong hàng đợi của nó, thời gian xếp hàng chờ và thời gian kéo về phải được cộng lại; nếu dùng pipelining từng tầng, cần một đồ thị thực thi mịn hơn. Ví dụ, với $Q=80$ ms, một lần kéo mất 60 ms, và phần tính còn lại là 10 ms, mức sẵn sàng song song cần tổng cộng 90 ms; chờ GPU rảnh rồi mới bắt đầu kéo cần 150 ms. Lượng tính toán và số byte truyền là giống hệt nhau — chỉ khác quan hệ phụ thuộc, vậy mà thời gian chênh nhau 60 ms.

Ví dụ 9.7: Cú trúng cache và độ trễ xếp hàng cùng quyết định định tuyến request như thế nào? A và B là hai instance A100, và request mang một tiền tố 8192 token cộng 256 token mới. A có tiền tố này trong HBM, nhưng phải xếp hàng 250 ms; B chỉ chờ 20 ms, nhưng không có cache. Ở 50% đỉnh A100 (theo quy ước Mục 9.2.3), tức 156 TFLOP/s: tính lại hoàn toàn 8448 token cần khoảng 138,4 TFLOP phép toán ma trận, khoảng 887 ms; sau một cú trúng, chỉ 256 token mới được tính, khoảng 4,81 TFLOP, 30,9 ms. B cũng có thể kéo tiền tố từ kho lưu trữ từ xa: một chi phí tra cứu cố định 10 ms, rồi toàn bộ 1,125 GiB đi qua mạng đến bộ nhớ host và sau đó PCIe 4.0 x16 đến GPU, tính ở 25 GB/s như trong Ví dụ 9.3, khoảng 48,3 ms.

Đường	Thời gian đến token đầu tiên
A: trúng cache cục bộ	$250+30.9\approx281$ ms
B: tính lại trực tiếp	$20+887\approx907$ ms
B: kéo từ xa qua 50 GbE (6.25 GB/s)	khoảng 282 ms
B: kéo từ xa qua 200 GbE (25 GB/s)	khoảng 137 ms

Trong hình định tuyến đầu tiên, dữ liệu của A đã nằm trên GPU, nhưng phép tính không thể bắt đầu cho đến 250 ms. B rảnh ở 20 ms; việc tính lại trực tiếp có thể bắt đầu ngay, nhưng 887 ms tính toán của nó dài hơn bất kỳ đường kéo nào, còn kéo từ xa thì phải tiếp tục chờ dữ liệu. Tăng băng thông từ xa rút ngắn đoạn màu cam; phần tra cứu, phần truyền từ bộ nhớ chính đến GPU và phép tính cuối cùng vẫn còn nguyên.

Để B trả về sớm hơn 281 ms của A, sau khi trừ 30,9 ms tính sau trúng cache, trạng thái phải sẵn sàng trong vòng 250 ms. Trừ tiếp 10 ms tra cứu và khoảng 48,3 ms từ bộ nhớ host đến GPU, chỉ còn khoảng 191,7 ms cho lần đọc từ xa. Chia 1,125 GiB cho ngân sách này cho băng thông mà tại đó lần kéo của B hòa với cú trúng cục bộ của A, khoảng 6,30 GB/s: 6,25 GB/s của 50 GbE hơi thấp hơn giá trị này, còn 200 GbE vượt xa. Băng thông mà tại đó việc kéo hòa với việc tính lại chỉ khoảng 1,48 GB/s — tính lại một tiền tố 8K trên một A100 gần như luôn là phương án chậm nhất.

Cùng một phiên vì thế có thể được sắp xếp lại theo nơi trạng thái và tài nguyên của nó cư trú. Ứng dụng giữ một context liên tục, còn dịch vụ chọn giữa việc tiếp tục dùng trạng thái cục bộ, di trú trạng thái, hay tính lại, dựa trên thời điểm mỗi đường trong ba đường này cho phép việc thực thi model tiếp theo bắt đầu. Chương 8 xác định các tiền tố tái sử dụng được dựa trên nội dung; mục này còn gấp thời gian xếp hàng chờ và băng thông liên kết vào quyết định định tuyến.

Sau khi chuyển sang 200 GbE, việc kéo từ xa rõ ràng là thuận lợi cho một request đơn lẻ; nhưng 16 lần kéo mỗi giây cần khoảng 19,3 GB/s, đã dùng khoảng 77% năng lực liên kết 25 GB/s này. Các đợt bùng nổ request làm tăng thời gian xếp hàng chờ truyền. Vì vậy sau khi tính băng thông cần cho một request đơn lẻ, ta cũng phải tính tổng lưu lượng dưới luồng đến liên tục.

So sánh trên giả định vị trí cache đã biết và dữ liệu khả dụng. Các bộ định tuyến thường dự đoán vị trí dựa trên các sự kiện cache; sự kiện trễ hoặc đối tượng bị trục xuất có thể khiến dự đoán không chính xác. Để thấy lỗi như vậy ảnh hưởng đến thời gian phản hồi thế nào, đổi thời gian xếp hàng chờ của A thành 80 ms và giả định cache chỉ thực sự khả dụng với xác suất $p$. Khi trúng, thời gian là 110,9 ms; nếu mọi tầng đều trượt và phải tính lại, là 967,2 ms; kỳ vọng là

$$\mathbb{E}[T_A]=110.9p+967.2(1-p)=967.2-856.3p\ \mathrm{ms}.$$

Để trung bình đánh bại việc tính lại trực tiếp 907 ms của B chỉ cần $p>7.0\%$. Lấy $p=0.9$, trung bình khoảng 196,5 ms, nhưng 10% request vẫn mất 967 ms, nên p99 của phân bố hai điểm này là 967 ms, xa mục tiêu 220 ms. Để đạt p99 là 220 ms, mô hình thời gian hai điểm này cần xác suất trúng tối thiểu 99%; 90% đã cải thiện đáng kể trung bình, nhưng vẫn đưa một trong mười request vào đường chậm 967 ms.

Một thí nghiệm áp lực tải chạy hai tác vụ đồng thời minh họa trực tiếp hơn sự đánh đổi giữa độ dính cache và sở thích instance nhàn rỗi. Với độ dính cache, request mục tiêu hoàn tất trong khoảng 1,38 giây, và cả hai tác vụ cũng hoàn tất ở thời điểm này; di chuyển request mục tiêu sang instance nhàn rỗi rút ngắn thời gian hoàn tất của nó xuống khoảng 0,33 giây, nhưng khi đó cả hai tác vụ phải đến khoảng 1,54 giây mới hoàn tất. Request mục tiêu nhanh hơn khoảng 1,05 giây, nhưng thời gian hoàn tất của mọi tác vụ bị trì hoãn khoảng 0,16 giây. Trước khi đưa ra quyết định định tuyến, trước tiên phải xác định mục tiêu được tối ưu là thời gian phản hồi của request mục tiêu hay thời gian hoàn tất của toàn bộ tác vụ.

Một khi quá trình khôi phục trạng thái từ Chương 8 được gấp vào quyết định định tuyến, ta phải so sánh cả thời điểm một instance trở nên nhàn rỗi lẫn thời điểm trạng thái của nó trở nên sẵn sàng. Lấy trạng thái phiên của DeepSeek V4.1 làm ví dụ: giả sử instance A giữ KV toàn cục và trạng thái SWA của encoder, nhưng có hàng đợi; instance B có thể thực thi ngay, nhưng phải kéo về KV toàn cục và khôi phục trạng thái SWA của encoder. Lợi thế của A là tái sử dụng được trạng thái, lợi thế của B là tài nguyên tính toán có thể bắt đầu ngay; điều bộ định tuyến phải so sánh là thời gian hoàn tất kỳ vọng của hai phía, chứ không chỉ cờ trúng cache.

Giả sử việc xử lý đầu vào mới, phát lại cửa sổ decoder và sinh của cả hai phía mất cùng thời gian, với công việc chuẩn bị thực thi tuần tự. Việc truyền trạng thái toàn cục của B, theo tính toán ở Chương 7, là 4,666 ms, và việc khôi phục trạng thái SWA encoder được giả định là 8 ms, tổng cộng 12,666 ms. A giữ cả hai phần trạng thái, nên thời gian chuẩn bị của nó chỉ là thời gian xếp hàng chờ: ở hàng đợi 10 ms, A bắt đầu xử lý đầu vào mới sớm hơn; ở hàng đợi 20 ms, B bắt đầu sớm hơn. 12,666 ms vì thế trở thành, trong ví dụ này, ngưỡng xếp hàng chờ tại đó lựa chọn định tuyến đảo chiều.

9.6 Khởi động dịch vụ, mở rộng quy mô và khôi phục sau lỗi

Các mục 9.2 đến 9.5 so sánh một request được bàn giao ở đâu và trạng thái của nó cư trú ở đâu. Mục này chuyển sang những thay đổi trong chính instance: một replica mới mất bao lâu để khởi động và warmup (khởi động nóng), trạng thái được bàn giao thế nào khi chiến lược song song hóa thay đổi lúc chạy, và dịch vụ tiếp tục thế nào sau một lỗi thẻ một phần nhờ dựa vào trạng thái đã lưu và các bản ghi đầu ra.

9.6.1 Chi phí khởi động và warmup

Các so sánh định tuyến trong Mục 9.5.4 đều bắt đầu từ các instance đã sẵn sàng. Trong lúc mở rộng quy mô hoặc khôi phục sau lỗi, một instance mới trước tiên phải hoàn tất khởi động trong khi các request chờ vẫn tiếp tục đến. Mục này vì thế đặt khởi động và khôi phục trạng thái lên cùng một dòng thời gian dịch vụ. Một replica mới cũng phải hoàn tất việc khởi tạo tiến trình và tokenizer (thành phần chuyển văn bản thành ID token), đọc trọng số và chia mảnh (sharding), biên dịch, dò năng lực KV, và graph capture (ghi lại các bước thực thi dưới dạng CUDA Graph từ Mục 5.5.2). Tổng thời gian cho việc chuẩn bị này quyết định khi nào replica mới có thể bắt đầu nhận request. Khi lần chạy thử đầu tiên kích hoạt biên dịch, thời gian biên dịch đã nằm trong lần chạy thử đó, và tổng thời gian phải được tính theo thứ tự phụ thuộc. Nghiên cứu chi phí khởi động Breaking the Ice, trong phân tích phân giai đoạn các phiên bản vLLM lịch sử, minh họa điểm này; một khi các quan hệ chứa đựng được khai triển, tổng thời gian khởi động được quyết định bởi đường phụ thuộc dài nhất từ khi tạo tiến trình đến khi có thể nhận request.

Giả sử việc chuẩn bị đồ thị thực thi thêm $T_s$ vào thời gian khởi động, nhưng mỗi bước thực thi tiếp theo sau đó tiết kiệm $\delta$; sau $N$ bước lợi ích ròng là $N\delta-T_s$. Thêm 10 giây và tiết kiệm 0,2 ms mỗi bước cần 50000 bước để hòa vốn; chỉ từ bước 50001 trở đi, khoản tiết kiệm tích lũy mới vượt thời gian khởi động thêm. Nếu mỗi bước sinh một token cho mỗi request trong lô 32 request, 50000 bước tương ứng khoảng 1,6 triệu token đầu ra. Thời gian được tiết kiệm một lần mỗi lô đã thực thi, nên lợi ích tích lũy phải được tính theo số lần thực thi lô.

Các request mới đến cũng chồng chất trong lúc khởi động. Nếu dịch vụ ban đầu hoàn toàn không khả dụng, tốc độ đến giữ nguyên là $\lambda$, và thời gian khởi động là $T_s$, backlog khi kết thúc khởi động khoảng $\lambda T_s$. Một khi sẵn sàng, năng lực dịch vụ là $\mu>\lambda$; trong một mô hình dòng chảy liên tục lý tưởng, thời gian xả thêm là

$$T_{drain}=\frac{\lambda T_s}{\mu-\lambda}.$$

Lấy cụm không đồng nhất của chương này làm ví dụ: khởi động mất 10 giây, trong đó mỗi giây có 3,5 request đến, để lại 35 request tồn đọng một khi dịch vụ sẵn sàng. Với PD trực tiếp sẵn sàng ở khoảng 4,55 request/s, các request mới vẫn chiếm 3,5 trong số đó, chỉ còn khoảng 1,05 request/s năng lực dọn backlog thực tế, cần khoảng 33 giây nữa để xả hết — tức giây thứ 43 tính từ lúc bắt đầu khởi động. Với co-location chunked lý tưởng ở 4,17 request/s, chỉ khoảng 0,67 request/s đi vào việc dọn backlog, mất đến giây thứ 63; co-location không chunking, chỉ ở 3,02 request/s, khiến backlog tăng vô hạn. Ba đường cong được thể hiện trong Hình 9-42.

Các request bị tồn đọng có xu hướng dồn đến cùng một lúc một khi dịch vụ sẵn sàng, và tại thời điểm đó, prefetch đồng thời cũng có thể thay đổi request nào bắt đầu thực thi trước. Xét một request 1024 token mà khi chạy một mình tái sử dụng 1008 token; khi tám request đến đồng thời, bốn request đầu mỗi cái đăng ký một prefetch 1024 token, cùng chiếm 4096 token, và các request còn lại không đăng ký được vì vượt hạn ngạch dung lượng. Request hoàn tất đầu tiên hóa ra lại là một trong số các request sau: nó không trúng cache nào cả và đi thẳng vào prefill; chính vì không chờ cache, nó vào hàng đợi thực thi sớm hơn. Vì vậy ngay cả khi một đối tượng có cache tồn tại, một request trước tiên phải có được không gian cần cho việc prefetch trước khi nó có thể dùng cache đó. Một khi không gian prefetch bị dùng hết, các request sau chỉ đơn giản tính lại trực tiếp, trong khi các request đã bắt đầu prefetch vẫn đang chờ dữ liệu của chúng.

Việc mở rộng quy mô cũng phải tính đến mối tương ứng giữa phiên bản model và phần cứng. Khi trọng số được cố định trên phương tiện bất biến, thêm các bộ tăng tốc cùng loại mở rộng dịch vụ của cùng phiên bản; triển khai trọng số mới đòi hỏi cấp phát các bộ tăng tốc hỗ trợ phiên bản mới. Bộ định tuyến phân phối request theo phiên bản model, và việc quy hoạch năng lực phải dành tài nguyên cho các phiên bản cũ và mới cùng tồn tại và cho việc thay thế bộ tăng tốc. Dịch vụ của một phiên bản cố định kéo dài càng lâu và nhu cầu càng lớn, càng nhiều request có thể chia sẻ khoản đầu tư triển khai.

9.6.2 Tái cấu hình lúc chạy và bàn giao trạng thái

Khởi động giải quyết khi nào một instance mới trở nên khả dụng; di trú lúc chạy còn phải cho phép instance đích tiếp tục từ nơi nguồn dừng lại. Thay đổi bậc tensor parallelism, bậc song song expert, hoặc quy mô cụm dịch vụ đòi hỏi phải sắp xếp lại trọng số và trạng thái request. Đưa các tham số lên thẻ đích chỉ là bước đầu; nó còn có thể cần thiết lập các nhóm giao tiếp, chuẩn bị một đồ thị thực thi mới, chuyển đổi bố cục, và tiếp tục nhận request. Các bước chuẩn bị và các lần di chuyển dữ liệu này có thứ tự phụ thuộc mà cùng nhau quyết định khi nào các request mới có thể được giao cho đích.

Di trú có kế hoạch có thể khai thác việc nguồn vẫn đang chạy: trước tiên sao chép ở chế độ nền bất kỳ context nào sẽ không còn thay đổi trong khi nguồn tiếp tục sinh; cuối cùng tạm dừng ngắn, sao chép trạng thái tích lũy trong lúc di trú, và bàn giao quyền thực thi cho đích. Lấy việc di trú đi một worker D trên một H20 làm ví dụ: context trung bình qua 32 request trong lô là 8704 token, với tổng KV khoảng 41,1 GB. Nguồn hoàn tất khoảng 1166 lần gọi decode mỗi giây, mỗi lần thêm KV của một token (144 KiB), nên trạng thái chỉ tăng khoảng 0,172 GB mỗi giây. Sao chép sang đích qua NIC 200 Gbit/s 25 GB/s của chương này giảm backlog với tốc độ khoảng 24,8 GB/s, hoàn tất việc sao chép trong khoảng 1,65 giây, trong đó tích lũy khoảng 0,28 GB trạng thái mới; với chỉ một cổng 50 GbE đơn (6,25 GB/s) nó mất khoảng 6,76 giây. Tốc độ decode thêm KV thấp hơn rất nhiều băng thông NIC, nên thời gian đuổi kịp gần như hoàn toàn do 41,1 GB ban đầu quyết định; một khi tốc độ sao chép tụt xuống mức tốc độ tăng trưởng trạng thái, backlog ngừng co lại. Điểm bàn giao cuối cùng cố định đồng thời cả phiên bản trạng thái lẫn quyền thực thi, ngăn đích bỏ lỡ các cập nhật cuối của nguồn.

Trong Hình 9-43, đường cong của nguồn cũng đang dâng lên, nên tốc độ đuổi kịp là chênh lệch giữa hai độ dốc; trong ví dụ này, mức tăng trưởng của decode cực chậm, nên đường cong của nguồn gần như phẳng. Khi năng lực sao chép đúng bằng tốc độ tăng trưởng trạng thái, hai đường chạy song song, và backlog ban đầu không bao giờ co lại. Lần bàn giao cuối phải được lập lịch tại thời điểm đích đã đuổi kịp nguồn và trạng thái hai phía khớp nhau.

Một loại điều chỉnh lúc chạy khác ngoài di trú là chuyển đổi chiến lược song song hóa: tổ chức lại cùng một tập thẻ thành TP hoặc SP×TP. Ở đây TP tách các ma trận trong tầng, và SP phân bổ một phần phép tính và trạng thái trung gian theo vị trí token. Các nghiên cứu tình huống từ ArcticInference (plugin inference vLLM mã nguồn mở của Snowflake) và vLLM minh họa cách tiếp cận này: việc chuyển đổi thay đổi thẻ nào và token nào tham gia vào phép tính của mỗi bước, đồng thời cũng thay đổi các trọng số, bố cục KV và đồ thị thực thi cần thiết. Dành trước trọng số và đồ thị thực thi cho cả hai chế độ có thể rút ngắn thời gian chờ chuyển đổi, nhưng lượng trọng số và đồ thị dành trước thêm này làm giảm không gian dành cho KV. Khi Elastic EP (mở rộng quy mô lúc chạy số thẻ trong một nhóm song song expert) mở rộng một nhóm expert, các thẻ mới thêm phải trước tiên có được trọng số expert trước khi có thể nhận các tác vụ được dispatch; xử lý một request hoàn chỉnh cũng cần trạng thái attention tương ứng.

Chỉ khi đích đã đuổi kịp bản cập nhật trạng thái của nguồn thì dữ liệu hai phía mới đồng nhất. Đích cũng phải hoàn tất việc chuẩn bị nhóm giao tiếp và đồ thị thực thi. Dưới đây, khối lượng dữ liệu được giữ cố định trong khi chỉ biến thiên băng thông truyền. Ví dụ di trú Qwen3-8B từ TP4 sang TP8 cần truyền khoảng 16,4 GB qua mạng, và việc dựng tensor đích cục bộ cũng cần đọc và ghi khoảng 4,7 GB dữ liệu. Đưa cùng một payload mạng lên một cổng 50 GbE đơn (6,25 GB/s) so với NIC 200 Gbit/s (25 GB/s) của chương này, riêng việc di chuyển mất khoảng 2,63 giây so với 0,66 giây — khác nhau bốn lần.

Nhưng nếu ta còn giả định việc thiết lập nhóm giao tiếp, chuẩn bị đồ thị thực thi và tiếp tục nhận request tuần tự chiếm 9 giây sau lần truyền, tổng thời gian trở thành khoảng 11,6 giây và 9,7 giây — chỉ giảm khoảng 17%. Nếu cả tám thẻ nằm trong một máy chủ 8×A100 duy nhất và việc di trú thay vào đó đi qua NVLink, ở 300 GB/s mỗi chiều mỗi A100, thẻ gửi nhiều dữ liệu nhất — khoảng 4,7 GB — chỉ cần khoảng 15,7 ms, và tổng thời gian vẫn khoảng 9,0 giây. Sàn 9 giây này giới hạn lợi ích của việc nâng băng thông thêm: ngay cả khi truyền mạng tiến về không, tổng thời gian cũng chỉ có thể tiến về 9 giây. Nếu các nhóm giao tiếp có thể được thiết lập và các đồ thị thực thi được chuẩn bị trước, thời gian chờ di trú có thể được rút ngắn hơn nữa.

Tại thời điểm này bản thân việc di chuyển đã gần chạm cận dưới vật lý của liên kết, và toàn bộ thời gian còn lại là chuẩn bị phần mềm. Theo tiêu chí ở Mục 1.3.4, loại khoảng trống này không thể được thu hẹp bằng liên kết nhanh hơn — chỉ bằng cách tái cấu trúc phần mềm: thiết lập các nhóm giao tiếp trước, chụp trước các đồ thị thực thi, tách rời các tiến trình khỏi việc lập lịch, và để việc chuẩn bị chồng lấp với việc truyền.

9.6.3 Lỗi một phần và khôi phục sinh trực tuyến

Trong một lần di trú có kế hoạch, nguồn vẫn có thể cung cấp một bản cập nhật cuối; sau một lỗi, dữ liệu của nguồn có thể không còn đọc được, và việc khôi phục phải dựa hoàn toàn vào trạng thái đã lưu trước đó và các bản ghi đầu ra. Việc khôi phục trước tiên phải xác định phần đầu ra nào mà người dùng đã nhận. Sau một lỗi có ba mục tiêu khả dĩ: khôi phục đủ trạng thái để tiếp tục decode; làm lại prefill dựa trên các token đã được xác định; hoặc lấy mẫu lại một đoạn đầu ra. Hai mục tiêu đầu tiếp tục chuỗi mà người dùng đã nhận; mục tiêu thứ ba đưa ra một lựa chọn ngẫu nhiên mới và có thể tạo ra một hậu tố khác. Với các rollout RL, điều này cũng thay đổi quá trình sinh mẫu.

Giả sử đầu vào ban đầu có 8192 token và 1025 token đầu ra đã được trả về cho người dùng, nhưng KV được lưu gần nhất chỉ bao phủ đầu vào ban đầu. Trong lúc khôi phục, nếu các đầu ra này đã được ghi lại một cách đáng tin cậy, ta chỉ cần đưa 1024 đầu ra đầu tiên trở lại như một lần prefill, dựng lại KV bao phủ 9216 token, rồi xử lý đầu ra thứ 1025 để tiếp tục sinh. Nếu một KV tương thích bao phủ 9216 token đã tồn tại, việc phát lại 1024 token này có thể được bỏ qua hoàn toàn.

Hình 9-44 biểu thị riêng hai loại bản ghi và các điểm đầu cuối của chúng. Một đầu ra đã được trả về không có nghĩa KV tương ứng của nó đã được lưu; trong lúc khôi phục, việc dùng các token đã ghi lại để tính lại dựng lại cùng một tiền tố mà không cần lấy mẫu lại các đầu ra đó.

Một write-ahead log (WAL) lưu một cách đáng tin cậy các thao tác hoặc kết quả đang chờ xử lý trước khi chúng được xác nhận ra bên ngoài. Ở đây, WAL cấp token lưu chuỗi đầu ra đã được xác định, còn KV lưu phép tính đã hoàn tất cho chuỗi đó. Cái trước quyết định tiếp tục chuỗi đầu ra nào sau khôi phục; cái sau quyết định còn phải làm lại bao nhiêu công việc. Dịch vụ sinh của DeepSeek V4 dùng loại cơ chế này; việc khôi phục cũng phải giữ phiên bản trọng số, chỉ số vị trí token và trạng thái decode nhất quán.

Phạm vi tác động của một lỗi được quyết định bởi nhóm đồng bộ. Mất một thẻ trong một nhóm tensor parallelism hoặc nhóm song song expert có thể làm dừng mọi request trên toàn bộ instance phối hợp đó; các replica hoàn chỉnh khác có thể tiếp tục phục vụ. Khôi phục sau lỗi tiến hành tuần tự qua phát hiện, dựng lại instance và khôi phục request; năng lực xử lý sau khôi phục quyết định các request bị tồn đọng cần thêm bao lâu để hoàn tất. Chương 10 phân tích sâu hơn các lựa chọn này ảnh hưởng thế nào đến các mẫu RL và tiến độ huấn luyện, và Chương 11 giải quyết việc khôi phục tác vụ cho các tool và môi trường.

9.7 So sánh toàn diện các phương án triển khai

9.7.1 Kết hợp replica, PD, AF và KV dùng chung

Mục này áp dụng các kết quả của các mục trước vào dịch vụ tám thẻ ở đầu chương, trước tiên xác định phương thức truyền trạng thái rồi so sánh liệu dịch vụ tổng thể có thể đáp ứng tốc độ đến và hạn khôi phục hay không. KV do P tạo ra có thể được bàn giao trực tiếp cho D, hoặc trước tiên đi vào một cụm dùng chung để D kéo về sau; nếu trạng thái mới do D sinh ra muốn được vòng P tiếp theo dùng, nó cũng phải được xác nhận là đã lưu và công bố. Bàn giao trực tiếp và lấy về qua cụm dùng chung có thể truyền cùng một nội dung, nhưng chiếm các liên kết và bộ đệm khác nhau.

Với KV cache context 1,125 GiB của chương này, bàn giao trực tiếp P→D di chuyển nó một lần; truyền qua cụm dùng chung di chuyển nó một lần trên mỗi cạnh P→cụm và cụm→D, cho tổng payload 2,25 GiB. Giả định cả hai cạnh chạy ở 25 GB/s và toàn bộ việc ghi phải hoàn tất trước khi đọc, trung gian cụm dùng chung thêm khoảng 96,6 ms chờ đợi, nhiều hơn bàn giao trực tiếp khoảng 48,3 ms.

Nếu D chỉ dùng trạng thái này một lần, sự trung gian này không cho lợi ích tái sử dụng nào. Nhưng nếu một instance khác sau đó tiếp tục cùng phiên, có cơ hội thay một lần tính lại tốn khoảng 856 ms (thời gian prefill từ Mục 9.2.3) bằng một lần lấy về tốn khoảng 48,3 ms; thời gian tiết kiệm đủ để bù đắp thời gian di chuyển thêm. Mục 9.7.3 định lượng lợi ích này so với khối lượng công việc của Ví dụ 9.8. Một cụm dùng chung giữ kết quả tính toán của một phiên cho các request sau dùng; AF thay vào đó thay đổi nơi mỗi tầng của request hiện tại thực thi — hai cái thay đổi các phần khác nhau của dòng thời gian.

Quy tắc tương tự áp dụng cho đầu vào hình ảnh. EC do E tạo ra và KV ngôn ngữ dùng các định danh cache khác nhau và chiếm không gian khác nhau; một cú trúng cache hình ảnh giảm công việc của E nhưng không tự động loại bỏ giai đoạn P của model ngôn ngữ tiếp theo. Trong đồ thị thực thi E→P→D, một cú trúng EC giảm yêu cầu của E, một cú trúng tiền tố ngôn ngữ giảm công việc của P, và tỷ lệ tài nguyên điều chỉnh khi khối lượng công việc của mỗi giai đoạn thay đổi.

9.7.2 So sánh các phương án dưới cùng ràng buộc chất lượng và tài nguyên

Ví dụ 9.8: Phương án triển khai inference nào có thể duy trì dịch vụ đồng thời dọn hết backlog khởi động trong hạn? Chúng ta dùng tài nguyên và khối lượng công việc ở đầu chương: bốn A100 80GB SXM và bốn H20 SXM5 96GB, với 3,5 request độc lập đến mỗi giây, mỗi request có 8192 token đầu vào và 1025 token đầu ra. Năng lực mỗi giai đoạn theo Ví dụ 9.2, và hai giai đoạn chiếm cùng một thẻ tuần tự khi chạy trên nó cùng nhau. Hai máy chủ dùng chung một kênh payload 25 GB/s, với mọi lần truyền đều dùng chung cùng băng thông liên kết đó. Trong cửa sổ so sánh, model và các thiết lập sinh giống hệt nhau, và các request không dùng chung các tiền tố tái sử dụng được với nhau. Dịch vụ khởi động từ trạng thái dừng, và cả ba phương án triển khai đều sẵn sàng sau 10 giây; sau khi sẵn sàng, hàng đợi được xử lý theo mô hình dòng chảy liên tục. Mục tiêu thiết kế là duy trì việc xử lý các request mới đến và dọn xong backlog khởi động trong vòng 60 giây tính từ lúc bắt đầu khởi động.

Các điều kiện dung lượng cũng phải được kiểm tra. Sau 1024 bước decode, KV của mỗi request bao phủ 9216 token, khoảng 1,27 GiB. Trên một H20, với batch size cư trú 32 request hoạt động, tổng trạng thái khoảng 40,5 GiB; cộng một bộ đệm nhận 1,125 GiB dành riêng cộng khoảng 15,3 GiB trọng số cho khoảng 56,9 GiB, vừa khít trong 96 GB (khoảng 89,4 GiB) bộ nhớ GPU. Quy đổi sang trạng thái MLA gọn, mỗi mục khoảng 618 MiB; 32 mục cộng một bộ đệm nhận 549 MiB tổng cộng khoảng 19,8 GiB. Phía A100 chỉ cần giữ hai trạng thái đồng thời — một đang được tính và một đang được gửi — tổng cộng 2,25 GiB. Phương án cụm dùng chung còn có 64 GiB năng lực trạng thái. Các request chưa được thực thi chỉ giữ đầu vào của chúng, và phép tính bắt đầu một khi không gian cache được cấp phát.

Bảng dưới đây so sánh ba phương án: replica đầy đủ, PD bàn giao trực tiếp, và PD có trung gian cụm dùng chung. Phương án cụm dùng chung truyền mỗi request hai lần qua kênh dùng chung vì nó ghi toàn bộ đối tượng trước khi đọc lại; cả phía đọc lẫn phía ghi của cụm đều có thể đạt băng thông kênh.

Phương án triển khai	Tổ chức P, D	Payload kênh mỗi request	Năng lực tính toán, request/s	Năng lực kênh, request/s	Thông lượng tổng thể sau khởi động, request/s
Tám replica đầy đủ	Mỗi thẻ chạy cả P và D	0	3.02	—	3.02
PD trực tiếp	Bốn A100 làm P, bốn H20 làm D	1.125 GiB	4.55	20.7	4.55
PD có trung gian cụm dùng chung	Cùng tỷ lệ P, D, P→cụm→D	2.25 GiB	4.55	10.3	4.55
PD trực tiếp, trạng thái MLA gọn	Bốn A100 làm P, bốn H20 làm D	549 MiB	4.55	43.4	4.55
PD có trung gian cụm dùng chung, trạng thái MLA gọn	Cùng tỷ lệ P, D, P→cụm→D	1.07 GiB	4.55	21.7	4.55

Replica đầy đủ chỉ hoàn tất 3,02 request mỗi giây, liên tục dưới tốc độ đến 3,5 request/s, nên phương án này bị loại đầu tiên. Năng lực kênh của cả hai phương án PD đều vượt xa 4,55 request/s, nên cả hai đều bị giới hạn bởi cụm tính toán. Dưới tải 3,5 request/s, truyền trực tiếp tiêu thụ khoảng 4,2 GB/s và trung gian khoảng 8,5 GB/s; trong giai đoạn xả 4,55 request/s, chúng cần lần lượt khoảng 5,5 và 11,0 GB/s. Với trạng thái MLA gọn, bốn con số này trở thành 2,0, 4,0, 2,6 và 5,2 GB/s — năng lực kênh tăng gấp đôi, nhưng kết luận không thay đổi.

Hai phương án có cùng thông lượng trạng thái ổn định, nhưng PD trực tiếp phù hợp hơn với tập request này. Các request sau không tái sử dụng tiền tố của các request này, vậy mà trung gian làm gấp đôi khối lượng truyền của kênh và thêm khoảng 48,3 ms chờ mỗi request. Cụm dùng chung 64 GiB có thể chứa nhiều nhất 56 tiền tố 1,125 GiB hoàn chỉnh, hoặc 119 dưới trạng thái MLA gọn; dưới khối lượng công việc này, không mục nào được giữ lại sẽ được dùng lại. Bàn giao trực tiếp làm cùng một việc với nhiều dư địa liên kết hơn và rút ngắn thời gian chờ bàn giao. Ví dụ này vì thế chọn bốn A100 cho P, bốn H20 cho D, và truyền trực tiếp P→D.

Tiếp theo chúng ta kiểm tra liệu phương án này có thể dọn xong backlog khởi động trong hạn hay không. Theo phép tính xả ở Mục 9.6.1, 35 request tồn đọng sau 10 giây khởi động được xả hết khoảng giây thứ 43 (tính từ lúc bắt đầu khởi động) dưới PD trực tiếp, đạt mục tiêu 60 giây. Replica đầy đủ tiếp tục thêm khoảng 0,5 request mỗi giây ngay cả sau khi sẵn sàng, nên đến giây thứ 60 backlog đã tăng từ 35 lên khoảng 59; ngay cả ở 4,17 request/s của co-location chunked lý tưởng, việc xả cũng không xong cho đến giây thứ 63, cũng trượt mục tiêu.

Ngược lại, ta cũng có thể suy ra tốc độ dịch vụ tối thiểu đáp ứng hạn này. Khởi động mất 10 giây, để lại 50 giây để dọn 35 request trong khi tiếp tục xử lý 3,5 request mới đến mỗi giây, đòi hỏi

$$\mu-3.5\geq\frac{35}{50},\qquad \mu\geq4.2\ \text{requests/s}.$$

4,55 request/s của PD trực tiếp vượt yêu cầu tối thiểu này với biên khoảng 8%. Nếu hiệu quả kernel thực tế chỉ bằng 90% giá trị giả định trong Ví dụ 9.2, năng lực cụm D tụt xuống khoảng 4,10 request/s; trạng thái ổn định vẫn xử lý được dòng request bền vững, nhưng chỉ khoảng 0,60 request/s đi vào việc dọn backlog, đẩy việc xả đến khoảng giây thứ 68,5 và trượt mục tiêu. Độ dốc của mỗi đường giảm dần trong Hình 9-42 chính là năng lực dọn backlog ròng này — tốc độ dịch vụ trừ tốc độ đến.

Một khi xác nhận đáp ứng được hạn, ta so sánh chi phí. Khi tính chi phí dịch vụ, phương thức tính tiền tài nguyên cũng quan trọng. Giả sử cả tám thẻ được giữ trước theo giờ, với tổng chi phí tám đơn vị tiền tệ mỗi giờ, và dịch vụ thực sự hoàn tất 3,5 request mỗi giây, cho 12600 request hoàn tất mỗi giờ, với chi phí khoảng 0,63 đơn vị tiền tệ mỗi nghìn request. Nếu tốc độ đến vẫn là 3,5 request/s, năng lực 4,55 request/s không tạo ra thêm request nào để xử lý; năng lực dư thừa được dùng để hấp thụ các đợt bùng nổ và dọn backlog khởi động.

So sánh lượng xử lý ở tải đầy đủ, 3,02 và 4,55 request/s tương ứng với khoảng 0,74 và 0,49 đơn vị tiền tệ mỗi nghìn request. Nếu doanh nghiệp còn đặt một hạn hoàn tất, và chỉ một phần tư số request trong phương án sau đạt điều kiện, tỷ lệ đạt điều kiện tụt xuống khoảng 1,14 request/s, và chi phí mỗi nghìn request đạt điều kiện tăng lên khoảng 1,95 đơn vị tiền tệ. Điều này thường được viết là

$$C_{effective}=\frac{\text{total cost over the accounting period}} {\text{number of requests or tasks meeting quality and deadline}}.$$

Tử số biến thiên theo tài nguyên tính toán, bộ nhớ chính, mạng và các instance dự phòng được giữ chạy; mẫu số biến thiên theo các lần đến thực tế và các lần hoàn tất đạt điều kiện. Lấy một agent thoát sớm làm ví dụ: nó có thể sinh ít token hơn và tiêu thụ ít tài nguyên hơn, nhưng vì nó không hoàn tất tác vụ, lần thoát này không được tính vào số tác vụ hoàn tất đạt điều kiện.

9.7.3 Điều chỉnh triển khai sau khi khối lượng công việc thay đổi

Giờ hãy thay đổi điều kiện trong Ví dụ 9.8 rằng “các tiền tố không bao giờ được tái sử dụng”. Giả sử một instance khác sẽ tái sử dụng KV cache context 1,125 GiB của mỗi phiên thêm một lần. Tính lại 8192 token này trên một A100 mất 0,856 giây, trong khi lấy về chỉ mất 48,3 ms. Chi phí thêm 48,3 ms đã trả cho việc trung gian, cộng 48,3 ms cho lần lấy về sau đó, tổng cộng khoảng 96,6 ms — thấp hơn nhiều 856 ms của việc tính lại; một lần tái sử dụng sau đó đem về ròng khoảng 760 ms tiết kiệm. Cụm dùng chung nhờ đó có một mục đích cụ thể: thay lặp lại tính toán bằng một lần đọc ngắn hơn.

Lợi ích này đồng thời làm tăng nhu cầu trên kênh. Mỗi lần bàn giao ban đầu ghi một lần và đọc một lần; lần tái sử dụng sau đọc thêm một lần, tổng cộng di chuyển 3,375 GiB. Ở 3,5 cặp-request đến mỗi giây, điều này cần khoảng 12,7 GB/s; kênh có thể hỗ trợ nhiều nhất khoảng 6,9 cặp-request/s. Với trạng thái MLA gọn, ba lần truyền tổng cộng 1,61 GiB, cần khoảng 6,0 GB/s ở 3,5 cặp-request/s, và kênh có thể hỗ trợ tới khoảng 14,5 cặp-request/s. So với một lần truyền, tái sử dụng sau đó làm tăng khối lượng đọc, tiêu thụ dư địa băng thông vốn có trước đó. Cụm dùng chung tiết kiệm việc tính lại đồng thời cũng hạ trần thông lượng cặp-request mà kênh có thể hỗ trợ.

Điều cụm dùng chung thay đổi là số lần truyền. Dưới đây, ta cố định D không có cache và thay vào đó biến thiên lượng đầu vào P phải tính lại, xét liệu việc phân bổ tài nguyên cũng nên điều chỉnh. Giả sử P đã trúng cục bộ 6144 token, còn D vẫn rỗng. Theo tính toán ở Mục 9.2.4, các replica đầy đủ cùng đạt khoảng 4,90 request/s; sự phân chia ban đầu bốn A100-P, bốn H20-D vẫn ở 4,55 request/s; và chuyển sang hai A100 cho P với sáu thẻ còn lại cho D đạt 5,69 request/s. Giả định cùng khởi động 10 giây và tốc độ đến 3,5 request/s, ba phương án xả hết lần lượt khoảng giây thứ 35,1, 43,2 và 26,0, tính từ lúc bắt đầu khởi động. Sau cú trúng tiền tố, các replica đầy đủ thực ra xả sớm hơn tỷ lệ PD ban đầu, vốn không còn là lựa chọn tốt nhất; hai A100 cho P với sáu thẻ còn lại cho D là sự phân công lao động tốt nhất cho khối lượng công việc này.

Giờ khôi phục đầu vào không trúng cache nhưng tăng đầu ra lên 4097 token — tức các request đòi hỏi inference lâu hơn. Sự phân công lao động tốt nhất trở thành hai A100 cho P và sáu thẻ còn lại cho D, nhưng điều này chỉ đạt khoảng 1,26 request/s. Tại thời điểm này, dù tỷ lệ P:D được điều chỉnh thế nào, tám thẻ ban đầu cũng không thể xử lý 3,5 request mỗi giây. Nhân bản ba lần triển khai tám thẻ như vậy cho năng lực kết hợp khoảng 3,78 request/s, hơi đạt để duy trì tốc độ đến; nếu cũng cần cùng hạn khởi động và xả, năng lực thiết yếu ít nhất là 4,2 request/s, và bốn nhóm cung cấp khoảng 5,04, nên phải cấu hình bốn nhóm. Mở rộng tổ hợp tài nguyên tính toán ban đầu theo nhóm, duy trì tốc độ đến cần 24 thẻ, trong khi đáp ứng hạn khôi phục cần 32. Mục đích của tài nguyên tính toán thêm là làm tăng tốc độ phân rã của backlog.

Điều này cũng cho thứ tự các suy dẫn của chương này nên được áp dụng cho một hệ thống mới. Trước tiên chuyển khối lượng công việc của mỗi request thành các yêu cầu tài nguyên theo các loại; rồi dùng phân bổ tài nguyên số nguyên để tìm cụm tài nguyên hoặc đơn vị thực thi bận nhất; tính đến thời gian truyền trạng thái và dấu chân bộ nhớ theo thứ tự thực thi; và cuối cùng dùng năng lực xử lý còn lại — tốc độ dịch vụ trừ tốc độ đến — để xác định một đợt bùng nổ hoặc backlog khởi động kéo dài bao lâu. Nếu nút thắt là D, thêm P sẽ không giảm backlog; nếu nút thắt là kênh dùng chung, thêm replica tính toán chỉ khiến nhiều request phải chờ lấy về hơn.

Trường hợp tám thẻ PD và trường hợp expert MoE gặp nhau ở đây. Cái trước giao mỗi giai đoạn cho các tài nguyên tính toán phù hợp hơn với giai đoạn đó; cái sau giảm lượng đọc trọng số nhờ tái sử dụng trong lô rồi dàn trải công việc của đơn vị thực thi bận nhất lên các replica expert. KV dùng chung thay vào đó bảo tồn các kết quả tính toán đã hoàn tất cho các request tương lai tái sử dụng; khởi động và khôi phục quyết định khi nào các tài nguyên tính toán này có thể bắt đầu phục vụ. Cơ sở cho một lựa chọn triển khai là các phương pháp triển khai này gộp lại thay đổi bao nhiêu phép tính và thời gian chờ đợi, và mất bao lâu để dọn xong backlog.

Tăng tốc một giai đoạn cũng thay đổi tỷ lệ instance. Giả sử liên kết có năng lực dồi dào, mỗi instance P xử lý 20 request mỗi giây, và mỗi instance D hoàn tất 5 request cùng loại mỗi giây; một P đi kèm bốn D cân bằng năng lực của hai cụm. Nếu giai đoạn D nhanh hơn bốn lần, giữ nguyên tỷ lệ ban đầu sẽ đẩy năng lực cụm D lên 80 request/s trong khi P vẫn ở 20; chuyển sang một P trên một D cho cả hai cụm 20 request/s và giải phóng ba instance D. Do đó lợi ích của việc tăng tốc một giai đoạn thể hiện ở chỗ cần ít tài nguyên hơn để hoàn thành cùng một công việc.

Bài tập chương

Các bài tập đi qua việc tính lại, các điều kiện đã thay đổi và thiết kế độc lập. Hai câu hỏi đầu thiết lập một đơn vị request chung; các bài 3 đến 9 mỗi bài thay đổi một điều kiện tính toán, giao tiếp hoặc trạng thái; bài 10 làm việc qua việc thiết kế một khối lượng công việc mới; và bài 11 làm lại phán đoán với trạng thái bàn giao được thay bằng MLA. Các bài được đánh dấu “core” chạy qua nhiều lớp tài nguyên.

9-1 Số lần gọi và bàn giao trạng thái của ba phương án triển khai inference. Với một request có 8192 token đầu vào và 1025 token đầu ra, hãy vẽ sơ đồ các phương án triển khai replica đầy đủ, PD và KV dùng chung, liệt kê cho mỗi phương án số lần gọi mỗi request, KV được tạo ra ở đâu, và các bàn giao xuyên instance. Sau đó đổi độ dài đầu ra thành 1 token và xác định công việc nào không còn cần chạy. Cuối cùng, xét trường hợp tiếp tục sinh sau một lần gọi tool, và đánh dấu vị trí của token cuối cùng đã được trả về nhưng KV tương ứng của nó chưa được sinh.

9-2 Nút thắt liên kết và thành phần request thay đổi tỷ lệ PD như thế nào. Tính lại 25 phương án phân bổ số nguyên từ Ví dụ 9.2, lần này đặt băng thông liên kết hiệu dụng đúng bằng băng thông cần để truyền một snapshot 1,125 GiB mỗi giây (khoảng 1,21 GB/s). Tìm cận trên mới của thông lượng tổng hợp; khi tốc độ đến đúng bằng cận này, thêm mười request cùng lúc và tìm backlog thay đổi thế nào theo thời gian. Sau đó kiểm tra lại hai kịch bản trúng tiền tố và 129 đầu ra. Cuối cùng, đổi giả định hiệu quả giai đoạn từ 50% xuống 40% đỉnh, suy lại năng lực prefill và decode của hai loại thẻ, và xác định liệu bốn A100 làm P và bốn H20 làm D vẫn vượt tốc độ đến 3,5 request/s hay không.

9-3 Batch size expert, tập lệnh và độ rộng bit trọng số thay đổi nút thắt thực thi CPU như thế nào. Dùng các hình dạng expert từ Ví dụ 9.3, tìm riêng cho kernel AVX-512 và AMX số token mỗi expert nhận được tại đó việc thực thi CPU chuyển từ bị giới hạn bởi đọc sang bị giới hạn bởi tính toán; sau đó tính lại cả hai điểm giao nhau với băng thông bộ nhớ đổi thành giá trị xuyên socket 125 GB/s. So sánh thời gian thực thi khi mỗi expert nhận 1 token so với 128 token. Đổi trọng số thành một byte mỗi phần tử trong khi giữ phép tính CPU hiệu dụng cố định, giải lại giao điểm của đường đọc và đường tính toán, và giải thích nó dịch chuyển theo hướng nào.

9-4 Khối lượng truyền, số lần khởi động và chồng lấp giao tiếp của PD và AF[core]. Dùng Qwen3-8B, với băng thông bàn giao hiệu dụng 25 GB/s, và chi phí khởi động lần lượt 1, 5 và 20 μs, so sánh một lần bàn giao 1,125 GiB với 72 lần bàn giao có tổng cùng số byte. Sau đó, dùng các kích thước payload AF thực tế từ Ví dụ 9.4, tính thời gian bàn giao tích lũy cho một request hoàn chỉnh với 8192 token đầu vào và 1025 token đầu ra.

Cũng xét bốn micro-batch độc lập, mỗi cái mất 2 ms ở phía attention và 3 ms ở phía feedforward. So sánh tổng thời gian thực thi hoàn toàn tuần tự với một pipeline hai giai đoạn lý tưởng, rồi tìm, với điều kiện pipeline vẫn nhanh hơn phương án tuần tự, mức tăng kết hợp tối đa giữa thời gian giao tiếp thêm và mất hiệu quả mà đường tới hạn có thể hấp thụ.

9-5 Ràng buộc dung lượng trọng số và thông lượng CPU cho inference không đồng nhất. Khôi phục các yêu cầu lưu trữ trọng số, bộ đệm GPU và bộ nhớ chính từ cấu hình đã lưu của DeepSeek V4-Flash hoặc Kimi K2. Sau khi tăng độ đồng thời request, dự đoán số expert được truy cập, số tác vụ của mỗi expert, và nút NUMA chịu tải nặng nhất. Rồi dựng một tập điều kiện request nơi tổng trọng số vừa khít nhưng tốc độ đến vượt năng lực tính toán CPU, và suy ra tốc độ tăng trưởng backlog.

9-6 Ràng buộc dung lượng trên replica expert và thu hồi chi phí nhân bản. Cho tám expert nhận lần lượt $[32,16,8,4,2,1,1,0]$ hàng đầu vào, so sánh chi phí tính toán khi chỉ tính các hàng hợp lệ, khi đệm đầu vào của các expert không rỗng lên 32 hàng, và khi đệm đầu vào của mọi expert lên 32 hàng. Sau đó, dưới các điều kiện của Ví dụ 9.6, tìm số lô tối thiểu cần để thời gian tiết kiệm tích lũy lần đầu vượt chi phí nhân bản; rồi đổi năng lực thêm mỗi thẻ thành 32 MiB và giải thích vì sao các phương án replica bất khả thi nên bị loại trước. Nếu điểm nóng thay đổi theo thời gian, giải thích cách dự đoán lợi ích tích lũy của việc nhân bản từ tải quan sát được trong một cửa sổ giám sát, và so sánh nó với chi phí di trú.

9-7 Điều kiện cho lợi ích của việc lưu, lấy về và tính lại KV[core]. Cho một KV tiền tố chiếm 1,125 GiB, và giả định các request tiếp theo sẽ dùng tiền tố này tổng cộng 100 lần, so sánh tổng thời gian của ba cách tiếp cận: tính lại một lần và giữ cư trú, lấy về một lần và giữ cư trú, và đọc từ xa ở mỗi lần dùng. Còn tính đến thời gian ghi và thời gian cache được giữ lại giữa hai request, và suy ra khi nào việc lưu KV đáng giá hơn việc tính lại nó; thiết kế một ví dụ nơi thay đổi dung lượng HBM khả dụng buộc trạng thái bị hoán đổi ra khỏi HBM. Dùng các bản ghi hai engine hiện có, giải thích những cơ hội tái sử dụng nào được giữ lại khi cụm CPU dùng chung tăng từ 4 GiB lên 8 GiB.

Sau đó, dùng cấu hình mỗi thẻ của DGX A100 từ Mục 9.5.2, tính: với khoảng cách 5 phút giữa hai lần dùng cùng một tiền tố, mỗi GPU cần dung lượng cache tối thiểu bao nhiêu, và các tầng lưu trữ nào tham gia? Với đầu vào mới lần lượt 128 và 512 token, tổng thời gian nạp trước từng tầng từ bộ nhớ host là bao nhiêu, và cần đọc trước bao nhiêu tầng trước khi tính toán bắt đầu để các lần đọc được che phủ hoàn toàn bởi tính toán? Cuối cùng, dùng định mức 1 DWPD của D7-P5520, tìm tỷ lệ KV mới mà SSD có thể chấp nhận bền vững về dài hạn; nếu tỷ lệ trúng tiền tố là 50%, giảm một nửa tốc độ sản xuất KV mới, tỷ lệ này trở thành bao nhiêu?

9-8 Các lựa chọn khôi phục cho lỗi trang KV và không tương thích phiên bản. Giải thích sự khác biệt giữa hai cách đếm khi KV trị giá 1024 token được đọc nhưng chỉ 1008 trong số các token đó thực sự được tái sử dụng. Với lỗi trang, trang cụt và không tương thích phiên bản, lần lượt đề xuất các điều kiện theo đó nên tiếp tục chờ, tính lại một phần, hoặc bỏ cache. Giải thích cách kiểm tra, lần lượt, liệu request có thể hoàn tất, liệu dữ liệu có cache có thể sửa chữa được, và liệu đầu ra khớp với kết quả sẽ có khi không dùng cache.

9-9 Điểm giao nhau băng thông cho định tuyến cache và độ trễ đuôi của token đầu tiên. Suy ra băng thông tại đó lần lấy về từ xa của B lần lượt bằng thời gian trúng cục bộ của A và thời gian tính lại cục bộ của B trong Ví dụ 9.7, và tính cho $p=0.5,0.9,0.99$ thời gian token đầu tiên trung bình khi chọn đường A, cùng với p99 được định nghĩa qua phân phối tích lũy nghịch đảo. Sau đó giả sử khi replica HBM không khả dụng, replica CPU vẫn khả dụng, và quá trình lấy về có thể chồng lấp với thời gian xếp hàng chờ 80 ms. Kiểm tra liệu mô hình phân bố hai điểm ban đầu còn áp dụng hay không.

9-10 Mở rộng quy mô PD và xếp hàng chờ dưới khối lượng công việc hỗn hợp đầu ra dài/ngắn[core]. Tiếp tục Ví dụ 9.8, giả sử một nửa trong số 3,5 request mỗi giây xuất 1025 token và nửa kia xuất 4097 token, đều có 8192 token đầu vào và không có cú trúng tiền tố; năng lực trong mỗi cụm được phân bổ theo khối lượng công việc trung bình dài hạn. Trước tiên, dùng phương pháp của Ví dụ 9.2, tìm GPU-giây D của hai loại thẻ ở cả hai độ dài đầu ra, lấy yêu cầu D trung bình mỗi request, rồi liệt kê mọi tổ hợp số nguyên để phân bổ tám thẻ giữa các giai đoạn P và D. Cho phép nhân bản cùng tổ hợp tám thẻ, tìm số nhóm tối thiểu cần cho mỗi mục tiêu trong hai mục tiêu: duy trì tốc độ đến; và, với thời gian khởi động 10 giây, dọn xong backlog vào giây thứ 60 sau khi bắt đầu khởi động. Cuối cùng, dồn các request đầu ra dài vào mười giây đầu của mỗi phút, vẽ hàng đợi thu được, và giải thích cửa sổ thời gian nào quyết định lựa chọn năng lực khi nhu cầu trung bình không đổi.

9-11 Phán đoán PD/AF cho MLA so với GQA. Thay trạng thái bàn giao được dùng xuyên suốt chương này bằng biểu diễn MLA gọn của DeepSeek-V3 (61 tầng, $d_c=512$, $d_r=64$, BF16), giữ nguyên năng lực giai đoạn của Ví dụ 9.2, payload AF của Ví dụ 9.4, và khởi động 5 μs. Trước tiên tìm số byte trạng thái cho 8192 token, và thời gian một bàn giao PD ở 25 và 50 GB/s; rồi tìm số hạng liên kết của $\mu_{PD}$, và cho ngưỡng băng thông trên đó liên kết trở thành ràng buộc chặn. Dùng $\alpha^*=(V_{KV}-V_{AF})/(71B)$, tìm thời gian khởi động tới hạn cho cả hai tốc độ liên kết, và nêu, với đầu ra 1025 và 4097 token, các bàn giao AF tích lũy 1024 bước và 4096 bước gấp bao nhiêu lần một bàn giao PD. Cuối cùng, thêm chi phí biến đổi query 2,05 GFLOP mỗi bước vào cụm D, tìm thay đổi năng lực cụm D thu được dùng phép tính hiệu dụng 74 TFLOP/s của H20, và xác định liệu bốn H20 vẫn đủ hay không.

Ví dụ làm việc: CPU thực thi expert chuyển từ bị giới hạn bởi đọc sang bị giới hạn bởi tính toán ở batch size nào? Khi số hạng đọc và số hạng tính của đường CPU một expert bằng nhau,

$$\frac{2mP_e}{C_C}=\frac{2P_e}{B_D}, \qquad m=\frac{C_C}{B_D}.$$

Ở đây, với BF16 dùng hai byte mỗi tham số và hai phép toán dấu phẩy động mỗi tham số mỗi hàng, hai hệ số triệt tiêu chính xác. Kernel AVX-512 với 1,8 TFLOP/s và 220 GB/s cho $m\approx8.2$: dưới chín token mỗi expert, sự chờ đợi bị chi phối bởi việc đọc trọng số; trên con số đó, nó bị chi phối bởi tính toán. 21,3 TFLOP/s của kernel AMX đẩy điểm giao nhau này lên khoảng 97 token. Khi một luồng đọc bộ nhớ trên một socket khác, băng thông giảm xuống 125 GB/s, di chuyển hai điểm giao nhau lên khoảng 14 và 170 token; thời gian đọc trọng số của một hàng tăng khoảng 76%, và kernel AVX-512 vẫn bị chi phối bởi tính toán ở 128 hàng.

Điểm giao nhau ở đây trả lời một câu hỏi khác với các ranh giới hàng 71/72 và 688/689 trong Hình 9-14. Cái trước là ranh giới tại đó CPU chuyển từ bị giới hạn bởi băng thông sang bị giới hạn bởi tính toán; cái sau so sánh toàn bộ đường CPU và GPU, gồm cả việc di chuyển trọng số. Một khi CPU vượt qua điểm giao nhau của nó, nó bị giới hạn bởi tính toán, nhưng nó vẫn có thể vượt đường GPU — vốn trước tiên phải di chuyển trọng số — cho đến khi chi phí tính toán tích lũy vượt quá chi phí di chuyển này.

Chú thích nguồn

• Sở hữu trọng số, trạng thái và giao tiếp cho cùng một request MoE. Cấu hình TP2×EP4 của nó, việc xử lý cùng một lô request và định dạng truyền FP32 là các điều kiện giảng dạy tường minh, dùng để minh họa cụ thể quyền sở hữu giao tiếp.

• Tài liệu lưu trữ về DistServe, Splitwise và việc đặt giai đoạn có thể tìm thấy trong tài liệu mở rộng của chương này và nghiên cứu về phân công lao động theo giai đoạn và bàn giao trạng thái.

• Tính toán bàn giao PD/AF cho Qwen3-8B, dùng các hình dạng model chính thức cố định, số byte và các giả định khởi động. Script sinh đọc một file JSON cùng tên. 25 GB/s dùng đơn vị thập phân, 1,125 GiB dùng đơn vị nhị phân; payload chính xác là 1207959552 byte, thời gian truyền thuần là 48,31838208 ms, và với 5 μs cộng thêm là 48,32338208 ms. Thời gian bàn giao AF tích lũy cho 1024 bước decode của một request được cho trong các kết quả tương ứng.

• Phân bổ số nguyên P, D không đồng nhất, so sánh đồng nhất tám A100, so sánh đồng nhất tám H20, trúng tiền tố, 129 đầu ra, 4097 đầu ra. Trường derived_stage_rates của mỗi kết quả liệt kê, theo thẻ, FLOP, lượng đọc, hai thời gian Roofline và tài nguyên ràng buộc cho prefill và decode.

• Các năng lực giai đoạn được suy ra bởi phép tính pd-pool từ bảng phần cứng và một hạch toán lượt truyền thẳng theo toán tử cho Qwen3-8B. Các con số đỉnh A100 80GB SXM lấy từ datasheet NVIDIA A100. NVIDIA chưa công bố datasheet H20; model và dung lượng lấy từ tài liệu AI Enterprise vGPU, còn tính toán BF16 và băng thông bộ nhớ lấy từ Bảng 3 ở trang 8 của MegaScale-Infer; các hàng A800 và H800 của cùng bảng khớp với datasheet NVIDIA. Hiệu chuẩn 50% đến từ Mục 8.6.3 và các bản ghi hiệu quả từng vòng của Thí nghiệm 8-1.

• Tính toán bàn giao PD/AF cho trạng thái MLA gọn, cùng với các so sánh MLA và GQA ở 50 GB/s; số byte mỗi token khớp với hàng deepseek-v3 của phép tính cache xuyên model. $d_c=512$ và $d_r=64$ được lấy từ trang 12 của bài báo DeepSeek-V2; V3 dùng cùng cấu hình attention. Payload chính xác là 575.668.224 byte; truyền thuần ở 25 GB/s là 23,02672896 ms, và thời gian khởi động tới hạn là 23003136/71 ns.

• Phân bổ số nguyên P, D dưới trạng thái MLA gọn, liên kết 50 GB/s, và so sánh trạng thái GQA 50 GB/s. 2.046.820.352 FLOP phụ mỗi bước của đường gọn được cho bởi trường mla_compact_path của các kết quả bàn giao MLA, và khớp từng tầng với hàng kv_b_proj của bảng toán tử decode một bước V3.

• Dỡ trọng số và vị trí thực thi và ghi chú phiên bản triển khai.

• Kernel AVX-512, 1 token mỗi expert, 128 token; kernel AMX, 1 token, 128 token; trường locality_reuse_regions của mỗi kết quả cho hai điểm giao nhau ở 71/72 và 688/689. Thông lượng kernel CPU được cho ở trang 4 và 6 của bài báo KTransformers; băng thông bộ nhớ và cấu hình PCIe ở trang 10; đỉnh A100 40GB PCIe từ bảng phần cứng.

• Các bản ghi thí nghiệm KTransformers công khai. Nền tảng hướng dẫn là dual 6454S + 4090; nền tảng của bài báo là dual 8452Y; các kết quả Expert Deferral đã công bố gồm cả trường hợp cải thiện chất lượng và suy giảm chất lượng.

• Các bản ghi cấu hình DeepSeek V4-Flash và Kimi K2. Các giới hạn độ đồng thời trong bảng được lấy từ cấu hình triển khai.

• Thực thi xuyên máy và tiến hóa khung và cơ sở cho việc mở rộng AF.

• Ghi chú về MoE serving tax, CRAFT và nghiên cứu khởi động.

• Các phép tính hoàn vốn cho nhân bản trong cùng HGX qua NVLink và nhân bản xuyên máy chủ qua ConnectX-7. Các ví dụ này giữ định tuyến và không gian trống thêm mỗi thẻ cố định, và tính thời gian chuẩn bị dưới nhân bản tuần tự. 989,4 TFLOP/s và 3350 GB/s của H100 SXM từ bảng phần cứng, cả hai lấy ở 50%; NVLink 450 GB/s mỗi chiều từ spec NVIDIA H100; NIC 50 GB/s mỗi chiều từ datasheet ConnectX-7. Thời gian chuẩn bị lần lượt là 0,62220256 ms và 5,31982304 ms; khoản tiết kiệm mỗi lô là 402784256/1675 ns (khoảng 0,2404682 ms); mức tối thiểu 3 lô và 23 lô được tính bằng các giá trị không làm tròn.

• Các bản ghi thí nghiệm thực thi expert và backend.

• Nghiên cứu về các tầng cache, đường đi và định tuyến.

• Datasheet DGX A100 (8×A100 80GB, 2 TB bộ nhớ host, 8×3,84 TB NVMe U.2, 8 NIC 200 Gbit/s một cổng) và bản tóm tắt sản phẩm Solidigm D7-P5520 (đọc/ghi tuần tự 128K tới 7100/4200 MB/s, 1 DWPD trong 5 năm). Dung lượng, thời gian giữ lại, thời gian lấy về và ghi, số tầng nạp trước mỗi tầng, và hạn ngạch ghi SSD trong mục này được cho bởi phép tính lưu trữ KV đa tầng; chạy python3 calculations/calc.py kv-tiers để tính lại. Bộ nhớ host được chia đều cho 8 GPU từ tổng 2 TiB; đọc/ghi SSD dùng các giá trị đỉnh của spec.

• Wang và cộng sự, KVCache Cache in the Wild (USENIX ATC 2025), Mục 3.4: Trace A là khối lượng trò chuyện của người dùng cá nhân, Trace B là khối lượng API; các kết luận dung lượng áp dụng cho các model GQA và được ước tính bằng tốc độ request tối đa mỗi instance.

• Báo cáo kỹ thuật Mooncake, Mục 4 và Bảng 1 (một trace mẫu một giờ với 23.608 request, trung bình 7590 token đầu vào); sự tập trung của trace Alibaba Cloud được bàn trong bài báo được trích trong ghi chú trước.

• Gao và cộng sự, Cost-Efficient Large Language Model Serving for Multi-turn Conversations with CachedAttention (USENIX ATC 2024), các Mục 3.2–3.3 mô tả nạp trước từng tầng, lưu bất đồng bộ, và prefetch cùng trục xuất dựa trên hàng đợi; các Mục 4.3.2–4.3.3 cho các phép đo bộ đệm nạp trước và tỷ lệ trúng.

• So sánh dung lượng cụm KV CPU dùng chung và phát lại một agent với context được bảo toàn thực tế. So sánh dung lượng dùng một tác vụ tra cứu có kiểm soát; việc phát lại agent thực tế cho thấy cả sự kết thúc sớm lẫn chất lượng tác vụ suy giảm.

• Nội dung về tính bền vững trạng thái và dịch vụ sinh của báo cáo kỹ thuật DeepSeek V4, và ghi chú đọc của chương này.

• Đọc trang sau khởi động lại và hạch toán tái sử dụng hiệu dụng; lượng đọc là 144 MiB và lượng tái sử dụng hiệu dụng là 141,75 MiB. Trong 64 trang (1024 token) được đọc, 63 trang (1008 token) được tái sử dụng.

• So sánh các chính sách prefetch cho trang cụt; cửa sổ quan sát thí nghiệm là 60 giây.

• Các phép tính định tuyến cache cho lấy về qua 50 GbE và lấy về qua 200 GbE, bao phủ toàn bộ đường tuần tự từ xa → bộ nhớ host → GPU; thời gian tính lại và tính sau trúng cache được lấy bằng cách chia FLOP ma trận cho 50% của 312 TFLOP/s A100 80GB SXM. PCIe 4.0 của A100 cung cấp 64 GB/s gửi/nhận kết hợp, theo datasheet A100 80GB.

• Nghiên cứu về các sự kiện cache và quyết định định tuyến, phân bố hai điểm cho việc vô hiệu hóa cache.

• Hạch toán cặp cho áp lực định tuyến thực tế, phân biệt thời gian hoàn tất của request mục tiêu với cặp tác vụ hoàn chỉnh; các điều kiện ban đầu được giữ nguyên cùng các kết quả.

• Nghiên cứu tổng hợp về Breaking the Ice; nghiên cứu dùng vLLM v0.10.1.1.

• Các quan sát nhánh request của HiCache, dùng chuỗi sự kiện cho cùng một ID request để giải thích hạn ngạch và tỷ lệ trúng hiệu dụng. Trong bản ghi ban đầu, hạn ngạch prefetch là 3289 token, với 4096 token đã được đăng ký là đang chiếm; tám request được client phát ra đồng thời, và GPU chạy tối đa một request tại một thời điểm.

• Nghiên cứu về song song hóa động và các điều kiện trạng thái, nghiên cứu về dispatch expert và mở rộng quy mô.

• Các phép tính di trú tuần tự qua 50 GbE, qua NIC 200 Gbit/s, và qua NVLink A100, cho một cận dưới thời gian di trú từ payload, băng thông liên kết và chín bước chuẩn bị tuần tự mỗi bước 1 giây. NVLink của A100 SXM cung cấp 600 GB/s gửi/nhận kết hợp, theo datasheet A100 80GB. Số byte KV và tốc độ gọi decode cho việc nhân bản nền được lấy từ derived_stage_rates của H20 trong phân bổ số nguyên P, D không đồng nhất.

• Dung lượng, kênh dùng chung, thời gian khởi động, mục tiêu xả và chi phí trong Ví dụ 9.8, cùng tỷ lệ đạt điều kiện cấp dịch vụ (SLO), đều là các giả định giáo khoa dùng để suy ra các điều kiện thay đổi thế nào. Chi phí đơn vị được tính bằng chi phí trọn giờ chia cho (3600 × tốc độ request hiệu dụng). Thời gian chuẩn bị tuần tự cho ví dụ di trú được đặt là 9 giây.

• Báo cáo kỹ thuật chính thức DeepSeek V4.1, các Mục 1, 2, 3 và 6; điều kiện cố định và tính lại cho phiên xuyên chương.

• Báo cáo kỹ thuật hệ thống inference DeepSeek-V3/R1, bao phủ EP quy mô lớn, ba loại cân bằng tải và độ chính xác giao tiếp; bản đọc nhanh DeepEP V2. Nguồn và ranh giới phiên bản.

• Đầu vào cố định cho độ lệch EP lớn và tách expert, script tính toán, kết quả tính lại. Băng thông NIC và NVLink từ datasheet HGX H100, spec NVIDIA H100 và datasheet ConnectX-7; tính toán H100 được lấy ở 50% đỉnh trong bảng phần cứng; các đầu ra được tính là cận dưới cho các mô hình thực thi được liệt kê, và các hệ số pipelining và flattening cho hai micro-batch trong Mục 9.4.3 được cho bởi cùng các kết quả.

• Đầu vào cố định cho quy mô EP và tải thẻ bận nhất, script tính toán, kết quả tính lại. Kịch bản điểm nóng dùng các phân số chính xác; kịch bản ngẫu nhiên dùng một seed ngẫu nhiên cố định; chỉ các số hàng hợp lệ được kiểm kê, loại trừ đệm, đọc trọng số và giao tiếp. Triển khai decode của DeepSeek với EP144, 32 expert dự phòng và 2 expert định tuyến mỗi thẻ được mô tả trong báo cáo kỹ thuật hệ thống inference DeepSeek-V3/R1.

• Zhu và cộng sự, MegaScale-Infer, arXiv:2504.02263v1, §6 về cân bằng tải, §7.1–7.2 về điều kiện thí nghiệm và thông lượng; CRAFT, MLSys 2026, tóm tắt, §3–5; Demystifying the Mixture of Experts Serving Tax, MLSys 2026, §3–5. Phạm vi tài liệu trích dẫn, phạm vi đọc và khả năng áp dụng của các con số được cho trong bản ghi nghiên cứu này.

Tóm tắt chương

Inference phân tán phân tán phép tính và trạng thái của một request đơn lẻ trên nhiều vị trí. PD, AF, việc đặt expert và KV dùng chung đều đòi hỏi cân nhắc lợi ích của việc thực thi cục bộ với phần bàn giao được thêm vào, và dung lượng, tốc độ dịch vụ, khởi động cùng khôi phục cùng nhau quyết định liệu một phương án triển khai có phù hợp hay không. Định tuyến không chỉ chọn các tài nguyên tính toán nhàn rỗi mà còn xác định trạng thái nào có thể được tái sử dụng. Cùng một suy dẫn cho các kết quả khác nhau với các biểu diễn context khác nhau: chuyển trạng thái bàn giao từ GQA sang MLA gọn giảm một nửa thời gian bàn giao PD, gấp đôi số hạng liên kết của $\mu_{PD}$, để nguyên bàn giao từng tầng của AF, và rút ngắn tương ứng thời gian khởi động tới hạn.

Sau một thay đổi phần cứng, trước tiên cố định request và phương án triển khai để xác định nút thắt mới, rồi phân bổ lại tài nguyên giữa các giai đoạn. Chương tiếp theo chuyển sang huấn luyện, bàn về việc cập nhật liên tục các tham số và trạng thái huấn luyện, và tiến trình huấn luyện tiến lên như thế nào.