요약
클라우드플레어 Workers AI의 GLM-5.3에서 다른 고객의 요청 내용이 응답 155건에 섞여 나갔습니다.
클라우드플레어가 SGLang 팀과 함께 공개한 사고 보고서입니다. 문제는 8월 27일 GLM-5.3 공개 때부터 이어졌고, 9월 8일 보안 연구자 가디 에브론의 제보로 드러났습니다.
왜 중요한가
- 여러 고객이 GPU 메모리를 나눠 쓰는 AI 추론 서비스에서 고객 간 격리가 깨질 수 있음을 보여 줍니다.
- 오류 대신 정상 응답이 나와서, 상태 코드와 성능만 확인한 테스트로는 유출을 잡지 못했습니다.
- 버그가 SGLang 엔진에 있었으므로 이 엔진을 쓰는 다른 운영자에게도 v0.5.22 이상으로 올리라고 권했습니다.
핵심 내용
- 영향받은 응답은 681,280토큰을 넘는 프롬프트에 대한 155건이며, 의도적 악용 흔적은 없었다고 밝혔습니다.
- 컨텍스트 창은 1,048,576토큰인데, 프리필(입력 처리 단계) GPU의 KV 캐시(앞 토큰의 계산 결과를 담는 메모리)는 681,280토큰분뿐이었습니다.
- 클라우드플레어는 이 차이를 출시 전에 알았지만, 긴 입력 테스트가 성공해 엔진이 알아서 처리한다고 여겼습니다.
- SGLang은 너무 긴 요청에 거부 표시만 하고 대기열에서 걸러 내지 않아, 이전 사용자 데이터가 남은 캐시 페이지가 응답에 쓰였습니다.
- 제보 다음 날 모델을 내리고 설정과 엔진을 고쳐 당일 복구했으며, 캐시 공간은 컨텍스트 창의 약 2배로 늘렸습니다.
HN 반응
- 제목에 모델 이름을 넣어 모델 결함처럼 읽힌다는 비판이 많았고, 글쓴이 측은 영향받은 엔드포인트를 알리려는 것이라고 답했습니다.
- 차이를 알고도 출시한 것을 버퍼 오버플로 방치에 빗댄 비판이 있었지만, 원인 분석과 빠른 대응을 높이 평가하는 의견도 나왔습니다.
이건 사실 GLM-5.3과는 별 상관이 없습니다. 모델을 여러 사용자가 공유하는데 관리(bookkeeping)를 제대로 하지 않으면 벌어지는 일이고, 실제 모델이 뭔지는 중요하지 않습니다. 이 사건이 보여주는 건 사용자 세션 사이의 격리가 충분하지 않았고, 절대 겹치면 안 되는 메모리가 겹칠 수 있었다는 점입니다.
이건 Z.AI 모델 버그이기 전에 한참 먼저 SGLang과 클라우드플레어의 버그입니다. Z.AI가 이걸 어떻게 막을 수 있었을지 모르겠습니다. 클라우드플레어는 제목에 다른 쪽(제 생각엔 아무 잘못 없는 쪽)을 들먹일 게 아니라 자기 잘못으로 인정해야 합니다.
저희는 모델의 버그라고 주장한 적이 한 번도 없습니다. 클라우드플레어 쪽 설정 실수와 SGLang의 버그였다는 점을 글에서 구체적으로 설명했습니다. 제목에 모델 이름을 넣은 건 어느 엔드포인트가 영향을 받았는지 고객이 알아야 하기 때문입니다. 게다가 저희가 쓴 표현은 "GLM-5.3"이 아니라 "GLM-5.3 Workers AI 모델"입니다.
납득이 안 됩니다. 제목에 'GLM 5.3 workers AI model'이라고 모델 이름을 콕 집어 넣으면 GLM 5.3에만 해당하는 문제처럼 읽히는데, 사실은 그렇지 않잖아요. SGLang을 언급하면서 에러가 안 난 걸 놀라워하는데, 문제는 처음부터 끝까지 당신들 쪽에 있었습니다.
맞아요, 제목을 아주 꼼꼼히 읽지 않는 사람이라면 GLM 버그를 말하는 것처럼 받아들일 게 뻔해요.
제목에 쓸데없는 부가 정보가 너무 많아서 "이건 클라우드플레어 버그다"라는 핵심이 묻혀 버려요.
제목이 수정됐는지는 모르겠지만, 지금 제목만 봐도 저는 이게 그쪽 버그라는 게 아주 분명해 보입니다. 캐시 얘기까지 나오는데 기술을 아는 사람(클라우드플레어로 모델을 쓰는 사람이라면)이 그걸 어떻게 오해하는지 모르겠어요.
제목은 표현이 서툽니다. 대충 훑어보다가 둘을 혼동하기 쉽다는 게 충분히 이해돼요. 제목에 모델 이름을 넣은 건 어리석은 선택입니다. 기사 본문에 언급하면 될 일이고, 지금 제목은 이 모델 자체와 관련된 문제처럼 읽힙니다.
글을 읽어 봤는데, 이건 그쪽 플랫폼의 GLM 5.3 모델에만 해당하는 문제가 맞는 것 같습니다. GLM 5.3만 SGLang을 쓰기 때문인지, 아니면 그 모델의 설정만 문제가 있어서인지는 모르겠습니다.
저랑 다른 글을 읽으셨나요? 글에서 제기한 문제들(아키텍처 분리, 메모리 전송, 클라우드플레어가 잘못 설정한 컨텍스트 윈도 할당, SGLang의 상태 누출, 클라이언트 오류 처리 부재) 중에 모델과 관련된 건 하나도 없습니다. 전부 하네스 계층, 즉 클라우드플레어의 설정에 있는 문제입니다.
더 나은 제목은 "Cloudflare가 프로비저닝한 GLM-5.3 Workers AI 모델의 요청 간 KV 캐시 노출" 같은 것이었을 겁니다. 책임 범위가 좁혀지니까요. AI와 SEO 데이터 스크레이핑이 판치는 시대에 클라우드플레어 블로그에 올렸다는 것만으로는 부족하고, 글쓴이들이 그걸 몰랐다면 오히려 놀랄 겁니다.
문제가 이 모델에 있는 건 아니지만, 이 모델에만 영향을 준 건 맞습니다.
제목에서 GLM 5.3을 빼도 제목과 본문 모두 완벽하게 말이 됐을 겁니다.
제목에 들어간 건 GLM-5.3 모델을 쓴 경우에만 영향이 있었을 수 있다고 고객에게 알려 주는 역할도 겸하기 때문이라고 생각해요. 그래도 좀 헷갈린다는 데는 동의합니다.
글을 읽고 모델 내용과는 아무 관계가 없다는 데 놀랐습니다. 100만 컨텍스트를 감당하는 모델이라면 어느 모델이든 클라우드플레어나 SGLang 쪽에서 이 버그나 설정 오류를 일으켰을 수 있습니다. 제목은 극도로 오해를 부릅니다.
"모델"을 "엔드포인트"로 바꾸면 도움이 될 것 같아요. 문제가 된 건 모델이 아니라 엔드포인트니까요.
저한테는 캐시와 관련된 건 모델 자체와 별 상관이 없다는 게 당연해 보입니다. 그리고 이 모델을 쓴 경우에만 영향을 받을 수 있다는 걸 제목으로 알 수 있어서 좋고요.
저는 "We have remediated the issue"라는 문장("문제를 해결했습니다")까지 읽고 나서야 클라우드플레어가 자기네 인프라에서 생긴 문제를 말하고 있다는 걸 알았습니다. 그 전까지는 전혀 분명하게 말하지 않고 오히려 다른 데를 가리키는 것처럼 보이거든요. 물론 클라우드플레어가 제품마다 어떤 이름을 쓰는지 이미 아는 사람이라면 얘기가 다르겠지만요.
GLM-5.3과 관련은 있지만, 모델과는 아무 관련이 없다는 말씀은 맞습니다.
영향을 받은 건 _GLM-5.3을 서빙하는 엔드포인트_입니다.
GLM-5.3 이름을 빼고 GLM-5.3을 서빙하는 엔드포인트를 달리 어떻게 가리킬 수 있을지 모르겠습니다.
다만 제목에 "모델"이라는 단어가 들어간 건 오해를 부른다고 생각합니다.
"저희는 GLM 5.3을 1,048,576토큰 컨텍스트 윈도로 배포했지만, 프리필(prefill) GPU의 KV 캐시 풀에는 681,280토큰 분량의 공간밖에 없었습니다. 출시 전부터 이 불일치를 알고 있었습니다."
681,280토큰밖에 못 담는데 1,048,576토큰이라고 광고했다는 건가요?
바로 다음 문장입니다. "저희는 엔진이 처리하지 못하는 프롬프트에는 오류를 반환할 것으로 기대했고, 긴 컨텍스트 테스트도 성공 응답을 반환했기 때문에 이게 문제라고 생각하지 않았습니다."
그건 SGLang에 책임을 돌리는 건데, SGLang도 이 일에 책임이 없습니다.
적어도 테스트하는 동안 누군가는 사용률 수치가 40%나 어긋난다는 걸 알아챘어야 합니다.
훨씬 나은 제목은 "Cloudflare의 설정 오류로 사용자 세션 간에 데이터 유출"이었을 겁니다.
그러니까 SGLang도 책임이 있죠. 분명히 그쪽 버그가 맞아요.
상관없어요. 100만 토큰 윈도라고 홍보해도 됐을 겁니다. 그러면 추론하다가 60만 토큰쯤에서 에러가 나겠죠. 작업을 끝낼 수도 없고, 60만 토큰 값도 청구받지 않을 테고요.
그쪽은 100만 토큰 윈도까지 되는 줄 알았던 거예요.
왜 그렇게 생각했을까요? 저는 전문가는 아니지만 가진 KV 캐시 풀보다 많이 서빙할 수 없다는 건 압니다. 동시 요청을 처리하려면 컨텍스트 윈도보다 KV 캐시 풀이 커야 하고요. 전체가 이상한데, 제 추측으로는 대부분의 사용자가 100k 정도 캐시를 쓰고 압축(compacting) 같은 걸 하니까 60만에 가까워질 일은 없다고 봤던 것 같습니다.
제 다른 댓글을 보세요. 이건 아마 프리필 GPU 풀에만 해당하는 얘기고, 일반적인 100만 토큰 세션은 문제없이 동작합니다. 클라우드플레어는 글 맨 위에 모델 서빙이 어떻게 돌아가는지 설명하는 링크를 걸어 두는 게 좋겠어요. 그 정도로 세부적인 내용까지 아는 사람이 많지 않으니까요.
이봐요, 이 문장을 앞 문장과 이어서 세 번이나 읽었는데 아직도 도무지 이해가 안 됩니다.
긴 프롬프트로 테스트하면서 실패했는지만 확인했다는 말 같아요. 그런데 그 테스트가 같은 KV 캐시 누출을 겪었을 텐데도 성공으로만 해석했을 가능성이 높다는 거죠.
고맙습니다...
그러니까 오버플로 위험이 있는 설정을 알면서도 배포한 거네요. 버퍼 오버플로 취약점이 있는 코드를 짜는 것과 다를 바 없습니다.
정확히 오버플로가 일어나도록 구성해 놓고도, "아마 스마트 포인터를 쓸 테니 괜찮겠지" 같은 생각으로 오버플로 취약점이 아닐 거라고 가정한 겁니다.
저는 그렇게 읽었습니다.
저는 캐시 히트나 생성과 별개로, 한 번의 프리필은 681k 토큰까지만 가능하다는 뜻으로 읽었습니다. 그렇게 긴 세션에서는 캐시 미스를 피하려고 다들 꽤 애를 쓰고, 그만큼 큰 단독 요청을 보내는 일도 드물어서 이 조건이 발동하는 경우는 드물 겁니다. 여러 턴에 걸친 평범한 코딩 세션이라면 1M까지도 문제없이 갑니다.
저는 이 RCA(근본 원인 분석)가 다른 대부분보다 훨씬 마음에 듭니다. 책임을 인정하는 태도와 테스트에서 이 버그를 잡지 못한 이유를 명확하게 설명한 점이 좋습니다.
또 문제가 생기자 모델을 내리고 꽤 빠르게 수습한 속도도 인상적입니다. 사실 수습 속도 자체는 저한테 덜 중요하지만, 자기네 플랫폼에서 모델 서빙을 바로 끊을 수 있다는 걸 보여준 건 좋습니다.