Mở rộng Quy mô và Triển khai¶

Phục vụ các mô hình lớn cho hàng triệu người dùng đòi hỏi phân tán suy luận qua nhiều GPU, dự đoán các token trước khi chúng được cần, cache ngữ cảnh chia sẻ, và chọn framework đúng. File này bao quát song song hóa khi suy luận, giải mã suy đoán (speculative decoding), cache tiền tố, các framework suy luận, tối ưu hóa chi phí và giám sát.

Một GPU H100 đơn phục vụ mô hình 70B có thể xử lý ~100 người dùng đồng thời ở độ trễ tương tác. Phục vụ 10 triệu người dùng đòi hỏi 100,000 GPU — tốn ~$3 tỷ mỗi năm cho tính toán cloud. Mỗi phần trăm hiệu quả được cải thiện tiết kiệm hàng chục triệu đô la. Đây là lý do tối ưu hóa suy luận không phải là lý thuyết: nó trực tiếp quyết định kinh tế của các sản phẩm AI.

Song song hóa Mô hình khi Suy luận¶

Khi một mô hình quá lớn cho một GPU đơn, nó phải được chia trên nhiều GPU. Các chiến lược song song hóa từ lúc huấn luyện (chương 6) áp dụng khi suy luận với các sự đánh đổi khác nhau.

Song song hóa Tensor (Tensor Parallelism)¶

Song song hóa tensor (kiểu Megatron, chương 6) chia các ma trận trọng số riêng lẻ trên các GPU. Với một lớp tuyến tính $Y = XW$, ma trận trọng số $W$ được chia theo cột trên $N$ GPU. Mỗi GPU tính một phần kết quả, sau đó một phép all-reduce tổng hợp:

\[W = [W_1 | W_2 | \cdots | W_N], \quad Y_i = X W_i, \quad Y = \text{concat}(Y_1, \ldots, Y_N)\]

Khi suy luận, song song hóa tensor là mặc định cho các mô hình không vừa một GPU. Một mô hình 70B ở FP16 cần 140 GB — chia trên 2 × GPU 80 GB với song song hóa tensor.
Tác động độ trễ: song song hóa tensor thêm một bước giao tiếp all-reduce mỗi lớp. Trên NVLink (900 GB/s), nó thêm ~0.1 ms mỗi lớp. Trên PCIe (32 GB/s), nó thêm ~3 ms mỗi lớp. Với mô hình 70B 80 lớp trên 2 GPU: NVLink thêm ~8 ms tổng cộng, PCIe thêm ~240 ms. Đây là lý do NVLink lại quan trọng đến thế cho suy luận đa GPU.

Song song hóa Pipeline (Pipeline Parallelism)¶

Song song hóa pipeline gán các lớp khác nhau cho các GPU khác nhau. GPU 1 xử lý các lớp 0-39, GPU 2 xử lý các lớp 40-79. Các token chảy qua pipeline theo thứ tự.
Khi suy luận, song song hóa pipeline có độ trễ cao hơn song song hóa tensor (toàn bộ pipeline phải được đi qua cho mỗi token) nhưng chi phí giao tiếp thấp hơn (chỉ có activation được truyền giữa các GPU, không có all-reduce). Nó được ưu tiên khi các GPU được nối bởi các kết nối chậm (các node khác nhau, không có NVLink).

Song song hóa Chuỗi (Sequence Parallelism)¶

Với các chuỗi rất dài, chính cache KV có thể không vừa một GPU ngay cả khi mô hình thì vừa. Song song hóa chuỗi chia cache KV trên các GPU: mỗi GPU lưu một phần của chuỗi các key và value đã cache.
Trong lúc attention, mỗi GPU tính các điểm attention cục bộ trên phân đoạn đã cache của nó, sau đó một phép tổng hợp (reduction) kết hợp kết quả. Được dùng trong suy luận ngữ cảnh dài (128K+ token) nơi cache KV vượt quá bộ nhớ của một GPU đơn.

Giải mã Suy đoán (Speculative Decoding)¶

Giải mã suy đoán là một trong những tối ưu hóa suy luận LLM có tác động lớn nhất. Ý tưởng: decode chậm vì nó sinh một token mỗi lần, với mỗi token đòi hỏi một lượt lan truyền thuận (forward pass) đầy đủ của mô hình lớn. Nhưng một mô hình nhỏ có thể sinh các token dự phòng nhanh hơn nhiều, và mô hình lớn có thể xác minh nhiều token dự phòng song song.

Speculative decoding: a fast draft model generates 5 candidate tokens, the target model verifies all in one pass, accepted tokens are kept and rejected ones resampled

Thuật toán:
1. Một mô hình nháp (draft model, nhỏ, nhanh — ví dụ 1B tham số) sinh $k$ token dự phòng theo phương thức tự hồi quy.
2. Mô hình đích (target model, lớn, chính xác — ví dụ 70B) chạy một lượt lan truyền thuận duy nhất trên toàn bộ chuỗi nháp, tính xác suất của mỗi token dự phòng.
3. Mỗi token dự phòng được chấp nhận nếu mô hình đích đồng ý (xác suất của nó cho token đó đủ cao). Các token bị từ chối được lấy mẫu lại từ phân bố của mô hình đích.
4. Trung bình, nhiều token được chấp nhận mỗi bước xác minh, cho tốc độ tăng tỷ lệ thuận với tỷ lệ chấp nhận.

\[\text{Speedup} \approx \frac{k \times \text{acceptance\_rate}}{\text{cost\_ratio}} \approx 2\text{-}3\times\]

Tại sao nó hoạt động không mất chất lượng: lược đồ lấy mẫu lại (rejection sampling) đảm bảo phân bố output khớp chính xác với mô hình đích. Giải mã suy đoán là không mất mát (lossless) — output thống kê giống hệt như chạy mô hình đích một mình, chỉ nhanh hơn.
Các biến thể:
- Medusa (Cai et al., 2024): thay vì một mô hình nháp riêng biệt, thêm nhiều "đầu" (heads) nhẹ vào mô hình đích dự đoán nhiều token tương lai đồng thời. Không cần mô hình riêng.
- EAGLE (Li et al., 2024): huấn luyện một đầu nháp nhẹ dùng các trạng thái ẩn (hidden states) của mô hình đích để dự đoán các token tương lai. Tỷ lệ chấp nhận cao hơn mô hình nháp độc lập.
- Tự giải mã suy đoán (self-speculative decoding): chính mô hình đích sinh các nháp bằng cách thoát sớm (chỉ chạy vài lớp đầu cho nháp, sau đó xác minh bằng mô hình đầy đủ).
- Giải mã song song (parallel decoding): sinh nhiều phần tiếp nối song song (cây các token dự phòng) và xác minh toàn bộ cây cùng lúc. Thông lượng cao hơn nhưng dùng nhiều bộ nhớ hơn cho các cache KV phân nhánh.

Cache Tiền tố (Prefix Caching)¶

Nhiều yêu cầu chia sẻ các tiền tố chung: system prompt, các ví dụ few-shot, hoặc các mẫu truy vấn phổ biến. Cache tiền tố lưu cache KV cho các tiền tố này và tái sử dụng nó qua các yêu cầu.
Cache system prompt: nếu mọi yêu cầu bắt đầu bằng cùng một system prompt 2000 token, cache KV cho 2000 token đó được tính một lần và chia sẻ qua tất cả các yêu cầu. Với mô hình 70B 80 lớp, điều này tiết kiệm ~200 MB mỗi yêu cầu.
Cache cây cơ số (Radix tree caching) (SGLang): tổ chức các tiền tố đã cache trong một cây cơ số (radix tree/trie). Khi một yêu cầu mới đến, tìm khớp tiền tố dài nhất đã cache và bắt đầu sinh từ đó, bỏ qua tính toán của tiền tố khớp.
Tác động: với các ứng dụng có tiền tố chia sẻ dài (chatbot có system prompt, RAG có các đoạn truy xuất chung), cache tiền tố giảm TTFT 50-90% và tiết kiệm lượng tính toán GPU tương ứng.

Loại bỏ Cache KV (KV-Cache Eviction)¶

Ngoài việc lượng tử hóa cache KV (file 01) và dùng GQA/MLA để giảm kích thước của nó (file 02), các chính sách loại bỏ cache KV (KV-cache eviction) chọn lọc loại bỏ các token đã cache ít có khả năng được attend trong tương lai.
H2O (Heavy-Hitter Oracle, Zhang et al., 2023) quan sát thấy điểm attention tuân theo luật lũy thừa (power law): một phần nhỏ các token ("heavy hitters") nhận phần lớn sự chú ý, trong khi đa số nhận sự chú ý không đáng kể. H2O giữ:
1. Các token gần đây (một cửa sổ cuộn của $w$ token cuối, như StreamingLLM).
2. Các token heavy-hitter (top-$k$ token theo điểm attention tích lũy qua tất cả các bước decode trước).
Các token không gần đây cũng không phải heavy-hitter sẽ bị loại bỏ. Điều này duy trì một cache KV có kích thước cố định trong khi vẫn giữ các token thực sự ảnh hưởng đến việc sinh. H2O đạt chất lượng gần với cache KV đầy đủ với chỉ 20% bộ nhớ.
Scissorhands (Liu et al., 2023) dùng cách tiếp cận tương tự nhưng với một thước đo tầm quan trọng tinh vi hơn: các token nhận sự chú ý cao ở bước hiện tại được giữ, trong khi các token không được attend trong $T$ bước sẽ bị loại bỏ. Điều này thích nghi với các mẫu attention thay đổi trong quá trình sinh.
Loại bỏ động + StreamingLLM: kết hợp các bồn attention (giữ vài token đầu vĩnh viễn) với loại bỏ động (giữ các token gần đây + heavy-hitter). Đây là cách tiếp cận tiết kiệm bộ nhớ nhất cho việc sinh rất dài, cho phép sinh độ dài vô hạn với sự suy giảm chất lượng có giới hạn.
Ý tưởng then chốt qua tất cả các phương pháp loại bỏ: attention của LLM thưa trong thực tế — mặc dù kiến trúc tính attention trên tất cả các token đã cache, nhưng các trọng số attention thực tế tập trung vào một tập hợp con nhỏ. Loại bỏ phần còn lại có tác động tối thiểu đến chất lượng output.