Blog / AI / Deep Article
Giải thích KV cache, phân mảnh GPU và PagedAttention trong vLLM; phân biệt tối ưu thông lượng với tốc độ phản hồi và những giới hạn cần đo thực tế.
Bạn hỏi chatbot và nhận câu trả lời ngay. Nhưng khi nhiều người cùng hỏi, một chatbot có thể trả lời rất nhanh ở những lượt đầu nhưng trở nên đắt đỏ khi phải xử lý hàng nghìn cuộc hội thoại dài cùng lúc. Vấn đề là nút thắt không chỉ nằm ở số tham số của mô hình hay sức mạnh của GPU. Một phần quan trọng nằm ở vùng nhớ lưu thông tin trung gian của các token đã đi qua mô hình: KV cache. Khi quản lý vùng nhớ này thiếu hiệu quả, máy chủ có thể hết bộ nhớ trước khi dùng hết năng lực tính toán.
Nhiều mô hình ngôn ngữ sinh văn bản theo kiểu tự hồi quy: dự đoán token kế tiếp dựa trên chuỗi token đứng trước. Ở mỗi lớp attention, mô hình tạo ra các biểu diễn thường gọi là *query* (truy vấn), *key* (khóa) và *value* (giá trị). Query của vị trí hiện tại tương tác với key của những vị trí được phép nhìn tới; các trọng số attention sau đó được dùng để tổng hợp value.
Thực tế là nếu cứ mỗi lần sinh token mới lại tính lại toàn bộ key và value của các token cũ, máy chủ sẽ lặp lại nhiều phép tính. KV cache lưu những biểu diễn key/value đã có để tái sử dụng trong các bước sinh tiếp theo. Tài liệu Transformers của Hugging Face mô tả rõ mục đích này: tránh tính lại phần có thể dùng lại, qua đó cải thiện hiệu suất sinh.
Trong kiến trúc Transformer tự hồi quy thông thường dùng attention đầy đủ, lượng dữ liệu KV lưu trữ tăng theo số token đang được giữ, số lớp, số đầu key/value, kích thước mỗi đầu và số byte trên mỗi phần tử. Công thức ước lượng đơn giản là:
Bộ nhớ KV ≈ 2 × số lớp × số token × số đầu KV × kích thước mỗi đầu × số byte/phần tử.
Bài học là hệ số hai xuất phát từ việc phải lưu cả key lẫn value. Ví dụ giả định: 32 lớp, 8 đầu KV, kích thước đầu 128, 16.000 token và 2 byte mỗi phần tử sẽ cần khoảng 1,05 GB chỉ cho KV cache của một chuỗi, chưa tính trọng số mô hình, vùng nhớ tạm, overhead quản lý và các yêu cầu khác. Đây chỉ là phép tính minh họa nhé, không phải thông số đo của một chatbot cụ thể. Các kiến trúc dùng attention cửa sổ trượt hoặc nén/giảm số đầu KV có thể thay đổi đáng kể kết quả.
Vấn đề là một cách quản lý cũ là đặt trước vùng nhớ liên tục đủ lớn cho độ dài tối đa dự kiến của từng yêu cầu. Nếu người dùng dừng sớm, phần dự phòng có thể bị bỏ phí. Khi các vùng nhớ được cấp phát và thu hồi với kích thước khác nhau, hệ thống còn có nguy cơ phân mảnh: tổng dung lượng trống không phản ánh đầy đủ khả năng bố trí một khối liên tục mới.
Đây mới là ý tưởng của PagedAttention: chia KV cache thành các block có sức chứa cố định theo số token. Những block thuộc cùng một cuộc hội thoại không nhất thiết nằm sát nhau trong bộ nhớ vật lý. Một bảng ánh xạ giúp hệ thống biết block logic nào tương ứng với vị trí vật lý nào. Cách tổ chức này gợi nhớ bộ nhớ ảo và phân trang của hệ điều hành, nhưng được áp dụng cho dữ liệu attention.
Thay vì giữ sẵn một vùng lớn cho toàn bộ cuộc trò chuyện, máy chủ cấp thêm block khi cần. Các block cùng kích thước giúp tái sử dụng vùng nhớ thuận tiện hơn; phần lãng phí do block chưa đầy thường tập trung ở block cuối của mỗi chuỗi. Khi các nhánh sinh cùng dùng một tiền tố, hệ thống còn có thể chia sẻ các block phù hợp, thay vì nhân bản mọi dữ liệu ngay từ đầu.
Câu hỏi là: PagedAttention là cách tổ chức và truy cập KV cache, không phải thuật toán làm mô hình suy luận thông minh hơn. Nó cũng không tự động giảm số phép toán attention của mọi kiến trúc. Lợi ích lớn nhất nằm ở sử dụng bộ nhớ linh hoạt và phục vụ đồng thời nhiều yêu cầu.
Trong bài báo năm 2023, nhóm nghiên cứu báo cáo vLLM đạt thông lượng phục vụ cao hơn khoảng 2–4 lần so với các hệ thống đối chứng được thử nghiệm, ở mức độ trễ tương đương trong các cấu hình đánh giá của họ. Thực tế là thông lượng ở đây là lượng công việc hệ thống xử lý được trong một khoảng thời gian, không có nghĩa mọi người dùng sẽ thấy từng token xuất hiện nhanh gấp bốn lần.
Phân trang KV cache chủ yếu giảm lãng phí do cấp phát và hỗ trợ chia sẻ block. Lượng tử hóa KV cache lưu key/value bằng biểu diễn có độ chính xác thấp hơn để giảm số byte; đổi lại có thể phát sinh chi phí chuyển đổi và rủi ro sai số. Offloading chuyển một phần cache khỏi GPU sang CPU để tiết kiệm VRAM, nhưng có thể chịu thêm chi phí truyền dữ liệu và tăng độ trễ.
Tài liệu Hugging Face hiện phân biệt các chiến lược Dynamic, Static, Quantized và Offloaded Cache. Dynamic Cache mở rộng theo tiến trình sinh; Static Cache đặt trước dung lượng để thuận lợi cho một số tối ưu biên dịch; offloading và quantization hướng tới giảm áp lực bộ nhớ theo những cách khác nhau. Không có lựa chọn tối ưu tuyệt đối đâu nhé: phải cân bằng tốc độ, dung lượng, độ dài ngữ cảnh và cấu hình phần cứng.
Với một doanh nghiệp Việt Nam chạy chatbot chăm sóc khách hàng, câu hỏi thực tế là: chậm vì GPU, thiếu VRAM hay vì hàng đợi? Một lập trình viên ở Việt Nam nên đo thời gian đến token đầu tiên, tốc độ token tiếp theo, số phiên đồng thời và bộ nhớ. Đấy mới là cách biết tối ưu nào có ích, chứ không phải cứ thấy benchmark đẹp là áp dụng.
Ở Việt Nam, nhiều đội làm trợ lý tài liệu tiếng Việt có cả phiên ngắn lẫn phiên dài. Vấn đề là phân bố độ dài quyết định nhu cầu cache. Ứng dụng trên điện thoại ưu tiên phản hồi sớm, còn hệ thống xử lý báo cáo ban đêm ưu tiên thông lượng. Câu hỏi là nên tối ưu chỉ số nào trước? Bài học cho lập trình viên là thử trên tải thật nhé.
Với doanh nghiệp Việt Nam, hãy so sánh cùng mô hình, GPU và dữ liệu tiếng Việt trong vài ngày. Đừng biến một benchmark thành cam kết tiết kiệm chi phí. Thực tế là tối ưu KV cache không sửa được câu trả lời bịa. Ứng dụng ở Việt Nam vẫn cần kiểm chứng chất lượng độc lập, đấy.
Câu hỏi là khi thay GPU, mô hình hoặc độ dài prompt thì kết quả còn giữ không? Bài báo không bảo đảm mọi hệ thống ở Việt Nam đều tăng thông lượng như nhau. Một lập trình viên cần thử trên dữ liệu thực tại Việt Nam, theo dõi độ trễ, lỗi hết bộ nhớ và chi phí mỗi yêu cầu. Kỹ thuật này không sửa lỗi bịa nguồn đâu nhé. Bài học cho đội AI ở Việt Nam là đo trước khi kết luận, chứ.
Kết luận: KV cache giúp mô hình tránh tính lại các biểu diễn cũ; PagedAttention giúp tổ chức vùng nhớ đó linh hoạt hơn khi phục vụ nhiều yêu cầu. Đây là ví dụ điển hình cho thấy hiệu năng AI không chỉ phụ thuộc mô hình lớn đến đâu, mà còn phụ thuộc cách phần mềm quản lý từng byte bộ nhớ.