Khi Bộ Đệm KV Biến Lệch Cấu Hình Thành Rò Rỉ Dữ Liệu Chéo

Báo cáo của Cloudflare về sự cố rò rỉ dữ liệu chéo trên mô hình @cf/zai-org/glm-5.3 thuộc Workers AI cho thấy một thực tế sống còn của hạ tầng AI: khi vận hành LLM đa khách hàng (multi-tenant), lỗi quản lý bộ nhớ chính là lỗ hổng bảo mật. Từ ngày 27/8 đến 9/9/2026, 155 phản hồi cho các câu lệnh (prompt) dài trên 681.280 token đã trả về nội dung từ phiên của khách hàng khác, do lệch cấu hình cửa sổ ngữ cảnh kết hợp với lỗi xử lý trạng thái trong engine mã nguồn mở SGLang.

Đánh Đổi Hiệu Năng Phía Sau Bộ Đệm KV Dùng Chung

Để hiểu vì sao prompt của người này có thể lọt vào câu trả lời của người khác, cần nhìn vào cách engine suy luận quản lý bộ nhớ GPU. Khi LLM xử lý câu lệnh, nó tính toán các tensor Khóa (Key) và Giá trị (Value) — tức bộ đệm KV (KV cache) — cho từng token để không phải tính lại toàn bộ chuỗi khi sinh từng từ tiếp theo.

Trong các engine thông lượng cao như SGLang hay vLLM, bộ đệm KV nằm trong vùng bộ nhớ GPU dùng chung, chia thành các trang (pages) cố định. Khi có yêu cầu mới, bộ lập lịch cấp phát trang trống để lưu ngữ cảnh; khi xong, các trang này được trả về bể nhớ để tái sử dụng. Điểm mấu chốt là các engine không xóa trắng (zero out) trang nhớ GPU giữa các yêu cầu, vì ghi đè số 0 lên hàng gigabyte bộ nhớ băng thông cao sau mỗi lượt sẽ gây trễ nghiêm trọng. Thay vào đó, hệ thống dựa vào quy ước: trang mới cấp phát luôn được ghi đè hoàn toàn ở pha tiền xử lý (prefill) trước khi pha giải mã (decode) đọc dữ liệu.

Tối ưu này chỉ an toàn khi cơ chế theo dõi quyền sở hữu trang và chuyển đổi trạng thái hoàn toàn kín kẽ. Nếu một yêu cầu bỏ qua bước ghi nhưng vẫn nhận con trỏ trang nhớ để đọc, mô hình không sập mà tiếp tục đọc trạng thái KV còn sót lại từ khách hàng trước.

Khi Kiến Trúc Tách Rời Khuếch Đại Lỗi Lệch Cấu Hình

Cloudflare chạy glm-5.3 bằng SGLang theo kiến trúc tách rời tiền xử lý và giải mã (disaggregated prefill/decode), chia tải cho hai cụm phần cứng:

• Các nút Prefill: Nhận toàn bộ prompt, tính toán song song các trang KV ban đầu và truyền qua RDMA bằng thư viện Mooncake.
• Các nút Decode: Nhận các trang KV đã điền dữ liệu và sinh tuần tự từng token đầu ra.

Sự cố kích hoạt khi hai lỗi chồng lên nhau. Đầu tiên là lệch cấu hình: Cloudflare đặt cửa sổ ngữ cảnh của glm-5.3 ở mức 1.048.576 token theo công bố, nhưng SGLang lại tính kích thước bể KV lúc khởi động dựa trên phần VRAM còn dư sau khi nạp trọng số. Trên GPU prefill, bể nhớ chỉ chứa được 681.280 token. Do thiếu bước kiểm tra ép bể KV vật lý phải lớn hơn hoặc bằng ngữ cảnh tối đa, các prompt từ 681.281 đến 1.048.576 token vẫn qua được cổng API nhưng không vừa bộ nhớ prefill.

Thứ hai là lỗi máy trạng thái trong SGLang (issue 30233 ngày 6/7/2026). Ở chế độ đơn nút, yêu cầu vượt dung lượng sẽ báo lỗi ngay. Nhưng ở chế độ tách rời, khi prompt vượt ngưỡng 681.280 token, SGLang đánh dấu yêu cầu là rejected và thay prompt quá khổ bằng 1 token giữ chỗ (placeholder) để xả luồng. Tuy nhiên, hàng đợi điều phối giữa prefill và decode chỉ kiểm tra cờ finished mà bỏ qua cờ rejected.

Hệ quả là yêu cầu bị từ chối vẫn đi tiếp. Cụm prefill chỉ xử lý 1 token giữ chỗ, báo hoàn tất truyền RDMA và chuyển giao cho nút decode. Nút decode liền sinh văn bản bằng cách đọc các trang KV được cấp phát nhưng chưa hề được ghi đè — làm lộ ngữ cảnh của người dùng trước.

Vì Sao Bài Kiểm Thử HTTP 200 Bỏ Sót Rò Rỉ?

Một chi tiết đáng chú ý là kỹ sư Cloudflare đã biết giới hạn 681.280 token trước khi ra mắt. Họ kỳ vọng SGLang sẽ từ chối prompt quá khổ bằng mã lỗi, nên khi bài kiểm thử ngữ cảnh dài trả về mã HTTP 200 kèm luồng token bình thường, họ tin rằng hệ thống đã xử lý êm đẹp giới hạn này.

Thực chất, bộ kiểm thử nhận về phản hồi HTTP 200 chứa văn bản sinh từ các trang KV chưa khởi tạo. Vì kịch bản chỉ kiểm tra mã trạng thái (status == 200) và độ trễ thay vì kiểm tra tính mạch lạc ngữ nghĩa hay truy xuất chuỗi đánh dấu (canary token), lỗi rò rỉ đã lọt qua khâu thử nghiệm.

Sau khi nhà nghiên cứu Gadi Evron từ Knostic báo cáo lỗ hổng qua HackerOne ngày 8/9/2026, Cloudflare tái hiện lỗi vào ngày 9/9, gỡ mô hình trong 40 phút từ lúc công bố sự cố và khôi phục dịch vụ cùng ngày. Họ đồng bộ cấu hình glm-5.3 với glm-5.2 — nâng bể KV prefill lên khoảng 2,04 triệu token — đồng thời phối hợp cùng SGLang tung bản vá (gồm PR 38704 và bản v0.5.22) để hủy ngay các yêu cầu bị từ chối trước khi cấp phát KV.

Gia Cố Hạ Tầng Suy Luận Tự Vận Hành

Với các đội ngũ vận hành SGLang, vLLM hay TensorRT-LLM đa khách hàng, sự cố này chứng minh bảo mật LLM gắn liền với quản trị bộ nhớ GPU. Kỹ sư hệ thống cần áp dụng ba chốt chặn:

def verify_kv_capacity(configured_max_context: int, prefill_kv_pool_tokens: int, decode_kv_pool_tokens: int) -> None:
    """Kiểm tra điều kiện bất biến khi khởi động nút suy luận tách rời."""
    if prefill_kv_pool_tokens < configured_max_context:
        raise RuntimeError(
            f"Bể KV prefill ({prefill_kv_pool_tokens}) nhỏ hơn "
            f"độ dài ngữ cảnh cấu hình ({configured_max_context}). Hủy khởi động."
        )
    if decode_kv_pool_tokens < configured_max_context:
        raise RuntimeError(
            f"Bể KV decode ({decode_kv_pool_tokens}) không đủ chứa toàn bộ ngữ cảnh."
        )

1. Kiểm tra dung lượng lúc khởi động: Chặn container suy luận nhận tải nếu bể KV thực tế trên nút prefill hoặc decode nhỏ hơn --context-length.
2. Cập nhật ngay engine tách rời: Hệ thống chạy SGLang chế độ tách rời cần nâng cấp lên v0.5.22 trở lên để hủy triệt để yêu cầu vượt ngưỡng ngay từ cổng tiếp nhận.
3. Kiểm thử ngữ nghĩa ở biên độ tối đa: Bài kiểm thử tải ngữ cảnh dài phải chèn chuỗi canary ở cuối prompt và đối chiếu kết quả đầu ra. Trong hạ tầng LLM, mã HTTP 200 chỉ chứng minh kết nối mạng thông suốt — không chứng minh ranh giới bộ nhớ vẫn an toàn.

Nguồn tham khảo

1. blog.cloudflare.com
2. github.com
3. github.com