Phương pháp dự đoán tốc độ xử lý token của từng người dùng trên GPU dùng chung

Góc nhìn kỹ thuật. Đây là tình trạng hoạch định dung lượng theo số lượng yêu cầu (request) trên một đường truyền vốn bị giới hạn bởi dung lượng byte. Máy chủ mô hình đọc trọng số một lần cho mỗi bước xử lý (step) đối với toàn bộ người dùng. Hệ thống đồng thời đọc lại toàn bộ nội dung hội thoại được lưu trữ của từng người dùng trong mỗi bước. Một vài phiên làm việc kéo dài của tác tử (agent) sẽ làm cạn kiệt băng thông đọc này, khiến tốc độ phản hồi của mọi phiên trò chuyện trên GPU đều bị chậm lại. Tóm tắt ngắn gọn. Mọi người dùng trên một GPU đều phải chờ đợi cùng một bước xử lý chung, và bước xử lý này sẽ kéo dài tương ứng với tổng dung lượng hội thoại của tất cả người dùng. Cần hoạch định dung lượng dựa trên số lượng token đang xử lý (tokens in flight), thay vì dựa trên số lượng người dùng. Giải thích đơn giản Hình ảnh một thủ thư trả lời thư của mọi người, từng từ một. Trong mỗi lượt, thủ thư đọc lại cuốn sách quy tắc lớn một lần. Quá trình này mất cùng một khoảng thời gian, dù có năm hay năm mươi người đang chờ đợi. Sau đó, người này đọc lại toàn bộ nội dung thư đã trao đổi của từng người để xác định từ tiếp theo. Những bức thư ngắn được xử lý rất nhanh. Tuy nhiên, chỉ cần một người có bức thư dài một trăm trang, toàn bộ lượt xử lý sẽ bị chậm lại đối với tất cả mọi người. Do đó, yếu tố làm chậm tốc độ không phải là số lượng người chờ đợi, mà chính là tổng số trang phải đọc lại. Vấn đề phát sinh Lỗi kỹ thuật này từng xuất hiện trước đây ngay cả trong các hệ thống không sử dụng mô hình trí tuệ nhân tạo. Hệ thống cổng API (API gateway) từng được ước tính quy mô theo số lượng yêu cầu mỗi giây. Quá trình kiểm thử tải chỉ gửi các gói dữ liệu (payload) nhỏ và đã vượt qua với dung lượng dự phòng lớn. Tuy nhiên, khi một khách hàng bắt đầu tải lên các tệp tin có dung lượng lớn, số lượng yêu cầu hầu như không thay đổi nhưng đường truyền mạng đã bị lấp đầy. Toàn bộ các yêu cầu đều bị chậm lại, kể cả những yêu cầu có kích thước rất nhỏ. Biện pháp xử lý khi đó là đo lường theo lưu lượng byte thay vì số lượng yêu cầu. Máy chủ mô hình AI cũng gặp phải lỗi tương tự. Giả định quá trình kiểm thử tải mô hình Qwen3 8B trên một GPU H100 với 40 người dùng trò chuyện đồng thời. Mỗi phiên trò chuyện chứa khoảng 2.000 token, và mỗi người dùng đạt tốc độ xử lý khoảng 71 token mỗi giây. Kết quả này đạt yêu cầu. Sau đó, đội ngũ kỹ thuật triển khai tính năng tác tử (agent). Các phiên làm việc này chứa tới 100.000 token bao gồm mã lệnh và dữ liệu đầu ra từ công cụ. Chỉ cần hai phiên tác tử tham gia cùng 40 phiên trò chuyện sẵn có, bảng điều khiển (dashboard) ghi nhận 42 yêu cầu đang chạy, chỉ tăng thêm hai yêu cầu so với thử nghiệm. Tuy nhiên, tốc độ truyền tải của mỗi người dùng giảm xuống còn khoảng 35 token mỗi giây. Hệ thống không gặp sự cố dừng hoạt động và bộ nhớ GPU vẫn còn dung lượng trống. GPU không hề cạn kiệt bộ nhớ. Thiết bị này đã cạn kiệt lưu lượng đọc trong mỗi bước xử lý. Kế hoạch dung lượng đã tính toán theo số lượng người dùng, trong khi chi phí thực tế lại tính bằng token. Giải pháp khắc phục: hoạch định dung lượng dựa trên tổng số token đang xử lý của toàn bộ người dùng, đồng thời tiếp nhận từng yêu cầu dựa trên giới hạn tốc độ thay vì giới hạn bộ nhớ. Giải pháp: Phân bổ định mức theo số token đang xử lý, không theo số lượng người dùng Vì sao việc bổ sung thêm một người dùng gần như không tốn thêm tài nguyên? Máy chủ tạo câu trả lời qua từng bước giải mã (decode step). Mỗi bước tạo ra đồng thời một token cho mọi yêu cầu đang hoạt động. Để tạo ra token đó, GPU phải đọc toàn bộ trọng số của mô hình từ bộ nhớ. Đối với mô hình Qwen3 8B ở định dạng 16-bit, dung lượng này là 16,4 GB. Tốc độ đọc, tức băng thông bộ nhớ, sẽ quyết định giới hạn tốc độ của quá trình này. Một bộ xử lý H100 đạt tốc độ đọc tối đa là 3,35 TB mỗi giây, trong khi quá trình giải mã thực tế đạt khoảng 60% mức đó. Như vậy, một bước xử lý mất khoảng 8 mili giây, và một người dùng đơn lẻ sẽ nhận được khoảng 120 token mỗi giây. Các trọng số chỉ được đọc một lần trong mỗi bước cho toàn bộ nhóm xử lý (batch), do đó một người dùng mới không làm phát sinh thêm lượt đọc thứ hai. Đây là lý do việc xử lý theo nhóm (batching) dường như không tiêu tốn tài nguyên bổ sung. Chi phí thực tế của mỗi người dùng gồm những gì? Mỗi yêu cầu đều duy trì một bộ nhớ đệm KV (KV cache), nơi lưu trữ các giá trị khóa và giá trị (keys và values) cho mọi token đã xuất hiện trước đó. Mô hình phải đọc lại toàn bộ dữ liệu này ở mỗi bước để xác định token tiếp theo. Đối với mô hình Qwen3 8B, con số này là 144 KiB cho mỗi token. Một phiên trò chuyện 2.000 token chiếm dung lượng 0,29 GB. Trong khi đó, một phiên làm việc của tác tử có độ dài 100.000 token chiếm tới 14,7 GB, gần tương đương kích thước của chính mô hình. Liệu bộ nhớ có bị cạn kiệt trước tiên? Với 90% dung lượng của một card 80 GB, bộ nhớ đệm (cache) có thể lưu giữ khoảng 377.000 token. Để bảo đảm mỗi người dùng đạt tốc độ 50 token/giây, mỗi bước xử lý (step) phải duy trì dưới mức 20 mili-giây. Mức này chỉ cho phép xử lý đồng thời khoảng 134.000 token trong quá trình truyền tải (in flight). Máy chủ vẫn tiếp nhận tác vụ và truyền dữ liệu (stream) ở tốc độ chậm. Phương pháp tính toán dung lượng bộ nhớ được trình bày trong tài liệu "How to Work Out How Much GPU Memory One Request Really Needs". Tác động khi có câu lệnh (prompt) mới Việc đọc một prompt mới, hay còn gọi là giai đoạn nạp trước (prefill), là tác vụ đòi hỏi năng lực tính toán. Máy chủ chia tách một phần tác vụ này và xử lý kết hợp trong các bước chung. Khi đó, thời gian của một bước sẽ kéo dài tương đương tác vụ chậm hơn trong hai tác vụ trên. Với khối lượng 2.048 token trong mỗi bước, tốc độ của 40 phiên trò chuyện sẽ giảm xuống còn khoảng 15 token/giây cho đến khi prompt được nạp hoàn tất. Tính xác thực của mô hình tính toán Số liệu này đã được đối chiếu với kết quả công bố thực tế nhằm kiểm chứng độ tin cậy. MosaicML đã thực hiện đo lường mô hình MPT-7B trên một GPU A100 với kích thước lô (batch size) từ 1 đến 64. Nếu chỉ tính dung lượng trọng số mô hình, thông lượng thực tế bị phóng đại lên gấp 4,7 lần. Khi tính toán bổ sung bộ nhớ đệm và khối lượng xử lý prompt, mức sai lệch chỉ còn trong khoảng 6%. Ý nghĩa thực tiễn Trường hợp phát sinh ảnh hưởng: Tình trạng này xuất hiện khi đơn vị tự vận hành máy chủ mô hình như vLLM, SGLang, TGI hoặc thuê hạ tầng điện toán chuyên dụng; đặc biệt rõ rệt khi các yêu cầu dài và ngắn cùng chia sẻ chung một GPU. Các phiên làm việc của tác tử (agent), rà soát mã nguồn trên toàn bộ kho lưu trữ (repository) và hội thoại với các tài liệu dài là những tác vụ dài. Trường hợp chỉ sử dụng API lưu trữ sẵn (hosted API), nhà cung cấp dịch vụ sẽ chịu trách nhiệm định cỡ dung lượng này. Kết quả thể hiện qua tốc độ trả token biến động tùy theo thời điểm trong ngày. Mức độ tác động: Các bài kiểm tra tải thường chỉ áp dụng một độ dài prompt cố định. Thử nghiệm với 40 phiên trò chuyện ngắn không thể phản ánh chính xác hiệu năng khi có thêm hai phiên làm việc của tác tử. Bảng điều khiển bộ nhớ vẫn hiển thị còn dung lượng khả dụng trong khi người dùng phản ánh tốc độ truyền tải bị chậm. Việc mở rộng thêm người dùng gửi các prompt ngắn có chi phí thấp, nhưng bổ sung thêm một phiên làm việc dài lại đòi hỏi tài nguyên rất lớn. Biện pháp xử lý: Trước hết, đối với hệ thống chưa thiết lập nâng cao: nhân độ dài ngữ cảnh phổ biến dài nhất với 144 KiB, hoặc theo chỉ số trên mỗi token của mô hình đang vận hành. Đối chiếu con số này với kích thước mô hình. Nếu bộ nhớ đệm của một phiên tương đương kích thước mô hình, chi phí cho phiên đó sẽ tương đương với toàn bộ các phiên còn lại gộp lại. Tiếp theo, tiến hành đo lường một chỉ số duy nhất trên máy chủ: số token/giây của một người dùng độc lập. Từ chỉ số này, có thể xác định băng thông hiệu dụng, qua đó thiết lập định mức token dựa trên mục tiêu tốc độ đề ra. Sau đó, áp dụng cơ chế tiếp nhận yêu cầu theo định mức tại cổng dịch vụ (gateway). Thực hiện phân luồng các phiên dài sang một cụm xử lý (pool) riêng biệt khi các phiên này có nguy cơ kéo hiệu năng của các phiên ngắn xuống dưới mức mục tiêu. Mã nguồn chi tiết được cung cấp tại mục ## Triển khai thực tế. Để tìm hiểu thêm về bộ nhớ đệm KV (KV cache), có thể tham khảo tài liệu "How Agent Context Gets Re-Read Every Turn". Triển khai thực tế Quy trình điều chỉnh. Ba khâu cần thay đổi gồm: bộ phận hoạch định dung lượng, cổng dịch vụ phía trước máy chủ, và bảng điều khiển giám sát. Khâu 1: Hoạch định dung lượng. Cần căn cứ trên cấu hình thực tế của mô hình, không dựa vào ước tính. Dung lượng bộ nhớ đệm trên mỗi token được tính bằng 2 (keys và values), nhân số lớp (layers), nhân số đầu key-value (key-value heads), nhân kích thước đầu (head size), nhân số byte trên mỗi đơn vị số: KV_TOK = 2 * 36 * 8 * 128 * 2 # Qwen3 8B: 147.456 byte trên mỗi token WEIGHT_BYTES = 8.2e9 * 2 def mea