Công NghệGrokking

Grokking: Kimi K3 dừng nhận thuê bao mới vì quá tải GPU, nhưng continuous batching giúp một GPU phục vụ hàng nghìn người dùng cùng lúc ra sao?

Moonshot dừng nhận thuê bao Kimi K3 mới vì GPU quá tải, dịp để hiểu kỹ thuật continuous batching và KV-cache, thứ quyết định một GPU phục vụ được bao nhiêu người dùng AI cùng lúc.

Minh Trí|
Grokking: Kimi K3 dừng nhận thuê bao mới vì quá tải GPU, nhưng continuous batching giúp một GPU phục vụ hàng nghìn người dùng cùng lúc ra sao?
Photo: panumas nikhomkhai — via Pexels • Nguồn ảnh

Ngày 19 tháng 7, Moonshot AI tuyên bố tạm ngừng nhận thuê bao mới cho Kimi K3, mô hình AI mã nguồn mở lớn nhất thế giới hiện nay với 2,8 nghìn tỷ tham số và cửa sổ ngữ cảnh 1 triệu token. Công ty thừa nhận thẳng thắn: lượng người dùng đổ về vượt xa dự đoán, và dàn GPU của họ cảm nhận rõ áp lực đó. Chỉ trong 48 giờ, nhu cầu đã áp sát giới hạn công suất, buộc Moonshot phải khóa cửa đăng ký mới để bảo vệ trải nghiệm cho những người đã trả tiền trước đó.

Vì sao một GPU không thể gánh vô hạn người dùng

Điểm mấu chốt cần hiểu là khi bạn hỏi Kimi K3 một câu, nó không chạy trên một luồng riêng cho bạn rồi biến mất. Mô hình phải nạp toàn bộ trọng số, có khi hàng trăm GB, vào bộ nhớ GPU trước, rồi mới tính toán từng token trả lời. Việc nạp trọng số này tốn kém đến mức nếu chỉ phục vụ một người mỗi lượt, phần lớn sức mạnh GPU sẽ nằm không trong lúc chờ đợi. Vì vậy các hệ thống công nghệ suy luận hiện đại phải nhồi nhiều người dùng vào cùng một đợt tính toán, gọi là batching.

Continuous batching: ghép khách đi chung xe theo thời gian thực

Batching kiểu cũ giống một chuyến xe buýt, xe chỉ chạy khi đủ khách, và ai lên sau phải đợi xe cũ chạy hết mới có chuyến mới. Vấn đề là mỗi câu trả lời của AI dài ngắn khác nhau, người hỏi một câu ngắn phải chờ người viết cả bài luận dài xong mới được xuống xe. Continuous batching, còn gọi là in-flight batching, giải quyết việc này bằng cách coi mỗi bước sinh một token là một đơn vị độc lập. Ngay khi một người dùng nào đó sinh xong token cuối và rời batch, chỗ trống lập tức được lấp bởi người dùng mới đang chờ, không cần đợi cả batch xong. Nhờ vậy GPU gần như không có khoảng trống rảnh rỗi, thông lượng tăng gấp nhiều lần so với cách cũ.

Cái giá phải trả: KV-cache ngốn bộ nhớ

Nhưng ghép nhiều người dùng cùng lúc không miễn phí. Mỗi cuộc hội thoại đang xử lý cần một vùng nhớ riêng gọi là KV-cache, lưu lại ngữ cảnh đã đọc để mô hình không phải tính lại từ đầu ở mỗi token mới. Với cửa sổ ngữ cảnh 1 triệu token như Kimi K3, KV-cache của một phiên có thể phình to đáng kể, trong khi VRAM lại hữu hạn. Số lượng người dùng đồng thời tối đa không còn bị giới hạn bởi tốc độ tính toán, mà bởi việc còn đủ chỗ chứa KV-cache trong bộ nhớ hay không. Đây chính xác là bức tường mà Moonshot đang đâm vào, mở rộng thuê bao đồng nghĩa phải mở rộng cả cụm GPU lẫn dung lượng nhớ, chứ không đơn giản chỉ là bật thêm máy chủ.

Vì sao khóa cửa lại là quyết định đúng

Nếu Moonshot cứ nhận thêm thuê bao trong lúc KV-cache đã cạn chỗ, hệ quả sẽ là độ trễ tăng vọt cho tất cả mọi người, kể cả khách hàng cũ. Việc tạm dừng rồi mở lại theo từng đợt, tách riêng gói Kimi Membership và Kimi Code Membership, thực chất là một hình thức lập kế hoạch công suất, kiểm soát tốc độ tăng trưởng để hạ tầng bắt kịp, thay vì để trải nghiệm người dùng sụp đổ hàng loạt.

Chia sẻ

Bình luận (0)

0/1000
Đang tải...

Tin cùng chuyên mục

Xem tất cả →
Grokking: Lỗi thực thi mã từ xa trong PHP nguy hiểm đến mức nào
Grokking

Lỗi thực thi mã từ xa trong PHP nguy hiểm đến mức nào

Hai lỗ hổng thực thi mã từ xa trong PHP đạt điểm CVSS 9,2 đã được vá khẩn cho bản 8.2–8.5. Palo Alto Networks ước tính hơn 22,6 triệu máy chủ có thể bị ảnh hưởng.

Dành cho bạn