Cloudflare đã xuất bản một báo cáo sự cố chi tiết mô tả cách một lỗi xử lý bộ đệm trong nền tảng AI không có máy chủ của họ đã khiến ít nhất 155 người dùng triển khai mô hình GLM-5.3 nhận được phản hồi chứa các đoạn lời nhắc và đầu ra của khách hàng khác. Báo cáo, được xuất bản vào ngày 26 tháng 10 dưới dạng tiết lộ phối hợp cùng với dự án công cụ suy luận nguồn mở SGLang, cung cấp một cái nhìn công khai hiếm hoi về hệ thống cung cấp LLM cho nhiều người thuê - và cảnh báo về các giả định bảo mật của bộ nhớ GPU.

Làm thế nào tìm thấy rò rỉ For more context on this story, see our ongoing more AI stories.

Theo Cloudflare, nhà nghiên cứu bảo mật Gadi Evron của Knostic đã cảnh báo công ty vào ngày 8 tháng 9 năm 2026, thông qua chương trình tiền thưởng lỗi HackerOne. Evron báo cáo rằng những lời nhắc rất dài được gửi tới mô hình GLM-5.3 trên nền tảng AI của Cloudflare đôi khi trả về văn bản thuộc phiên của những người dùng khác. Cloudflare đã tái tạo sự cố vào sáng hôm sau và vô hiệu hóa mô hình cùng ngày, khôi phục nó vào ngày 9 tháng 9 sau khi triển khai các bản sửa lỗi.

Mô hình bị ảnh hưởng là @cf/zai-org/glm-5.3 — mô hình mã hóa tác nhân từ Z.ai mà Cloudflare phục vụ thông qua Workers AI, nền tảng suy luận không có máy chủ của công ty. Cloudflare xác nhận rằng không có mô hình nào khác được lưu trữ trên nền tảng này bị ảnh hưởng.

Điều gì thực sự đã xảy ra

Vụ việc bắt nguồn từ hai vấn đề chồng chéo, một vấn đề về vận hành và một ở chính động cơ.

Đầu tiên là cấu hình sai. Cloudflare đã triển khai GLM-5.3 với cửa sổ ngữ cảnh 1.048.576 mã thông báo, nhưng nhóm bộ nhớ đệm khóa-giá trị (KV) trên GPU nạp sẵn của nó chỉ có chỗ cho 681.280 mã thông báo. Công ty thừa nhận họ đã biết về sự không phù hợp này trước khi ra mắt và mong đợi công cụ suy luận sẽ từ chối các yêu cầu quá dài một cách an toàn.

Thứ hai là lỗi động cơ. Ở chế độ điền trước/giải mã được phân tách — kiến ​​trúc mà Workers AI sử dụng, trong đó một nhóm GPU xử lý lời nhắc và chuyển bộ đệm KV kết quả cho một nhóm GPU riêng biệt tạo ra phản hồi — SGLang đã xử lý yêu cầu quá dài không chính xác. Lời nhắc không phù hợp với nhóm đã được đánh dấu nội bộ là bị từ chối và được thay thế bằng trình giữ chỗ một mã thông báo. Nhưng thay vì hủy bỏ yêu cầu và trả về lỗi máy khách, giai đoạn điền trước đã tạo bộ đệm KV cho lời nhắc giữ chỗ và chuyển nó đến nút giải mã, sau đó tạo ra phản hồi trộn lẫn dữ liệu còn sót lại từ các yêu cầu trước đó chia sẻ cùng một trang bộ nhớ.

Kết quả: từ ngày 27 tháng 8 đến ngày 9 tháng 9, một số ít khách hàng sử dụng mô hình đã nhận được phản hồi chứa dữ liệu từ các yêu cầu của khách hàng khác được đưa ra ngay trước yêu cầu của họ. Tổng cộng, 155 phản hồi đã bị ảnh hưởng – theo Cloudflare, tất cả đều có các lời nhắc dài hơn 681.280 mã thông báo.

Không có bằng chứng cố ý khai thác

Cloudflare tuyên bố rằng sau khi loại trừ thử nghiệm của chính họ và các yêu cầu xác thực của nhà nghiên cứu, các yêu cầu bị ảnh hưởng đều nhất quán về thời gian và khối lượng khi sử dụng theo ngữ cảnh dài thông thường và công ty không tìm thấy bằng chứng nào cho thấy bất kỳ ai cố tình khai thác lỗi. Vì mọi yêu cầu bị ảnh hưởng đều vượt quá dung lượng của nhóm có kích thước thấp nên khoảng thời gian tiếp xúc bị giới hạn chặt chẽ — một lớp lót bạc xuất phát từ chính cấu hình sai đã gây ra sự cố.

Cách khắc phục: Nhóm lớn hơn và đường dẫn thất bại an toàn hơn

Việc khắc phục đã có tác dụng trên cả hai lớp lỗi. Cloudflare đã cấu hình lại quá trình triển khai GLM-5.3 để phù hợp với cấu hình GLM-5.2, giải phóng đủ bộ nhớ GPU để nhóm KV điền trước hiện chứa khoảng 2,04 triệu mã thông báo — gần gấp đôi độ dài ngữ cảnh 1.048.576 mã thông báo của mô hình. Lời nhắc phù hợp với cửa sổ ngữ cảnh giờ đây luôn phù hợp với nhóm.

Nhưng công ty cũng nhấn mạnh rằng chỉ dựa vào kích thước nhóm là rất mong manh: những thay đổi về lượng tử hóa, độ song song tensor, kích thước đồ thị CUDA hoặc phiên bản mô hình trong tương lai có thể âm thầm thay đổi kích thước nhóm. Vì vậy, nó cũng vá chính đường dẫn từ chối của SGLang, đảm bảo rằng yêu cầu bị từ chối sẽ bị hủy bỏ hoàn toàn thay vì tạo và chuyển bộ đệm cho một trình giữ chỗ. Cả hai thay đổi đều được xác thực dựa trên tập lệnh sao chép của nhà nghiên cứu và các thử nghiệm đánh dấu canary của chính Cloudflare trước khi mô hình được khôi phục và các bản sửa lỗi đã được đóng góp ngược dòng cho các nhà bảo trì SGLang.

Tại sao bộ nhớ GPU dùng chung là câu hỏi bảo mật

Báo cáo giải thích một phương pháp sẽ khiến nhiều nhà phát triển ứng dụng ngạc nhiên: các công cụ suy luận thường không loại bỏ các trang bộ đệm KV giữa các yêu cầu, vì yêu cầu tiếp theo chỉ ghi đè lên chúng. Đây là sự đánh đổi hiệu suất có chủ ý, phổ biến trên các công cụ suy luận, nhưng như sự cố này cho thấy, bất kỳ đường dẫn nào cho phép tạo phản hồi trước khi các trang đó bị ghi đè hoàn toàn sẽ biến hoạt động tối ưu hóa hiệu suất thành vectơ rò rỉ dữ liệu.

Tiết lộ này đã đến với cộng đồng nhà phát triển: câu chuyện đã đạt 123 điểm trên Hacker News trong vòng vài giờ, với cuộc thảo luận tập trung vào cách thức chế độ thất bại — một yêu cầu đáng lẽ phải thất bại nặng nề thay vì tiến hành âm thầm ở trạng thái bị hỏng — phản ánh những bài học kinh điển từ kỹ thuật hệ thống phân tán.

Bài học rộng hơn cho cơ sở hạ tầng AI

Vụ việc này là lời nhắc nhở rằng phạm vi bảo mật cho các ứng dụng AI hiện đã mở rộng sâu vào cơ sở hạ tầng suy luận. Việc phục vụ mô hình nhiều bên thuê tập trung dữ liệu của nhiều khách hàng thông qua các bộ tăng tốc dùng chung, nhóm bộ nhớ đệm dùng chung và các kiến ​​trúc ngày càng kỳ lạ như điền trước phân tách và truy cập bộ nhớ trực tiếp từ xa. Sự không khớp nhỏ giữa cửa sổ ngữ cảnh được quảng cáo của mô hình và năng lực vật lý được cung cấp để phục vụ nó đủ để vi phạm sự cô lập của người thuê.

Đối với các doanh nghiệp xây dựng trên nền tảng AI không có máy chủ, báo cáo của Cloudflare có hai điểm rút ra: lỗi cách ly đối tượng thuê trong phân phối LLM là có thật và đã xảy ra trong quá trình sản xuất, đồng thời thời gian phản hồi của nhà cung cấp — dưới 24 giờ kể từ khi báo cáo đến khi vô hiệu hóa, một ngày để khắc phục và khôi phục — là tiêu chuẩn về sự siêng năng cần có từ bất kỳ nhà cung cấp nào xử lý các lời nhắc nhạy cảm.

---

Stay Ahead of AI

Get the latest AI news, analysis, and breakthroughs — all in one place.

Read more AI news →