Công thức của Cloudflare để phục vụ Kimi và GLM: lượng tử hóa bộ nhớ đệm KV, nén trọng số, xác minh bộ nhớ đệm

Chạy các mô hình hỗn hợp chuyên gia lớn như Kimi K-series của Moonshot và GLM của Z.ai trên hạ tầng GPU dùng chung là bài toán bộ nhớ trước khi là bài toán tốc độ. Đội ngũ Workers AI của Cloudflare đã giải quyết vấn đề đó bằng ba kỹ thuật xếp lớp trên thiết lập prefill/decode phân tách hiện có: lượng tử hóa bộ nhớ đệm KV, nén trọng số mô hình, và thêm kiểm tra an toàn cho bộ nhớ đệm dùng chung mà các tối ưu hóa này cho phép.

Bộ nhớ đệm KV FP8 tăng gấp đôi dung lượng ngữ cảnh

Bộ nhớ đệm KV—cấu trúc lưu trữ khóa và giá trị chú ý cho mỗi token đã xử lý—thường là thứ đầu tiên lấp đầy bộ nhớ GPU, không phải trọng số. Cloudflare lưu trữ nó ở dạng dấu phẩy động 8-bit (FP8, e4m3) thay vì mặc định 16-bit (BF16), giảm một nửa kích thước. Với Kimi K2.6, điều đó nâng ngữ cảnh có thể chứa trong bộ nhớ từ khoảng 686.000 token lên khoảng 1,37 triệu.

Lượng tử hóa bộ nhớ đệm không phải là thắng lợi về tốc độ thô—kernel chú ý FP8 thực hiện thêm một chút công việc chuyển đổi cho mỗi token, nên BF16 nhanh hơn vài phần trăm ở bất kỳ mức độ đồng thời nào. Thắng lợi là dung lượng: BF16 hết bộ nhớ đệm ở 32 yêu cầu đồng thời, trong khi FP8 tiếp tục đến 64 và đạt 2.192 token mỗi giây, cao hơn khoảng 41% so với đỉnh của BF16, với chi phí mỗi token thấp hơn khoảng 30%. Vì prefill bị ràng buộc bởi tính toán hơn là bộ nhớ, Cloudflare giữ bộ nhớ đệm ở BF16 ở đó và chỉ áp dụng FP8 cho nhóm decode.

Độ chính xác được giữ vững. Trên GSM8K, ARC, MMLU, MMLU-Pro, và các benchmark nội bộ, bộ nhớ đệm FP8 và BF16 không khác biệt về mặt thống kê.

Trọng số INT4 giảm GLM 5.2 đi 40%

Với GLM 5.2, Cloudflare nén trọng số từ dấu phẩy động 8-bit sang số nguyên 4-bit (INT4). Checkpoint giảm từ 705 GB xuống 421 GB, và bộ nhớ mỗi GPU trong triển khai tensor-parallel 8 chiều giảm từ khoảng 88 GB xuống 52 GB—chừa chỗ cho khoảng 1,18 triệu token bộ nhớ đệm KV trên cùng phần cứng.

Trọng số nhỏ hơn làm decode nhanh hơn vì tạo mỗi token nghĩa là truyền trọng số ra khỏi bộ nhớ, và tốc độ decode bị ràng buộc bởi băng thông. Ở độ đồng thời thấp, hiệu quả rõ rệt: thông lượng một yêu cầu tăng từ 60 lên 92 token mỗi giây, tăng 55%. Ở độ đồng thời cao hơn, mức tăng ổn định ở 16–27%. Prefill, bị ràng buộc bởi tính toán, thực sự chậm hơn với INT4 (8.660 so với 10.160 tok/s ở FP8), nên thiết kế phân tách cho phép Cloudflare chạy INT4 cho decode và FP8 cho prefill—mỗi cái ở nơi nó thắng. Độ chính xác nằm trong khoảng 0,8 điểm so với FP8 trên tất cả các benchmark.

Bảo vệ bộ nhớ đệm dùng chung

Cả hai tối ưu hóa đều nhồi nhiều yêu cầu hơn lên cùng một GPU, nghĩa là hàng trăm yêu cầu đang đọc và ghi các trang của cùng một bộ nhớ đệm KV vật lý. Chú ý phân trang, xử lý theo lô liên tục, và tái sử dụng bộ nhớ đệm đều phụ thuộc vào việc ghi sổ hoàn hảo. Ở khối lượng yêu cầu của Cloudflare, ngay cả lỗi một phần tỷ cũng sẽ xuất hiện thường xuyên.

Phòng thủ của họ: mỗi trang bộ nhớ đệm vật lý có một thẻ thay đổi khi cấp phát lại, và máy chủ ghi lại trang và thẻ mà mỗi yêu cầu mong đợi. Trước khi các thao tác decode được hỗ trợ đọc từ bộ nhớ đệm, các ánh xạ được kiểm tra; bất kỳ sự không khớp nào sẽ hủy yêu cầu thay vì trả dữ liệu từ sai trang. Chi phí dưới 1% trên cả thông lượng và độ trễ p95, đo trên mô hình sản xuất với đầu vào 8.192 token và đầu ra 1.000 token. Kiểm tra chạy như một xác thực theo lô riêng thay vì hợp nhất vào kernel chú ý, tránh cuộc đua giữa các nhóm luồng GPU. Nó được bật theo từng triển khai, và trình theo dõi no-op mặc định có chi phí bằng không.

Tiếp theo là gì

Cloudflare đang mở rộng bộ nhớ đệm KV FP8 trên nhiều hạ tầng hơn, xác thực trọng số NVFP4 trên Blackwell, và hướng tới việc bật kiểm tra toàn vẹn ở mọi nơi với chi phí không đáng kể. Công việc được đóng góp ngược lên SGLang, khung phục vụ mã nguồn mở mà họ sử dụng và đóng góp.