심층 해설 · 약 4분 읽기
Cloudflare가 설명한 GLM-5.3 캐시 격리 사고와 성공 응답의 한계
10월 26일 공개는 8~9월 사고에 대한 보고다. 설정과 엔진 수정, 아직 끝나지 않은 무결성 작업을 구분한다.
- 사이트 게시일
- 원문 게시일
- 출처 확인일
Cloudflare는 10월 26일 Workers AI의 GLM-5.3 배포에서 요청 간 데이터 노출이 발생한 경위를 공개했다. 회사는 캐시 용량 불일치와 SGLang 거부 처리 오류가 결합한 결과라고 설명한다. 9월 9일 복구한 사고에 대한 보고이며, 새 장애나 모든 GLM 배포에서 입증된 결함을 뜻하지 않는다.
뉴스 듣기
이 기사를 읽어 드리거나 뉴스를 계속 재생합니다.
읽기를 준비하는 중…
기기 음성
읽기는 브라우저나 기기에서 처리합니다. AISubHub는 내용을 오디오 API로 보내지 않습니다. 사용 가능한 음성과 잠금 화면 재생은 기기에 따라 다릅니다.
계속 재생할 때 짧은 구절이 반복될 수 있습니다.
핵심 요약
- Cloudflare는 8월 27일부터 9월 9일까지 155개 응답이 영향을 받았고 모두 681,280 tokens를 넘는 프롬프트였다고 밝혔다. 155는 고객 수가 아니다.
- 설정된 문맥은 1,048,576 tokens였지만 prefill 풀은 681,280 tokens만 수용했다. 수정 후에는 약 204만 tokens이며 엔진의 거부 경로도 고쳤다.
- 분리형 운영자에게 SGLang v0.5.22 이상을 권고한다. 탐지 범위는 아키텍처에 따라 다르며 장기 무결성 작업은 완성된 보편적 보장이 아니다.
공개일과 사고 기간은 서로 다르다
Cloudflare는 Workers AI 출시일인 8월 27일부터 9월 9일까지를 노출 기간으로 제시한다. Knostic의 Gadi Evron이 9월 8일 문제를 신고했다. 다음 날 13:22 UTC에 사고를 선언하고 14:00에 모델을 비공개로 전환했으며, 수정과 검증 뒤 19:40에 공개 서비스를 복구했다. 10월 26일은 조율된 공개 날짜다.
회사는 같은 모델에 직전에 들어온 다른 고객 요청의 자료가 포함된 응답 155개를 확인했다. 자체 시험과 연구자의 시험을 제외하면 시간과 양이 일반적인 긴 문맥 사용과 부합했고 고의 악용 증거는 없었다고 설명한다. 이는 악용이 전혀 없었다는 증명이 아니다. 다른 Workers AI 모델은 영향받지 않았다는 것도 회사의 조사 결론이다.
공시된 문맥이 실제 캐시 풀보다 컸다
이 배포에서는 prefill GPU가 프롬프트를 처리하고 키·값 캐시를 Mooncake와 RDMA를 통해 decode GPU로 전달했다. SGLang은 가중치를 적재한 뒤 남은 메모리로 풀 크기를 정했고 문맥 상한은 따로 설정했다. 그 결과 1,048,576 tokens 문맥에 681,280 tokens 용량만 제공되는 불일치가 생겼다.
Cloudflare는 출시 전에 이 차이를 알았지만 긴 문맥 시험에서 성공 응답을 받아 과도한 요청은 안전하게 실패할 것으로 가정했다고 인정한다. 보고서는 HTTP 상태와 성능을 확인하면서 출력 검증은 충분히 하지 않은 공백을 지적한다. 설명된 원인은 배포 설정과 엔진의 상호작용이며 모델 가중치의 백도어를 입증하지 않는다.
거부 예정 요청이 여전히 활성 상태로 통과했다
스케줄러는 너무 큰 요청에 거부 표시를 하고 프롬프트를 한 토큰짜리 임시 입력으로 교체했다. 그러나 분리형 입구는 거부 여부가 아니라 요청이 종료됐는지를 검사했다. 보류된 오류가 종료 판정을 참으로 만들지 않았기 때문에 prefill과 decode 모두 오류로 끝나야 할 요청을 받아들였다.
원문의 그림은 예약한 8페이지 가운데 새 요청이 1페이지만 쓰고 나머지 7페이지에는 이전 데이터가 남는 예를 보여 준다. 이 페이지 수는 사고 통계가 아닌 설명용이다. 클라이언트는 HTTP 200, 그럴듯한 토큰 수, 자연스러운 글을 받으면서도 이전 요청 내용을 포함할 수 있었다. 응답 성공은 격리의 정확성을 입증하지 못했다.
즉시 복구는 설정과 엔진 두 층에서 이뤄졌다
Cloudflare에 따르면 설정 변경 후 prefill 풀은 약 204만 tokens를 수용해 1,048,576 tokens 문맥보다 커졌다. 동시에 거부 예정 요청을 할당·캐시 전송 전 입구에서 종료하도록 엔진을 고쳤다. 두 변경을 검증한 뒤 서비스를 재개했다고 한다. 풀 확장만으로는 향후 메모리 설정에 대한 취약한 의존성이 남는다.
상류 표는 v0.5.20 초기 수정, v0.5.21의 더 이른 거부, v0.5.22까지의 후속 강화를 구분한다. 분리형 운영자에게 v0.5.22 이상이나 적절한 패치 백포트를 권고한다. 이는 해당 서빙 방식과 수정 묶음에 대한 조언이며 성능 비교나 버전 번호만으로 모든 배포의 안전을 증명하는 말이 아니다.
진행 중 쓰기는 페이지 수명을 분산 문제로 만든다
보고서는 관련된 다른 오류도 설명한다. 요청을 중단해도 이미 전송한 RDMA 쓰기는 회수할 수 없다. 목적지 페이지를 너무 빨리 재사용하면 늦게 도착한 쓰기가 다른 요청을 손상시킬 수 있다. 이런 시간 의존 경쟁과 달리 이번 거부 요청은 결정적으로 잘못된 인계 경로를 따랐다. 두 경우 모두 관련 작업이 끝날 때까지 소유권을 추적해야 한다.
회사는 양쪽 역할의 지연 해제, Mooncake 전송 배치 제한, 로드 밸런서 연결 종료 처리 변경, 배포 검사를 설명한다. 가중치·양자화·병렬 설정을 바꿀 때마다 양쪽 실제 풀을 측정하도록 권한다. Checksum과 KV Canary는 아직 모든 아키텍처를 지원하지 않아, 옵션을 켰다고 매 요청을 검사한다고 가정할 수 없다.
장기 무결성 작업은 아직 완성되지 않았다
페이지 태그 시제품은 8월 GLM-5.2에서 시험됐다. Cloudflare는 처리량과 꼬리 지연 비용이 1% 미만이었다고 보고하지만, 신뢰성 문제로 곧 비활성화했다고 밝힌다. 이 수치는 제한된 실험의 결과이지 현재 배포된 보호나 보편적 비용 측정이 아니다. 해제 시 페이지를 0으로 지우는 방안도 초안으로 남아 있다.
전송 체크섬은 인계를 검증하고 페이지 소유권 검사는 이후 읽기까지 검증을 넓히는 방안이다. Cloudflare는 분산 전송 프로토콜의 형식 모델도 계획하면서 증명 범위의 한계를 인정한다. AISubHub 분석: 격리, 거부, 수명 불변조건을 각각 확인하고 배포된 보호와 시제품, 미래 보장을 명확히 구분해야 한다.
중요한 이유
AISubHub 분석: 테넌트 격리는 별도의 인수 기준이어야 한다. HTTP 상태, 토큰 집계, 속도가 정상처럼 보여도 메모리 소유권이 잘못될 수 있다. 설정 검증과 실패 경로 시험은 성능 벤치마크와 다른 문제를 확인한다.
제한 및 이용 가능성
범위, 복구 결과, 고의 악용 증거를 찾지 못했다는 설명은 Cloudflare의 자체 보고다. AISubHub는 서비스나 패치를 독립 감사하지 않았다. 모든 GLM 배포가 영향받았거나 모든 SGLang 설정이 캐시 수명 오류에서 안전하다는 결론은 낼 수 없다.
출처와 근거
원문 게시일: · 출처 확인일:
AI 보조 편집 기사를 명시한 일차 출처와 대조합니다. 업체 주장은 출처를 밝히며 게재는 추천을 뜻하지 않습니다.