Hiệu năng bộ nhớ đệm AI cần được đo trong ranh giới tin cậy

Thông báo ngày 26 tháng 10 năm 2026 của Cloudflare ghi nhận lộ dữ liệu giữa các yêu cầu trong triển khai GLM-5.3 từ ngày 27 tháng 8 đến 9 tháng 9. Công ty nói các mô hình Workers AI khác không bị ảnh hưởng. Báo cáo công ty.

Đây là một sự cố cụ thể, không phải bằng chứng rằng mọi dịch vụ suy luận dùng chung đều làm lộ thông tin. Tuy nhiên, nó đặt ra câu hỏi rộng hơn khi mua dịch vụ: khi nhà cung cấp công bố tốc độ cao hơn, phép đo đã giữ nguyên những ranh giới nào? Tốc độ chỉ có giá trị nếu dịch vụ vẫn thực hiện công việc được khách hàng cho phép.

Sự tách biệt giữa khách hàng cũng thuộc định nghĩa khối lượng công việc

Hãy hình dung một trợ lý tài liệu giả định được hai công ty sử dụng. Cả hai đều yêu cầu tóm tắt hợp đồng và dùng cùng chỉ dẫn công khai, nhưng tài liệu riêng của họ khác nhau. Một bài đo gộp các tác vụ vào cùng nhóm thuận tiện có thể cho kết quả hấp dẫn mà không phản ánh yêu cầu bảo mật thực tế.

Đề xuất phân tích của chúng tôi là đưa nhóm được phép chia sẻ vào định nghĩa khối lượng công việc. Các tác vụ thuộc một người, một nhóm, một tổ chức hay những tổ chức không liên quan? Những mô tả này không tương đương. Ngay trong một công ty, điều tra pháp lý và hội thoại hỗ trợ thông thường cũng có thể cần ranh giới truy cập khác nhau.

Điều này thay đổi cách đọc bảng so sánh. Giả sử một phép thử cho phép tái sử dụng rộng rãi, còn phép thử khác tách các phòng ban. Độ trễ thấp hơn ở phép thử đầu không tự chứng minh triển khai tốt hơn; chúng có thể đang cung cấp hai dịch vụ khác nhau. Trước hết cần thống nhất phạm vi chia sẻ được phép, rồi mới so sánh hiệu năng bên trong phạm vi đó.

Lập luận không phải là chia sẻ luôn sai. Tái sử dụng chỉ dẫn công khai mà mọi người đều có quyền xem có thể là lựa chọn hợp lý. Vấn đề xuất hiện khi cách phân nhóm kỹ thuật thuận tiện trở thành quyết định cấp quyền chưa được xem xét. Cùng mô hình, cùng tài khoản thanh toán hoặc câu hỏi có cách diễn đạt tương tự không tự quyết định những tác vụ nào nên chia sẻ trạng thái phát sinh.

Khách hàng cũng mua nhiều hơn một câu trả lời. Ranh giới cần giữ được lúc tải cao, sau khi tác vụ kết thúc và khi cách sử dụng thay đổi. Vì vậy, điều kiện cách ly nên đứng cùng loại tác vụ, quy mô đầu vào và tiêu chí nghiệm thu như tiền đề của báo cáo hiệu năng, thay vì một chú thích bên lề.

Có câu trả lời chưa phải là nghiệm thu đầy đủ

Thông báo ngày 26 tháng 10 của SGLang mô tả yêu cầu đã bị từ chối vẫn đi vào khâu bàn giao phân tách và đọc trang bộ nhớ đệm chưa được điền cho nó; báo cáo bàn riêng về bảo vệ vòng đời. Báo cáo bên duy trì.

Phân biệt này quan trọng với phân tích của chúng tôi: cố ý tái sử dụng tính toán khác với vô tình tiếp cận trạng thái của yêu cầu khác. Không thể mặc nhiên coi quy tắc quản lý trường hợp đầu là biện pháp ngăn trường hợp sau. Bên mua cần biết cả cách sắp xếp được phép lẫn bằng chứng triển khai giữ được nó khi tác vụ không diễn ra bình thường.

Có thể thiết kế một bài nghiệm thu có kiểm soát bằng tài liệu hư cấu, không dùng hồ sơ khách hàng. Một nhóm nhận nhãn dự án riêng biệt; nhóm khác không có quyền đọc nhãn ấy. Người đánh giá kiểm tra xem câu trả lời có mang thông tin từ sai nhóm hay không, đồng thời xác nhận các bản tóm tắt hợp lệ vẫn hữu ích. Đây là đề xuất kiểm thử được cấp phép, không phải ước tính tần suất lỗi của một dịch vụ thực tế.

Bài thử nên bao gồm tác vụ bị từ chối, bị gián đoạn và được thử lại, vì đó đều là trải nghiệm khách hàng có thể gặp. Chỉ thử tác vụ đúng định dạng và hoàn tất suôn sẻ sẽ để lại khoảng trống giữa kết luận công bố với câu hỏi vận hành. Tuy nhiên, vượt qua bài thử cũng không chứng minh mọi khả năng rò rỉ đã bị loại bỏ; nó chỉ tạo bằng chứng cho cấu hình, tình huống và thời gian quan sát đã xác định.

Một báo cáo hữu ích vì thế nên tách ba kết quả: câu trả lời hữu ích và được cấp quyền, từ chối hoặc thất bại rõ ràng, và câu trả lời đáng lẽ không được tạo ra với quyền hiện có. Gộp mọi phản hồi vào một tỷ lệ thành công sẽ che khuất khác biệt quan trọng nhất. Thất bại được giải thích rõ có thể tốt hơn câu trả lời trôi chảy nhưng sai nguồn.

Cách phân biệt này còn định hình động lực tối ưu hóa. Chỉ nhắm giảm lỗi có thể khuyến khích trả nội dung cho nhiều tác vụ hơn; nhắm kết quả hữu ích được cấp quyền có thể khiến dừng một số tác vụ trở thành lựa chọn đúng. Đây là lập luận về tiêu chí nghiệm thu, không phải cáo buộc động lực sai lệch ở nhà cung cấp nào.

Cố định ranh giới trước khi so sánh hiệu quả

Một ví dụ thiết kế khác: tài liệu vLLM mô tả giá trị salt tùy chọn để giới hạn tái sử dụng bộ nhớ đệm tiền tố giữa yêu cầu có salt khớp nhau. Nó không sửa mọi lỗi vòng đời bộ nhớ đệm. Tài liệu vLLM.

Hàm ý mua sắm không phải bắt buộc dùng cách triển khai ấy. Điều cần có là chính sách chia sẻ mà bên mua mô tả được và bên vận hành kiểm tra được. Chủ ứng dụng có thể cho phép tái sử dụng trong một dự án nhưng tách khách hàng không liên quan. Người khác có thể chấp nhận dịch vụ chậm hơn để giảm trạng thái phát sinh được dùng chung. Chỉ nhìn số token mỗi giây không đủ đánh giá hai lựa chọn.

Có phản biện hợp lý: chia tách càng hẹp có thể càng giảm lợi ích kinh tế của nền tảng chung, còn kiểm thử phức tạp làm chậm áp dụng. Sự đánh đổi ấy cần được trình bày, không che đi. So sánh đúng là giữa các thiết kế đáp ứng cùng ranh giới bắt buộc, xét độ trễ, năng lực và gánh nặng vận hành; không phải giữa dịch vụ cách ly và phép đo không chịu cùng hạn chế rồi gọi chúng tương đương.

Nguyên tắc vẫn áp dụng khi nhóm thay đổi mô hình truy cập. Gộp hai không gian làm việc có thể tạo cơ hội chia sẻ mới; loại một thành viên có thể thu hẹp phạm vi. Trong mô hình quản trị chúng tôi đề xuất, thay đổi này cần kích hoạt việc xem lại giả định hiệu năng, không chỉ sửa danh bạ người dùng. Cấu hình nhanh chỉ có giá trị khi quyền của nó còn phù hợp với công việc.

Các thông báo không xác lập kiến trúc tốt nhất cho mọi khách hàng. Chúng gợi ra câu hỏi đánh giá chính xác hơn: còn bao nhiêu thông lượng hữu ích sau khi yêu cầu tách biệt đã được nêu rõ và kiểm tra? Đó là cơ sở chọn dịch vụ suy luận có ý nghĩa hơn một con số tốc độ tách khỏi ranh giới tin cậy.