Chuyển giao bộ nhớ cho CPU: Bí quyết giúp mô hình AI tăng tốc độ xử lý

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400">

16-09-2026 11:07:18 Nguồn: QbitAI

Để GPU bận rộn với việc tạo Token

Kim Lỗi (Jin Lei) đưa tin từ Aofeisi

QbitAI | Kênh chính thức QbitAI

Việc sử dụng Agent để lập trình (Coding) chắc hẳn đã không còn xa lạ với mọi người.

Tuy nhiên, nếu chúng ta chuyển tầm nhìn từ cửa sổ trò chuyện sang các trung tâm dữ liệu phía sau, mọi chuyện sẽ không còn đơn giản như vậy.

Một Coding Agent sửa lỗi (bug) xuyên suốt hơn chục tệp tin cần phải đọc mã nguồn, tra cứu tài liệu và chạy thử nghiệm nhiều lần. Những lượt tương tác đầu tiên có thể diễn ra suôn sẻ, nhưng khi nhiệm vụ tiếp tục chạy, lượng thông tin lịch sử mà hệ thống cần xử lý sẽ ngày càng tích tụ nhiều hơn.

Khi hàng ngàn Agent cùng làm việc theo cách này, các đơn vị vận hành có thể gặp phải một vấn đề đau đầu: máy chủ vẫn đang chạy, nhưng khả năng đáp ứng đồng thời (concurrency) ngày càng trở nên eo hẹp, khiến một số yêu cầu phải chờ đợi rất lâu mới có thể xuất ra Token đầu tiên.

Chẳng lẽ chỉ còn cách tiếp tục bổ sung thêm GPU?

Không hề, không hề.

Mô hình vẫn là mô hình đó, máy chủ vẫn là máy chủ đó, gốc rễ của vấn đề thực chất nằm ở bộ nhớ.

Bởi vì mỗi khi mô hình ngôn ngữ lớn (LLM) tạo ra một Token mới, nó vẫn cần tiếp tục sử dụng thông tin từ ngữ cảnh trước đó. Để không phải tính toán lại từ đầu mỗi lần, hệ thống sẽ lưu trữ các kết quả trung gian đã tính toán trước đó; cuộc hội thoại càng dài, "bộ nhớ" này tự nhiên càng chồng chất.

Một khi bộ nhớ đồ họa (VRAM) không còn đủ chứa, một phần bộ nhớ đệm (cache) sẽ bị xóa đi. Khi Agent cần đến những thông tin lịch sử này ở lượt tiếp theo, nó có thể phải thực hiện lại quá trình Prefill. Những gì vốn đã được tính toán trước đó lại phải tốn thời gian GPU để tính lại một lần nữa.

Đặc biệt là trong kỷ nguyên Agent, AI hiếm khi chỉ thực hiện các tác vụ hỏi-đáp đơn thuần, mà thay vào đó là các nhiệm vụ đòi hỏi sự suy ngẫm, lập kế hoạch và hành động lặp đi lặp lại. Trong quá trình này, nó sẽ liên tục tích lũy lịch sử hội thoại, bằng chứng truy xuất, kết quả từ công cụ và các trạng thái trung gian, v.v.

Thế là, một thứ vốn ẩn sâu bên trong quá trình suy luận của mô hình lớn và người dùng phổ thông gần như không thể cảm nhận được, đã bị đẩy ra ánh sáng – đó chính là KV Cache.

Đặc điểm của nó chỉ gói gọn trong một từ: Lớn. Nhưng các đơn vị vận hành không thể vì tiết kiệm không gian mà để mặc những nội dung đã tính toán chiếm dụng GPU và phải tính lại nhiều lần. Vì vậy, bài toán suy luận với ngữ cảnh dài không chỉ dừng lại ở sức mạnh tính toán mà còn mở rộng sang lưu trữ, di chuyển và tái sử dụng dữ liệu.

Và chìa khóa để giải quyết vấn đề này không phải là GPU như bạn nghĩ, mà là – CPU.

Tại sao bộ nhớ của AI lại ngày càng đắt đỏ?

Trước hết, hãy làm rõ về KV Cache.

Đối với các mô hình Transformer sử dụng cơ chế tự chú ý nhân quả (causal self-attention), các Token đã xử lý trước đó sẽ để lại các Key và Value tương ứng trong lớp chú ý. Khi mô hình tạo các Token tiếp theo, nó có thể tiếp tục sử dụng các kết quả này. Hệ thống suy luận lưu trữ chúng lại, và đó chính là KV Cache.

Bạn có thể hiểu nó như những ghi chú mà mô hình thực hiện khi "đọc sách". Sau này, khi gặp những đoạn cần liên kết với ngữ cảnh phía trên, mô hình có thể truy xuất ghi chú để tiết kiệm việc tính toán lặp lại cho các Token đã có.

Vì vậy, "bộ nhớ" mà chúng ta đang nói đến ở đây chính là các trạng thái trung gian để lại trong quá trình suy luận, trọng số của mô hình không hề thay đổi vì điều này.

Những ghi chú này thực sự giúp tiết kiệm tính toán, nhưng chúng cũng chiếm dụng không gian lưu trữ đáng kể. Hơn nữa, Agent càng đọc nhiều, các ghi chú mà máy chủ cần lưu giữ cho nó thường càng dày thêm.

Vậy sự tăng trưởng này rõ rệt đến mức nào?

Hãy thử làm một phép tính với Qwen3-8B. Theo cấu hình mô hình công khai, trong điều kiện KV Cache sử dụng định dạng BF16 hoặc FP16 (mỗi giá trị chiếm 2 byte), dữ liệu KV tương ứng với mỗi Token là 147.456 byte, tức khoảng 147KB. Con số này chưa bao gồm các chi phí quản lý bộ nhớ đệm bổ sung.

Tại sao một Token lại kéo theo một bộ nhớ đệm lớn như vậy? Bởi vì hệ thống không lưu trữ văn bản của chính Token đó, mà lưu trữ Key và Value tương ứng của nó trong các lớp tính toán chú ý đa tầng. Theo cấu trúc của mô hình này, công thức tính là: 2 phần K/V × 36 lớp × 8 đầu KV (KV heads) × 128 chiều mỗi đầu × 2 byte.

Tiếp theo, chúng ta chỉ mượn chi phí mỗi Token này để suy diễn dung lượng cho ngữ cảnh 1 triệu Token: nếu cần lưu trữ 1 triệu Token, dữ liệu KV tương ứng sẽ là khoảng 147GB. Lưu ý rằng, 1M ở đây chỉ là giả định tính toán, không đại diện cho khả năng hỗ trợ thực tế của Qwen3-8B; thông số chính thức của nó là 32.768 Token gốc và có thể mở rộng lên 131.072 Token bằng YaRN.

Với một yêu cầu đơn lẻ đã như vậy, nếu chúng ta mở rộng quy mô yêu cầu thì sao? Giả sử một dịch vụ có 3 triệu người dùng hoạt động hàng ngày (DAU), mỗi người gửi 10 yêu cầu mỗi ngày và mỗi yêu cầu đều được tính theo ngữ cảnh 1M như trên, thì một ngày sẽ có 30 triệu yêu cầu.

Chưa tính đến nén và chia sẻ tái sử dụng, nếu cộng dồn toàn bộ khoảng 147GB cho mỗi yêu cầu, quy mô dữ liệu KV tích lũy hàng ngày sẽ là: 3 triệu × 10 × 147GB ≈ 4410PB. Nếu DAU tăng lên 300 triệu, với cùng giả định đó, con số này sẽ tăng gấp 100 lần, đạt khoảng 441.000PB, tức 441EB.

Tuy nhiên, cần phân biệt hai việc: tổng dữ liệu KV liên quan đến các yêu cầu trong một ngày và lượng dữ liệu KV mà trung tâm dữ liệu cần lưu trữ cùng lúc là hai khái niệm khác nhau. Phép tính trên là suy diễn quy mô dựa trên việc đếm toàn bộ và độc lập cho mỗi yêu cầu, không thể trực tiếp coi là danh mục mua sắm thiết bị lưu trữ.

Để biết cần trang bị bộ nhớ đệm lớn bao nhiêu, đơn vị vận hành còn phải xem xét có bao nhiêu yêu cầu chạy đồng thời vào giờ cao điểm, bộ nhớ đệm cần lưu giữ bao lâu, những tiền tố (prefix) nào có thể chia sẻ, cũng như các chiến lược nén và loại bỏ dữ liệu. Một phần bộ nhớ đệm đã được tái sử dụng không nên bị tính dung lượng trùng lặp chỉ vì nó được yêu cầu nhiều lần.

Tất nhiên, "sổ tay" của các mô hình khác nhau cũng khác nhau. Số lớp mô hình, số lượng đầu KV, độ chính xác của bộ nhớ đệm, v.v. đều ảnh hưởng đến kích thước, không thể chỉ nhìn vào số lượng tham số. Những con số trên không phải là mức sử dụng thực tế của một dịch vụ cụ thể, nhưng chúng cho thấy lý do tại sao các đơn vị vận hành cần đặc biệt chú ý đến "bộ nhớ" này: độ dài ngữ cảnh và quy mô yêu cầu sẽ cùng nhau làm cho bài toán bộ nhớ đệm ngày càng lớn hơn.

Trong khi đó, VRAM của GPU còn phải chứa trọng số mô hình và các dữ liệu khác trong quá trình vận hành. Khi mọi thứ cùng chia sẻ không gian này, KV Cache càng chiếm nhiều, hệ thống càng có ít dư địa cho các yêu cầu khác.

Lúc này, hệ thống suy luận buộc phải đưa ra lựa chọn: giảm số lượng yêu cầu xử lý đồng thời, chuyển một phần bộ nhớ đệm sang các tầng lưu trữ khác, hoặc xóa bỏ bộ nhớ đệm tạm thời không sử dụng.

Quay lại ví dụ về Coding Agent ở trên. Nó có thể đang chờ công cụ chạy thử nghiệm, hệ thống tận dụng khoảng thời gian này để xóa một phần bộ nhớ đệm lịch sử của nó. Khi kết quả thử nghiệm trả về, Agent chuẩn bị tiếp tục làm việc thì phát hiện bộ nhớ đệm cần dùng đã không còn nữa.

Nếu các tầng lưu trữ khác cũng không lưu dữ liệu này, mô hình sẽ phải xử lý lại các đầu vào lịch sử tương ứng và xây dựng lại bộ nhớ đệm. Giai đoạn xử lý đầu vào này được gọi là Prefill, đầu vào càng dài thì thường càng tốn thời gian. Thời gian chờ đợi Token đầu tiên của người dùng, tức TTFT, có thể theo đó mà tăng lên.

Nội dung đã tính toán xong, một lát sau lại phải tính lại. Đối với đơn vị vận hành, thứ tiêu tốn không chỉ là điện năng và thời gian, mà còn là cơ hội mà số GPU này lẽ ra có thể dùng để xử lý các nhiệm vụ mới và tạo ra các Token mới.