클라우드플레어는 10월26일 Workers AI에서 제공하던 GLM-5.3의 요청 간 자료 노출을 공개했다. 회사가 확인한 영향 기간은 8월27일부터 9월9일까지다. 같은 모델에 앞서 들어온 다른 고객의 입력과 생성 내용이 일부 응답에 나타났다. 조사에서 영향을 받은 응답은 155건으로, 모두 68만1,280토큰보다 긴 입력에 대한 것이었다.
10월의 발표가 다루는 것은 9월에 고친 사고다
회사에 따르면 9월8일 제보를 받고 다음 날 문제를 재현해 모델의 공개 접근을 중단했다. 설정과 엔진을 고친 뒤 9일 저녁 서비스를 복구했다. 다른 Workers AI 모델의 영향과 고의적 악용 증거는 발견하지 못했다고 밝혔다. 이는 운영사의 조사 결과이며, 이번 공개를 현재 모든 모델에서 계속되는 사고로 읽어서는 안 된다.
설정에는 들어갔지만 메모리에는 들어가지 않았다
문제가 된 배포의 문맥 길이는 104만8,576토큰으로 설정돼 있었다. 그러나 입력을 먼저 처리하는 GPU의 KV 캐시 풀에는 68만1,280토큰만 담을 수 있었다. KV 캐시는 모델이 앞선 내용을 이어 계산하기 위해 보관하는 중간 자료다. 입력을 허용하는 설정값과 실제 처리 공간이 일치하지 않은 것이다.
클라우드플레어는 이 차이를 출시 전에 알고 있었다고 설명한다. 다만 긴 입력 시험에서 성공 상태 코드와 오류 없는 스트림을 받았기 때문에 엔진이 차이를 처리한다고 판단했다. 사후 기록은 출력의 내용과 일관성까지 검사하지 않은 점을 시험의 공백으로 짚는다. 허용 길이를 적은 설정만 읽어서는 실행 중인 엔진의 수용 능력을 알 수 없었다.
거절한 요청이 다음 단계로 넘어간 이유
이 배포는 입력을 처리하는 프리필과 응답을 생성하는 디코드가 분리돼 있었다. 용량을 넘은 요청은 내부에서 거절 표시를 받았지만, 한 토큰짜리 대체 입력으로 바뀐 뒤에도 인계 경로를 따라갔다. 디코드 쪽은 전송 완료를 보고 원래 요청에 필요한 캐시가 모두 채워졌다고 간주했다. 실제로 새로 쓰이지 않은 영역에는 이전 요청의 자료가 남아 있었다.
SGLang 팀의 설명에 따르면 단일 노드의 거절 경로는 오류를 반환했다. 같은 입력 검사가 있어도 두 단계가 나뉜 경로에서 거절 상태를 전달하는 방식은 달랐다. 후속 수정은 입구에서 거절된 요청을 인계 전에 멈추게 한다. 내부 실패가 최종 성공 응답으로 바뀌지 않도록 경계마다 상태를 이어주는 작업이다.
요청이 끝나는 때와 쓰기가 끝나는 때
두 팀은 이 사고와 함께 캐시 메모리의 수명 문제도 다뤘다. 별개의 관련 오류에서는 요청이 중단돼도 다른 장치가 이미 시작한 전송은 계속될 수 있었다. 그 사이 수신 측이 해당 공간을 다른 요청에 내주면 늦게 도착한 쓰기가 새 요청의 자료를 덮는다. 사용자가 연결을 끊었다는 사실만으로 원격 쓰기까지 끝난 것은 아니었다.
SGLang은 중단된 요청의 공간을 바로 재사용하지 않고 전송이 정리되는 동안 보유하는 방식을 설명했다. 거절된 요청의 잘못된 인계와 진행 중인 쓰기의 지연 도착은 원인이 다르다. 하나의 패치를 모든 캐시 문제의 해결로 묶기보다, 새 요청을 받는 문턱과 이미 맡긴 메모리를 돌려받는 시점을 함께 다뤘다는 점이 중요하다.
상태 코드, 내용의 일관성, 자료의 출처를 따로 확인하면
HTTP 200은 요청에 응답이 왔다는 신호였지만 그 내용이 해당 요청의 자료만으로 구성됐다는 증거는 아니었다. 문장이 자연스럽게 이어졌다는 사실도 자료의 출처가 맞다는 확인을 대신하지 못했다. 같은 응답에서 전송의 성공, 내용의 일관성, 요청 사이의 격리는 각각 다른 항목이었다.
거절된 요청을 다음 단계에 보내지 않는 수정과 이미 시작된 원격 쓰기가 끝날 때까지 공간을 보유하는 수정도 다른 경계를 다룬다. 전자는 어떤 작업이 진입하는지, 후자는 언제 메모리를 다시 내주는지의 문제다.
| 항목 | 확인할 대상 |
|---|---|
| 상태 코드 | 오류가 최종 응답까지 올바르게 전달되는가 |
| 출력 내용 | 입력에 맞는 응답과 일관성을 갖는가 |
| 자료 격리 | 다른 요청이 남긴 자료가 섞이지 않는가 |
| 메모리 수명 | 진행 중인 쓰기가 끝나기 전에 재사용되지 않는가 |
긴 입력을 받을 수 있다는 설정과 실제로 요청을 안전하게 처리할 메모리는 별개의 조건이었다. 오류 처리와 비동기 쓰기의 경계를 함께 살펴야 성공 상태 코드 뒤에서도 자료 격리가 유지되는지 판단할 수 있다.
ARCH.B 의견
문서 검색이나 코드 분석 도구를 만드는 팀에게 이 기록은 모델의 답변 정확도 이전의 질문을 남긴다. 응답을 정상적으로 받았더라도 그 내용이 이 요청에 속한 자료만으로 만들어졌는가. 긴 입력을 보냈을 때의 속도와 비용만 재면 이 질문은 빠진다. 서버가 오류 없이 일을 끝냈다는 관측과 사용자별 자료의 경계를 지켰다는 검증은 다른 결과를 요구한다.
클라우드플레어가 이후 배포 검사에 실행 중인 캐시 풀과 문맥 길이의 직접 대조를 넣은 이유도 여기에 있다. 설정 파일의 의도보다 실제 장치가 할당한 자원을 읽는 것이다. 또한 앞선 요청이 남긴 식별용 자료가 다음 응답에 나오는지 시험하면, 그럴듯한 문장이 잘못된 메모리에서 나오는 경우를 잡을 수 있다. 이 사건의 핵심은 더 긴 문맥을 지원하는 수치보다, 자료의 소유권을 오류·중단·인계 뒤에도 끝까지 유지하는 데 있다.
